100만 줄 코드를 AI로 40일에 만든 실전기 2026 — 하네스 엔지니어링이 진짜 경쟁력인 이유

Posted on by

AI 코딩 얘기만 나오면 다들 모델 이름부터 외친다. “뭐가 더 똑똑하냐”, “생각 토큰이 얼마냐”, “벤치 점수가 얼마냐”.

근데 진짜 실무 얘기로 들어가면 은근 시시하게 결론 난다.

결국 승부는 모델보다 하네스다.

40일 동안 약 100만 줄을 만들었다는 Backend.AI:GO 사례를 보면 더 그렇다. 여기서 무서운 건 “AI가 코드를 많이 썼다”가 아니다. 그 정도 물량을 인간이 안 터지고 굴리게 만든 운영 방식이 더 중요하다.

Quick Answer

AI로 짧은 기간에 엄청난 코드 양을 뽑아낸 팀이 공통으로 보여주는 건 세 가지다. 첫째, 결과물을 바로 뽑으려 하지 않고 컨텍스트를 먼저 쌓는다. 둘째, 모델 하나에 올인하지 않고 하네스와 워크플로를 계속 튜닝한다. 셋째, 쓰는 속도보다 검증·handoff·재시도 루프를 더 강하게 만든다. 즉 “AI가 코드를 대신 써줬다”보다 “사람이 AI가 일하게 만드는 장치를 만들었다”가 더 정확한 요약이다.

이 글이 필요한 사람

  • AI 코딩 도구는 잔뜩 써봤는데 팀 생산성은 생각보다 안 오른 사람
  • Claude Code, Codex, Cursor를 써도 자꾸 재작업과 검수가 터지는 사람
  • “모델 바꾸면 해결되겠지” 하다가 통장과 멘탈만 깎인 사람
  • 에이전트 코딩을 개인 장난감이 아니라 팀 운영 레벨로 붙이고 싶은 사람

지금 결론

  1. 100만 줄을 만든 비밀은 모델 스펙보다 하네스 엔지니어링에 있다.
  2. 좋은 팀은 결과물을 한 번에 뽑으려 하지 않고 생성 장치 자체를 반복 개선한다.
  3. 같은 모델을 써도 컨텍스트 설계, 검증 루프, handoff 기준이 다르면 결과가 완전히 달라진다.
  4. 그래서 AI 코딩 시대 경쟁력은 “누가 더 비싼 모델 쓰나”보다 “누가 더 덜 망가지게 굴리나”로 간다.

왜 이 사례가 중요한가

내가 이 얘기에 꽂힌 이유는 숫자보다 구조 때문이다.

  • 40일
  • 약 100만 줄
  • 대규모 토큰 사용

이 셋만 보면 “와 미쳤네”인데, 실무 관점에서 더 중요한 건 딴 데 있다.

그 많은 산출물이 왜 팀을 박살내지 않았냐는 거다.

AI 코딩은 잘못 붙이면 코드가 아니라 쓰레기 산만 빨리 쌓인다. 리뷰는 못 따라가고, 히스토리는 더러워지고, 컨텍스트는 세션마다 새고, 사람은 더 피곤해진다.

그래서 이 사례에서 정말 봐야 할 건 “AI가 많이 썼다”가 아니라:

  • 어떤 컨텍스트를 먼저 줬는지
  • 어떤 루프로 검증했는지
  • 어디서 자동화하고 어디서 사람을 세웠는지

이런 운영 계층이다.

Agentic Workflow에서 진짜 중요한 것

GeekNews 요약 메모를 읽으면서 제일 와닿은 문장은 이거였다.

결과물을 바로 뽑으려 하지 말고, 생성 장치를 계속 개선하라.

이게 말은 담백한데 실전에서는 꽤 무섭다.

보통은 이렇게 생각한다.

  • 프롬프트 더 잘 쓰면 되겠지
  • 더 센 모델로 바꾸면 되겠지
  • 한 번 더 돌리면 되겠지

근데 팀 단위로 가면 이 셋 다 오래 못 간다. 결국 필요한 건 “이번 한 번 잘 되게 하는 법”이 아니라 매번 덜 망하게 돌아가게 하는 법이다.

내가 실제로 느낀 하네스의 차이

이건 남의 이야기만은 아니다. 나도 블로그 OS 돌리면서 비슷한 걸 꽤 많이 봤다.

1. 모델보다 컨트롤 플레인이 더 중요하다

Claude든 Codex든 잘 쓰는 순간도 있고 멍청한 순간도 있다. 근데 하네스가 있으면 멍청한 순간에 덜 망가진다.

예를 들면:

  • 역할 분리
  • review gate
  • publish contract
  • owner / help_team / next_check

이런 게 있으면 에이전트가 한 번 삐끗해도 회사가 같이 넘어지진 않는다.

2. 컨텍스트는 “많이”보다 “못 찾는 것”이 중요하다

디렉토리 구조 같은 건 에이전트가 읽으면 된다. 진짜 중요한 건 걔가 스스로 모르는 규칙이다.

  • 어떤 글은 배당노마드에 넣으면 안 되는지
  • 어떤 상태는 당일 ops_verified로 닫아도 되는지
  • 어떤 문제는 운영팀이 바로 고쳐도 되는지

이런 게 하네스의 진짜 컨텍스트다.

3. 검증 없는 속도는 그냥 사고다

AI가 빨리 쓰는 건 장점이 아니다. 빨리 쓰고도 안 터지는 구조가 있어야 장점이 된다.

그래서 실무에서는 보통 이 순서가 맞다.

  1. 초안 생성
  2. 구조/팩트 검수
  3. 발행 계약 확인
  4. 운영 검증
  5. 성과 검증

중간에 하나라도 빠지면, 속도는 그냥 사고차량의 가속 페달이 된다.

왜 Claude Code와 Codex가 다르게 느껴지는가

요약 메모에서도 비슷한 포인트가 나오는데, 체감상 이 둘은 철학이 좀 다르다.

  • Claude Code는 사용자 의사와 정렬을 자주 확인하는 쪽
  • Codex는 더 자율적으로 밀어붙이는 쪽

이건 누가 낫다가 아니라, 하네스 설계가 달라야 한다는 뜻이다.

Claude Code는 alignment 루프를 잘 쓰는 팀에 잘 맞고, Codex는 batch와 delegation을 잘 설계한 팀에서 힘이 세다.

그래서 같은 팀에서도:

  • 정밀한 검토가 필요한 일
  • 병렬로 많이 쳐야 하는 일

을 나눠서 붙이는 게 낫다.

실수 TOP 5

실수 1. 모델만 바꾸면 해결된다고 믿는다

진짜 병목이 컨텍스트 누수, 검증 부재, handoff 꼬임인데 모델만 갈아끼우면 돈만 더 탄다.

실수 2. 한 번에 완벽한 산출물을 원한다

한 번에 완벽하게 쓰게 만들려는 팀보다, 생성 장치를 반복 개선하는 팀이 오래 이긴다.

실수 3. 에이전트 역할을 안 나눈다

리서치, 작성, 리뷰, 배포를 한 놈이 다 하면 잘할 때는 빨라 보이는데, 망할 때는 같이 크게 망한다.

실수 4. 검증을 사람 의지에만 맡긴다

사람이 꼼꼼한 건 미덕인데, 시스템이 검증을 안 잡아주면 결국 피곤한 사람이 다 떠안는다.

실수 5. 언제 안 써야 하는지 규칙이 없다

AI 코딩은 다 되는 마법봉이 아니다. 민감한 권한, 법/세금, 배포 위험이 큰 부분은 인간이 더 세게 잡아야 한다.

언제 특히 잘 먹히나

  • 반복되는 코드/문서/운영 루프가 많을 때
  • 팀이 이미 리뷰/검증 문화는 있는데 속도가 부족할 때
  • 사람이 직접 다 하다가 handoff 비용에 지쳐 있을 때
  • “한 명의 천재”보다 “덜 삐끗하는 시스템”이 필요한 팀

언제 오히려 별로인가

  • 작은 일인데 하네스부터 거창하게 깔고 싶을 때
  • 검증 루프 없이 무조건 자동화부터 하고 싶을 때
  • 팀 내 규칙이 아직 없는데 에이전트만 늘리고 싶을 때

이 셋이면 높은 확률로 생산성보다 피로도만 오른다. AI 코딩이 빨라졌는데 사람이 더 피곤한 팀이 딱 여기서 나온다.

FAQ

Q1. 100만 줄 만들었다는 게 진짜 중요한 포인트야?

A. 숫자는 상징일 뿐이고, 더 중요한 건 그렇게 많은 산출물을 팀이 감당 가능하게 만든 운영 방식이다.

Q2. 하네스 엔지니어링은 개발자만 하는 거야?

A. 아니다. 글쓰기 팀이든 운영팀이든, 역할 분리와 검증 루프를 설계하면 이미 하네스 엔지니어링을 하고 있는 셈이다.

Q3. 좋은 모델 하나만 있으면 충분하지 않아?

A. 짧은 단발 작업은 그럴 수 있다. 하지만 팀 단위 반복 작업은 결국 하네스 품질이 생산성을 가른다.

Q4. Claude Code랑 Codex 중 뭘 써야 해?

A. 둘 중 하나가 정답이라기보다, 작업 유형에 맞는 통제 구조를 붙일 수 있느냐가 더 중요하다.

Q5. 지금 당장 뭘 먼저 바꾸면 좋아?

A. 프롬프트 문구보다 먼저 역할 분리, 검증 단계, 실패 시 다음 액션 3개를 문서로 박는 게 체감이 크다.

다음에 읽을 글

출처

  • GeekNews 요약 메모: 260316_[요약] 진짜 내 일을 위한 Agentic Workflow
  • AI Frontier ep86 관련 정리 메모