AI 에이전트를 위한 하네스를 만들었다가, 나 자신을 위한 하네스도 필요하다는 것을 깨달았다

내 에이전트는 주말 동안 12개의 깔끔한 PR(Pull Request)을 제출했다.

하지만 제품은 3주가 지난 지금까지도 출시되지 않았다.

모델을 둘러싼 하네스(Harness)는 제대로 작동했다. 하지만 나를 둘러싼 하네스는 존재하지 않았다. 그리고 이것이 바로 2026년 에이전틱 코딩(Agentic Coding)의 실제 이야기라고 생각한다. 모델이 구축할 수 없어서가 아니라, 모델이 구축한 것을 당신이 끝마치도록 붙잡아줄 무언가가 없다는 것이 말이다.

하네스란 실제로 무엇인가

본격적인 에이전틱 코딩(Agentic Coding)을 해봤다면, 모델 단독으로는 무용지물이라는 것을 이미 알고 있을 것이다. 가공되지 않은 LLM(Large Language Model)은 하네스가 없는 말과 같다. 거친 힘은 있지만, 어디로 향해야 할지 모른다. 하네스는 모델을 둘러싸는 모든 것이다: 범위가 지정된 작업(Scoped tasks), 깔끔한 컨텍스트(Context), 명세 기반 루프(Spec-driven loops), 그리고 모델이 제멋대로 날뛰지 않게 하는 규율(Discipline)까지. 그것이 모델을 실제로 일을 수행하는 에이전트(Agent)로 바꾸는 것이다.

Andrej Karpathy는 실패 모드를 정확하게 짚어냈다: 에이전트가 멍청해지는 이유는 모델이 나빠서가 아니다. 너무 많은 정보, 너무 오래된 정보, 혹은 잘못된 정보를 읽게 하기 때문이다. 그래서 당신은 컨텍스트(Context)를 엔지니어링한다. 모델이 보는 것을 큐레이션(Curate)한다. 단순히 분위기에 휩쓸리는(Vibing) 대신 통제권을 유지한다.

이것은 진정한 기술(Craft)이며, 실제로 효과가 있다. 나는 이 일에 능숙해졌다. 나는 몇 시간 동안 에이전트를 궤도(Rails) 위에 유지할 수 있다.

하지만 아무도 내게 말해주지 않은 것이 있다: 나는 기계를 위한 그 모든 규율을 구축했지만, 나 자신을 위한 규율은 단 하나도 구축하지 않았다는 사실이다.

존재하지 않는 하네스

모델에는 내가 세심하게 관리하는 컨텍스트 윈도우(Context Window)가 있다. 나에게도 컨텍스트 윈도우가 있는데, 사이드 프로젝트를 시작한 지 4일째가 되면 본업, 불안정한 배포(Deploy), 그리고 "이 아이디어는 어차피 별로였어"라는 막연한 느낌으로 가득 차 버린다. 아무도 그것을 축소(Scope down)해주지 않는다. 내가 침묵할 때 아무도 알아차리지 못한다.

에이전트에게는 자신의 출력을 확인하는 루프(Loop)가 있다. 나에게는 루프가 없다. 내가 멈추면, 아무것도 실행되지 않는다. PR(Pull Request)들은 제품의 90%가 완성된 상태로, 세상이 결코 보지 못할 브랜치에 그저 놓여 있을 뿐이다.

이것이 바로 AI가 소프트웨어를 더 좋게 만든 것이 아니라, 더 﫼 나쁘게 만든 부분이다. METR는 2025년에 숙련된 개발자들을 대상으로 실제 과업을 측정했으며, AI 도구를 사용할 때 이들이 19% 더 느려진다는 사실을 발견했다 (arxiv.org/abs/2507.09089). 그 이유는 AI가 쉽고 만족스러운 부분들을 먹어치우고, 당신을 어렵고 지루하며 프로젝트를 망치는 부분에 홀로 남겨두기 때문이다. 에이전트(Agent)는 당신에게 계획과 디프(diff)를 제공할 것이다. 하지만 당신이 4일 차를 건너뛰고 있다는 사실은 알아차리지 못할 것이다.

빌드가 쉬워지는 것이 함정이다

Karpathy는 이를 '에이전트의 해'가 아니라 '에이전트의 﫼 대(decade)'라고 불렀다. 즉, 우리는 그 곡선의 끝이 아니라 시작점에 더 가까이 있다. 그리고 여기 불편한 2차 효과(second-order effect)가 있다. 에이전트 기반 도구들이 좋아질수록, 빌드(build) 과정은 거의 아무것도 남지 않을 정도로 붕괴된다. 주말 사이에 제품의 90%를 만들어내는 것이 이제는 평범한 일이 되었다.

이는 병목 현상(bottleneck)이 사라진 것이 아님을 의미한다. 그것은 한 단계 위로 이동했을 뿐이다.

빌드하는 것이 어려운 부분이었을 때, "완성되지 않았다"는 것은 "만들어지지 않았다"는 뜻이었다. 하지만 이제는 무언가가 﫼 만들어졌고 — 당신의 머신에서 실행도 되지만 — 여전히 출시(ship)되지는 않는다. 더 빠른 빌드는 더 많은 출시를 의미할 예정이었다. 대신 그것은 그저 '거의 완성된 것들'의 더 큰 묘지를 만들어냈을 뿐이다. 완성되지 않은 리포지토리(repo)가 줄어드는 것이 아니라 더 많아졌다. 완성의 격차(completion gap)는 벌어지고 있으며, 에이전트 기반 코딩(agentic coding)에 﫼 능숙해진 사람들에게서 가장 빠르게 벌어지고 있다.

인간을 위한 하네스(harness)란 무엇인가 — 그리고 무엇이 아닌가

그렇다면 당신 자신을 무엇으로 감싸야 하는가?

대시보드(dashboard)는 아니다. 대시보드는 활동을 보여줄 뿐, 당신의 부재를 알아차리지 못한다. 연속 달성 기록(streak counter)은 당신이 포기하는 모습을 지켜보는 더 보기 좋은 방법일 뿐이다. 커뮤니티(community) 또한 아니다. 관객들은 당신이 게시물을 올릴 때는 박수를 치지만, 당신이 2주 동안 사라지면 아무 말도 하지 않는다. 대시보드는 책임감(accountability)이 아니다. 커뮤니티 또한 책임감이 아니다.

실제로 효과가 있는 것은 당혹스러울 정도로 오래된 방식입니다. 바로 읽어주는 사람입니다. 당신을 추적하는 소프트웨어가 아니라, 당신이 침묵할 때 이를 알아차리고 당신이 회피하고 있는 행동을 지적해 주는 사람 말입니다. AI는 추적(track)하지만, 사람은 읽습니다(read). 하네스(harness)의 핵심은 그것이 감싸고 있는 대상이 경로를 벗어나는 순간, 그 대상에 '작용'한다는 점에 있습니다. 모델에게 그것은 컨텍스트 엔지니어링 (context engineering)입니다. 당신에게 그것은 다음 단계를 기대할 이유가 있는 또 다른 사람입니다.

당신은 이미 당신의 에이전트(agent)를 위해 이 사실을 받아들이고 있습니다. 점검 장치도 없이 자율 루프 (autonomous loop)를 배포하며 그저 작업에 집중하기를 바라는 일은 절대 하지 않을 것입니다. 하지만 혼자서 사이드 프로젝트를 시작할 때마다 당신은 자신에게 정확히 그 행동을 하고 있습니다.

솔직한 다음 단계

만약 당신의 프로젝트들이 계속해서 같은 지점에서 무너진다면 — 그리고 그것은 대개 '동일한' 지점, 즉 당신만의 지점일 것입니다 — 유용한 것은 더 많은 동기부여가 아닙니다. 당신의 루프가 실제로 어디에서 깨지는지를 파악하는 것입니다.

저는 바로 그 점을 위해 무료 진단 도구를 만들었습니다. 7개의 질문, 약 2분 소요, 결과 확인을 위한 가입은 필요 없습니다. 이 도구는 당신이 어디에서 멈추는지, 그리고 무엇이 그 흐름을 깨뜨리는지 단 하나의 행동을 지목해 줍니다.

모델을 위한 완벽한 하네스를 설계하고도 정작 아무것도 출시하지 못할 수 있습니다. 당신 자신의 루프가 어디에서 깨지는지 확인해 보세요: mvpbuilder.io/ship-readiness

빌딩 인 퍼블릭 (Building in public). 125일 차.