AWSKRUG 플랫폼 엔지니어링 모임 후기 : 하네스 엔지니어링과 AI-DLC 플랫폼
Charlies챌리
2026. 4. 26. 23:12
최근 스스로 하네스를 구축해보겠다고 시도하다 진행 중이던 프로젝트 코드가 엉망이 된 경험이 있어, 결국 다시 순정 상태로 돌아가서 코딩하고 있는 내 모습을 보면서 AI를 더 잘 다루고 싶다는 생각이 들었다.
다른 사람들은 도대체 AI를 어떻게 쓰길래 그렇게 생산성이 올랐다고 말하는 걸까. 나도 AI를 쓰면서 생산성이 늘긴 했지만, 링크드인이나 주변에서 "하루에 Claude Max 토큰 3개를 다 쓴다" 같은 이야기를 들으면 도대체 어떤 식으로 활용하길래 저게 가능한가하는 생각이 들었다. 그러던 와중에 마침 딱 맞는 주제의 밋업이 열려서 신청하게 됐다.
에이전트 시대의 소프트웨어 개발 - 하네스 엔지니어링과 AI-DLC 플랫폼
에이전트가 신뢰성 있게 소프트웨어를 구축하도록 환경, 제약 조건, 피드백 루프를 설계하는 방법론인 하네스 엔지니어링(Harness Engineering)을 소개하고, 이를 AI-DLC 플랫폼에 어떻게 적용하고 있는지 사례로 풀어주는 자리였다.
링크드인이나 스래드에 올라오는 글처럼 무조건 따라해보세요가 아닌, 수치 기반으로 차분하게 풀어주는 점이 가장 좋았다.
가장 기억에 남는 부분은 모델이 바뀌면 지금 구축한 하네스도 다 갈아엎어야 할 수도 있고, 아예 필요 없어질 수도 있다는 이야기였는데, 가장 좋은 하네스는 언제든 덜어낼 수 있게 단순하게 설계됐을 때라는 말을 덕분에 이해할 수 있었다.
컨텍스트 엔지니어링과 하네스 엔지니어링은 함께 가야하는 엔지니어링이라고 하였는데, 이야기를 들으면서 AI로 고분분투하며 몇차례 skills와 hooks를 갈아엎는 요즘 내 모습을 떠올리며 결국 좋은 AI 네이티브한 개발을 하기 위해 스스로도 모르게 컨텍스트 + 하네스 엔지니어링을 하고 있었다는 점이 재밌었다.
하나 인상적이었던 건, 회사에서는 개발자들이 AI 활용 노하우를 서로 공유하면서 함께 생산성을 올리길 바라지만, 정작 현업자들은 "나만 생산성이 올랐으면 좋겠다"는 심리가 있다는 점이었다. 그래서 "각자 자기만의 하네스를 짜고 있는데 회사 차원에서는 보고가 안 된다"는 이야기. 이 간극이 플랫폼 엔지니어링 관점에서 왜 중요한 화두인지, 모임이 끝날 때쯤 자연스럽게 이해됐다.
AI 에이전트를 실무에 도입하면서 막연하게 느끼던 것들이 꽤 명확한 언어로 정리되는 시간이어서, 느낀 점과 함께 몇 가지를 블로그에 남기게 되었다.
Harness Engineering이란?
처음 들었을 때 가장 와닿은 비유가 마구(馬具, Horse Harness)였다. 말의 힘을 억압하는 게 아니라 올바른 방향으로 집중시키는 장치. 에이전트도 똑같다는 거다. 능력을 누르는 게 아니라 신뢰할 수 있는 방향으로 흐르게 하는 환경 설계.
마구(Harness)는 말을 억압하는 게 아니라 능력을 올바른 방향으로 집중시키는 장치다. 하네스 엔지니어링도 똑같다.
요즘 다들 이야기하는 프롬프트 엔지니어링, 컨텍스트 엔지니어링이 그 안의 하위 개념이라고 보면 된다. Anthropic도 "Effective harnesses for long-running agents"에서 비슷한 결론을 내놨고, 하네스 설계의 핵심은 결국 세 축으로 정리된다.
- System Prompt: 행동 지침, CLAUDE.md, 컨텍스트 정의
- Tools: CLI, MCP, 파일시스템 접근 등 에이전트가 쓸 수 있는 도구
- Middleware: Hooks, 검증 단계, 가드레일, 피드백 루프
발표자님이 강조한 포인트가 인상적이었다. 모델을 바꾸지 않고 하네스만 개선해도 성능이 극적으로 향상된다. 우리는 보통 "더 좋은 모델 나오면 해결될 거야"라고 미루는데, 사실 지금 모델로도 하네스만 잘 짜면 충분히 다른 결과가 나온다는 거다.
안티패턴: Vibe Coding
가장 경계해야 할 안티패턴으로 바이브 코딩이 언급됐다.
생성된 코드를 이해하지 않고, 검증 없이 수용하는 행태.
하네스 없이 에이전트를 운영하면 비용은 줄어들지만 엔트로피가 5~10배 빠르게 축적된다. 단기적으로 빨라 보이지만 장기적으로는 코드베이스가 무너지는 패턴. 이거 진짜 공감했다 — 내가 도입부에 적은 *"프로젝트 코드가 엉망이 됐다"*는 게 정확히 이 패턴이었던 것 같다.
핵심 원칙들
발표에서 나온 8가지 원칙 중 보안 일하면서 특히 와닿은 것들만 추렸다.
- 에이전트는 암묵지를 모른다. 저장소에 저장되지 않은 원칙은 모른다. 슬랙이나 노션에만 있는 규칙들을 코드베이스로 끌어올려야 한다.
- Agent Legibility First. 에이전트가 읽기 쉽게 코드베이스를 최적화한다. 작은 진입점을 만들어 필요할 때만 깊게 들어가도록.
- 가드레일을 명확하게. 직관에 맡기는 것보다 가드레일을 주는 게 오히려 명확하다. AI가 고민할 시간을 줄여주기 때문.
- 검증된 기술을 써라. AI가 이해할 수 있는 수준의 복잡도를 유지할 것.
- 사후 교정이 더 싸다. 모든 걸 사전 승인으로 막으려 하면 승인 피로도가 커져서 자동 승인하는 이슈가 생긴다.
- 결정론적 검증 → 확률론적 검증 순서로. 린터, 타입체커, 테스트가 먼저, 판단 영역만 LLM 기반 리뷰로.
- 모델 능력이 발전하면 하네스 복잡도는 감소해야 한다. 영구적 자산이 아니라는 뜻.
Context Rot과 Progressive Disclosure
이 부분이 개인적으로 가장 흥미로웠다.
Context Rot(컨텍스트 부패) - 컨텍스트가 커질수록 에이전트 성능은 절벽이 아니라 완만한 기울기로 떨어진다. 그래서 실제로 쓰면서도 인지하기 어렵다. 어느 순간 "왜 이렇게 멍청해졌지?" 싶을 때는 이미 컨텍스트가 비대해진 상태다.
해법은 Progressive Disclosure(점진적 공개)다. 지식을 4단계로 계층화하고, 필요할 때만 로딩한다.
CLAUDE.md → 핵심 100줄만 (항상 로딩)
.claude/rules/ → 도메인별 규칙 (조건부 로딩)
docs/ → 상세 문서 (참조 시점에 로딩)
codebase → 실제 코드 (필요한 부분만 읽기)
MCP 최대한 안 붙이려고 노력합니다. 다 붙이면 그냥 컨텍스트만 잡아먹어요.
MCP 서버 하나에 도구 100개씩 들어있는 경우도 있는데, 그게 다 컨텍스트로 들어가면 에이전트가 시작하기도 전에 이미 망가져 있다.
계층적 피드백 루프
가장 직접적으로 적용 가능한 패턴이었다.
핵심은 L1에서 잡을 수 있는 문제를 L5까지 보내지 말라는 거다. 보안 리뷰 에이전트 호출이 L4쯤이라고 보면, 오타나 신택스 에러는 L1에서 잡혀야 한다. 그래야 에이전트가 비싼 단계에서 비싼 시간을 안 쓴다.
그리고 에이전트 친화적 에러 메시지 - 에러 메시지에 "무엇이 잘못됐는지"와 "어떻게 고쳐야 하는지"를 둘 다 명시해야 한다. 통과한 테스트는 출력하지 말고 실패한 것만 출력. 안 그러면 컨텍스트가 잘못 쌓인다.
피드백 강도에 대한 이야기도 좋았다.
같은 피드백을 2번 줘야 한다면 그건 시스템의 실패다. 에이전트가 실패하면 "더 열심히 하라"가 아니라 "어떤 역량, 컨텍스트, 구조가 부족한지" 물어야 한다.
Swiss Cheese Trust Model
단일 게이트로 모든 결함을 잡을 수는 없다. 이질적인 검증을 겹겹이 쌓아 구멍이 겹치지 않게 한다는 모델. 보안에서 익숙한 Defense in Depth 개념이랑 똑같다.
특히 강조된 게 적대적 검증 - 코드 생성 에이전트와 리뷰 에이전트는 반드시 분리해야 한다. 스스로 만든 건 실제 품질과 무관하게 긍정적으로 평가하기 때문에.
독립적인 평가기를 회의적으로 튜닝하는 것이, 생성기를 자기비판적으로 만드는 것보다 훨씬 다루기 쉽다.
이건 Anthropic 엔지니어링 블로그에도 비슷한 이야기가 있다. Generation과 Evaluation을 분리한 에이전트 구조가 self-evaluation보다 일관되게 더 좋은 성능을 낸다는 것.
AI-DLC 생명주기
전통적 SDLC가 AI 중심으로 재편된 모델. AWS가 AI-DLC(AI-Driven Development Lifecycle)라는 이름으로 정리한 게 있는데, 발표에서는 이걸 6단계로 풀어서 설명했다.
각 단계의 핵심은 인간이 할 마지막 영역이 무엇인가를 명확히 하는 거다. AI가 코드를 작성하고 검증하고 머지하고, 인간은 릴리스 브랜치 승인과 아키텍처 결정에만 개입하는 구조.
흥미로웠던 건 Phase 5의 기술부채 관리 관점이다.
에이전트가 만드는 기술부채를 고이자 대출처럼 지속적으로 소액 상환한다.
에이전트는 코드를 대량으로 증폭시키고, 문서 드리프트도 빠르게 일으키고, 무의식적으로 아키텍처 드리프트를 만든다. 이걸 한 번에 갚으려고 하면 안 되고, 매 PR마다 조금씩 갚아야 한다는 거다.
Brownfield 적용 전략
Brownfield(브라운필드)란? 이미 운영 중인 기존 시스템·코드베이스
신규 프로젝트(Greenfield)에는 적용하기 쉽지만, 사실 진짜 문제는 레거시 시스템(Brownfield)이다.
핵심은 암묵지를 코드베이스로 끌어올리는 것.
- 슬랙 스레드에만 있는 결정사항 → 저장소 문서로
- 한 사람만 아는 시스템 동작 → 명시적 규칙 파일로
- 회의록의 컨벤션 → CLAUDE.md로
새로운 조직에 들어왔을때, 막상 구조나 코드베이스를 보면서 파악한 것들을 문서화하겠다고 다짐을 했지만 막상 정신없이 파악하고 다음 일을 하다보면 결국 레거시는 또 레거시대로 남아있게된다.
정책이나 운영 등 사람 머릿속에는 있는데, 이걸 문서화하여 끌어올리지 않으면 어떤 에이전트도 우리 환경에서 제대로 일할 수 없다.
발표 사이사이 나온 인사이트
발표자님이 슬라이드 외로 풀어준 이야기 중 좋았던 부분.
- 한 달 전에 "내부적으로 도입해야 한다"고 발표했는데, 한 달 만에 슬라이드가 20장 업데이트됐다. 이 분야 변화 속도.
- 클로드 코드를 로컬에서만 돌리면 안 된다. 패럴럴로 돌아가야 한다. 워크트리부터 시작하고 멀티에이전트로 확장하는 걸 권장.
- 실행 비용이 저렴해진 시대라 야근이 줄었다. 밤에 구현이나 리서치를 돌려두고 자고, 다음날 아침에 결과를 본다.
정리하며
핵심 메시지를 다시 추리면
- 모델을 기다리지 말고 하네스를 짜라. 지금 모델로도 충분히 다른 결과가 나온다.
- 컨텍스트는 작게 유지하라. Progressive Disclosure를 활용해 필요할 때만 로딩.
- L1에서 잡을 수 있는 문제를 L5까지 보내지 말라. 결정론적 검증을 먼저.
- 생성과 평가를 분리하라. 자기 채점은 항상 후하다.
- 암묵지를 코드베이스로 끌어올려라. 에이전트는 슬랙을 안 본다.
- 하네스는 영구적 자산이 아니다. 모델이 발전하면 하네스도 단순해져야 한다.
테스트 품질이 성능의 상한선이다. 정답 데이터셋이 있어야, 우리가 원하는 요구사항과 일치하는 결과가 나온다.
방향을 잘못 잡으면 돈을 아무리 부어도 의도한 결과가 안 나온다는 것. 업무 자동화 만들 때 항상 명심해야 할 부분이다.
결국 잘 쓰는 사람들은 그냥 토큰을 많이 쓰는 게 아니라, 에이전트가 신뢰할 수 있게 일하도록 환경을 설계하고 있었다는 것. 그리고 그 설계가 단순할수록 좋다는 것이다.
참고 자료