DevToys is a cross-platform Swiss Army knife for developers. DevToys helps in daily tasks like formatting JSON, comparing text, testing RegExp. No need to use many untruthful websites to do simple tasks with your data.

DevToys - A Swiss Army knife for developers

devtoys는 base64 인코딩 디코딩, uuid 생성, html 인코더 디코더, json <-> yaml 변환, 마크다운 프리뷰 등 다양한 기능을 지원하는데요!

전 개발하다가 가끔 구글에서 json2table web.. 이런 식으로 찾아서 볼 때도 있는데..
이 앱 한개로 다 해결돼요!

(무료라서 무조건 좋군요..ㅋㅋㅋㅋ)

https://devtoys.app/

devtoys는 base64 인코딩 디코딩, uuid 생성, html 인코더 디코더, json &lt;-&gt; yaml 변환, 마크다운 프리뷰 등 다양한 기능을 지원하는데요! 전 개발하다가 가끔 구글에서 json2table web.. 이런 식으로 찾아서 볼 때도 있는데.. 이 앱 한개로 다 해결돼요! (무료라서 무조건 좋군요..ㅋㅋㅋㅋ) https://devtoys.app/

Devtoys

개발자라면 이걸 깔아보는 거 어때요?

너무좋네요 ㅎㅎㅎ 감사합니다!!

One of my udemy students asked a question about the difference between Postgres and MySQL. The answer turned out too long I thought I'll make it into a post. In a nutshell, the main difference...

Postgres vs MySQL

간단히 말해, 두 데이터베이스의 주요한 차이점은 기본 인덱스와 보조 인덱스를 구현하고, 데이터를 저장하고 업데이트하는 방법으로 요약됩니다. 이에 대해 더 살펴보겠습니다. 

MySQL
기본 인덱스에서 값은 모든 속성을 포함한 전체 행 객체입니다. 그래서 기본 인덱스를 클러스터형 인덱스(clustered indexes) 또는 인덱스-조직형 테이블(index-organized table)이라고 부르는 경우가 많습니다. 즉, 기본 인덱스는 테이블입니다.
 
기본 인덱스에서 키를 조회하면 키가 존재하는 페이지와 해당 키의 값(즉, 전체 행)을 찾을 수 있어 추가 열을 가져오기 위한 추가 I/O가 필요하지 않습니다.
 
보조 인덱스에서는 키가 인덱싱된 열(들)이고 값은 실제 행이 위치한 곳을 가리키는 포인터입니다. 보조 인덱스 리프 페이지의 값은 주로 기본 키입니다.
 
MySQL에서는 모든 테이블에 기본 인덱스가 있어야 하며, 모든 추가 보조 인덱스는 기본 키를 가리킵니다. MySQL 테이블에 기본 키를 생성하지 않으면 시스템이 이를 생성합니다

PostgreSQL
PostgreSQL에서는 기본 인덱스가 없으며, 모든 인덱스는 보조 인덱스이고 시스템이 관리하는 데이터 페이지의 튜플 ID를 가리킵니다. 힙에 로드된 테이블 데이터는 기본 인덱스 리프 페이지와 달리 정렬되지 않습니다. 따라서 행을 1-100까지 삽입하고 모든 행이 동일한 페이지에 있을 때, 나중에 120번 행을 업데이트하면 이 20개의 행이 다른 페이지로 이동해 순서가 뒤바뀔 수 있습니다. 반면 클러스터형 기본 인덱스에서는 키의 순서를 만족하는 페이지로 삽입해야 합니다. 그래서 PostgreSQL 테이블은 "힙 조직형 테이블(heap organized tables)"로 자주 불립니다.
 
PostgreSQL에서는 업데이트와 삭제가 실제로 삽입입니다. 모든 업데이트나 삭제는 새로운 튜플 ID를 생성하고, MVCC(Multi-Version Concurrency Control) 이유로 기존 튜플 ID는 유지됩니다.

Processes vs Threads
MySQL은 스레드를 사용합니다. 이는 여러 이유로 효율적일 수 있습니다:
 * 경량성: 스레드는 프로세스보다 가벼워서 시스템 자원을 덜 사용합니다.
 * 메모리 공유: 스레드는 부모 프로세스의 가상 메모리 주소를 공유하므로 메모리 사용 효율성이 높습니다.
 * 컨텍스트 스위칭: 스레드 간의 컨텍스트 스위칭은 TLB(Translation Look-aside Buffer)를 무효화하지 않기 때문에 상대적으로 빠릅니다. 이는 메모리 매핑이 동일하기 때문에 메모리 접근이 더 효율적입니다.
PostgreSQL은 프로세스를 사용합니다. 이는 스레드 기반 접근 방식과 비교하여 다음과 같은 장단점이 있습니다:
 * 독립성: 각 프로세스는 독립된 가상 메모리를 가지므로 하나의 프로세스가 크래시하더라도 다른 프로세스에 영향을 미치지 않습니다.
 * PCB vs. TCB: 프로세스 제어 블록(PCB)이 스레드 제어 블록(TCB)보다 크지만, 이는 프로세스가 독립된 자원과 환경을 가지고 있기 때문입니다.

Summary
각 데이터베이스 시스템의 장단점을 이해하고, 여러분의 사용 사례와 쿼리에 맞는 시스템을 선택하는 것이 중요합니다. MySQL의 스레드 기반 접근 방식은 가벼운 메모리 사용과 빠른 컨텍스트 스위칭을 제공하는 반면, PostgreSQL의 프로세스 기반 접근 방식은 더 높은 독립성과 안정성을 제공합니다. 따라서 어떤 데이터베이스가 더 적합한지는 사용자의 특정 요구 사항과 환경에 따라 달라질 수 있습니다.
 
결론적으로, 어떤 데이터베이스 시스템이 더 좋다고 단정 지을 수는 없습니다. 각각의 데이터베이스 시스템이 제공하는 기능과 성능을 이해하고, 여러분의 필요에 가장 적합한 것을 선택하는 것이 중요합니다.

번역: [https://ducktopia.tistory.com/128]
원문:

간단히 말해, 두 데이터베이스의 주요한 차이점은 기본 인덱스와 보조 인덱스를 구현하고, 데이터를 저장하고 업데이트하는 방법으로 요약됩니다. 이에 대해 더 살펴보겠습니다.&nbsp; MySQL기본 인덱스에서 값은 모든 속성을 포함한 전체 행 객체입니다. 그래서 기본 인덱스를 클러스터형 인덱스(clustered indexes) 또는 인덱스-조직형 테이블(index-organized table)이라고 부르는 경우가 많습니다. 즉, 기본 인덱스는 테이블입니다.&nbsp;기본 인덱스에서 키를 조회하면 키가 존재하는 페이지와 해당 키의 값(즉, 전체 행)을 찾을 수 있어 추가 열을 가져오기 위한 추가 I/O가 필요하지 않습니다.&nbsp;보조 인덱스에서는 키가 인덱싱된 열(들)이고 값은 실제 행이 위치한 곳을 가리키는 포인터입니다. 보조 인덱스 리프 페이지의 값은 주로 기본 키입니다.&nbsp;MySQL에서는 모든 테이블에 기본 인덱스가 있어야 하며, 모든 추가 보조 인덱스는 기본 키를 가리킵니다. MySQL 테이블에 기본 키를 생성하지 않으면 시스템이 이를 생성합니다 PostgreSQLPostgreSQL에서는 기본 인덱스가 없으며, 모든 인덱스는 보조 인덱스이고 시스템이 관리하는 데이터 페이지의 튜플 ID를 가리킵니다. 힙에 로드된 테이블 데이터는 기본 인덱스 리프 페이지와 달리 정렬되지 않습니다. 따라서 행을 1-100까지 삽입하고 모든 행이 동일한 페이지에 있을 때, 나중에 120번 행을 업데이트하면 이 20개의 행이 다른 페이지로 이동해 순서가 뒤바뀔 수 있습니다. 반면 클러스터형 기본 인덱스에서는 키의 순서를 만족하는 페이지로 삽입해야 합니다. 그래서 PostgreSQL 테이블은 "힙 조직형 테이블(heap organized tables)"로 자주 불립니다.&nbsp;PostgreSQL에서는 업데이트와 삭제가 실제로 삽입입니다. 모든 업데이트나 삭제는 새로운 튜플 ID를 생성하고, MVCC(Multi-Version Concurrency Control) 이유로 기존 튜플 ID는 유지됩니다. Processes vs ThreadsMySQL은 스레드를 사용합니다. 이는 여러 이유로 효율적일 수 있습니다:<ul ><li>경량성: 스레드는 프로세스보다 가벼워서 시스템 자원을 덜 사용합니다.</li><li>메모리 공유: 스레드는 부모 프로세스의 가상 메모리 주소를 공유하므로 메모리 사용 효율성이 높습니다.</li><li>컨텍스트 스위칭: 스레드 간의 컨텍스트 스위칭은 TLB(Translation Look-aside Buffer)를 무효화하지 않기 때문에 상대적으로 빠릅니다. 이는 메모리 매핑이 동일하기 때문에 메모리 접근이 더 효율적입니다.</li></ul>PostgreSQL은 프로세스를 사용합니다. 이는 스레드 기반 접근 방식과 비교하여 다음과 같은 장단점이 있습니다:<ul ><li>독립성: 각 프로세스는 독립된 가상 메모리를 가지므로 하나의 프로세스가 크래시하더라도 다른 프로세스에 영향을 미치지 않습니다.</li><li>PCB vs. TCB: 프로세스 제어 블록(PCB)이 스레드 제어 블록(TCB)보다 크지만, 이는 프로세스가 독립된 자원과 환경을 가지고 있기 때문입니다.</li></ul> Summary각 데이터베이스 시스템의 장단점을 이해하고, 여러분의 사용 사례와 쿼리에 맞는 시스템을 선택하는 것이 중요합니다. MySQL의 스레드 기반 접근 방식은 가벼운 메모리 사용과 빠른 컨텍스트 스위칭을 제공하는 반면, PostgreSQL의 프로세스 기반 접근 방식은 더 높은 독립성과 안정성을 제공합니다. 따라서 어떤 데이터베이스가 더 적합한지는 사용자의 특정 요구 사항과 환경에 따라 달라질 수 있습니다.&nbsp;결론적으로, 어떤 데이터베이스 시스템이 더 좋다고 단정 지을 수는 없습니다. 각각의 데이터베이스 시스템이 제공하는 기능과 성능을 이해하고, 여러분의 필요에 가장 적합한 것을 선택하는 것이 중요합니다. 번역: [https://ducktopia.tistory.com/128]원문:

Medium

🕊️[Medium] Postgres vs MySQL

이번 영상의 주인공은 실리콘밸리 인스타그램 수석 엔지니어이자 ChatGPT 유튜브 채널 커리어해커 알렉스(@careerhackeralex)를 운영하고 계시는 안상현님입니다. 실리콘밸리 최전선에 있는 현직자는 ChatGPT를 어떻게 활용하고 있을까요? 더 나아가 AI시대 앞으로 우리의 경쟁력은 무엇이 될지 상현님의 인사이트를 지금 바로 만나보시죠. #챗gpt #인공지능 #코딩 2017년, 1인 크리에이터의 프로젝트로 시작된 EO의 대표 시리즈, [리얼밸리

AI 시대 변화가 두려운 모든 분들에게 | 인스타그램 수석 개발자 알렉스

AI의 발달로 일자리가 없어지지 않느냐는 불안은 여러 직군에서 이야기가 나오고 있습니다. 특히, 저희 개발자들은 더욱더 그렇죠. 사실 개발을 잘 모르는 사람도 AI를 통해 그 어려운 개발도 손쉽게 할 수 있는 세상이 오다 보니 개발을 주 업으로 하고 있는 저희 개발자들 입장에서는 소위 "현타"가 올 정도니까요. 그렇지만 이러한 "위기"를 곧 "기회"로 삼는 분들이 꽤 많으신데요. 이번에 공유드리는 영상은 실리콘밸리 인스타그램 수석 엔지니어가 생각하는 AI 도구 즉, ChatGPT에 대해 어떻게 바라봐야 하는가에 대해 이야기를 하고 있습니다.

이 영상에서는 각자의 자원은 한정되어 있기에 내가 가진 자원으로 최대한의 성과를 내는 것이 중요하다고 이야기를 하고, 그에 ChatGPT는 상식을 깨는 매우 불규칙한 도구였으며, 현 시점에서 가장 강력한 리소스라고 생각한다고 합니다. 그 이유로 ChatGPT의 가장 혁신적인 부분은 생각을 표현하는 궁극적인 매개체인 언어를 모방한다는 점인데요. 시작의 부담과 길을 줄여줄 수 있는 도구가 좋은데, ChatGPT는 생각을 주입하는 방식으로 시작에 도움을 주고 있습니다. 궁극적으로 ChatGPT를 대체, 자동화, 새로운 가치 창출을 위한 리소스로 활용하는 방법에 대한 질문이 늘고 있죠. 도구를 주도함으로써 원하는 결과물을 얻을 수 있고, 그런 도구가 있으면 이전에는 불가능했던 일을 할 수 있다고 합니다.

저 또한 이 영상을 보기 전, 그러니까 ChatGPT가 세상에 본격적으로 나와 개발자들의 일자리가 없어진다는 말을 들을 때면 항상 "오히려 좋아"라는 생각을 했던 것 같습니다. 정통 자바 백엔드 개발자인 저로서 최근에 프론트 개발이라든지, Spark, Scala 등 전혀 경험해 보지 못한 영역에서 개발을 해야 하는 상황인데 이때 ChatGPT의 도움을 받아 개발을 하고 있죠. 여기서 중요한 점은 이러이러한 상황에서 코드를 만들어줘~라고 Q&A 하듯 물어만 보는 것에서 그치지 않고 왜 그러한 코드가 작성되었는지, 문법은 어떻고 어떤 의미를 가지는지 등 세부적으로 물어보며 ChatGPT가 제시하는 문맥 그 자체를 이해하려고 노력하려 합니다. 거의 과외 선생님인 샘이죠. 그렇게 ChatGPT를 활용해서 작성한 코드를 마지막엔 관련 개발에 경험이 풍부한 동료들과 함께 코드 리뷰를 하며 개발을 마무리하는 게 요즘의 일상 같습니다.

여러분들은 ChatGPT, AI를 어떻게 활용하고 계시나요? 단순 구글링 수준으로만 활용하신다면 모든 순간순간마다 AI를 도입하여 복잡하고 반복적인 부분들은 맡겨두고 더 중요한 본질에 대해 고민하는 시간을 할애하는데 집중하는 건 어떨까요? 아무리 AI가 날뛰어도 저희 개발자(사람)가 해야 하는 영역은 분명히 있다고 믿으니까요 ㅎ

https://www.youtube.com/watch?v=_drFaRrJxlQ

AI의 발달로 일자리가 없어지지 않느냐는 불안은 여러 직군에서 이야기가 나오고 있습니다. 특히, 저희 개발자들은 더욱더 그렇죠. 사실 개발을 잘 모르는 사람도 AI를 통해 그 어려운 개발도 손쉽게 할 수 있는 세상이 오다 보니 개발을 주 업으로 하고 있는 저희 개발자들 입장에서는 소위 "현타"가 올 정도니까요. 그렇지만 이러한 "위기"를 곧 "기회"로 삼는 분들이 꽤 많으신데요. 이번에 공유드리는 영상은 실리콘밸리&nbsp;인스타그램&nbsp;수석&nbsp;엔지니어가 생각하는 AI 도구 즉, ChatGPT에 대해 어떻게 바라봐야 하는가에 대해 이야기를 하고 있습니다. 이 영상에서는 각자의 자원은 한정되어 있기에 내가 가진 자원으로 최대한의 성과를 내는 것이 중요하다고 이야기를 하고, 그에 ChatGPT는 상식을 깨는 매우 불규칙한 도구였으며, 현 시점에서 가장 강력한 리소스라고 생각한다고 합니다. 그 이유로 ChatGPT의 가장 혁신적인 부분은 생각을 표현하는 궁극적인 매개체인 언어를 모방한다는 점인데요. 시작의 부담과 길을 줄여줄 수 있는 도구가 좋은데, ChatGPT는 생각을 주입하는 방식으로 시작에 도움을 주고 있습니다. 궁극적으로 ChatGPT를 대체, 자동화, 새로운 가치 창출을 위한 리소스로 활용하는 방법에 대한 질문이 늘고 있죠. 도구를 주도함으로써 원하는 결과물을 얻을 수 있고, 그런 도구가 있으면 이전에는 불가능했던 일을 할 수 있다고 합니다. 저 또한 이 영상을 보기 전, 그러니까 ChatGPT가 세상에 본격적으로 나와 개발자들의 일자리가 없어진다는 말을 들을 때면 항상 "오히려 좋아"라는 생각을 했던 것 같습니다. 정통 자바 백엔드 개발자인 저로서 최근에 프론트 개발이라든지, Spark, Scala 등 전혀 경험해 보지 못한 영역에서 개발을 해야 하는 상황인데 이때 ChatGPT의 도움을 받아 개발을 하고 있죠. 여기서 중요한 점은 이러이러한 상황에서 코드를 만들어줘~라고 Q&amp;A 하듯 물어만 보는 것에서 그치지 않고 왜 그러한 코드가 작성되었는지, 문법은 어떻고 어떤 의미를 가지는지 등 세부적으로 물어보며 ChatGPT가 제시하는 문맥 그 자체를 이해하려고 노력하려 합니다. 거의 과외 선생님인 샘이죠. 그렇게 ChatGPT를 활용해서 작성한 코드를 마지막엔 관련 개발에 경험이 풍부한 동료들과 함께 코드 리뷰를 하며 개발을 마무리하는 게 요즘의 일상 같습니다. 여러분들은 ChatGPT, AI를 어떻게 활용하고 계시나요? 단순 구글링 수준으로만 활용하신다면 모든 순간순간마다 AI를 도입하여 복잡하고 반복적인 부분들은 맡겨두고 더 중요한 본질에 대해 고민하는 시간을 할애하는데 집중하는 건 어떨까요? 아무리 AI가 날뛰어도 저희 개발자(사람)가 해야 하는 영역은 분명히 있다고 믿으니까요 ㅎ https://www.youtube.com/watch?v=_drFaRrJxlQ ﻿

YouTube

Groq에서 Whisper API를 드디어 사용 할 수 있게 되었네요. 역시 속도가 압도적입니다. 스트리밍 API인 줄..😲

오리지널인 OpenAI API보다 4.6배 빠르고, 12배가 쌉니다. (단, OpenAI는 Whisper v2, Groq는 v3)

어떻게 한 건진 모르겠지만 fal ai가 Groq만 빠른데, 얘는 API가 보안적인 위험이 있을 수 있어서 배치처리 용도 외에는 좀 그랬는데요. 이제 실시간 용도가 필요하면 Groq을 사용하면 될 것 같네요.

Groq에서 Whisper API를 드디어 사용 할 수 있게 되었네요. 역시 속도가 압도적입니다. 스트리밍 API인 줄..😲 오리지널인 OpenAI API보다 4.6배 빠르고, 12배가 쌉니다. (단, OpenAI는 Whisper v2, Groq는 v3) 어떻게 한 건진 모르겠지만 fal ai가 Groq만 빠른데, 얘는 API가 보안적인 위험이 있을 수 있어서 배치처리 용도 외에는 좀 그랬는데요. 이제 실시간 용도가 필요하면 Groq을 사용하면 될 것 같네요.

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

많은 한국 개발자들이 코딩을 중단하고 매니지먼트쪽으로 들어가는 것 굉장히 두려워한다. 사실 모든 사람들이 매니저 역할을 할 필요는 없지만 코딩을 계속한다고 해도 개인기를 부려서 혼자만 인정받으려 하지 말아야 한다. 단순 코딩을 잘 하는 것이 아닌 그 이상이 필요하고 그게 내 경쟁력이 되어야 한다는 점인데 의사소통을 잘 해서 문제 정의를 잘 하고 주어진 업무의 완료 시간 추정 잘하고 내가 만든 코드를 운영 관점에서도 바라봐야 한다. 그냥 혼자 코딩만 잘 한다면 요즘처럼 AI 코딩 생산성 툴이 나오는 세상에서는 대체 1순위가 되기 쉽다.

그럼 영향력이란 무엇일까? 나의 존재로 인해 내 주변 사람들의 역량이 올라가는 것이라 생각한다. 영향력은 꼭 매니저에게만 필요한 것일까? 그와 상관없이 시니어급이라면 꼭 갖추어야할 기술이다. "기술"이라고 지칭한 이유는 타고나는 재능이 아니란 점을 분명히 하고 싶어서다. 즉 처음부터 잘 한다기 보다는 크고 작은 실수/실패를 거쳐서 생겨나는 기술이다.

영향력의 시작은 좋은 평판을 갖는 것이다. 앞서 이야기한 맡은 일의 결과를 만들어내고 맞는 공헌을 하는 사람이 되는 것이 좋은 평판의 한 포인트이고 다른 한 포인트는 팀 플레이어가 되는 것이다. 팀 플레이어라는 관점에서는 긍정적인 태도를 바탕으로 내가 맡은 업무 뿐만 아니라 내 업무 밖의 일도 팀을 위해 하는 그런 모습을 갖는 것이 중요하다. 즉 좋은 평판이란 다시 같이 일하고 싶은 사람이 되는 것이며 이를 통해 생각하지 못했던 기회가 생긴다 ("지인 추천")

좋은 평판 = 맡은 일의 결과를 내기 x 팀 플레이어가 되기

여러분의 커리어 후반기에도 새로운 기회를 매번 내가 찾아서 가야한다면 그게 과연 원하는 길일까? 좋은 평판을 통해 지인 추천의 형태로 기회를 만들어내는 것이 더 자연스럽다고 생각한다.

구체적인 영향력을 갖는 방법은 여러가지가 있다.

 1. 주변 사람들을 잘 도와준다. 주니어들을 잘 코칭해준다. 주니어들의 일을 대신 해주라는 이야기가 아니다. 누가 새로 들어와서 헤매는 것 같으면 도움이 되는 조언해주고 막힌 부분을 뚫어준다.
 2. 미팅을 리딩하거나 할때 다양한 사람들이 자기의 의견을 쉽게 표현할 수 있는 환경을 만들고 의견을 내지 못하고 자기검열하는 사람들 찝어서 말을 시켜본다.
 3. 리더나 리드로써 다른 팀원이 해야할 일을 본인이 습관적으로 하고 있는지 고민해보고 일을 넘기는 노력을 한다. 지난 회에 이야기했던 것처럼 나의 역할에 맞는 공헌/임팩트를 내는 것이 중요하다.
 4. 사람들이나 팀간의 충돌이 있을 때 해결하는데 초점을 맞추고 원칙을 만들어 다음에 비슷한 문제가 생겼을 때 방안으로 바라볼 수 있게 만든다.
 5. 아쉬운 행동을 하는 사람을 바라보는 관점은 호기심이 되어야 하며 항상 선의를 가지고 행동해야 한다.

9번에 걸쳐 긴 커리어를 행복하게 이어갈 수 있는 개발자의 마인드셋에 대해 이야기해보았다. 요약하면 수능준비처럼 몇년 공부해서 되는 것이 아니고 오랜 시간에 걸쳐 실수와 고민을 통해 만들어지는 것이란 점을 꼭 기억했으면 좋겠다. 다음에는 조금더 기술적인 측면에서 이야기를 해보고자 한다.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 많은 한국 개발자들이 코딩을 중단하고 매니지먼트쪽으로 들어가는 것 굉장히 두려워한다. 사실 모든 사람들이 매니저 역할을 할 필요는 없지만 코딩을 계속한다고 해도 개인기를 부려서 혼자만 인정받으려 하지 말아야 한다. 단순 코딩을 잘 하는 것이 아닌 그 이상이 필요하고 그게 내 경쟁력이 되어야 한다는 점인데 의사소통을 잘 해서 문제 정의를 잘 하고 주어진 업무의 완료 시간 추정 잘하고 내가 만든 코드를 운영 관점에서도 바라봐야 한다. 그냥 혼자 코딩만 잘 한다면 요즘처럼 AI 코딩 생산성 툴이 나오는 세상에서는 대체 1순위가 되기 쉽다. 그럼 영향력이란 무엇일까? 나의 존재로 인해 내 주변 사람들의 역량이 올라가는 것이라 생각한다. 영향력은 꼭 매니저에게만 필요한 것일까? 그와 상관없이 시니어급이라면 꼭 갖추어야할 기술이다. "기술"이라고 지칭한 이유는 타고나는 재능이 아니란 점을 분명히 하고 싶어서다. 즉 처음부터 잘 한다기 보다는 크고 작은 실수/실패를 거쳐서 생겨나는 기술이다. 영향력의 시작은 좋은 평판을 갖는 것이다. 앞서 이야기한 맡은 일의 결과를 만들어내고 맞는 공헌을 하는 사람이 되는 것이 좋은 평판의 한 포인트이고 다른 한 포인트는 팀 플레이어가 되는 것이다. 팀 플레이어라는 관점에서는 긍정적인 태도를 바탕으로 내가 맡은 업무 뿐만 아니라 내 업무 밖의 일도 팀을 위해 하는 그런 모습을 갖는 것이 중요하다. 즉 좋은 평판이란 다시 같이 일하고 싶은 사람이 되는 것이며 이를 통해 생각하지 못했던 기회가 생긴다 ("지인 추천") 좋은 평판 = 맡은 일의 결과를 내기 x 팀 플레이어가 되기 여러분의 커리어 후반기에도 새로운 기회를 매번 내가 찾아서 가야한다면 그게 과연 원하는 길일까? 좋은 평판을 통해 지인 추천의 형태로 기회를 만들어내는 것이 더 자연스럽다고 생각한다. 구체적인 영향력을 갖는 방법은 여러가지가 있다. <ol ><li>주변 사람들을 잘 도와준다. 주니어들을 잘 코칭해준다. 주니어들의 일을 대신 해주라는 이야기가 아니다. 누가 새로 들어와서 헤매는 것 같으면 도움이 되는 조언해주고 막힌 부분을 뚫어준다. </li><li>미팅을 리딩하거나 할때 다양한 사람들이 자기의 의견을 쉽게 표현할 수 있는 환경을 만들고 의견을 내지 못하고 자기검열하는 사람들 찝어서 말을 시켜본다.</li><li>리더나 리드로써 다른 팀원이 해야할 일을 본인이 습관적으로 하고 있는지 고민해보고 일을 넘기는 노력을 한다. 지난 회에 이야기했던 것처럼 나의 역할에 맞는 공헌/임팩트를 내는 것이 중요하다. </li><li>사람들이나 팀간의 충돌이 있을 때 해결하는데 초점을 맞추고 원칙을 만들어 다음에 비슷한 문제가 생겼을 때 방안으로 바라볼 수 있게 만든다.</li><li>아쉬운 행동을 하는 사람을 바라보는 관점은 호기심이 되어야 하며 항상 선의를 가지고 행동해야 한다.</li></ol> 9번에 걸쳐 긴 커리어를 행복하게 이어갈 수 있는 개발자의 마인드셋에 대해 이야기해보았다. 요약하면 수능준비처럼 몇년 공부해서 되는 것이 아니고 오랜 시간에 걸쳐 실수와 고민을 통해 만들어지는 것이란 점을 꼭 기억했으면 좋겠다. 다음에는 조금더 기술적인 측면에서 이야기를 해보고자 한다.

좋은 개발자가 알아야하는 9가지 포인트들 - 9. 영향력 갖기

오랜 시간의 실행과 회고를 통해 만들어진다는 점 꼭 기억하겠습니다.

무려 37년전에 애플에서 만든 노코드 툴(!)의 원조 하이퍼카드의 웹 시뮬레이터. 저는 실제로 써 본 적은 없지만, 컨셉이 정말 매우 미래지향적입니다. 지금봐도 미래지향적임. 시뮬레이터 구현을 정말 잘 해 놨네요. 심심풀이 장난감으로 재밌습니다. 👍

무려 37년전에 애플에서 만든 노코드 툴(!)의 원조 하이퍼카드의 웹 시뮬레이터. 저는 실제로 써 본 적은 없지만, 컨셉이 정말 매우 미래지향적입니다. 지금봐도 미래지향적임. 시뮬레이터 구현을 정말 잘 해 놨네요. 심심풀이 장난감으로 재밌습니다. 👍

아참, 링크 👉 https://hcsimulator.com/

아인슈타인 윈도우(Einstein Window)는 최근 제가 배운 효율적인 시간 관리 전략입니다. 하루 중 창의성과 생산성을 최대로 발휘할 수 있는 시간대를 파악하고 그 시간을 최대한 활용하려는 방법입니다.

아인슈타인 윈도우(Einstein Window)는 각 개인이 가장 집중력이 높고 창의적인 생각이 가능한 '멘탈 피크 타임(Mental Peak Time)'을 파악한 뒤, 그 시간을 가장 중요한 작업에 할애하는 것을 목표로 합니다. 멘탈 피크 타임은 각 개인마다 그 시간대가 다르며, 평균적으로 약 2시간에서 4시간 사이로 알려져 있습니다.

아인슈타인 윈도우를 찾고 활용하는 방법은 다음과 같습니다.

✅ 자기 관찰하기
몇 주 동안 자신의 일과를 관찰하여, 언제 가장 집중하고 생산적인지 기록합니다. 이를 통해 자신의 피크 타임을 확인할 수 있습니다.

✅ 중요한 작업 선별하기
자신의 아인슈타인 윈도우 내에서 가장 중요하거나 창의력이 필요한 작업을 배치합니다. 이 시간을 최대한 효과적으로 사용하도록 계획합니다.

✅ 방해 금지
아인슈타인 윈도우 동안에는 방해받지 않도록 주변 환경을 조정합니다. 전화기나 이메일 같은 방해 요소를 최소화하고, 조용하고 집중할 수 있는 환경을 만듭니다.

✅ 일관성 유지하기
매일 같은 시간대에 중요한 작업을 수행함으로써, 몸과 마음이 그 시간에 최적의 성과를 낼 수 있도록 훈련합니다.

✅ 평가 및 조정하기
정기적으로 자신의 생산성을 평가하고 아인슈타인 윈도우가 여전히 최적인지 확인합니다. 필요하다면 시간대를 조정하여 계속해서 최고의 성과를 낼 수 있도록 합니다.

위 5가지 방법을 통해 우리는 개인의 생산성을 극대화하고, 시간을 보다 효율적으로 관리할 수 있습니다.

#데이터리차드 #시간관리 #생산성 #아인슈타인 #윈도우

아인슈타인 윈도우(Einstein Window)는 최근 제가 배운 효율적인 시간 관리 전략입니다. 하루 중 창의성과 생산성을 최대로 발휘할 수 있는 시간대를 파악하고 그 시간을 최대한 활용하려는 방법입니다. 아인슈타인 윈도우(Einstein Window)는 각 개인이 가장 집중력이 높고 창의적인 생각이 가능한 '멘탈 피크 타임(Mental Peak Time)'을 파악한 뒤, 그 시간을 가장 중요한 작업에 할애하는 것을 목표로 합니다. 멘탈 피크 타임은 각 개인마다 그 시간대가 다르며, 평균적으로 약 2시간에서 4시간 사이로 알려져 있습니다. 아인슈타인 윈도우를 찾고 활용하는 방법은 다음과 같습니다. ✅ 자기 관찰하기 몇 주 동안 자신의 일과를 관찰하여, 언제 가장 집중하고 생산적인지 기록합니다. 이를 통해 자신의 피크 타임을 확인할 수 있습니다. ✅ 중요한 작업 선별하기 자신의 아인슈타인 윈도우 내에서 가장 중요하거나 창의력이 필요한 작업을 배치합니다. 이 시간을 최대한 효과적으로 사용하도록 계획합니다. ✅ 방해 금지 아인슈타인 윈도우 동안에는 방해받지 않도록 주변 환경을 조정합니다. 전화기나 이메일 같은 방해 요소를 최소화하고, 조용하고 집중할 수 있는 환경을 만듭니다. ✅ 일관성 유지하기 매일 같은 시간대에 중요한 작업을 수행함으로써, 몸과 마음이 그 시간에 최적의 성과를 낼 수 있도록 훈련합니다. ✅ 평가 및 조정하기 정기적으로 자신의 생산성을 평가하고 아인슈타인 윈도우가 여전히 최적인지 확인합니다. 필요하다면 시간대를 조정하여 계속해서 최고의 성과를 낼 수 있도록 합니다. 위 5가지 방법을 통해 우리는 개인의 생산성을 극대화하고, 시간을 보다 효율적으로 관리할 수 있습니다. #데이터리차드 #시간관리 #생산성 #아인슈타인 #윈도우

아인슈타인 윈도우(Einstein Window)

디자인시스템 래핑 후 1년 뒤..

디자인 시스템을 많은 회사에서 고려하지만, 함부로 도전하면 안된다고 생각합니다.
디자인 시스템 자체 개발은 많은 자원을 요구됩니다. 그렇지만 대게 없는 리소스로 일하다가 어떻게 생산성을 끌어올릴까 고민해서 시작하는 경우가 많습니다.

만드는게 문제가 아니라 그 이후에 유지보수 하느라 수많은 커뮤니케이션과 긴급 대응이 발생할 겁니다. 이걸 감당하기 쉽지 않습니다.
사업은 살아있는 생물같아서 강건너나 다른 나라, 혹은 우주로 날아가버리기도 합니다. 그러면 기존 디자인 요소로 따라가지 못하는 요소가 범람하고, 디자인시스템이 무용지물이 되기도 합니다.

글에서 범용적인 디자인 시스템을 래핑해서 커스텀하는 현실적인 조언을 합니다.

만약 누군가 조직 안에서 디자인시스템이란 말을 꺼냈다면, 문제가 디자인 시스템이 없어서 발생했는지 고민해봐야겠습니다.

https://velog.io/@pandati0710/스타트업의-현실적인-디자인시스템-제작-후-1년-뒤

디자인 시스템을 많은 회사에서 고려하지만, 함부로 도전하면 안된다고 생각합니다.디자인 시스템 자체 개발은 많은 자원을 요구됩니다. 그렇지만 대게 없는 리소스로 일하다가 어떻게 생산성을 끌어올릴까 고민해서 시작하는 경우가 많습니다. 만드는게 문제가 아니라 그 이후에 유지보수 하느라 수많은 커뮤니케이션과 긴급 대응이 발생할 겁니다. 이걸 감당하기 쉽지 않습니다.사업은 살아있는 생물같아서 강건너나 다른 나라, 혹은 우주로 날아가버리기도 합니다. 그러면 기존 디자인 요소로 따라가지 못하는 요소가 범람하고, 디자인시스템이 무용지물이 되기도 합니다. 글에서 범용적인 디자인 시스템을 래핑해서 커스텀하는 현실적인 조언을 합니다. 만약 누군가 조직 안에서 디자인시스템이란 말을 꺼냈다면, 문제가 디자인 시스템이 없어서 발생했는지 고민해봐야겠습니다. https://velog.io/@pandati0710/스타트업의-현실적인-디자인시스템-제작-후-1년-뒤

Velog

유지보수하느라 많은 코스트가 드는것에 공감갑니다ㅎㅎ
그래서 요즘엔 코드 자체를 복사해서 가져다 커스텀 할 수 있는 레포지토리가 있더라구요
아무래도 범용 디자인시스템들도 커스텀에는 한계가 있나봅니다.
https://ui.shadcn.com/
2023년 기준 star수 1위였다고 하네요!

개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등.

기술 스택만큼 중요한 비즈니스 도메인

개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등... 이렇게 꼬리에 꼬리를 잊는 질문이 이어지죠. 제 답변을 들은 후 실망하는 표정을 감추지 못하는 지원자도 보았습니다 😞

그러나 정작 본인이 지원한 회사가 어떤 사업을 하는지에 대한 관심을 갖고 좋은 질문을 하는 개발자들은 상대적으로 드문 것 같아요. 혹시 기술 스택(Tech Stack)만 나랑 잘 맞으면 어떤 비즈니스든지 입사해서 천천히 배울 수 있다고 생각하시는 건가요? 🤨

사실 제가 예전에 그랬거든요... 하하 😂

저도 예전에는 이직하거나 팀을 옮길 때 사용하는 기술을 매우 중요하게 생각했어요. 특히 한국에서 일했을 때는 주구장창 자바와 스프링, 오라클 DB로만 개발하여 이 기술 스택을 벗어나는 회사를 기피했죠. 힘들게 쌓은 지식과 경험을 새로운 업무에서 100% 활용할 수 없을까봐 걱정이 됐고, 앞으로의 경력에 도움이 될지 모를 생소한 기술을 배워야 하는데 부담을 느꼈습니다.

그런데 소프트웨어 개발을 시작한 지 언 16년이 지난 현재의 관점에서 생각해보면, 그 때 제 생각이 참 짧았다는 생각이 들어요. 기껏해야 몇 년 안 되는 경험을, 까짓 것 좀 못 살리면 어떻다고... 그 새로운 기술을 배울 수 있는 좋은 기회들을 그냥 보내 버렸을까요? 깐깐하게 기술 스택을 따지는 것도 중요하겠지만, 이 바닥에서 점점 경력이 쌓이다 보니 자신에게 잘 맞는 비즈니스 도메인을 선택하는 것도 그에 못지 않게 참 중요하다는 생각이 듭니다.

우리 한번 소프트웨어 개발자로서 냉정하게 생각을 해볼까요? 새로운 기술을 배우는 게 힘든가요? 새로운 비즈니스를 배우는 게 힘든가요? 개발 관련된 지식은 온라인에 학습 자료가 풍부하며 심지어 무료도 많은데요. 하지만 특정 비즈니스에 대한 지식은 배우는데 많은 비용이 들거나 체계적인 교육없이 노하우처럼 전수되는 경우도 있죠. 따라서 상대적으로 배우려는 의지와 적극성이 더 필요합니다. 해당 비즈니스 도메인에 흥미가 없다면 배우는 과정 자체가 고통이 될 수도 있고요.

아무래도 첫 직장은 선택하기 보다는 선택 당하는 입장이라서 자신이 원하는 비즈니스 도메인을 고르기가 쉽지 않은데요. 저도 첫 직장에서는 생각치도 못했던 기업용 소프트웨어를 개발하게 되었고, ERP(Enterprise Resource Planning)와 CRM(Customer Relationship Management)과 같은 생전 처음 들어보는 방대한 엔터프라이즈 솔루션에 대해서 공부해야 했습니다. 선배 어깨 넘어로 배우다 보니 답답하기도 했지만, 전문 교육은 업무를 1~2주 빠져야 해서 신청하기가 눈치가 보였죠. 그런데 솔직히... 어떻게 보면 이건 다 핑계입니다. 저는 단지 그 비즈니스 도메인에 큰 매력을 느끼지 못했던 것입니다.

그 이후에 다른 회사들을 다니면서 모바일 앱 스토어나 전자 상거래 플랫폼과 같은 대국민 소프트웨어를 개발했는데요. 아무래도 제가 실생활에서 사용하는 서비스다 보니 비즈니스에 대해서 관심이 많아지더라고요. "아, 내가 주문한 제품이 이런 이런 과정을 거쳐서 결제가 되고, 이런 이런 과정을 거쳐서 배송이 되고, 반품은 이런 이런 과정을 거쳐서 이뤄지는구나!" 자꾸 호기심이 생겨서 사업 담당자를 찾아가서 이것저것 자주 물어보곤 했습니다. 귀찮아 하시면 어떨까 걱정했지만 오히려 정반대였습니다. 비즈니스를 제대로 이해하려고 찾아오는 개발자는 어디서든 환영받으니까요.

현재 저는 캐나다에서 아이를 키우는 중이어서, 여느 학부모처럼 저의 관심사는 교육 쪽으로 옮겨가게 되었습니다. 그런데 저는 줄곧 한국에서 교육을 받아왔기 때문에 캐나다의 교육 시스템에 대해 매우 생소했습니다. 그래서 여러 기회가 있었지만 EdTech(교육 기술) 분야에서 한 번 일해보기로 결심했지요. 몇 년간 이 분야에서 몸 담으면서 캐나다의 공교육 행정이 어떻게 돌아가고, 선생님들이 학교에서 어떻게 학생들을 가르치며, 부모들은 어떤 교육을 기대하고 있는지 배울 수가 있었습니다. 이렇게 제가 일을 하면서 체득한 도메인 지식들은 캐나다에서 육아를 하는데 정말 큰 도움이 되고 있습니다.

최근에는 프로젝트 때문에 캐나다를 포함한 여러 교육 선진국들의 유학 프로세스에 대해서 공부하고 있는데요. 저는 한 번도 해외 유학을 가보지 않아서 이 쪽에 대해서는 완전 문외한이었는데, 이제는 제 주변에 있는 많은 이민자들이 어떤 과정을 거쳐 이 나라에서 공부하고 정착까지 하게 되는지에 대해 이해할 수 있게 되었어요. 이처럼 자신이 평소에 관심이 있는 비즈니스 도메인에서 일하게 되면 단순히 소프트웨어 개발을 넘어, 자연스럽게 해당 비즈니스 도메인에서 전문성을 키울 수 있답니다. 도메인 전문성을 갖춘 소프트웨어 개발자는 귀해서 시장에서 항상 좋은 대우를 받는 건 다들 아실 거에요.

요즘에는 진짜 소프트웨어 개발이 필요하지 않은 분야가 없다고 하죠? 그래서 저는 소프트웨어 개발자는 원하는 비즈니스 도메인을 선택할 수 있는 진짜 얼마 안 되는 축복받은 직업이라고 생각합니다. 앞으로 개발자로 커리어를 쌓아가시면서 어떤 기술을 쓰고 싶으신지 뿐만 아니라, 자신이 어떤 비즈니스에 흥미를 느끼시고 배우고 싶으신지에 대해서도 좀 더 생각해보시면 어떨까요?

여러분은 저보다 좀 더 빨리 기술 스택의 굴레에서 벗어나 좀 더 재미있는 비즈니스 도메인에서 일하실 수 있으셨으면 좋겠습니다! 🙏🚀

개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등... 이렇게 꼬리에 꼬리를 잊는 질문이 이어지죠. 제 답변을 들은 후 실망하는 표정을 감추지 못하는 지원자도 보았습니다 😞 그러나 정작 본인이 지원한 회사가 어떤 사업을 하는지에 대한 관심을 갖고 좋은 질문을 하는 개발자들은 상대적으로 드문 것 같아요. 혹시 기술 스택(Tech Stack)만 나랑 잘 맞으면 어떤 비즈니스든지 입사해서 천천히 배울 수 있다고 생각하시는 건가요? 🤨 사실 제가 예전에 그랬거든요... 하하 😂 저도 예전에는 이직하거나 팀을 옮길 때 사용하는 기술을 매우 중요하게 생각했어요. 특히 한국에서 일했을 때는 주구장창 자바와 스프링, 오라클 DB로만 개발하여 이 기술 스택을 벗어나는 회사를 기피했죠. 힘들게 쌓은 지식과 경험을 새로운 업무에서 100% 활용할 수 없을까봐 걱정이 됐고, 앞으로의 경력에 도움이 될지 모를 생소한 기술을 배워야 하는데 부담을 느꼈습니다. 그런데 소프트웨어 개발을 시작한 지 언 16년이 지난 현재의 관점에서 생각해보면, 그 때 제 생각이 참 짧았다는 생각이 들어요. 기껏해야 몇 년 안 되는 경험을, 까짓 것 좀 못 살리면 어떻다고... 그 새로운 기술을 배울 수 있는 좋은 기회들을 그냥 보내 버렸을까요? 깐깐하게 기술 스택을 따지는 것도 중요하겠지만, 이 바닥에서 점점 경력이 쌓이다 보니 자신에게 잘 맞는 비즈니스 도메인을 선택하는 것도 그에 못지 않게 참 중요하다는 생각이 듭니다. 우리 한번 소프트웨어 개발자로서 냉정하게 생각을 해볼까요? 새로운 기술을 배우는 게 힘든가요? 새로운 비즈니스를 배우는 게 힘든가요? 개발 관련된 지식은 온라인에 학습 자료가 풍부하며 심지어 무료도 많은데요. 하지만 특정 비즈니스에 대한 지식은 배우는데 많은 비용이 들거나 체계적인 교육없이 노하우처럼 전수되는 경우도 있죠. 따라서 상대적으로 배우려는 의지와 적극성이 더 필요합니다. 해당 비즈니스 도메인에 흥미가 없다면 배우는 과정 자체가 고통이 될 수도 있고요. 아무래도 첫 직장은 선택하기 보다는 선택 당하는 입장이라서 자신이 원하는 비즈니스 도메인을 고르기가 쉽지 않은데요. 저도 첫 직장에서는 생각치도 못했던 기업용 소프트웨어를 개발하게 되었고, ERP(Enterprise Resource Planning)와 CRM(Customer Relationship Management)과 같은 생전 처음 들어보는 방대한 엔터프라이즈 솔루션에 대해서 공부해야 했습니다. 선배 어깨 넘어로 배우다 보니 답답하기도 했지만, 전문 교육은 업무를 1~2주 빠져야 해서 신청하기가 눈치가 보였죠. 그런데 솔직히... 어떻게 보면 이건 다 핑계입니다. 저는 단지 그 비즈니스 도메인에 큰 매력을 느끼지 못했던 것입니다. 그 이후에 다른 회사들을 다니면서 모바일 앱 스토어나 전자 상거래 플랫폼과 같은 대국민 소프트웨어를 개발했는데요. 아무래도 제가 실생활에서 사용하는 서비스다 보니 비즈니스에 대해서 관심이 많아지더라고요. "아, 내가 주문한 제품이 이런 이런 과정을 거쳐서 결제가 되고, 이런 이런 과정을 거쳐서 배송이 되고, 반품은 이런 이런 과정을 거쳐서 이뤄지는구나!" 자꾸 호기심이 생겨서 사업 담당자를 찾아가서 이것저것 자주 물어보곤 했습니다. 귀찮아 하시면 어떨까 걱정했지만 오히려 정반대였습니다. 비즈니스를 제대로 이해하려고 찾아오는 개발자는 어디서든 환영받으니까요. 현재 저는 캐나다에서 아이를 키우는 중이어서, 여느 학부모처럼 저의 관심사는 교육 쪽으로 옮겨가게 되었습니다. 그런데 저는 줄곧 한국에서 교육을 받아왔기 때문에 캐나다의 교육 시스템에 대해 매우 생소했습니다. 그래서 여러 기회가 있었지만 EdTech(교육 기술) 분야에서 한 번 일해보기로 결심했지요. 몇 년간 이 분야에서 몸 담으면서 캐나다의 공교육 행정이 어떻게 돌아가고, 선생님들이 학교에서 어떻게 학생들을 가르치며, 부모들은 어떤 교육을 기대하고 있는지 배울 수가 있었습니다. 이렇게 제가 일을 하면서 체득한 도메인 지식들은 캐나다에서 육아를 하는데 정말 큰 도움이 되고 있습니다. 최근에는 프로젝트 때문에 캐나다를 포함한 여러 교육 선진국들의 유학 프로세스에 대해서 공부하고 있는데요. 저는 한 번도 해외 유학을 가보지 않아서 이 쪽에 대해서는 완전 문외한이었는데, 이제는 제 주변에 있는 많은 이민자들이 어떤 과정을 거쳐 이 나라에서 공부하고 정착까지 하게 되는지에 대해 이해할 수 있게 되었어요. 이처럼 자신이 평소에 관심이 있는 비즈니스 도메인에서 일하게 되면 단순히 소프트웨어 개발을 넘어, 자연스럽게 해당 비즈니스 도메인에서 전문성을 키울 수 있답니다. 도메인 전문성을 갖춘 소프트웨어 개발자는 귀해서 시장에서 항상 좋은 대우를 받는 건 다들 아실 거에요. 요즘에는 진짜 소프트웨어 개발이 필요하지 않은 분야가 없다고 하죠? 그래서 저는 소프트웨어 개발자는 원하는 비즈니스 도메인을 선택할 수 있는 진짜 얼마 안 되는 축복받은 직업이라고 생각합니다. 앞으로 개발자로 커리어를 쌓아가시면서 어떤 기술을 쓰고 싶으신지 뿐만 아니라, 자신이 어떤 비즈니스에 흥미를 느끼시고 배우고 싶으신지에 대해서도 좀 더 생각해보시면 어떨까요? 여러분은 저보다 좀 더 빨리 기술 스택의 굴레에서 벗어나 좀 더 재미있는 비즈니스 도메인에서 일하실 수 있으셨으면 좋겠습니다! 🙏🚀

Linkedin

굉정히 좋은 내용이네요. 저도 비즈니스 도메인에 대한 이해와 관심이 중요하다고 생각합니다. 좋은 글 감사합니다

R2R is a RAG engine with a RESTful API and production features. Including multimodal file ingestion, hybrid search, knowledge graphs, and document management. - SciPhi-AI/R2R

GitHub - SciPhi-AI/R2R: R2R is a RAG engine with a RESTful API and production features. Including multimodal file ingestion, hybrid search, knowledge graphs, and document management.

R2R이라는 오픈소스 RAG 서버가 꽤 괜찮네요. 벡터 검색 뿐 아니라 키워드 검색과 하이브리드, 그래프 검색까지 거의 it just works 수준으로 사용 할 수 있도록 해 줍니다.

벡터/키워드 검색은 Postgres, 그래프 검색은 Neo4j를 사용해서 범용성도 좋은 것 같구요. 대시보드도 제공해주고, 도커로 배포도 쉽게 가능합니다.

LangChain, LlamaIndex 같은 것들이 프로토타이핑에는 나쁘지 않지만 실서비스에 쓰기에는 문제가 좀 있는데요. R2R이 이를 해결해 줄 수 있을지 기대해봐야겠습니다.

https://github.com/SciPhi-AI/R2R

R2R이라는 오픈소스 RAG 서버가 꽤 괜찮네요. 벡터 검색 뿐 아니라 키워드 검색과 하이브리드, 그래프 검색까지 거의 it just works 수준으로 사용 할 수 있도록 해 줍니다. 벡터/키워드 검색은 Postgres, 그래프 검색은 Neo4j를 사용해서 범용성도 좋은 것 같구요. 대시보드도 제공해주고, 도커로 배포도 쉽게 가능합니다. LangChain, LlamaIndex 같은 것들이 프로토타이핑에는 나쁘지 않지만 실서비스에 쓰기에는 문제가 좀 있는데요. R2R이 이를 해결해 줄 수 있을지 기대해봐야겠습니다. https://github.com/SciPhi-AI/R2R

GitHub

 1. Materialized Views:
 * 정의:
   * Materialized View(MV)는 쿼리 결과를 저장하고 있는 데이터베이스 객체입니다. 이렇게만 말하면 SQL 데이터베이스에만 국한된 개념처럼 보이지만 좀 더 넓은 개념의 의미로 보면 Materialized View는 데이터의 사본을 미리 계산하고 저장하여 성능을 향상시키는 기법입니다.
 * When to use:
   * 복잡한 쿼리: 여러 조인, 집계 및 계산을 포함하는 복잡한 쿼리라서 데이터를 직접 쿼리하기 어려울 때
   * 반복적인 읽기 작업: 자주 읽히는 데이터의 경우 Materialized View 기법을 통해서 읽기 성능을 향상 시킬 수 있습니다.
   * 데이터 집계: 집계 연산 (Aggregation, 합계, 평균, 개수 등) 에서 Materialized Views 를 통해 사전 집계된 결과를 제공해서 성능을 향상 시킬 수 있습니다.
   * 서로 다른 데이터 저장소의 기능을 활용하기 위해서. 예를 들면 쓰기에 효율적인 데이터 스토어는 데이터를 저장소 역할로 사용하고, 쿼리와 읽기 성능이 좋은 관계형 데이터 스토어에서 Materialized View 를 저장하는 식으로.
 * How to use:
   * SQL 에서의 Materialized View 는 Materialized View 객체를 생성하고, 갱신 전략과 그것에 맞는 갱신 주기를 설정하고 조회하면 됩니다.
   * 추가로 너무 자주 갱신할 경우 성능에 부담이 되고, 너무 늦게 갱신하면 오래된 데이터를 볼 수 있는 문제가 발생할 수 있습니다.
 * Considerations:
   * 갱신 오버헤드: 갱신 시 리소스가 소요되는 걸 고려해서 갱신 전략과 갱신 주기를 설정하세요.
   * Dsposability and Regeneratibility: Materialized View 가 없어지거나 만료되더라도 원본 데이터에서 다시 만들 수 있어야 합니다.
   * Consistency: Materialized View 는 원본 데이터로 만들어진 별도의 캐싱 데이터 이므로 데이터 일관성이 안 맞을 수 있습니다. 이것에 대한 고려도 필요합니다.
   * 원본 데이터가 단순하거나 쿼리하기 쉽다면 이 기법은 적절하지 않을 수 있습니다.

 2. Indexing:
 * 정의:
   * 데이터베이스의 특정 열에 대해 검색 속도를 향상시키기 위해 데이터 구조를 사용하는 전략입니다.
 * When to use:
   * 빈번한 검색: 자주 검색되는 열에 대해 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다.
   * JOIN 및 WHERE 절: JOIN이나 WHERE 절에서 자주 사용되는 열에 인덱스를 생성하면 쿼리 성능이 향상됩니다.
   * 정렬과 그룹화: ORDER BY나 GROUP BY 구문에서 자주 사용되는 열에 인덱스를 생성하면 성능이 개선될 수 있습니다.
 * How to use:
   * 데이터베이스에서 인덱스를 사용하는 방법은 간단합니다. 인덱스로 사용할 테이블 칼럼을 선택하고 생성만 하면 사용됩니다.
 * Considerations:
   * 인덱스 오버헤드: 인덱스 생성 및 유지 관리에는 추가 저장 공간과 CPU 자원이 필요합니다. 인덱스가 많아지면 데이터 삽입, 업데이트, 삭제 작업의 성능이 저하될 수 있습니다.
   * 인덱스 선택: 모든 열에 인덱스를 생성하는 것은 바람직하지 않습니다. 자주 사용되는 열과 쿼리 성능에 중요한 열에 인덱스를 생성하는 것이 좋습니다.

 3. Denormalziation
 * 정의:
   * 비정규화(Denormalization)는 데이터베이스의 성능을 향상시키기 위해 데이터를 중복 저장하는 전략입니다. 이는 데이터를 정규화하여 중복을 최소화하는 것과 반대되는 개념으로, 특정 쿼리 성능을 최적화하기 위해 데이터를 중복 저장하여 조인을 줄이고 조회 속도를 향상시킵니다.
 * When to use:
   * 읽기 성능 향상: 데이터 읽기 작업이 빈번하고, 읽기 성능이 중요할 때 비정규화를 통해 데이터를 중복 저장하여 조회 속도를 높일 수 있습니다.
   * 복잡한 조인 줄이기: 여러 테이블을 조인하는 복잡한 쿼리를 자주 실행해야 하는 경우, 비정규화를 통해 조인을 줄이고 쿼리 성능을 향상시킬 수 있습니다.
   * 데이터 통합: 서로 다른 데이터 소스에서 데이터를 통합하여 조회할 때, 비정규화를 통해 데이터를 하나의 테이블에 저장하고 조회 성능을 높일 수 있습니다.
 * How to use:
   * 비정규화를 적용하려면 먼저 어떤 데이터가 중복 저장될지 결정해야 합니다. 자주 사용되는 데이터를 식별하고, 해당 데이터를 중복 저장하여 조회 성능을 향상시킵니다.
 * Considerations:
   * 데이터 일관성: 데이터가 중복 저장되므로 일관성을 유지하기 어려울 수 있습니다. 데이터가 변경될 때마다 비정규화된 데이터를 업데이트해야 하므로, 이를 위한 추가적인 로직이 필요합니다
   * 저장 공간 증가: 비정규화는 데이터를 중복 저장하므로 저장 공간 요구량이 증가할 수 있습니다. 데이터베이스의 저장 공간을 충분히 확보해야 합니다.

 4. Vertical Scaling:
 * 정의:
   * Vertical Scaling(수직적 확장)은 기존 서버나 데이터베이스의 하드웨어 사양을 업그레이드하여 성능을 향상시키는 방법입니다. 주로 CPU, RAM, 스토리지와 같은 자원을 추가하거나 교체하는 방식으로 이루어집니다.
 * When to use:
   * 단일 서버의 성능이 충분하지 않을 때: 현재 사용 중인 서버가 증가하는 데이터 처리량을 감당하지 못할 때 수직적 확장을 통해 성능을 향상시킬 수 있습니다.
   * 애플리케이션 구조가 수평적 확장을 지원하지 않을 때: 애플리케이션이 여러 서버에 분산될 수 없는 경우, 단일 서버의 성능을 높이는 것이 효과적입니다.
   * 쉽게 성능 향상이 필요할 때: 하드웨어 업그레이드는 상대적으로 쉽게 성능을 향상시킬 수 있는 방법입니다.
 * How to use:
   * 하드웨어 업그레이드: 서버의 CPU, RAM, 스토리지 등의 하드웨어를 업그레이드합니다.
   * 가상 머신 또는 클라우드 인스턴스 업그레이드: 클라우드 환경에서는 더 높은 사양의 인스턴스로 업그레이드할 수 있습니다.
 * Considerations:
   * 비용: 수직적 확장은 초기 비용이 높을 수 있습니다. 고성능 하드웨어는 높은 비용을 수반하므로 예산을 고려해야 합니다.
   * 확장 한계: 수직적 확장은 물리적 한계가 있습니다. 하드웨어의 최대 성능에 도달하면 더 이상 확장할 수 없으므로, 장기적인 확장성 계획을 고려해야 합니다.
   * 단일 장애점(Single Point of Failure): 단일 서버에 의존하는 경우, 해당 서버가 장애를 일으키면 전체 시스템이 영향을 받을 수 있습니다. 이 경우 고가용성 및 백업 계획을 수립하는 것이 중요합니다.

 5. Caching:
 * 정의:
   * 캐싱 (Caching) 은 자주 조회되는 데이터를 임시 저장소에 저장하여 데이터베이스 접근을 줄이고 응답 시간을 단축시키는 전략입니다. 메모리나 고속 스토리지를 사용하여 데이터를 임시로 저장함으로써 데이터베이스 성능을 향상시킬 수 있습니다.
 * When to use:
   * 자주 조회되는 데이터: 특정 데이터가 자주 조회되는 경우, 캐싱을 통해 데이터베이스 부하를 줄이고 응답 시간을 개선할 수 있습니다.
   * 읽기 성능 최적화: 읽기 작업이 빈번하고, 빠른 응답 시간이 중요한 경우 캐싱을 통해 성능을 최적화할 수 있습니다.
   * 복잡한 쿼리 결과 캐싱: 복잡한 쿼리를 자주 실행해야 하는 경우, 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.
   * API 응답 속도 개선: 웹 애플리케이션이나 API의 응답 속도를 개선하기 위해 캐싱을 사용할 수 있습니다.
 * How to use:
   * 캐시 설정: 캐시를 설정하려면 먼저 캐시 저장소를 선택합니다. Redis, Memcached, 로컬 메모리 등을 사용할 수 있습니다.
   * 캐시 정책 결정: 캐시 만료 시간(TTL, Time to Live)과 갱신 정책을 설정합니다. 캐시 만료 시간은 데이터의 유효 기간을 결정하며, 갱신 정책은 캐시 데이터가 만료되거나 갱신될 시점을 결정합니다.
   * 데이터 일관성 유지: 캐시된 데이터와 원본 데이터의 일관성을 유지하기 위한 전략을 마련합니다. 원본 데이터가 변경될 때 캐시를 갱신하거나 무효화하는 로직을 구현합니다.
 * Considerations:
   * 캐시 적중률(Cache Hit Rate): 캐시의 효율성을 높이기 위해 캐시 적중률을 모니터링합니다. 캐시 적중률이 낮다면 캐시 정책을 재검토하여 개선합니다.
   * 데이터 일관성: 캐시된 데이터는 원본 데이터가 변경되었을 때 일관성을 유지하기 어려울 수 있습니다. 데이터가 갱신될 때 캐시를 무효화하거나 갱신하는 전략이 필요합니다.
   * 캐시 오버헤드: 캐싱은 추가 저장 공간과 메모리 사용을 필요로 합니다. 캐시 크기를 적절히 관리하여 메모리 사용량을 최적화해야 합니다.
   * TTL 설정: 캐시 만료 시간을 적절히 설정하여 데이터의 최신성과 성능 사이의 균형을 맞춥니다. 너무 짧으면 캐시의 이점을 살리기 어렵고, 너무 길면 오래된 데이터를 반환할 위험이 있습니다.

 6. Replication:
 * 정의:
   * 데이터베이스 복제(Replication)는 데이터베이스의 데이터를 다른 서버에 복제하여 고가용성 및 성능을 향상시키는 전략입니다. 복제된 데이터베이스는 읽기 작업을 분산시키고, 데이터베이스 장애 시에도 시스템을 지속적으로 운영할 수 있도록 합니다.
 * When to use:
   * 고가용성 요구: 시스템의 고가용성이 중요한 경우, 복제를 통해 장애 시에도 서비스가 중단되지 않도록 할 수 있습니다.
   * 읽기 성능 향상: 읽기 작업이 빈번한 경우, 여러 복제본으로 읽기 작업을 분산시켜 성능을 향상시킬 수 있습니다.
   * 백업 및 복구: 데이터를 다른 서버에 복제함으로써 백업 및 복구 작업을 용이하게 할 수 있습니다.
   * 지연시간 향상: 여러 지역에 걸쳐 데이터를 분산하여 사용자에게 더 가까운 서버에서 데이터를 제공할 수 있습니다.
 * How to use:
   * 마스터-슬레이브 복제: 한 서버(마스터)가 쓰기 작업을 처리하고, 다른 서버들(슬레이브)이 읽기 작업을 처리하도록 설정하도록 할 수 있습니다.
   * 다중 리더 복제: 두 개 이상의 서버가 모두 쓰기 및 읽기 작업을 처리할 수 있도록 설정하도록 할 수 있습니다.
   * 비동기 및 동기 복제: 비동기 복제는 성능이 좋지만 데이터 일관성이 떨어질 수 있고, 동기 복제는 데이터 일관성이 높지만 성능이 저하될 수 있습니다. 필요에 따라 선택합니다.
   * 멀티 스레딩 복제: 복제 작업을 병렬로 처리하여 성능을 향상시키는 방법입니다. 슬레이브 서버에서 여러 스레드를 사용하여 마스터의 데이터를 병렬로 복제합니다.
   * 리더 없는 복제(Leaderless Replication): 모든 노드가 동등한 역할을 하여 데이터 읽기 및 쓰기 작업을 분산 처리하는 방식입니다. 주로 NoSQL 데이터베이스에서 사용되며, 각 노드가 독립적으로 작동하여 고가용성과 확장성을 제공합니다.
 * Considerations:
   * 복제 지연: 네트워크 지연이나 복제 설정에 따라 데이터 복제에 시간이 걸릴 수 있습니다. 복제 지연이 발생한다면 최신 데이터 조회의 어려움, 복제 서버의 성능 저하 등이 일어날 수 있기 때문에 복제 지연을 최소화하기 위한 네트워크 설정 및 모니터링이 필요합니다.
   * 데이터 일관성: 비동기 복제는 실시간으로 데이터가 동기화되지 않으므로 일관성 문제가 발생할 수 있습니다. 동기 복제를 통해 데이터 일관성을 유지할 수 있지만 성능에 영향을 줄 수 있습니다.
   * 충돌 해결: 마스터-마스터 복제에서는 동일한 데이터에 대한 충돌이 발생할 수 있습니다. 충돌 해결 정책을 마련해야 합니다.

 7. Shrading:
 * 샤딩(Sharding)은 데이터베이스를 여러 개의 작은 단위(샤드)로 분할하여 각각 독립적인 데이터베이스 서버에 저장하는 전략입니다. 각 샤드는 전체 데이터의 일부를 포함하며, 이를 통해 대규모 데이터베이스의 성능과 확장성을 향상시킬 수 있습니다.
 * When to use:
   * 데이터베이스 크기가 매우 큰 경우: 단일 서버가 전체 데이터를 처리하기 어려운 경우 샤딩을 통해 데이터베이스를 분할하여 처리 성능을 높일 수 있습니다.
   * 높은 트래픽: 많은 사용자가 동시에 데이터베이스에 접근할 때 샤딩을 통해 트래픽을 여러 서버에 분산시킬 수 있습니다.
   * 높은 쓰기/읽기 작업: 데이터 쓰기와 읽기 작업이 많은 경우, 샤딩을 통해 특정 샤드에서만 작업을 처리하여 성능을 최적화할 수 있습니다.
   * 데이터 분리 요구: 지리적 위치나 비즈니스 요구에 따라 데이터를 분리하여 저장해야 할 때 샤딩을 활용할 수 있습니다.
 * How to use:
   * 샤드 키 선택: 데이터를 분할할 기준이 되는 샤드 키를 선택합니다. 일반적으로 사용자 ID, 지역 코드, 타임스탬프 등이 샤드 키로 사용됩니다.
   * 샤딩 알고리즘 선택: 샤딩 알고리즘을 선택하여 데이터를 분할합니다. 주요 알고리즘으로는 다음과 같은 두 가지가 있습니다:
     * Range 기반 샤딩: 샤드 키의 범위에 따라 데이터를 분할합니다. 예를 들어, 특정 사용자 ID 범위마다 다른 샤드에 저장합니다.
     * Hashing 기반 샤딩: 샤드 키를 해싱하여 데이터를 분산합니다. 이 방식은 데이터를 고르게 분산시키는 데 유리합니다.
   * 데이터베이스 분할: 샤드 키를 기반으로 데이터를 여러 데이터베이스 서버에 분할 저장합니다.
   * Routing 로직 구현: 데이터베이스 시스템이 자동으로 샤딩을 지원하지 않는 경우, 애플리케이션 레벨에서 샤드 키를 이용해 데이터를 적절한 샤드에 라우팅하는 로직을 구현합니다. MongoDB와 같은 일부 데이터베이스는 이 로직을 자체적으로 지원합니다
 * Considerations:
   * 데이터 일관성: 여러 샤드에 데이터가 분산되므로, 트랜잭션을 처리할 때 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 분산 트랜잭션 관리나 eventual consistency 모델을 고려해야 합니다.
   * 샤드 간 조인: 샤드 간 조인이 필요한 경우 성능 저하가 발생할 수 있습니다. 가능한 샤드 내에서 데이터를 처리하고, 샤드 간 조인을 최소화하는 설계를 고려해야 합니다.
   * 샤드 키 선택: 샤드 키를 적절히 선택하지 않으면 특정 샤드에 데이터가 집중되어 부하가 증가할 수 있습니다. 고르게 분산되는 샤드 키를 선택하는 것이 중요합니다.
   * 리밸런싱 문제: 데이터 분포가 불균형해질 때, 샤드 추가/제거가 발생할 때 리밸런싱 작업이 필요합니다. 이를 위해 데이터 이동 및 재분할 작업을 효율적으로 자동화하는 방법을 마련해야합니다.
   * Hot Spot 문제: 특정 샤드에 데이터가 집중되어 해당 샤드에 과부하가 발생하는 문제가 발생할 수 있습니다.

<ol ><li>Materialized Views:</li></ol><ul ><li>정의:<ul ><li>Materialized View(MV)는 쿼리 결과를 저장하고 있는 데이터베이스 객체입니다. 이렇게만 말하면 SQL 데이터베이스에만 국한된 개념처럼 보이지만 좀 더 넓은 개념의 의미로 보면 Materialized View는 데이터의 사본을 미리 계산하고 저장하여 성능을 향상시키는 기법입니다.</li></ul></li><li>When to use:<ul ><li>복잡한 쿼리: 여러 조인, 집계 및 계산을 포함하는 복잡한 쿼리라서 데이터를 직접 쿼리하기 어려울 때</li><li>반복적인 읽기 작업: 자주 읽히는 데이터의 경우 Materialized View 기법을 통해서 읽기 성능을 향상 시킬 수 있습니다.</li><li>데이터 집계: 집계 연산 (Aggregation, 합계, 평균, 개수 등) 에서 Materialized Views 를 통해 사전 집계된 결과를 제공해서 성능을 향상 시킬 수 있습니다.</li><li>서로 다른 데이터 저장소의 기능을 활용하기 위해서. 예를 들면 쓰기에 효율적인 데이터 스토어는 데이터를 저장소 역할로 사용하고, 쿼리와 읽기 성능이 좋은 관계형 데이터 스토어에서 Materialized View 를 저장하는 식으로.</li></ul></li><li>How to use:<ul ><li>SQL 에서의 Materialized View 는 Materialized View 객체를 생성하고, 갱신 전략과 그것에 맞는 갱신 주기를 설정하고 조회하면 됩니다.</li><li>추가로 너무 자주 갱신할 경우 성능에 부담이 되고, 너무 늦게 갱신하면 오래된 데이터를 볼 수 있는 문제가 발생할 수 있습니다.</li></ul></li><li>Considerations:<ul ><li>갱신 오버헤드: 갱신 시 리소스가 소요되는 걸 고려해서 갱신 전략과 갱신 주기를 설정하세요.</li><li>Dsposability and Regeneratibility: Materialized View 가 없어지거나 만료되더라도 원본 데이터에서 다시 만들 수 있어야 합니다.</li><li>Consistency: Materialized View 는 원본 데이터로 만들어진 별도의 캐싱 데이터 이므로 데이터 일관성이 안 맞을 수 있습니다. 이것에 대한 고려도 필요합니다.</li><li>원본 데이터가 단순하거나 쿼리하기 쉽다면 이 기법은 적절하지 않을 수 있습니다.</li></ul></li></ul> <ol start="2"><li>Indexing:</li></ol><ul ><li>정의:<ul ><li>데이터베이스의 특정 열에 대해 검색 속도를 향상시키기 위해 데이터 구조를 사용하는 전략입니다.</li></ul></li><li>When to use:<ul ><li>빈번한 검색: 자주 검색되는 열에 대해 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다.</li><li>JOIN 및 WHERE 절: JOIN이나 WHERE 절에서 자주 사용되는 열에 인덱스를 생성하면 쿼리 성능이 향상됩니다.</li><li>정렬과 그룹화: ORDER BY나 GROUP BY 구문에서 자주 사용되는 열에 인덱스를 생성하면 성능이 개선될 수 있습니다.</li></ul></li><li>How to use:<ul ><li>데이터베이스에서 인덱스를 사용하는 방법은 간단합니다. 인덱스로 사용할 테이블 칼럼을 선택하고 생성만 하면 사용됩니다.</li></ul></li><li>Considerations:<ul ><li>인덱스 오버헤드: 인덱스 생성 및 유지 관리에는 추가 저장 공간과 CPU 자원이 필요합니다. 인덱스가 많아지면 데이터 삽입, 업데이트, 삭제 작업의 성능이 저하될 수 있습니다.</li><li>인덱스 선택: 모든 열에 인덱스를 생성하는 것은 바람직하지 않습니다. 자주 사용되는 열과 쿼리 성능에 중요한 열에 인덱스를 생성하는 것이 좋습니다.</li></ul></li></ul> <ol start="3"><li>Denormalziation</li></ol><ul ><li>정의:<ul ><li>비정규화(Denormalization)는 데이터베이스의 성능을 향상시키기 위해 데이터를 중복 저장하는 전략입니다. 이는 데이터를 정규화하여 중복을 최소화하는 것과 반대되는 개념으로, 특정 쿼리 성능을 최적화하기 위해 데이터를 중복 저장하여 조인을 줄이고 조회 속도를 향상시킵니다.</li></ul></li><li>When to use:<ul ><li>읽기 성능 향상: 데이터 읽기 작업이 빈번하고, 읽기 성능이 중요할 때 비정규화를 통해 데이터를 중복 저장하여 조회 속도를 높일 수 있습니다.</li><li>복잡한 조인 줄이기: 여러 테이블을 조인하는 복잡한 쿼리를 자주 실행해야 하는 경우, 비정규화를 통해 조인을 줄이고 쿼리 성능을 향상시킬 수 있습니다.</li><li>데이터 통합: 서로 다른 데이터 소스에서 데이터를 통합하여 조회할 때, 비정규화를 통해 데이터를 하나의 테이블에 저장하고 조회 성능을 높일 수 있습니다.</li></ul></li><li>How to use:<ul ><li>비정규화를 적용하려면 먼저 어떤 데이터가 중복 저장될지 결정해야 합니다. 자주 사용되는 데이터를 식별하고, 해당 데이터를 중복 저장하여 조회 성능을 향상시킵니다.</li></ul></li><li>Considerations:<ul ><li>데이터 일관성: 데이터가 중복 저장되므로 일관성을 유지하기 어려울 수 있습니다. 데이터가 변경될 때마다 비정규화된 데이터를 업데이트해야 하므로, 이를 위한 추가적인 로직이 필요합니다</li><li>저장 공간 증가: 비정규화는 데이터를 중복 저장하므로 저장 공간 요구량이 증가할 수 있습니다. 데이터베이스의 저장 공간을 충분히 확보해야 합니다.</li></ul></li></ul> <ol start="4"><li>Vertical Scaling:</li></ol><ul ><li>정의:<ul ><li>Vertical Scaling(수직적 확장)은 기존 서버나 데이터베이스의 하드웨어 사양을 업그레이드하여 성능을 향상시키는 방법입니다. 주로 CPU, RAM, 스토리지와 같은 자원을 추가하거나 교체하는 방식으로 이루어집니다.</li></ul></li><li>When to use:<ul ><li>단일 서버의 성능이 충분하지 않을 때: 현재 사용 중인 서버가 증가하는 데이터 처리량을 감당하지 못할 때 수직적 확장을 통해 성능을 향상시킬 수 있습니다.</li><li>애플리케이션 구조가 수평적 확장을 지원하지 않을 때: 애플리케이션이 여러 서버에 분산될 수 없는 경우, 단일 서버의 성능을 높이는 것이 효과적입니다.</li><li>쉽게 성능 향상이 필요할 때: 하드웨어 업그레이드는 상대적으로 쉽게 성능을 향상시킬 수 있는 방법입니다.</li></ul></li><li>How to use:<ul ><li>하드웨어 업그레이드: 서버의 CPU, RAM, 스토리지 등의 하드웨어를 업그레이드합니다.</li><li>가상 머신 또는 클라우드 인스턴스 업그레이드: 클라우드 환경에서는 더 높은 사양의 인스턴스로 업그레이드할 수 있습니다.</li></ul></li><li>Considerations:<ul ><li>비용: 수직적 확장은 초기 비용이 높을 수 있습니다. 고성능 하드웨어는 높은 비용을 수반하므로 예산을 고려해야 합니다.</li><li>확장 한계: 수직적 확장은 물리적 한계가 있습니다. 하드웨어의 최대 성능에 도달하면 더 이상 확장할 수 없으므로, 장기적인 확장성 계획을 고려해야 합니다.</li><li>단일 장애점(Single Point of Failure): 단일 서버에 의존하는 경우, 해당 서버가 장애를 일으키면 전체 시스템이 영향을 받을 수 있습니다. 이 경우 고가용성 및 백업 계획을 수립하는 것이 중요합니다.</li></ul></li></ul> <ol start="5"><li>Caching:</li></ol><ul ><li>정의:<ul ><li>캐싱 (Caching) 은 자주 조회되는 데이터를 임시 저장소에 저장하여 데이터베이스 접근을 줄이고 응답 시간을 단축시키는 전략입니다. 메모리나 고속 스토리지를 사용하여 데이터를 임시로 저장함으로써 데이터베이스 성능을 향상시킬 수 있습니다.</li></ul></li><li>When to use:<ul ><li>자주 조회되는 데이터: 특정 데이터가 자주 조회되는 경우, 캐싱을 통해 데이터베이스 부하를 줄이고 응답 시간을 개선할 수 있습니다.</li><li>읽기 성능 최적화: 읽기 작업이 빈번하고, 빠른 응답 시간이 중요한 경우 캐싱을 통해 성능을 최적화할 수 있습니다.</li><li>복잡한 쿼리 결과 캐싱: 복잡한 쿼리를 자주 실행해야 하는 경우, 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.</li><li>API 응답 속도 개선: 웹 애플리케이션이나 API의 응답 속도를 개선하기 위해 캐싱을 사용할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>캐시 설정: 캐시를 설정하려면 먼저 캐시 저장소를 선택합니다. Redis, Memcached, 로컬 메모리 등을 사용할 수 있습니다.</li><li>캐시 정책 결정: 캐시 만료 시간(TTL, Time to Live)과 갱신 정책을 설정합니다. 캐시 만료 시간은 데이터의 유효 기간을 결정하며, 갱신 정책은 캐시 데이터가 만료되거나 갱신될 시점을 결정합니다.</li><li>데이터 일관성 유지: 캐시된 데이터와 원본 데이터의 일관성을 유지하기 위한 전략을 마련합니다. 원본 데이터가 변경될 때 캐시를 갱신하거나 무효화하는 로직을 구현합니다.</li></ul></li><li>Considerations:<ul ><li>캐시 적중률(Cache Hit Rate): 캐시의 효율성을 높이기 위해 캐시 적중률을 모니터링합니다. 캐시 적중률이 낮다면 캐시 정책을 재검토하여 개선합니다.</li><li>데이터 일관성: 캐시된 데이터는 원본 데이터가 변경되었을 때 일관성을 유지하기 어려울 수 있습니다. 데이터가 갱신될 때 캐시를 무효화하거나 갱신하는 전략이 필요합니다.</li><li>캐시 오버헤드: 캐싱은 추가 저장 공간과 메모리 사용을 필요로 합니다. 캐시 크기를 적절히 관리하여 메모리 사용량을 최적화해야 합니다.</li><li>TTL 설정: 캐시 만료 시간을 적절히 설정하여 데이터의 최신성과 성능 사이의 균형을 맞춥니다. 너무 짧으면 캐시의 이점을 살리기 어렵고, 너무 길면 오래된 데이터를 반환할 위험이 있습니다.</li></ul></li></ul> <ol start="6"><li>Replication:</li></ol><ul ><li>정의:<ul ><li>데이터베이스 복제(Replication)는 데이터베이스의 데이터를 다른 서버에 복제하여 고가용성 및 성능을 향상시키는 전략입니다. 복제된 데이터베이스는 읽기 작업을 분산시키고, 데이터베이스 장애 시에도 시스템을 지속적으로 운영할 수 있도록 합니다.</li></ul></li><li>When to use:<ul ><li>고가용성 요구: 시스템의 고가용성이 중요한 경우, 복제를 통해 장애 시에도 서비스가 중단되지 않도록 할 수 있습니다.</li><li>읽기 성능 향상: 읽기 작업이 빈번한 경우, 여러 복제본으로 읽기 작업을 분산시켜 성능을 향상시킬 수 있습니다.</li><li>백업 및 복구: 데이터를 다른 서버에 복제함으로써 백업 및 복구 작업을 용이하게 할 수 있습니다.</li><li>지연시간 향상: 여러 지역에 걸쳐 데이터를 분산하여 사용자에게 더 가까운 서버에서 데이터를 제공할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>마스터-슬레이브 복제: 한 서버(마스터)가 쓰기 작업을 처리하고, 다른 서버들(슬레이브)이 읽기 작업을 처리하도록 설정하도록 할 수 있습니다.</li><li>다중 리더 복제: 두 개 이상의 서버가 모두 쓰기 및 읽기 작업을 처리할 수 있도록 설정하도록 할 수 있습니다.</li><li>비동기 및 동기 복제: 비동기 복제는 성능이 좋지만 데이터 일관성이 떨어질 수 있고, 동기 복제는 데이터 일관성이 높지만 성능이 저하될 수 있습니다. 필요에 따라 선택합니다.</li><li>멀티 스레딩 복제: 복제 작업을 병렬로 처리하여 성능을 향상시키는 방법입니다. 슬레이브 서버에서 여러 스레드를 사용하여 마스터의 데이터를 병렬로 복제합니다.</li><li>리더 없는 복제(Leaderless Replication): 모든 노드가 동등한 역할을 하여 데이터 읽기 및 쓰기 작업을 분산 처리하는 방식입니다. 주로 NoSQL 데이터베이스에서 사용되며, 각 노드가 독립적으로 작동하여 고가용성과 확장성을 제공합니다.</li></ul></li><li>Considerations:<ul ><li>복제 지연: 네트워크 지연이나 복제 설정에 따라 데이터 복제에 시간이 걸릴 수 있습니다. 복제 지연이 발생한다면 최신 데이터 조회의 어려움, 복제 서버의 성능 저하 등이 일어날 수 있기 때문에 복제 지연을 최소화하기 위한 네트워크 설정 및 모니터링이 필요합니다.</li><li>데이터 일관성: 비동기 복제는 실시간으로 데이터가 동기화되지 않으므로 일관성 문제가 발생할 수 있습니다. 동기 복제를 통해 데이터 일관성을 유지할 수 있지만 성능에 영향을 줄 수 있습니다.</li><li>충돌 해결: 마스터-마스터 복제에서는 동일한 데이터에 대한 충돌이 발생할 수 있습니다. 충돌 해결 정책을 마련해야 합니다.</li></ul></li></ul> <ol start="7"><li>Shrading:</li></ol><ul ><li>샤딩(Sharding)은 데이터베이스를 여러 개의 작은 단위(샤드)로 분할하여 각각 독립적인 데이터베이스 서버에 저장하는 전략입니다. 각 샤드는 전체 데이터의 일부를 포함하며, 이를 통해 대규모 데이터베이스의 성능과 확장성을 향상시킬 수 있습니다.</li><li>When to use:<ul ><li>데이터베이스 크기가 매우 큰 경우: 단일 서버가 전체 데이터를 처리하기 어려운 경우 샤딩을 통해 데이터베이스를 분할하여 처리 성능을 높일 수 있습니다.</li><li>높은 트래픽: 많은 사용자가 동시에 데이터베이스에 접근할 때 샤딩을 통해 트래픽을 여러 서버에 분산시킬 수 있습니다.</li><li>높은 쓰기/읽기 작업: 데이터 쓰기와 읽기 작업이 많은 경우, 샤딩을 통해 특정 샤드에서만 작업을 처리하여 성능을 최적화할 수 있습니다.</li><li>데이터 분리 요구: 지리적 위치나 비즈니스 요구에 따라 데이터를 분리하여 저장해야 할 때 샤딩을 활용할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>샤드 키 선택: 데이터를 분할할 기준이 되는 샤드 키를 선택합니다. 일반적으로 사용자 ID, 지역 코드, 타임스탬프 등이 샤드 키로 사용됩니다.</li><li>샤딩 알고리즘 선택: 샤딩 알고리즘을 선택하여 데이터를 분할합니다. 주요 알고리즘으로는 다음과 같은 두 가지가 있습니다:<ul ><li>Range 기반 샤딩: 샤드 키의 범위에 따라 데이터를 분할합니다. 예를 들어, 특정 사용자 ID 범위마다 다른 샤드에 저장합니다.</li><li>Hashing 기반 샤딩: 샤드 키를 해싱하여 데이터를 분산합니다. 이 방식은 데이터를 고르게 분산시키는 데 유리합니다.</li></ul></li><li>데이터베이스 분할: 샤드 키를 기반으로 데이터를 여러 데이터베이스 서버에 분할 저장합니다.</li><li>Routing 로직 구현: 데이터베이스 시스템이 자동으로 샤딩을 지원하지 않는 경우, 애플리케이션 레벨에서 샤드 키를 이용해 데이터를 적절한 샤드에 라우팅하는 로직을 구현합니다. MongoDB와 같은 일부 데이터베이스는 이 로직을 자체적으로 지원합니다</li></ul></li><li>Considerations:<ul ><li>데이터 일관성: 여러 샤드에 데이터가 분산되므로, 트랜잭션을 처리할 때 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 분산 트랜잭션 관리나 eventual consistency 모델을 고려해야 합니다.</li><li>샤드 간 조인: 샤드 간 조인이 필요한 경우 성능 저하가 발생할 수 있습니다. 가능한 샤드 내에서 데이터를 처리하고, 샤드 간 조인을 최소화하는 설계를 고려해야 합니다.</li><li>샤드 키 선택: 샤드 키를 적절히 선택하지 않으면 특정 샤드에 데이터가 집중되어 부하가 증가할 수 있습니다. 고르게 분산되는 샤드 키를 선택하는 것이 중요합니다.</li><li>리밸런싱 문제: 데이터 분포가 불균형해질 때, 샤드 추가/제거가 발생할 때 리밸런싱 작업이 필요합니다. 이를 위해 데이터 이동 및 재분할 작업을 효율적으로 자동화하는 방법을 마련해야합니다.</li><li>Hot Spot 문제: 특정 샤드에 데이터가 집중되어 해당 샤드에 과부하가 발생하는 문제가 발생할 수 있습니다.</li></ul></li></ul>

반드시 알아야 하는 7가지 데이터베이스 확장성 전략

1️⃣ The C Programming Language

컴퓨터 프로그래밍의 근본 (주니어)

2️⃣ Code Complete

소프트웨어 개발의 모든 것 (주니어, 미드)

3️⃣ Refactoring

소프트웨어 유지보수의 모든 것 (주니어, 미드)

4️⃣ 구글 엔지니어는 이렇게 일한다

소프트웨어 개발 협업에 대한 모든 것 (미드, 시니어)

5️⃣ 최고의 프롬프트 엔지니어링 강의

AI/LLM과 프롬프트 엔지니어링의 근본(주니어, 미드, 시니어)

이상한 것이 끼어있는 것 같지만 착각입니다.

1️⃣ The C Programming Language 컴퓨터 프로그래밍의 근본 (주니어) 2️⃣ Code Complete 소프트웨어 개발의 모든 것 (주니어, 미드) 3️⃣ Refactoring 소프트웨어 유지보수의 모든 것 (주니어, 미드) 4️⃣ 구글 엔지니어는 이렇게 일한다 소프트웨어 개발 협업에 대한 모든 것 (미드, 시니어) 5️⃣ 최고의 프롬프트 엔지니어링 강의 AI/LLM과 프롬프트 엔지니어링의 근본(주니어, 미드, 시니어) 이상한 것이 끼어있는 것 같지만 착각입니다.

모든 개발자를 위한 프로그래밍 책 Top 5

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께

그 누구도 나의 서사를 대신 써주지 않는다

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께

코노님이 작성한 글입니다. 지금처럼 경력자를 후려치는 마케팅이 성행하는 시기에 살펴볼만한 대목이 많네요!

 * 물경력과 성장: 글에서는 '물경력 탈출’과 같은 마케팅이 저연차 개발자들의 불안을 자극하는 것에 대해 비판하며, 진정한 성장의 의미를 탐구합니다.
 * 개인적 경험의 가치: 다양한 경험들이 개발자로서의 성장에 어떻게 기여하는지를 공유하며, 링크드인에 적을 수 없는 경험들도 중요하다고 강조합니다.
 * 자기 인정의 중요성: 필자는 타인의 인정을 넘어 자기 스스로를 인정하는 것이 진정한 성장으로 이어진다고 주장합니다.
 * 본인의 서사 쓰기: 자신의 경험을 소중히 여기고, 타인의 시선에 휘둘리지 않으며, 자신만의 서사를 써나가야 한다고 강조합니다.

https://codingpause.hashnode.dev/about-growing-up

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께 코노님이 작성한 글입니다. 지금처럼 경력자를 후려치는 마케팅이 성행하는 시기에 살펴볼만한 대목이 많네요! <ul ><li>물경력과 성장: 글에서는 '물경력 탈출’과 같은 마케팅이 저연차 개발자들의 불안을 자극하는 것에 대해 비판하며, 진정한 성장의 의미를 탐구합니다.</li><li>개인적 경험의 가치: 다양한 경험들이 개발자로서의 성장에 어떻게 기여하는지를 공유하며, 링크드인에 적을 수 없는 경험들도 중요하다고 강조합니다.</li><li>자기 인정의 중요성: 필자는 타인의 인정을 넘어 자기 스스로를 인정하는 것이 진정한 성장으로 이어진다고 주장합니다.</li><li>본인의 서사 쓰기: 자신의 경험을 소중히 여기고, 타인의 시선에 휘둘리지 않으며, 자신만의 서사를 써나가야 한다고 강조합니다.</li></ul> https://codingpause.hashnode.dev/about-growing-up

코딩 놓으려 했는데

네이버 폼 설문에 바로 참여해 보세요.

[토스 프론트엔드 멘토링] Frontend Accelerator 1기에 지원하기

토스에서는 프론트엔드 멘토링 시스템 Frontend Accelerator 1기를 모집한다고 하네요.
Frontend Accelerator란 4주 동안 토스 프론트엔드 리드와 멘토-멘티의 관계를 맺어 토스 엔지니어링의 일하는 방식을 경험하고, 기술 관련 피드백을 얻는 프로그램인데요.
프로그램 종료 이후, 훌륭한 성장을 이뤄내신 분은 토스 Frontend Developer 채용 서류 패스 기회를 준다고 하니 좋은 기회가 될것 같습니다. 아래는 상세 내용 입니다

멘토링 진행 과정
 * 멘티에게 과제를 부여하고, 멘토는 가이드와 피드백을 주며 멘티가 리팩토링해나가는 과정을 함께합니다.
 * 멘토링은 모두 온라인으로 진행되며, 토스 슬랙 채널과 구글밋 미팅을 기반으로 진행됩니다.

일정
 * 7월 25일 ~ 8월 16일까지 1주일에 1회, 총 4회 정기 미팅을 진행합니다.
 * 이 외 시간에는 멘토와 멘티가 필요에 따라 자유롭게 소통합니다.

지원 대상
 * 프론트엔드 엔지니어로서 빠르게 성장을 경험하고 싶으신 분
 * 토스 프론트엔드 리드와의 네트워킹에 니즈가 있으신 분
 * 토스 프론트엔드 엔지니어가 실제로 마주하게 되는 문제를 함께 고민하고 싶으신 분

지원 자격
 * 3년 이하의 경험을 가진 분이라면 누구나 지원 가능합니다. 실무 경험이 없어도 괜찮습니다.

멘티 선발 과정
 1. 지원: 6월 17일 ~ 6월 26일까지
 2. 테스트: 6월 29일 (지원해주신 모든 분들께 테스트 참여의 기회가 부여됩니다.)
 3. 캐주얼챗: 7월 4일 ~ 7월 5일 중 조율 (테스트 합격자를 대상으로 캐주얼챗을 제안드립니다.)
 4. 선발 결과 발표: 7월 8일
 5. 멘토링 기간: 7월 25일 ~ 8월 16일 (주 1회, 1시간씩 온라인 미팅을 진행합니다.)

지원 방법
 * 6월 17일 ~ 6월 26일까지 이력서 없이 간단한 답변만으로 누구나 지원이 가능합니다.
 * 지원해주신 모든 분들께 6월 29일 온라인 테스트 (20분 소요)의 기회가 부여됩니다.

토스에 채용이 되지 않는다고 해도 멘토링을 하면서 많이 성장할 수 있는 기회가 될것 같습니다. 3년 이하의 주니어 분들은 지원을 해보시는것을 추천드립니다.

토스에서는 프론트엔드 멘토링 시스템 Frontend Accelerator 1기를 모집한다고 하네요.Frontend Accelerator란 4주 동안 토스 프론트엔드 리드와 멘토-멘티의 관계를 맺어 토스 엔지니어링의 일하는 방식을 경험하고, 기술 관련 피드백을 얻는 프로그램인데요.프로그램 종료 이후, 훌륭한 성장을 이뤄내신 분은 토스 Frontend Developer 채용 서류 패스 기회를 준다고 하니 좋은 기회가 될것 같습니다. 아래는 상세 내용 입니다 멘토링 진행 과정<ul ><li>멘티에게 과제를 부여하고, 멘토는 가이드와 피드백을 주며 멘티가 리팩토링해나가는 과정을 함께합니다.</li><li>멘토링은 모두 온라인으로 진행되며, 토스 슬랙 채널과 구글밋 미팅을 기반으로 진행됩니다.</li></ul> 일정<ul ><li>7월 25일 ~ 8월 16일까지 1주일에 1회, 총 4회 정기 미팅을 진행합니다.</li><li>이 외 시간에는 멘토와 멘티가 필요에 따라 자유롭게 소통합니다.</li></ul> 지원 대상<ul ><li>프론트엔드 엔지니어로서 빠르게 성장을 경험하고 싶으신 분</li><li>토스 프론트엔드 리드와의 네트워킹에 니즈가 있으신 분</li><li>토스 프론트엔드 엔지니어가 실제로 마주하게 되는 문제를 함께 고민하고 싶으신 분</li></ul> 지원 자격<ul ><li>3년 이하의 경험을 가진 분이라면 누구나 지원 가능합니다. 실무 경험이 없어도 괜찮습니다.</li></ul> 멘티 선발 과정<ol ><li>지원: 6월 17일 ~ 6월 26일까지</li><li>테스트: 6월 29일 (지원해주신 모든 분들께 테스트 참여의 기회가 부여됩니다.)</li><li>캐주얼챗: 7월 4일 ~ 7월 5일 중 조율 (테스트 합격자를 대상으로 캐주얼챗을 제안드립니다.)</li><li>선발 결과 발표: 7월 8일</li><li>멘토링 기간: 7월 25일 ~ 8월 16일 (주 1회, 1시간씩 온라인 미팅을 진행합니다.)</li></ol> 지원 방법<ul ><li>6월 17일 ~ 6월 26일까지 이력서 없이 간단한 답변만으로 누구나 지원이 가능합니다.</li><li>지원해주신 모든 분들께 6월 29일 온라인 테스트 (20분 소요)의 기회가 부여됩니다.</li></ul> 토스에 채용이 되지 않는다고 해도 멘토링을 하면서 많이 성장할 수 있는 기회가 될것 같습니다. 3년 이하의 주니어 분들은 지원을 해보시는것을 추천드립니다.

네이버 폼

토스 프론트엔드 멘토링 시스템 "Accelerator 1기 모집"

『소프트웨어 장인』에 이은 또 한 권의 '로버트 C. 마틴 시리즈' 베스트셀러!70년 동안 개발자들에게 검증 받은 개발 방법론과 주옥 같은 팁들을 한 권으로 총 정리! `좋은 소프트웨어 설계를 하라`는 말에 명확한 답과 방법을 떠올릴 수 있는가? 개발은 명확한...

읽기 쉬운 코드 - 예스24

안녕하세요. 오늘은 최근에 읽은 책 소개를 하나 할까 합니다.

종종 주니어 개발자 분들과 이야기를 나누다보면 '읽기 좋은 코드란 무엇일까요?' '코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?' 라는 질문을 많이 받곤 합니다. 그 기준은 무엇이고, 어떻게 발전 시킬수 있을지에 대한 고민도 많이 듣게되구요.

종종 주니어 개발자들과의 대화에서 "읽기 좋은 코드란 무엇일까요?", "코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?"에 대한 질문을 많이 받습니다. 그런 코드를 위해 구체적으로 어떤 방식으로 코드를 작성해야 하는지, 발전시킬수 있는지에 대해서도 질문을 많이 듣습니다.

생각나는 여러 기준을 제시하며 대화를 나누곤 했지만, 그러한 기준을 정확히 어디서 배웠고 어떻게 내재화하게 되었는지 생각해보면 그 출처가 명확하지 않았습니다. 나름 선호하는 코드 스타일과 개선이 필요한 코드를 식별하고 규칙을 만들어 적용해왔지만, 도움이 될 수 있는 구체적인 액션 아이템을 제시할때는 어려움을 느끼곤 했습니다.

그러다 최근 이 두 책을 제공받아 읽게 되었습니다. 그러다 최근 두 권의 책을 읽게 되었습니다. 이 책들은 좋은 코드를 작성하기 위한 기준과 코드에 안정성을 부여하는 방법에 대해 명확한 저자의 관점으로 구체적인 예시와 함께 설명하고 있습니다. 여러 곳에서 배운 지식들을 체계적으로 정리하고 재조명할 수 있는 좋은 기회가 되었습니다.

최근 비슷한 고민을 하는 개발자들뿐만 아니라 주니어 개발자들에게도 명확한 지침서가 될 수 있을 것이라 생각되어 다음 책들을 추천합니다. 목차를 확인해보시고 관심이 간다면 주문하여 읽어보시길 바랍니다.

 * 읽기 쉬운 코드: http://gilbut.co/c/24034992MF
 * 코드 작성 가이드: http://gilbut.co/c/24046947nM

안녕하세요. 오늘은 최근에 읽은 책 소개를 하나 할까 합니다. 종종 주니어 개발자 분들과 이야기를 나누다보면 '읽기 좋은 코드란 무엇일까요?' '코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?' 라는 질문을 많이 받곤 합니다. 그 기준은 무엇이고, 어떻게 발전 시킬수 있을지에 대한 고민도 많이 듣게되구요. 종종 주니어 개발자들과의 대화에서 "읽기 좋은 코드란 무엇일까요?", "코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?"에 대한 질문을 많이 받습니다. 그런 코드를 위해 구체적으로 어떤 방식으로 코드를 작성해야 하는지, 발전시킬수 있는지에 대해서도 질문을 많이 듣습니다. 생각나는 여러 기준을 제시하며 대화를 나누곤 했지만, 그러한 기준을 정확히 어디서 배웠고 어떻게 내재화하게 되었는지 생각해보면 그 출처가 명확하지 않았습니다. 나름 선호하는 코드 스타일과 개선이 필요한 코드를 식별하고 규칙을 만들어 적용해왔지만, 도움이 될 수 있는 구체적인 액션 아이템을 제시할때는 어려움을 느끼곤 했습니다. 그러다 최근 이 두 책을 제공받아 읽게 되었습니다. 그러다 최근 두 권의 책을 읽게 되었습니다. 이 책들은 좋은 코드를 작성하기 위한 기준과 코드에 안정성을 부여하는 방법에 대해 명확한 저자의 관점으로 구체적인 예시와 함께 설명하고 있습니다. 여러 곳에서 배운 지식들을 체계적으로 정리하고 재조명할 수 있는 좋은 기회가 되었습니다. 최근 비슷한 고민을 하는 개발자들뿐만 아니라 주니어 개발자들에게도 명확한 지침서가 될 수 있을 것이라 생각되어 다음 책들을 추천합니다. 목차를 확인해보시고 관심이 간다면 주문하여 읽어보시길 바랍니다. <ul ><li>읽기 쉬운 코드: http://gilbut.co/c/24034992MF</li><li>코드 작성 가이드: http://gilbut.co/c/24046947nM</li></ul>

예스24

읽기 쉬운 코드 / 코드 작성 가이드

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다, 엔비디아 CEO "日정원사와의 만남이 날 성공하게 만들어" 젠슨 황, 美대학 졸업식 연설 일본 정원사, 찌는 듯한 날에도 묵묵히 나뭇잎·이끼 정리하며 "정원 가꿀 시간은 충분" 말에 인생에서 가장 큰 깨달음 "평생 바치면 시간은 충분 우선순위 정해 집중하라" "매일 아침 중요한 업무부터 봐 출근도 전에 이미 성공적인 하루"

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다

우리는 늘 시간에 쫓겨서 살아갑니다.
해야 할 일이 많고, 하고 싶은 일이 많습니다.

회사의 CEO인 젠슨황에게도 그러했을 것입니다.
젠슨황은 1년에 1달동안은 해외에서 일을 한다고 해요.
자녀들이 10살때에 일본에서 1달동안 일을 한적이 있는데,
덥고 습한날 거대한 정원을 대나무 집게로 다듬는 정원사를 보며 물었습니다.

황 : 무엇을 하고 있나요?
정원사 : 죽은 이끼를 따고 있어요.
황: 정원이 너무 넓지 않나요?
정원사 : 25년간 정원을 가꿨고, 앞으로도 시간은 충분합니다.
황 : !!

이 순간이 젠슨황에게 가장 큰 깨달음을 준 시간이라고 해요.
너무나 넓어 보이는 정원이지만,
지금껏 25년간 정원을 가꿔온 정원사는 급하지 않았습니다.
매일 매일 자신을 믿으며 정원을 가꿀뿐이었죠.

직접적으로 겪은 이야기가 아니기에 여러분에게는 크게 와닿지 않을 수 있습니다.
젠슨황은 이렇게 얘기하네요.

'여러분이 평생을 바쳐 완성하고 싶은 기술을 찾기 바랍니다.
많은 일이 일어나고 있고 해야할 일이 많지만
인생의 우선순위를 정하고, 삶의 우선순위를 정하면 시간은 충분할 거예요.'

우리에게는 아직 시간이 많습니다.
우선순위를 정하고 방향을 잘 정해서 나아가봅시다.

https://www.hankyung.com/article/202406171169i

우리는 늘 시간에 쫓겨서 살아갑니다.해야 할 일이 많고, 하고 싶은 일이 많습니다. 회사의 CEO인 젠슨황에게도 그러했을 것입니다.젠슨황은 1년에 1달동안은 해외에서 일을 한다고 해요.자녀들이 10살때에 일본에서 1달동안 일을 한적이 있는데,덥고 습한날 거대한 정원을 대나무 집게로 다듬는 정원사를 보며 물었습니다. 황 : 무엇을 하고 있나요?정원사 : 죽은 이끼를 따고 있어요.황: 정원이 너무 넓지 않나요?정원사 : 25년간 정원을 가꿨고, 앞으로도 시간은 충분합니다.황 : !! 이 순간이 젠슨황에게 가장 큰 깨달음을 준 시간이라고 해요.너무나 넓어 보이는 정원이지만,지금껏 25년간 정원을 가꿔온 정원사는 급하지 않았습니다.매일 매일 자신을 믿으며 정원을 가꿀뿐이었죠. 직접적으로 겪은 이야기가 아니기에 여러분에게는 크게 와닿지 않을 수 있습니다.젠슨황은 이렇게 얘기하네요. '여러분이 평생을 바쳐 완성하고 싶은 기술을 찾기 바랍니다.많은 일이 일어나고 있고 해야할 일이 많지만인생의 우선순위를 정하고, 삶의 우선순위를 정하면 시간은 충분할 거예요.' 우리에게는 아직 시간이 많습니다.우선순위를 정하고 방향을 잘 정해서 나아가봅시다. https://www.hankyung.com/article/202406171169i

한국경제

젠슨황의 인생에 가장 큰깨달음을 준 한마디 - 시간은 충분하다

In business, being a nice person in the room can be more impactful than being the smartest. I share my insights on empathy, respect, and active listening as key skills for successful meetings and creating a positive team environment.

Do not try to be the smartest in the room; try to be the kindest. | Jorge Galindo's blog

"가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요."

"잘 듣고, 존중하고, 공감하고, 해결 중심 접근 방식을 통해 팀의 생산성을 향상 시킬 수 있습니다."

"친절함은 전염성이 있습니다. 당신이 친절하기 시작하면 다른 사람들도 친절해질 것이고, 팀 전체에 영향을 끼칠 것입니다"

"가장 똑똑한 사람은 몇몇 사람이 그리워 하지만, 친절한 사람은 모두가 그리워 합니다"

https://www.jorgegalindo.me/en/blog/posts/do-not-be-the-smartest-in-the-room-try-to-be-the-kindest

"가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요." "잘 듣고, 존중하고, 공감하고, 해결 중심 접근 방식을 통해 팀의 생산성을 향상 시킬 수 있습니다." "친절함은 전염성이 있습니다. 당신이 친절하기 시작하면 다른 사람들도 친절해질 것이고, 팀 전체에 영향을 끼칠 것입니다" "가장 똑똑한 사람은 몇몇 사람이 그리워 하지만, 친절한 사람은 모두가 그리워 합니다" https://www.jorgegalindo.me/en/blog/posts/do-not-be-the-smartest-in-the-room-try-to-be-the-kindest

Jorgegalindo

가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요

들어가며 안녕하세요. LINE+ Contents Service Engineering 조직에서 백엔드 개발을 맡고 있는 양강현, 이병찬입니다. 저희가 속해 있는 Contents Se...

Req-Saver로 캐시의 골칫거리 'Thundering Herd 문제' 쉽게 풀기!

라인에서 Cache를 사용할 때 발생하는 Thundering Herd 문제를 어떻게 해결했는지를 설명한 글입니다.

저도 이번에 이러한 현상을 Thundering Herd라고 부르는지 처음 알게 되었는데 보통 캐시를 쓰게 되면 디비에서 데이터를 가져와서 Redis 같은 캐시에 넣어두고 이후에는 캐시해서 조회해서 빠른 응답을 주게 됩니다. 하지만 캐시의 데이터를 계속 쓸수는 없고 캐시도 데이터가 많아지면 오래된 데이터는 사라지기 때문에 캐시에 데이터가 없거나 하면 디비에 가서 데이터를 가져와서 다시 캐시에 채워주게 됩니다.

이러한 경우 서버가 1대라면 문제가 안되지만 서버가 많고 당연히 사용자 요청도 동시에 많이 이뤄지기 때문에 캐시가 TTL로 없어지거나 하면 수많은 요청이 동시에 캐시에 데이터가 없어서 디비에 가서 디비에서 연결이 몰리고 이 데이터를 다시 캐시에 채워넣으려고 여러번 저장이 이뤄지게 되는데 이 문제를 Thundering Herd 문제라고 합니다.

이 문제를 Req-Saver라는 라이브러리를 만들어서 여러 요청이 들어왔을 때 하나의 요청만 디비에 갔다와서 데이터를 채워넣고 다른 요청은 캐시에 채워진 데이터로 응답하도록 지연시키는 구현을 했고 이를 스프링에 적용해서 성능 비교를 한 결과 평균 51%의 성능이 향상되었다고 합니다.

서비스에 따라 다르긴 하지만 부하가 심한 경우 캐시 만료에 따라 디비나 캐시에 부하가 몰릴 수 있는데 꽤 괜찮은 방법으로 보입니다.

https://techblog.lycorp.co.jp/ko/req-saver-for-thundering-herd-problem-in-cache

라인에서 Cache를 사용할 때 발생하는 Thundering Herd 문제를 어떻게 해결했는지를 설명한 글입니다. 저도 이번에 이러한 현상을 Thundering Herd라고 부르는지 처음 알게 되었는데 보통 캐시를 쓰게 되면 디비에서 데이터를 가져와서 Redis 같은 캐시에 넣어두고 이후에는 캐시해서 조회해서 빠른 응답을 주게 됩니다. 하지만 캐시의 데이터를 계속 쓸수는 없고 캐시도 데이터가 많아지면 오래된 데이터는 사라지기 때문에 캐시에 데이터가 없거나 하면 디비에 가서 데이터를 가져와서 다시 캐시에 채워주게 됩니다. 이러한 경우 서버가 1대라면 문제가 안되지만 서버가 많고 당연히 사용자 요청도 동시에 많이 이뤄지기 때문에 캐시가 TTL로 없어지거나 하면 수많은 요청이 동시에 캐시에 데이터가 없어서 디비에 가서 디비에서 연결이 몰리고 이 데이터를 다시 캐시에 채워넣으려고 여러번 저장이 이뤄지게 되는데 이 문제를 Thundering Herd 문제라고 합니다. 이 문제를 Req-Saver라는 라이브러리를 만들어서 여러 요청이 들어왔을 때 하나의 요청만 디비에 갔다와서 데이터를 채워넣고 다른 요청은 캐시에 채워진 데이터로 응답하도록 지연시키는 구현을 했고 이를 스프링에 적용해서 성능 비교를 한 결과 평균 51%의 성능이 향상되었다고 합니다. 서비스에 따라 다르긴 하지만 부하가 심한 경우 캐시 만료에 따라 디비나 캐시에 부하가 몰릴 수 있는데 꽤 괜찮은 방법으로 보입니다. https://techblog.lycorp.co.jp/ko/req-saver-for-thundering-herd-problem-in-cache

LY Corporation Tech Blog

라인에서 Cache를 사용할 때 발생하는 Thundering He

[#유퀴즈온더블럭] 천우희가 외모 때문에 오디션 떨어졌었다고😲? 예쁘고 귀엽고 사랑스러운데 연기까지 잘해버려서 세상이 질투했나 보다😎

1. “(데뷔 전에 오디션을 볼 떄) ‘배우 할 수 없다. 못 생겼다' 이런 얘기를 많이 들었어요"

2. “그 당시 허탈함이 있었는데, 그렇게 저한테 타격감은 없었어요. 저는 힘들 걸 ‘너무 힘들다' 이러는 성격이 아니고, ‘와~ 얼마나 잘 되려고 (지금) 이럴까?’ 이렇게 생각하는 편이에요"

3. “집에서 알바할 때도, 제가 전을 직접 부쳤거든요. 하면서도 ‘내 인생이 점점 버라이어티해지는군. 재밌겠어', 약간 이렇게 생각하고"

4. “그냥 이런 생각을 많이 했어요. ‘에피소드 하나 더 생긴다고 생각하지 뭐~', 약간 이렇게" (갈등 = 에피소드)

5. “(그런 상황에서도) 내가 할 수 있는 게 뭘까? 좀 자기 객관화를 해야겠다는 생각이 들더라고요. ‘내가 가지고 있는 포지션과 내가 가지고 있는 강점이 뭐지?’라는 생각을 하면서, 제가 나이대에 있는 배우들을 다 검색해봤어요" (=치열한 자료 조사)

6. “다 검색해봤는데, 저랑 느낌이 비슷한 사람은 없더라고요. (그래서) 그냥 그 치기 어린 나이에 생각했던 건 나는 ‘모 아니면 도다’였어요”

7. “크게 절망하지 않았던 게, 좌절하지 않았던 게, ‘(못 생겨서 배우를 할 수 없다면 하면) 내가 한 번 보여주지. 내가 이 얼굴로 배우의 얼굴이 뭐가 좋은지 진짜 보여줄게’, 이런 마음이 있었어요” (=의지력)

8. “똑같은 상황이라도, 저는 결국 ‘마음가짐’이라고 생각하거든요. 힘들다 힘들다 생각하면 그 생각 안에서 (내가) 못 벗어나는 거에요? 그래서 ‘얼마나 잘 되려고 이럴까?'라고 생각하면서 항상 좋은 면을 생각해보려고 하죠"

- 배우 천우희

https://www.youtube.com/watch?v=dyuaT8xyvDg&t=599s

1. “(데뷔 전에 오디션을 볼 떄) ‘배우 할 수 없다. 못 생겼다' 이런 얘기를 많이 들었어요" 2. “그 당시 허탈함이 있었는데, 그렇게 저한테 타격감은 없었어요. 저는 힘들 걸 ‘너무 힘들다' 이러는 성격이 아니고, ‘와~ 얼마나 잘 되려고 (지금) 이럴까?’ 이렇게 생각하는 편이에요" 3. “집에서 알바할 때도, 제가 전을 직접 부쳤거든요. 하면서도 ‘내 인생이 점점 버라이어티해지는군. 재밌겠어', 약간 이렇게 생각하고" 4. “그냥 이런 생각을 많이 했어요. ‘에피소드 하나 더 생긴다고 생각하지 뭐~', 약간 이렇게" (갈등 = 에피소드) 5. “(그런 상황에서도) 내가 할 수 있는 게 뭘까? 좀 자기 객관화를 해야겠다는 생각이 들더라고요. ‘내가 가지고 있는 포지션과 내가 가지고 있는 강점이 뭐지?’라는 생각을 하면서, 제가 나이대에 있는 배우들을 다 검색해봤어요" (=치열한 자료 조사) 6. “다 검색해봤는데, 저랑 느낌이 비슷한 사람은 없더라고요. (그래서) 그냥 그 치기 어린 나이에 생각했던 건 나는 ‘모 아니면 도다’였어요” 7. “크게 절망하지 않았던 게, 좌절하지 않았던 게, ‘(못 생겨서 배우를 할 수 없다면 하면) 내가 한 번 보여주지. 내가 이 얼굴로 배우의 얼굴이 뭐가 좋은지 진짜 보여줄게’, 이런 마음이 있었어요” (=의지력) 8. “똑같은 상황이라도, 저는 결국 ‘마음가짐’이라고 생각하거든요. 힘들다 힘들다 생각하면 그 생각 안에서 (내가) 못 벗어나는 거에요? 그래서 ‘얼마나 잘 되려고 이럴까?'라고 생각하면서 항상 좋은 면을 생각해보려고 하죠" - 배우 천우희 https://www.youtube.com/watch?v=dyuaT8xyvDg&amp;t=599s

배우 천우희의 스토리적 사고

추천해주신 도서가 다 좋아보입니다! 5번은 이미 읽고 있는 거네요! 
🤣

개발자

송은혜

와이즈넛 챗봇 개발자

박창만

개발

우다원

오락까락끼리까락하는 개발자

홍성준

Chief Maker

겸임강사

Co-founder, VP

책임연구원

Lead of Generative AI

R&D 그룹장

Lead of AI Production

골빈해커

링크

Code addict, AI/ML believer, 25+ years’ coding experienced start-up guy, Built a unicorn and building another big one!

모든 개발자를 위한 프로그래밍 책 Top 5

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필