
- 45권의 기술 서적이 남긴 단 하나의 인사이트
- Bento — 파일 하나로 끝내는 오피스 스위트
- 스타트업 Postgres 생존 가이드
지능이 흔해진 시대에도 개발자의 진짜 실력은 도구가 아니라 ‘무엇을 어떻게 만들지 아는 감각’에서 갈립니다. 오늘 GeekNews를 달군 세 편의 글은 공교롭게도 그 감각을 서로 다른 각도에서 이야기합니다. 45권의 기술서가 남긴 문장, 파일 하나에 담긴 오피스, 그리고 프로덕션 Postgres의 생존법까지. 개발자가 오늘 챙길 이슈 3선을 3분 안에 정리했습니다.
45권의 기술 서적이 남긴 단 하나의 인사이트
두 번 설계하라 — AI 시대에 더 강해진 원칙
기술 서적 팟캐스트 ‘Book Overflow’가 2주년을 맞아, 지난 2년간 읽은 45권에서 지금까지 사고방식에 영향을 주는 ‘단 하나의 인사이트’만 골라 공유했습니다. 그중 가장 자주 인용된 책은 John Ousterhout의 ‘A Philosophy of Software Design’입니다. 핵심은 “두 번 설계하라(Design It Twice)” — 처음부터 완벽하게 설계하려 하지 말고, 시스템을 만들며 배우고 개선하라는 것입니다. 흥미롭게도 진행자들은 LLM을 활용하면 두 번 설계하는 데 드는 노력이 줄어들어 이 원칙이 오히려 더 실용적이 됐다고 말합니다.
나머지 목록도 결이 비슷합니다. Martin Fowler의 ‘Refactoring’은 리팩토링을 ‘출력을 바꾸지 않고 설계만 개선하는, 언제든 멈춰도 되는 작은 작업’으로 좁게 정의합니다. Michael Feathers의 ‘Working Effectively with Legacy Code’는 “변경하기 두렵거나 어려운 코드는 잘못 설계된 것”이라고 단언하죠. Kent Beck의 ‘Tidy First’는 코드의 ‘옵셔널리티(유연성)’를 옵션 거래의 시간 가치에 빗대 설명합니다. 도구와 문법이 아니라 ‘판단의 원칙’을 다룬 책들이 오래 살아남았다는 점이 인상적입니다.
Tech Insight — AI가 코드를 대신 써주는 시대에 이 목록이 가리키는 방향은 분명합니다. 문법을 외우는 능력은 값이 떨어지고, ‘무엇을 두 번 설계할지, 어떤 복잡성을 캡슐화할지’를 결정하는 안목이 귀해집니다. 신입 개발자라면 최신 프레임워크 책보다 이런 ‘원칙서’를 먼저 읽는 편이 레버리지가 큽니다.
Bento — 파일 하나로 끝내는 오피스 스위트
570KB HTML 한 개가 문서이자 앱
Bento는 문서·편집기·뷰어·발표 도구를 하나의 .bento.html 파일에 담은 PowerPoint 대체제입니다. 약 570KB짜리 파일 하나가 완전한 애플리케이션으로 동작하며, 계정도 클라우드도 설치 프로그램도 필요 없습니다. 브라우저로 열면 즉시 편집기가 뜨고, 저장하면 문서 데이터가 파일 자체에 다시 기록됩니다. 글꼴·이미지·차트까지 포함돼 파일 사본만으로 어디서든 열고 발표할 수 있죠. 이메일이나 AirDrop으로 전달하는 것이 곧 ‘공유’가 됩니다.
개발자 입장에서 가장 눈여겨볼 지점은 포맷 설계입니다. 슬라이드 데이터가 파일 상단에 읽을 수 있는 평문 JSON으로 저장돼, Claude Code·Codex·Cursor 같은 AI 에이전트가 애플리케이션 코드를 건드리지 않고 JSON만 수정해 슬라이드를 만들 수 있습니다. 같은 id를 가진 요소를 슬라이드 사이에서 움직이는 Morph 전환, 의존성 없는 자체 차트 엔진, AES-GCM 종단간 암호화와 CRDT 기반 실시간 협업까지 지원합니다. 소프트웨어는 MIT 라이선스로 공개됐고, Docs와 Sheets도 같은 단일 파일 방식으로 준비 중입니다.
Tech Insight — ‘로컬 우선(local-first) + AI 친화 포맷’의 조합은 앞으로 더 흔해질 신호입니다. 상태를 서버가 아니라 파일 안에 두면 벤더 종속과 구독료에서 자유로워지고, 데이터를 평문 JSON으로 노출하면 에이전트가 곧바로 자동화할 수 있습니다. 사내 발표자료나 리포트를 다루는 팀이라면 ‘사람이 아니라 에이전트가 편집하는 문서’를 실험해 볼 만합니다.
스타트업 Postgres 생존 가이드
ORM 밖에서 SQL을 직접 쥐어야 할 때
작업 큐 서비스 Hatchet이 2년간 프로덕션에서 겪은 문제를 바탕으로, 초기 스키마 설계부터 대량 쓰기와 테이블 마이그레이션까지 Postgres 운영 원칙을 정리했습니다. 읽기는 인덱스와 ORDER BY를 맞추되, 쿼리 플래너가 통계에 따라 순차 스캔을 고를 수 있으므로 EXPLAIN ANALYZE로 예상치와 실제를 반드시 비교하라고 강조합니다. 쓰기 안정성은 짧은 트랜잭션, 필요한 행만 잠그기, CREATE INDEX CONCURRENTLY, 연결 풀링에 달려 있으며, 여러 행을 한 번에 보내는 배치 처리는 이들의 측정에서 처리량을 약 10배 높였습니다.
규모가 커질수록 무서운 것은 성능이 아니라 방치된 유지보수입니다. 고빈도 쓰기 환경에서 기본 autovacuum 설정이 dead tuple을 제때 회수하지 못하면 테이블이 팽창하고, 최악의 경우 transaction ID wraparound에 이르러 큰 폭의 다운타임이 발생합니다. 작업 큐에는 FOR UPDATE SKIP LOCKED로 다른 쿼리를 방해하지 않고 행을 예약하고, 시계열 데이터는 파티셔닝으로 autovacuum과 삭제를 가볍게 만듭니다. 글의 결론은 명확합니다 — ORM은 편리하지만, 결정적인 순간에는 추상화 밖에서 SQL을 직접 제어할 수 있어야 합니다.
Tech Insight — 스타트업 초기라면 ORM으로 빠르게 출시하는 편이 옳습니다. 다만 HN 토론에서 나온 지적처럼, 진짜 생존을 좌우하는 건 백업·복구 계획과 모니터링·경보입니다. transaction ID 경고를 이메일이 아니라 호출기(온콜)에 연결해 두는 것만으로도 ‘박싱 데이 새벽에 DB가 멈추는’ 사고를 피할 수 있습니다.
관련 글
- 25년간의 소프트웨어 개발 이야기
- Google에서 14년간 얻은 21가지 교훈
- Slidev — 개발자를 위한 발표자료 작성 도구
- Reveal.js — 오픈소스 HTML 프리젠테이션 프레임워크
- 건강한 Postgres DB를 위한 팁
출처
- GeekNews — 45권의 기술 서적에서 얻은 핵심 인사이트
- GeekNews — Bento, 파일 하나에 모두 들어가는 오피스 스위트
- GeekNews — 스타트업의 Postgres 생존 가이드
AI Biz Insider · Tech Digest · aibizinsider.com
댓글 남기기