디자인 의사결정 기록 — 왜 그렇게 했는지 남기기

디자인 의사결정 기록이 없으면 6개월 전에 만든 화면을 새로 합류한 팀원이 보고 묻는다. “이 버튼은 왜 여기 있어요? 왼쪽에 두는 게 더 자연스러울 것 같은데요.” 정작 그 결정을 내린 사람도 정확한 이유가 기억나지 않는다. 당시 여러 대안을 검토했고 나름의 근거가 있었지만, 그 과정은 어디에도 남아있지 않다. 디자인 의사결정은 결과물인 화면만 남고, 그 화면에 이르기까지의 논의와 이유는 휘발되는 경우가 대부분이다.

1. 6개월 후 아무도 이유를 기억하지 못한다

디자인 작업은 코드와 달리 커밋 로그 같은 자연스러운 기록 장치가 없다. 화면 파일은 계속 갱신되고 이전 버전은 쉽게 덮어써진다. 그 결과 “왜 이렇게 만들었는가”라는 질문에 답할 수 있는 사람은 오직 당시 결정에 참여했던 사람의 기억뿐이고, 그 사람이 팀을 떠나면 이유 자체가 사라진다. 새로 합류한 사람은 같은 논쟁을 처음부터 반복하게 되고, 이는 프로젝트가 길어질수록 점점 큰 비효율로 쌓인다.

2. 결정만 남고 이유는 사라지는 흔한 패턴

기록을 아예 안 하는 팀만 문제인 것은 아니다. 회의록에 “필터를 상단으로 옮기기로 함”이라고만 적어두고, 왜 그렇게 정했는지는 빠뜨리는 경우도 흔하다. 결정 자체는 남았지만 이유가 없으니, 나중에 그 결정을 다시 검토할 때는 결국 처음부터 논의를 다시 시작해야 한다. 결과만 있고 근거가 없는 기록은 사실상 기록하지 않은 것과 크게 다르지 않다.

이 문제를 피하려면 회의록을 “무엇을 정했다”로 끝내지 않고, 반드시 “왜 그렇게 정했다”까지 한 문장이라도 덧붙이는 습관을 들여야 한다. 짧아도 괜찮다. 이유 한 줄이 있고 없고의 차이는 나중에 검토할 때 크게 벌어진다.

3. 디자인 의사결정 기록의 최소 형식

거창한 문서화 시스템은 필요 없다. “검색 결과 화면에 필터를 상단에 둘지 좌측에 둘지 검토했다. 모바일 비중이 높은 사용자층을 고려해 상단 배치를 선택했다. 2026년 8월”처럼 짧게 적어두면, 나중에 같은 논의가 다시 나왔을 때 처음부터 다시 토론하는 대신 이 기록을 출발점으로 삼을 수 있다. 소프트웨어 개발에서 쓰이는 아키텍처 결정 기록(ADR) 형식도 본질적으로 같은 원리를 따른다.

4. 어디에 기록할 것인가

기록의 형식보다 중요한 것은 접근성이다. 디자인 파일 안에 별도 페이지로 남기거나, 팀이 이미 쓰는 문서 도구에 프로젝트별 로그를 만드는 방식 모두 가능하다. 핵심은 새로운 도구를 하나 더 만드는 게 아니라, 이미 팀원들이 매일 들여다보는 곳에 기록을 붙이는 것이다. 디자인 시스템 거버넌스를 운영하는 팀이라면 컴포넌트 변경 이력에 결정 기록을 함께 남기는 방식도 효율적이다.

5. 기록은 누구의 책임인가

기록 문화가 정착되지 않는 또 다른 이유는 이 책임이 누구에게도 명확히 배정되어 있지 않기 때문이다. “누군가 남겨두겠지”라는 생각으로 모두가 미루면 결국 아무도 기록하지 않는다. 회의를 주재하는 사람이 마지막 5분을 할애해 오늘의 결정과 이유를 함께 정리하는 역할을 맡는 식으로, 최소한 한 사람에게라도 이 책임을 명시적으로 지정해두는 편이 실질적으로 작동한다.

이 역할을 매번 같은 사람이 맡을 필요는 없다. 회의마다 돌아가면서 기록 담당을 정하면 특정 한 사람에게 부담이 몰리지 않고, 동시에 팀 전체가 “왜 이 결정을 내렸는가”를 스스로 정리해보는 훈련도 함께 된다.

6. 마치며

모든 결정을 기록하려고 하면 기록 자체가 업무를 늦추는 부담이 된다. 되돌리기 쉬운 사소한 선택까지 문서화할 필요는 없다. 크리틱 세션에서 나온 결론이 대표적인 기록 대상이다.

디자인 의사결정 기록은 미래의 팀원에게 보내는 짧은 편지와 같다. 오늘 내린 결정 하나를 다섯 줄로 남겨보는 것부터 시작해보자.