AI 시대의 기획 커뮤니케이션, 설명 없는 목업과 스팩브릿지를 만든 이유

 

AI 도구를 쓰면서 기획하는 방식이 꽤 많이 달라졌습니다.
가장 크게 느낀 변화는 "화면을 만드는 비용"이 눈에 띄게 줄었다는 점이에요.
그런데 화면을 만들기가 쉬워지니, 예전에는 문제가 되지 않던 곳에서 새로운 문제가 생겼습니다.
오늘은 그 이야기를 정리해 보려고 해요.

 

예전에 저는 파워포인트로 화면 기획서를 만들었습니다.
화면 그림 옆에 번호를 붙이고, 번호마다 설명을 적는 방식이었어요.
이 버튼은 언제 눌리는지, 값이 비어 있으면 어떻게 되는지, 권한이 없으면 무엇이 보이는지 같은 내용이 한 장 안에 같이 있었습니다.
화면은 어설퍼도 설명이 있었기 때문에, 개발자가 문서를 보면 의도를 어느 정도 읽을 수 있었어요.

 

하지만, 내부에서 Claude로 화면 목업을 만들어 기획을 진행해 보니 상황이 달랐습니다.
AI가 만들어 주는 화면은 처음부터 꽤 그럴듯합니다.
눈으로 보면 바로 이해가 되는 것처럼 느껴져요.

그런데 그 화면에는 설명이 없었습니다.

화면은 있는데 "왜 이렇게 생겼는지"와 "이 화면이 지켜야 할 규칙"은 어디에도 적혀 있지 않았어요.

 

 

문제는 개발자와 이야기할 때 드러났습니다.
화면이 그럴듯해서 기획자는 "다 전달됐다"고 생각하기 쉬운데, 개발자 입장에서는 화면에 보이지 않는 부분이 훨씬 많습니다.
예를 들면 이런 것들이에요.

• 이 버튼은 어떤 조건에서 활성화되는지
• 값이 잘못 들어왔을 때 어떤 문구가 나와야 하는지
• 로그인하지 않은 사람에게도 이 화면이 보이는지

이런 질문이 메신저와 회의에서 하나씩 나오고, 답변도 여러 곳에 흩어졌습니다.
결국 기획서가 해 주던 일을 말로 대신하게 되었고, 말은 쌓이지 않고 사라진다는 점이 가장 컸어요.
화면은 빨리 만들었는데 소통에 드는 시간은 오히려 늘어난 셈이었습니다.

 

이 문제를 보완하려고 올해 2월쯤 개인 프로젝트를 시작했습니다.

이름은 스팩브릿지(SpecBridge)입니다.
핵심 생각은 간단해요.
별도의 문서나 코멘트 도구를 오가지 말고, 실제로 개발된 웹 화면 위에서 검토하고 그 화면의 스펙까지 같이 관리하자는 것이었습니다.
한 문장으로 줄이면 "웹 화면 자체를 살아 있는 기획서이자 검토 공간으로 만든다"예요.

기능은 크게 두 갈래로 나뉩니다.
하나는 화면 위에 핀을 꽂아 의견을 남기는 어노테이션이에요.
핀마다 댓글과 레이블, 해결 여부를 관리하고, 1차 기획 검토나 개발 검수처럼 검토 회차를 나눠서 볼 수 있게 했습니다.
다른 하나는 화면별 스펙 문서입니다.
정책을 마크다운으로 적고, DB 컬럼과 ERD를 정리하고, 화면에서 쓰는 API를 함께 적어 둘 수 있게 했어요.
기존 React 앱을 컴포넌트로 감싸서 붙이는 SDK 형태로 설계했습니다.

 

기능을 만들수록 두 개의 제품이 한 도구 안에 들어간 느낌이 들었습니다.
어노테이션은 "여기 고쳐 주세요"라고 말하는 도구이고, 스펙 문서는 페이지 전체의 정책과 데이터와 API를 정의하는 도구예요.
문제는 이 둘이 서로 연결되어 있지 않았다는 점입니다.
핀에 "회원정보 저장 오류"라고 적어도, 그것이 어떤 API나 어떤 컬럼과 관련 있는지 이어 줄 방법이 없었어요.

그래서 방향을 세 가지로 놓고 고민했습니다.
어노테이션 중심으로 가거나, 어노테이션과 스펙을 연결하거나, 아예 제품을 둘로 나누는 방법이었어요.
저는 연결하는 안이 이름의 뜻과 가장 잘 맞는다고 봤습니다.
화면의 문제와 실제 스펙 사이를 이어 주는 것이 말 그대로 브리지니까요.
지금은 이 도구를 "화면, 요구사항, 데이터, API를 연결하는 살아 있는 스펙 레이어"라고 정의하고 있습니다.

 

개발하면서 가장 어려웠던 부분은 탭을 처리하는 방식이었습니다.
화면 안에서 탭을 바꾸면 같은 페이지인데 보이는 내용이 달라지기 때문에, 핀을 어느 화면 상태에 붙여야 하는지가 애매해졌어요.
핀은 화면 위치를 기준으로 저장하는데, 그 위치가 어떤 탭 상태에서 찍힌 것인지까지 깔끔하게 담는 것이 쉽지 않았습니다.
이 부분이 아직 만족스럽게 풀리지 않아서, 탭이 많은 화면은 Figma를 같이 쓰면서 보완했어요.
화면 상태마다 프레임을 따로 둘 수 있다는 점은 Figma가 여전히 편했습니다.

 

이 경험을 하면서 정리한 생각이 하나 있습니다.
화면을 만드는 일은 점점 AI가 잘하게 되지만, 그 화면에 담긴 의도와 규칙을 남기는 일은 여전히 사람이 해야 한다는 점이에요.
오히려 화면이 쉽게 나오는 만큼 "설명이 없는 화면"이 더 쉽게 만들어집니다.
기획서의 역할이 화면을 그리는 것에서 의도를 남기는 것으로 옮겨 가고 있다고 느꼈어요.

그리고 그 의도는 화면과 떨어져 있으면 금방 잊힙니다.
그래서 화면 옆, 가능하면 화면 위에 같이 있어야 한다고 생각하게 되었습니다.
스팩브릿지는 결국 그 생각을 도구로 옮겨 보려는 시도예요.

 

스팩브릿지는 아직 진행 중입니다.
탭 처리처럼 풀지 못한 숙제가 남아 있고, 어노테이션과 스펙을 연결하는 부분도 더 다듬어야 해요.
조만간 깃허브에 공개할 예정이라, 공개되면 사용 방법과 함께 다시 정리해 보겠습니다.
그때는 실제로 써 보면서 알게 된 점을 같이 적어 보려고 해요.