이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 제가 작성한 버튼 레이블과 에러 메시지를 팀원이 다른 화면에 사용할 때마다 조금씩 달라지는 것을 보았습니다. 저장하기와 저장이 혼재되었고, 에러 메시지 문체도 제각각이었습니다. 이 문제를 정리하고 싶어서 노션에 UX 라이팅 가이드를 만들었습니다. 버튼은 동사로, 에러는 원인과 해결 방향으로 쓰는 원칙을 적고 예시를 함께 붙였습니다. 처음에는 팀원들이 잘 참고하지 않았지만, 리뷰 때 가이드 링크를 함께 남기는 방식으로 자연스럽게 사용을 유도하였습니다. 도전 과제는 문서를 쓰는 것보다 읽히게 만드는 것이었습니다. 그 과정에서 시스템 확장의 진짜 어려움이 무엇인지 배웠습니다. 문서가 팀의 언어가 되려면 쓰기 쉽고 찾기 쉬워야 하며, 그 설계 자체가 라이팅 작업이라는 생각이 들었습니다.
사이드 프로젝트에서 온보딩 메시지, 빈 상태 문구, 알림 텍스트를 각자 작성하다 보니 어투가 제각각이었어요. 어떤 건 반말, 어떤 건 존댓말, 어떤 건 명사형 종결이었습니다. 저는 어투 3원칙을 정의하고, 자주 쓰는 패턴을 템플릿으로 공유 시트에 정리했어요. 팀원이 새 문구를 쓸 때 시트에서 유사 패턴을 먼저 찾아보는 흐름이 생겼습니다. 완전한 시스템은 아니었지만 일관성이 눈에 띄게 좋아졌어요. 도전은 처음 패턴이 너무 많아서 찾기 어렵다는 피드백이었고, 5개로 줄이고 나서야 실제로 쓰이기 시작했습니다. 5개로 줄이고 나서야 실제로 쓰이기 시작했습니다.
시스템은 간단할수록 쓰인다는 걸 배웠고, 이후 어떤 라이팅 가이드도 핵심 패턴 5개 이내로 시작하는 습관이 생겼어요.
팀의 디자인 시스템에 UX 라이팅 섹션이 없다는 걸 발견했어요. 개발자가 컴포넌트를 쓸 때 placeholder나 에러 메시지를 직접 쓰게 되는 구조였습니다. 저는 각 컴포넌트별 권장 문구와 작성 원칙을 추가하는 PR을 제안했어요. 처음엔 굳이 필요한가라는 반응이 있었는데, 실제 화면에서 일관성 없는 예시를 보여주니 공감을 얻었습니다. 통합 후 PR 리뷰 때 라이팅 코멘트가 절반으로 줄었어요. 도전은 작성 기준이 없으면 PR마다 주관적 의견이 나온다는 문제였고, 기준을 문서화하니 논의 시간이 줄었습니다. 시스템은 사람을 설득하고 나서야 진짜 동작한다는 걸 배웠어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 UX 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.