유저는 반드시 기대한 행동을 하지 않는다 2 – CS 유입이 말해준 유저의 기대 기능

문제 제기

시스템은 정상적으로 작동하고 있었다.
지원자는 자소서만 첨부해도 ‘지원 완료’가 되었고, 개발과 QA는 기획서에 명시된 흐름대로 동작을 확인했다.
하지만 문제는 그 ‘정상’이라는 기준이 시스템의 시선에만 머물러 있었다는 점이었다.

결과적으로 유저는 자기가 이력서를 제출했다고 믿었고,
기업은 서류가 누락된 걸 뒤늦게 확인했으며,
그 누구도 이 상황을 사전에 인지하거나 해결할 수 있는 구조는 없었다.

👉 이전 글에서도 다뤘던 내용입니다.

[유저는 반드시 기대한 행동을 하지 않는다 – 지원 완료의 맹점]

사례 요약

실제로 있었던 사례다.
기업 회원이 이력서 없이 자소서만 제출된 지원서를 확인한 뒤,
이력서 누락을 지적하며 물어왔다.

“지원자에게 서류 보완 요청을 할 수 있는 기능이 있나요?”

하지만 현재 시스템에서는
지원 이후 지원자에게 개별적으로 연락하거나 보완을 요청할 수 있는 기능은 존재하지 않는다.
플랫폼 상에서는 지원이 완료되면 일방향 흐름으로 간주되기 때문이다.

문제의 본질

이 사례는 단순한 누락이 아니라,
유저가 원했던 기능이 무엇인지가 명확히 드러난 순간이었다.

보통 지원자는 이력서 파일 안에 자기소개서를 함께 작성해 제출하기 때문에,
‘자소서만 제출된 상태’는 기획 단계에서 예외로 분류되었고,
별도 로직을 추가할 필요는 없다고 판단되었다.
예컨대 첨부된 파일의 형식을 자동으로 구분하거나, 내용 유무를 판단하는 로직은
기술 구현 난이도가 높고 예외도 많다.

하지만 기업 회원의 문의는 단순한 확인이 아니었다.
실제로 지원자와 연결되어, 보완을 요청하고 싶어 했다.
즉, 유저는 처음부터 ‘지원자와의 소통 기능’이 있을 거라 기대한 것이다.

인사이트

이 문의는 단순한 불편 신고가 아니었다.
‘CS가 먼저 발견한 다음 기획의 방향’이었다.

만약 기업이 지원자에게 서류 보완을 요청할 수 있었다면,

기업은 CS를 거치지 않고 문제를 바로 해결할 수 있었고
지원자는 개별 연락 없이도 명확한 안내를 받을 수 있었을 것이다
결과적으로 문의 유입 자체가 줄고, 실패한 지원 케이스도 줄었을지 모른다

기획서에는 없었지만,
유저는 이미 그 기능을 필요로 하고 있었다.

마무리

기능은 시스템에서 태어나지만,
유저의 행동을 통해 자라난다.

CS는 단순한 사후 대응이 아니라,
기획이 놓친 흐름을 먼저 보여주는 통로일 수 있다.

이번 사례를 통해 분명히 알 수 있었다.
유저가 진짜 원했던 건, ‘지원자와 소통할 수 있는 기능’이었다.
그 기능은 없었지만, 유저는 이미 그걸 기대하고 있었고,
우리는 그 기대를 통해 다음 기능의 방향을 포착할 수 있었다.