AI 코딩의 본질은 모델이 아니라 하네스다

Matt Pocock의 에이전틱 엔지니어링 워크플로우를 다룬 Tech Bridge 영상 썸네일

AI 코딩 이야기를 하면 대부분 먼저 모델 이름을 꺼냅니다. Claude가 낫다, Codex가 빨라졌다, Gemini CLI가 어디까지 한다더라. 물론 모델은 중요합니다. 그런데 Matt Pocock은 이 영상에서 조금 다른 곳을 보라고 말합니다. 진짜 차이는 모델이 아니라 하네스(harness)에서 난다는 것입니다.

하네스는 모델을 둘러싼 작업 환경입니다. 프롬프트, skill, 코드베이스 구조, 테스트, 문서, 샌드박스, GitHub Actions, 리뷰 흐름까지 모두 포함합니다. 자동차로 치면 엔진만 보는 것이 아니라 섀시, 공기역학, 피트 크루, 트랙 운영까지 보는 셈입니다.

이 관점은 AI 코딩을 처음 쓰는 사람에게도, 이미 Claude Code나 Codex를 업무에 붙이고 있는 팀에게도 중요합니다. 왜냐하면 모델 성능은 우리가 직접 통제하기 어렵지만, 하네스는 우리가 설계할 수 있기 때문입니다.

AI는 전술적 프로그래밍을 먹어치웠다

Matt Pocock은 John Ousterhout의 표현을 빌려 프로그래밍을 두 층으로 나눕니다. 하나는 전술적 프로그래밍입니다. 코드를 쓰고, 버그를 고치고, 커밋을 만들고, 문법을 맞추는 일입니다. 다른 하나는 전략적 프로그래밍입니다. 어떤 구조가 유지보수에 좋은지, 작업을 어떻게 쪼개야 하는지, 코드베이스가 앞으로 어떤 방향으로 가야 하는지 판단하는 일입니다.

AI는 이미 전술적 프로그래밍을 상당 부분 먹어치웠습니다. 작은 기능 구현, 테스트 추가, 리팩터링 초안, 문서 수정은 이제 사람이 직접 붙잡고 있어야만 하는 일이 아닙니다. 문제는 여기서부터입니다. 전술을 AI가 맡을수록 인간의 가치는 전략으로 이동합니다.

그래서 AI 시대의 개발자는 단순히 “프롬프트를 잘 쓰는 사람”이 아니라 “좋은 위임을 설계하는 사람”이 되어야 합니다. 목표를 명확히 쓰고, 범위를 좁히고, 완료 기준을 정하고, 테스트 방법을 붙여야 합니다. AI가 코드를 많이 만들수록, 인간은 더 선명하게 판단해야 합니다.

Skill은 많이 붙이는 것이 아니라 절차로 관리해야 한다

영상에는 Matt이 사용하는 skill 이야기가 자주 나옵니다. skill은 반복되는 사고 절차나 작업 방식을 AI가 다시 사용할 수 있도록 만든 지시 묶음입니다. 예를 들어 학습 코치를 만들거나, 설계를 공격적으로 검토하게 하거나, 특정 방식으로 PR을 리뷰하게 할 수 있습니다.

흥미로운 점은 Matt이 skill을 무조건 많이 붙이라고 말하지 않는다는 것입니다. 오히려 모든 skill, plugin, MCP server, Claude.md, agents.md를 지우고 빈 상태에서 시작해보라고 권합니다. 먼저 AI가 기본 상태에서 어떻게 행동하는지 관찰하고, 정말 필요한 것만 다시 추가하라는 뜻입니다.

여기에는 중요한 이유가 있습니다. 너무 많은 지시와 skill 설명은 컨텍스트 창을 오염시킵니다. 모델은 더 많은 정보를 받았지만 오히려 더 혼란스러워질 수 있습니다. 그래서 Matt은 모델이 알아서 호출하는 능력형 skill보다, 사용자가 필요할 때 명시적으로 부르는 절차형 skill을 더 선호합니다. 핸들은 사람이 잡고 있어야 한다는 관점입니다.

AFK 에이전트는 ‘무한 루프’보다 ‘큐’에 가깝다

요즘 agentic loop라는 표현이 자주 나옵니다. 에이전트가 계속 생각하고, 실행하고, 관찰하고, 다시 실행하는 구조입니다. 멋있게 들리지만 실무에서는 조금 위험하게 느껴질 때도 있습니다. 범위가 흐려지고, 비용이 커지고, 검토 지점이 사라질 수 있기 때문입니다.

Matt은 여기서 “loop보다 queue”라는 관점을 제안합니다. GitHub issue나 Jira ticket처럼 작업을 큐에 쌓고, 에이전트가 하나씩 가져가 처리하게 하는 방식입니다. 조사하고, 수정하고, 테스트하고, PR을 만들고, 마지막에는 사람이 확인합니다.

이 방식은 낯설지 않습니다. 개발팀은 원래 큐로 일해왔습니다. 백로그, 이슈, PR, 리뷰가 모두 큐 기반입니다. AI 에이전트는 그 흐름에 새로운 작업자 노드로 들어오는 것입니다. 그래서 처음부터 완전 자동화를 꿈꾸기보다, 작은 큐부터 맡기는 편이 안전합니다.

예를 들면 이런 작업이 좋습니다.

실패한 테스트 원인 조사
문서와 README 업데이트
단순 리팩터링 후보 제안
PR 리뷰 초안 작성
보안 점검 체크리스트 실행
오래된 이슈의 재현 가능성 확인

핵심은 사람이 옆에서 매 초 개입하지 않아도 되는 단위로 작업을 쪼개는 것입니다. 그리고 결과는 반드시 리뷰합니다.

AX: 이제는 Agent Experience도 설계해야 한다

개발팀은 오랫동안 DX, 즉 Developer Experience를 이야기해왔습니다. 개발자가 설치하고, 실행하고, 테스트하고, 배포하기 쉬운 환경을 만드는 일입니다. Matt은 여기서 한 단계 더 나아가 AX, 즉 Agent Experience를 말합니다.

AX는 에이전트가 코드베이스에서 일하기 쉬운 정도입니다. 좋은 AX를 가진 저장소는 이런 특징을 가집니다.

폴더 구조가 예측 가능하다.
테스트 실행 명령이 명확하다.
타입체크와 린트가 자동화되어 있다.
README와 개발 문서가 최신이다.
모듈 경계가 비교적 분명하다.
작은 변경을 안전하게 검증할 수 있다.
샌드박스에서 실행해도 필요한 정보가 충분하다.

흥미로운 점은 좋은 AX가 좋은 DX와 크게 겹친다는 것입니다. 사람에게 좋은 코드베이스는 AI에게도 좋습니다. 다만 AI 시대에는 이 기준이 더 날카로워집니다. 사람이 눈치로 넘어가던 빈틈을 에이전트는 자주 놓칩니다. 그래서 문서, 테스트, 명령어, 경계가 더 중요해집니다.

AI가 발견한 문제는 시스템 개선으로 바꿔야 한다

최신 모델이 보안 버그를 찾아냈다고 합시다. 여기서 “이 모델 정말 좋다”로 끝나면 절반만 배운 것입니다. 더 중요한 질문은 따로 있습니다. 왜 이 버그가 지금까지 남아 있었을까? 기존 테스트가 왜 잡지 못했을까? 비슷한 문제가 더 있을까? 다음에는 자동으로 찾게 만들 수 있을까?

Matt의 관점에서 AI가 준 결과는 단발성 산출물이 아니라 하네스를 개선할 신호입니다. 버그 하나를 고치는 데서 멈추지 않고, 테스트를 추가하고, 리뷰 기준을 바꾸고, 보안 점검 skill을 만들고, CI에 넣을 수 있는 검사를 찾는 방식입니다.

이것이 AI 코딩을 일회성 생산성 도구가 아니라 조직의 학습 시스템으로 쓰는 방법입니다. AI가 코드를 더 빨리 쓰게 하는 것보다, AI가 발견한 패턴을 다음 작업 환경에 반영하는 것이 더 오래갑니다.

제품과 비즈니스 판단은 여전히 인간의 몫이다

영상 후반부에서 SaaS가 죽었는지, AI 스타트업은 어떻게 해야 하는지에 대한 이야기도 나옵니다. Matt의 답은 의외로 담백합니다. 고객과 이야기하고, 실제 문제를 찾고, 프로토타입을 만들고, 해결책을 검증하라는 것입니다.

AI는 구현 속도를 높입니다. 그러나 무엇을 만들지, 왜 만들어야 하는지, 어떤 기능을 빼야 하는지는 자동으로 해결하지 못합니다. 오히려 구현이 쉬워질수록 더 많은 기능을 넣고 싶은 유혹이 커집니다. 이때 필요한 질문은 “무엇을 더 만들까?”가 아니라 “무엇을 줄이면 더 명확해질까?”일 수 있습니다.

AI 시대에도 제품의 중심은 고객의 문제입니다. 에이전트는 그 문제를 빠르게 실험하게 해주는 도구입니다. 문제 정의 자체를 대신해주는 존재는 아닙니다.

한국 개발자와 조직이 바로 해볼 7가지

첫째, 저장소의 README를 에이전트 기준으로 다시 읽어보세요. 처음 들어온 AI가 설치, 실행, 테스트를 이해할 수 있는지 확인합니다.

둘째, 자주 반복하는 요청을 skill이나 템플릿으로 만드세요. 단, 너무 많이 만들지 말고 실제로 반복되는 절차부터 시작합니다.

셋째, 이슈를 AI에게 줄 수 있는 크기로 쪼개세요. “관리자 페이지 개선”보다 “필터 컴포넌트에 빈 상태 메시지 추가, 기존 테스트 통과”가 낫습니다.

넷째, 테스트 명령과 완료 기준을 작업 지시에 포함하세요. AI에게 맡긴 뒤 사람이 다시 처음부터 확인하는 시간을 줄일 수 있습니다.

다섯째, AFK 작업은 샌드박스와 권한 제한 안에서 시작하세요. API key, 배포 권한, 운영 DB 접근은 특히 조심해야 합니다.

여섯째, AI가 만든 PR을 코드만 보지 말고 실패 패턴까지 보세요. 어디서 헷갈렸는지 알면 문서와 하네스를 개선할 수 있습니다.

일곱째, 최신 모델 뉴스는 따라가되, 팀의 기본기를 더 자주 점검하세요. 구조, 테스트, 문서, 리뷰 흐름이 약하면 어떤 모델도 오래 버티지 못합니다.

FAQ

AI 코딩에서 하네스란 무엇인가요?

하네스는 모델이 일하는 전체 환경입니다. 프롬프트, skill, 코드베이스 구조, 테스트, 문서, 샌드박스, CI, 리뷰 흐름까지 포함합니다. 모델 자체보다 우리가 직접 설계하고 개선할 수 있는 영역입니다.

왜 최신 모델보다 코드베이스 구조가 중요하다고 하나요?

좋은 구조와 테스트가 있으면 AI가 적은 맥락으로도 안전하게 변경할 수 있습니다. 반대로 구조가 복잡하고 문서가 낡았으면 비싼 모델도 헤맵니다. 그래서 토큰 비용을 줄이는 방법은 프롬프트 최적화만이 아니라 변경하기 쉬운 코드베이스를 만드는 것입니다.

Agentic loop와 queue 방식은 어떻게 다른가요?

Agentic loop는 에이전트가 계속 실행과 관찰을 반복하는 구조에 가깝습니다. Queue 방식은 사람이 정의한 작업 목록을 에이전트가 하나씩 처리하고, 결과를 리뷰하는 방식입니다. 실무에서는 queue 방식이 범위와 책임을 관리하기 쉽습니다.

AX는 기존 DX와 무엇이 다른가요?

DX는 사람이 개발하기 쉬운 경험이고, AX는 AI 에이전트가 작업하기 쉬운 경험입니다. 둘은 많이 겹칩니다. 명확한 문서, 예측 가능한 구조, 자동화된 테스트는 사람에게도 좋고 에이전트에게도 좋습니다.

AI에게 코딩을 맡길 때 가장 먼저 준비할 것은 무엇인가요?

작업 범위와 완료 기준입니다. 무엇을 바꿀지, 바꾸지 말아야 할 것은 무엇인지, 어떤 테스트를 통과해야 하는지 적어야 합니다. 그 다음에 샌드박스, 권한 제한, 리뷰 흐름을 붙이면 더 안전합니다.

참고자료

AI 코딩의 다음 단계는 더 많은 도구를 켜는 일이 아닐 수 있습니다. 오히려 잠시 멈추고, AI가 일하는 환경을 보는 일입니다. 어떤 문서가 부족한지, 어떤 테스트가 불안한지, 어떤 작업을 큐로 넘길 수 있는지 확인하는 것. 그 작은 정리가 최신 모델 하나를 더 구독하는 것보다 큰 차이를 만들 수 있습니다.

Thinknote