모델이 아니라면, 당신은 하네스다
GDG Build with AI Seoul 2026에서 이경록의 발표를 듣고 정리한 기록 — 프롬프트에서 컨텍스트, 그리고 하네스로
2022년에 나는 죄인이었다. AI가 엉뚱한 답변을 내놓을 때마다 속으로 자책했다. 프롬프트를 잘못 썼구나. 더 정교하게 다듬었어야 했는데. 그 시절 우리 모두는 모델이 내 마음을 읽어주길 기대하면서, 정작 내 부족함을 탓하고 있었다. 프롬프트 엔지니어링 강의를 듣고, 예쁜 템플릿을 메모장에 복사해두고, 붙여넣기를 반복했다.
그 단계가 지나고 나서야 깨달았다. 문제는 내가 아니라 구조였다. 조직 차원에서 모든 사람이 프롬프트 전문가가 될 수는 없다. 그래서 우리는 컨텍스트를 시스템화하기 시작했다. RAG로 지식을 뽑아다 넣고, 메모리를 붙이고, 툴 콜링으로 중간 단계를 자동화했다. 사용자의 입력이 조금 허술해도 시스템이 보완해주는 구조. 꽤나 그럴듯했다.
그런데 1년을 쓰고 나서 이런 질문을 받았다. “첫 달이랑 지금이랑 얼마나 달라졌어요?” 솔직히 말하기 어려웠다. 처음 만들어놓은 게 그대로였다. 좋아진 게 있다면, 개발자가 손수 고쳤기 때문이다. AI가 학습해서 나아진 게 아니라.
피드포워드와 피드백 사이
프롬프트 엔지니어링도, 컨텍스트 엔지니어링도, 하네스도 결국 같은 게임을 하고 있다. LLM이 받아들일 수 있는 컨텍스트는 유한하고, 우리는 그 제한된 공간에 어떤 정보를 어떻게 넣을지를 경쟁하는 것이다. Nvidia라고 해서 무한 컨텍스트를 쓸 수 있는 게 아니다. Gemini든, Claude Opus든, 한정된 공간 안에서 동등하게 싸운다.
이전까지 우리가 해온 건 피드포워드였다. 입력 단계의 맥락을 최대한 정교하게 구성하면 좋은 출력이 나온다는 믿음. 그래서 컨텍스트가 잘못 나오면 입력을 고쳤다. 사람이 직접 들어가서, 시스템 프롬프트를 다듬고, RAG 파이프라인을 손봤다. 그게 루틴이 됐다.
하네스가 다른 이유는 여기에 피드백이 붙는다는 점이다. 답변이 나온 뒤에 그 답변을 보고 입력 방식 자체를 수정하는 루프. 개발자가 수작업으로 고쳐주던 걸, 시스템이 스스로 업데이트하는 구조. 빨간색으로 고정돼 있던 시스템 프롬프트와 컨텍스트 덩어리가 말랑말랑한 마크다운으로 바뀐다. Skills, Tools, Rules, Middleware. 사람도 수정하기 쉽고, AI도 수정하기 쉬운 형태.
예를 들면 이런 식이다. RAG에서 C1, C2, C3, C4를 가져왔는데 정답은 C2와 C4뿐이다. 하네스 이전엔 오답을 체크하고 넘겼다. 하네스에서는 C1이 남고 C4가 탈락했을 때, “Verification Logic에 허점이 있구나”를 감지하고 그 로직 자체를 고쳐버린다. 다음에 같은 오류가 반복되지 않는다. 쓰면 쓸수록 나아지는 시스템의 작동 방식이 바로 이거다.
4월에 비가 안 온다는 가정으로 야외 워크샵을 예약해달라고 시켰는데 비가 왔다. LLM은 친절하게 물어봐줄 것 같지만, 우리가 bypass permissions를 선호한다는 걸 안다. 그래서 스스로 판단해서 캔슬을 해버린다. 실내로 바꿨어야 했는데. 이런 엣지 케이스를 만났을 때, 과거엔 그냥 넘어갔다. 지금은 이 실패에서 룰을 추가한다. “워크샵 때 천재지변이 생기면 캔슬이 아니라 실내 전환이나 확인 요청을 해라.” 그 룰이 하네스에 쌓이고, 다음에는 같은 실수를 하지 않는다.
정확도 78%의 함정
SOTA 모델도 단일 태스크 정확도가 95%다. 에러가 5%다. 그걸 10번 반복하면 정확도가 60%로 떨어진다. Terminal-bench 1등이 75%인 이유가 여기 있다. 우리가 Claude Code를 돌려놓고 다른 일을 하는 건, 얘가 나 대신 오래오래 잘 해줄 거라는 믿음 때문인데, 실제로 작업이 길어질수록 오류가 누적되고 결과물 품질은 조용히 무너진다.
그리고 컨텍스트 길이의 문제가 여기에 겹친다. Opus 기준으로 20만 토큰에서 정확도가 91.3%다. 100만 토큰을 꽉 채우면 같은 모델인데 78%로 떨어진다. 100만 토큰이 된다고 해서 여유롭게 쓰면 안 된다는 얘기다. 20만 토큰 안팎에서 써야 된다. 이게 Progressive Disclosure가 필요한 이유다. Skills를 로드할 때도 파일 전체를 다 읽는 게 아니라 frontmatter만 먼저 읽고, 본문이 필요한지 판단한다. 필요한 것만, 필요한 때에.
150만 줄짜리 코드를 리팩토링하는 프로젝트를 한 달 잡고 시작하면, 26일을 마크다운 깎는 데 쓴다. 코드 한 줄 못 건드린다. Source of Truth를 만들고, 에이전트가 참조할 맥락을 정제하는 게 그만큼 중요하다. 완벽한 계획을 가지고 가도 오류는 난다. “누구나 완벽한 계획을 가지고 있다. 실패하기 전까지.” 실패했을 때 그 실패를 어떻게 시스템에 돌려보내느냐가 경쟁력이다.
조직에서 하네스를 쓸 때 또 하나의 함정이 있다. 자가 진화하는 시스템의 가장 큰 매력은 복리다. 쓰면 쓸수록 쌓이고, 쌓일수록 좋아진다. 그런데 이게 과적합 위험을 품고 있다. 나의 기호, 나의 판단 편향이 시스템에 반영되면 “얘가 나를 잘 이해하는구나”라고 느껴지지만, 조직 차원의 성과와 다른 방향일 수 있다. 평가 시스템이 먼저 있어야 하는 이유다. 무엇을 근거로 스킬에 반영할지, 누가 승인할지, 어떻게 롤백할지. 거버넌스 없이 Self-evolving은 그냥 편향이 자라는 시스템이다.
팀 하네스를 만들어서 20명한테 공유했다가 일주일 만에 그게 틀렸다는 걸 깨달았다. 내가 일하는 방식을 팀에 강제하는 순간 그 하네스는 내 것이지 팀 것이 아니다. 타협점을 찾았다. 개인 스킬, 팀 스킬, 회사 자산으로 분리하고, 각 레벨은 각 레벨의 합의 방식으로 운영한다. 하네스는 나의 일을 줄여주는 도구에서 시작한다. 거기서 조직으로 확장하는 거지, 처음부터 조직 최적화를 강요할 수 없다.
“If you are not the model, you are the harness.” 어디선가 읽은 문장인데, 생각할수록 정확하다. 모델은 점점 상품이 된다. Claude를 쓰든, GPT를 쓰든, 같은 모델을 쓰는 사람은 점점 많아진다. 그 모델을 어떻게 운용하느냐가, 즉 어떤 하네스를 가지고 있느냐가 개인의, 조직의 경쟁력이 된다. 내가 수년간 쌓아온 스킬과 룰과 피드백 루프는 옆 사람한테 그냥 복사해줄 수 없다. 그게 노하우이기 때문이다.
오픈 소스 하네스를 다운받으면 그 안에 담긴 온갖 노하우가 내 것이 될 것 같지만, CLAUDE.md 안의 에이전트들은 내 프로젝트에 최적화되어 있지 않다. reference로 참조하고, 내 프로젝트에 맞게 고쳐야 한다. 그게 지금 우리가 해야 할 일이다. 모델을 더 잘 쓰는 법이 아니라, 모델을 둘러싼 구조를 어떻게 만들고 키워갈 것인가.
모델은 상품이 될 것이고, 동작하는 방식이 경쟁 우위가 될 것이다. 지금 당장, 개인 차원에서부터 시작하는 게 맞다.
이 글은 GDG Build with AI Seoul 2026에서 이경록의 발표를 듣고 정리한 기록입니다.