바이브코딩과 어색해진 개발자와의 소통

요즘 PM 중에 바이브코딩을 한 번도 안 해본 사람을 찾기가 더 어렵지 않을까 싶다. 처음엔 신기했고, 그 다음엔 편했고, 사실 누구보다 열심히 쓰고있다. 그런데 회사에서는 어느 순간부터 불편한 점도 있었다.

처음 바이브코딩으로 프로토타이핑을 만든게 2~3개월 전쯤이었던 것 같다. 새로 검토 중인 기능의 인터랙션을 말로 설명하기가 어려워서, “이 정도 느낌의 화면을 한번 시각화해볼 수 있을까?” 정도의 가벼운 마음으로 시도했다. 30분 정도가 지나서 클릭이 되는 프로토타입이 떠 있었다. 처음 봤을 때는 솔직히 좀 들떴다. “이걸 회의에 들고 가면 설명이 훨씬 쉽겠다”는 단순한 생각이었다.

그 다음 회의에서 그 프로토타입을 보여줬다. 회의는 빠르게 진행됐다. “이 정도 흐름이면 와이어프레임을 그릴 때 참고하기 좋겠다”고 했고, 백엔드 개발자는 데이터 흐름을 빠르게 확인할 수 있어 좋다고 했다. 좋은 회의였다고 본다.

문제는 그 다음 단계에서 시작됐다.

프론트 개발자와의 그 일

본격적으로 프로젝트에서 바이브 코딩으로 프로토타이핑을 그렸던 적이 있다. 그리고 그 프로토타입을 프론트 개발자에게도 공유했을 때, 조금 미묘한 고민을 했다. 명시적으로 그 개발자분은 불편하다고 말하진 않았지만, 혹시나 내가 만든 프로토타이핑을 보고 오해가 있을까 걱정이 되었다. 마치 내가 개발자의 영역까지도 침범? 하는 것 같은 모습으로 비춰질까봐 조심스러웠다. 회의에서 “프로토타입이 때문에 프론트는 직접 개발하는 방식으로 진행했으면 좋겠다” 고 이야기했지만 그럼에도 뭔가 찜찜했다.

며칠 후에 친한 개발자에게 이 일을 이야기했다. 그 친구가 말한 의견은 이러했다. 디자이너의 와이어프레임은 “디자이너의 결과물을 검증하기 위한 사고의 도구” 로 받아들여진다. 그런데 내가 보여준 그 바이브코딩의 클릭 가능한 프로토타입은, 그 결의 도구가 아니라 이미 절반쯤 만들어진 프론트 결과물처럼 보일 수 있다. 같은 행위인데 받는 사람에게 닿는 무게가 달랐을 수도 있다고..

이 무게의 차이는 백엔드 개발자에게서는 거의 안 느껴졌다. “PM이 데이터 흐름을 좀 본대”는 백엔드 입장에서는 협업이 빨라지는 일이다. 그런데 프론트 영역은 다를 수 있겠다는 생각을 했다. 내가 즉 PM이 만든 UI는 프론트의 영역과 직접 충돌한다. 백엔드와 프론트, 두 영역에서 같은 도구가 다른 톤으로 받아들여졌다는 점이 신기하면서도 무거웠다.

사실 디자이너와의 관계도 이 지점에서 함께 흔들렸던 것 같다. 와이어프레임이 와이어프레임으로 끝나기 전에 PM이 화면을 먼저 만들어서 들고 오면, 디자이너의 설계 영역이 어디부터 시작해야 하는지가 흐려진다. 디자이너가 이걸 명시적으로 불편하다고 말한 적은 없지만, 명시적으로 말하지 않는다고 해서 그 흔들림이 없는 건 아니라는 생각이 든다.

사실 PM이 만든 프로토타입이 프론트 개발자와 디자이너의 전문성과 비교할 영역은 아니라고 본다.

내가 만든 프로토타입은 “이 정도 화면으로 이런 구성이 필요할텐데” “사용자가 이 화면에서는 필요한 것이니 이렇게 만들면 편리할지” 를 묻는 질문에 가깝다.

그 질문 자체는 PM의 일이라고 생각된다. 다만 그 질문을 클릭 가능한 형태로 던지는 순간 받는 사람에게 닿는 무게가 달라질 수 있다고 생각했다. 이게 도구의 문제이지, 누가 더 잘하느냐의 문제가 아니라고 본다. 당연히 개발자가 개발해줘야죠!

그래서 만든 사용 원칙들

사실 이런 불편을 해소하는 방법을 한 번에 찾지 못했다. AI를 사용하면서 지금 시점의 사용 원칙은 대략 세가지다.

첫째, 프로토타입은 “구현 제안”이 아니라 “사고의 도구”임을 먼저 명시한다. 공유하기 전 한 줄로 “이건 와이어프레임 대용이고, UI 결정은 디자이너와 프론트 영역”이라고 적는다. 자리 잡는 데 약간의 비용이 들지만, 그 한 줄이 있고 없고가 받는 사람의 무게를 바꾸는 것 같다.

둘째, 완성도는 와이어프레임 수준에 그친다. 색을 입히지 않고, 인터랙션 디테일을 만들지 않고, 폰트나 간격을 손대지 않는다. “여기까지가 PM의 영역”이라고 생각한다. (사실 잘 모르기도한다)

셋째, 결과물보다 “검증하고 싶었던 가설”을 먼저 공유한다. “이 화면을 만들었다”가 아니라 “이 가설을 확인하고 싶어서 이 형태로 만들어봤다”가 시작 문장이 되도록 한다.

동료의 한마디

얼마 전 그 프론트 개발자와 다시 같이 일할 일이 생겼다. 회식 자리에서 그때 얘기를 꺼냈더니, “사실 그때는 좀 곤란했는데 지금은 같이 일하기 편하다”는 답을 받았다. 어떤 부분이 편하냐고 물었더니, “가설을 먼저 얘기해주니까, 내가 어디까지 검증할지를 정할 수 있어서”라고 했다.

이 한마디가 사실 이 글의 결론에 가깝다. 도구가 PM의 결과물의 형태를 바꿨다면, 결과물의 모양만 바꾸는 게 아니라 그 결과물을 어떤 위치에 두는가도 같이 바뀌어야 한다는 것이다.

이건 도구의 문제가 아니라 직무 정의의 문제

이 편을 닫으면서 한 가지를 정리해두고 싶다. 바이브코딩의 어색함은 사실 도구의 문제가 아니라고 생각된다. PM이라는 직무의 경계가 흔들리는 것에 가깝다.

이전에는 PM이 만들 수 있는 결과물의 종류가 분명했다. 정책서, PRD, 요구사항 문서, 회의록. 그 외 영역은 다른 직무의 결과물이었다. 그런데 이제는 PM이 클릭 가능한 화면도, 데이터 분류 결과도, 시스템 영향 범위 추정도 만들 수 있다. 만들 수 있는 게 늘었다는 사실 자체는 좋은 일인데, 그게 자동으로 좋은 협업으로 이어지지 않을 때도 있는 것 같다. 규모가 큰 조직일수록..

개인의 프로젝트가 아니라면, 만들 수 있는 게 늘어난 만큼, 만들지 않을 선택, 개입하지 않을 선택, 도 같이 늘어나야 하지 않을까 싶다. 이게 AI를 쓰면서 천천히 배운 것이다. 지금도 매번 잘 되지는 않는다. 한 번씩 어긋난다. 그래도 어긋났을 때 “내가 어디서 자리를 잘못 잡았는지”를 묻는 일이, 이전보다는 조금 더 빨라졌다고 본다.

이건 결론이라기보다 여전히 진행 중인 질문이다.

AI 관련 시리즈를 쓰기 시작할 때 “정답을 알려주는 글이 아니라 같이 헤매는 동료의 작업기”라고 적었는데, 이 편이 그 약속에 가장 가까운 글인 것 같다.