8 작동 원리
바이브 코딩을 제대로 쓰려면 그 밑에서 무엇이 돌아가는지 대략은 알아야 한다. 이 장은 수학 없이, 그러나 정확하게 설명한다. 다음 토큰 예측이라는 기본 구조, 코딩 에이전트의 해부학, 그리고 왜 하필 코드에서 이 방식이 가장 잘 통했는지.
8.1 다음 토큰 예측에서 코드까지
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. LLM의 기본 동작은 다음에 올 토큰을 예측하는 것뿐이다. 이 단순한 메커니즘에서 코드를 짜는 능력이 어떻게 나오는지, 그리고 왜 코드가 자연어보다 이 메커니즘에 특히 잘 맞는 대상인지를 수식 없이 정확하게 설명하는 것이 이 꼭지의 임무다. 코드의 구문 규칙성, 공개 저장소라는 방대한 학습 데이터, 실행 가능성이 주는 신호가 각각 어떤 역할을 하는지 짚는다. 동시에 이 메커니즘이 어디서 무너지는지, 즉 환각이 코드 생성에서 어떤 형태로 나타나는지도 다룬다. “모델이 이해한다”는 말과 “패턴을 흉내낸다”는 말 사이의 실제 경계가 이 장 전체(8장)의 밑그림이 된다.
시드 질문
- 다음 토큰 예측이라는 단순한 학습 목표에서 코드를 짜는 능력은 구체적으로 어떤 경로로 나타나는가?
- 코드 생성이 자연어 생성보다 학습에 유리한 이유는 무엇인가, 구문 규칙성과 데이터 규모 중 어느 쪽이 더 크게 기여하는가?
- 환각은 코드 생성에서 구체적으로 어떤 형태를 띠는가, 존재하지 않는 API를 지어내는 경우와 틀린 인자를 쓰는 경우는 원인이 같은가?
- “모델이 코드를 이해한다”는 주장과 “패턴을 흉내낼 뿐이다”는 주장은 각각 무엇을 근거로 삼는가?
- 컨텍스트 윈도 크기의 확장은 실제 코딩 작업에서 어떤 성능 개선으로 이어졌는가?
조사 포인터
- Karpathy, “Software 2.0”(2017) 원문을 코드를 데이터로 다루는 관점의 원류로 재독할 것
- 다음 토큰 예측, 트랜스포머 구조에 관한 대중적이면서 정확한 설명 자료를 선별해 인용할 것
- 코드 생성의 환각 현상을 다룬 학술 논문을 우선 검색할 것 (실증 연구가 3부 전체의 기본 태도다)
8.2 코딩 에이전트의 해부학
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. 코딩 에이전트가 한 턴에서 실제로 무엇을 하는지 분해한다. 사용자 입력이 프롬프트로 구성되는 과정, 도구 호출(파일 읽기·쓰기, 명령 실행), 실행 결과가 다시 컨텍스트로 들어가는 피드백 루프, 그리고 이 루프가 몇 차례 반복되며 작업이 종료되는지를 단계별로 짚는다. Anthropic의 “Building effective agents”가 제시하는 워크플로와 에이전트의 구분을 이론 축으로 삼고, 오픈소스 코딩 에이전트의 실제 소스 코드를 대조해 이론과 구현의 간극을 확인하는 것이 핵심 작업이다.
시드 질문
- 코딩 에이전트 한 턴을 사용자 입력부터 최종 응답까지 단계별로 분해하면 무엇이 나오는가?
- 도구 호출(tool use)은 모델 쪽에서 무엇을 의미하고, 하네스 쪽에서는 무엇을 준비해줘야 성립하는가?
- Anthropic이 구분하는 “워크플로”와 “에이전트”의 경계는 어디이고, 실제 코딩 에이전트들은 어느 쪽에 더 가까운가?
- 오픈소스 코딩 에이전트의 소스에서 메인 루프는 실제로 어떻게 구현되어 있는가, 문서상 설명과 일치하는가?
- 실행 결과(테스트 실패, 에러 메시지, 셸 출력)가 다시 모델 입력으로 들어가는 피드백 루프가 없으면 무엇이 달라지는가?
조사 포인터
- Anthropic, “Building effective agents”(2024-12) 원문을 정독하고 이 장의 이론 축으로 쓸 것
- 오픈소스 코딩 에이전트(CLI형 도구 여러 종)의 GitHub 저장소에서 메인 루프 코드를 직접 읽을 것
- 하네스 엔지니어링 관련 자료를 찾아 §3.4, glossary의 agent harness 항목과 교차 참조할 것
8.3 검증 비대칭: 왜 하필 코드였나
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. 코드가 AI 생성의 첫 주력 분야가 된 이유 중 하나는 검증 가능성이다. 코드는 실행하면 맞았는지 틀렸는지 적어도 부분적으로 즉시 알 수 있지만, 산문이나 그림은 그렇지 않다. 이 비대칭이 왜 생기는지, 테스트·컴파일·타입 체크 같은 자동 검증 신호가 모델 학습과 에이전트 루프 설계에서 실제로 어떤 역할을 하는지, 그리고 이 검증 이점이 글쓰기나 다른 창작 분야로 일반화되려면 어떤 조건이 필요한지를 다룬다. §6.1(글쓰기)의 “검증이 어려운 아티팩트” 논의와 대칭을 이루는 꼭지다.
시드 질문
- “코드는 실행하면 검증된다”는 명제는 정확히 무엇을 검증하고 무엇을 검증하지 못하는가?
- 자동 검증 신호(테스트 통과, 컴파일 성공, 타입 체크)는 에이전트 루프 설계에 구체적으로 어떻게 반영되는가?
- 검증 비대칭 가설을 뒷받침하거나 반박하는 실증 연구는 무엇이 있는가?
- 이 검증 이점이 글쓰기, 이미지, 데이터 분석 같은 다른 산출물로 일반화되려면 어떤 조건(형식화 가능성, 채점 가능한 기준의 존재)이 필요한가?
- 검증 가능한 작업 위주로 자동화가 앞서가는 현상은 장기적으로 어떤 편향을 만드는가?
조사 포인터
- 검증 가능한 보상(verifiable reward) 기반 학습을 다룬 실증 연구를 찾아 확인할 것
- §5.4(검증 가능한 단위 만들기), §6.1(글쓰기)과 교차 참조해 중복 없이 역할을 나눌 것
- 소프트웨어 테스팅 이론과 AI 평가(evals) 문헌이 만나는 지점을 확인할 것