나만의 Harness를 만들어야 하는 이유
이 글에서 다룰 것
"AI한테 잘 부탁하면 알아서 잘해주겠지" — 이 마음으로 그때그때 프롬프트를 던지고, 스킬 몇 개로 돌리다 보면 어느 순간 깨달아요. 어제 잘 되던 게 오늘 깨지고, 결과가 들쭉날쭉하고, 맞게 된 건지 확인할 길이 없다는 걸요.
이 글은 Agentic 코딩의 본질이 일관성·품질·예측 가능성이라는 걸 짚고, 그 셋을 받쳐주는 장치 — 나만의 Harness(통제 구조) — 가 왜 필요한지를 풀어볼게요. 결국 "코딩하는 사람"에서 "엔지니어링을 지휘하는 사람" 으로 옮겨가는 이야기예요.
핵심 메시지
코딩하는 사람에서, 엔지니어링을 지휘하는 사람으로.
Agentic 코딩 시대에 중요해진 건 세 가지예요 — Consistency(반복 가능)·Quality(검증 가능)·Determinism(예측 가능). 그때그때 프롬프트와 스킬 몇 개로 즉흥적으로 돌리면 이 셋이 한꺼번에 무너져요. 그래서 내 도메인과 제약에 맞춘 나만의 Harness 를 만들어야 하는 거죠.
1. Agentic 코딩의 세 가지 본질
에이전트와 일할 때 우리가 진짜로 다루는 건 결국 이 세 가지예요.
- Consistency — 같은 일을 시키면 반복 가능한 결과가 나오는가
- Quality — 그 결과를 검증할 수 있는가
- Determinism — 다음에 어떻게 나올지 예측할 수 있는가
이 셋을 보장해주는 장치가 곧 Harness고요.
2. 즉흥성의 비용 - 그때그때 프롬프트의 함정
그때그때 프롬프트를 쓰고, 만들어둔 스킬 몇 개로 즉흥적으로 운영하면 — 일관성도, 회귀 방지(전에 되던 게 안 깨지게)도, 검증 가능성도 동시에 흔들려요.
물론 예외는 있어요. "한 번 쓰고 버릴" 바이브 코딩이라면 상관없죠. 그런데 소프트웨어가 대체로 어떤가요? 계속 변해요. 기능이 붙고, 고쳐지고, 또 붙고요. AI 시대에도 이 본질은 그대로예요. 그러니 한 번 쓰고 버릴 게 아니라면, 통제 구조가 필요한 거죠.
3. 가져다 쓰되, 의미를 알기 - 모르면 블랙박스
좋은 출발은 검증된 프레임워크부터 가져다 쓰는 거예요 — TDD, 플래닝 스킬, sub-agent 오케스트레이션, 코드 리뷰 에이전트 같은 거요. 굳이 처음부터 다 만들 필요 없어요.
단, 의미를 모르면 그 도구들은 블랙박스가 돼버려요. "TDD의 의미는 뭐지?", "스펙을 정리하는 기준은?", "내 리뷰의 기준은 뭐지?" — 이걸 알고 있어야, 가져온 도구를 내 워크플로로 진화시킬 수 있거든요. 그냥 가져다 쓰기만 하면 왜 되는지 모른 채 굴리게 되고요.
4. 나만의 Harness - 5가지 엔지니어링 구성 요소
가져온 걸 내 도메인과 제약에 맞게 다듬으면 그게 나만의 Harness예요. 목표는 Harness 그 자체가 아니라, 일관되고 품질 좋은 결과를 지속적으로 재현 가능하게 만드는 것이고요. 결국 엔지니어링 측면으로 보는 거죠.
뼈대는 다섯 요소예요.
| 요소 | 역할 |
|---|---|
| Specification | 의도를 코드로 정확히 옮기기 |
| Planning | 단계를 분해하고, 검증 지점을 설계하기 |
| Test Harness | 자동화된 검증 조건 만들기 |
| Review loop | 결과 품질 확인하기 |
| Failure recovery | 실패했을 때 회복 경로 두기 |
5. Harness는 정적인 산출물이 아니다 - 계속 진화한다
이걸 다 갖추면 끝일까요? 아니요, 거기서부터가 시작이에요. 소프트웨어 개발이랑 똑같거든요. 프로젝트 형태가 바뀌고, 팀이 바뀌고, 도메인·도구·사람·환경이 계속 바뀌니까, Harness도 함께 진화해야 해요.
그러다 보면 되던 게 안 되기 시작해요. 잘 나오던 결과가 어느 날부터 어긋나고요. 그때 필요한 건 끈질긴 추적 — "왜 안 되지? 왜 틀리지?" 하고 파고드는 거예요. 이게 꼭 타고난 엔지니어링 감각이나 풍부한 경험에서만 나오는 건 아니에요. 점검과 시도가 누적되면, 비로소 본인만의 Harness가 완성되는 거죠.
6. "정답이 뭐예요?" - 정답은 없어요
"그래서 뭘 써야 돼요?"라고 물으면, 솔직히 정답은 없어요. 다만 선택지를 많이 알수록 유리하죠. 같은 상황에도 꺼내 쓸 카드가 많아지니까요.
- Agent topology: single-agent / multi-agent / sub-agent
- Automation: Skill / Slash command / Hook / 결정론적 스크립트
이런 개념들을 폭넓게 알아두면, 내 환경에 맞는 조합을 직접 고를 수 있게 돼요.
7. 전체 워크플로 - 12스텝 한 장
이 모든 게 한 개발 사이클로 어떻게 맞물리는지는 한 장의 그림으로 정리돼 있어요.
AI 하네스 워크플로우 12스텝
환경 셋업 → 요구사항·설계 → TDD 사이클 → 완성, 그리고 이를 감싸는 META 자동화 2단계까지가 한 흐름이에요.
마무리 - 코딩하는 사람에서, 지휘하는 사람으로
얼마 전까지 우리는 코딩하는 사람이었잖아요. 그런데 이제는 엔지니어링을 지휘하는 사람이라고 생각해요. 한 줄 한 줄 직접 치는 것보다, 일관되고 검증 가능하고 예측 가능한 결과가 나오는 구조를 만드는 게 더 중요해진 거죠.
거창하게 한 번에 다 갖추려 할 필요 없어요. 내 환경에 맞춰 하나씩 쌓다 보면 어느새 견고한 나만의 Harness가 손에 잡혀요. 여러분도 한번 도전해보세요!
참고 영상
