당신이 AI 에이전트에게 계정 설정 화면을 요청했다고 가정해 봅시다. 그러면 그 에이전트는 카드 형태의 그리드, 당신이 언급한 적 없는 다크 모드 토글, 그리고 무해한 선호도 옆에 놓인 '계정 삭제' 제어판 등을 반환합니다. 당신은 이에 대해 이의를 제기합니다. 다음 프롬프트에서는 제품에 존재하지 않는 다른 레이아웃과 소셜 로그인 스위치를 에이전트가 발명해냅니다.
에이전트는 빈틈을 채웠습니다. 마치 추측을 제품 규칙처럼 취급한 것입니다.
'디자인 결정 방법(Design Decision Method)'의 첫 번째 단계는 바로 이러한 상황을 막기 위해 존재합니다. '1단계, 맥락 설정(establish context)'은 에이전트가 레이아웃에 대해 어떤 결정을 내리기 전에 먼저 간략한 개요와 이미 존재하는 제품을 읽도록 요구합니다.
1단계에서 요청하는 것들
이 방법론은 에이전트에게 다음 사항들을 명시하도록 요청합니다:
- 대상 사용자(the audience)
- 작업 빈도(how often the task happens)
- 실수가 초래하는 비용(what a mistake costs)
- 기기(the device)
또한 에이전트가 알고 있는 것과 가정하는 것을 분리하도록, 그리고 제품에 없는 규칙이나 기능을 발명하지 않도록 요청합니다.
이것이 바로 첫 번째 단계 전체입니다. 아직 와이어프레임도 없고, 색상 팔레트도 없습니다. 개요와 기존 제품을 짧게 읽은 후, 사실과 가정을 솔직하게 나열하는 것입니다.
실제 예시: example.com의 계정 설정 화면
만약 당신이 example.com에서 작은 제품을 운영하고 있고, 에이전트에게 계정 설정 화면을 요청했다고 가정해 봅시다. 이것은 절차가 어떻게 적용되는지에 대한 예시일 뿐이며, 사례 연구나 측정된 결과는 아닙니다.
이 방법론 없이 진행할 경우, 에이전트는 발명합니다. 왜냐하면 토글이나 카드, 삭제 경로는 다른 제품들에서 익숙하기 때문입니다.
하지만 1단계를 먼저 채운다면, 메모는 다음과 같이 보일 수 있습니다:
청중(Audience): 자신의 프로필을 관리하는 계정 소유자. 대부분 직접 가입한 사람들.
작업 및 빈도(Task and frequency): 이메일이나 비밀번호를 가끔 변경함. 알림 환경 설정을 거의 검토하지 않음. 계정을 삭제하는 경우는 거의 없음.
실수 비용(Cost of a mistake): 이메일이나 비밀번호는 보통(잠김 또는 메일 누락). 삭제나 청구서 변경은 높음.
기기(Device): 우선 휴대폰, 다음으로 데스크톱.
알려진 정보(Known): 제품에는 이메일, 비밀번호, 그리고 세 가지 알림 토글이 있음. 소셜 로그인은 없음. 팀 계정도 없음.
가정 (Assumptions) (표시됨): 오프라인 사용은 요청되지 않았으므로 설계하지 않음. 청구 설정은 다른 곳에 존재하며, 이 화면이 이를 발명하는 것은 아님.
이제 에이전트는 상상(발명)을 멈출 장소를 갖게 되었다. 제품에 없었던 다크 모드 스위치는 제외된다. 다른 앱들이 그렇게 한다고 해서 삭제 제어 기능이 저비용 환경 설정 옆에 배치되지 않는다. 선택적 추가 기능들은 사실처럼 은밀하게 포함되기보다 레이블링(labeling)된다.
알려진 것 대 가정된 것 (Known versus assumed)
유용한 부분은 이 분리이다. “알려진 정보(Known)”는 브리프, 코드 또는 이미 가지고 있는 화면에서 온다. “가정된 정보(Assumed)”는 나머지 모든 것이며, 표시된 상태로 유지된다.
만약 에이전트가 디자인을 변경할 수 있는 격차에 대해 질문할 수 없다면, 조용히 채우기(filling)하는 대신 결과물에서 가정을 목록화해야 한다. 레이아웃이 확정되기 전에 추측을 확인하거나, 수정하거나, 거부할 수 있다.
에이전트와 함께 구축할 때 이것이 중요한 이유 (Why this matters when you build with agents)
에이전트는 패턴을 완성하는 데 능숙하다. 하지만 제품이 그 패턴을 제공한 적이 없다는 것을 알아차리는 것은 덜 능숙하다. 화면은 완성된 것처럼 보이고, 상상된 부분들은 사용자가 클릭할 때까지 발견하기 어렵다.
맥락(context)을 설정하는 것은 첫 번째 결과물을 이 화면이 누구를 위한 것인지, 사람들이 얼마나 자주 사용하는지, 실수가 비용이 얼마인지, 그리고 어떤 기기에서 사용되는지에 대한 간결한 진술로 만든다. 이후 단계들은 그 진술을 기반으로 구축된다. 이것 없이는, 추측을 장식하는 데만 집중하게 된다.
이 방법론이 시간을 절약한다고 주장하지는 않는다. 그것은 측정된 바가 없다. 하지만 제공하는 것은 UI가 되기 전에 발명된 규칙을 포착할 수 있는 장소이다.
비례적으로 유지하기 (Keep it proportional)
사소한 복사본 변경(copy change)이라고 해서 긴 맥락 설명이 필요하지는 않습니다. 이 방법은 모든 작은 수정에 필수로 요구되는 것이 아니라 공유된 절차입니다. 하지만 해당 변경 사항이 새로운 기능을 발명하거나, 비용이 큰 액션을 포함하거나, 다른 도메인의 관례를 가져올 수 있는 경우에는 몇 줄을 할애하여 기록해야 합니다.
디자인 기록 템플릿에는 이를 위한 짧은 '맥락(Context)' 섹션이 있습니다. 여기에는 대상 독자 및 역할(audience and roles), 주요 작업 및 빈도(primary tasks and frequency), 오류 비용(cost of error), 장치(device), 알려진 사실(known facts), 그리고 가정(assumptions) 등이 포함됩니다. 변경 사항에 필요한 만큼 이 섹션을 활용하십시오.
배치되는 위치 (Where this fits)
맥락 설정은 6단계 중 첫 번째 단계입니다: 맥락 설정, 시각 시스템 선택, 레이아웃 전 객체 매핑, 결정 기록 작성, 각 뷰 구조화, 그리고 배포 및 검증 순서로 진행됩니다.
사용해 보기 (Try it)
Design Decision Method는 AI 에이전트를 사용하여 인터페이스를 구축하는 개발자를 위한 경량의 디자인 의사결정 워크플로우입니다. 이 방법은 오픈 Agent Skills 형식을 따르며 MIT 라이선스가 적용되어 있습니다. Claude Code, Cursor, Gemini CLI, Codex에 대한 설치 경로는 README 파일에서 확인할 수 있습니다.