No Vibes Allowed: Solving Hard Problems in Complex Codebases - Dex Horthy, HumanLayer

영상 링크: No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer
채널명: AI Engineer

진정한 바이브 없이: 복잡한 코드베이스에서 어려운 문제 해결하기 핵심 요약

• 본 발표는 Dex Horthy(HumanLayer)가 복잡한(brownfield) 코드베이스에서 AI 코딩 에이전트의 실질적 한계를 극복하기 위한 “컨텍스트 엔지니어링” 기법을 상세히 다룸
• 10만 명 이상의 개발자 대상 조사 결과, AI 활용은 간단한(greenfield) 프로젝트(새로운 소형 대시보드 등)에서는 효과적이나, 레거시·복잡한 코드베이스에서는 재작업(sloppy code) 비율이 높아 실질적인 생산성 저하 문제 발생
• Dex 팀은 3명, 8주에 걸쳐 컨텍스트 최적화에 집중, 코드 재작업 없이 2~3배 높은 산출물을 달성하며 업무 방식·협업 방식 전환을 강제받음
• 그 결과 “연구→계획→구현(Research→Plan→Implement, RPI)” 프롬프트 시스템을 개발하여, 전 세계 수천 명이 GitHub에서 활용
• 기본적 AI 에이전트 활용(반복적 수정·혼합된 컨텍스트 사용)의 한계를 인식하고, ‘의도적 압축(compaction)’ 기법, ‘서브에이전트(sub-agent)’, ‘점진적 컨텍스트 샤딩’, 등으로 효율 극대화 시도
• LLM의 출력은 컨텍스트 품질에 절대적으로 좌우되므로, 컨텍스트 윈도우 크기 및 내용 품질 관리가 필수(특히 40% 수준 이상 시 ‘멍청이 구간(dumb zone)’ 돌입)
• ‘멘탈 얼라인먼트(mental alignment, 팀의 코드 이해 동기화)’ 유지를 위해, 플랜 파일에 구체적 코드 스니핏·프로세스 추가, 코드 리뷰 효율화
• 실전 예시(30만 라인 Rust 코드베이스 일발 수정, BAML에 3.5만 라인 PR), 실패 사례(파켓자바에서 하둡 의존성 제거 실패) 등을 공유하며 한계·과제도 언급
• ‘스펙 드리븐 개발’ 용어 및 프랙티스의 의미 희석화, 지나친 자동 문서화의 문제도 강조
• 조직 내 AI 활용도 향상을 위한 리더십의 문화적 변화 및 컨텍스트 엔지니어링 최적화의 필요성 강조

세부 요약 - 주제별 정리

대규모 개발자 설문에서 복잡한 코드베이스 AI 활용은 재작업 비중이 매우 높게 나타남

• 10만 명 개발자 설문 결과, AI 코딩 도구 활용 시 단순하고 신규인(greenfield) 프로젝트에서는 성과가 좋으나
• 복잡하거나 레거시(brownfield) 코드베이스에서는 대부분 시간과 리소스를 재작업(slop)과 코드 변경(churn)에 사용
• “우리가 저번 주에 배포한 허접 코드를 다시 뜯어고치는 경우가 많다”는 표현
• Vercel 등 신규 서비스 코드에선 AI가 잘 동작하지만, 10년된 자바 레거시에서는 효과 미미
• Dex 본인 및 다수 엔지니어 경험치와 완전히 일치

컨텍스트 엔지니어링 기법으로 단기간 내 협업 및 생산성 비약적 상승 경험

• Dex 팀(3인, 8주) 내에서 ‘콘텍스트 최적화’에 집중
• 처음 접한 클라우드 기반 코드 에디터 UX에는 큰 감흥 없었으나, 컨텍스트 관리 방식 전환 후 2~3배 생산성 상승
• 폭증하는 산출물로 인해 내부 협업 방식도 전면 재설계 필요
• 계량적·논리적 절차(Research → Plan → Implement)로 접근, 깃허브에서 수천 명이 해당 프롬프트 활용
• 해커뉴스 등에서 큰 반향(바이럴화) 기록

AI가 복잡한 레거시 코드베이스에서 실질적으로 작동하기 위한 전제조건이 강조됨

• 목표는 ‘노 슬롭(No Slop)’: 재작업 없는 건실한 코드 품질 유지
• 컨텍스트 윈도우 관리, 컴팩션, 작업 통합을 통한 높은 토큰 활용도 달성
• 멘탈 얼라인먼트(팀원 간 코드·변경 의도 동기화) 확보 필수, 아닌 경우 생산성 저하 및 누적 부실 발생
• 원천적으로 인간이 의미있는 업무만 AI에게 오프로드(offload)해야 효과적

반복적 프롬프트 이용에서 벗어나 ‘의도적 압축’이 에이전트 활용 효율을 극대화함

• “틀렸다→수정 지시→재요청”의 단순 반복이 아닌, 특정 단계에서 전체 컨텍스트를 마크다운 파일로 압축
• 새 AI 세션에 압축된 문맥 제공시, 초기 정보 탐색 불필요, 곧바로 업무에 착수
• 압축 내용: 실제로 작업에 필요한 파일명·라인넘버·최소한의 문맥 정보
• 컨텍스트 윈도우 내 용량(168,000 토큰 내외)을 적절히 분할해 활용(약 40% 이상 진입 시 품질 저하)

컨텍스트 윈도우의 품질·양·궤적(trajectory)이 LLM 결과에 결정적임

• LLM은 논디터미니즘이지만 ‘stateless(상태비저장)’하며, 입력 컨텍스트 품질이 결과 결정
• 잘못된 컨텍스트가 반복 입력될 경우, ‘실패→인간의 지적→재실패’ 패턴이 누적
• 바람직한 방향성(trajectory) 유지를 위한 정보 선별, 잘못된 정보→누락 정보→노이즈 순으로 위험성 판단
• Jeff Huntley 연구 등도, 컨텍스트 윈도우 과다 사용 시 결과 품질 저하 ‘멍청이 구간’(dumb zone) 개념 제시

서브에이전트는 역할 분업이 아니라 컨텍스트 조절·단편화에 중점적으로 활용해야 효과적임

• 프런트엔드·백엔드·QA·데이터 사이언스 역할별 anthropomorphizing은 비효율적
• 서브에이전트는 대규모 코드베이스 내 특정 정보 탐색·이해를 위한 별도 컨텍스트 윈도우 생성/반환 용도
• 메인 에이전트는 요약된 결과물(필요한 파일 등)만 받아, ‘스마트 존(smart zone)’ 유지

‘연구→계획→구현’(RPI) 워크플로우로 컨텍스트 윈도우 최소화 및 성과 최적화 가능

• Research(연구): 시스템 구조·관련 파일·목표·기존 동작 탐색 및 객관적 정보 수집, 오픈소스 프롬프트와 샘플 결과 활용
• Plan(계획): 명확한 작업 순서·파일명·코드 스니핏·테스트 방식 등 상세기획, 계획안에 실제 코드 예시 포함 권장
• Implement(구현): 계획안을 참조해 구현, dumbest model조차도 실수 가능성 minimal
• 전체 작업 과정에서 의도적으로 context를 최소화하며, 작업 반복 및 버퍼현상 방지

실전 대형 코드베이스 적용 성공 및 실패 사례에서 한계와 개선점을 도출함

• 30만 라인 Rust 기반 Boundary ML 코드베이스 일괄 수정(one-shot fix) 성공
  • 한 밤 동안 구현, CTO 승인 후 곧바로 릴리즈 포함
• 35,000줄의 대규모 코드 PR 및 약 7시간 작업 후 1~2주 예상 분량 완료, 일부 codegen 포함
• Hadoop 의존성 제거(파켓자바) 시도는 복잡성, 계획 부정확 등으로 실패, 화이트보드 재기획 필요
• 결국 AI가 ‘사고(thinking)’ㅡ자체를 대체하는 것은 불가능하며, 고차원 통찰 및 설계는 인간 몫

스펙 드리븐 개발(Spec-driven Development) 용어가 의미 확산·희석을 겪으면서 한계 도달함

• 업계에서 ‘스펙’이 의미하는 범위가 너무 넓어져, 실질적으로 구체성 상실(semantic diffusion)
  • 단순 프롬프트, 제품 요구 명세서, 피드백 루프, 마크다운 일기장 등 다양하게 혼용
  • 오픈소스 문서화와 동의어로 쓰이기도 함
• “에이전트” 용어처럼, 스펙드리븐도 결국 실체가 무의미해짐

실질적이고 검증된 4단계 실천 전략을 통해 높은 생산성과 협업 품질 도달

• (1) 연구: 코드베이스 구조 파악(순간 캡처·온디맨드 샤딩), 거짓(슬롭)이 적은 정보만 재가공
• (2) 계획: 의도 압축, 실제 작업 단위·코드 스니핏 등 최대한 구체화
• (3) 멘탈 얼라인먼트: 코드 리뷰 시 ‘왜/무엇을/어떻게’에 대한 팀 간 이해 통일
  • PR에 연구·계획·빌드 결과 첨부, 깃허브 메시지보다 효과적으로 작업 흐름 전달
• (4) 구현 및 피드백: 사람 주도 계획 검토 필수, 나쁜 계획 한 문장이 수백 줄의 나쁜 코드 유발 가능
• 주기적 반복과 숙련이 필요하며, 여러 도구 최적화보다 한 도구를 집중적으로 활용 권고

조직 차원의 문화 변화와 지속적 학습이 AI 기반 업무 혁신의 성공 열쇠임

• 조직 내 기술 리더가 변화 선도 필요, 99% AI 제작 코드 시대 대비해 SDLC 자체 혁신 필요
• 미드레벨 개발자는 생산성 향상 효과 크나 품질 문제도 동반, 시니어·스태프 엔지니어는 정제되지 않은 결과물에 피로도 증가
• ‘슬롭’ 발생은 AI나 주니어의 책임이 아니라 조직 문화와 워크플로우 문제
• 컨텍스트 엔지니어링이 실제로 작동할 수 있게 기획·활용 경험 축적이 관건, HumanLayer 등에서는 Aentic IDE 등 도구화 진행

결론: 완벽한 프롬프트, 은탄환 없는 현실 인식이 필요하며, 컨텍스트 엔지니어링 역량·프로세스 적응이 가장 본질적인 과제임

• RPI(Research Plan Implement) 워크플로 자체보다 ‘의도적 컴팩션’과 ‘스마트존 유지’가 핵심
• “사고(Thinking)”는 AI에게 외주화 불가, 사람이 컨텍스트·계획·판단에 적극 개입해야 함
• 하이픈(hype) 없이 실천 가능한 컨텍스트 관리·엔지니어링 역량 구축에 집중 필요