← 전체 아티클 목록으로 돌아가기

코딩 대화가 멈추지 않을 때, 실행과 확인으로 돌아오기

저자: 고경만 (해경, haegyung) · 출처: haegyung.com · 최초 발행: 2026-01-05 · 개선 정본 판본

바이브 코딩을 하다 한 작업에 오래 묶여 있었다는 이야기를 들었다. 이 글을 처음 쓰던 무렵, 나는 성인 ADHD 증상이 두드러져 힘들었던 시기를 지나고 있었다. 약을 복용하면서도 내게 맞는 인지 훈련과 도구, 작업 규칙을 직접 만들고 고쳐왔다. 그 취약함과 경험이 이 글의 출발점이다. 여기서 나누려는 것은 작업을 운영하는 방법이며, 약의 효과나 치료 방법을 설명하려는 것은 아니다.

내가 걱정하는 장면은 오래 집중했다는 사실 자체가 아니다. 답을 계속 읽고 수정을 반복하는데 무엇을 확인했는지 말하기 어려워지는 때다. 대화는 늘어나지만 작업이 나아가는지 알 수 없다.

내가 살피는 세 가지 신호

작업의 방향을 바꿀 수 있는가, 끝낸 뒤 다시 시작할 여력이 있는가, 행동과 결과 확인이 이어지는가를 살핀다. 나는 이를 주도감, 회복, 피드백의 리듬이라고 부른다.

이 세 가지는 개인적인 운영 기준이다. 어느 질문에 몇 개 답했다고 몰입이나 과몰입을 진단할 수 있는 검증된 척도는 아니다. 기존 원고의 ‘아니오 두 개’ 기준도 그런 판정값으로 사용해서는 안 된다.

지금 목적을 한 문장으로 설명하기 어렵거나, 같은 실패를 확인 없이 되풀이하거나, 잠시 멈추기로 정한 조건을 계속 미루고 있다면 작업을 돌아볼 신호로 삼을 수 있다. 몸이 불편하거나 일상에 영향이 생기는 문제는 코딩 규칙만으로 해결하려 하지 않는다.

시작하기 전에 완료와 중단을 적기

작업을 열기 전에 오늘 남길 결과를 적는다. ‘로그인 개선’보다 ‘특정 입력에서 발생하는 오류를 재현하고 수정 여부를 확인한다’처럼 눈으로 확인할 수 있게 쓴다. 이번에 다루지 않을 범위도 정한다.

이어 언제 멈출지 적는다. 확보하지 못한 자료가 필요한 경우, 같은 시도가 새로운 단서를 만들지 못하는 경우, 예정한 작업 시간을 넘기는 경우처럼 자신에게 맞는 조건을 정할 수 있다. 횟수나 시간은 개인의 운영 선택이지 연구로 검증된 보편 기준은 아니다.

질문을 늘리는 대신 한 번 실행하기

지금 할 행동 하나, 결과를 확인할 방법 하나, 막혔을 때의 다음 선택 하나를 적는다. AI에 묻더라도 그 한 번의 실행에 필요한 정보부터 요청한다. 답을 받은 뒤에는 가능한 범위에서 실행하고, 기대한 결과와 실제 결과를 대조한다.

‘더 좋은 방법이 있을까’라는 탐색이 길어졌다면 현재 제약에서 시험할 후보를 고른다. 계속 옵션을 더 받는 대신 무엇을 알기 위한 시험인지 정한다. 시험으로 구분할 수 없는 후보라면 선택 기준부터 다시 적는다.

표면만 계속 고치고 있다면 실패를 재현할 자료를 만든다. 입력, 기대한 결과, 실제 결과를 남기고 원인 가설 하나를 검토한다. 여러 변경을 한꺼번에 넣으면 무엇이 달라졌는지 알기 어려워진다.

신호가 나타났을 때 쓸 짧은 규칙

내게는 잠시 자리에서 일어나거나 물을 마시는 것이 작업의 흐름을 끊어 다시 보는 계기가 되곤 했다. 누구에게나 즉시 같은 효과가 있다는 뜻은 아니다. 자신에게 맞는 쉬는 방법과 재시작 조건을 정하는 것이 필요하다.

쉬고 돌아오면 세 줄을 다시 읽는다. 지금 할 일, 바로 확인할 것, 막히면 할 선택이다. 이전 시도에서 새로 알아낸 것이 없다면 같은 요청을 반복하기 전에 자료나 가설을 바꾼다. 지금 할 일을 설명할 수 없으면 추가 수정을 시작하지 않는다.

AI에 요청할 두 가지 방식

첫 번째는 다음 행동을 좁히는 요청이다. ‘목표는 이것이고, 현재 관측은 이렇다. 이 제약 안에서 지금 할 행동 하나와 확인할 결과, 막힐 때 선택을 제안해줘.’

두 번째는 가설을 시험하는 요청이다. ‘이 원인을 의심하고 있다. 관측한 단서는 이것이다. 가능한 한 작은 변경으로 이 가설을 구분할 시험을 제안해줘. 무엇을 보면 가설을 버려야 하는지도 적어줘.’

제안을 받았다고 바로 실행할 필요는 없다. 파일을 잃거나 외부 서비스에 영향을 줄 수 있는 변경이라면 먼저 범위와 복구 방법을 확인한다. 작은 시험이라는 표현보다 실제로 무엇을 바꾸는지가 중요하다.

돌아가는 기능보다 확인한 차이를 남기기

특정 경우에만 오류가 나는 기능을 생각해 보자. 먼저 실패한 입력을 남기고 같은 조건에서 재현한다. 다음으로 가설 하나를 정해 수정하고, 그 입력과 주변 사례에서 결과를 확인한다. 결과가 달라지지 않았다면 새 패치를 쌓기 전에 가설을 다시 본다.

이 과정의 목적은 모든 작업을 기계적으로 느리게 만드는 것이 아니다. 무엇을 배웠는지 모른 채 반복하는 시간을 알아차리는 것이다. 내 경험에서 유용했던 규칙과 일반 연구의 효과를 같게 말하지 않으려 한다. 실제로 도움이 되는지는 자기 작업 기록에서 살펴야 한다.

오래 버틴 시간만으로 몰입의 가치를 판단하고 싶지 않다. 작업의 방향을 다시 잡을 수 있고, 무엇을 확인했는지 말할 수 있고, 필요할 때 멈출 수 있는가. 나에게는 그 질문이 다음 작업을 시작할 기준이 된다.

독자의 맥락과 여백

이 글을 읽으며 떠오른 당신의 장면은 무엇인가요? 질문과 선택의 맥락을 자기 노트에 기록해 보세요.