코딩 에이전트에게 트레이서 불릿을 먼저 쏘게 하라는 조언의 논문 근거와 한계

코딩 에이전트에게 신규 기능 개발을 통째로 맡겨 본 경험이 있다면 익숙한 장면이 있습니다. 에이전트는 30분 넘게 쉬지 않고 데이터베이스 스키마, API 라우트, UI 컴포넌트를 층층이 쌓아 올립니다. 수천 줄의 코드가 생성됐는데 막상 버튼을 클릭하면 반응이 없습니다. 화면에 아무것도 나오지 않을 때도 있습니다. 레이어 하나하나는 그럴듯한데 서로 이어 붙이는 순간 무너지고, 어디서부터 잘못됐는지 찾는 시간이 처음부터 다시 일을 시키는 시간보다 길어집니다.

모던웹연구소가 레퍼런스로 삼는 자료 두 곳이 이 문제에 같은 처방을 내립니다. Gene Kim·Steve Yegge의 책 Vibe Coding과 Matt Pocock의 AI Hero 강의입니다.

(이미지 출처: Amazon, AI Hero)

처방의 이름은 '트레이서 불릿'입니다. 그런데 두 자료 모두 이 기법이 왜 AI 시대에 더 잘 통하는지 실증 근거를 인용하지는 않습니다. 그래서 모던웹연구소가 직접 확인했습니다. 원천 자료 21건을 수집하고 그중 뽑아낸 주장 25건을 검증하였습니다. 여기에 더해 3번의 교차 검증도 진행(딥 리서치)한 결과를 정리합니다.

트레이서 불릿이란 무엇인가

트레이서 불릿(tracer bullet)은 The Pragmatic Programmer(실용주의 프로그래머, Andy Hunt·David Thomas)에서 언급된 프로젝트 관리 전략입니다. 어두운 밤의 기관총 사수는 탄도를 계산해서 조준하지 않습니다. 빛이 나는 예광탄을 먼저 쏴서 탄환이 실제로 어디로 날아가는지 눈으로 확인하고 조준을 수정합니다.

(야간 사격 훈련에서 발사된 예광탄. 이미지 출처: Business Insider, 사진: Sgt. Pete Thibodeau/US Marine Corps)

이 기법을 개발 분야로 옮기면 시스템의 모든 레이어를 관통하는 얇은 실행 경로 하나를 먼저 만들어 아키텍처가 실제로 동작하는지 확인한 뒤 살을 붙이는 방식이 됩니다. 실용주의 프로그래머의 저자 Andy Hunt는 2003년 인터뷰에서 '실행의 얇은 한 줄이 끝에서 끝(end to end)을 관통하는 애플리케이션의 골격'이 트레이서 불릿 기법의 핵심이라고 정의했습니다.

(이미지 출처: 모던웹연구소가 메가존 ICON 2026 행사에서 발표한 자료)

집을 지을 때 방 하나를 완벽하게 꾸민 뒤 다음 방으로 넘어가는 건축 전문가는 없습니다. 뼈대를 먼저 세우고 수도·전기·배관이 끝에서 끝까지 통하는지 확인한 다음에 내부를 채웁니다. 트레이서 불릿이 바로 이 순서입니다. 소프트웨어 개발 업계에서는 같은 개념을 워킹 스켈레톤(walking skeleton), 스틸 스레드(steel thread), 수직 슬라이스(vertical slice)라고도 부릅니다.

프로토타입 개발에선 높은 확률로 버리는 코드를 만들게 됩니다. 프로덕션용 코드와 프로토타입용 코드는 품질이 다르기 때문입니다. 그런데, 트레이서 불릿 기법을 적용해 만든 코드는 최종 시스템의 골격으로 남는다는 점에서 프로토타입 개발과 다릅니다.

결론부터, 직접 실증한 논문은 없습니다

트레이서 불릿이라는 이름을 걸고 코딩 에이전트를 대상으로 대조 실험한 논문은 확인되지 않았습니다. 워킹 스켈레톤 같은 동의어로 넓혀도 마찬가지였습니다. 여기서 조사를 멈추면 트레이서 불릿 기법은 '근거 없는 실무 구전'이라는 결론이 나옵니다. 하지만 그렇지 않습니다. 기법을 구성하는 요소 각각은 정량 근거가 있습니다.

트레이서 불릿은 세 가지 메커니즘의 결합입니다.

• 첫째: 코드를 쓰기 전에 무엇을 만들지 구조를 정하고(계획 우선),

• 둘째: 동작하는 끝-끝 골격을 먼저 세우고(골격 우선 분해),

• 셋째: 실행 결과를 보고 조준을 수정합니다(반복 피드백).

이 세 메커니즘 각각은 LLM(대규모 언어 모델, Large Language Model)을 대상으로 한 피어리뷰 논문에서 정량으로 입증되었습니다. 하나씩 살펴봅시다.

근거 1. 실행하고, 결과를 보고, 다시 조준하면 성공률이 오른다

가장 두터운 근거는 반복 정제(iterative refinement) 계열 연구입니다. 한 번에 완성된 코드를 뽑는 대신 일단 실행 가능한 출력을 만들고 그 실행 결과를 피드백으로 되돌려 다시 시도하게 하는 접근입니다.

머신러닝 분야 최상위 학회에 게재된 논문들에서 일관된 방향을 확인했습니다. Reflexion(NeurIPS 2023)은 에이전트가 실패 원인을 말로 반성하게 하고, 다음 시도에 반영하게 하는 루프를 더해 함수 단위 코드 생성 벤치마크 HumanEval에서 pass@1 91%를 기록했습니다.

(이미지 출처: https://arxiv.org/abs/2303.11366)

생성한 코드가 첫 제출에 테스트를 통과하는 비율을 pass@1이라고 부르는데, pass@1 91%는 당시 최고 기록을 세우던 GPT-4의 80%를 11%p 넘어선 수치입니다. Google DeepMind의 Self-Debugging(ICLR 2024)은 모델이 자기 코드의 실행 결과를 읽고 스스로 고치게 해 코드 번역(TransCoder)·기초 파이썬 문제(MBPP) 벤치마크의 정답률을 최대 12%p 개선했고, LeDex(NeurIPS 2024)는 정제 과정 자체를 학습시켜 pass@1을 최대 15.92%p 올렸습니다. Self-Refine(NeurIPS 2023)에서도 비슷한 성능 개선을 확인했는데, 코딩 과제를 수행할 때의 이득은 3.6~8.7%p로 논문 전체 평균(약 20%p)보다 작았다는 점을 함께 적어 둡니다.

주의할 점이 하나 있습니다. 이 수치들은 모두 '최대(up to)' 기준이고, 이득은 테스트 실행 같은 외부 피드백이 있을 때 성립합니다. 이 한정이 오히려 트레이서 불릿과 연결되는 지점인데 뒤에서 다시 짚겠습니다.

근거 2. 계획을 먼저 세우게 하면 정확도가 오른다

두 번째 갈래는 계획 우선(plan-then-implement) 연구입니다. Self-planning(ACM TOSEM 2024)에선 계획 단계와 구현 단계를 분리하는 것만으로 계획 없이 구현하는 것 대비 최대 25.4%, 단계별 추론(Chain-of-Thought) 대비 최대 11.9%의 Pass@1 개선이 이뤄진다는 것을 여러 벤치마크와 언어에서 확인했습니다.

Scale AI의 PlanSearch(ICLR 2025)는 코드를 바로 여러 개 뽑는 대신 풀이 전략을 먼저 여러 갈래로 만드는 방식입니다. 코드부터 생성하면 표현만 다르고 접근은 비슷한 답이 반복되기 때문입니다. 그래서 PlanSearch는 문제에서 읽어낼 수 있는 관찰을 자연어로 나열하고 이를 조합해 서로 다른 풀이 전략을 만든 뒤 전략마다 코드를 생성했습니다. 이 방식으로 Claude 3.5 Sonnet은 LiveCodeBench에서 후보 200개 중 하나라도 정답이 나오는 비율(pass@200)을 77.0%까지 끌어올렸습니다. 전략 없이 코드만 200개 뽑는 반복 샘플링은 60.6%, 한 번에 뽑은 코드(pass@1)로는 41.4%였습니다. 계획 우선 접근 방식의 강력함이 눈에 띕니다.

단 PlanSearch는 대규모 샘플링 예산을 전제한 결과이고 일부 모델에서는 pass@1이 오히려 내려갈 수 있다고 논문 스스로에서 밝혔습니다.

근거 3. 골격을 먼저 세우는 접근의 학술판, Parsel

트레이서 불릿과 구조가 가장 닮은 연구는 Stanford의 Parsel(NeurIPS 2023)입니다. 과제를 계층적인 자연어 함수 기술로 먼저 분해해 상위 구조를 확정하고, 각 함수의 구현은 테스트 검증을 통과하는 조합을 탐색으로 알아내 구현하는 '구조 먼저, 구현 나중' 파이프라인입니다.

성과는 두 벤치마크에서 측정됐습니다. 알고리즘 대회 문제 1만 개를 모은 벤치마크 APPS 기준으로, AlphaCode·Codex로 코드를 바로 생성하는 것보다 과제를 먼저 분해하면 상대적인 통과율이 75% 이상 높았습니다(기존 통과율이 10%였다면 17.5% 이상이 됐다는 뜻). 함수 단위 벤치마크인 HumanEval에서는 자동 생성 테스트까지 결합해 pass@1 85%를 기록했습니다. 당시까지 발표된 최고 기록은 67%였습니다.

APPS(Automated Programming Progress Standard)는 UC 버클리의 Dan Hendrycks 연구진이 NeurIPS 2021에서 공개한 코드 생성 벤치마크입니다. Codeforces 같은 공개 알고리즘 문제 사이트에서 수집한 문제 1만 개로 구성됩니다. APPS 벤치마크는 사람이 직접 문제를 풀어야 하는 대회처럼 자연어로 작성된 지문을 읽고 입출력 처리까지 포함한 프로그램 전체를 작성해야 하고, 생성된 코드는 테스트 케이스를 실행하여 채점합니다. 난이도는 입문(introductory)·면접(interview)·대회(competition) 3단계입니다. 함수 하나를 완성하는 HumanEval보다 훨씬 어려워서 복잡한 문제에서 분해 접근의 효과를 확인하기에 적합합니다.

다만 85%라는 숫자는 그대로 받아들이면 안 됩니다. 비교 대상인 67%가 조건이 다른 이전 연구의 기록이기 때문입니다. 해당 논문에선 분해만 빼고 시도 횟수만 같게 하여 비교도 진행했습니다. 이 방식에서 81.1%라는 성능을 기록했습니다. 결국 과제 분해를 통해 순수하게 개선된 값은 약 4%p라는 말입니다. 실험 모델이 2022~2023년 세대라는 점까지 더하면 Parsel은 골격 우선 접근의 방향을 보여주는 근거이지 압도적인 격차를 증명한 논문은 아닙니다.

실무 관점에서는 이 '시도 횟수를 같게 맞춘' 비교가 오히려 중요한 시사점을 줍니다. 시도 횟수를 늘려 성공률을 올리는 방식은 시도마다 토큰 비용이 그대로 쌓입니다. 그렇기 때문에 엔터프라이즈 계약(정량제)으로 토큰 비용을 직접 부담하는 조직이라면 같은 예산으로 성공률을 더 올려 주는 과제 분해·계획 쪽이 합리적인 선택입니다. Parsel이 APPS에서 더 적은 샘플 예산으로도 더 높은 통과율을 달성했다는 점도 같은 방향을 가리킵니다.

여기까지의 학술 근거를 한 표로 정리하면 다음과 같습니다.

벤치마크 밖의 실전 근거, Anthropic의 '세션당 기능 하나'

학술 벤치마크는 대부분 함수 단위 문제입니다. 실제 큰 코드베이스를 대상으로 에이전트를 운영할 때와 가까운 사례는 Anthropic의 장기 실행 에이전트 실험 보고에 있습니다. 이 실험에선 Claude Opus 4.5와 Claude Agent SDK로 기능 200개가 넘는 claude.ai 클론을 수십 세션에 걸쳐 만드는 시도를 했습니다. 여기서 '세션당 기능 하나만 구현'하게 제한한 조치가 에이전트가 한 번에 너무 많이 만들려는 경향을 막는 데 결정적(critical)이었다는 보고가 나왔습니다. 세션당 기능 하나라는 제약이 없으면 구현 도중 컨텍스트 창을 소진해 다음 세션에선 반쯤 구현되고 문서화되지 않은 기능 개발이 시작되어 실패가 반복됐다고 합니다. 도입부에서 묘사한 바로 그 장면입니다.

공식 가이드에서도 같은 방향을 제시합니다. Claude Code 베스트 프랙티스에선 탐색·계획·구현·커밋의 4단계 워크플로를 권장하며 "계획 없이 바로 코딩하게 두면 잘못된 문제를 푸는 코드가 나올 수 있다"고 명시하고, 테스트나 빌드 종료 코드처럼 통과·실패가 분명한 신호를 주면 에이전트가 '작업-검사-반복' 루프를 스스로 닫는다고 설명합니다.

(이미지 출처: https://code.claude.com/docs/en/best-practices 해당 공식 문서엔 Plan 모드의 한계에 대해서도 담겨있으니 1독을 권합니다.)

OpenAI의 Codex 공식 문서도 복잡하거나 모호한 작업은 코드 작성 전에 계획부터 만들게 하라고 권장하며 전용 Plan mode(/plan)를 제품에 내장했습니다. 두 회사 모두 트레이서 불릿이라는 용어를 쓰지는 않고, 이 자료들은 통제 실험이 아니라 내부 경험에 기반한 정성 보고라는 점도 구분해 둡니다.

반례가 오히려 알려 주는 것

반대 방향의 연구도 있습니다. Olausson 등의 ICLR 2024 연구는 같은 연산 예산이라면 자기 수정(self-repair)의 이득이 미미할 수 있음을 보였고, Huang 등의 ICLR 2024 연구는 외부 피드백 없이 모델이 순수하게 자기 생각만으로 교정하는 데는 한계가 있음을 보였습니다. 두 반례의 공통 조건을 읽어 보면 흥미로운 결론이 나옵니다. 이득이 사라지는 경우는 '실행 피드백이 없을 때'입니다.

트레이서 불릿이 하는 일이 바로 그 실행 피드백을 프로젝트 첫날부터 만드는 것입니다. 끝에서 끝까지 관통하는 경로가 있어야 실행이 되고, 실행이 되어야 테스트·빌드·화면이라는 외부 신호가 생기고, 그 신호가 있어야 반복 정제의 이득이 성립합니다. 레이어별로 쌓기만 한 코드는 통합 전까지 실행 자체가 안 되니 에이전트가 받을 피드백이 없습니다.

반례 논문들은 트레이서 불릿을 반박하는 게 아니라 왜 골격이 '실행 가능'해야 하는지를 설명해 주는 셈입니다.

남은 공백

모던웹연구소가 다양한 논문을 참고해 작성한 이 인사이트 보고서엔 한계가 있습니다. 위 학술 실증 대부분은 HumanEval·MBPP·APPS 같은 함수 수준 벤치마크와 2022~2023년대 모델 기반입니다. 저장소 전체를 다루는 에이전트 작업에서는 두 방식을 정면으로 비교한 통제 실험이 아직 없습니다. 여기서 두 방식이란 얇은 끝-끝 골격을 먼저 만들어 검증한 뒤 기능을 하나씩 붙여 가는 트레이서 불릿 방식과, 처음부터 전체 기능을 한 번에 구현하게 맡기는 방식을 말합니다. 실제 GitHub 저장소의 이슈를 해결하게 하는 SWE-bench 같은 저장소 수준 벤치마크에서 이 둘을 나란히 견준 연구는 이번 조사에서 찾지 못했습니다. 최신 추론 모델에서 명시적 계획 단계의 이득이 그대로 유지되는지도 열린 질문입니다.

2026년 3분기 현재 상태를 한 문장으로 요약하면 이렇습니다. 트레이서 불릿이라는 '단어'를 증명한 논문은 없지만 그 구성 메커니즘 세 가지는 각각 정량 입증됐고, 에이전트를 가장 오래 굴려 본 회사들의 실전 보고와 방향이 일치합니다.

그래서 어떻게 적용하나

모던웹연구소가 실제 코딩 에이전트 기반 작업에 적용하는, 교육과 컨설팅에서 강조하는 방식은 네 가지입니다.

• 티켓을 수직으로 자릅니다. 스펙을 에이전트에 넘길 때 '백엔드 전부, 그다음 프런트엔드 전부'가 아니라 스키마·API·UI·테스트를 한 줄로 관통하는 얇은 단위로 나눕니다. Matt Pocock도 스펙을 티켓으로 분해하는 자신의 스킬에서 티켓 하나하나를 트레이서 불릿 형태로 만들도록 설계했습니다.

• 세션당 기능 하나를 원칙으로 둡니다. Anthropic 실험이 보여 준 그대로, 컨텍스트 창이 소진되기 전에 완결되는 크기가 기준입니다.

• 통과·실패 신호를 먼저 설계합니다. 테스트, 빌드 종료 코드, 스크린샷 비교처럼 에이전트가 스스로 검사할 수 있는 신호를 만들어 두면 반복 정제 연구들이 입증한 이득이 실제로 작동합니다.

• 골격이 검증되기 전에는 살을 붙이지 않습니다. 예광탄이 표적을 맞히는 것을 확인한 뒤에 실탄을 쏩니다.

코딩 에이전트가 코딩의 상당수를 인간 대신 수행해 주는 시대에 실무자들의 노하우 상당수는 논문보다 빠르게 축적됩니다. 그럴수록 어떤 조언이 어떤 근거로부터 나왔는지 아는 기관을 찾는 것이 좋은 교육기관과 컨설턴트를 찾는 기준이 됩니다. 트레이서 불릿 기법은 그 관점에서 모던웹연구소가 드리는 실무 노하우 중 하나입니다.

참고 자료

• Tracer Bullets: Keeping AI Slop Under Control (AI Hero, Matt Pocock, 실무자 자료)

• 5 Agent Skills I Use Every Day (AI Hero, Matt Pocock, 실무자 자료)

• Tracer Bullets and Prototypes (Andy Hunt·David Thomas 인터뷰, 개념 원출처 1차 자료)

• Reflexion: Language Agents with Verbal Reinforcement Learning (NeurIPS 2023)

• Teaching Large Language Models to Self-Debug (ICLR 2024)

• Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023)

• LeDex: Training LLMs to Better Self-Debug and Explain Code (NeurIPS 2024)

• Self-planning Code Generation with Large Language Models (ACM TOSEM 2024)

• Planning In Natural Language Improves LLM Search For Code Generation (ICLR 2025)

• Parsel: Algorithmic Reasoning with Language Models by Composing Decompositions (NeurIPS 2023)

• Effective harnesses for long-running agents (Anthropic Engineering)

• Claude Code Best Practices (Anthropic 공식 문서)

• Codex Best Practices (OpenAI 공식 문서)

• Is Self-Repair a Silver Bullet for Code Generation? (ICLR 2024)

• Large Language Models Cannot Self-Correct Reasoning Yet (ICLR 2024)

• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 2024)