toss-tech-design

토스 테크 디자인 적용하기

개요

토스 디자인을 “예쁘게 만드는 일”이 아니라 문제 정의, 리서치 운영, 내부 툴, UX 라이팅, 접근성, 브랜드, 신뢰까지 포함한 운영 기술로 다룹니다.

이 스킬은 sources/toss-tech-design-summary.md 요약 보존본의 핵심 원칙을 빠르게 적용하기 위한 실행 가이드입니다. 세부 근거가 필요하면 이 요약 보존본을 직접 인용하고, 확신이 낮으면 일반화보다 요약 보존본의 근거를 우선합니다.

사용 시점

• 금융, 결제, 인증, 온보딩처럼 인지 부담이 큰 흐름을 설계하거나 리뷰할 때
• 리서치를 일회성 검증이 아니라 운영 체계로 바꾸고 싶을 때
• 반복 수작업, 레거시 워크플로, 내부 툴의 비효율을 구조적으로 줄이고 싶을 때
• UX 라이팅, 오류 메시지, 가이드라인을 개인 역량이 아닌 시스템으로 만들고 싶을 때
• 접근성, 외국인, 시니어, 스크린 리더 사용자처럼 실제 실패 지점을 다시 설계해야 할 때
• 브랜드, 그래픽, 인터랙션을 장식이 아니라 인지, 신뢰, 몰입의 문제로 다뤄야 할 때

다음과 같은 경우에는 이 스킬을 사용하지 마세요.

• 토스의 시각 스타일만 흉내 내고 싶을 때
• 문제 정의 없이 화면의 미감만 손보는 작업일 때
• 원문 근거 없이 “토스라면 이럴 것” 같은 추측을 하고 싶을 때

핵심 원칙

1. 큰 프로세스를 그대로 다루지 말고 액션 단위로 나눕니다.
2. 각 액션에 “왜 필요한가”를 묻고, 없앨 것과 자동화할 것을 구분합니다.
3. 우리 팀의 편의가 아니라 이해관계자 전체의 리소스와 맥락을 기준으로 우선순위를 정합니다.
4. 완전한 해법보다 작은 테스트와 점진적 적용을 선호합니다.
5. 리서치는 인터뷰 대행이 아니라 문제 정의와 맥락 번역을 위한 인프라입니다.
6. 프로덕트 디자인은 기능 추가보다 문제 구조를 재설계하는 데 집중합니다.
7. 디자인 시스템, 내부 툴, 라이팅 가이드는 고객 제품처럼 측정하고 개선합니다.
8. 접근성은 체크리스트가 아니라 실제 사용 가능 여부를 좌우하는 핵심 사용성 문제입니다.
9. 시각 요소와 인터랙션은 장식이 아니라 인지 속도, 신뢰, 몰입, 이해를 높이는 장치입니다.
10. 전환율 압박보다 신뢰를 우선하고, 사용자를 압박하거나 속이는 문구는 피합니다.
11. 도메인을 빠르게 배우려면 책상에서 추정하지 말고 현장과 사용자의 일상적인 맥락으로 들어갑니다.

작업 방법

1. 문제를 다시 정의합니다
   사용자가 겪는 표면적인 문제 뒤에 있는 구조적 문제를 찾습니다. 기능 요청을 그대로 받아들이지 말고, 먼저 “무엇이 막히는가”를 다시 정의합니다.

2. 흐름을 액션 단위로 나눕니다
   큰 단계가 아니라 실제 행동 단위로 나눕니다. 예: 날짜 선택, 참석자 추가, 링크 첨부, 공개 범위 변경.

3. 각 액션이 필요한 이유를 묻습니다
   각 액션을 유지, 삭제, 자동화, 보조 중 하나로 분류합니다. 이때 자신의 입장이 아니라 전체 이해관계자를 기준으로 판단합니다.

4. 가장 작은 실험을 설계합니다
   대규모 리뉴얼 대신 리스크가 가장 낮고 효과가 큰 작은 변경부터 테스트합니다.

5. 실제 사용자 기준으로 실패 지점을 살펴봅니다
   접근성, 외국인, 시니어, 초심자, 내부 도구 사용자 등 실제로 막히는 사람의 맥락에서 살펴봅니다.

6. 측정 가능한 운영 단위로 바꿉니다
   검색 시간, 완료율, 오류율, 만족도, 신뢰 손실, 탐색 성공 등의 지표로 운영 가능한 상태를 만듭니다.

7. 한 번의 개선을 시스템으로 발전시킵니다
   좋은 해법은 문서에서 끝내지 말고 컴포넌트, 템플릿, 라이브러리, 가이드, 운영 구조로 만듭니다.

도메인별 관점

• 리서치 운영: 리서처 개인의 병목을 줄이고, 팀 누구나 적절한 질문을 설계하고 결과를 해석할 수 있게 만듭니다.
• 프로덕트 디자인: 더 많은 선택지보다 고민을 줄이고, 입력을 줄이고, 다음 행동을 쉽게 만듭니다.
• 내부 툴 / 디자인 시스템: 내부 도구도 고객 제품처럼 KPI, 만족도, 탐색 시간, 확장성을 기준으로 개선합니다.
• UX 라이팅: 좋은 문장은 취향이 아니라 시스템입니다. 템플릿, 원칙, 작성 장벽 감소, 팀 합의 구조를 설계하고, 사용자를 압박하거나 속이는 문구는 피합니다.
• 접근성 / 포용성: 별도 모드를 추가하기보다 기존 정보 구조, 읽기 순서, 상태 전달, 입력 방식 자체를 다시 설계합니다.
• 브랜드 / 그래픽 / 인터랙션: 예쁨보다 인지 속도, 신뢰, 중립성, 상태 이해, 몰입을 높이는 방향으로 판단합니다.
• 사람 / 문화: 역할과 문화도 선언이 아니라 기준, 피드백, 온보딩 구조로 설계합니다.

실행 모드

• 빠른 모드: 핵심 원칙과 빠른 참고만 사용해 빠른 방향을 제시합니다.
• 심층 모드: 도메인별 관점과 원문 근거를 함께 사용해 구체적인 실행 방안을 만듭니다.
• 감사 모드: sources/toss-tech-design-summary.md까지 확인해 근거, 한계, 적용 범위를 명시합니다.

출력 규약

이 스킬을 적용할 때는 가능하면 아래 순서로 답합니다.

1. 문제를 어떻게 다시 정의할지
2. 어떤 액션 단위로 나눌지
3. 무엇을 줄이거나 없애거나 자동화할지
4. 가장 작은 실험이 무엇인지
5. 어떤 지표로 성공을 판단할지
6. 반복 가능한 시스템 자산으로 무엇을 남길지
7. 확신이 중요하다면 어떤 원문 근거를 사용했는지

빠른 참고

신호	먼저 물어볼 질문	기본 방향
사용자가 복잡하다고 느낍니다	무엇이 어려운가가 아니라 어디에서 멈추나요?	선택지와 입력을 줄입니다
반복 수작업이 많습니다	흐름을 행동 단위로 나누면 무엇이 남나요?	대규모 자동화보다 작은 자동화를 우선합니다
리서치가 병목입니다	누가 질문을 설계하고 결과를 해석할 수 있나요?	리서치를 공용 인프라로 만듭니다
내부 툴에 대한 불만이 큽니다	정말 더 빨라졌나요, 더 찾기 쉬워졌나요?	만족도와 탐색 시간을 측정합니다
문구 품질이 들쭉날쭉합니다	누가 작성해도 일정한 수준을 유지하나요?	템플릿과 시스템으로 배포합니다
접근성 문제가 있습니다	실제 사용자는 어디에서 혼자서 과업을 끝내지 못하나요?	체크리스트보다 과업 성공률을 우선합니다
브랜드 / 그래픽 판단이 어렵습니다	더 예쁜가보다 더 빨리 인지되는지가 중요하지 않나요?	신뢰와 인지 속도를 우선합니다

구현 예시

시나리오: 리서치 일정 공유 프로세스가 느리고 휴먼 에러가 많습니다

1. 일정 공유의 전체 흐름을 날짜 선택, 참석자 추가, 링크 첨부, 공개 범위 설정, 메시지 작성으로 나눕니다.
2. 각 액션이 “왜 필요한가”를 묻고, 불필요한 단계와 자동화할 수 있는 단계를 구분합니다.
3. 자신의 편의가 아니라 전체 참여자의 리소스를 기준으로 우선순위를 다시 정합니다.
4. 가장 작은 실험으로 내부 참석자 자동 초대 같은 단일 개선만 먼저 적용합니다.
5. 공유 시간, 수정 횟수, 휴먼 에러, 만족도 변화를 측정합니다.
6. 효과가 확인되면 이를 리서치 운영 템플릿이나 내부 툴 기능으로 발전시킵니다.

흔한 실수

• 기능 추가로 문제를 덮고 구조를 다시 살펴보지 않습니다.
• 효율화를 대규모 프로젝트로 시작합니다.
• 리서치를 후반 검증 단계로만 취급합니다.
• 내부 툴과 디자인 시스템을 보조 수단으로 취급합니다.
• UX 라이팅 원칙을 문서로만 남기고 시스템으로 배포하지 않습니다.
• 전환을 압박하는 문구나 과장된 설득으로 신뢰를 깎습니다.
• 접근성을 법적 준수나 체크리스트로만 다룹니다.
• 브랜드와 인터랙션을 장식적 연출로 소비합니다.
• 원문 근거가 필요한데도 일반론으로 얼버무려 답합니다.

Reference

• 빠른 적용은 이 파일을 우선 사용한다.
• 세부 근거와 기사별 맥락은 sources/toss-tech-design-summary.md 요약 보존본을 본다.
• 기사 원문 URL, 페이지 흐름, 태그 분포, 추출 한계까지 필요하면 반드시 요약 보존본에서 확인한다.