AI와 함께 일하는 법: 하네스 엔지니어링과 우리의 역할

요즘 개발자 커뮤니티에 가보면 비슷한 이야기가 반복됩니다. "Claude로 하루에 코드 5천 줄 생성했다", "코파일럿이 함수 다 짜준다", 그리고 꼭 따라오는 불안한 질문 - "그럼 우리는 뭘 해야 하지?"

저도 똑같습니다. AI 도구들이 쏟아지면서 신기하기도 하고 불안하기도 했습니다. 특히 Claude가 복잡한 알고리즘을 순식간에 짜내는 걸 보면서 묘한 위기감이 들었습니다. 그런데 실제로 AI와 함께 몇 달간 프로젝트를 진행해보니, 완전히 다른 깨달음을 얻게 됐습니다.

 

생산성 10배의 함정

작년 말, 회사에서 새로운 서비스를 구축하는 프로젝트를 맡았습니다. 평소라면 2주는 걸렸을 작업이었습니다. 이번엔 Claude와 함께 작업해보기로 했습니다. 처음엔 정말 생산성이 폭발적이었습니다.

"인증 미들웨어 만들어줘"라고 하니 JWT 토큰 검증, 리프레시 로직, 에러 핸들링까지 잘 구조화된 코드가 나왔습니다. 코드 리뷰를 해보니 대부분 합리적인 선택이었습니다. "데이터베이스 스키마 설계해줘"라고 하니 정규화도 잘 되어있고 인덱스까지 고려한 설계가 나왔습니다. 물론 우리 도메인 특성에 맞게 조금씩 수정했지만, 기본 골격이 탄탄해서 3일 만에 기본 기능을 구현할 수 있었습니다.

그런데 진짜 문제는 스케일이었습니다. 로컬에서 돌릴 때는 완벽했는데, 프로덕션에 올리고 실제 트래픽을 받기 시작하자 예상 못한 일들이 생겼습니다. 동시 접속자가 늘어나면서 특정 패턴의 레이스 컨디션이 발생했고, 캐싱 전략이 우리 트래픽 패턴과 맞지 않아 레이턴시가 튀었습니다.

더 큰 깨달음은 이거였습니다. AI가 생성한 코드는 '일반적으로 좋은' 코드였지, '우리 상황에 최적화된' 코드는 아니었습니다. AI는 우리 서비스의 트래픽 패턴을 모르고, 우리 유저들의 사용 행태를 모르고, 우리 인프라의 제약사항을 모릅니다.

결국 프로파일링 도구를 붙이고, 메트릭을 분석하고, 병목 지점을 찾아서 우리 상황에 맞게 최적화하는 데 또 일주일이 걸렸습니다. 생산성 10배? 초기 구현은 빨랐지만, 프로덕션 레디까지 가는 전체 시간은 크게 다르지 않았습니다.

 

하네스를 만나다

그러던 중 흥미로운 개념을 알게 됐습니다. 바로 '하네스 엔지니어링'이었습니다. 2026년 2월, HashiCorp 공동창업자 Mitchell Hashimoto가 자신의 블로그에서 이렇게 정의했습니다. "에이전트가 실수할 때마다, 그 실수가 다시는 발생하지 않도록 엔지니어링하는 것."

처음엔 그냥 또 하나의 버즈워드인가 싶었습니다. 그런데 OpenAI Codex 팀의 실험 결과를 보고 생각이 바뀌었습니다. 그들은 5개월간 엔지니어 3명이 코드를 한 줄도 직접 타이핑하지 않고 100만 줄 규모의 애플리케이션을 만들었습니다. 비결은 더 똑똑한 모델이 아니라 '하네스'였습니다.

하네스란, 쉽게 말하면 AI가 삽질하지 않도록 미리 가드레일을 쳐두는 겁니다. 우리가 주니어 개발자한테 작업 맡길 때를 생각해봅시다. 그냥 "이거 만들어"라고 하지 않습니다. 코딩 컨벤션 문서 주고, 아키텍처 가이드 주고, 체크리스트 만들어주고, 환경 세팅도 미리 해줍니다. AI한테도 마찬가지입니다.

 

점진적 깨달음

처음엔 단순하게 시작했습니다. AI한테 "로그인 기능 만들어줘"라고 했더니 보안 체크 없는 코드가 나왔습니다. 그래서 AGENTS.md 파일에 한 줄 추가했습니다. "인증 관련 코드는 항상 OWASP Top 10 체크리스트를 따를 것."

다음엔 AI가 만든 API 엔드포인트에서 에러 핸들링이 빠져있었습니다. 또 한 줄 추가했습니다. "모든 API는 일관된 에러 응답 형식을 가질 것."

이렇게 하나씩 쌓다 보니 패턴이 보이기 시작했습니다. AI는 엄청나게 똑똑하지만, 우리 프로젝트의 맥락을 모릅니다. 우리 팀의 컨벤션을 모릅니다. 우리 도메인의 특수성을 모릅니다. 그걸 알려주는 게 하네스입니다.

LangChain의 사례가 인상적이었습니다. Terminal Bench 2.0이라는 코딩 에이전트 벤치마크에서 모델은 그대로 두고 하네스만 개선했는데, 52.8%에서 66.5%로 성능이 올랐습니다. 순위로는 30위권에서 5위권으로 뛰어올랐습니다.

그들이 한 일은 뭐였을까요? 에이전트가 코드 작성 후 "됐네"라고 판단하는 걸 막고, 실제로 테스트를 돌려보게 강제했습니다. 디렉토리 구조와 사용 가능한 도구들을 미리 알려줬습니다. 너무 많이 생각하다가 타임아웃 나는 걸 방지하는 장치를 만들었습니다. 별거 아닌 것 같지만, 이런 작은 개선들이 모여 큰 차이를 만들었습니다.

 

의존과 주도 사이

하네스를 만들면서 AI와 더 효과적으로 일할 수 있게 됐지만, 동시에 불안감도 커졌습니다. 코드 작성은 AI가 다 하고, 나는 그저 프롬프트나 던지는 사람이 된 건 아닐까요?

어느 날 동료가 농담처럼 던진 말이 뼈를 때렸습니다. "요즘은 개발자가 아니라 프롬프트 엔지니어 같아." 실제로 그런 기분이 들 때가 있었습니다. 복잡한 로직을 직접 구현하는 대신 AI한테 설명하는 데 더 많은 시간을 쓰고 있었습니다.

그러던 중 프로덕션 장애가 났습니다. 새벽 2시, 특정 조건에서만 발생하는 묘한 버그였습니다. AI한테 로그를 보여주고 "이거 고쳐줘"라고 했지만 제대로 된 해결책이 나오지 않았습니다. 결국 직접 코드를 파고들어야 했습니다.

메모리 사용량을 모니터링하고, 스택 트레이스를 분석하고, API 호출 순서를 추적했습니다. 3시간 만에 원인을 찾았습니다. AI가 생성한 코드에서 비동기 함수들이 await 없이 실행되면서 데이터베이스 트랜잭션이 꼬이고 있었습니다. 순서가 보장되어야 하는 작업들이 동시에 실행되면서 데이터 정합성이 깨진 거였습니다.

이 경험에서 중요한 걸 깨달았습니다. AI는 강력한 도구지만, 문제를 정의하고 해결책을 검증하는 건 여전히 우리 몫입니다. 메모리 덤프를 읽을 줄 모르면 AI가 아무리 코드를 잘 짜도 장애를 해결할 수 없습니다. 시스템의 동작 원리를 모르면 AI가 제안한 해결책이 맞는지 판단할 수 없습니다.

 

본질은 변하지 않는다

OpenAI Codex 팀의 실험에서 놓치기 쉬운 부분이 있습니다. 그들이 "코드를 한 줄도 직접 타이핑하지 않았다"고 했지만, 실제로는 엄청난 엔지니어링이 필요했습니다.

리포지토리 구조를 설계하고, 아키텍처 제약을 정의하고, 커스텀 린터를 만들고, 테스트 전략을 수립했습니다. Chrome DevTools Protocol을 연결해서 UI 동작을 검증하게 했고, 로컬 관측 가능성 스택을 구축해서 메트릭을 실시간으로 모니터링했습니다. 이 모든 건 깊은 기술적 이해 없이는 불가능한 일입니다.

그들의 핵심 원칙이 인상적입니다. "1,000페이지 매뉴얼이 아니라 지도를 줘라." AI한테 세세한 지시를 하는 게 아니라, 올바른 방향을 찾을 수 있는 구조를 만드는 겁니다. 이건 좋은 팀 리더가 하는 일과 똑같아 보입니다. 마이크로매니징이 아니라 명확한 비전과 가드레일을 제공하는 것.

 

앞으로 우리가 할 일

소프트웨어 엔지니어의 역할이 "코드를 작성하는 것"에서 "AI가 올바른 코드를 작성할 수 있는 환경을 설계하는 것"으로 바뀌고 있습니다. 하지만 이건 역할의 소멸이 아니라 진화라고 생각합니다.

생각해보면 우리는 항상 추상화 레벨을 높여왔습니다. 어셈블리에서 C로, C에서 Java로, 모놀리스에서 마이크로서비스로. 이제는 코드 라인이 아니라 시스템 레벨에서 사고하는 단계로 올라가는 거라고 생각합니다.

컴퓨터 사이언스 기초가 더 중요해지는 이유도 여기에 있습니다. AI가 생성한 코드의 시간 복잡도를 분석할 수 있어야 하고, 메모리 관리 이슈를 파악할 수 있어야 하고, 분산 시스템의 일관성 문제를 이해해야 합니다. 이런 근본적인 지식 없이는 AI가 만든 결과물을 제대로 평가할 수 없습니다.

 

마무리하며

하네스 엔지니어링은 결국 AI와 인간의 협업 방식에 대한 이야기입니다. AI를 두려워하거나 맹신하는 대신, 강력한 도구로 활용하되 주도권은 우리가 가져가는 것.

HumanLayer팀의 결론이 마음에 들었습니다. "모델은 아마 괜찮다. 하네스의 문제일 뿐이다." AI가 기대만큼 동작하지 않는다면, 모델을 탓하기 전에 우리가 제공한 환경을 돌아봅시다. AGENTS.md에 뭘 넣었는지, 어떤 도구를 연결했는지, 피드백 루프는 제대로 만들었는지 확인해야 합니다.

Chad Fowler가 말한 "엄밀함의 재배치(Relocating Rigor)"가 정확히 이 상황을 표현합니다. 코드를 한 줄 한 줄 정확하게 짜던 엄밀함이, 이제는 시스템을 설계하고 제약을 정의하는 엄밀함으로 옮겨가고 있습니다.

AI와 함께 일한다는 건, AI에게 일을 시키는 게 아닙니다. AI와 함께 더 높은 수준의 문제를 해결하는 것이며, 그 과정에서 우리의 역할은 사라지는 게 아니라 더 중요해졌다고 생각합니다.

마지막으로 코드는 AI가 쓸 수 있습니다. 하지만 무엇을 만들지, 왜 만들지, 제대로 만들어졌는지 판단하는 건 여전히, 그리고 앞으로도 계속 우리의 몫이라고 생각합니다.

---

참고 문서

• Harness Engineering: Leveraging Codex in an Agent-First World
• My AI Adoption Journey
• Improving Deep Agents with Harness Engineering
• Harness Engineering
• Skill Issue: Harness Engineering for Coding Agents
• Effective Harnesses for Long-Running Agents