크리스 핸슨(Chris Hanson)은 AI 코딩 에이전트를 활용할 때 전문가가 목표와 설계를 이끌고 모델이 구현과 검증을 돕는 방식을 ‘Resonance Coding’이라고 부른다. 그는 빠른 시제품에는 즉흥적인 ‘Vibe Coding’도 유용하지만, 다른 사람이 유지·사용할 제품을 만들려면 인간의 전문성과 지속적인 검토가 필요하다고 주장한다.

즉흥적으로 만든 결과와 그 한계

핸슨은 한 시간 안에 마인크래프트 복제 게임을 만들도록 코딩 에이전트에 지시한 사례를 소개한다. 결과물인 Stelexcraft는 55분의 코딩 세션으로 만들어졌고, 크리에이티브·서바이벌 모드, 51종의 블록, 동물과 좀비, 제작법 등을 갖췄다. 제작 과정은 빌드 보고서, 기능은 기능 목록, 원작과의 비교는 비교 문서에 정리돼 있다.

핸슨은 이 결과가 눈길을 끄는 시연이라고 평가하면서도, 코드 구조를 이해하고 계획에 없던 기능을 추가하거나 멀티플레이어·레드스톤·네더를 구현할 수 있는지는 별개의 문제라고 지적한다. 익숙한 사례를 바탕으로 짧은 시간에 결과물을 만드는 데는 적합할 수 있지만, 요구사항과 설계가 빠진 채 진행하면 후반의 수정이 다른 부분의 오류로 번지고 결과물을 유지하기 어려워질 수 있다는 설명이다.

그는 ‘Vibe Coding’이라는 말이 안드레이 카파시(Andrej Karpathy)가 2025년 2월 만든 표현이라고 소개한다. 핸슨은 이를 프롬프트를 입력하고 결과를 받아 실행한 뒤, 오류를 다시 전달하는 방식으로 설명한다. 이런 접근은 폐기할 시제품이나 개념 검증, 간단한 도구, 시간이 제한된 해커톤에는 쓸모가 있다. 사용자가 해당 분야의 전문가가 아닐 때 에이전트에게 일을 맡기는 경우도 예로 든다.

전문가가 방향을 정하고 함께 반복한다

핸슨이 제안하는 Resonance Coding에서는 인간 전문가가 목표와 우선순위, 설계 원칙을 정하고 최종 결정을 내린다. LLM은 선택지와 절충안을 제안하고, 계획을 세우며, 테스트·점검·리팩터링 같은 작업을 맡는다. 모델이 맥락을 모른 채 내놓는 제안은 도움이 될 수도 있지만, 사용자가 말하지 않은 요구사항을 놓칠 수도 있으므로 전문가가 판단하고 조정해야 한다는 주장이다.

그는 이 협업을 한 번에 끝내는 절차가 아니라 반복되는 순환으로 설명한다. 먼저 LLM이 전문가에게 질문해 숨은 전제와 요구사항을 드러낸다. 이어 요구사항·용어·제약·비목표를 문서로 남기고, 여러 설계안을 비교해 결정을 기록한다. 작업을 작고 확인 가능한 단위로 나눈 뒤 인간이 변경 내용을 살피며 함께 구현하고, 테스트와 반대 관점의 점검을 거쳐 개선 사항을 프로젝트 기록에 반영한다. 프로젝트 기록은 대화 맥락이 초기화되거나 여러 에이전트를 나눠 쓸 때 방향을 유지하는 데 중요하다고 덧붙인다. 사전 질문 단계에는 맷 포콕(Matt Pocock)의 Grill Me 스킬을 활용할 수 있다고 소개한다.

이 방식은 인간이 프로젝트 전체를 직접 수행할 수 있을 만큼의 분야 지식을 갖췄을 때 가장 효과적이라는 것이 핸슨의 설명이다. 사람이 몇 주나 몇 달 걸릴 일을 에이전트와 함께 더 짧은 시간에 처리하더라도, 전문가가 맥락과 유지보수성을 고려해 결과를 이끌어야 한다고 본다. 그는 이를 인간이 설계와 판단을 맡고 모델이 생산성을 키우는 협업으로 묘사하며, 리누스 토르발스(Linus Torvalds)의 AI 활용 발언도 언급한다.

빠른 시작보다 검증이 중요하다

핸슨은 전문가가 모델의 결정을 무비판적으로 승인하면 협업이 아니라 다시 즉흥적인 코딩으로 돌아간다고 경고한다. 테스트, 이견 제시, 다른 관점의 검토, 현실의 요구사항 확인이 모델의 결과를 제어하는 장치가 돼야 한다. 전문가가 없으면 Resonance Coding은 문서 작업이 늘어난 Vibe Coding에 그칠 수 있고, 시작 단계도 더 느리다.

그는 이 방식이 모든 프로젝트에 필요한 것은 아니라고 선을 긋는다. Vibe Coding으로 만든 시제품을 기능과 설계, 사용자의 요구에 맞춰 검토한 뒤 본격 개발의 출발점으로 삼을 수도 있다. 하지만 누군가 비용을 지불하거나 결과물에 의존하고, 이후 유지보수해야 한다면 전문가의 판단과 인간·AI 간 반복적인 검증을 중심에 둬야 한다는 것이 글의 결론이다. 이는 핸슨이 제안하는 개발 접근법이며, 글에서 독립적인 성능 검증 결과를 제시한 것은 아니다.