11 원리의 재발견

방법론 아래에는 원리가 있다. 추상화와 정보 은닉, 기술 부채, 조직과 시스템 구조의 동형성, 본질적 복잡성과 우연적 복잡성, 그리고 사람과 시간의 교환 법칙. 반세기 전의 논문들이 컨텍스트 윈도와 에이전트의 시대에 어떻게 다시 읽히는지가 이 장의 내용이다.

11.1 추상화와 정보 은닉: Parnas가 옳았던 이유, 다시

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Parnas(1972)의 정보 은닉 기준, 즉 모듈을 기능이 아니라 변경될 가능성이 있는 결정을 기준으로 나눠야 한다는 논거를 컨텍스트 창이 유한한 AI 에이전트 시대의 코드베이스 설계와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Parnas 원논문이 비교한 두 가지 모듈 분해 방식을 정확히 읽는다. 다음으로 AI 에이전트가 코드를 다루는 방식이 이 기준을 다시 요구하는 사례를 모은다. 마지막으로 사람의 인지 한계를 위해 고안된 원칙이 모델의 컨텍스트 한계를 위해서도 같은 형태로 유효한지 논증한다.

시드 질문

Parnas(1972)가 논문에서 비교한 두 가지 모듈 분해 방식, 즉 흐름도 기준 분해와 정보 은닉 기준 분해는 정확히 어떤 예제로 제시되었나? (원전 확인)
Parnas가 정보 은닉의 근거로 든 것은 변경 용이성이었고 이는 사람 프로그래머의 인지 부담을 줄이기 위한 논거였다. 이 논거가 컨텍스트 창이 유한한 AI 에이전트에게도 그대로 적용되는가, 아니면 에이전트의 한계는 성격이 달라 다른 분해 기준이 필요한가? (원전 확인)
에이전트 코딩 도구의 공식 문서나 실무 가이드가 에이전트가 다루기 좋은 코드베이스 구조를 명시적으로 권장하는 사례가 있는가, 있다면 그것이 Parnas의 정보 은닉 기준과 얼마나 겹치는가? (재발견 사례 수집)
AI 친화적 리포지토리 구조를 표방하는 리팩토링 사례나 논의(작은 파일, 명확한 파일명, 순수 함수 선호 등)를 얼마나 찾을 수 있는가? (재발견 사례 수집)
Parnas 이후 발전한 다른 모듈화 원칙(응집도와 결합도, SOLID 등)과 비교했을 때, AI 시대의 재발견이 정보 은닉 하나에 집중되는 이유는 무엇인가?
컨텍스트 엔지니어링(이 책 §3.2)에서 말하는 무엇을 보여줄 것인가의 문제와 Parnas의 모듈 경계 문제는 같은 문제의 다른 이름인가, 다른 문제인가?

조사 포인터

Parnas, “On the Criteria to Be Used in Decomposing Systems into Modules”(1972) 원문
이 책 §3.2(컨텍스트 엔지니어링), §5.3(컨텍스트 관리의 기술)과의 접점, 중복 서술 피할 것
에이전트 코딩 도구의 리포지토리 구조 권장 가이드(공식 문서, 엔지니어링 블로그)
응집도와 결합도 등 이후 모듈화 이론과의 비교 자료

11.2 기술 부채: 은유가 이자율을 만났을 때

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Cunningham이 OOPSLA 1992 experience report에서 처음 쓴 기술 부채 은유의 원래 의미를 생성 속도가 부채 누적 속도를 크게 높인 AI 코딩 시대의 재소환 사례와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Cunningham의 원래 발언과 이후 은유가 오용되어 온 경위를 정확히 읽는다. 다음으로 AI 시대의 부채 관련 논의, 생성 코드의 유지보수 비용을 다룬 실증 조사를 사례로 모은다. 마지막으로 의도적이고 상환 계획이 있는 부채와 무분별한 부채라는 원래 은유의 구분이 AI 생성 코드에도 적용 가능한지 논증한다.

시드 질문

Cunningham이 1992년 OOPSLA experience report에서 실제로 사용한 표현과 맥락은 정확히 무엇이었나, 그가 나중에 이 은유의 오용에 대해 언급한 적이 있다면 그 내용은 무엇인가? (원전 확인)
Cunningham의 원래 논지는 빚을 지는 것 자체가 나쁘다는 것이 아니라 빚을 인식하고 상환 계획을 세워야 한다는 것에 가까웠는데, 이 조건부적 성격이 오늘날 기술 부채라는 말이 쓰이는 방식에서 얼마나 유지되고 있는가? (원전 확인)
AI가 빠르게 생성한 코드에 대해 기술 부채가 크게 늘고 있다는 주장을 실증적으로 뒷받침하는 조사나 데이터가 존재하는가? (재발견 사례 수집)
이자율 은유를 문자 그대로 확장해서 AI 생성 코드의 이자율을 정량적으로 논의한 사례가 있는가, 있다면 무엇을 측정 지표로 삼았는가? (재발견 사례 수집)
부채를 의도적으로 지는 경우(빠른 프로토타이핑을 위해)와 무분별하게 지는 경우(검증 없이 AI 출력을 그대로 반영)의 구분이 AI 코딩 워크플로에서 실제로 관찰되는가?
기술 부채 개념이 정량화 시도(부채 지표, 정적 분석 도구류)를 거쳐온 역사가 있는데, AI 생성 코드에 대해서도 유사한 정량화 시도가 있는가?

조사 포인터

Cunningham의 OOPSLA 1992 experience report 원문(정확한 제목과 인용은 확인할 것)
Cunningham 본인의 이후 인터뷰에서 은유의 오용에 대한 코멘트가 있는지 확인
이 책 §9.3(품질 부채와 유지보수)과 역할 분담. 그 꼭지는 현재 실태에, 이 꼭지는 은유 자체의 역사와 재소환에 집중
AI 생성 코드 유지보수 비용에 관한 최근 실증 연구나 업계 보고서

11.3 Conway의 법칙과 인간-AI 조직

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Conway(1968)의 원논문이 제시한 명제, 즉 시스템 설계가 그것을 만든 조직의 소통 구조를 반영한다는 관찰을 사람과 에이전트가 뒤섞인 조직의 코드 구조와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Conway 원논문의 정확한 주장과 근거를 읽는다. 다음으로 사람과 AI가 혼합된 조직의 코드 구조 관련 사례를 모은다. 마지막으로 Conway가 전제한 소통 비용이라는 메커니즘이 사람과 근본적으로 다른 행위자인 AI 에이전트에게도 같은 방식으로 작동하는지 논증한다.

시드 질문

Conway가 1968년 논문에서 실제로 사용한 사례와 논증, 즉 위원회의 설계 산출물이 위원회 자신의 구조를 닮는다는 관찰은 정확히 무엇이었나? (원전 확인)
Conway의 법칙이라는 이름과 역 Conway 전략(원하는 아키텍처에 맞게 조직을 먼저 설계하는 전략)이라는 표현은 Conway 본인이 만든 것인가, 후대에 붙여진 것인가? (원전 확인)
한 사람이 여러 에이전트를 동시에 지휘하는 작업 구조에서, 조직 구조가 코드 구조를 닮는다는 명제는 무엇을 닮는다고 봐야 하는가, 지휘자 1인의 인지 구조인가 에이전트들의 통신 프로토콜인가?
멀티에이전트 시스템을 운용하는 조직에서 역 Conway 전략을 의도적으로 적용한 사례, 즉 원하는 소프트웨어 아키텍처를 얻기 위해 에이전트 조직 구조를 먼저 설계한 사례가 보고된 적이 있는가? (재발견 사례 수집)
Conway의 법칙이 성립하는 메커니즘으로 흔히 꼽히는 소통 비용은 사람 사이에서는 회의와 문서화와 신뢰 형성으로 이루어지는데, 에이전트 사이의 소통 비용은 무엇으로 구성되며 이것이 법칙의 성립 여부를 바꾸는가?
멀티에이전트 프레임워크의 설계 자체가 이미 Conway의 법칙을 의식하고 있는가, 즉 도구 설계자들이 이 법칙을 인용하며 아키텍처를 정당화한 사례가 있는가? (재발견 사례 수집)

조사 포인터

Conway, “How Do Committees Invent?”(1968) 원논문(원 게재지 확인)
역 Conway 전략 용어의 출처(Conway 본인인지 후대 정리자인지 확인)
멀티에이전트 코딩 시스템 설계 문서, 실무자들의 에이전트 조직 운용 후기
이 책 14장(일의 재구성) 관련 꼭지와의 접점, 역할 중복 피할 것

11.4 No Silver Bullet, 다시 읽기

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Brooks(1986)가 제시한 본질적 복잡성과 우연적 복잡성의 구분, 그리고 생산성을 10배 높일 단일 기술은 없다는 주장을 LLM 코딩 도구가 실제로 어느 쪽 복잡성을 줄이는지와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Brooks 원논문의 두 복잡성 구분과 그가 검토한 유망 기법들에 대한 평가를 정확히 읽는다. 다음으로 LLM 코딩 도구의 생산성 관련 실증 연구를 사례로 모은다. 마지막으로 Brooks가 은총알이 아니라고 판단한 근거가 LLM에도 그대로 적용되는지, 아니면 LLM이 그가 상상하지 못한 종류의 해법인지 논증한다.

시드 질문

Brooks가 “No Silver Bullet”(1986)에서 구분한 본질적 복잡성과 우연적 복잡성의 정확한 정의는 무엇이었나, 각각의 예로 든 것은 무엇이었나? (원전 확인)
Brooks는 논문에서 이미 인공지능을 은총알 후보로 검토하고 기각했는데, 그가 기각한 근거는 정확히 무엇이었나, 그 근거는 오늘날의 LLM에도 여전히 유효한가? (원전 확인)
LLM 코딩 도구의 생산성 향상을 측정한 실증 연구는 그 향상이 본질적 복잡성을 줄인 것인지 우연적 복잡성(타이핑, 문법, 보일러플레이트)을 줄인 것인지 구분해서 보고하는가? (재발견 사례 수집)
LLM이 마침내 은총알이라는 취지의 주장과, LLM도 결국 우연적 복잡성만 줄일 뿐이라는 반론이 실제로 맞서고 있는가, 있다면 각각의 핵심 논거는 무엇인가? (재발견 사례 수집)
Brooks가 은총알이 없다고 결론 내린 이유 중 하나는 소프트웨어의 본질적 어려움(복잡성, 정합성, 변경 가능성, 비가시성)이 표현 형식을 바꿔도 사라지지 않는다는 것이었는데, 자연어 프롬프트라는 새 표현 형식이 이 네 어려움 중 어느 것을 실제로 줄이는가?
Brooks 본인이 이후 인터뷰나 후기 저작에서 자신의 1986년 예측을 되짚어본 발언이 있는가, 있다면 무엇을 재확인하거나 수정했는가?

조사 포인터

Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering”(1986) 원문
본질적 복잡성과 우연적 복잡성 구분을 다룬 이후 소프트웨어 공학 문헌
LLM 코딩 생산성에 관한 실증 연구(기업 및 학계 조사)
이 책 4장(기회와 포텐셜), 8장(작동 원리)과의 접점, 이 꼭지는 Brooks의 프레임을 통한 재평가에 집중

11.5 Mythical Man-Month: 사람-월에서 에이전트-시간으로

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Brooks(1975)의 핵심 법칙, 즉 지연된 프로젝트에 인력을 추가하면 더 늦어진다는 주장과 그 근거를 에이전트를 추가로 병렬 투입하는 최근 실무와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Brooks의 법칙과 의사소통 오버헤드 근거를 원전에서 정확히 읽는다. 다음으로 여러 에이전트를 동시에 돌리는 병렬 운용 사례를 모은다. 마지막으로 사람을 추가하는 것과 에이전트를 추가하는 것이 의사소통 오버헤드라는 메커니즘 면에서 같은지 다른지 논증한다.

시드 질문

Brooks(1975)가 지연된 프로젝트에 인력을 추가하면 더 늦어진다는 법칙을 도출한 정확한 논증은 무엇이었나, 특히 의사소통 경로 수가 인원수의 어떤 함수로 증가한다고 계산했나? (원전 확인)
Brooks의 논증은 신참 훈련 비용과 작업이 순차적으로 분할되지 않는 어려움도 근거로 들었는데, 이 두 근거 각각이 에이전트를 추가로 투입하는 상황에는 어떻게 적용되거나 적용되지 않는가? (원전 확인)
여러 에이전트를 병렬로 동시에 돌려 같은 프로젝트의 다른 부분을 각각 맡기는 방식이 실제로 전체 완료 시간을 줄이는지, 아니면 사람의 조정 비용으로 상쇄되는지에 대한 사례나 보고가 있는가? (재발견 사례 수집)
Brooks의 법칙이 성립하는 핵심 메커니즘이 사람 사이의 의사소통 오버헤드라면, 에이전트 사이에는 이에 대응하는 오버헤드가 존재하는가, 존재한다면 무엇으로 측정되는가(토큰 비용, 컨텍스트 공유 실패, 충돌하는 변경 등)?
Brooks의 법칙이 에이전트에는 적용되지 않는다거나 반대로 그대로 적용된다고 명시적으로 주장하는 실무자나 연구자의 글이 존재하는가? (재발견 사례 수집)
Brooks가 같은 책에서 함께 제시한 외과 수술팀 모델과 개념적 무결성의 중요성은 에이전트 오케스트레이션 논의에서 어떻게 재조명되는가?

조사 포인터

Brooks, “The Mythical Man-Month”(1975) 원문(해당 장 확인)
멀티에이전트 병렬 코딩 운용에 관한 실무자 글, 도구 문서(병렬 서브에이전트, 여러 워크트리 동시 운용 등)
이 책 §8.2(에이전트 해부학)와의 접점, 역할 중복 피할 것