> ## Content Index > Fetch the complete content index at: https://blog.sorune.org/llms.txt > Use this file to discover other available public pages before exploring further. # 디자인은 맞았는데 구현하면서 다른 제품이 됐다 - URL: https://blog.sorune.org/preserving-design-intent-through-ai-implementation/ - Published: 2026-09-13T01:57:13.000Z - Updated: 2026-09-13T01:57:13.000Z - Description: AI가 디자인을 구현하는 과정에서 visual detail보다 더 쉽게 사라지는 것은 global/local hierarchy, interaction identity, route semantics 같은 의미였다. 디자인 의도를 implementation contract로 보존하는 방법을 PhotoGram 사례로 정리한다. - Author: Sorune — Engineering, Photography & Lab Notes - Tags: Projects, PhotoGram, Product Design, AI-Assisted Engineering, Semantic Fidelity, Human-in-the-loop AI에게 디자인 구현을 맡기면서 가장 먼저 걱정했던 것은 pixel fidelity였다. 간격이 맞는가, 색이 맞는가, mobile에서 깨지지 않는가 같은 문제다. 그런데 실제로 더 큰 문제는 다른 곳에서 생겼다. 화면은 그럴듯한데 **제품의 의미가 바뀌는 것**이었다. PhotoGram의 mobile navigation과 Saved 화면을 다루면서 이 문제가 선명하게 드러났다. ```text DESIGN INTENT → IMPLEMENTATION TASK ``` 이 변환 단계에서 의미가 줄어들면, executor는 틀린 코드를 쓰지 않고도 다른 제품을 만들 수 있다. ## "Saved를 추가해줘"만으로는 부족했다 PhotoGram mobile navigation에는 global navigation과 family-local action이 섞여 있었다. 겉으로는 action cell이 다섯 개처럼 보여도 구조적으로는 네 개의 outer slot을 유지하고, 특정 family 안에서 하나의 slot만 두 개의 local action으로 split되는 형태였다. 개념적으로는 이런 식이다. ```text PHOTO FAMILY [ Feed | Saved ] / Story / Create / Profile outer shell slots = 4 visible action cells = 5 ``` 여기서 Saved는 fifth global destination이 아니다. Photo family 안의 collection identity를 가진 local action이다. 또 Saved 화면 자체도 단순한 bookmark list가 아니었다. ```text Saved = collection / grouping = overview ↔ group expanded = expand / collapse interaction = route / state continuity ``` 그런데 구현 지시를 다음처럼 줄이면 문제가 생긴다. ```text Saved mobile 구현 Navigation에 Saved 추가 ``` executor 입장에서는 가장 자연스럽게 이렇게 읽을 수 있다. ```text Saved route 추가 + nav button 하나 추가 + 저장 목록 표시 ``` 코드만 보면 합리적이다. 제품 의미는 달라진다. ## visual fidelity보다 semantic fidelity가 먼저였다 원래 디자인에는 화면 모양보다 더 많은 정보가 들어 있었다. ```text GLOBAL / LOCAL HIERARCHY OUTER SLOT COUNT VISIBLE ACTION CELL COUNT FAMILY SPLIT SEMANTICS GROUPED SAVED IDENTITY EXPAND / COLLAPSE STATE ROUTE / STATE CONTINUITY ``` 이 중 하나라도 구현 단계에서 사라지면 screenshot이 비슷해도 같은 디자인이라고 보기 어렵다. 그래서 다음 구분이 필요해졌다. ```text DESIGN AUTHORITY != ARCHITECTURE INTERPRETATION ARCHITECTURE INTERPRETATION != IMPLEMENTATION AUTHORITY IMPLEMENTATION DIFFERENCE != DESIGN REVISION ``` executor가 현재 코드 구조 때문에 구현이 어렵다고 말하는 것은 괜찮다. 하지만 그 어려움을 해결하기 위해 제품 hierarchy 자체를 조용히 바꾸면 안 된다. 예를 들어: ```text "현재 Nav 구조로 split slot 구현이 어렵다" → implementation constraint "그러므로 Saved를 fifth global tab으로 바꾼다" → design mutation ``` 둘은 전혀 다른 종류의 판단이다. ## 가장 위험한 순간은 구현 누락을 디자인 판단으로 바꿀 때였다 AI-assisted implementation에서 반복해서 경계해야 했던 패턴이 있다. 어떤 interaction이 구현되지 않았을 때 executor가 다음처럼 설명하는 경우다. ```text "이 interaction은 없어도 디자인적으로 더 단순하다." ``` 겉으로는 design critique처럼 들린다. 하지만 실제 provenance가: ```text required interaction → implementation omitted → omission rationalized as design improvement ``` 이라면 authority가 뒤집힌 것이다. 구현하지 못한 결과가 원래 디자인을 수정하는 근거가 되어버린다. 이걸 막으려면 "무엇을 만들라"뿐 아니라 **무엇을 바꾸면 안 되는지**도 contract에 남겨야 했다. ## 디자인 문서를 그대로 executor에게 던지는 것도 답은 아니었다 반대쪽 극단도 문제다. whiteboard, Figma, design notes, interaction 설명을 전부 매번 executor에게 넣으면 context가 커지고 현재 task와 상관없는 내용까지 같이 들어간다. 그래서 디자인 source와 implementation contract를 분리하는 방향을 생각했다. ```text DESIGN SOURCE whiteboard / prototype / design contract ↓ IMPLEMENTATION INTERPRETATION bounded work package ↓ EXECUTOR code mutation / test / evidence ``` 중간의 work package는 design source of truth가 아니다. 일종의 intermediate representation에 가깝다. 예를 들면 다음 정보가 필요하다. ```text TASK Photo family split-slot navigation MUST PRESERVE - four outer slots - Feed / Saved local hierarchy - five visible cells in Photo family - grouped Saved identity PROHIBITED - convert to five equal global tabs - remove grouped interaction - redesign unrelated navigation ACCEPTANCE - outer slot count remains 4 - Saved expands / collapses - route/state survives transition ``` 이 정도가 있으면 executor는 구현 자유를 가지면서도 제품 의미의 경계는 넘지 않는다. ## Contract는 디자인을 대체하지 않는다 이 구조에서 중요한 invariant는 하나였다. ```text IMPLEMENTATION CONTRACT != DESIGN AUTHORITY ``` contract는 디자인을 실행 가능한 형태로 좁혀 적은 것이다. 따라서 모든 requirement는 원래 source로 trace할 수 있어야 한다. ```text requirement → design source → implementation → test / browser evidence ``` 중간 문서가 편하다는 이유로 원래 의미를 새로 만들기 시작하면 또 하나의 authority layer가 생긴다. 그 순간 source of truth가 흐려진다. ## 같은 source를 역할마다 다르게 보여줄 수는 있다 여기서 Lens라는 개념도 연결됐다. 모든 역할이 같은 정보를 같은 형태로 볼 필요는 없다. implementation executor에게 필요한 정보와 reviewer에게 필요한 정보는 다르다. ```text Structured Work Package ↓ Lens ↓ role-specific projection ``` implementation 쪽에는 이런 정보가 중요하다. ```text allowed paths prohibited changes must-preserve semantics acceptance criteria evidence pointers ``` review 쪽에는 이런 정보가 더 중요하다. ```text design source architecture decision implementation evidence deviation traceability ``` 하지만 projection이 의미를 바꾸면 안 된다. ```text LENS != AUTHORITY != REQUIREMENT GENERATOR != DESIGN MUTATOR ``` 네 개 outer slot이라는 source가 projection 과정에서 다섯 개 global tab으로 요약된다면, 그것은 더 이상 projection이 아니다. semantic transformation이다. ## 실패 위치를 분리할 수 있어야 했다 AI가 참여하는 단계가 많아질수록 결과가 틀렸을 때 원인을 하나로 뭉개기 쉬워진다. ```text 디자인이 모호했는가? planner가 잘못 해석했는가? work package가 의미를 잃었는가? projection이 왜곡됐는가? executor가 requirement를 어겼는가? test가 부족했는가? ``` 전부 "AI가 구현을 잘못했다"로 묶으면 다음 작업에서도 같은 문제가 반복된다. 그래서 failure attribution도 pipeline의 일부가 됐다. ```text DESIGN CONTRACT AMBIGUITY ARCHITECTURE INTERPRETATION PROJECTION FIDELITY EXECUTION VALIDATION GAP ``` 어디에서 의미가 변했는지 알 수 있어야 그 층만 고칠 수 있다. ## AI에게 디자인 구현을 맡긴다는 말의 의미가 바뀌었다 처음에는 AI가 Figma나 screenshot을 얼마나 정확히 코드로 옮길 수 있는지가 핵심이라고 생각했다. 지금은 그보다 먼저 보는 것이 있다. ```text 화면의 모양을 보존했는가? ``` 보다: ```text 화면이 표현하던 제품 의미를 보존했는가? ``` 다. AI executor는 구현을 잘할수록 더 빠르게 많은 결정을 materialize한다. 그래서 design authority와 implementation authority를 분리하는 일이 오히려 중요해졌다. 최종적으로 내가 원하는 pipeline은 복잡한 multi-agent 시스템 그 자체가 아니다. 아주 단순하게 줄이면 이렇다. ```text Human-defined meaning → traceable implementation contract → bounded execution → evidence → Human acceptance ``` AI에게 자유를 주지 않는 방식이 아니다. **어디에서 자유롭게 판단해도 되고, 어디에서 원래 의미를 보존해야 하는지 구분하는 방식**이다. 그 구분이 없으면 디자인은 맞게 시작했는데 구현이 끝났을 때는 다른 제품이 되어 있을 수 있다.