프론트엔드
인제 본격적으로 프론트엔드를 위한 뼈대를 구축하는 작업에 들어갔다.
백엔드로 어느 정도 완성을 했으니...
프론트엔드부터는 Ai가 전부 코드를 치고, 나는 PM으로써 전체적인 부분을 조정하는 역할로 한번 넘어가 보기로 했다.
사실 내가 프론트엔드 개발을 제대로 해본 적이 없어서 그런 것도 있고, 무엇보다 코드 그 자체 보다는 UI/UX 등의 사용자 경험에 집중해보고 싶어서 그랬다.
결과적으로, 이틀에 걸쳐 디자인 MCP를 고르고, 선택을 다시 보류하고, 사내 카페 공간의 이미지를 여러 번 고쳐 그렸다.
남은 건 도구 이름이 아니라 "지금 무엇을 결정해야 하고 무엇은 아직 미뤄도 되는가"를 가르는 기준이었다.
그래서 글 이름도 여기부터는...'딴짓천국 디자인하기'로 바꾸었다.
MCP부터 고르려다 생긴 질문
Stitch와 Figma 공식 문서를 먼저 읽었다. Figma 공식 MCP는 현재 캔버스 쓰기를 지원하고, Stitch는 설명으로 화면을 생성·수정·변형하는 흐름을 지원한다. 두 도구를 비교할 때 "읽기 전용 vs 쓰기 가능"으로 단순화하지 않았다. 아직 시안이 없는 상태였으므로, 설명만으로 변형안을 만들어볼 수 있는 쪽이 먼저 필요했다. 그래서 Stitch를 첫 디자인 MCP로 선택했다.
다만 도구 디렉터리 검색 결과에 Stitch가 안 보인다고 해서 "MCP 자체가 없다"고 단정하지는 않았다. 디렉터리 미등재와 서비스 부재는 다른 사실이다. 인증·등록·연결 검증은 선택과 별개의 다음 단계로 남겨뒀다.
왜 티켓을 설계 티켓과 기능 티켓으로 나눴나
준비 문서 커밋·푸시와 GitHub 티켓 발행을 요청받은 뒤, "티켓도 나눠야 하는구나"라는 말이 나왔다. 이유는 단순하다. 설계 티켓은 선택·검증이 끝나면 닫히지만, 기능 티켓은 구현과 사용자 동작 검증까지 끝나야 닫힌다. 이 둘을 한 이슈에 섞으면, 아직 답이 없는 화면 구성이나 접속 방식을 AI가 임의로 정해버리고 구현을 시작하기 쉽다.
그래서 부모 이슈는 큰 방향을 담고, 자식 이슈는 한 번의 결정 또는 하나의 독립적인 기능만 담도록 설계했다. 자식 이슈 하나가 끝났다고 전체 프런트가 완성되는 게 아니라는 전제도 같이 세웠다. 이 기준으로 설계 지도·MVP 명세 2개와 설계/준비 5개·기능 4개, 총 11개 이슈를 발행했다. 구현 이슈는 기존 enhancement 라벨을 썼고, 아직 결정되지 않은 작업에는 ready-for-agent를 붙이지 않았다. 세부 결정이 안 끝난 일을 "에이전트가 바로 착수해도 되는 일"처럼 보이게 하고 싶지 않았기 때문이다.
Stitch 연결 직전에 멈춘 이유 — frontend-design 스킬
인증 방식(API key vs OAuth)과 Stitch 작업 공간(신규 전용 공간 vs 기존 공간), 두 가지 질문을 막 던지려던 참에 다른 질문이 들어왔다. "MCP 대신 Anthropic의 frontend-design 같은 스킬을 설치하는 건 어떨까?"
스킬과 MCP는 역할이 다르다. 스킬은 AI가 디자인을 판단하고 구현하는 방법을 안내하는 문서이고, Stitch MCP는 외부 서비스에서 실제로 시안을 만들고 고치는 연결이다. 스킬 설치 자체에는 외부 인증이 필요 없지만, 설치만으로 좋은 결과가 보장되는 것도 아니다. 공식 지침은 색상·글꼴·배치를 먼저 계획하고 검토한 뒤 코딩하라고 안내하고 있었다.
여기서 제안한 순서는 "스킬로 방향을 먼저 구체화하고, 외부 시안 도구가 필요해지면 그때 Stitch를 연결하자"였다. 사용자가 동의했고, Stitch 연결은 보류했다. frontend-design 스킬을 설치했고, 세션 마무리 시점에는 Web Interface Guidelines(web-design-guidelines)와 React Best Practices(vercel-react-best-practices)도 추가로 설치했다. 셋 다 설치만으로 구현을 시작한 건 아니고, UI 검토와 React/Next.js 성능 검토에 쓰는 참조로 남겨뒀다.
비슷한 맥락에서 create-design-system-rules도 물어봤는데, 이건 Figma 쪽 프롬프트로 디자인을 저장소 구현 방식에 맞춰 옮기는 규칙 파일을 만드는 도구였다. 지금은 Figma 연결도, 프런트 컴포넌트도, 합의된 디자인 규칙도 없는 상태라 도입을 보류했다. 스킬 이름과 MCP 기능을 구분하지 않으면 "설치했으니 뭔가 됐다"는 착각이 생기기 쉽다는 걸 다시 확인한 지점이다.
디자인 질문의 속도 조절
"방 선택과 닉네임 입력을 함께 보여줄지, 아니면 닉네임을 먼저 받을지" 같은 질문을 쌓아가다가 "오늘 안에 다 정해야 할까?"라는 질문이 돌아왔다. 답은 아니었다. 오늘 모든 디자인을 끝낼 필요는 없고, 결정에 필요한 구체적인 안부터 하나씩 보여주면 된다는 쪽으로 속도를 조정했다. 질문을 한꺼번에 늘리지 않는 것 자체가 하나의 결정이었다.
사내 카페, 그런데 왜 뻔한 게시판처럼 보였나
frontend-design 지침으로 색상·글꼴·배치를 먼저 ASCII로 정리하고, 창가 라운지(상단 풍경 + 아래 입장 영역)와 오피스 사이 카페(좌측 풍경 + 우측 입장 영역) 두 구성안을 만들었다. 추천은 두 번째였지만, 사용자 반응은 "둘 다 뻔한 게시판 같다"였다.
문제는 창문을 장식으로 두고 실제 화면은 목록과 폼으로 채운 점이었다. 사용자가 원한 건 "공간을 바라보는 듯한 느낌"이었다. 여기서 레이아웃 비교를 접고, imagegen 스킬로 카페 입구에서 창가·공용 테이블·주변 오피스가 보이는 원근감 있는 장면을 탐색하는 쪽으로 방향을 바꿨다. 이건 평면 레이아웃 문제가 아니라 시점의 문제였다는 뜻이다.
공간감을 이미지로 좁혀가기
이후 피드백은 전부 "공간을 어떻게 바라보게 할 것인가"에 관한 것이었다. 순서대로 보면:
- 첫 이미지는 카페 입구의 관찰자 시점이었는데, 사용자는 "탁자에 앉아 있는 느낌"을 원했다. 관찰자 시점을 1인칭으로, 탁자 면을 화면 아래에 두고 앉은 눈높이로 바꿨다.
- 앉은 공간감은 맞는데 시선 방향이 틀렸다는 피드백이 왔다. 햇살과 창을 등 뒤에 두고 카페 안쪽과 그 너머 오피스를 바라보는 방향으로 다시 수정했다.
- 식물을 없애고 안쪽 업무공간이 안 보이게 해달라는 요청이 이어졌다.
- 그런데 식물과 업무공간을 지우고 나니 "카페처럼 안 보인다"는 반응이 나왔다. 뒤에서 햇살이 들어오고 직접 창이 안 보여도, 고층빌딩 안에 있다는 느낌과 커피 머신·정수기·간식 상자 같은 장소성의 단서가 필요하다는 설명이었다. 벽과 좌석만 비워둔 탓에 "카페"라는 단서 자체를 잃었던 것이다. 셀프바와 건축적 채광·그림자를 더한 수정 시안을 다시 요청했다.
- "공간을 더 좁히자"는 요청이 있었는데, 처음엔 실내 전체를 작게 바꾸는 쪽으로 해석했다가 정정을 받았다. 의도는 전경 전체의 축소가 아니라 "커피 머신·정수기 왼쪽으로 깊게 이어지는 통로를 닫으라"는 것이었다. 기존 전경과 오른쪽 가구는 유지하고, 왼쪽의 먼 테이블만 벽으로 닫았다. 햇살도 옆에서 비추는 인상이 아니라 시청자 바로 뒤에서 들어오는 방향으로 다시 맞췄다.
이 과정에서 치수를 가정해 이미지 비례를 잡긴 했지만, 이걸 실제 서비스나 3D 공간의 확정 치수로 쓴 건 아니다. 이미지 생성 과정의 보조 수단이었을 뿐이다.
왼쪽 깊은 공간을 닫고 햇살 방향을 고친 마지막 이미지에 "좋아 이렇게 하자"는 승인이 나왔다. 이 이미지는 docs/drafts/frontend/assets/lounge-approved-view.png로 보관했다. 원본은 그대로 두고 복사했다. 이후 좌석 밀도를 더 줄여달라는 추가 피드백도 있었는데, 앞쪽 내 탁자와 맞은편 의자는 유지하고 배경의 반복 좌석만 줄이는 쪽으로 탐색을 이어갔다. 배경에 작은 2인 테이블 하나와 짧은 벤치를 남기는 구체안이 나왔지만, 이 정확한 수량 자체는 아직 확정된 정책이 아니다.
승인된 건 "공간의 기준"이지, 입장 폼의 세부나 실제 3D 기술·조작 방식까지는 아니다. 이 구분을 분명히 해두지 않으면 이미지 하나의 승인이 전체 프런트 설계의 승인으로 번지기 쉽다.
움직임의 범위: 메타버스가 아니라 고개를 돌리는 느낌
이미지 작업 중에 "사실 3D처럼 움직이는 걸 생각했는데 별로일까"라는 질문이 나왔다. 여기서 중요했던 건 이전에 분명히 제외했던 "이동형 메타버스"와, 앉은 자리에서 시선을 돌리는 연출을 구분하는 일이었다. 미세한 깊이감, 고정된 자리에서의 시선 회전, 자유로운 공간 이동은 전혀 다른 범위의 작업이다.
결국 사용자가 원하는 움직임은 "고개를 돌리는 느낌"으로 확정됐다. 자리는 고정하고 주변만 둘러보는 경험이다. 실제 3D 엔진 필요 여부, 회전 범위, 조작법, 모바일 동작은 전부 아직 정해지지 않았다. 고정된 시선 연출을 넣기로 했다고 해서 기존에 제외했던 메타버스형 이동 범위가 되살아나는 건 아니라는 점도 같이 못박아뒀다.
명세와 티켓, 그리고 남은 결정
to-spec으로 기존 프런트 MVP 명세(#2)에 방 선택·닉네임 동시 표시, 사내 카페 방향, 설치한 세 스킬, Stitch 연결 보류를 반영했다. 중복 명세를 새로 만들지는 않았다. to-tickets를 요청받았을 때 나온 질문은 "정하지 않은 부분이 있는데 이슈를 쪼개는 게 성급하지 않나"였는데, 답은 이렇다 — 큰 기능을 분할 초안으로 정리하는 것과, 세부 정책이 열려 있는 구현 티켓에 ready-for-agent를 붙이는 건 다른 문제다. 미결정 사항은 디자인·접속 경로 같은 결정 이슈로 남겨두고, 구현 티켓은 선행 조건이 실제로 해결된 뒤에야 범위와 완료 기준을 확정하기로 했다.
승인된 기준과 다음 단계
오늘 세션에서 바뀐 건 디자인 이미지와 문서뿐이다. 앱·백엔드 코드는 건드리지 않았고, 승인받은 공간 이미지를 기준 파일로 보관한 것, decisions와 NEXT 문서를 갱신한 것, 명세 초안의 오래된 창문/구성안 설명을 최신 합의에 맞춘 것이 전부다.
다음 단계는 승인된 공간 안에 방 선택·닉네임·채팅을 어떻게 배치할지를 디자인으로 검토하는 일이다. 3D 엔진, 조작법, 모바일 구도는 여전히 미정이고, Stitch 연결도 여전히 보류 상태다. 결정하지 않은 것을 결정한 것처럼 적지 않는 것, 그게 이번 두 세션에서 가장 자주 반복된 작업이었다.