#개발 문화
3개의 포스트
코드를 보지 마라, 아이디어를 잡아라 — antirez가 던진 불편한 질문
Redis를 만든 사람이 말했다. '아무도 이 코드를 봐선 안 된다. 코드가 담은 아이디어만 보면 된다.' 30개월에 걸친 그의 입장 변화를 추적하고, 1975년의 책이 왜 지금 다시 읽히는지, 그리고 숫자들이 정말 그의 반대편에 서 있는지 끝까지 따져본다.
이해가 새로운 병목이다 — AI가 코드를 다 짜는 시대, 인간에게 남은 진짜 일
AI 에이전트가 코드를 초당 수백 줄씩 쏟아낸다. 생성은 공짜가 됐고, 검증도 점점 자동화된다. 그런데 병목 하나가 조용히 남았다 — 사람이 그걸 아직 이해하고 있는가? Geoffrey Litt의 2026년 7월 에세이 「Understanding is the new bottleneck」을 축으로, 왜 '이해'가 새로운 병목이 됐는지 파헤친다. 앨런 케이의 50년 전 꿈부터 페퍼트의 '매쓰랜드', 마투셰크의 간격 반복 퀴즈, 스토리 교수의 '인지 부채(cognitive debt)'까지 — 개념의 뿌리를 쉽게 따라가고, /explain-diff·마이크로월드·공유 공간이라는 세 가지 무기를 사례로 만난다. 마지막엔 독자가 직접 '이해 게이트'를 통과해 본다. '루프 밖으로 나가는 게 아니라, 더 깊이 루프 안으로.'
버그를 찾겠다는 착각: 코드 리뷰의 진짜 목적, 1976에서 2026까지
한 수학자의 마스토돈 글 한 줄이 개발자 타임라인을 뒤흔들었다. '코드 리뷰의 목적은 버그를 찾는 게 아니다. 유지보수하기 어려운 코드를 찾는 것이다.' 왜 이 말이 375점짜리 논쟁이 됐을까? 1971년 와인버그의 '에고 없는 프로그래밍', 1976년 Fagan 인스펙션, 그리고 2013년 마이크로소프트가 570개 리뷰 코멘트를 직접 세어 밝혀낸 충격적 반전 — '기대 1위는 버그였지만, 실제 코멘트의 14%만이 버그였다'. 여기에 2026년, AI가 버그를 잡기 시작하면서 사람의 역할이 어디로 이동하는지까지. 용어가 생소해도 그림과 사례로 끝까지 쉽게 읽는 특집.