문제해결.zip작업실준비 중문제 접수
스크랩← 스크랩

결국 모든 회사는 하네스가 된다

Shrivu Shankar 블로그 (2026-08-24, 영문)원문 보기 →

요즘 AI 개발 쪽에서 '하네스'라는 말이 부쩍 자주 들린다. 원래는 말에 채우는 마구를 가리키는 말이다. AI 모델을 힘 좋은 말이라고 치면, 하네스는 그 말이 실제로 일을 하게 만드는 장비 일체다. 모델은 혼자 두면 글로 대답하는 것밖에 못 한다. 파일을 열어 볼 손도 없고, 어제 한 일도 기억하지 못한다. 그 바깥에서 도구를 쥐여 주고, 볼 자료를 챙겨 주고, 한 일을 적어 두는 게 하네스다. 개발자들이 쓰는 Claude Code가 대표적이다. Anthropic은 Claude Code를 "모델 바깥에서 도구를 주고, 모델이 보는 내용을 관리하는 층"이라 설명하고, 이 층을 하네스라고 부른다. 말이 아무리 좋아도 고삐와 쟁기 없이는 밭을 못 가는 것과 같다.

하네스 안에 뭐가 들었는지는 예를 보면 쉽다. 모델은 대화창이 바뀌면 앞일을 잊는다. 그래서 Anthropic은 긴 작업을 맡길 때 세 가지를 붙였다. 지금까지 한 일을 적는 진행 기록, 만들어야 할 기능 200여 개를 적은 목록, 단계마다 남기는 저장 기록이다. 일을 이어받은 모델은 이걸 먼저 읽고 하던 데서부터 시작한다. OpenAI 팀은 AI에게 두꺼운 설명서를 통째로 주지 않았다. 100줄 남짓한 목차만 주고, 필요할 때 자세한 문서를 찾아가게 했다. 이렇게 기억을 대신 들어 주고 길을 알려 주는 장치가 다 하네스다.

그리고 같은 말이라도 마구에 따라 일솜씨가 달라진다. AI 개발 도구 회사 LangChain은 모델은 그대로 두고 하네스만 손봐서, 코딩 과제 시험 점수를 52.8%에서 66.5%로 올렸다고 밝혔다. 순위로는 30위 밖에서 5위 안으로 올라선 셈이다. OpenAI는 사람이 코드를 한 줄도 직접 쓰지 않고 AI에게만 맡겨 다섯 달 동안 제품을 만들어 봤다. 처음엔 진도가 생각보다 느렸는데, 모델 실력이 모자라서가 아니라 일할 환경이 덜 갖춰져서였다고 한다. 그래서 엔지니어들의 일은 코드를 쓰는 데서 AI가 일할 판을 짜는 쪽으로 바뀌었다.

글쓴이 Shrivu Shankar는 여기서 한 걸음 더 나간다. 소프트웨어를 만들어 파는 회사라면, 알아차렸든 못 했든 결국 회사 전체가 하나의 하네스가 된다는 거다. 처음엔 사람이 다 만든다. 그러다 개발자가 AI를 옆에 두고 같이 일하고, 기획이나 영업도 뒤따른다. 다음엔 AI 여러 개를 서버에 띄워 두고, 사람은 일을 맡긴 뒤 결과를 확인한다. 노트북 한 대로 스무 개를 돌릴 수는 없으니까. 마지막엔 순서가 뒤집혀서, AI가 먼저 할 일을 찾아오고 사람은 그걸 받아 보는 쪽이 된다.

여기까지 들으면 "AI가 찍어 낸 어설픈 물건만 쏟아지는 거 아니야?" 하는 걱정이 들 만하다. 글쓴이는 그게 사람을 몽땅 빼 버린 회사를 떠올려서 드는 걱정이라고 본다. 잘 만든 하네스는 오히려 사람이 꼭 봐야 할 순간을 골라서 부른다. 화면을 새로 고친다면, AI가 사용자 의견을 모으고 몇 가지 안을 미리 시험해 본 다음, 괜찮은 것 몇 개만 디자이너 앞에 가져오는 식이다. 사람도 하네스의 한 부분인 셈이다. 물론 글쓴이도 아직은 어렵다고 인정한다. 자기 회사에서 꽤 오래 해 봤는데도, 뭘 할지 정하고 검토하는 일까지 AI에게 맡기긴 힘들었다고.

그럼 하네스는 사다 쓰면 되지 않을까? 글쓴이는 반만 맞다고 한다. 코드 짜기 같은 낱낱의 작업은 남이 만든 도구를 끼워 써도 된다. 하지만 맨 꼭대기, 그러니까 뭘 만들지 정하고 돌아온 결과를 받아 보는 자리만큼은 직접 쥐고 있어야 한다. 그 자리까지 통째로 맡길 수 있다면, 그 사업은 이미 누가 해도 똑같은 사업이 된 거라서다. Stripe, Ramp, DoorDash가 개발용 AI 도구를 직접 만들어 쓰기 시작한 걸 글쓴이는 그 신호로 본다.

인사이트

모델은 이제 누구나 빌려 쓴다. 다들 비슷한 말을 빌려 타는 셈이다. 그러면 차이는 어디서 날까. 무슨 자료를 쥐여 줄지, 어디서 멈추고 사람을 부를지, 무엇만큼은 남에게 맡기지 않을지. 말보다 마구를 얼마나 잘 짜 두었느냐에서 갈리는 시대다.

일이 막히는 자리도 옮겨 가고 있다. 예전엔 손이 모자라서 일이 밀렸다. 요즘은 만드는 건 금방인데, 그중 뭐가 맞는지 봐 줄 사람의 시간이 모자라서 밀린다. OpenAI 팀도 코드가 쏟아지자 막힌 곳은 사람이 확인하는 쪽이었다고 적었다. 그래서 손은 기꺼이 맡기되, 눈은 꼭 필요한 곳에 아껴 쓰는 게 실력이 되어 간다.

지금 내 일에서 꼭 내 눈으로 봐야 하는 건 뭐고, 그냥 습관처럼 다 들여다보고 있는 건 뭘까.

확인한 것
  1. 기사모델은 대화창이 바뀌면 앞일을 잊는다. 그래서 진행 기록 · 기능 목록 · 저장 기록을 붙였다

    확인맞다. 첫 차례의 모델이 진행 기록 파일, 기능 200개 넘는 목록(처음엔 전부 '안 됨'으로 표시), 첫 저장 기록을 깔아 둔다. 다음 차례의 모델은 이 기록과 저장 이력부터 읽고 이어 간다. 기능 목록은 모델이 일을 덜 하고 끝났다고 말하는 걸 막으려고 둔 것이다

    Anthropic 엔지니어링 블로그 (Justin Young, 2025-11-26)

  2. 기사사람이 코드를 한 줄도 쓰지 않고 다섯 달 동안 제품을 만들었다. 처음 더뎠던 건 모델이 아니라 환경 탓이었다

    확인OpenAI 자체 기록이다. 엔지니어 세 명으로 시작해 지금은 일곱 명, 코드 약 100만 줄, 코드 변경 약 1,500건(1인당 하루 3.5건). 손으로 짰을 때의 약 10분의 1 시간이라는 건 그쪽 추정이다. 정식 출시 전 판으로 사내와 일부 바깥 시험 사용자가 쓴다. AI에게 주는 안내 문서는 약 100줄짜리 목차로 두었고, 코드가 늘자 사람이 확인하는 쪽에서 막혔다고 적었다

    OpenAI 엔지니어링 블로그 (Ryan Lopopolo, 2026-02-11)

  3. 기사모델은 그대로 두고 하네스만 손봐서 52.8%에서 66.5%로 올렸다

    확인LangChain 자체 발표다. 모델(gpt-5.2-codex)은 고정하고 지시문 · 도구 · 호출 앞뒤에 끼우는 점검 장치만 바꿨다. 시험은 Terminal Bench 2.0, 순위는 30위 밖에서 5위 안. 공식 순위표는 지금 다음 판으로 넘어가 있어 2.0 당시 기록을 따로 대조하지는 못했다

    LangChain 블로그 (Vivek Trivedy, 2026-02-17)

  4. 기사가장 좋은 모델로도 무엇을 할지 정하고 검토하는 일까지 맡기긴 어렵다. 우리도 오래 해 봤다

    확인글쓴이가 일하는 Abnormal AI의 'Nora'다. 글쓴이가 그 회사 블로그에 공동 필자로 올라 있다. 2024년 5월 사내 슬랙 봇으로 시작해, 2026년 5월 기준 하루 코드 변경 200건 넘게, 요청 약 1,000건을 처리한다. 만드는 일은 이미 많이 맡겼는데도 바깥쪽 일은 어렵다는 이야기다

    Abnormal AI 개발 블로그 (2026-05-04)

  5. 기사Stripe는 개발용 AI 도구를 직접 만들어 쓴다

    확인'Minions'. 사람이 한 줄도 쓰지 않고 검토만 한 코드 변경이 매주 1,300건 넘게 합쳐진다(2026-02-19 기준, 열흘 전 첫 글에선 1,000건). 직접 만든 이유로 흔치 않은 언어 조합과 자체 라이브러리를 든다. 원문이 이 대목에 건 링크는 회사 글이 아니라 개발 도구 업체 Ona의 소개 페이지라, 세 회사의 글을 따로 열었다

    Stripe 개발 블로그 (Alistair Gray, 2026-02-19)

  6. 기사Ramp도 직접 만들어 쓴다

    확인'Inspect'. 출시 두어 달 만에 프런트 · 백엔드 저장소에 합쳐진 코드 변경의 약 30%를 썼다(2026-01-12 글 기준). 기획자와 디자이너도 쓴다. 이후 비율이 더 올랐다는 숫자는 2차 기사에만 있어 넣지 않았다

    Ramp 개발 블로그 (2026-01-12)

  7. 기사DoorDash도 직접 만들어 쓴다

    확인'Flux'. 2026년 한 달 동안 개발 작업 13만 건을 처리했고, 매주 코드 검토를 2만 5천 건 넘게 돌린다. 코드를 쓰는 건 거의 풀렸고, 어려운 건 맞는 환경 · 도구 · 권한 · 제약을 주는 일이었다고 적었다. 처음엔 코드 검토 하나로 좁게 시작해 신뢰를 쌓았다

    DoorDash 개발 블로그 (2026-08-11)

  8. 기사소프트웨어를 파는 회사는 결국 회사 전체가 하네스가 된다

    확인글쓴이의 전망이다. 원문에 자체 숫자나 조사는 없고, 근거로 든 것은 위의 회사 사례와 자기 회사 경험이다. 발행 6주 뒤(10/7)까지 글쓴이가 이 주장을 고치거나 거둔 글은 없다

    원문 · 글쓴이 글 목록

2026.10.07에 확인했습니다.

함께 본 것
원문 보기 →하네스가 곧 회사다 · Shrivu Shankar 블로그 (2026-08-24, 영문)