데이터를 크롤링해서 분석하고, 점수를 매기고, 결과를 비교해주는 도구를 만들던 때였습니다. 아이디어 자체는 꽤 명확했는데, 막상 만들기 시작하니까 구현할 기능이 생각보다 많았습니다.

Claude에게 닥치는 대로 말했습니다. “데이터 크롤링해줘, 점수 매기는 로직 만들어줘, 비교 기능 넣어줘, 그래프도 넣어줘.” 밤새 Claude와 주고받으면서 코드를 쌓아나갔습니다.

새벽 4시에 만들어진 코드의 운명

새벽 4시쯤 되었을 때, 뭔가 돌아가는 것 같긴 한데 자꾸 이상한 결과가 나왔습니다. 여러 기능을 동시에 추가하다 보니 어디서 문제가 생기는지도 몰랐습니다.

Claude에게 고쳐달라고 했습니다. 고쳐줬습니다. 또 다른 버그가 났습니다. 또 고쳐줬습니다. 고칠 때마다 다른 곳이 망가지는 것 같았습니다. 새벽 5시에 저는 지쳐서 그냥 잠들었습니다.

다음 날 낮에 깨어나서 전날 밤에 만든 코드를 봤습니다. 솔직히 뭐가 뭔지 모르겠었습니다. Claude도 아마 전날 밤의 대화 맥락을 잃었을 것이고, 저도 맥락을 잃었습니다. 어떤 코드가 어떤 버그를 고치려고 추가된 건지, 어떤 로직이 어떤 기능을 위한 건지. 뒤죽박죽이었습니다.

그날 밤 짠 코드는 결국 다 버렸습니다.

피로한 상태에서 빠르게 만든 코드는 결국 더 많은 시간을 잡아먹었습니다.

다음 날 다시 시작한 방법

다음 날 저는 접근을 바꿨습니다. 코드를 만들기 전에 30분 동안 Claude와 대화만 했습니다. 코드 없이. 기능 요구사항도 말하지 않고.

“이 도구의 목적이 정확히 뭐야?”, “핵심 기능 하나만 꼽으면 뭐야?”, “어떤 데이터가 필요하고, 어떤 순서로 처리해야 해?”, “이 도구를 쓰는 사람이 어떤 순서로 쓰게 될까?”, “어떤 경우에 실패할 수 있어?”

Claude가 질문에 답하고, 저도 생각을 정리하면서 30분 동안 대화했습니다. 그 결과로 메모 하나가 생겼습니다. 핵심 기능 목록, 데이터 흐름, 예외 처리 시나리오, 사용자 시나리오. A4 반 장 분량이었습니다.

그걸 가지고 Claude에게 “이 설계대로 만들어줘”라고 했습니다. 한 시간이 안 돼서 핵심 기능이 동작하는 코드가 나왔습니다. 전날 밤 다섯 시간 동안 만든 것보다 훨씬 깨끗하고 잘 돌아갔습니다. 버그도 훨씬 적었습니다.

왜 이런 차이가 생기는가

이 경험에서 배운 게 있습니다. AI는 맥락이 명확할수록 좋은 코드를 씁니다. 제가 원하는 것이 모호하면 AI도 모호하게 만듭니다. 제가 명확하면 AI도 명확하게 만듭니다.

전날 밤에는 흥분 상태에서 기능들을 주워섬겼기 때문에 Claude가 만드는 것도 산발적이었습니다. 다음 날은 명확한 목적과 범위를 가지고 시작했기 때문에 결과가 달랐습니다.

이건 AI의 문제가 아닙니다. 제가 무엇을 원하는지를 얼마나 명확하게 알고 있는가의 문제입니다. 그리고 그 명확함은 빠르게 만들려는 욕심을 잠깐 내려놓는 것에서 시작됩니다.

AI와 대화하는 방법도 실력입니다

이 경험 이후로 저는 뭔가 만들고 싶을 때 먼저 멈춥니다. “이게 정말 필요한 기능인가?”, “이게 어떻게 동작해야 하는가?”, “어떤 경우에 실패할 수 있는가?”, “핵심은 뭐고 나중에 추가해도 되는 건 뭔가?”

이 질문들을 먼저 대화로 풀고 나면, 실제 코드 작성 시간이 극적으로 줄어들었습니다. 전날 밤 다섯 시간 걸린 작업이 다음 날 한 시간으로 줄었습니다.

한 가지 더 배운 것이 있습니다. Claude에게 어떻게 말하는가도 실력입니다. “이거 만들어줘”보다 “이런 문제를 이런 방식으로 해결하고 싶은데, 이렇게 접근하면 어떨까? 제약 조건은 이거야”라고 말하면 결과가 다릅니다. 맥락을 충분히 주고, 제약 조건을 명시하고, 예외 케이스를 미리 알려주면 Claude가 훨씬 정확한 코드를 씁니다.

이 능력도 경험을 통해 늘었습니다. 처음에는 막연하게 말했고, 지금은 거의 설계서 수준으로 말합니다. AI와의 대화 능력은 코딩 능력과 별개로 키울 수 있고, 반드시 키워야 합니다.

30분의 대화가 다섯 시간의 코딩보다 나은 결과를 만들었습니다.

아직도 이 실수를 가끔 합니다

솔직히 말하면 지금도 가끔 같은 실수를 합니다. 흥미로운 아이디어가 떠오르면 당장 만들고 싶은 충동이 있습니다. 그 충동에 져서 생각 없이 시작하면 어김없이 시간 낭비가 생깁니다.

그래서 이제는 의식적으로 멈추는 연습을 합니다. “지금 당장 만들고 싶다”는 느낌이 들면, 그 에너지로 먼저 설계를 합니다. 메모장에 기능 목록을 씁니다. Claude와 아이디어 대화를 합니다. 그리고 나서 만들기 시작합니다.

이 습관 하나가 만드는 속도를 두 배 이상 빠르게 만들었습니다.

이 원칙이 적용되는 다른 상황들

“30분 대화가 5시간 코딩보다 낫다”는 원칙은 특정 도구에만 적용되지 않습니다.

API 설계를 할 때도 마찬가지입니다. 바로 엔드포인트를 만들기 시작하면 나중에 구조를 갈아엎게 됩니다. Claude와 “이 API를 쓰는 쪽에서 어떤 데이터가 필요한가?”를 먼저 정리하고 나면 한 번에 잘 만들어집니다.

데이터베이스 스키마를 짤 때도 마찬가지입니다. 바로 테이블을 만들기 시작하면 나중에 컬럼을 자꾸 추가하거나 관계를 바꾸게 됩니다. “어떤 쿼리를 자주 쓸 것인가?”를 먼저 이야기하고 나면 처음부터 맞게 잡힙니다.

무언가를 만들기 전에 그것의 목적을 명확히 하는 30분. 이 30분이 이후의 몇 시간을 절약합니다. 그리고 이건 AI가 없던 시절에도 사실이었습니다. AI와 함께 하면 그 효과가 더 극적으로 드러날 뿐입니다.

설계 대화가 만드는 또 다른 가치

설계 대화를 먼저 하면 코드 품질 이상의 가치가 생깁니다. 자신이 무엇을 만들려는지 더 명확하게 이해하게 됩니다. “이 기능이 왜 필요한가?”를 말하다 보면 불필요한 기능을 걸러내게 됩니다. “어떤 예외가 있을까?”를 생각하면 나중에 발생할 버그를 미리 방지하게 됩니다.

저는 이 과정을 “만들기 전에 충분히 생각하기”라고 부릅니다. 빠르게 만드는 것보다 옳게 만드는 것이 결국 더 빠릅니다.