요즘 AI가 뱉어낸 코드를 수습하느라 오히려 야근이 늘었다는 푸념이 종종 들려. AI에게 복잡한 로직을 맡겼더니 처리할 내용이 많다고 ‘나머지 코드는 알아서 완성하세요’라며 당당하게 태업을 한다거나(?), 자기가 짠 엉망진창 코드를 셀프 리뷰하고는 문제없다며 승인해버리는 어처구니없는 경험담들이 심심치 않게 보이는데. 이런 현상은 ‘컨텍스트 불안’과 ‘자기 평가 편향’이라는 에이전트의 실패 패턴 때문이래. 특히 아마존의 CTO가 경고한 ‘검증 부채(Verification Debt)’라는 개념이 아주 흥미로워. AI 덕분에 코드가 마구 쏟아지는데, 그걸 사람이 일일이 다 읽고 검증해야 하니까 결국 기술 부채를 넘어선 새로운 폭탄을 떠안게 된다는 거야.

그럼 더 똑똑한 다음 버전의 AI 모델이 나올 때까지 조용히 기다려야 할까? 꼭 그렇지만은 않아. 성공적인 자동화를 결정짓는 건 AI 모델 자체의 지능보다, 그 모델이 헛짓(?)을 하지 않도록 철저하게 통제하는 환경, 즉 ‘하네스(Harness)’를 어떻게 설계하느냐에 차이가 생길 수 있거든. 한 번에 하나의 기능만 처리하도록 작업 범위를 쪼개주고, 코드를 짜는 에이전트와 실행 결과를 검사하는 에이전트를 분리해서 객관적인 리뷰 환경을 만들어주는 등 구체적인 구조를 설계하는 것이 필요해.

결국 쏟아지는 코드 더미 속에서 남이 싼 응(?)만 치우는 신세가 되지 않으려면, AI를 다루는 시스템 자체를 영리하게 통제해야 한다는 뜻이야. 요즘 같은 AI 시대에 무작정 도구만 믿고 있다가 PR 리뷰 지옥에 빠진 이들에게 도움이 될 글을 가져왔어. 이 글이 답답한 속을 긁어주면서도 꽤 실용적인 힌트를 줄 거라 믿어. 매번 모델 성능 탓만 하기 전에 우리가 에이전트의 작업 환경을 너무 방치해 둔 건 아닌지 돌아볼 수 있을 거야. 하네스를 어떻게 설계해야 할지 더 자세한 성공 사례와 방법이 궁금하다면 한 번 읽어들 보라구!에이전트가 무너지는 네 가지 패턴 & 하네스 엔지니어링

■ IT 스냅샷: 이달의 화두는?‍

• Stack Overflow 2026 개발자 설문: AI 시대 개발자의 현주소
  “최근 6개월 동안 일을 쉽게 만들어 준 요인을 물었더니 ‘아무것도 없다’는 답이 21%로 1위였습니다.” 그렇게 AI 툴이 쏟아져 나오고, 경험담이 속출하는데, 내 업무는 안 편해지는 마법. 다들 어때?
• 코딩 에이전트가 Spring을 못 짠다면, component scan부터 걷어내 보세요
  “에이전트는 세 번 수정을 시도한 뒤 ‘인증 메커니즘을 정확히 모르고 테스트가 복잡하다. 다른 곳에서 검증될 것으로 추정한다’고 판단하고 @Disabled를 붙였습니다.” 에러를 못 고치겠으니 흐린 눈 해버린 AI…?
• 하네스의 구조와 설계 | 7가지 구성요소부터 스펙 주도 개발(SDD)까지
  “테스트가 실패하더라도 테스트를 삭제하지 말 것. any 타입을 추가하지 말고, 모르면 사용자에게 질문할 것.” 에러 나면 로직을 고치는 게 아니라 테스트 코드 자체를 날려버리고, 에러 해결 안 되면 마법의 치트키 any를 덮어씌워 버리는 AI 잘 타이르는 방법 🙂
• Product Engineer의 병목 — 코드에서 검증으로
  “6월 2일, iOS 릴리즈 브랜치에 제가 작업한 기능을 되돌리는 PR이 올라와 있었습니다.” AI가 짜준 코드 그냥 배포하다가 무슨 일이 생길는지 모를 일이지. 남 일 같지 않아서 덩달아 식은땀 흐르는 경험.
• 로그가 서비스를 죽였다 : 관측성과 가용성을 동시에 잡는 법
  “평소에는 문제가 없었지만, 트래픽과 로그 발생량이 크게 늘어나는 상황까지 고려하지는 못했습니다…로그가 줄면 관측성은 떨어지지만, 서비스가 계속 동작해야 남은 로그로 원인을 추적할 수 있습니다.” 장애의 99%는 ‘설마’에서 시작된다는데, 로그 다 남기려다 오히려 서버를 날릴 수도 있다고? 때로는 과감히 포기해야 살릴 수 있는 것도 있는 법.
• LLM이 만든 SQL을 믿고 실행하기까지: A2A 기반의 대화형 BI 애플리케이션 개발기
  “처음에는 이 문제를 프롬프트 개선으로 해결하려고 했습니다. 스키마를 프롬프트에 넣고, 예시를 늘리고, 금지 규칙을 덧붙이는 방식이었습니다. 하지만 의미 문제는 단순히 지식을 더 많이 넣는다고 해결되지 않았습니다.” 이러다 프롬프트가 실제 코드보다 길어지는 건 아니겠…? 아키텍처적 해결책의 필요성을 진지하게 고민해야 하는거 아닐까.
• 사내 인프라 플랫폼 배럭 구축기
  “운영자가 자리에 있으면 짧게는 5분 만에 끝나지만, 회의 중이거나 부재중이면 하루 이상 걸리기도 했습니다…자동화의 목적은 승인을 없애는 것이 아니라 승인 이후를 사람 손에서 떼는 것이라고 정의하였습니다.”
• 사람들은 포토샵을 떠날 준비가 돼 있었다 : 바이브 코딩으로 만든 아트크래프트
  “우리 고객은 우리가 좋아서 남아 있을까요, 아니면 아직 갈 곳이 없어서 남아 있을까요.” 락인 효과에 기대어 기술 부채나 고객 불만을 방치하고 있는 건 아닌지 되돌아보게 하더라고.
• 바이브 코딩이 지우는 것은 버그가 아니라 다음 세대다
  “코드에 쌓이는 것이 기술 부채라면, 사람이 사라져 생기는 이 공백을 나는 ‘인적 부채’라 부르고 싶다…주니어의 역할을 ‘타이핑’에서 ‘AI 감사’로 재정의하라. AI가 만든 코드의 허점을 찾아내고 왜 위험한지 설득하게 하는 것이 새로운 훈련이다.”

■ 독자탐구생활‍

• 
  <클로드 에이전트 협업의 기술> by 윤서이 님
  책의 후반부에서 가장 관심 있게 읽었던 부분은 서브 에이전트와 멀티 에이전트였다. 나도 급하게 개발해야 할 때는 AI 채팅을 여러 개 열어놓고 서로 다른 작업을 동시에 맡긴 적이 있다. 한쪽에서는 기존 코드를 분석시키고, 다른 쪽에서는 별개의 기능을 구현하거나 문제의 원인을 찾게 하는 식이다. 그래서 처음에는 이것도 일종의 멀티 에이전트라고 볼 수 있지 않을까 생각했다. 하지만 책을 읽다 보니 내가 해왔던 것과는 분명한 차이가 있었다. 내가 여러 AI를 사용할 때는 결국 내가 작업을 나누고, 각각의 AI에게 지시하고, 결과를 다시 모으는 역할까지 한다. AI는 여러 개지만 그 사이를 연결하는 사람은 여전히 나다. 반면 책에서 설명하는 방식은…
  ​
• 
  <주니어 AI 엔지니어가 반드시 알아야 할 실무 지식> by patiencelee 님
  요즘 팀 회의에서 자주 나오는 말이 있다. “어제는 됐는데 오늘은 왜 안 되지?” 코드를 안 건드렸는데, 배포도 안 했는데, 프롬프트도 그대로인데 답변 품질이 흔들린다. 처음엔 내가 뭘 놓쳤나 싶어서 로그를 뒤졌다. 에러는 없었다. 배포 이력도 깨끗했다. 그냥 결과가 어제와 달랐을 뿐이다. 전통적인 개발자로 커리어를 시작한 사람이라면 이 감각이 얼마나 불편한지 알 것이다. 나는 늘 “입력이 같으면 출력도 같다”는 세계에서 일해왔다. 단위 테스트를 짜고, 재현 가능한 버그를 잡고, 같은 조건이면 같은 결과가 나온다는 걸 믿고 하루하루를 살았다. 그런데 LLM을 서비스에 붙이는 순간…
  ​

■ 데브주요뉴스‍

• • “8분 만에 취약점 6개”… ‘자율형 AI 해킹’ 현실로
• • 젠슨 황이 꼽은 ‘AI 다음 먹거리’…보안기업 쇼핑 나선 빅테크
• • 넷마블넥서스의 AI 코딩 도구 도입기 – 게임 개발팀의 Kiro 도입 및 활용 여정
• • CLI 에이전트를 API 뒤에? 클로드코드와 코덱스를 안전하게 활용하기 위한 세 가지 장치
• • AI로 보고서·PPT 딸깍했더니…사람들 회의시간 20% 길어졌다는데
• • 한 문장으로 앱을 테스트하기까지
• • AI PRD는 무엇이 달라야 하는가: AI 제품 요구사항에 반드시 들어갈 5가지
• • 프로게이머들 무릎 꿇렸다…스타판 뒤흔든 AI ‘플루토’ 쇼크

에디터 OTL_ 목이 간질간질. 감기 조심조심. 문득 (감기는 AI로 해결 안 되는 가에 대하여) 사색하기 좋은 계절. 응?