기획서 대신 화면이 온다

우리 조직에서 기획은 사업팀이나 마케팅팀에서 넘어온다. 전담 기획자가 없는 조직이 대개 그렇듯, 요청은 정제된 기획서보다는 아이디어 메모에 가까운 형태로 온다. 그걸 받아서 실제 구현 가능한 형태로 확인하고 정리하는 건 자연스럽게 개발자들의 몫이 된다.

이런 구조는 어디서나 비슷한 긴장을 만든다. 개발자 쪽에서는 “정리된 기획을 가져와 달라”는 요구가 나오기 쉽고, 요청하는 쪽에는 “개발자들은 안 된다는 말부터 한다”는 인상이 쌓이기 쉽다. 근데 한 발 떨어져서 보면 양쪽 다 이해가 된다. 사업팀과 마케팅팀은 기획자가 아니다. 전문적인 기획서를 만드는 건 그들에게 어려운 일이고, 애초에 그들의 업무도 아니다. 글로 어느 정도라도 정리해서 가져오면 충분히 제 몫을 한 것이다.

문서가 아니라 코드가 온다

그런데 요즘 새로운 케이스가 생겼다. 바이브 코딩이 가능해지면서, 고객이 원하는 기능을 타팀이 직접 바이브 코딩으로 시각화해서 들고 오기 시작했다. 문서 대신 “이렇게 동작했으면 좋겠어요”라며 실제로 돌아가는 화면을 가져오는 것이다.

처음엔 당황했다. 받은 게 기획서도 아니고 스펙도 아니고 코드니까. 근데 어쩌겠나, 이걸 재료로 기획을 만들어 나가기로 했다.

받은 코드를 기획으로 풀어낸다. 그 화면이 의도하는 요구사항이 뭔지 역으로 정리한다. 화면에 보이는 것뿐 아니라, 화면에 안 보이는 규칙(어떤 조건에서 이 버튼이 비활성인지, 데이터가 없으면 뭘 보여줄지)을 질문 목록으로 뽑는다.
기술 검토를 같이 진행한다. 실제 시스템 기준으로 가능한 것, 불가능한 것, 다르게 풀어야 하는 것을 구분해서 공유한다. “안 된다”가 아니라 “이 방식 대신 이렇게 하면 같은 목적을 달성한다”로.
화면 플로우를 도식화해서 역으로 검토 요청한다. 정리한 기획과 플로우를 들고 “이렇게 진행하면 되는지” 타팀에 다시 확인받는다.

확정된 화면은 스킬이 받는다

이 왕복이 끝나면 확정된 화면이 피그마로 넘어온다. 여기서부터는 다시 스킬의 몫이다. /figma에 피그마 URL을 주면 디자인 컨텍스트를 읽어 컴포넌트 트리를 설계하고 구현까지 한다.

이 스킬은 처음에 하나의 파일에 변환 규칙을 전부 적어뒀는데, 프로젝트마다 규칙이 달라서 금방 감당이 안 됐다. 그래서 /figma는 현재 작업 디렉토리에서 프로젝트를 판별하고 해당 규칙 파일을 로드하는 데까지만 하게 하고, 실제 규칙은 프로젝트별 스킬로 떼어냈다. 오케스트레이터와 do-* 스킬의 관계를 한 번 더 쓴 셈이다. 규칙 파일에는 user-invocable: false가 붙어 있어서 내가 직접 부를 수도 없다.

규칙 자체는 꽤 빡빡하게 적혀 있다. 예를 들어 사용자에게 보이는 텍스트는 예외 없이 i18n JSON에 키로 등록하고 t()로만 쓰라는 조항이 있는데, 그게 피그마 CSS를 그대로 반영하라는 조항보다 우선한다고 순서까지 적어뒀다. 규칙 두 개가 충돌할 때 무엇을 버릴지 정해두지 않으면 AI가 그 자리에서 임의로 고르기 때문이다. 모호한 기획이 임의 결정으로 이어지는 것과 같은 얘기이고, 그래서 우선순위가 없는 규칙 목록은 사실 규칙 구실을 못 한다.

왕복이 남긴 것

그러고 나서 느낀 건데, 이렇게 정리된 기획은 나에게도 좋은 경험이었다. 예측하지 못했던 예외 처리, 놓치고 있던 부분들을 구현에 들어가기 전에 먼저 확인하고 검토할 수 있었다. 예전처럼 구현 중간에 “어 이 케이스는 어떻게 하지”가 터져서 작업이 멈추는 일이 줄었다.

최근 작업이 딱 그랬다. 요청 자체는 화면 하나를 추가해달라는 한 줄짜리였는데, 스펙으로 다듬어보니 그 화면이 외부 서비스와 데이터를 주고받는 구조였다. 그래서 개인정보 처리와 동의 절차를 함께 검토해야 한다는 걸 이 단계에서 짚었다. 그에 맞춰 화면 플로우와 API 범위가 정해졌고, 보안 검토도 같이 걸었다. 기능 요구사항 한 줄이 동의 흐름, 화면 순서, API 설계, 보안 검토로 갈라진 셈이다.

이런 건 구현하다 마주치면 이미 늦다. 코드를 되돌리는 게 아니라 화면 설계를 되돌려야 하기 때문이다. 기획 단계의 검토가 기능 요구사항만이 아니라 그 옆에 붙는 법적·보안 요건까지 미리 끌어내는 이유다.

AI에게 구현을 맡기는 워크플로우에서는 이 앞단 검토가 특히 중요하다. 모호한 요구사항은 AI의 임의 결정이 되어 QA에서야 발견되니까, 기획 취합 단계의 왕복이 뒤 단계의 왕복을 줄여준다.

아직 결론은 못 내렸다

다만 이 방식이 좋다고 결론 내리기엔 아직 애매하다. 화면은 “이렇게 동작한다”를 보여주지, “왜 이게 필요하고 무엇을 해결하려는지”를 말해주지 않는다. 바이브 코딩된 화면을 처음 받았을 때 든 생각도 솔직히 “그래서… 뭘 원하시는 건데?”였다. 문서였다면 목적이 한 줄이라도 적혀 있었을 텐데, 화면에는 결과만 있고 의도가 없다. 그 의도를 코드에서 역산하는 작업이 통째로 내 몫이 된 셈이다.

그나마 AI가 있어서 넘어온 코드를 빠르게 분석하고 요구사항 후보를 뽑아낼 수 있었지, 이걸 손으로 뜯어봐야 했다면 문서 받는 것보다 오래 걸렸을지도 모른다. 그래서 이게 효율적인 방법인지는 사실 아직도 모르겠다. 확실한 건 이런 케이스가 앞으로 더 늘어날 거라는 것, 그리고 “이건 기획서가 아니다”라고 돌려보내는 선택지는 없다는 것이다.

사실 왕복 구조를 만든 데는 속마음이 하나 더 있었다. 정리된 요구사항과 화면 플로우 도식을 역으로 보내는 건 검토 요청이면서 동시에 시연이다. “적어도 이 정도가 있어야 서로 소통이 된다”를 말로 하는 대신 결과물로 보여주는 것. 바이브 코딩으로 화면을 만들 수 있다는 건 같은 AI로 목적과 조건, 예외 케이스를 정리하는 것도 가능하다는 뜻이다. AI를 쓸 줄 안다는 건 그럴듯한 화면을 뽑아내는 게 아니라, 이 정도는 정리해서 들고 오는 것 아닐까. “제대로 된 기획서를 가져와라”라는 요구는 갈등만 남기기 쉽다. 그래서 이번엔 요구 대신, 소통이 되는 기획의 실물을 왕복 속에서 계속 보여주는 쪽을 택했다. 이게 통할지는 두고 봐야겠지만, 적어도 방향은 이쪽이 맞다고 생각한다.

이 글은 클로드 코드 스킬로 티켓부터 배포까지 자동화한 이야기에서 기획 취합 부분만 떼어낸 것이다. 여기서 정리한 스펙이 그쪽 워크플로우의 입력이 된다.