브룩스의 법칙은 AI 시대에도 유효하다. "요구사항 불명확하면 에이전트를 더해도 틀린 답을 빨리 얻을 뿐"

혼자 개발하는 입장에서 브룩스 법칙이 아직 유효한 부분은 타이핑이 아니라 조율과 이해에 드는 비용이야. AI는 코드 생산을 싸게 만들었지만 리뷰하고 설계 일관성 유지하고 왜 그렇게 했는지 기억하는 건 여전히 집중력을 잡아먹더라. 테스트 붙은 작고 명확한 작업은 잘 되는데 여러 파일을 건드리는 열린 변경은 리뷰 노동이 늘어서 속도 이득이 상쇄됨.

오히려 집중력이 더 드는 것 같아. 밧줄이 팽팽하게 당겨져서 가운데가 풀리는 기분임. 짧게는 재밌고 중독적인데 길게 보면 인지적으로 녹초가 돼.

지금 이 도구를 제일 잘 쓰는 방법은 코드를 아예 안 읽는 것 같기도 해. 모델이 짜고 모델이 리뷰하고 사람은 질문하고 방향만 잡는 식. Claude Code에 코드 에디터가 없는 게 일부러라는 얘도 있는데 지속 가능한지는 모르겠음.

요구사항이 불명확하면 틀린 답을 더 빨리 얻는다는 말은, 틀린 답을 그렇게 빨리 얻을 수 있어서 오히려 요구사항을 파악하는 최선의 방법이 됐다는 뜻이지.

그게 성립하려면 검증 비용이 아주 싸고 틀린 답에서 정답을 추론할 수 있어야 하는데 항상 그렇진 않아. 어떤 접근의 치명적 결함은 한참 지나야 보이고, 실패한 시도가 쌓여도 정답이 저절로 보이진 않아서 결국 생각은 필요함.

빈 종이랑 한 시간에 $4어치 토큰으로 한 방에 뽑은, 20군데가 명백히 틀린 POC 중에 뭐가 요구사항 목록 뽑기엔 더 나은 출발점일까?

AI를 발견용 인터페이스로 쓰자는 얘기에 동의해. 기능을 심어두고 MCP로 사용자가 쓰게 하면서 실제 흐름을 파악하고 나서 만드는 순서가 맞는 것 같음.

생각을 끄면 얘기가 달라져. 며칠 굴려서 기능 하나 건졌는데 원래 만들어야 할 게 아니었던 적도 있고, 아무도 이해 못 하는 대규모 리팩터링이 남기도 함. 예전처럼 미리 어떻게 엮일지 고민했으면 눈치챘을 문제임.

그건 옛날의 Build One To Throw Away를 현대적으로 다시 말한 것뿐인 것 같아. 프로토타입을 자유롭게 던져볼 수 있게 된 건 진짜 좋아졌으니 거기에 테스트를 잔뜩 붙여서 엣지 케이스를 끌어내면 됨.

틀린 답인 걸 모를 때가 문제지. 1930년대 루마니아 사진 속 인물을 물었더니 Gemini가 이온 안토네스쿠라고 확신 있게 답하고, 아니라고 하니까 마노일레스쿠라고 또 확신 있게 답하더라. 구글로 마노일레스쿠 사진을 찾아보니 그것도 틀렸음. AI는 정보 엔트로피의 큰 새 공급원임.

출력량이 너무 많아서 검토가 안 됨. 설계 질문 하나에 모델이 대안 2~3개를 내놓고 조금 더 물으면 30페이지짜리 문서가 나옴.

프로토타입으로 요구사항 잡는 건 좋은데 그 POC가 요구사항을 만족한 것처럼 출시되는 게 문제라는 데 동의해. 사람 손을 두 번 거쳐야 함. 계획과 인수 조건 승인, 그리고 계획 대비 확인.

AI 이전부터 있던 안티패턴임. 테스터 주도 개발이라고, 제대로 고치는 대신 아무거나 바꿔서 통과할 때까지 돌리는 식. AI가 그 과정을 훨씬 빠르게 만들 뿐 똑같이 틀림.

아홉 에이전트가 한 달에 아기를 못 만든다는 비유는 좀 이상하지 않아? 임신은 원래 기간이 정해진 생물학적 현상인데 그게 AI에 어떻게 적용됨? 에이전트가 뭔지부터, 왜 에이전트를 사람으로 가정하는지 모르겠음.

원래 문장은 '아홉 명의 여자가 한 달에 아기를 낳을 수는 없다'였고, 요점은 인력이 늘면 조율 오버헤드가 커지고 병렬화가 안 되는 작업엔 의존성이 생긴다는 거야. 개인 프로젝트에서만 써봤는데 여러 에이전트에 작업을 명시적으로 쪼개 조율시키는 게 단일 에이전트보다 빠르다고는 못 하겠더라. 요즘 하네스는 알아서 서브에이전트를 띄우기도 하고.