하네스 엔지니어링 활용편 — AI 코딩이 답답할 때, 모델보다 먼저 고쳐야 하는 것들

여기까지 읽고 나면 자연스럽게 이런 생각이 든다.

 

“알겠어. 개념도 알겠고, Anthropic이 어떻게 굴렸는지도 봤어. 그런데 내 프로젝트에서는 뭘 해야 하는데?”

 

사실 이 질문이 제일 중요하다.
개념은 멋있고, 사례는 인상적이다. 그런데 내 저장소에 붙는 순간부터는 얘기가 완전히 달라진다. 거기에는 오래된 코드가 있고, 반쯤 깨진 테스트가 있고, 이름만 남은 문서가 있고, 사람도 자주 안 지키는 규칙이 있다. 그런 현실 위에 AI 코딩 에이전트를 올리면 어떤 일이 생기냐면… 모델이 멍청해서가 아니라 환경이 엉망이라서 계속 삐끗한다.

 

나는 하네스 엔지니어링을 거창한 멀티 에이전트 설계로 보기보다, “에이전트가 계속 같은 데서 미끄러질 때 바닥에 미끄럼방지 테이프를 붙이는 일”에 더 가깝다고 본다. 이 비유가 좀 덜 있어 보일 수는 있는데, 실무에서는 이쪽이 훨씬 정확하다.

 

좋은 출발점은 이상적인 구조를 미리 설계하는 게 아니다.
실패를 하나 잡고, 그 실패가 다시 안 나게 만드는 것이다.

 

이상적인 하네스를 먼저 만들려 하지 마라

 

이건 여러 팀이 거의 독립적으로 같은 결론에 도달한 지점이다. Mitchell Hashimoto도 비슷한 말을 했고, HumanLayer 팀도 같은 방향으로 갔다. 핵심은 단순하다.

 

에이전트가 실제로 틀린 적이 없는 규칙은 아직 넣지 말라는 것.

 

이게 왜 중요하냐면, 하네스를 만들기 시작하면 사람은 본능적으로 미래의 모든 문제를 선제적으로 막고 싶어 하기 때문이다. “이런 것도 필요할 것 같고, 저런 것도 있으면 안전하겠지” 하면서 규칙을 계속 늘린다. 그런데 그렇게 쌓인 규칙은 대개 두 가지 부작용을 만든다. 하나는 컨텍스트를 잡아먹는다는 점이고, 다른 하나는 정말 중요한 지시를 묻어버린다는 점이다.

 

이건 TDD랑 좀 닮아 있다. 실패하는 테스트가 먼저 있고, 그 실패를 막는 코드를 추가한다. 하네스도 비슷하다. 에이전트가 실제로 어떤 식으로 망가졌는지 본 다음에, 그 실패를 방지하는 장치를 하나 추가한다. 그 정도면 충분하다. 적어도 처음에는.

 

이 원칙이 좋은 이유는 하네스가 점점 현실화된다는 데 있다. 문서 속 이상형이 아니라, 내 저장소에서 실제로 발생한 사고 목록이 곧 하네스 설계서가 된다. “가끔 타입 에러를 무시하고 커밋한다”, “같은 기능을 두 군데 고친다”, “테스트를 빼버리고 끝났다고 말한다”, “경로를 잘못 들어가 엉뚱한 디렉토리를 만진다” 같은 구체적인 실패가 기준이 된다. 이렇게 쌓인 하네스는 적어도 허공에 떠 있지 않다.

 

ETH Zurich 쪽 연구도 이 감각을 꽤 냉정하게 뒷받침한다. 설정 파일을 LLM이 길게 생성하게 했더니 성능은 별로 안 좋아지고 비용만 늘어나는 경우가 나왔고, 사람이 정성껏 써도 개선 폭이 생각보다 크지 않았다. 코드베이스 개요나 디렉토리 목록을 잔뜩 넣는다고 특별히 더 잘해지는 것도 아니었다. 모델은 저장소를 생각보다 잘 뒤진다. 문제는 검색 능력이 아니라, 잘못된 결정을 반복하게 만드는 환경 쪽일 때가 많다.

 

그러니까 첫 원칙은 의외로 소극적이다.

 

많이 넣지 말고, 틀린 것부터 막아라.

 

이게 시작점이다.

 

규칙은 적을수록 좋다. 진짜로

 

하네스 엔지니어링에서 가장 반직관적인 부분은 여기다.
대부분 처음엔 이렇게 생각한다.

 

규칙을 많이 주면 더 잘하겠지.
도구를 많이 연결하면 더 똑똑해지겠지.
에이전트를 역할별로 쪼개면 더 안정적이겠지.

 

실제로는 그렇지 않은 경우가 많다.

 

Vercel도 초기에 도구를 넉넉하게 주는 쪽으로 갔다가, 오히려 도구를 줄인 뒤 성능이 나아졌다는 이야기를 했다. 이건 직관에 좀 어긋난다. 선택지가 많으면 유연해질 것 같은데, 에이전트는 오히려 흔들린다. 어떤 도구를 써야 할지 판단해야 하고, 각 도구 설명이 프롬프트 공간을 차지하고, 결국 핵심 작업 맥락이 희석된다.

 

MCP 서버를 많이 물리는 것도 비슷하다. 연결하는 순간 뭔가 강력해진 느낌이 든다. GitHub도 연결하고, DB도 연결하고, Playwright도 붙이고, 이슈 트래커도 넣고, 내부 위키도 물리고… 그런데 그 도구 정의들 자체가 토큰을 먹는다. 겉으로는 200K 컨텍스트 창이 열려 있어도, 실제로 작업에 쓸 수 있는 공간은 훨씬 줄어든다. HumanLayer가 Linear MCP를 통째로 붙이는 대신 자주 쓰는 핵심 기능만 감싼 가벼운 CLI를 만든 것도 그래서다. 화려한 연결보다 얇고 자주 쓰는 인터페이스가 더 효율적일 때가 많다.

 

이쯤에서 관점을 바꿔야 한다.
“무엇을 더 붙일까?”보다 “무엇을 안 붙여도 될까?”를 먼저 보는 쪽으로.

 

GitHub, Docker, 기본 DB CLI처럼 모델이 이미 훈련 데이터에서 익숙하게 본 도구는, 굳이 무거운 MCP 인터페이스로 포장하지 않아도 되는 경우가 있다. CLI를 그대로 쓰게 하는 편이 더 싸고, 더 짧고, 더 덜 헷갈린다. 실무에서는 이런 판단이 계속 중요해진다. 기술적으로 가능하냐보다, 작업 컨텍스트를 얼마나 덜 오염시키느냐가 더 중요해진다.

 

처음 만드는 파일은 거대한 설계 문서가 아니다

 

실제로 뭘 먼저 해야 하냐고 묻는다면, 나는 거의 항상 컨텍스트 파일부터 시작하라고 말할 것 같다. Claude를 쓰면 CLAUDE.md, Codex 계열이면 AGENTS.md처럼 프로젝트 루트에 두는 그 파일 말이다.

 

근데 여기서도 사람들이 자주 과하게 간다.

 

처음부터 완벽한 온보딩 문서를 만들려고 한다.
프로젝트 철학, 디렉토리 설명, 계층 규칙, 코딩 스타일, 리뷰 원칙, 배포 방식, 팀 문화까지 다 때려 넣는다.

 

그러면 대개 망한다.

 

초기 버전은 짧아야 한다. 정말 짧아야 한다.
에이전트가 지금 당장 일을 시작하는 데 필요한 것만 있어야 한다.

 

예를 들면 이런 정도다.

 

개발 서버는 뭘로 띄우는지
테스트는 어떤 명령으로 도는지
빌드는 뭘 실행하는지
커밋 메시지 규칙이 있는지
절대 깨지면 안 되는 의존 방향이 있는지

 

그 이상은 대부분 나중 문제다.

 

이 파일의 목적은 세계관 설명이 아니다.
첫 작업에서 덜 망하게 만드는 것이다.

 

그리고 이 파일은 정적인 문서가 아니라 실패 기록을 흡수하면서 자라는 장치여야 한다. 에이전트가 React Query 대신 fetch를 직접 남발했으면 그때 한 줄 추가하면 된다. 커밋 전에 테스트를 자꾸 건너뛰면 그 규칙을 그때 넣으면 된다. 처음부터 “언젠가 필요할 것 같은 것”까지 다 넣기 시작하면, 정작 자주 틀리는 규칙이 희미해진다.

 

프로젝트가 커지면 더더욱 하나의 파일로 버티지 말아야 한다. OpenAI 팀이 AGENTS.md를 “모든 걸 담는 문서”가 아니라 “지도”처럼 쓰라고 한 것도 같은 맥락이다. 루트 파일은 전역 규칙만 담고, 실제 세부 규칙은 디렉토리 가까이에 내려놓는 편이 낫다. 컴포넌트 폴더에는 컴포넌트 규칙, API 폴더에는 API 규칙, 테스트 폴더에는 테스트 관례. 그렇게 해야 근처 맥락만 읽고 움직일 수 있다. 사람도 큰 저장소에서는 그렇게 일한다. 에이전트도 마찬가지다.

 

훅은 “조언”이 아니라 “강제”다

 

여기서부터 하네스가 좀 더 하네스다워진다.

 

문서에 “테스트 꼭 돌리세요”라고 써두는 건 약하다.
읽을 수도 있고, 무시할 수도 있다.
에이전트도 마찬가지다.

 

반면 훅은 다르다.
행동 중간에 자동으로 끼어든다.

 

파일을 수정한 뒤 자동으로 포맷팅이 돌게 만들고, 타입 체크를 강제하고, 위험한 명령은 실행 전에 막아버리는 식이다. 이건 체감상 차이가 꽤 크다. 문서 규칙은 권고에 가깝고, 훅은 물리 법칙에 가깝다. 잘못하면 튕긴다. 그래서 더 효과가 있다.

 

예를 들어 git commit --no-verify를 금지하는 훅 같은 건 너무 사소해 보여서 처음엔 우습다. 그런데 에이전트가 실패를 피하려고 그런 우회로를 쓰기 시작하면, 그때부터 하네스는 무너진다. 테스트를 통과하지 못했는데도 커밋이 쌓이고, 나중에는 사람이 그 부채를 다 받아낸다. 이런 건 프롬프트에서 타이르는 것보다 훅으로 잘라내는 편이 훨씬 낫다.

 

파일 저장 뒤 포맷터와 타입 체크를 자동으로 거는 것도 마찬가지다. “코드 스타일을 지켜라”, “타입 에러를 남기지 마라”라고 백 번 말하는 것보다, 저장하자마자 검사해서 바로 에러를 돌려주는 편이 훨씬 강하다. OpenAI 팀이 말한 “기계적 강제”가 이쪽이다. 프롬프트는 설득이고, 훅과 린터는 구조다. 설득은 흔들리지만 구조는 덜 흔들린다.

 

작업 단위를 강제로 줄여야 한다

 

Anthropic 사례를 보면서 가장 현실적으로 가져올 만했던 건 이 부분이다.
한 번에 하나의 기능만 하게 만드는 것.

 

이게 별거 아닌 것 같은데, 실제로 에이전트가 망가지는 가장 흔한 방식 중 하나가 범위를 슬금슬금 넓히는 것이다. 원래는 인증 버그 하나만 고치면 되는데, 관련된 유틸도 건드리고, API 응답 형식도 조금 바꾸고, 테스트가 거슬리니까 같이 손대고, 결국 두세 기능이 섞인 채로 끝나버린다. 사람도 이런 실수를 한다. 에이전트는 더 자주 한다.

 

그래서 “작업 단위”를 작게 묶는 규칙은 생각보다 중요하다.

 

기능 하나 끝나면 커밋한다.
커밋 전 테스트를 돌린다.
여러 기능을 동시에 수정하지 않는다.
세션 시작할 때 현재 상태를 확인한다.

 

이런 문장은 심심해 보이지만 효과가 세다. 이유는 간단하다. 에이전트가 길을 잃었을 때 돌아올 기준점이 생기기 때문이다.

 

OpenAI 팀도 비슷한 이야기를 했다. 에이전트가 고전하고 있다는 건 모델이 멍청하다는 뜻이 아니라, 작업 경계를 더 잘라야 한다는 신호일 수 있다. 빠진 도구가 있는지, 피드백 루프가 약한지, 문서가 너무 크거나 흐린지 점검해야 한다. 중요한 건 “왜 못하지?”라고 묻는 게 아니라 “어디서 범위가 흐려졌지?”를 보는 쪽이다.

 

서브 에이전트의 목적은 분업보다 격리다

 

서브 에이전트를 쓰는 이유도 종종 오해된다.
사람들은 역할놀이처럼 생각한다.
기획 담당, 구현 담당, 리뷰 담당을 세우면 더 체계적일 거라고.

 

물론 그럴 수도 있다.
근데 실무에서 더 중요한 건 역할 분담보다 컨텍스트 격리다.

 

큰 작업을 한 덩어리로 들고 있으면 컨텍스트가 금방 탁해진다. 그래서 특정 조사나 분석만 따로 떼서 다른 에이전트에 넘기는 게 낫다. 예를 들어 “이 버그 좀 봐줘”는 너무 넓다. 대신 “src/auth/session.ts에서 refreshToken 갱신 시 동시 요청 충돌이 의심되니, race condition 여부를 확인하고 mutex나 debounce 쪽 수정안을 제안해라” 정도로 좁혀야 한다. 이건 프롬프트를 잘 쓴다는 얘기가 아니라, 작업 표면적을 줄인다는 얘기에 가깝다.

 

서브 에이전트는 상위 대화를 공유하지 않는다고 생각하는 편이 안전하다. 방금 방에 들어온 똑똑한 동료처럼 다뤄야 한다. 배경, 의심 지점, 원하는 결과물을 짧고 명확하게 줘야 한다. 그렇지 않으면 상위 에이전트가 알고 있던 맥락을 서브 에이전트가 전혀 모른 채 엉뚱한 탐색을 시작한다.

 

그리고 결과가 별로면 한 번에 포기하지 말고, 최대 두세 번 정도 후속 질문으로 좁혀 들어가는 루프를 만드는 편이 낫다. 이건 사람이 동료에게 조사 맡기는 방식과 거의 같다. “별거 없네요”라는 답이 오면, 그걸 그대로 믿고 끝내는 게 아니라 “그럼 이 경로는 확인했어?”, “동시 요청 시나리오는 재현했어?”를 한 번 더 묻는다. 하네스는 결국 이런 루프를 자동화하는 일이다.

 

CI와 린터는 가장 값싼 교사다

 

에이전트에게 뭔가를 학습시킨다는 말을 들으면 다들 거창한 메모리 시스템이나 리플렉션 루프를 떠올리는데, 솔직히 대부분 프로젝트에서는 그 전에 할 일이 있다.

 

기존 CI를 잘 읽게 만드는 것.

 

이미 있는 린터, 테스트, 빌드 파이프라인이 있다면 그걸 먼저 에이전트의 피드백 루프로 연결하는 편이 훨씬 싸다. CI 실패 로그를 읽고, 그 에러를 보고, 다시 수정하게 만드는 것만으로도 효과가 꽤 크다. 왜냐하면 그 피드백은 이미 프로젝트에 맞춰져 있기 때문이다. 사람이 합의해 놓은 규칙이 그대로 들어 있다.

 

여기서 중요한 건 실패를 “무시하지 못하게” 만드는 것이다. 린트 에러를 넘어가거나, 타입 에러가 있는 상태로 커밋하거나, 테스트를 건너뛰는 습관이 남아 있으면 결국 사람이 그 뒤치다꺼리를 하게 된다. 프롬프트로 “무시하지 마라”라고 적는 건 약하고, 실패 자체를 진행 불가 상태로 만드는 편이 훨씬 낫다.

 

나는 이걸 하네스에서 가장 ROI 높은 부분 중 하나라고 본다.
새로운 기술을 붙이지 않아도 된다.
이미 있는 검사 체계를 에이전트 쪽 루프로 연결하기만 하면 된다.

 

관찰 가능성이 없으면 에이전트는 계속 헛짚는다

 

또 하나 자주 놓치는 게 있다.
에이전트가 자기 작업 결과를 볼 수 있어야 한다는 점이다.

 

코드만 읽게 하면 절반밖에 못 한다.
런타임 로그를 못 보고, 브라우저를 못 열고, 실제 화면을 못 확인하면 자꾸 추측으로 고친다. 이건 사람이 디버깅할 때 로그도 없이 코드만 들여다보는 것과 비슷하다. 가능은 하지만 비효율적이고, 자주 틀린다.

 

Anthropic이 브라우저 자동화 도구를 붙였을 때 코드만으로는 안 보이던 UI 버그를 실제 상호작용으로 찾아낸 사례가 나왔던 것도 그래서다. 브라우저 네이티브 얼럿이나 예상 못 한 모달, 스크롤 위치 문제 같은 건 소스만 봐서는 확신하기 어렵다. 직접 눌러보고, 눈으로 확인하고, 로그를 읽어야 한다.

 

실무에서 이건 꽤 중요하다.
“기능 완료” 선언을 코드 기준이 아니라 사용자 행동 기준으로 바꿔주기 때문이다.

 

그래서 로그 접근, 화면 자동화, 기본적인 메트릭 확인 정도는 가능하면 빨리 열어주는 편이 낫다. 에이전트가 스스로 자기 출력을 검증할 수 있어야 하네스가 점점 덜 사람 의존적으로 돌아간다.

 

보안은 마지막 장식이 아니라 구조 한가운데 있어야 한다

 

하네스를 강화할수록 보안 이야기를 뒤로 미루기 쉽다.
먼저 잘 돌게 만들고, 나중에 잠그자는 식이다.

 

근데 이건 꽤 위험하다.

 

에이전트에게 도구를 더 주고, 파일 접근을 더 열고, 외부 시스템과 연결할수록 공격 표면도 같이 넓어진다. 그리고 프롬프트 인젝션은 “누가 일부러 공격할 때만 생기는 특수 상황”이 아니라, 악의적인 텍스트가 컨텍스트 안으로 들어올 수 있다는 전제를 항상 깔아야 하는 문제다. 도구 설명이 거짓말할 수도 있고, HTML이나 문서 안에 유도 문장이 숨어 있을 수도 있다. 이걸 예외 상황으로 보면 늦는다.

 

그래서 최소한의 분리는 빨리 해야 한다.
개인 계정과 에이전트 계정을 분리하고,
자격 증명은 짧게 가져가고,
비신뢰 작업은 격리된 환경에서 돌리고,
아웃바운드 네트워크를 기본 차단하고,
민감 경로 접근을 좁혀야 한다.

 

이런 얘기는 늘 재미없다.
근데 한번 사고 나면 제일 비싸다.

 

실제로 보고된 취약점들을 보면, “신뢰 확인 전에 실행됐다”, “기본 URL 조작으로 요청이 먼저 나갔다” 같은 식으로 생각보다 낮은 층에서 사고가 난다. 거창한 자율 에이전트 철학보다, 프로세스 그룹 킬과 데드맨 스위치 같은 지루한 장치가 더 중요한 순간이 있다. 하네스 엔지니어링은 멋진 오케스트레이션만이 아니라, 이 지루한 안전장치까지 포함한 말이어야 한다.

 

미래 얘기보다 먼저, 템플릿이 생길 가능성은 높다

 

앞으로 어떻게 바뀔까를 말할 때 다들 자기개선 하네스나 병렬 오케스트레이션 같은 그림을 먼저 꺼낸다. 물론 그 방향도 맞다. 에이전트가 자기 실행 흔적을 보고 하네스 수준의 원인을 역추적하는 흐름은 분명히 올 것이다. Meta나 LangChain 쪽에서 탐색하는 그림도 흥미롭다.

 

근데 그 전에 더 빨리 올 변화가 하나 있다.

 

팀들이 하네스를 템플릿처럼 갖게 된다는 것.

 

생각해보면 대부분 조직은 기술 스택이 몇 가지 안 된다. Next.js + TypeScript + Postgres 조합, React SPA + API 서버 조합, Python 백엔드 조합… 결국 반복된다. 그렇다면 매번 처음부터 하네스를 새로 짜는 대신, 스택별 기본 하네스를 출발점으로 쓰게 될 가능성이 높다. 이미 그런 시도들이 조금씩 나오고 있다. 구조화된 스킬 묶음, 기본 MCP 조합, 서비스 디자인 시스템을 마크다운으로 패키징하는 흐름 전부 같은 방향이다.

 

이게 굳어지면 프레임워크를 보는 기준도 달라질 수 있다. 예전엔 개발자 경험이나 생태계, 코드 스타일 취향이 큰 기준이었다면, 앞으로는 “이 스택은 좋은 하네스를 얹기 쉬운가?”가 더 중요해질 수 있다. 사람이 쓰기 좋은 프레임워크와 에이전트가 덜 삐끗하는 프레임워크가 완전히 같지는 않을 수도 있다.

 

레거시는 결국 한 번은 맞아야 한다

 

여기서 약간 불편한 얘기도 해야 한다.

 

AI 에이전트와 함께 처음부터 자란 코드베이스와, 그 이전 시대의 레거시 코드베이스 사이에는 분명히 격차가 생긴다. 레거시에 하네스를 붙이는 일은 정적 분석 도구를 처음 도입할 때랑 비슷하다. 온갖 경고가 한꺼번에 터지고, 어디서부터 손대야 할지 감이 안 온다. 구조가 흐리고, 규칙이 암묵적이고, 테스트가 약하면 에이전트는 계속 길을 잃는다.

 

그래도 어쩔 수 없다.
어딘가에서는 시작해야 한다.

 

중요한 건 레거시 전체를 한 번에 AI 친화적으로 만들겠다는 식의 야심찬 계획이 아니다. 가장 자주 건드리는 경로 하나, 가장 자주 실패하는 작업 하나부터 잡는 편이 낫다. 로그인 플로우, 결제 흐름, 빌드 파이프라인, 프론트 공용 컴포넌트처럼 반복적으로 일이 모이는 곳부터. 거기서 규칙을 만들고, 검사 루프를 붙이고, 작업 단위를 줄이면 된다. 하네스는 대부분 그렇게 자란다.

 

지금 당장 할 수 있는 건 의외로 소박하다

 

여기까지 읽으면 뭔가 큰 시스템을 도입해야 할 것 같지만, 실제 첫 걸음은 별로 화려하지 않다.

 

프로젝트 루트에 짧은 컨텍스트 파일 하나 두기.
에이전트가 실제로 한 실수를 거기에 한 줄씩 추가하기.
--no-verify 같은 우회로 차단하기.
파일 수정 뒤 포맷팅과 타입 체크를 자동으로 걸기.
한 번에 하나의 기능만 다루게 커밋 단위를 줄이기.
브라우저나 로그처럼 결과를 직접 확인할 수 있는 도구 하나 열어주기.

 

이 정도만 해도 체감이 꽤 달라진다.

 

일주일쯤 지나면 필요한 MCP를 3~5개 수준으로만 선별해서 붙여볼 수 있고, 반복되는 조사 작업은 서브 에이전트로 떼볼 수도 있다. 한 달 정도 지나면 디렉토리별 규칙 파일, 진행 로그, 기능 리스트, CI 피드백 루프까지 붙일 수 있다. 그런데 순서를 거꾸로 잡으면 안 된다. 처음부터 다 하려다 보면 거의 항상 문서만 남는다.

 

병목은 모델이 아니라 환경인 경우가 많다

 

이 시리즈를 관통하는 결론은 결국 여기로 돌아온다.

 

에이전트가 기대만큼 안 나오면, 사람은 제일 먼저 모델을 의심한다. 더 좋은 모델을 쓰면 해결될 것 같고, 더 긴 컨텍스트를 사면 좋아질 것 같고, 더 비싼 추론 모델로 바꾸면 뚫릴 것 같다. 물론 그런 개선도 있다. 하지만 실제 팀 단위 생산성에서는 병목이 다른 곳에 있는 경우가 훨씬 많다.

 

도구 연결이 허술하고,
실패 후 복구 루프가 없고,
테스트가 약하고,
문서가 너무 크거나 낡았고,
위험한 행동을 막는 구조가 없다.

 

이 상태에서 모델만 바꿔봐야, 잘하는 속도로 더 빨리 망가질 뿐이다.

 

반대로 하네스가 잘 잡히면 모델 격차는 생각보다 덜 치명적일 수 있다. 모델 성능은 계속 상향 평준화된다. 오늘 앞선 모델이 몇 달 뒤에도 계속 앞서 있을 거라고 장담하기 어렵다. 그런데 하네스는 다르다. 그건 팀이 자기 환경에 맞게 쌓은 운영 자산이다. 도구 연결 방식, 피드백 루프, 문서 배치, 아키텍처 강제, 보안 경계. 이런 건 모델 출시처럼 밖에서 떨어지지 않는다. 안에서 직접 만들어야 한다.

 

예전에는 코드를 얼마나 정확하게 짜느냐가 개발자의 엄밀함이었다면, 이제는 AI가 덜 실수하도록 환경을 얼마나 엄밀하게 설계하느냐가 점점 더 중요해지고 있다. 코드 작성의 정밀함이 환경 설계의 정밀함으로 이동하는 셈이다.

 

그래서 코딩 에이전트가 답답할 때는, 모델 욕부터 하기 전에 먼저 이 질문을 던지는 편이 낫다.

 

지금 내 저장소에서
에이전트가 반복적으로 망가지는 지점은 어디고,
그걸 다시 못 하게 막는 가장 작은 구조는 뭔가.

 

대부분의 경우, 진짜 답은 그 질문 쪽에 있다.