클로드 코드만으로는 바이브코딩에서 한계를 느꼈습니다

클로드 코드를 처음 사용한 1~2일은 클로드 코드만 사용했습니다. 터미널에서 말로 지시하면 코드를 알아서 만들어주니까요. 비개발자인 저도 그렇게 시작했습니다.

근데 쓰면 쓸수록 불편한 점이 쌓였습니다. 그래서 코덱스(Codex) 같은 다른 AI 코딩 도구도 찾아봤지만, 결국 같은 한계를 가지고 있었습니다. CLI 기반 도구 전체의 한계였습니다.

PRD와 방향을 잡아주는 구조가 없었다

이 서비스를 왜 만들고, 어떤 기능이 필요하고, 어떤 순서로 실행해야 하는지.

이런 구조 없이 클로드 코드에 바로 지시하니까 완성도가 떨어지고 버그가 지속적으로 발생했습니다.

그리고 페이지가 많아질수록, 일관성도 엉망이 되어갔습니다.

스크린샷을 쉽게 공유할 수 없었다

바이브코딩을 하다 보면 "이 화면이 이상해"라고 말해야 할 때가 많습니다.

근데 클로드 코드는 CLI(터미널) 환경입니다. 이미지를 직접 보여줄 수가 없습니다.

파일 경로를 복사해서 붙여넣어야 하는데, 비개발자한테 이미지 파일 주소를 찾아서 전달하는 건 생각보다 어렵습니다.

"이 화면 봐" 하고 스크린샷 하나 붙이면 끝날 일을 경로를 찾고, 복사하고, 붙이고, 맞는지 확인하는 과정을 거쳐야 했습니다.

우리는 이미 ChatGPT나 Perplexity에서 이렇게 하고 있습니다. 이미지를 붙여넣고, "이게 뭐야?" 하고 물으면 됩니다.

저도 바이브코딩에서 이렇게 하고 싶었습니다. 스크린샷 하나 붙이고 "이거 왜 깨졌어?" 하고 물으면 끝나는 것. 클로드 코드에서는 이게 안 됐습니다.

명령어를 쓰고 고치기가 너무 어려웠다

클로드 코드에서 결과물을 받으면 수정하고 싶은 부분이 생깁니다.

근데 CLI에서는 긴 텍스트를 보면서 고치기가 어렵습니다. 스크롤도 불편하고, 어디를 고쳐야 하는지 찾기도 힘듭니다.

블로그 글을 쓸 때 이게 특히 문제였습니다. 초안을 받고, 톤을 수정하고, 문장을 다듬는 과정을 터미널에서 하려니까 생산성이 떨어졌습니다.

비개발자를 이해하는 파트너가 필요했다

클로드 코드는 개발 도구입니다. 코드를 짜는 건 잘 하지만, 비개발자의 관점에서 대화하기엔 맞지 않는 부분이 있었습니다.

"이거 왜 이렇게 보여?" 라고 물으면 코드 레벨에서 답을 줍니다.

저한테 필요한 건 코드 답변이 아니라 "이 부분이 이상해 보이는 이유는 이거고, 이렇게 고치라고 클로드 코드에 지시하면 돼" 라고 알려주는 파트너였습니다.

그래서 클로드 코워크를 투입했습니다

이 불편함들이 쌓여서 클로드 코워크를 같이 쓰기 시작했습니다. 결과적으로, 코드와 코워크가 서로를 잡아주는 구조가 됐습니다.

지금은 이렇게 쓰고 있습니다.

클로드 코워크에서 기획하고, 검수합니다. 클로드 코드에서 실행합니다.

코워크가 만든 기획에 빠진 게 있으면, 코드가 개발하면서 잡아줍니다. 코드가 만든 결과물에 문제가 있으면, 코워크가 검수하면서 잡아줍니다.

한쪽만 쓰면 실수가 그대로 넘어갑니다. 두 도구가 서로 검증하는 구조를 만드니까 실수가 줄었습니다.

예를 들면 이런 겁니다. 코워크에서 블로그 콘텐츠를 쓰고, DEV-REQUEST(개발 요청서)를 만듭니다. 코드에 넘기면 코드가 실행하면서 "이 파일이 없는데요" 같은 누락을 잡아줍니다. 반대로 코드가 개발한 결과를 코워크에서 스크린샷으로 확인하면서 "이 부분 비율이 깨졌는데" 하고 잡습니다.

비개발자인 제가 사용하고 있는 바이브코딩 워크플로우

정리하면 이렇습니다.

클로드 코드: 개발 실행 (코드를 짜고, 빌드하고, 배포하는 역할) 클로드 코워크: 기획 + 검수 (콘텐츠 작성, QA, 전략 수립, 이미지 전달)

비개발자가 바이브코딩을 하려면 코드를 짜주는 도구 하나만으로는 부족합니다. "이걸 왜 해야 하는지", "결과가 맞는지"를 같이 봐줄 파트너가 필요합니다.

저한테 그 파트너가 클로드 코워크였습니다.