AI가 당신에게 뺨을 때릴 때
Source: Dev.to
AI가 얼굴을 때릴 때: Adama에서 Claude가 만든 코드를 디버깅하기
AI가 복잡한 기능을 “바이브‑코드”하게 만든 뒤, 놓친 미묘한 버그를 디버깅하느라 몇 시간을 보낸 적 있나요? 저는 Adama—상태를 유지하는 서버리스 앱을 위한 플랫폼—를 구축하면서 Claude를 사용해 개발 속도를 높이고 있습니다. 큰 그림은 잘 잡아주지만, 비동기 타이밍이나 파이프라인 설정 같은 저수준 함정에서는 자주 걸립니다. 아래는 실제 디버깅 전쟁 이야기를 세 가지 소개하고, AI를 적절히 관리하는 교훈을 정리했습니다.
WebSocket 활성화: Netty 파이프라인 악몽
Claude에게 Adama에서 AI가 실시간으로 문서를 컴파일하도록 하는 MCP (Message Control Protocol) 서버를 만들도록 했습니다. 첫 번째 시도는 꽤 괜찮았습니다. 문서의 모든 코드 스니펫을 파싱하고 검증하는 “북 제너레이터”와 실시간 상호작용을 위한 Netty 기반 WebSocket 지원을 포함했죠.
하지만 유닛 테스트가 폭발했습니다. Claude가 만든 코드는 Netty 파이프라인에 여러 개의 WebSocketServerProtocolHandler를 사용했는데, Netty는 하나만 허용합니다. 수정을 요청했지만 상황은 악화되었습니다: 되돌리기, 추상화 레이어 추가, 더 많은 테스트 실패가 이어졌습니다.
진짜 문제는? 테스트가 핸드셰이크 전에 채널 쓰기를 기다리지 않았다는 점이었습니다. 로그를 보면 비동기 불일치가 드러났습니다. Claude는 실행 환경을 직접 확인할 수 없었기에 이 부분을 놓쳤습니다—아마도 컨텍스트 윈도우를 다 써버려서였겠죠.
교훈: AI는 보일러플레이트에 강하지만 런타임 인사이트가 부족합니다. 빠른 로컬 빌드와 풍부한 로그가 필수입니다. 문제를 해결하고 나니 MCP 핵심 기능이 아름답게 동작해, Claude가 Adama 스니펫을 매끄럽게 컴파일할 수 있게 되었습니다.
Adama 교육: 빌드 시간과 컨텍스트 손실
다음으로 Claude에게 Adama 문서를 다시 작성하고 샘플을 생성하도록 했습니다. 새로운 Markdown‑to‑site 엔진은 컴파일 성공을 80 % 첫 번째 시도에서 보고했으며, 소스에서 자동으로 정제되었습니다.
하지만 모노레포 빌드가 10분이나 걸렸습니다—인간 개발자가 IDE에서 유닛 테스트로 탐색하기엔 괜찮지만, AI가 반복하기엔 치명적이었죠. Claude는 부분적인 기능(예: 미완성 타입 시스템)에서 길을 잃었고, 전체 컨텍스트를 충분히 파악하지 못했습니다.
교훈: AI에게 IDE와 동일한 환경을 제공하세요. 빌드를 빠르게 최적화하고, 컴파일러 오류에 문서 힌트를 풍부하게 넣으세요. “mainline + experiments” 요약을 프롬프트에 포함해 팀 핸드오프를 시뮬레이션합니다. Ship > experiment.
대규모 리팩터링: 컨텍스트 오버플로우
Adama의 타입 시스템은 복잡합니다—짧은 프롬프트조차 전사(transcribe) 단계에서 환각을 일으킵니다. 10k+ 토큰을 사용했음에도 출력은 여전히 깨졌습니다. AI는 전체 언어 리팩터링을 전문 “에이전트” 없이 수행하면 금새 막히게 됩니다.
교훈: 작업을 마이크로‑태스크로 나누세요. 프롬프트를 조직도처럼 구성해 서브시스템별 전문가를 지정합니다. 개발자 여러분, 이제 여러분에게 필요한 새로운 스킬은 AI를 분산 팀처럼 관리하는 것입니다.
AI를 제어하라: 실천 가능한 요점
AI는 다음을 강제할 때 가속됩니다:
- 빠른 피드백 루프: 1분 이내 빌드/테스트.
- 풍부한 신호: 로그, 오류‑문서화.
- 범위가 제한된 프롬프트: 거대한 모놀리스를 피하고, 적절히 청크화.
- 인간 감시: 모든 것을 검토.
큰 성과: 전체 문서 생성기, AI 자체 개선을 위한 MCP, 80 % 컴파일 성공률. 하지만 디버깅이 나를 깨우게 했습니다—AI는 마법이 아니라 스테로이드를 맞은 주니어 개발자에 불과합니다.
직접 Adama를 사용해 보고, 상태ful 개발 도구를 지원하려면 adama‑core에 ⭐️를 눌러 주세요. 여러분이 겪은 최악의 AI 디버깅 이야기는 무엇인가요?