채팅으로 코딩한다는 것

결론부터

지난 한 주, 가장 많이 한 코딩은 출퇴근길 지하철에서 짧은 한 줄을 텔레그램에 던지는 것이었다. "오늘 daily-feed 마지막 커밋 뭐였어?" "blog dev 서버 떠 있어?" "텔레그램 봇 시리즈 5편 발행해줘." 데스크톱 앞에 앉아 키보드를 잡지 않은 채로 코딩 흐름이 굴러갔다.

채팅으로 코딩한다는 건 데스크톱 코딩의 휴대용 버전이 아니다. 다른 워크플로우다. 짧은 메시지가 만드는 흐름, 손이 묶여 있을 때 가능한 음성 입력, 5분짜리 작업이 데스크톱에선 보내기 어려웠던 시간에 끼어든다. 이 글은 그 흐름에 대한 짧은 정리다.

세 가지 모드 — 데스크톱, 채팅, 음성

같은 코딩이라도 인터페이스에 따라 가능한 작업의 모양이 다르다.

데스크톱은 모든 것이 가능하다. 5개 파일을 동시에 띄우고, IDE의 자동완성 + 디버거 + 다중 터미널이 모두 손끝에 있다. 깊이 있는 작업, 1시간 이상의 집중, 복잡한 리팩토링에 적합하다. 단점은 자리에 있어야 한다는 것 — 데스크톱 코딩의 시간은 "키보드 앞에 앉은 시간"으로만 흘러간다.

채팅은 한 줄짜리 입력과 N줄짜리 응답이 전부다. 깊은 디버깅은 어렵지만 빠른 점검·짧은 편집·간단한 커밋 같은 일이 가능하다. 데스크톱에선 "별일 아니니까 나중에"로 미루던 작업이 채팅에선 즉시 처리된다 — 미루는 비용이 없어진다.

음성은 손이 묶여 있을 때의 채팅이다. 운전 중에 한 줄 묻거나, 양손이 막혀 있을 때 마이크로 입력한 텍스트가 채팅과 같은 파이프라인을 탄다. 정확도가 떨어져서 긴 작업엔 안 어울리지만, "지금 이 한 줄"의 입력 비용을 거의 0으로 만든다.

짧은 메시지 한 줄의 가치

채팅으로 코딩한다고 했을 때 가장 의외였던 건 "진짜 작업"의 비율이 생각보다 높다는 점이다. 처음엔 "데스크톱에 가서 해야지" 하던 일이 채팅에 던져보니 사실 한 줄로 끝나는 경우가 많았다.

• "daily-feed 어제 cron 정상 돌았어?"
• "blog typecheck 한 번 돌려서 에러 있는지 알려줘."
• "텔레그램 봇 시리즈 #3 발행해줘."
• "어제 commit 메시지에 오타 있던 거 amend해서 다시 푸시."

이 작업들의 공통점 — 데스크톱이라면 작업 시작에 1-2분이 필요하다. IDE 띄우고, 터미널 켜고, cd 하고, 컨텍스트를 떠올리고. 그 setup 비용이 5분짜리 작업의 비용을 사실상 7분으로 만든다. 그래서 미룬다.

채팅에선 setup이 0이다. 메시지 한 줄 던지면 토픽 자동 라우팅으로 cwd가 맞춰져 있고, Claude가 컨텍스트를 들고 들어와 작업한다. 5분짜리 작업이 5분에 끝난다. 그 작은 차이가 하루 동안 쌓이면 의외로 크다.

hub-and-spoke가 채팅 환경에서 의미하는 것

채팅 워크플로우에서 가장 중요한 디테일은 응답이 빨리 시작되는 것이다. 사용자 입장에서 "지금 뭔가 동작하고 있다"의 첫 신호가 빠르면 채팅이 살아 있다. 첫 신호까지 30초가 걸리면 채팅이 죽는다.

데스크톱에선 사용자가 작업 중이라 응답이 좀 느려도 다른 창을 보면 된다. 채팅에선 그게 안 된다. 메시지를 던지고 답을 기다리는 동안 사용자의 모든 주의가 채팅 화면에 가 있다. 응답이 빨리 시작되어야 한다, 완성될 때까지 걸리는 시간이 짧아야 하는 게 아니라.

그래서 hub-and-spoke 패턴이 의미가 있다. 메인 채팅(hub)은 1-2초 안에 짧게 답하고, 무거운 작업은 specialist subagent로 dispatch한다. specialist는 자기 cwd에서 작업하고 1-2 문장 보고로 돌아온다. 사용자가 받는 첫 메시지는 거의 즉시 도착하고, 후속 결과는 specialist 완료 후 따로 도착한다.

[사용자] "daily-feed에 오늘 cron 정상 돌았는지 확인해줘"
 
[hub, 즉시] "specialist 보내서 확인 중. 잠시만요."
[specialist, 30초 후] "✓ 09:00 cron 정상. 12편 발행 누적."

데스크톱에선 의미 없는 분할이지만, 채팅에선 결정적이다. 첫 메시지의 1-2초가 채팅의 생명을 결정한다.

채팅이 못 하는 것

채팅 워크플로우의 한계도 명확하다.

• 시각적인 작업 — 디자인 톤 조정, OG 이미지 미리보기, mermaid 다이어그램의 layout 확인. 모바일 화면에서 텍스트로만 검토하기엔 한계가 있다.
• 여러 파일의 동시 편집 — 채팅에선 한 작업에 한 답이 자연스럽다. 5개 파일을 동시에 만지는 큰 리팩토링은 데스크톱이 빠르다.
• 긴 응답 — 채팅 한 응답이 5000자를 넘으면 모바일 스크롤이 부담된다. 긴 결과물은 데스크톱에서 받는 게 낫다.

이 한계들이 의미하는 건 모든 코딩을 채팅으로 옮기지 않는다는 것이다. 데스크톱과 채팅은 보완 관계다. 깊은 작업은 책상에서, 짧은 점검·즉시 처리·출퇴근길 5분은 채팅으로.

닫는 글

채팅으로 코딩한다는 건 코딩을 휴대용으로 만드는 게 아니다. 데스크톱에선 보내기 어려웠던 시간들 — 출퇴근길, 식당에서 친구를 기다리는 5분, 잠들기 전 침대에서의 10분 — 을 코딩 가능한 시간으로 회수하는 것이다.

같은 사람의 하루가 길어지지 않는다. 다만 같은 하루 안에서 코딩에 쓸 수 있는 시간의 모양이 조금씩 늘어난다. 그 늘어남이 의외로 크다.