한 줄: 좋은 설계는 자신의 존재를 잊게 만든다. 나쁜 설계는 사용자가 “왜?”라고 묻게 하며 계속 자기소개를 한다.
0. 5초 요약
상위 랭크의 평일 낮, 상대가 잘 잡히지 않는 카드게임을 생각해 보자. 플레이어가 적은 것은 UI가 해결할 수 없지만, 실패할 때마다 사람이 직접 재시도를 눌러야 한다면 얘기가 달라진다. PvP인데 첫 전투가 UI전이다.
그래서 원칙은 간단하다. 대전 이외의 것으로 싸우게 하지 마라. 사람은 “보통 다음은 이렇게 된다”, “이 목적이면 구조가 이래야 한다”는 예측을 갖고 있다. 현실이 어긋나면 “어?”, “왜?”, “이상한데?”가 나온다.
이 글에서는 이를 실무적으로 구조적 불일치 감지라고 부른다. 정식 심리학 용어는 아니며 prediction error, expectancy disconfirmation, processing fluency, person–environment fit, expectancy violations, 전문가 직관을 연결하는 설명용 이름이다.
위화감은 경보다. 원인에 대한 판결은 아니다.
1. 발단: 첫 보스가 재시도 버튼
랭크 상승 → 사람 적음 → 매칭 실패 → 재시도 → 또 실패 → 또 재시도. UI가 사람을 만들 수는 없지만 자동 재검색이나 지속 검색은 설계할 수 있다.
불만은 “상대가 없다”에서 “왜 내가 검색 담당자냐?”로 바뀐다. 카드게임은 카드, 템포, 리스크와 승부를 시켜야 한다. 수동 매칭 재가동 기사라는 부업을 주면 안 된다.
사람을 cron으로 만들지 마라. 게임을 켰지 UI 운영팀에 입사한 게 아니다.
2. 원칙: 목적 밖 PvE를 없애라
사용자의 목표와 무관한 마찰을 사용자 업무로 넘기지 마라. 쇼핑하려다 회원가입과 싸우고, 예약하려다 빈자리 화면과 싸우고, 업무를 끝내려다 승인권자 찾기 게임을 하고, 자동화를 해놓고 매일 사람이 “오늘도 자동인가” 감시하는 것이 전부 목적 밖 PvE다.
아무도 “결제 폼 격파” 업적을 원하지 않는다. 좋은 서비스는 사용자의 적을 늘리지 않는다.
3. 완성도가 높으면 “아무 느낌도 없다”
자동문이 열리고, 결제가 끝나고, 검색하면 나오고, 다음 행동이 자연스럽고, 누가 결정하는지 명확하고, 대화가 평범하게 통한다. 감상은 “별거 없음”.
하지만 그게 강하다. processing fluency 연구는 처리하기 쉬운 정보가 호감, 확신 등 다양한 판단과 연결될 수 있음을 다룬다. 기대와 실제 경험의 관계도 서비스 만족도에 중요하다.
성숙한 시스템은 투명해지고, 미성숙한 시스템은 “여기 눌러”, “다른 부서에 물어”라고 계속 자기소개한다. 나쁜 설계는 자기소개가 시끄럽다. 좋은 설계는 사라진다.
4. 연구 언어로 번역하기
Prediction error: 264개 신경영상 연구를 통합한 메타분석은 보상, 처벌, 행동, 인지, 지각, 사회적 추론 등에서 예측오차를 검토했다. 일상어로는 “어? 다음이 이거야?”
Expectancy disconfirmation: 2024년 메타분석은 150 records, 168개 독립 연구, 58,597명을 통합했다. 만족은 성능만이 아니라 기대와 실제 차이에도 영향을 받는다.
Processing fluency: 읽고, 찾고, 이해하고, 예측하기 쉽게 하라. 고객의 뇌를 무료 보조 CPU로 쓰지 마라.
Person–Environment Fit: 좋은 환경도 사람과 맞지 않으면 불편하다. 비싼 신발도 사이즈가 안 맞으면 아프다.
Expectancy Violations Theory: 사람·관계·상황에서 기대한 행동이 어긋나면 주의를 끈다. 예상보다 친절한 긍정적 위반도 있다.
5. 구조적 불일치 5종
- 목적–수단: 빨리 하자며 승인 3개 추가.
- 책임–권한: 알아서 하라며 결정하면 왜 마음대로 했냐고 함. 지뢰밭 체험학습.
- 말–행동: 도전을 환영한다며 실패만 오래 벌줌. 포스터와 현장이 다른 회사.
- 평가–성과: 생산성을 원하면서 오래 남아 있는 행동을 보상. 사람은 점수 따는 법을 최적화한다.
- 인간–시스템: 반복 클릭, 중복 입력, 매일 수동 시작, 이상 없음 확인. 사람을 cron으로 만들지 마라.
6. 센서의 사고 흐름
목적 파악 → 합리적 구조 예측 → 현실 관찰 → 차이 발견 → 왜? → 원인·기준·책임 확인 → 필요하면 재설계.
이상한 점을 잘 찾는 것이 곧 부정적인 성격이라는 뜻은 아니다. 다만 한번 불필요한 단계를 발견하면 평생 보인다. 신발 속 돌멩이가 산책 전체의 주인공이 된다. 세계가 UI Debug Mode에 고정된다.
7. 서비스: UI를 보스전으로 만들지 마라
중복 입력, 불필요 확인, 예측 가능한 실패 뒤 수동 복구, 뒤로 가면 사라지는 입력, 불명확한 버튼, 원인 대신 코드만 보이는 오류, 시스템이 이미 아는 정보의 재질문을 찾아라.
작은 마찰도 반복되면 경험 전체를 점령한다. 성숙한 서비스는 “무엇을 추가할까?”뿐 아니라 “무엇을 더 이상 의식하지 않아도 될까?”를 묻는다.
8. 환경: 제도 버그를 근성으로 패치하지 마라
누가 결정하는지 몰라 베테랑에게 묻고, 완료조건이 없어 눈치를 보고, 데이터 위치가 불명확해 아는 사람을 찾고, 시스템이 안 이어져 Excel로 붙이고, 스케줄이 깨져 사람이 매일 감시한다.
일이 끝났다고 시스템이 정상인 것은 아니다. 사람이 결함 있는 제도를 실시간 수동 보정하는 것일 수 있다. 유능한 사람이 나쁜 프로세스를 연명시키는 역설도 생긴다. 지옥의 상부상조다.
9. 사람: 위화감은 독심술이 아니다
말과 행동의 반복 모순, 상황마다 바뀌는 규칙, 한 방향으로만 움직이는 책임은 관찰할 가치가 있다. 하지만 “불일치를 봤다”와 “악의가 있다”는 다르다.
사실, 예상, 정확한 차이, 대안 설명, 다음 검증을 나눠라. 위화감은 화재경보기지 방화범 사진이 아니다.
10. 전문가 직관은 언제 맞는가
Kahneman과 Klein은 2009년, 신뢰할 수 있는 직관에 학습 가능한 규칙성이 있는 환경과 충분한 연습·피드백이 중요하다고 논의했다. 결과 확인이 어렵고 규칙이 자주 바뀌며 우연성이 강하면 경험이 길다고 촉이 정확한 것은 아니다.
맞은 촉만 기억하지 말고 틀린 촉도 기록하라. 자기 기억 리뷰에서 별 5개만 필터링하지 마라.
11. 위화감을 개선으로 바꾸기
목적을 적고 → 현상 프로세스를 적고 → 목적 밖 전투를 찾고 → 왜 사람이 하는지 기술·안전·비용·정책·레거시를 확인하고 → 없애기·자동화·통합·가시화하고 → 개선 후 “왜?”가 줄었는지 본다.
12. Why Count
한 번 이용하면서 “왜 눌러?”, “왜 또 입력해?”, “왜 저 사람에게 물어?”, “왜 내가 체크해?”, “왜 이 규칙?”을 몇 번 생각하는지 센다.
0회: 투명. 12회: 양호. 35회: 시스템이 등장인물이 됨. 6회 이상: 제품이 아니라 운영·유지보수를 체험 중. 정식 학술척도는 아니지만 개선 포인트를 찾기 쉽다.
13. “평범함”은 최고급 상품
문은 열리고, 전기는 켜지고, 검색은 찾아지고, 결제는 끝나고, 조직에서는 누가 결정하는지 이해되고, 관계에서는 매번 규칙을 재구성하지 않아도 되는 것이 정상이다.
그래서 좋은 설계의 평가는 “그냥 평범했어요”가 되기 쉽다. 그 평범함 뒤에 엄청난 예외처리와 테스트가 있다. 최고의 설계는 만들기 어려웠다는 흔적을 숨긴다. 식당은 “오늘도 주방에 불 안 났습니다”라고 발표하지 않는다. 그냥 밥을 낸다.
14. 결론: 좋은 설계는 사라진다
위화감은 세상이 틀렸다는 증거도, 내가 옳다는 증거도 아니다. 내부 모델과 관찰한 현실이 다르다는 알림이다.
관찰과 해석을 나누고, 불일치를 분류하고, 원인을 검증하고, 불필요한 마찰을 없애면 결국 “왜?”가 사라진다.
대전 밖에서 싸우게 하지 마라. 일 밖에서 일하게 하지 마라. 살기 위해 운영·유지보수까지 시키지 마라. 사용자를 시스템의 무료 디버거로 만들지 마라.
