#코드 리뷰
7개의 포스트
![[특집] AI가 코드를 쓸수록 설계가 중요해진다 — 「도메인 주도 설계는 AI가 코드를 쓸 때 더 중요해진다」 완전 해부](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Fddd-cover.webp&w=3840&q=75)
[특집] AI가 코드를 쓸수록 설계가 중요해진다 — 「도메인 주도 설계는 AI가 코드를 쓸 때 더 중요해진다」 완전 해부
2026년 8월 20일, 폴란드의 Go 백엔드 교육 회사 스리 닷 랩스의 공동창업자 미워시 스몰카가 올린 에세이 한 편이 두 달에 걸쳐 조용히 퍼졌다. 주장은 단순하다 — '에이전트를 어떻게 설정하고 어떤 LLM을 쓰는지는 해법에 대한 명확한 정신 모델만큼 중요하지 않다. 둘 중 하나를 골라야 한다면 나는 생각을 건너뛰느니 코드를 한 줄도 직접 쓰지 않겠다.' 이 글은 그 주장을 끝까지 파고든다. 2003년 에릭 에반스의 '파란 책'이 왜 나왔고 지식 탐구·유비쿼터스 언어·바운디드 컨텍스트가 정확히 무엇을 뜻하는지, 1985년 피터 나우르의 '이론 만들기'부터 2026년 OpenAI의 하니스 엔지니어링까지 어떤 계보 위에 서 있는지, 월 1달러를 아낀 에이전트 일화가 왜 팀 커뮤니케이션의 축소판인지, 그리고 Faros·METR·GitClear·LinearB의 2025~2026년 데이터가 '쓰기가 싸지자 읽기가 비싸졌다'를 어떻게 증명하는지를 사례와 함께 풀었다. 본 버논의 '에이전트는 아직 도메인 모델을 못 만든다'는 증언, 에반스의 2026년 기조연설, 네이버·카카오·삼성·토스의 AI 코딩 도입과 GeekNews의 차가운 반응까지 — 다섯 개의 인터랙티브 도구로 2026년 가을 한국의 독자가 이 글에서 가져갈 것을 정리했다.
에이전트 여럿, 저장소 하나 5편 — 두 에이전트에게 같은 일 시키고 좋은 것만 합치기
같은 기능을 Claude Code와 Codex에게 각자의 worktree·브랜치에서 동시에 맡기고, git log·diff A...B·range-diff·같은 테스트로 두 결과를 비교한 뒤 좋은 부분만 골라 합치는 법을 실제 출력으로 따라갑니다. 통째로 채택(squash), 커밋만 가져오기(cherry-pick -x), 파일 하나 가져오기(restore --source), 세 번째 에이전트에게 합치기를 맡기는 법과 뒷정리, 그리고 이 방법이 오히려 손해인 경우까지 다룹니다.
Git, 이것만 알면 협업한다 6편 — Pull Request로 함께 일하기
혼자 쓰던 git을 팀의 도구로 바꾸는 마지막 한 걸음, Pull Request. 브랜치를 만들어 push하고, PR을 열고, 리뷰를 주고받고, 세 가지 머지 버튼 중 하나로 main에 합치는 GitHub Flow 한 바퀴를 민지와 도윤의 카페 웹사이트로 따라가 봅니다. 머지 방식마다 역사가 어떻게 달라지는지는 로컬에서 직접 재현해 확인합니다.
AI 맹목(AI-Blindness) — 뇌가 AI 문서를 광고처럼 건너뛰기 시작했다
2026년 8월, 한 엔지니어가 '나는 AI 맹목이 되어가고 있다'는 짧은 글을 올렸고 해커뉴스에서 228개의 댓글이 붙었다. 1998년의 '배너 블라인드니스'가 광고를 안 보이게 만들었듯, 이제 우리의 뇌는 AI 특유의 냄새가 나는 문서를 자동으로 건너뛴다. 문제는 그 문서 중에 진짜 읽어야 할 것이 섞여 있다는 점이다. 이 글은 이 개념이 왜 나왔는지, 워크슬롭·AI 슬롭·curl 버그바운티 종료·GitHub PR 킬스위치 같은 사례가 무엇을 말하는지, 그리고 AI를 써서 글을 쓰는 사람과 그것을 읽어야 하는 사람이 각각 무엇을 해야 하는지를 정리한다.
코드를 보지 마라, 아이디어를 잡아라 — 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가 버그를 잡기 시작하면서 사람의 역할이 어디로 이동하는지까지. 용어가 생소해도 그림과 사례로 끝까지 쉽게 읽는 특집.