"코드보다 인터뷰가 먼저" — 한 참여자의 talk-driven engineering 방법론과 오픈소스 스킬 공개

밤 10시 반, 한 참여자가 자신의 작업 방식을 상세히 풀어놓기 시작했다. 요지는 코드를 서두르지 않는다는 것이다. "그래서 플랜 인터뷰가 한 30-1시간이 보통이고"라며, 본격적인 구현에 앞서 요구사항을 다지는 데만 최대 한두 시간을 쓴다고 밝혔다. 코드 한 줄 치기 전에 인터뷰에만 그만큼을 투자한다는 것이다.

방식의 핵심은 문서가 아니라 대화였다. "Q&A로 처리해요 저는"이라는 설명에 다른 참여자가 "Q&A로 처리한다는게 인터뷰지로 쓴다는건가요? 신기한 방법론인데 대부분 체크리스트나 To-do로 하지 않나요? 궁금하네요 어케하시는지"라고 되물었다. 그는 오케스트레이터·플래너·태스커를 용도별로 나눠 쓰는 앙상블 구조를 설명하며 "이게 claude gemini gpt가 아무래도 프리트레이닝이 근본적으로 다르니까" 서로 다른 모델을 섞어 쓰는 효용이 있다고 덧붙였다. 스펙 문서를 쓰는 대신 질의응답으로 요구사항의 암묵지를 걷어낸다는 접근이었다.

그는 자신의 방법론에 'talk-driven engineering'이라는 이름까지 붙였고, 이를 줄여 '입코딩'이라 부른다고 소개했다. 지켜보던 한 참여자는 "또 배웠다"며 즉각 반응했다. 이어서 그는 직접 만든 오픈소스 스킬 레포를 함께 꺼냈다. "https://github.com/OutlineDriven/odin-claude-plugin"이라는 링크와 함께 "제가 오리지널로 만든게 70%"라며 차용분과 자작분의 비율까지 투명하게 밝혔다. 가져온 부분은 라이선스가 열린 것들이며 그마저도 자기 방식으로 바꿔놨다는 설명이 이어졌고, 자신의 스킬 설계 전반에 "복잡성을 관리하는쪽" 철학이 깔려 있다고 마무리했다.

인터뷰에만 최대 두 시간을 쏟는다는 이 워크플로우는, 결국 요구사항을 정확히 고정하는 초기 투자가 뒤에서 루프를 덜 태운다는 이 커뮤니티의 암묵적 합의를 보여준다. 오리지널 70%·차용 30%라는 비율을 스스로 공개한 대목은, 스킬을 배포할 때 출처를 분명히 하는 게 이 방의 기본 매너로 자리잡았음을 시사한다. 요구사항을 대화로 조각하는 이 방식이 하나의 이름 붙은 방법론으로 공유됐다는 점에서, 커뮤니티의 작업 문화가 개인기에서 재현 가능한 절차로 옮겨가고 있음을 엿볼 수 있다. 좋은 결과물을 만드는 노하우가 감이 아니라 이름 붙은 워크플로우로 정리돼 공유될 때, 그것을 따라 배우려는 사람이 곧바로 나타난다는 점도 이 방의 학습 밀도를 보여준다.