코딩을 이미 할 줄 알 때 '바이브 코딩' 시작하는 방법

이미 코딩할 줄 아는 사람이 코딩 어시스턴트(coding assistant)를 처음 사용해 보면 좌절감을 느낄 수 있습니다. 파일을 열고 몇 줄만 수정하면 될 것 같은데, 대신에는 작업을 설명하고, 세부 사항을 명확히 하고, 긴 답변을 읽어야 합니다. 화면에 코드가 나타나면 '이건 내가 이미 할 수 있었는데'라는 완벽하게 합리적인 생각이 듭니다.

어쩌면 정말로 그 특정 작업을 더 빨리 끝낼 수도 있습니다. 하지만 한 번의 시도만으로는 어시스턴트를 평소 작업 흐름에 어떻게 녹여낼지 궁금증을 남깁니다. 전체 애플리케이션을 맡기는 것은 위험하게 느껴지고, 명백한 한 줄을 완성해 달라고 요청하는 것은 무의미합니다.

저는 익숙한 프로젝트에서 작은 변경부터 시작할 것을 추천합니다. 미리 결과를 상상하고 실수를 찾아낼 수 있는 종류의 작업 말입니다. 이렇게 하면 과정 자체에 집중할 자유가 생깁니다: 작업을 어떻게 설명해야 하는지, 첫 시도에서는 어떤 일이 발생하는지, 그리고 나의 개입이 어디에 필요한지를요.

큰 화면에서 발견한 작은 불편함

개인 블로그를 운영한다고 상상해 보세요. 평소에는 노트북으로 열어보면 괜찮아 보입니다. 그런데 어느 날 대형 모니터로 페이지를 열었더니, 아티클 목록이 벌어져 있는 것을 발견합니다. 제목은 왼쪽으로 멀리 떨어져 있고, 이미지는 오른쪽으로 늘어나 있으며, 그 사이에 너무 많은 공간이 있어서 더 이상 같은 카드 일부처럼 느껴지지 않습니다.

한편, 헤더와 작성자 설명은 정상적으로 보입니다. 휴대폰에서도 특별히 거슬리는 것은 없습니다. 전체 사이트를 재설계하고 싶지 않습니다. 이미 작동하는 부분을 유지하면서 넓은 레이아웃을 통일시키고 싶습니다.

이것이 유용한 첫 번째 작업이 됩니다. 눈에 보이는 결함이 있고 경계가 명확합니다. 시작하기 전에 '완료'의 의미를 결정할 수 있습니다: 목록이 나머지 콘텐츠와 정렬되고, 이미지는 비율을 유지하며, 제목은 읽기 쉬워야 하고, 휴대폰 레이아웃에는 가로 스크롤바가 없어야 합니다.

이러한 명확성은 어시스턴트가 모든 것이 고쳐졌다고 발표할 때 유용하게 쓰일 것입니다. 당신은 그 답변과 비교할 무언가를 갖게 될 테니까요.

실험하기 전에 평소처럼 현재 작업물을 저장하고 별도의 브랜치(branch)를 생성하세요. 변화를 차분하게 되돌릴 수 있다는 점은 모든 실패한 시도에 대해 걱정할 필요 없이 무언가를 시도하는 것을 더 쉽게 만듭니다.

대화는 보이는 것에서 시작합니다

어시스턴트(assistant)에게 동료가 유용하다고 생각할 만한 자료, 즉 페이지 자체, 문제의 스크린샷, 그리고 무엇이 불편한지에 대한 몇 마디가 필요합니다. 도구가 프로젝트를 읽을 수 있다면, 템플릿과 스타일을 찾도록 요청할 수 있습니다. 일반적인 채팅에서는 관련 코드 조각(snippet)을 직접 제공해야 합니다. 레이아웃을 조사하기에는 페이지 코드와 스크린샷만으로 충분하며, 자격 증명(credentials)이나 사용자 데이터는 이 단계에서 역할이 없습니다.

첫 번째 요청에는 평범한 설명만으로 충분합니다:

제 블로그의 작성자 페이지에서 기사 목록이 큰 화면에서 헤더와 작성자 설명을 넘어 더 넓게 퍼집니다. 제목과 이미지가 너무 멀리 떨어져 있습니다. 작은 화면에서의 레이아웃은 만족스럽습니다.

목록의 너비를 제어하는 것이 무엇인지 찾아 원인을 설명하고, 작은 변경 사항을 제안해 주세요. 아직 파일을 수정하지 마세요. 스크린샷과 페이지 주소를 첨부했습니다.

첫 메시지에서 원인을 추측하거나 어떤 클래스(class)를 추가해야 할지 지시할 필요가 없습니다. 관찰한 내용을 설명하고 어시스턴트에게 조사하도록 요청하는 것만으로 충분합니다. 이는 또한 변경 사항이 프로젝트에 나타나기 전에 자신이 과제를 같은 방식으로 이해했는지 확인할 기회를 제공합니다.

유용한 설명은 코드와 비교해 볼 수 있습니다. 예를 들어, 어시스턴트는 헤더가 너비 제한을 가진 컨테이너(container) 안에 있고, 기사 목록은 그 밖에 있다고 보여줄 수 있습니다. 사용자는 템플릿을 열어 그것이 사실인지 확인합니다. 만약 설명이 파일과 일치하지 않는다면, 즉시 불일치를 논의하는 것이 더 좋습니다.

이 시점에서 같은 템플릿이나 스타일을 사용하는 다른 페이지가 있는지 물어볼 가치가 있습니다. 작은 변경 사항도 이웃에게 영향을 줄 수 있습니다. 작성자 페이지를 수정하는 것이 사용자가 알아차리지 못하는 사이에 카테고리 페이지를 변경할 수도 있기 때문입니다.

코드가 도착했을 때

설명이 이해가 되면, 어시스턴트에게 제안된 변경 사항을 적용하고 diff를 보여달라고 요청하세요. 작업이 익숙해지면서 읽어야 할 일련의 변경 사항들이 생깁니다.

브라우저를 흘깃 보고 넘어가고 싶은 유혹에 빠질 수 있습니다. 하지만 변경된 라인들을 몇 분 동안 살펴보는 것이 무슨 일이 일어났는지 이해하는 데 도움이 됩니다. 왜 여기에 너비 제약 조건이 추가되었을까요? 기존 컨테이너가 재사용되었나요? 이웃 블록의 변화는 어디서 온 것일까요?

만약 어시스턴트가 클래스 이름도 변경하고, 전체 파일을 포맷팅하며, 몇 가지 다른 것도 “개선”했다면, 그 변경 사항들이 왜 필요한지 물어보세요. 간결한 diff가 원래 작업과 연결하기 더 쉽습니다. 관련 없는 것은 별도의 대화에서 처리해도 됩니다.

낯선 구조를 이해하는 척할 필요는 없습니다. 직접 살펴보거나, 왜 필요한지 물어보거나, 프로젝트에서 이미 사용된 접근 방식을 제안할 수 있습니다. 결국 코드는 채팅을 닫은 후에도 여전히 여러분의 저장소에 남아있기 때문입니다.

일반적인 채팅 방식은 하나의 수동 단계를 추가합니다: 제안된 스니펫을 파일에 복사하는 것입니다. 그 이후 과정은 동일합니다: diff를 검사하고 페이지를 여는 것입니다.

페이지가 크기 조정에도 살아남아야 한다

블로그가 이제 큰 모니터에서는 훌륭해 보일 수 있습니다. 만족스럽지만, 이 작업에는 또 다른 조건이 있었습니다: 작은 화면을 유지하는 것.

저는 페이지를 넓은 창, 일반적인 노트북 너비, 그리고 좁은 휴대폰 너비에서 열어볼 것입니다. 그런 다음 단순히 창의 가장자리를 드래그할 것입니다. 때로는 문제가 선택한 크기 사이에서 나타나기도 합니다: 제목이 갑자기 줄 바꿈되거나, 이미지가 너무 좁아지거나, 예상치 못한 간격이 생길 수 있습니다.

만약 변경 사항이 공유되는 템플릿에 영향을 준다면, 그것을 사용하는 다른 페이지도 확인하세요. 빌드 및 프로젝트 검사도 유용하지만, 제목이 이미지 옆에서 읽기 편한지는 알려주지 못할 것입니다. 어시스턴트가 실제로 무엇을 확인했는지, 그리고 여전히 여러분의 주의가 필요한 것이 무엇인지 묻는 것이 도움이 됩니다.

와이드 레이아웃이 괜찮아 보이지만, 모바일에서 왼쪽에 추가적인 간격이 생겼습니다. 이것은 대화에 가져갈 수 있는 구체적인 관찰 사항입니다:

기사 목록이 와이드 스크린에서는 올바르게 정렬되었습니다. 너비가 390픽셀일 때, 왼쪽에 추가적인 간격이 있습니다. 여기 스크린샷이 있습니다. 마지막 변경 중 어떤 부분이 이것을 유발했는지 찾고, 와이드 스크린 결과를 유지하는 수정 방법을 제안해 주세요.

작동 리듬이 점차 생겨납니다. 당신은 불일치를 지적하고, 어시스턴트가 조사하며, 당신은 다음 버전을 확인합니다. 변경 사항이 계속 쌓이고 설명이 결과와 일치하지 않으면, 멈추고 저장된 상태로 돌아갈 수 있습니다. 때로는 복잡하게 얽힌 수정 과정을 계속하는 것보다 좁은 작업을 다시 명시하는 것이 더 쉽습니다.

첫 시도 후

페이지가 제대로 보이면, 다음 작업으로 넘어가기 전에 잠시 멈춥니다. 어시스턴트는 어디서 시간을 절약했나요? 무엇을 설명하기 어려웠나요? 어떤 실수를 스스로 발견했고, 어떻게 해결했나요?

이러한 답변들이 경험에 대한 전반적인 느낌(좋다/싫다)보다 더 유용합니다. 낯선 템플릿을 찾는 것은 빠를 수 있지만, 디자인을 논의하는 데 너무 오래 걸렸을 수도 있습니다. 혹은 코드가 즉시 작동했지만, 평소보다 훨씬 더 정확하게 승인 기준을 설명해야 했을 수도 있습니다.

작은 블로그 수정만으로도 첫 시도를 할 수 있습니다. 입력 유효성 검사(input validation)나 보고서 변경과 같은 작업에도 동일하게 접근할 수 있습니다. 익숙한 작업을 선택하고, 올바른 결과를 상상하며, 확인하는 과정을 거쳐 진행합니다.

이러한 변화 하나만으로도 시작하기에 충분합니다. 그 후에는 자신만의 경험을 갖게 될 것입니다: 유용한 표현 방식, 불필요한 수정 사항, 그리고 프로젝트에 대한 이해 없이 작업이 멈춘 지점들입니다. 이것은 다음 작업을 선택할 때 기반을 다질 수 있는 무언가를 제공합니다.

제가 이 작업 방식에 대한 저의 태도를 “네, 저는 바이브 코딩 합니다”에서 작성했습니다.