AI 시대에 소프트웨어 기본기가 중요한 이유를 엉클 밥에게 물었습니다

URL: https://www.youtube.com/watch?v=IyJNc5vpN1Q 날짜: 2026-08-21 채널: Tech Bridge 원문 제목: [한영자막] AI 시대에 소프트웨어 기본기가 중요한 이유를 엉클 밥에게 물었습니다

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 전술적 코딩을 빠르게 수행해도, 소프트웨어 기본기는 복잡성을 사람이 이해하고 에이전트가 다룰 수 있는 구조로 조직하는 유일한 기반이므로 사라지지 않는다.==

• 에이전트는 빠르지만 지저분한 코드가 누적되면 사람과 마찬가지로 혼란에 빠지고, 수정 과정에서 다른 부분을 깨뜨리며 제자리걸음을 한다.
• 긴 규칙 프롬프트는 컨텍스트 윈도우(Context Window)의 ‘중간에서 잊히는 현상(lost in the middle)’ 때문에 약해지므로, 짧은 초기 지시와 결정론적 자동 검사(Deterministic Checks)를 결합해야 한다.
• 테스트, CRAP 분석, 변이 테스트(Mutation Testing), 모듈 의존성 검사, UI 기반 QA를 연쇄적으로 통과시키면 에이전트의 속도를 유지하면서 품질을 높일 수 있다.
• 인간의 개발 규율을 그대로 강제하기보다 인간의 품질 가치와 설계 원칙을 유지하되, 에이전트의 메모리·속도에 맞춰 복잡도 임계값과 작업 순서를 조정해야 한다.

소프트웨어는 인간이 시도한 일 가운데 가장 복잡한 대상이며, 기본기는 그 복잡성을 인간과 모델이 함께 파악할 수 있는 형태로 정리하는 방법이다. 에이전트는 구현 같은 전술적 작업(Tactical Programming)에 강하지만 전략적 프로그래밍(Strategic Programming), 즉 무엇을 만들고 어떻게 나눌지 결정하는 일에는 약하다. 따라서 개발자는 코드를 완전히 포기하는 대신, 직접 코드를 작성하고 에이전트가 고생하는 모습을 판별할 수 있는 감각을 익힌 뒤, 구조·검증·피드백을 설계하는 전략가로 역할을 옮겨야 한다.

1. 목욕 가운을 입은 ‘엉클 밥’과 60년 프로그래밍의 출발점

소프트웨어 기본기에 대한 주장은 Robert C. Martin(“Uncle Bob”)의 오랜 실무 경험과 유머 섞인 일화에서 출발한다.

1.1. 아침 목욕 가운 호통의 탄생

1. SQL 인젝션을 걱정한 오전 6시
   1. 약 2년 전, Bob은 오전 6시에 집 현관 앞 목욕 가운 차림으로 있다가 SQL이 끔찍하다고 생각했다.
   2. SQL Injection이 반복되는 상황에서 데이터베이스 접근에 텍스트 언어를 사용하는 것이 보안상 말이 되지 않는다고 느꼈다.
   3. 휴대전화로 즉석에서 분노 섞인 독백을 녹화했고, 이 짧은 영상이 ‘Morning Bathrobe Rant’가 됐다.
   4. 반응이 좋아 몇 차례 더 이어졌고, 목욕 가운은 Bob의 캐릭터가 됐다.
2. 현재의 목욕 가운 농담
   1. Bob은 이 대화가 이른 아침이라 커피를 마시기 전에는 건드리지 말라는 농담을 했다.
   2. 실제 촬영 시각은 오전 10시였고, 커피를 마신 뒤 첫 번째 Diet Coke를 마시는 상태라 괜찮다고 답했다.
   3. 셔츠를 입고 나온 상태를 두고 “이제 목욕 가운은 벗었다”는 식의 농담이 오갔다.

1.2. 12세의 3비트 컴퓨터에서 반세기 경력으로

1. 최초의 프로그램
   1. Bob은 1964년, 12세 때 처음 프로그램을 작성했다.
   2. 어머니가 생일 선물로 사 준 작은 모형 컴퓨터에 흰색 튜브를 말뚝에 꽂아 프로그램하는 방식이었다.
   3. 본질적으로 3비트 유한 상태 머신(Finite State Machine)이었지만, 12세의 Bob을 강하게 매료시켰다.
2. 기계 없이도 계속한 학습
   1. 아버지가 Fortran, COBOL, PL/I 책을 사 주었고 Bob은 모두 읽었다.
   2. 실행할 기계가 없었기 때문에 종이에 프로그램을 쓰고 머릿속으로 실행했다.
   3. 16세에 소량의 코드를 작성하는 일을 처음 얻었고, 18세에 정식 직장을 얻은 뒤 계속 프로그래머로 일했다.
   4. 프로그래밍 경력은 반세기를 넘어섰고, 최초의 프로그래밍 경험보다 개발자가 된 기간이 더 짧을 정도로 소프트웨어를 오래 다뤘다.

1.3. 《Clean Code》가 만든 영향력

1. 가장 자주 인용되는 소프트웨어 공학서
   1. Bob은 여러 권의 책을 썼지만 그중 하나가 특히 큰 반응을 얻었다고 겸손하게 말했다.
   2. 진행자가 들어 올린 책은 《Clean Code》 2판이었다.
   3. 소프트웨어 공학에서 좋은 책을 논할 때 가장 자주 인용되고 되돌아오는 책이며, 매우 큰 영향력을 행사했다는 평가를 받았다.
2. AI 이전 시대와 AI 시대의 연결
   1. Bob은 AI 이전 시대에 Clean Code와 테스트 중심의 규율을 발전시켰고, AI가 등장한 뒤에는 그 원칙을 에이전트 작업에 적용하고 있다.
   2. 핵심 질문은 AI가 기본기를 대체하는가가 아니라, 기본기를 에이전트의 속도와 작업 방식에 맞춰 어떻게 활용하는가이다.

2. 에이전트를 처음 만났을 때 발견한 속도와 ‘개똥(dog doo)’

AI 에이전트의 빠른 구현 능력은 기존에 사람이 감당하지 못했던 품질 검사를 현실적인 선택으로 바꿨지만, 지저분한 코드의 누적 문제는 그대로 남았다.

2.1. Grok에서 시작한 실험

1. 처음에는 감탄하지 못한 모델들
   1. Bob은 2025년 12월 크리스마스 무렵부터 AI를 본격적으로 만지기 시작했다.
   2. ChatGPT와 여러 모델을 이미 조금씩 써 봤지만 처음에는 특별히 인상적이지 않았다.
   3. 이후 AI가 생각보다 흥미로울 수 있다고 느꼈고, 초창기 Grok 에이전트를 처음으로 프로젝트에 투입했다.
2. 빠르지만 나를 느리게 만드는 에이전트
   1. Grok에게 코드를 작성하게 했고, 결과는 서툴렀지만 실제 코드가 나왔다.
   2. 진행 중인 프로젝트를 함께 작업하게 하자 에이전트는 빠르게 결과를 만들었다.
   3. 그러나 매번 뒤처리를 해야 했고, 코드 곳곳에 작은 ‘개똥’과 보풀이 남았다.
   4. Bob은 에이전트가 빠르지만 자신을 느리게 만든다는 역설을 발견했다.

2.2. 지저분한 코드가 에이전트를 멈추게 하는 과정

1. 문제를 미룰수록 더 커지는 지저분함
   1. 한 작업이 끝난 뒤 남은 엉망을 정리하지 않고 다음 작업을 시키면 더 많은 엉망이 쌓였다.
   2. 코드가 복잡해질수록 에이전트의 속도가 느려지고, 처리하기 어려워졌다.
2. 수정이 수정을 낳는 제자리걸음
   1. 에이전트가 한 가지를 바꾸면서 다른 부분을 우연히 깨뜨렸다.
   2. 깨진 부분을 고치다가 또 다른 부분을 깨뜨리는 순환이 반복됐다.
   3. 빠르고 꽤 똑똑한 에이전트도 지저분한 코드에 취약하며, 임계점을 넘으면 더 이상 코드를 다루지 못한다.
   4. 실제로 한 에이전트가 더는 감당하지 못하고 포기한 것처럼 행동한 사례도 있었다.
3. 품질 문제는 속도 문제가 아니라 처리 가능성의 문제
   1. 버그가 즉시 눈에 보이지 않아도 코드가 복잡해지면 에이전트의 판단 경로가 흐려진다.
   2. 따라서 ‘빨리 만들고 버그가 사라질 때까지 밀어붙이기’는 장기적으로 속도를 잃는 전략이다.

2.3. 과거에는 비현실적이었던 검사를 에이전트에게 맡기다

1. CRAP 분석(CRAP Analysis)
   1. 2000년대 초 Bob은 코드 커버리지(Code Coverage)와 각 함수의 순환 복잡도(Cyclomatic Complexity)를 결합해 함수가 얼마나 위험하거나 형편없는지 점수화하는 CRAP 분석을 접했다.
   2. 큰 프로젝트에 적용하자 문제가 많은 함수가 다수 드러났다.
   3. 그러나 모든 함수를 고치고 테스트를 다시 작성하는 데 너무 오래 걸렸고, 기존 기능이 작동하고 있었기 때문에 정상 빌드 과정에 넣기 어려웠다.
2. 변이 테스트(Mutation Testing)
   1. 변이 테스트 도구는 소스 코드의 부호와 비교 연산자를 의도적으로 바꾼다.
   2. 음수 부호를 양수로, less-than을 greater-than으로, equal을 not-equal로 바꾸는 식이다.
   3. 각 변이에 전체 테스트 스위트를 실행하고 테스트가 실패해야 변이를 죽인 것으로 본다.
   4. 테스트가 실패하지 않으면 살아남은 변이(Surviving Mutant)이며, 테스트가 놓친 구멍이므로 추가 검증이 필요하다.
3. AI가 바꾼 현실성
   1. Bob은 2000년 무렵 같은 프로젝트에 변이 테스트를 돌렸고, 테스트 스위트가 4분 걸리는 상태에서 수백 번 실행해야 해 밤새 기다렸다.
   2. 살아남은 변이를 찾아 고칠 수 있었지만 일반적인 빌드 흐름에 넣기에는 여전히 비현실적이었다.
   3. 에이전트는 지루한 작업을 싫증 내지 않고 지시받은 대로 빠르게 반복한다.
   4. 최근에는 과거에 밤새 걸리던 변이 테스트를 약 30분에 끝내고, 빠진 테스트를 보완하게 할 수 있었다.
   5. 에이전트가 남긴 ‘개똥’을 자동 검사와 수정 루프로 정리하는 일이 가능해졌다.

3. 짧은 지시와 결정론적 도구로 에이전트를 가두기

에이전트의 품질은 긴 훈계보다 짧은 핵심 지시와 결과를 판정하는 자동 검사의 조합에서 나온다.

3.1. 규칙을 프롬프트에 쌓는 방식의 한계

1. 초기에는 사람이 직접 조종했다
   1. Bob도 처음에는 “테스트 주도 개발(Test-Driven Development)을 이렇게 하라”, “Clean Code를 지켜라”, “코드는 이 규칙을 따라야 한다” 같은 프롬프트를 작성했다.
   2. 결국 좋은 코드에 대한 설명이 5~10쪽짜리 문서로 늘어났고, Clean Code 책 전체를 넣고 싶은 유혹도 생겼다.
2. 규칙은 ‘해적의 지침’처럼 취급된다
   1. 모델은 긴 규칙을 절대적인 법이 아니라 《캐리비안의 해적》에 나오는 ‘규칙이라기보다 지침(guidelines)’처럼 다루는 경향이 있다.
   2. 규칙이 많아질수록 일부는 부드럽게 무시되며, 프롬프트가 길다고 준수도가 선형으로 올라가지 않는다.

3.2. Lost in the Middle과 초기 프롬프트 최소화

1. 컨텍스트 중간이 희미해지는 현상
   1. 모델의 컨텍스트 윈도우가 길어지면 맨 앞과 맨 끝의 정보가 중간보다 더 큰 주목을 받는다.
   2. 긴 지시의 50번째나 80번째 문장은 컨텍스트의 중간에 묻혀 사실상 사라질 수 있다.
   3. 처음에 넣은 규칙도 문서가 길어지면 중간으로 밀려나며, 모델은 계속 커지는 맥락에서 중요한 부분을 추출해야 한다.
2. ‘스마트 구역’과 ‘멍청한 구역’
   1. 컨텍스트 초반, 특히 첫 15만 토큰 정도는 상대적으로 똑똑한 ‘스마트 구역’처럼 작동한다.
   2. 토큰이 늘어나면 트랜스포머(Transformer)의 주의집중 관계가 희석되고, 모든 토큰이 붐비는 방에서 소리치는 것처럼 신호와 잡음을 구분하기 어려워진다.
3. 실행 원칙
   1. 초기 프롬프트를 절대적인 최소량으로 줄여 우선순위 영역에 최대한 보존한다.
   2. 나머지 품질 규칙은 컨텍스트 속 문장이 아니라 코드 실행 후 결과를 판정하는 결정론적 도구로 옮긴다.
   3. 결정론적 도구는 컨텍스트에 들어간 지시처럼 중간에서 잊히지 않으며, 실패 시 에이전트가 수정하도록 강제할 수 있다.

3.3. 품질과 생산성 사이의 임계점

1. 자동 검사도 무한히 추가할 수는 없다
   1. 에이전트에게 “검사가 통과할 때까지 코드를 바꿔라”고 하면 에이전트는 루프를 돌며 테스트 추가, 순환 복잡도 축소, 함수 분할을 반복한다.
   2. 검사가 많아지면 에이전트가 인간보다 느려질 수 있으므로, 어느 지점에서는 게임에서 이긴 것이 아니다.
2. 현재 관찰한 생산성 여유
   1. Bob은 결정론적 검사를 많이 붙여 속도를 늦춰도 인간보다 대략 2~4배 빠른 여유를 얻을 수 있다고 말했다.
   2. 더 높은 품질을 위해 생산성을 일부 희생하는 교환이 존재하며, 아직 품질과 속도의 최적 임계점을 찾지는 못했다.
3. 기본 목표
   1. 에이전트의 빠른 코드 생성 능력을 그대로 활용한다.
   2. 인간의 느린 코드 검토 속도를 에이전트에게 강요하지 않는다.
   3. 인간은 코드 한 줄 한 줄을 모두 읽는 대신 검사 점수, 테스트 결과, 구조적 규칙, 표본 검토로 전체 품질을 확인한다.

4. 여러 에이전트가 통과하는 구현 가우틀릿

Bob의 현재 방식은 한 에이전트에게 모든 역할을 맡기는 대신, 한정된 작업과 깨끗한 컨텍스트를 가진 여러 에이전트를 순서대로 통과시킨다.

4.1. 다중 에이전트의 이점과 비용

1. 병렬화
   1. 여러 코더 에이전트를 동시에 실행할 수 있다.
   2. Bob의 작은 노트북도 세 명보다 훨씬 많은 에이전트를 실행할 수 있다.
   3. 서로 독립적인 작업을 병렬 처리하면 전체 처리 시간을 줄일 수 있다.
2. 컨텍스트와 궤적을 작게 유지
   1. 각 에이전트가 하나의 작업에만 집중하면 Lost in the Middle 문제가 줄어든다.
   2. 에이전트를 작업하고 종료시키면 다음 에이전트가 깨끗한 컨텍스트 윈도우로 시작한다.
   3. 단점은 에이전트 하나가 시작하는 데 10~15초가 걸리고, 새 컨텍스트에서 전체 상황을 다시 파악해야 한다는 점이다.

4.2. Bob의 역할별 파이프라인

1. Specifier: 사람의 요구를 검증 가능한 문서로 변환
   1. Specifier는 사람이 쓴 요구 문서를 받아 Gherkin 문서와 QA 절차(QA Procedure)를 만든다.
   2. Gherkin은 Given-When-Then 형식의 높은 수준의 인수 테스트(Acceptance Test)다.
   3. QA 절차는 UI에서 실제 시스템을 조작하는 시스템 테스트(System Test)다.
   4. 문서는 개발자의 관점이 아니라 “당신은 UI를 조작하는 인간이며 시스템이 작동함을 증명해야 한다”는 인간 사용자의 관점으로 작성한다.
2. Coder: 동작을 만드는 구현 담당
   1. Coder는 단위 테스트(Unit Test)를 작성한다.
   2. 요구된 스토리를 구현하는 코드를 작성하고 Gherkin 시나리오도 통과시킨다.
   3. 구현자는 빠르게 동작하게 만드는 데 집중하므로, 최종 코드가 지저분해질 수 있다는 점을 전제로 한다.
3. Cleaner: CRAP 분석과 일반 코드 리뷰
   1. Cleaner는 CRAP 분석을 실행하고 일반적인 코드 리뷰를 수행한다.
   2. 구현자가 남긴 함수 복잡도, 중복, 보풀과 같은 문제를 정리한다.
   3. 구현자가 좋은 구조를 처음부터 만들 것이라고 기대하지 않고, 별도 단계로 청소 작업을 맡긴다.
4. Hardener: 변이 테스트를 통과시키는 품질 담당
   1. Hardener는 변이 테스트를 실행하며, Bob의 표현대로 “무자비한(merciless)” 역할을 한다.
   2. 100% 코드 커버리지를 확보하고, equal·less-than 같은 비교 연산을 변이시켜도 테스트가 모두 잡아내는지 확인한다.
   3. 살아남은 변이가 있으면 테스트를 보강해 빈틈을 막는다.
5. QA Agent: 실제 사용 흐름을 실행
   1. QA Agent는 Specifier가 작성한 QA 문서를 실행 가능한 스크립트로 바꾼다.
   2. 스크립트가 UI와 시스템을 조작하고, 결과를 결정론적으로 산출한다.
   3. 이 단계까지 통과하면 단위 수준의 코드뿐 아니라 사용자가 실제로 밟는 시스템 경로도 검증된다.

4.3. 시간 대비 품질 결과

1. 단일 에이전트와 가우틀릿 비교
   1. 단일 에이전트가 약 5분 동안 작업하면 결과가 나올 수 있지만, 품질은 의심스럽다.
   2. Specifier·Coder·Cleaner·Hardener·QA의 전체 파이프라인은 약 1시간이 걸린다.
   3. 사람이라면 같은 작업에 반나절 정도 걸릴 수 있으므로, 대략 4~5배 생산성 향상과 더 높은 품질을 동시에 얻는다.
2. 생산성을 앞당겨 투자하는 구조
   1. 구현 초기에 검사와 정리에 시간을 쓰는 것은 생산성을 잃는 일이 아니라 코드베이스에 투자하는 일이다.
   2. 깨끗한 구조와 강한 테스트가 이후의 변경 비용과 에이전트의 혼란을 줄여 더 큰 생산성을 만든다.

4.4. 컨텍스트 궤적과 커피·연속극 비유

1. 세션의 방향성이 누적된다
   1. 에이전트가 한 세션에서 특정 방식으로 유도되면 같은 컨텍스트 안의 이후 작업도 그 방향을 계속 따른다.
   2. 한 번 UI를 테스트해야 한다고 학습하면 이후 변경에서도 계속 UI 테스트를 시도하는 식으로 궤적(Trajectory)이 형성된다.
   3. 구현 에이전트와 100% 커버리지를 요구하는 Hardener는 서로 다른 목표와 궤적을 가지므로 분리하는 편이 낫다.
2. 커피와 연속극의 비유
   1. 커피의 종류와 추출법을 이야기하던 모델의 컨텍스트에 지나가던 사람이 최신 연속극 이야기를 끼워 넣으면 모델은 둘을 구분하지 못한다.
   2. 그 뒤부터 모든 커피 관련 답변이 연속극과 섞일 수 있다.
   3. 모델이 혼란스러운 정보 없이 한 방향으로만 나아가게 컨텍스트를 유지하면 환각(Hallucination)과 오정렬(Misalignment)이 줄어든다.
   4. 역할별 에이전트와 깨끗한 컨텍스트는 가우틀릿을 통과하는 동안 이런 혼선을 줄이는 장치다.

5. 모듈 구조와 깊은 모듈이 에이전트의 사고를 돕는 방식

강한 테스트만으로 잘못 설계된 API와 모듈 경계를 고칠 수 없으므로, Bob은 구조를 직접 관찰하고 결정론적으로 제한한다.

5.1. 에이전트에게 구조를 질문하고 직접 재설계한 과정

1. 자동 구현 뒤의 수동 심문
   1. 최근까지 Bob은 에이전트에게 시스템을 구현하게 한 뒤 “구조가 무엇인가”, “모듈끼리 어떻게 관계하는가”, “모듈은 대체 무엇인가”, “서로 어떻게 통신하는가”를 물었다.
   2. 답변은 매우 무서운 수준으로 뒤엉킨 경우가 많았다.
   3. Bob은 모듈을 어떻게 나눌지 직접 설계하고, 통신 규칙과 구현 계획을 에이전트에게 다시 전달했다.
2. 아키텍처 뷰어
   1. 에이전트에게 UML과 유사한 아키텍처 뷰어를 만들게 했다.
   2. 화면에서 모듈 구조와 의존성 방향을 보고, 모듈을 클릭해 하위 모듈로 내려갈 수 있다.
   3. 하위 모듈을 다시 클릭하면 해당 코드가 나타나므로, 시스템 전체에서 코드 한 부분까지 원하는 깊이로 드릴다운할 수 있다.
   4. 이 도구는 사람이 코드를 전부 읽지 않고도 구조의 문제를 빠르게 발견하게 해 주었다.
3. 의존성 규칙 검사기
   1. 어떤 모듈이 어떤 모듈에 의존해야 하는지, 어떤 의존성은 금지되는지, 의존성 방향이 어떻게 흘러야 하는지를 명세 파일에 기록한다.
   2. 마지막에 결정론적 검사기가 규칙 위반을 찾아내면 에이전트는 반드시 수정해야 한다.
   3. 수정 방법은 의존성 역전(Dependency Inversion), 인터페이스 삽입, 모듈 분할 등이 될 수 있다.
   4. Bob은 이 구조 검사를 완전히 자동화하려 하고 있지만 아직 큰 성과를 내지 못했다.

5.2. 모듈 경계가 인간과 모델에게 주는 인지적 레버리지

1. 잘 나뉜 구조는 복잡성을 격리한다
   1. 인간은 머릿속에서 대상을 구획화하므로, 규율 있는 인터페이스로 나뉜 모듈을 더 쉽게 파악한다.
   2. 모델과 에이전트도 인간과 비슷하게 모듈 내부의 주제가 섞이지 않고 한정될 때 더 잘 작동한다.
   3. 한 모듈 안에 모든 기능과 관심사를 넣으면 에이전트가 자신이 무엇을 해야 하는지 잃어버린다.
2. Deep Module의 원리
   1. John Ousterhout가 말한 깊은 모듈(Deep Module)은 인터페이스가 작고, 그 아래에 많은 구현 정보를 숨긴다.
   2. 얕은 모듈(Shallow Module)은 인터페이스가 넓고 내부에 숨기는 정보가 적어 사용자가 부담해야 할 지식이 많다.
   3. 에이전트는 내부 구현을 모두 읽지 않고도 이름과 인터페이스를 통해 모듈의 역할을 파악할 수 있다.
   4. 내부 코드가 일관되고 테스트가 설명 역할을 하면, 깊은 모듈은 에이전트에게 큰 도움을 준다.
3. 테스트도 시스템의 설명서다
   1. 모델은 인터페이스 이름과 구조뿐 아니라 테스트를 읽어 시스템의 동작을 이해한다.
   2. 따라서 좋은 모듈 경계, 명확한 인터페이스, 일관된 코드, 의미 있는 테스트는 모두 에이전트가 코드를 읽는 비용을 줄인다.
   3. Bob의 《Clean Code》 부록에는 Ousterhout와 모듈 설계에 대해 논쟁한 내용이 있으며, 두 사람 모두 그 대화를 즐겼다고 말했다.

6. 인간의 규율을 복사하지 말고 인간의 가치를 보존하라

AI 시대의 기본기는 과거 규칙의 기계적 복제가 아니라, 왜 그 규칙이 필요한지 이해하고 에이전트의 능력에 맞게 임계값과 절차를 다시 설계하는 일이다.

6.1. CRAP 점수와 순환 복잡도의 임계값 조정

1. 인간에게 적용하던 기준
   1. 인간 개발자에게는 CRAP 점수를 4 미만으로 유지하는 것을 목표로 삼는다.
   2. 순환 복잡도는 함수 안을 통과하는 가능한 경로의 수이며, 낮을수록 사람이 이해하고 테스트하기 쉽다.
2. 에이전트에게 허용하는 기준
   1. 100% 커버리지가 확보된 상태에서 CRAP 점수 6은 함수 안에 6개의 경로가 있고 모두 테스트된다는 뜻이다.
   2. Bob은 에이전트의 정확한 단기 기억이 인간보다 훨씬 강하므로 현재 기준을 6으로 두고, 8까지 높일지 실험 중이다.
   3. 에이전트에게도 적정 복잡도 임계값이 있지만 인간과 같을 필요는 없다.
   4. 에이전트와의 논쟁에서 에이전트가 6이 적당하다고 말해도 그 답을 절대 신뢰하지는 않으며, 실험과 검사 결과를 기준으로 판단한다.

6.2. TDD는 인간에게는 규율, 에이전트에게는 선택 사항

1. 인간에게 유효한 TDD 순서
   1. 테스트 주도 개발은 테스트를 한 줄 작성하고, 그 테스트를 통과시키는 생산 코드를 한 줄 작성한 뒤, 다음 테스트로 넘어가는 방식이다.
   2. 단기 기억이 제한된 인간에게는 작고 검증 가능한 단계를 유지하게 해 주므로 큰 효과가 있다.
2. 에이전트의 자연스러운 작업 순서
   1. 에이전트에게 인간과 같은 한 줄 단위 TDD 규율을 강제하는 것은 합리적이지 않을 수 있다.
   2. 에이전트는 한 함수를 먼저 작성하고 그 함수의 테스트를 작성한 다음, 다음 함수로 넘어가는 John Ousterhout식 순서로 되돌아가는 경향이 있다.
   3. 고강도 TDD를 지시해도 결국 함수 단위 구현과 테스트로 회귀하므로, Bob은 이를 허용한다.
3. 가치와 행동의 분리
   1. 테스트 가능성, 낮은 복잡도, 명확한 모듈, 검증 가능한 품질 같은 인간의 가치는 에이전트에 계속 적용해야 한다.
   2. 인간이 작업하기 편하도록 만들어진 세밀한 행동 규율을 에이전트에 그대로 강제하는 것은 실수일 수 있다.
   3. 보존해야 할 것은 인간의 가치이며, 조정할 수 있는 것은 임계값과 작업 방식이다.

7. 과도한 사전 계획보다 짧은 구현과 피드백

에이전트의 구현 비용이 극적으로 내려간 상황에서는 완벽한 사전 설계를 유지하기보다 작은 변경과 빠른 피드백으로 방향을 교정하는 편이 낫다.

7.1. 계획을 먼저 완성하려는 유혹과 실패

1. Waterfall의 반복
   1. 인간은 에이전트에게 일을 넘기기 전에 요구사항과 계획을 전부 명세하고 싶은 유혹을 받는다.
   2. 1970년대에는 이 유혹이 Waterfall 프로세스로 이어졌다.
   3. 계획을 모두 만든 뒤 실행하면 실제 결과가 계획과 전혀 다르게 나오기 때문에 Agile 혁명이 이 방식에 반발했다.
2. 최근의 Spec-Driven Development 실험
   1. Bob은 이번 주에도 많은 계획을 먼저 작성하고 에이전트에게 넘기는 실험을 했다.
   2. 계획을 실행하는 동안 사람이 미처 생각하지 못한 것이 드러났고, 에이전트는 그 빈틈을 채우지 못한 채 엉뚱한 방향으로 달렸다.
   3. 결국 작업을 중단하고 계획을 다시 쓰고 처음부터 시작해야 했다.
   4. 에이전트는 계획을 매우 좋아하며 상세하고 아름다운 문서를 만들지만, 실제 실행 단계에서 무너질 수 있다.
3. Agile식 대안
   1. 한두 개의 스토리를 먼저 구현한다.
   2. 결과를 보고 아키텍처와 방향을 다시 점검한다.
   3. 필요한 구조를 수동으로 정리한 뒤 몇 개의 스토리를 더 구현한다.
   4. 작은 구현→피드백→재조직을 반복하며, 마지막에 사람이 구조를 정리하는 단계를 완전히 없애지 못할 수도 있다.

7.2. 집을 1달러에 고치는 비유

1. 변경 비용이 높을 때의 선택
   1. 기초와 지붕을 놓는 첫 변경부터 집을 완전히 바꾸는 마지막 변경까지 모두 1달러라고 가정한다.
   2. 수천 달러를 들여 완벽한 설계를 만든 뒤 시공자에게 한 번에 건네는 방식과, 시공자에게 기초를 짓게 한 뒤 방·계단·동선을 직접 보며 계속 바꾸는 방식이 있다.
2. AI 시대의 변화
   1. 계단을 옮기고, 부엌과 거실의 위치를 바꾸고, 아이들이 걸어 다니는 모습을 본 뒤 동선이 나쁘면 다시 고치는 일이 예전보다 훨씬 싸졌다.
   2. 변경 비용은 1달러보다 조금 비쌀 수 있지만 과거보다 0에 가까워졌다.
   3. 변경 비용이 이렇게 내려갔다면 비싼 사전 계획에 모든 노력을 쓰기보다 실제 결과를 보며 계속 다듬는 편이 합리적이다.
   4. 핵심 전략은 “조금 만들고, 틀리면 고치고, 다시 조금 만든다”는 반복이다.

7.3. 사양(Specification)은 일시적이며 결과가 최종 사양이 된다

1. 사양을 저장하는 방식에 대한 견해
   1. Bob은 사양이 소스 코드처럼 영구적으로 저장되는 문서라고 생각하지 않는다.
   2. 요구사항을 설명하는 사양은 계속 바뀌고, fiddling 과정에서 사라지는 일시적(Ephemeral) 도구다.
   3. 과거에는 인간이 소스 코드를 작성했기 때문에 소스 코드가 인간의 최종 사양 역할을 했지만, 이제 에이전트가 코드를 작성하면서 그 등식이 달라졌다.
2. 도구를 복사하지 말고 자신에게 맞게 재생성하기
   1. Bob은 CRAP 도구를 Closure, Java, Go 등에 맞게 만들었고 변이 테스터와 에이전트 하네스도 구축했다.
   2. 다만 다른 사람이 자신이 만든 도구를 그대로 내려받기를 권하지 않는다.
   3. 도구 저장소를 에이전트에게 보여 주고, 자신의 프로젝트와 요구에 맞는 버전을 에이전트가 다시 만들게 하는 편이 더 낫다.
   4. 결과물이 해당 프로젝트에 맞는 실행 가능한 사양이 된다.
3. 정보 비대칭
   1. 에이전트는 사람이 보내 준 긴 문서를 거의 모두 읽는 반면, 사람은 에이전트가 쓴 긴 결과물을 거의 읽지 않는다.
   2. 사람은 거대한 명세를 전달해도 일부만 읽을 수 있지만, 에이전트는 명세를 읽고 실행한다.
   3. 이 비대칭을 인정하면 인간은 긴 문서를 계속 쓰는 것보다 결과를 검증할 수 있는 도구를 만드는 데 집중하게 된다.

8. 전술적 프로그래밍을 넘어 전략적 프로그래밍을 배우는 법

에이전트가 구현을 먹어 치운 뒤에도 사람은 목표, 구조, 검증, 방향을 결정해야 하며, 초보자가 그 역할을 배우는 교육 경로가 필요하다.

8.1. Tactical Programming과 Strategic Programming

1. 두 종류의 프로그래밍
   1. John Ousterhout의 구분에서 전술적 프로그래밍은 현장에서 전투하는 하사관처럼 당장 기능을 구현하는 일이다.
   2. 전략적 프로그래밍은 전쟁의 방향을 지시하는 장군처럼 시스템의 목표와 구조, 장기적인 방향을 정하는 일이다.
   3. 에이전트는 전술적 구현에는 매우 강하지만 전략적 결정에는 매우 약하다.
2. 전략가가 해야 할 일
   1. 무엇을 만들지 정하고, 요구를 작은 스토리로 나누고, 모듈과 인터페이스를 설계한다.
   2. 테스트, 변이 테스트, 아키텍처 규칙, QA 절차를 설계해 에이전트가 움직일 가우틀릿을 만든다.
   3. 에이전트의 결과를 모두 읽기보다 코드가 구조적 규칙과 결정론적 검사를 통과하는지 확인한다.

8.2. 초보 개발자의 권장 교육 경로

1. 먼저 직접 코드를 작성한다
   1. 대학이든 다른 교육 과정이든 최소 1년 정도 직접 코드를 작성해야 한다.
   2. 그래야 에이전트가 다루는 문제와 코드가 망가지는 방식이 무엇인지 알 수 있다.
2. 에이전트를 많이 쓰는 회사에서 ‘에이전트처럼’ 훈련한다
   1. 전략을 담당하는 리드 엔지니어는 신입을 에이전트처럼 취급하고 에이전트와 같은 종류의 작업을 준다.
   2. 신입도 에이전트와 동일한 결정론적 도구, 테스트, 품질 관문을 통과해야 한다.
   3. 몇 달 동안 매우 비생산적으로 느껴질 수 있지만, 그 과정에서 기본기와 판단력을 배운다.
   4. 가우틀릿을 통과한 뒤에야 자신의 에이전트를 운영하도록 맡길 수 있다.
3. 코드를 완전히 잃지 않는다
   1. 프로그래머가 코드의 실체를 전혀 모른 채 에이전트만 지휘하면 전략적 판단의 근거를 잃는다.
   2. Bob은 10년 전에도 어셈블리 언어를 한 번도 써 보지 않았다면 주말 동안이라도 작성해 보라고 권했다.
   3. Java 같은 고수준 언어만 쓰면 내부에서 실제로 무슨 일이 일어나는지 모르는 ‘환상 세계’에 살게 되기 때문이다.
   4. 어셈블리를 경험하면 추상화 아래에 있는 실행의 실체를 이해할 수 있다.

8.3. 추상화 계층을 통과하는 학습 순서

1. 기초에서 에이전트까지
   1. 이진(Binary) 수준에서 데이터와 계산의 토대를 이해한다.
   2. 어셈블리 언어(Assembly Language)로 CPU에 가까운 명령과 실행을 경험한다.
   3. C 같은 기본 언어로 메모리와 시스템에 가까운 코드를 작성한다.
   4. Python 같은 고수준 언어로 추상화된 프로그램을 만든다.
   5. 결정론적 도구를 활용하는 에이전트 작업을 경험한다.
   6. 마지막으로 감독 아래에서 에이전트를 전략적으로 운영한다.
2. 실패를 조기에 알아채는 감각
   1. Bob이 에이전트의 ‘개똥’을 알아본 가장 중요한 단서는 코드 모양보다 에이전트의 몸부림(thrashing)이었다.
   2. 에이전트가 한 수정으로 다른 것을 깨뜨리고, 같은 문제를 반복해서 고치며, 방향 없이 빙빙 돌면 구조가 이미 한계에 가까워진 신호다.
   3. 숙련자는 과거 자신이 겪은 실패와 고생을 기억하기 때문에 이 신호를 알아챌 수 있지만, 초보자는 단순히 빠르게 코드가 생성되는 것만 보고 문제를 놓칠 수 있다.
3. 오래된 책에서 전략을 배운다
   1. Tom DeMarco와 Ed Yourdon의 고전적인 소프트웨어 공학서에서 시스템을 조직하고 관리하는 전략적 감각을 배울 수 있다.
   2. 《The Pragmatic Programmer》 같은 책에도 오래된 듯 보이지만 여전히 유효한 원칙이 많다.
   3. 1970~1980년대에 쓰인 책은 시대에 맞지 않는 부분을 걸러야 하지만, 오늘날에도 반복되는 설계와 프로젝트 실패의 교훈을 담고 있다.
   4. 책을 읽는 것만으로 끝나지 않고 에이전트를 직접 운영하며 그 원칙을 체감해야 한다.
4. 짧아진 피드백 루프의 활용
   1. 전통적인 전략적 실수는 결과가 9개월 뒤에 나타날 수 있어, 6개월 만에 직장을 옮기면 자신의 판단이 틀렸는지도 모를 수 있다.
   2. 에이전트로 구현과 피드백이 빨라지면 모듈 설계와 품질 판단의 결과를 더 이르게 볼 수 있다.
   3. 단, 빠른 피드백을 얻으려면 테스트와 구조 검사가 결과를 명확히 보여 주도록 만들어야 한다.

9. 소프트웨어 기본기가 여전히 중요한 이유

추상화 계층이 모델 수준으로 올라가도 복잡성을 조직하는 원리는 사라지지 않는다.

9.1. 소프트웨어는 인간이 시도한 가장 복잡한 대상이다

1. 복잡성의 본질
   1. Edsger Dijkstra가 한 말로 기억되는 핵심 주장은 소프트웨어가 인간이 시도한 일 중 가장 복잡한 대상이라는 것이다.
   2. Bob은 정확한 인용자는 확신하지 못했지만, 소프트웨어 복잡성에 대한 판단 자체는 분명히 유지했다.
2. 기본기의 역할
   1. 기본기는 복잡성을 인간이 머릿속에서 이해할 수 있는 형태로 정리한다.
   2. 모델과 에이전트도 인간을 본떠 학습한 시스템이므로, 인간이 이해할 수 있게 정리된 구조를 더 잘 다룬다.
   3. 낮은 복잡도, 깊은 모듈, 명확한 인터페이스, 테스트, 의존성 규칙은 AI 시대에도 복잡성 관리의 언어다.

9.2. 추상화가 올라갈 때마다 반복된 공포

1. 이진·어셈블리·컴파일러·모델
   1. 과거에는 이진 위에 어셈블리가 생겼고, 그 위에 고수준 언어와 컴파일러가 생겼다.
   2. 개발자의 추상화 계층은 이제 컴파일러 위의 모델 수준까지 올라왔다.
   3. 각 단계에서 아래 계층의 사람들은 “이제 너무 쉬워져서 일자리가 사라지고, 다섯 살 아이도 코드를 쓰게 될 것”이라고 걱정했다.
2. 변하지 않는 원칙
   1. 추상화가 올라가도 시스템은 복잡하며, 모든 계층에서 같은 설계·검증·구조화 원리가 필요하다.
   2. 기본기를 버리면 그 규칙은 1년 뒤 바닥에서 다시 주워 먼지를 털어야 하는 형태로 돌아온다.
   3. AI가 코드를 만들 수 있다는 사실은 복잡성을 설계하고 검증해야 할 필요성을 없애지 않는다.
3. 글쓰기와 추상화에 대한 오래된 경고
   1. 진행자는 Plato가 글쓰기가 사람을 더 멍청하게 만들 것이라고 말했다는 일화를 언급했다.
   2. 새로운 추상화가 인간의 능력을 망칠 것이라는 주장은 고대 그리스 시대부터 반복됐다.
   3. 추상화는 기억과 구현의 부담을 덜어 주지만, 이해와 판단의 책임을 없애지는 않는다.

주요 발언 모음

“에이전트는 빠르지만, 나를 느리게 만든다.”
“They are fast, but they make me slow.”

“이것들이 빠르고, 실제로 빠르며, 내가 좋은 일을 하도록 제한할 수 있다면, 내 느림을 그들에게 강요하지 않겠다.”
“I am not going to impose my slowness upon them.”

“모델에 말하는 핵심은 초기 프롬프트를 절대적인 최소량으로 줄이는 것이다.”

“결정론적 도구는 그렇게 사라지지 않는다.”

“인간의 가치를 에이전트에 부과하는 것은 실수가 아니지만, 인간의 규율을 그대로 부과하는 것은 실수일 수 있다.”

“사양은 일시적이다. 사양은 사라진다.”

“소프트웨어 기본기는 여전히 중요하다. 소프트웨어는 인간이 시도한 일 가운데 가장 복잡한 것이기 때문이다.”

“규칙을 버리면 1년 뒤 바닥에서 다시 주워 들고, 왜 필요한지 기억하게 될 것이다.”

핵심 데이터 & 수치

• 1964년: Bob이 12세에 3비트 유한 상태 머신 방식의 첫 프로그램을 작성했다.
• 16세·18세: 16세에 첫 코딩 일을 얻었고 18세에 정식 프로그래머가 됐다.
• 반세기 이상: 프로그래머로 활동한 기간이 50년을 넘었다.
• 오전 6시: SQL Injection과 텍스트 기반 데이터베이스 접근을 고민하다 목욕 가운 호통을 녹화한 시각이다.
• 4분: 2000년 무렵 테스트 스위트 한 번의 실행 시간이었다.
• 수백 회·밤새: 변이 테스트를 반복 실행하기 위해 과거에는 밤새 기다려야 했다.
• 약 30분: 최근 에이전트가 변이 테스트를 수행하고 테스트 구멍을 보완하는 데 걸린 시간이다.
• CRAP 4: 인간 함수에 권장하던 낮은 복잡도 기준이다.
• CRAP 6, 8 실험: 에이전트에는 6을 허용하고 8까지 높일지 검토 중인 기준이다.
• 2~4배: 결정론적 검사로 느려져도 인간보다 높게 유지되는 생산성 여유의 관찰치다.
• 10~15초: 새 에이전트가 시작하고 컨텍스트를 구성하는 데 걸리는 시간이다.
• 5분 대 1시간 대 반나절: 단일 에이전트의 불확실한 구현, 다중 에이전트 가우틀릿, 인간 작업의 대략적인 시간 비교다.
• 4~5배: 가우틀릿 방식이 사람보다 빠르면서 더 높은 품질을 얻는다고 본 생산성 향상치다.
• 첫 15만 토큰: 컨텍스트 윈도우에서 상대적으로 ‘스마트 구역’처럼 작동한다고 언급된 대략적 범위다.
• 약 1,500명: 대화 종료 시점에 스트림을 시청하던 인원이다.

결론 및 시사점

1. 에이전트의 속도는 소프트웨어 기본기를 폐기할 이유가 아니라, 과거에 비싸서 못 하던 품질 검사를 실행할 기회다.
2. 긴 규칙 프롬프트보다 짧은 핵심 지시와 실패 시 수정되는 결정론적 도구를 결합해야 한다.
3. 구현·정리·강화·QA를 서로 다른 에이전트와 깨끗한 컨텍스트로 분리하면 역할 혼선과 Lost in the Middle을 줄일 수 있다.
4. 모듈을 작고 명확하게 나누고, 깊은 모듈과 규율 있는 인터페이스를 사용하면 인간과 에이전트 모두 시스템을 더 쉽게 파악한다.
5. 테스트 커버리지와 변이 테스트는 에이전트가 남긴 코드의 품질을 측정하고, UI QA는 실제 사용자 경로를 검증한다.
6. 인간용 TDD의 세밀한 순서를 에이전트에게 그대로 강요할 필요는 없지만, 테스트 가능성과 낮은 복잡도라는 인간의 품질 가치는 지켜야 한다.
7. 변경 비용이 낮아진 만큼 거대한 사전 계획보다 작은 스토리, 빠른 피드백, 반복적 구조 개선을 우선해야 한다.
8. 개발자는 코드를 완전히 포기하지 말고 이진·어셈블리·C·고수준 언어를 거쳐 에이전트를 전략적으로 운영하는 감각을 익혀야 한다.
9. 전략적 프로그래밍은 무엇을 만들지, 어떻게 나눌지, 어떤 검증 관문을 통과시킬지 결정하는 인간의 핵심 역할로 남는다.
10. 추상화 계층이 모델 수준으로 올라가도 소프트웨어의 복잡성은 사라지지 않으며, 기본기는 그 복잡성을 정리하는 공통 언어로 남는다.

핵심 요약 (20줄)

1. 소프트웨어는 인간이 시도한 일 가운데 가장 복잡하며 기본기는 그 복잡성을 구조화하는 방법이다.

2. Robert C. Martin은 1964년 12세 때 3비트 유한 상태 머신으로 첫 프로그램을 작성했다.

3. Bob은 실행할 기계가 없어도 Fortran·COBOL·PL/I 프로그램을 종이에 쓰고 머릿속으로 실행했다.

4. SQL Injection의 위험을 고민하던 오전 6시 목욕 가운 호통이 ‘Morning Bathrobe Rant’로 발전했다.

5. 초기 Grok 에이전트는 빠르게 코드를 만들었지만 정리하기 어려운 ‘개똥’과 보풀을 남겼다.

6. 지저분한 코드가 누적되자 에이전트는 한 부분을 고치며 다른 부분을 깨뜨리는 순환에 빠졌다.

7. CRAP 분석은 코드 커버리지와 순환 복잡도를 결합해 함수의 변경 위험을 수치화한다.

8. 변이 테스트는 비교 연산자와 부호를 바꿔 테스트가 실제 결함을 잡는지 검증한다.

9. 과거에 밤새 걸리던 변이 테스트를 에이전트는 약 30분에 수행하고 빈틈을 보완한다.

10. 긴 규칙 문서는 Lost in the Middle 때문에 컨텍스트 중간에서 영향력을 잃기 쉽다.

11. 초기 프롬프트는 최소화하고 나머지 품질 기준은 결정론적 자동 검사로 강제해야 한다.

12. 여러 에이전트는 병렬 실행과 역할별 깨끗한 컨텍스트를 통해 구현 품질을 높인다.

13. Specifier·Coder·Cleaner·Hardener·QA Agent는 요구사항·구현·정리·강화·시스템 검증을 나눠 맡는다.

14. 약 5분 걸리는 불확실한 단일 구현은 한 시간짜리 가우틀릿으로 바뀌지만 사람의 반나절보다 빠르다.

15. 잘 나뉜 모듈과 깊은 인터페이스는 모델이 모든 구현을 읽지 않고도 시스템을 이해하게 한다.

16. 인간의 TDD 순서를 그대로 강제하기보다 테스트 가능성과 낮은 복잡도라는 가치를 보존해야 한다.

17. Bob은 인간의 CRAP 기준 4보다 높은 6을 에이전트에 허용하고 8까지 실험하고 있다.

18. 변경 비용이 낮아진 시대에는 완벽한 사전 계획보다 작은 구현과 피드백의 반복이 유리하다.

19. 초보 개발자는 직접 코드를 쓰고 어셈블리부터 에이전트 운영까지 추상화 계층을 통과해야 한다.

20. AI가 전술적 코딩을 맡아도 목표·구조·검증을 결정하는 전략적 프로그래밍과 기본기는 사라지지 않는다.