Tech Digest(2026년 7월)

Tech Digest는 개발, 기술, 제품, 오픈소스, 스타트업에 관한 아티클을 읽고 개인적으로 이해한 내용을 기록합니다. 이 활동을 통해 더 많은 사람들이 도움을 받을 수 있었으면 해서 블로그도 공유를 시작합니다.

읽은 글

AI가 코드를 쓰는 시대, 인간이 코드를 쓰는 것도 가치가 있다.

• 현재 엔지니어의 역할은 코드를 직접 쓰는 것이 아니라, AI 에이전트가 잘 작동할 수 있는 소프트웨어 팩토리(인프라)를 구축하는 것
• 잘 다듬어진 테스트와 프롬프트만 있으면 AI는 충분히 좋은 변경을 만들 수 있어서, 인간이 직접 코드를 쓰는 것이 무의미해 보일 수 있다. 하지만 필자는 여전히 직접 코드를 쓰는 것이 유용하다고 주장한다
• 가장 큰 이유는 영어를 거치지 않고 직접 실행 환경에서 생각할 수 있기 때문
  • 영어는 계산/알고리즘을 정확하게 표현하기에 부적합하다
  • 생성된 코드만 읽고 승인하는 방식으로는 소유감(ownership)이 약해지고, Slop(엉성한 코드)을 놓치기 쉽다
• 자신이 다루기 어려운 코드는 AI에게도 어렵다
  • 인간이 직접 코드를 정리하고 일관된 원칙을 부여하면, 결과적으로 AI(소프트웨어 팩토리) 전체가 더 잘 작동한다
• AI 에이전트는 컴파일러가 아니라, 신입 인턴에 가깝다
  • 불완전한 코드 + 모호한 지시를 받아 안전한 변경만 만들려는 경향이 강함
  • 이로 인해 기존의 나쁜 결정(예: 잘못된 아키텍처)을 래퍼(기존 코드나 기능을 감싸는 새로운 코드 layer를 만드는 것)와 인디렉션(직접 하지 않고, 간접적으로 거쳐서 하는 것, 중간 단계를 추가하는 행위)으로 감싸며 더 복잡하게 만든다
  • 인간이 직접 코드를 쓰며 불필요한 부분을 과감히 삭제하고 탐색해야 더 나은 설계가 나온다
• AI 덕분에 소프트웨어 개발 환경은 크게 향상되었다. 하지만 세세한 디테일에 주의를 기울이고, 전체 그림과 연결짓기 위해서는 직접 손을 움직여 코드를 경험하는 과정이 여전히 필요하다

나는 왜 객체 설계를 포기하고 스프레드시트처럼 코딩하기 시작했나

• 많은 개발자는 애플리케이션이 커지면 MVC, MVVM, DI 등의 수많은 디자인 패턴을 도입하려 한다. 그러나 저자는 이런 접근이 코드의 의도와 실제 동작 사이에 수많은 추상화 층을 만들어내, 결과적으로 실행 시에야 전체 모습을 파악할 수 있는 복잡한 객체 그래프를 낳는다고 지적함. 이로 인해 버그 추적이나 사양 변경 시 코드의 ‘고고학적 발굴 조사’를 강요당하는 현상에 강한 의문을 제기한다.
• 이에 저자가 선택한 대안은 전통적인 객체 중심 설계(요소를 클래스에 쪼개는)가 아니라, 데이터를 중심으로 한 명시적 데이터 흐름 모델이었다. 모든 로직을 ‘셀(변수)‘과 ‘계산(데이터 간의 의존 관계)‘으로 구성된 프로그램(시트) 단위로 정의하며, Excel의 스프레드시트에서처럼 데이터 간 의존성(영향 범위)을 코드상에서 명시적으로 기술하는 방향으로 틀었다.
• 이 접근의 핵심은 애플리케이션의 구성 단위를 ‘상태와 행동을 가진 객체’에서 ‘명시적으로 연결된 데이터의 처리 과정’으로 재구성 했다. 전통적인 설계에서는 어떤 객체의 변화가 다른 곳에 전달되기 위해 옵저버 패턴이나 이벤트 버스 같은 복잡한 배선이 필요했다. 그러나 입력과 출력을 데이터로서 미리 선언함으로써, 코드들이 서로를 숨겨서 참조하는 ‘보이지 않는 결합’을 근본부터 배제하게 했다.
• 게다가 UI의 자동 생성이나 되돌리기(Undo/Redo) 같은 시스템 공통의 무거운 기능을 개별 기능 클래스의 구현에 의존시키지 않고, 데이터 흐름의 구조 자체에 포함시킨 점도 극히 합리적이다. 기능을 추가하는 것은 새로운 클래스 간의 결합 관계를 협상하는 것이 아니라, 단순히 새로운 ‘데이터 처리 시트’를 병렬로 배치하는 것으로 끝낸다. 시스템의 전체 구조가 런타임상의 메모리 공간에서가 아니라, 코드상의 정적인 데이터로서 한눈에 파악할 수 있는 상태를 만들어 개발 효율을 비약적으로 향상시켰다.

C로 직접 만든 TCP 로드 밸런서로 이해하는 이벤트 드리븐 아키텍처

• TCP 레벨(Layer 4) 로드 밸런서를 C로 직접 구현하며 그 동작 원리를 깊이 이해하려는 실천적 해설이다. 단순한 개념 설명을 넘어, 「왜 thread-per-request 모델이 한계에 부딪히는가」와 「이벤트 드리븐 설계가 왜 효과적인가」를 메모리·CPU 관점에서 구체적으로 보여준다.
• 로드 밸런서의 기본 역할은 클라이언트 연결 수락 → 백엔드 서버 선택 → 연결 → 양방향 데이터 전달로 단순하지만, 본질은 대량의 동시 연결을 어떻게 효율적으로 처리하느냐 에 있다. 스레드를 요청마다 생성하는 방식은 일견 이해하기 쉽지만, 메모리 소비나 컨텍스트 스위치의 비용으로 인해 곧 한계에 도달한다. 특히 백엔드 처리 중 스레드가 idle 상태로 대기하는 비효율이 크다. 그래서 등장하는 것이 epoll이나 kqueue 같은 이벤트 알림 기구를 사용한 설계이다.
• 이 설계에서는 「처리하는」 것이 아니라 「기다리는」 것을 다루는 방식이 근본적으로 바뀐다. 전통적으로는 각 요청에 전용 실행 주체(스레드)를 할당했지만, 이벤트 드리븐에서는 「지금 바로 처리해야 할 연결만 골라내는」 발상으로 바뀐다. 결과적으로 단일 또는 소수의 스레드로 수만 개의 연결을 다룰 수 있게 되어 리소스 효율이 극적으로 개선된다.
• CPU의 사용법도 함께 바뀐다. 스레드가 많을 경우 CPU는 문맥 전환에 시간을 빼앗기지만, 이벤트 드리븐에서는 그 오버헤드가 거의 사라진다. 즉, 같은 하드웨어에서도 「무엇에 시간을 쓰고 있는가」가 바뀜으로써 실효 성능이 크게 달라진다. 이 설계 사상이 NGINX나 HAProxy 같은 고성능 시스템의 핵심 설계 사상이다.

CPU를 가장 화나게 하는 데이터 접근 패턴

• CPU에게 최악의 데이터 액세스 패턴을 탐구하는 실험을 통해, 메모리 계층(캐시, TLB, 페이지 테이블)과 DRAM의 작동 방식을 상세히 설명한 기사이다. 순차 액세스가 가장 빠른 반면, 랜덤 액세스는 이미 10배 이상 느려진다. 저자는 캐시 라인 낭비, 페이지 경계 활용(프리페치 무력화), 캐시 set conflict, stride를 통한 TLB/PTE 부하 증가, 그리고 DRAM bank/row conflict까지 하나씩 역이용하여 랜덤보다 약 33% 더 느린 액세스 패턴을 만들어낸다.
• CPU의 성능을 결정짓는 것은 클럭 주파수나 명령 실행 속도만이 아니다. 최근 CPU는 ‘다음에 무엇을 읽을지’를 예측하여 캐시로 미리 데이터를 옮겨 빠르게 처리한다. 따라서 프로그램의 실행 속도는 알고리즘뿐만 아니라 데이터를 어떤 순서로 읽는지에 크게 좌우된다.
• 그리고 그 최적화를 하나씩 파괴해 나가는 구성으로 되어 있다. 먼저 캐시 라인을 낭비하고, 다음으로 페이지 경계를 넘어 프리페치를 무력화하며, 이어서 캐시 세트 충돌이나 TLB·페이지 테이블의 부하를 늘리고, 마지막으로 DRAM 내부의 뱅크 충돌까지 노란다. 단순한 벤치마크가 아니라, ‘CPU가 왜 빠른가’를 역방향으로 이해하는 교재가 된다.
• 최종 단계에서는 성능 저하의 원인이 CPU가 아니라 메모리 컨트롤러나 DRAM의 내부 구조로 옮겨간다. 소프트웨어 코드가 결국 하드웨어의 물리적 구조에까지 영향을 받는다는 사실을 이 실험이 보여준다.

2.7KB 메모장 TinyRetroPad, bloat 시대에 던지는 메시지

• 전 Microsoft 엔지니어이자 Task Manager의 저자로 알려진 데이브 플러머(Dave Plummer)는, 최근 몇 년간 Windows 기본 메모장이 AI 기능과 각종 부가 기능으로 인해 점점 비대해지는 현상에 의문을 제기하며, 불과 약 2.5~2.7KB 크기의 초소형 메모장 “TinyRetroPad”를 공개했다. 이는 Windows XP 시대의 메모장을 연상시키는 간결한 조작성을 유지하면서도, 파일 열기·저장·폰트 변경·인쇄 등의 기본 기능을 모두 갖추고 있다.
• TinyRetroPad는 필요한 기능을 애플리케이션 내부에 모두 직접 구현하지 않고, Windows에 기본 탑재된 RichEdit 컴포넌트 등을 적극적으로 활용한다. 프로그램 자체는 극도로 작지만, OS가 제공하는 메커니즘을 현명하게 재사용함으로써 충분한 실용성을 확보했다. 이는 “새로 만드는” 것이 아니라 “이미 있는 것을 잘 활용하는” 설계 철학을 보여준다.
• 과거 Microsoft에서는 Notepad는 플레인 텍스트 전용, WordPad는 리치 텍스트 전용으로 역할을 명확히 구분하고, 불필요한 기능을 넣지 않는 것이 미덕으로 여겨졌다. 그러나 현재는 단순한 도구에도 AI 어시스턴트, 클라우드 연동, 텔레메트리 등 수많은 기능이 기본으로 추가되는 것이 당연시되고 있다. 사용자 경험 향상이라는 명목으로 기능이 계속 늘어나면서, 애플리케이션은 점점 크고 복잡해졌고, 본래의 “바로 시작해서 바로 쓸 수 있는 도구”라는 본질이 희미해졌다.
• TinyRetroPad는 이러한 흐름에 대한 일종의 반발이라고 생각한다. 극단적으로 작은 구현을 통해 “정말 필요한 것은 무엇인가”, “OS가 제공하는 공통 기능을 더 믿고 활용할 수는 없는가”라는 소프트웨어 설계의 원점을 다시금 되묻고 있다.
• 이 이야기는 단순한 “옛날 Notepad가 좋았어”라는 노스탤지어가 아니다. AI 시대일수록 모든 소프트웨어에 기능을 끊임없이 추가하려는 경쟁이 치열해지지만, 진정한 가치는 “무엇을 추가할까”를 결정하는 데서뿐만 아니라 “무엇을 추가하지 않을까”를 현명하게 판단하는 설계력에서도 나온다.
• 이 프로젝트는 단순히 “작은 바이너리”를 만드는 데 목적이 있는 것이 아니라, OS 전체를 하나의 플랫폼으로 보고 공통 자산을 최대한 재사용한다는 고전적인 설계 사상을 실증한다. 컴포넌트 재사용, 책임 분리, 단순성 유지라는 원칙이 AI 시대의 소프트웨어 개발에서도 여전히 강력한 가치를 지니고 있음을, 이 작은 텍스트 에디터가 조용히 보여주고 있다.

AI가 코드를 쓰는 시대, 우리는 무엇을 가르칠 것인가

• AI에 의한 코드 생성이 일상화되고 있는 시대에, 저자는 12년 만에 대학 알고리즘 강의를 다시 맡게 되었다. 이전에는 “어떤 교과서를 쓸까”가 주요 고민이었지만, 이번에는 “무엇을 가르쳐야 하는가”가 핵심 주제가 되었다. 학생들의 학습 방식과 소프트웨어 개발 현장이 크게 변했기 때문이다.
• 저자는 AI가 코드를 생성하는 시대가 되었기 때문에, 학생들에게 코드를 읽고 이해하며, 그 안에 담긴 알고리즘을 파악하고, 정확성과 성능을 분석·평가하는 능력이 더욱 중요해졌다고 강조한다. 교재 선택에서도 시중 교과서나 AI 기능을 강조하는 플랫폼(zyBooks 등)보다는, 자신의 강의 노트를 중심으로 엄선한 웹 자료를 보완하는 방향을 검토하고 있다. 알고리즘의 기본 체계 자체는 여전히 가치가 있는지 독자에게 묻는다.
• AI의 등장에도 불구하고 저자는 “새로운 알고리즘을 대거 추가해야 한다”는 극단적인 결론을 내리지 않는다. 오히려 코드 작성의 가치가 상대적으로 낮아질수록 추상적 사고와 계산 복잡도·타당성 평가 능력이 더 중요해진다는 관점을 제시한다.
• 교재 선택 기준 역시 가격이나 AI 기능 유무가 아니라, 학생의 이해를 얼마나 깊게 이끌어내는가에 초점을 맞추고 있다. AI 도입 자체를 목표로 삼지 않고, 학습 경험을 어떻게 설계할 것인지에 관심을 두는 태도가 인상적이다.
• 마지막으로 저자가 독자들에게 적극적으로 의견을 구하는 모습에서 알 수 있듯이, AI 시대의 컴퓨터과학 교육 커리큘럼은 아직 “완성형”이 아니다. 교육자들이 직접 시행착오를 거치며 만들어가는 과정이라는 점이 잘 드러난다.

시간이 증명하는 좋은 API

• 좋은 API는 처음에 “아름답게 보이는” 것이 아니라, 시간이 지나도 망가지지 않고 계속 사용되는 API이다. API의 진짜 품질은 설계 직후나 첫 버전 단계에서는 제대로 판단할 수 없다. 처음에는 요구사항이 단순하고, 사용자도 제한적이며, 주변 시스템도 변하지 않았기 때문에 거의 모든 API가 괜찮아 보인다. 그러나 다른 팀이 사용하기 시작하고, 요구사항이 바뀌며, 구현이 교체되고, 원래 설계자가 전혀 예상하지 못한 방식으로 활용되면서 진짜 우수한 API인지가 드러난다. 저자는 “시간이 지나도 여전히 의미가 있는 API”가 진정한 좋은 API의 기준이라고 강조한다.
• 이런 관점에서는 경계(Boundary)를 얼마나 신중하게 결정하느냐가 API 수명을 좌우한다. 편리함을 이유로 내부 상태나 불필요한 필드를 공개하면, 그것이 곧 사용자들의 전제가 되어 나중에 변경하기 극도로 어려워진다. 현재 UI나 일시적인 요구사항에 맞춰 API를 설계하는 경우도 마찬가지다. 프로덕트가 변하는 순간 API도 함께 구식이 된다. API는 화면의 모양이 아니라, 더 오래 지속되는 도메인 개념을 표현해야 하며, 버저닝(versioning)도 근본적인 설계 문제를 해결해주지 못한다고 지적한다.
• 이 사고방식의 핵심은 “API는 코드가 아니라 계약(Contract)이다”라는 인식이다. 개발자는 구현을 자유롭게 바꿀 수 있다고 생각하지만, 한 번 공개된 동작이나 데이터는 사용자가 의존하게 되면서 사실상의 사회적·기술적 계약이 된다. 따라서 “추가하는 것은 쉽지만, 삭제하는 것은 매우 어렵다”는 원칙을 가장 중요하게 여겨야 한다. 처음부터 최소한만 공개하고, 정말 필요할 때만 추가하는 보수적인 접근이 장기적으로 안정적인 API를 만든다. API는 화려함이나 단기적인 편리함보다 변경 내성(Change Resilience)을 최우선으로 설계해야 한다는 것이다.
• 프론트엔드에 최적화된 응답이나 지나치게 똑똑한 API도 경계해야 한다. 처음에는 개발 효율이 높아 보이지만, 실제로는 암묵적 가정과 복잡성을 API 안에 숨겨두는 행위일 뿐이다. 새로운 유스케이스가 등장하면 유연성을 잃고 유지보수가 힘들어진다. 장수하는 API는 화려함보다 조금 지루하고 솔직한(boring and honest) 모습, 즉 경계와 상태를 명확하게 드러내는 모습을 가져야 한다고 저자는 결론짓는다.

AI가 만드는 부와 권력을 누구에게 돌려줄 것인가 — 버니 샌더스의 제안

• 버니 샌더스는 WIRED 인터뷰에서 AI를 “인류 역사상 가장 중대하고 변혁적인 기술”로 규정하면서도, 그 개발·배치 방향을 소수의 거대 IT 기업과 억만장자(머스크, 베이조스, 저커버그 등)가 독점적으로 결정하는 것을 가장 큰 문제로 지적한다. AI가 인간 지식과 노동을 기반으로 한 기술임에도 불구하고, 그 이익이 극소수에게 집중되는 구조를 비판하며, 데이터센터 건설 모라토리엄(일시 중단)과 미국 AI 주권 부 펀드(American AI Sovereign Wealth Fund)를 주요 대안으로 제시하며, AI로 인한 이익을 주주뿐 아니라 사회 전체에 분배해야 한다고 주장한다.
• 주권 부 펀드는 단순한 재분배를 넘어, AI 기업(매출 2억 달러 이상)의 지분 절반을 공공이 소유하고 이사회에 공공 대표를 절반 참여시켜, 이익 분배뿐 아니라 기술 개발·배치 결정 자체에 시민의 목소리를 반영하려는 것이다. AI로 인한 대규모 실업(트럭·운송 노동자 등), 어린이 정신건강 악화, 프라이버시 침해, 정교해지는 딥페이크 등 위험이 이미 드러나고 있음에도, 의회에서는 의미 있는 논의나 입법이 전혀 이루어지지 않고 있다고 강하게 비판한다.
• 그 배경으로 거대 IT 기업의 막대한 정치 자금 기부, 슈퍼 PAC, Citizens United 판결 등 부패한 선거 자금 시스템으로 인해 많은 정치인들이 AI 규제에 손대지 못하는 구조가 있다고 분석한다. 샌더스는 문제의 본질을 ‘AI 기술 자체’가 아니라 AI가 증폭시키는 권력 집중과 올리가키(소수 지배)에 둔다. 데이터센터 반대 운동도 환경·전기 요금 문제뿐 아니라, 지역 주민보다 기업 의지가 우선시되는 ‘민주주의 결여’에 대한 반발로 해석한다.
• 샌더스는 AI 개발을 ‘중국과의 경쟁’이라는 국가주의 프레임으로 접근하는 데도 거리를 두고 있으며, 인류 전체의 이익과 국제 협력을 강조한다. 기술 경쟁을 핑계로 규제를 미루는 대신, 사회적·인간적 가치를 최우선으로 다뤄야 한다는 입장이다.
• 전반적으로 이 인터뷰는 AI 논쟁의 초점이 ‘기술의 편리함 vs 위험’에서 ‘AI가 창출하는 막대한 부와 권력을 누가 통제하고, 누구를 위해 설계되는가’라는 자본주의·민주주의의 근본 설계 문제로 이동하고 있음을 보여준다. 샌더스는 수십 년간 일관되게 주장해온 ‘집중된 부의 민주주의 위협’이 AI 시대에 정점에 달했다고 보고, 지금이 변화를 위한 결정적 순간이라고 강조한다.

우수한 엔지니어란, 코드를 쓰는 사람이 아니라 팀의 ‘보이지 않는 마찰’을 줄이는 사람이다

• 이 글은 채용 면접에서 시스템 설계나 알고리즘 능력으로 높은 점수를 받지 못했던 엔지니어 ‘Mitch’가, 실제 입사 후 조직에 큰 가치를 창출하는 과정을 그린다. 그는 화려한 코딩 실력이나 아키텍처 설계 능력이 뛰어나지 않지만, 오래된 문서를 정리하고, 모호한 책임 영역을 명확히 하며, 인수인계 과정의 잠재적 문제를 미리 발견해 해결한다. 팀은 점차 그가 있음으로써 일이 훨씬 수월해지고 있다는 사실을 깨닫는다.
• 저자는 이런 인재를 ‘Gap Reader(갭 리더)’라고 명명한다. 이들의 핵심 가치는 방대한 지식량이 아니라, ‘어디에 구멍(갭)이 있는지’를 감지하는 능력이다. 조직 간 인식 차이, 아무도 소유하지 않는 책임 공백, 미래 장애 요인이 될 수 있는 의존 관계나 손실된 맥락을 찾아내 메워나간다. 그러나 이러한 성과는 ‘아무 일도 일어나지 않았다’는 형태로 나타나기 때문에, 면접이나 성과 평가에서 쉽게 간과되기 쉽다는 점을 지적한다.
• 이 글은 엔지니어링의 가치를 ‘코드를 작성하는 능력’에서 한 단계 더 나아가 ‘조직 전체의 마찰과 조정 비용을 줄이는 능력’으로 확장한다. 소프트웨어 개발에서 많은 작업은 실제 코딩 시간보다 사람과 사람, 팀과 팀을 연결하고, 안전하게 변경할 수 있는 상태를 만드는 데 쓰인다. Mitch가 하는 일은 바로 이런 기술적 레버리지(technical leverage)를 창출하는 진짜 엔지니어링이다.
• 이 글은 평가 시스템의 구조적 문제도 제기한다. 장애를 일으킨 뒤 영웅적으로 해결한 사람은 인정받기 쉽지만, 장애 자체를 미연에 방지한 사람은 눈에 띄지 않는다는 역설을 꼬집는다. ‘성과’는 눈에 보이는 결과물뿐 아니라, 문제가 발생하지 않은 안정성에도 존재한다는 관점이다.
• 마지막으로, Gap Reader의 잠재적 위험도 언급한다. 이 능력이 뛰어난 사람에게 조직이 지나치게 의존하게 되면, “그 사람에게 물어보면 된다”는 상태가 되어 개인 자체가 병목(Bottleneck)이 될 수 있다. 본래는 이런 지식과 조정을 시스템과 프로세스로 전환해야 하는데, 사람에게 의존하게 되면 장기적으로 위험해진다는 것이다.

시니어 엔지니어가 되어 배운 것들

• 「좋은 엔지니어는 모범 사례를 아는 사람이지만, 시니어는 그것을 깨야 할 순간을 아는 사람이다.」 이 한 문장이 10년 넘게 경험을 쌓은 엔지니어가 도달한 결론을 가장 잘 표현한다. 기술 스택이나 프로그래밍 언어의 우열에 크게 의미를 두지 않는다. 대신 소프트웨어 개발의 기본 원칙, 사람과의 소통, 문서 작성, 매니저와의 신뢰 관계, 적절한 이직 타이밍 같은 보편적인 요소들이 긴 커리어에서 훨씬 더 중요하다고 필자는 말한다. “최고의 코드는 존재하지 않는 코드”, “SQL은 투자 대비 효과가 가장 높은 언어” 같은 직설적인 의견도 유행보다 본질을 중시하는 태도를 보여준다.
• 커리어가 쌓일수록 가치관도 많이 바뀐다. 젊을 때는 최신 기술과 코딩 자체에 열중했지만, 경험을 쌓으면서 사람을 키우는 일, 팀을 지탱하는 일, 가족과 건강, 삶의 균형이 훨씬 더 소중하다는 것을 깨닫게 된다. “코드를 쓰는 것은 일의 일부일 뿐, 삶 그 자체는 아니다”라는 관점이 글 전체를 관통한다.
• 이 사고방식이 가장 잘 드러나는 것은 모범 사례를 아는 것과 상황에 따라 일부러 벗어나는 것을 구분하는 능력이다. 경험은 단순히 지식을 늘려주는 것이 아니라, 현실의 제약이나 조직 상황을 고려해 최적의 판단을 내릴 수 있게 해준다고 필자는 반복해서 강조한다. 기술뿐만 아니라 인간관계, 비즈니스, 조직 운영까지 폭넓게 생각할 수 있게 됐을 때 진짜 시니어 엔지니어라고 할 수 있다.
• 일에 대한 태도도 변한다. 기술은 취미에서 직업으로 바뀌고, 일은 삶의 중심에서 한 부분으로 자리 잡는다. 대신 자신이 키운 사람들, 지탱한 팀, 쌓아온 신뢰 관계가 오래 남는 진짜 성과라는 가치관으로 자연스럽게 옮겨간다.

오픈 소스

Postgres 하나면 충분하다

• 이 사이트는 많은 개발 팀이 실제 필요를 앞지른 premature optimization으로 Redis, Elasticsearch, Kafka 등 수많은 외부 서비스를 도입해 시스템을 불필요하게 복잡하게 만드는 관행을 날카롭게 비판한다. 표면적으로는 진지한 기술 제안처럼 보이지만, “Webscale™(유행하는 기술을 무작정 늘어놓은 복잡한 구성)” 스택이라는 풍자적 표현을 통해 트렌드를 맹목적으로 추종하는 엔지니어 문화와 “혁신 토큰(inovation tokens)” 낭비하지 말라는 등 풍자와 실용적인 조언을 하고 있다.
• 결국 “하나의 데이터베이스로 충분하다”는 메시지는, 운영 복잡성과 예상치 못한 문제에 시달리는 현업 개발자들에게 강력한 공감을 불러일으키며, 지루하지만 검증된 인프라(Boring Infrastructure)로의 회귀와 Postgres의 한계를 먼저 도전해보는 실용성을 강조한다.
• 이 주장이 설득력을 얻는 배경에는 하드웨어의 극적인 발전이 있다. 과거 고가의 전용 장비와 자원 부족해서 성능을 짜내기 위해 데이터를 분산·최적화할 수밖에 없는 물리적 제약이 존재해 부족한 자원과의 싸움이었지만, 지금은 단일 서버로도 수백 코어 CPU, 테라바이트 메모리, 초고속 NVMe 스토리지를 활용할 수 있게 되었다. 한때 대규모 데이터 센터나 전문 DBA(데이터베이스 관리자) 팀이 필요했던 수준의 부하를, 이제 저렴한 한 대의 머신이 여유롭게 처리해 버린다. 대부분의 애플리케이션에서 “성능 부족 공포”는 이미 시대착오적인 것이 되었다.

아래는 Postgres로 할 수 있는 것들에 대응되는 툴들(오픈소스)을 소개한다.

Herdr

Herdr이 AI Agent 시대에는 잘 맞는 툴인 것 같다. IDE에서 CLI로 넘어가면서 자연스럽게 아래 워크플로가 가능해진다. 자세한 사용법은 Herdr 설정에서 확인할 수 있다.

• 평소에는 Ghostty에서 터미널 중심으로 작업하고,
• 대규모 코드 리딩이 필요하면 Zed에서 하고,
• 이동 중에는 Orca IDE에서 같은 Agent를 이어받아 확인하며,
• 다시 집에 와서는 Ghostty에서 이어서 작업한다.