[AI] 프롬프트에서 루프까지: AI 프로그래밍 방법론은 어떻게 진화하고 있나 (프롬프트 → 컨텍스트 → 하네스 → 루프 엔지니어링)

AI 생성 이미지

 

안녕하세요. 코딩하는 Jay입니다.

 

오늘은 요즘 개발 판에서 빠르게 바뀌고 있는 "AI와 함께 코딩하는 방법론"의 흐름을 정리해보려고 합니다.

 

혹시 얼마 전까지 "프롬프트 잘 쓰는 법"을 열심히 공부했는데, 어느새 "컨텍스트 엔지니어링"이 나오고, 또 "하네스"니 "루프"니 새로운 말이 계속 쏟아져서 좀 어지러우셨던 적 있으시죠? 저도 그랬습니다. 그런데 하나하나 뜯어보니 이게 서로 다른 유행이 아니라, 이전 단계를 흡수하면서 한 층씩 위로 올라가는 진화더라고요. 오늘은 그 네 단계를 순서대로 정리해보겠습니다.

한 문장 요약: 질문에서 시스템으로

먼저 큰 그림부터 보겠습니다. 네 단계는 결국 "무엇을 잘 다룰 것인가"의 대상이 바뀌어 온 역사입니다.

• 프롬프트 엔지니어링 — 어떻게 질문할 것인가
• 컨텍스트 엔지니어링 — 무엇을 넣어줄 것인가
• 하네스 엔지니어링 — 에이전트를 어떻게 감쌀(운용할) 것인가
• 루프 엔지니어링 — 에이전트를 프롬프트하는 시스템을 설계할 것인가

관심의 초점이 "한 번의 대화" → "모델이 보는 정보 전체" → "에이전트를 둘러싼 실행 환경" → "그 환경을 스스로 돌리는 자동 루프"로 점점 넓어져 온 것입니다.

 

1단계. 프롬프트 엔지니어링 (Prompt Engineering)

가장 먼저 유행한 개념입니다. 핵심 질문은 "어떻게 물어봐야 원하는 답이 나올까?" 였습니다.

• 역할 부여("너는 시니어 개발자야"), 예시 제공(few-shot), 단계별 사고 유도(Chain of Thought) 같은 기법들이 여기에 속합니다.
• 대상이 한 번의 요청·응답이라는 게 특징입니다. 질문을 잘 다듬는 것에 집중하는 단계죠.

한동안 "프롬프트 엔지니어"라는 직무 이야기까지 나올 정도로 뜨거웠지만, 코딩 에이전트가 본격화되면서 한계가 드러났습니다. 아무리 질문을 잘 다듬어도, 모델이 우리 프로젝트를 모르면 좋은 코드가 나올 수 없었기 때문입니다.

 

2단계. 컨텍스트 엔지니어링 (Context Engineering)

그래서 초점이 "어떻게 물어보나"에서 "모델에게 무엇을 보여줄 것인가"로 옮겨갔습니다.

이 용어는 2025년 6월 무렵 안드레이 카파시(Andrej Karpathy)가 "프롬프트 엔지니어링이라는 말은 이 작업의 무게를 과소평가한다"고 지적하면서 널리 퍼졌고, Anthropic도 같은 개념을 정리해 발표했습니다.

• 프롬프트 엔지니어링이 일회성·순간의 질문을 다룬다면, 컨텍스트 엔지니어링은 지속되는 자산을 다룹니다.
• 시스템 지시문, 검색해온 문서(RAG), 설정 파일, 컨벤션 문서 등 모델의 컨텍스트 창에 들어가는 토큰 전체를 관리하는 일입니다.
• Claude Code의 CLAUDE.md나 Cursor의 규칙 파일처럼, 세션이 바뀌어도 계속 에이전트의 행동을 규정하는 파일이 대표적인 산출물입니다.

핵심 질문은 "지금 이 작업을 하려면 모델이 어떤 정보를 알고 있어야 하나?"입니다. 질문 문장보다 모델의 작업 환경(무엇을 아는가)이 결과를 좌우한다는 깨달음이었습니다.

 

3단계. 하네스 엔지니어링 (Harness Engineering)

컨텍스트까지 잘 갖추자, 이번엔 에이전트가 도구를 쓰고, 파일을 고치고, 여러 단계를 스스로 밟는 "자율 에이전트"가 현실이 됐습니다. 그러자 문제는 "정보를 뭘 주나"를 넘어 "이 강력하지만 거친 에이전트를 어떻게 안전하고 안정적으로 굴릴 것인가"로 넘어갑니다. 이게 하네스(harness, 마구·굴레) 엔지니어링입니다.

벤처투자자 토마스 텅구즈(Tomasz Tunguz)는 이를 "야생마(머스탱)를 길들이는 일"에 비유하면서, LLM을 중심에 두고 그 주위를 감싸는 7가지 구성요소로 하네스를 정의했습니다.

• Context & Memory (맥락·메모리)
• Tools & Action (도구·행동, MCP가 연결 조직 역할)
• Orchestration & Loop (오케스트레이션: 사고→행동→관찰→반복)
• State & Persistence (상태·영속성, 중간에 죽어도 8단계부터 재개)
• Sandbox & Compute (격리된 작업 공간)
• Observability & Governance (관측·거버넌스, evals·가드레일)
• Cost & Workflow Optimization (비용·아키텍처 판단)

핵심 통찰은 "모두가 같은 모델을 쓸 수 있는 시대에는, 모델이 아니라 그 모델을 잘 타는 쪽(best rider)이 이긴다"는 것입니다. 즉 경쟁력이 모델 자체가 아니라 모델을 감싸는 운용 설계로 옮겨간 셈이죠.

 

4단계. 루프 엔지니어링 (Loop Engineering)

그리고 지금 이야기되는 가장 최신 단계가 루프 엔지니어링입니다. 앞의 세 단계가 모두 "내가 에이전트를 더 잘 다루는 법"이었다면, 루프 엔지니어링은 결이 조금 다릅니다. 아예 "에이전트를 프롬프트하는 자리에서 나를 빼버리는 것"이거든요.

Anthropic의 Claude Code 책임자 보리스 체르니(Boris Cherny)의 말이 이 단계를 잘 요약합니다.

"이제 저는 Claude에 프롬프트하지 않습니다. Claude에 프롬프트하고 무엇을 할지 정하는 루프를 돌립니다. 제 일은 루프를 작성하는 것입니다."

즉 매 턴 직접 지시하는 대신, 작업을 찾아 → 분배하고 → 검증하고 → 완료를 기록하고 → 다음 작업을 정하는 작은 시스템을 한 번 설계해두고, 그 시스템이 에이전트를 반복해서 찌르게 하는 방식입니다. 개발자 애디 오스마니(Addy Osmani)와 피터 슈타인베르거(Peter Steinberger)가 이 개념을 활발히 정리하고 있습니다.

루프는 대략 다섯 가지 구성요소(+메모리)로 이뤄집니다.

• Automations — 스케줄에 따라 스스로 발동해 할 일을 찾음 (루프의 심장 박동)
• Worktrees — 여러 에이전트가 병렬로 일해도 파일이 충돌하지 않게 격리
• Skills — 프로젝트 지식을 외부 파일로 적어둬 매번 다시 설명하지 않게 함
• Plugins·Connectors — MCP로 이슈 트래커·DB·Slack 등 실제 도구에 연결
• Sub-agents — 코드를 쓰는 쪽과 검증하는 쪽을 분리 (자기 숙제는 후하게 채점하니까)
• (+) 메모리 — 대화 밖 markdown 파일이나 보드에 상태를 저장. 모델은 실행 사이에 다 잊어버리니, 기억은 컨텍스트가 아니라 디스크에 있어야 합니다

특히 "코드를 쓴 에이전트가 스스로 채점하지 않게, 별도의 검증 에이전트를 둔다"는 생성/평가 분리가 루프의 핵심 장치입니다. Claude Code의 /goal이 내부적으로 하는 일이 바로 이것이라고 하네요.

 

네 단계 한눈에 비교

단계	핵심 질문	다루는 대상	대표 산출물
프롬프트 엔지니어링	어떻게 물어볼까	한 번의 요청	잘 다듬은 프롬프트
컨텍스트 엔지니어링	무엇을 보여줄까	모델이 보는 정보 전체	CLAUDE.md·규칙 파일·RAG
하네스 엔지니어링	어떻게 감싸 굴릴까	에이전트 실행 환경	도구·상태·샌드박스·evals
루프 엔지니어링	어떻게 자동화할까	에이전트를 굴리는 시스템	자동 루프·스케줄·검증자

이렇게 놓고 보면, 새 개념이 옛 개념을 버리는 게 아니라는 점이 분명해집니다. 컨텍스트 엔지니어링 안에도 좋은 프롬프트가 필요하고, 하네스 안에도 컨텍스트 관리가 들어가며, 루프는 그 하네스를 통째로 굴립니다. 이전 단계를 흡수하면서 한 층씩 추상화가 올라가는 구조입니다.

 

그래도 사라지지 않는 것: 검증과 이해는 사람의 몫

한 가지는 짚고 넘어가야 할 것 같습니다. 루프가 알아서 돌아간다고 해서 개발자가 없어지는 건 아니라는 점입니다. 오히려 루프 관련 글들이 공통적으로 세 가지를 경고합니다.

• 검증은 여전히 본인 몫 — 무인으로 도는 루프는 무인으로 실수하는 루프이기도 합니다. "완료(done)"는 증명이 아니라 주장일 뿐입니다.
• 이해는 방치하면 썩는다 — 내가 직접 안 쓴 코드를 빨리 내보낼수록, 존재하는 코드와 내가 실제로 이해하는 코드 사이 간극이 커집니다(comprehension debt).
• 편안한 자세가 위험한 자세 — 돌려받은 걸 그대로 받아들이기 시작하면(cognitive surrender), 같은 루프라도 독이 됩니다.

그래서 나온 표현이 "루프를 만들되, 엔지니어로 남아라(build the loop, stay the engineer)"입니다. 방법론이 아무리 발전해도 결국 방향을 정하고 결과를 검증하는 판단은 사람에게 남는다는 뜻인 것 같습니다.

 

결론

정리하면 AI 프로그래밍 방법론은 프롬프트 → 컨텍스트 → 하네스 → 루프 엔지니어링 순으로, 관심의 초점이 "한 번의 질문"에서 "에이전트를 스스로 굴리는 시스템"으로 넓어져 왔습니다. 각 단계는 앞 단계를 대체하는 게 아니라 흡수하며 쌓이는 것이라, 지금 어느 단계를 공부하시든 다음 단계로 자연스럽게 이어질 수 있습니다.

레버리지 지점이 계속 위로 옮겨가고 있지만, 마지막에 코드를 읽고 "이건 아니다"라고 말할 사람은 여전히 우리 개발자라는 점은 변하지 않는 것 같습니다. 다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!

 

참고 / 출처

• Andrej Karpathy — "context engineering" 개념 정리 (2025-06)
• Anthropic — Effective context engineering for AI agents
• Tomasz Tunguz — AI 하네스 7 구성요소 (tomtunguz.com)
• Addy Osmani — Loop Engineering (Boris Cherny·Peter Steinberger 인용)