'AI가 내 코드를 대신 써준다'는 프레임은 절반만 맞다. 진짜 흥미로운 일은 AI에게 탐구를 맡길 때 벌어진다. 최근 세 가지 사례가 이 명제를 서로 다른 각도에서 동시에 증명했다. 한쪽에선 Claude가 헬스 앱의 비공개 API를 스스로 역공학했고, 다른 쪽에선 게임 개발자가 범용 AI 도구의 한계에 지쳐 도메인 특화 워크플로우를 직접 설계했으며, 또 다른 쪽에선 AI 기반 명세 분석이 57년 동안 아무도 발견하지 못한 아폴로 11호의 버그를 끄집어냈다.
AI가 패킷을 읽고, 도구를 짜고, 다시 코치가 됐다
dev.to에 올라온 한 사례는 'AI를 창의적 문제 해결 파트너로 쓴다'는 것이 어떤 모습인지를 가장 직관적으로 보여준다. 헬스 트래킹 앱 Liftoff에는 데이터 내보내기 기능이 없었다. 개발자는 Claude에게 이 문제를 던졌고, Claude는 mitmproxy 설치부터 iPhone 프록시 설정, HTTPS 복호화 인증서 설치까지 단계별로 안내한 뒤, 캡처된 트래픽을 직접 분석해 앱이 tRPC를 사용하고 있음을 파악했다. 인증 흐름, 워크아웃 엔드포인트, 운동 타입 코드 체계까지 API 전체를 스스로 매핑한 것이다. 개발자는 패킷 하나 읽지 않았다.
이것으로 끝이 아니었다. Claude는 이어서 Go + Cobra 기반 CLI 도구를 작성했고, 인증 토큰 관리와 자동 갱신, tRPC 요청 포맷 처리까지 구현했다. 결말이 흥미롭다. 이 CLI로 추출한 6개월치 훈련 데이터를 다시 Claude에게 넘기자, Claude는 이번엔 운동 프로그래밍 코치로 변신했다. API를 역공학하고 → 추출 도구를 만들고 → 그 데이터로 다시 분석하는, AI가 자신의 루프를 스스로 닫은 셈이다. 단순한 코드 생성기가 아니라, 문제 공간 전체를 함께 탐색하는 파트너에 가깝다.
범용 AI의 벽—게임 개발자가 직접 허물었다
그러나 이런 성과는 AI를 '잘 쓸 수 있는 조건'이 갖춰졌을 때 나온다. 같은 dev.to에서 게임 개발자 Zhudanyang이 공유한 경험은 그 반대편을 보여준다. 그는 Unity 프로젝트에 여러 AI 코딩 어시스턴트를 써봤지만, 반복적으로 같은 패턴의 실패를 겪었다. AI는 자동 생성 설정 파일을 직접 수정했고, Update() 루프 안에 GetComponent
그가 만든 Danya는 이 공백을 정면으로 겨냥한다. 프로젝트 루트에서 danya를 실행하면 엔진을 자동 감지하고, 제약 규칙·품질 게이트 훅·리뷰 스코어링 룰셋이 담긴 .danya/ 디렉토리를 생성한다. 핵심은 이것이 '가이드라인'이 아니라 '강제 실행'이라는 점이다. AI가 자동 생성 코드를 건드리려 하면, 쉘 훅이 exit non-zero로 막는다. AI의 논리로 설득할 수 없는 기계적 차단이다. 성능 린터는 Update/Tick/_process 내부의 GetComponent, FindActor, get_node 같은 핫패스 함정 18가지를 정적으로 잡아낸다. 여기에 AI가 실수를 저지르면 그 패턴을 룰 파일에 자동으로 학습하는 자기 진화 루프까지 갖췄다. Unity, Unreal, Godot, 그리고 Go/C++/Java/Node.js 서버 프로젝트까지 7개 템플릿을 지원한다.
Danya가 보여주는 통찰은 단순하지만 강력하다. 범용 AI 도구의 한계는 모델 성능의 문제가 아니라 컨텍스트 설계의 문제다. 도메인 지식을 규칙으로 구체화하고, AI가 넘어선 안 되는 경계를 코드 레벨에서 박아두면, 같은 AI가 완전히 다른 품질의 협업 파트너가 된다.
57년 된 버그를 찾아낸 '행위 명세 기반 분석'
가장 극적인 사례는 아폴로 11호에서 왔다. JUXT 팀은 AI 기반 명세 언어 Allium과 Claude를 활용해 13만 줄의 AGC 어셈블리 코드를 1만 2,500줄의 행위 명세로 변환했다. 이 과정에서 자이로 제어 루틴의 비정상 종료 경로(BADEND)에서 LGYRO 잠금이 해제되지 않는 버그가 발견됐다. 잠금이 해제되지 않으면 이후 모든 자이로 관련 기능이 멈춘다. 역사상 가장 철저히 검토된 코드베이스라 불리는 AGC에서, 57년 동안 아무도 발견하지 못한 결함이었다.
이 분석의 방법론이 중요하다. 기존 검증은 코드 읽기, 에뮬레이션, 전사 정확도 확인에 집중됐다—코드가 현재 무엇을 하는가를 확인하는 방식이다. Allium 명세 기반 접근은 코드가 무엇을 해야 하는가를 정의하고, Claude가 모든 실행 경로를 추적해 의도와 실제 동작의 불일치를 찾아냈다. 테스트가 현재 동작을 검증한다면, 명세는 의도된 행위를 검증한다. 이 차이가 57년의 시간을 넘었다.
다만 이 발견에는 주석이 필요하다. 해커뉴스에서 AGC 복원 프로젝트를 이끈 Mike Stewart는 이 버그가 실제로 Apollo 14와 15 사이에 이미 수정됐으며, SATANCHE 테스트 중 발견돼 L-1D-02로 기록된 사실을 밝혔다. 또한 재현 코드를 직접 실행해본 개발자는 Phase 5(데드락 시연)가 실제 에뮬레이터를 돌리지 않고 예상 결과만 출력하는 가짜 코드임을 확인했다. AI가 찾아낸 결함 자체는 실재했지만, '57년간 미발견'이라는 서사는 사실과 달랐고, AI가 생성한 재현 코드는 검증이 허술했다. 분석 파트너로서의 AI가 인상적인 만큼, AI 결과물을 그대로 신뢰하는 위험도 함께 드러난 셈이다.
AI를 '탐구 파트너'로 쓰는 법의 공통 조건
세 사례를 관통하는 패턴이 있다. 첫째, AI에게 무엇을 만들어가 아니라 무엇을 찾아라고 요청할 때 다른 종류의 가치가 나온다. 역공학, 경로 추적, 결함 탐지—이것들은 코드 생성이 아니라 분석과 탐구의 영역이다. 둘째, 도메인 지식을 AI가 접근할 수 있는 형태로 구조화하는 것이 성과의 질을 결정한다. Danya의 룰셋이든, Allium의 행위 명세든, mitmproxy의 트래픽 덤프든—AI에게 '어디를 봐'가 아니라 '뭘 찾아'를 전달하는 컨텍스트 설계가 핵심이다. 셋째, AI 결과물은 출발점이지 종착점이 아니다. AGC 사례처럼, AI가 찾아낸 것을 인간이 다시 검증하고 맥락을 보충하는 루프가 없으면 극적인 서사는 종종 사실과 빗나간다.
범용 AI 도구가 성숙할수록, 역설적으로 도메인 특화 워크플로우의 가치는 올라간다. AI가 강력할수록 그것을 올바른 방향으로 묶어두는 설계—제약, 명세, 검증 루프—가 더 중요해지기 때문이다. 앞으로 주목할 변화는 '어떤 AI 모델이 더 똑똑한가'가 아니라 '누가 더 정밀한 탐구 환경을 설계하는가'로 이동할 것이다.