[PM] 고객 요청 다루기 — 오류인가 개선인가 추가개발인가

고객은 자기 요청이 어떤 종류인지 모릅니다. 알 필요도 없습니다 — 그건 PM의 일입니다. 고객 입장에서는 전부 "이거 안 돼요" 또는 "이거 해주세요" 한마디지만, 처리하는 사람 입장에서는 대응 속도도, 담당 부서도, 비용 발생 여부도 완전히 다릅니다. 그래서 요청이 들어오면 가장 먼저 하는 일이 "이게 어느 유형인가"를 가르는 것입니다.

이 표의 진짜 쓸모는 속도와 비용을 가르는 데 있습니다. 장애는 지금 당장, 개선은 우선순위를 매겨서, 추가개발은 돈과 계약 이야기부터. 운영 문의와 설정 변경은 개발자에게 갈 것도 없이 당신 선에서 끝납니다. 신입이 이 구분을 못 하면, 5분이면 끝날 설정 문의도, 돈 받아야 할 추가개발도, 지금 뛰어야 할 장애도 전부 똑같이 "개발팀 확인 요청 드립니다"라는 한 줄로 뭉개집니다. 분류는 PM이 요청에 얹는 첫 번째 가치입니다.

특히 헷갈리는 짝이 **장애와 오류(버그)**입니다. 둘 다 겉으로는 "안 돼요"로 들리지만 대응이 다릅니다. 장애는 '지금 업무가 멈췄는가'가 기준입니다 — 원인이 버그든 서버 다운이든 연동 장애든, 다수가 못 쓰고 있으면 일단 장애로 다뤄 지금 뛰어야 합니다. 오류(버그)는 '원래 스펙과 다른가'가 기준입니다 — 한 명이 특정 조건에서만 겪고 업무가 멈추진 않았다면, 급히 뛰기보다 재현해서 패치를 검토합니다. 그래서 같은 "결제가 안 돼요"도 '전 직원 결제 중단'이면 장애, '내 특정 카드만 실패'면 개별 오류로 갈립니다 — 범위와 영향도가 둘을 가르는 잣대입니다.

일곱 유형 중에서도 신입이 가장 자주 헷갈리고, 가장 크게 손해 보는 경계가 버그 · 개선 · 추가개발입니다. 이 셋을 가르는 기준은 딱 하나 — **"원래 어떻게 하기로 되어 있었는가"**입니다.

문제는 고객이 늘 **"이거 버그 아니에요?"**라는 프레임으로 말한다는 것입니다. 고객에게는 자기 기대와 다르게 동작하는 모든 것이 '버그'로 보이기 때문입니다. 여기서 신입이 "네 버그 같네요, 고쳐드릴게요"라고 받으면, 실제로는 개선이나 추가개발이었던 것을 무상 하자로 자백하는 셈이 됩니다.

예시로 감을 잡아봅시다. 시나리오의 첫 문장 — "조직도에서 예전에 없앤 부서가 계속 보여요. 버그 아니에요?" 이걸 바로 "버그"라고 받으면 안 됩니다. 확인해야 할 포인트는 이렇습니다.

• 기존 요구사항에 있었나 — '폐지된 부서는 조직도에서 숨긴다'가 애초 스펙에 정의돼 있었나? 있었으면 버그, 없었으면 개선·추가개발.
• 제품의 기본 스펙인가 — 이 제품이 원래 '미사용 부서 자동 숨김'을 기본으로 제공하나, 아니면 노출이 기본인가?
• 이 고객사만의 기준인가 — '미사용'을 판단하는 규칙(예: 인원 0명, 폐지일 경과)이 이 고객사만의 정책이면, 제품 표준 동작이 아니라 설정·정책 문제일 수 있다.
• 미사용 판단 기준이 명확한가 — 무엇을 기준으로 '미사용'이라 하는지가 정의돼 있지 않으면, 애초에 고칠 대상 자체가 모호하다.
• 운영 데이터에 어떤 영향이 있나 — 숨김 처리가 과거 인사이력·권한·통계에 영향을 주진 않는가? 함부로 숨겼다가 정상 부서까지 사라지면 2차 사고.

이 다섯 개를 확인하기 전까지 당신이 할 수 있는 정직한 답은 "현상 확인 후 원인 구분이 필요합니다" 하나뿐입니다. 확인 결과에 따라 같은 요청이 무상 하자가 될 수도, 유상 견적이 될 수도 있습니다.

두 번째 예시로 추가개발 판정도 연습해 봅시다. 시나리오의 "직원 등록할 때 사번을 자동으로 넣어주면 안 될까요? 간단한 거잖아요." — 여기서 "간단한 거잖아요"라는 말에 넘어가 "네 해드릴게요"라고 하면 안 됩니다. 확인 포인트는 이렇습니다. 원래 사번을 자동 채번하기로 계약·스펙에 있었나(있었으면 미구현이니 버그에 가깝고, 없었으면 새 동작), 기존 사번 체계와 충돌하지 않나(이미 수기로 부여한 사번, 지점별 규칙, 퇴사자 사번 재사용 여부), 자동 채번 규칙이 정의돼 있나(연도+순번? 부서코드+순번?). 화면상으로는 '빈칸에 숫자 하나 넣기'처럼 보여도, 그 뒤에는 채번 규칙·중복 방지·기존 데이터 정합성이 얽혀 있습니다. 계약·범위에 없던 새 동작이면 이건 추가개발이고, PM 단독으로 확약할 게 아니라 영업·계약 라인과 함께 검토할 일입니다. 겉보기 난이도로 유형을 판정하지 않는 것 — 이것이 신입이 가장 먼저 익혀야 할 절제입니다.

고객은 개발자가 아니므로, 자기가 겪은 일을 자기 언어로 말합니다. 그 언어는 원인 진단이 아니라 체감한 증상입니다. 신입 PM의 일은 그 표현을 곧이곧대로 받아 적는 게 아니라, 그 뒤에 있는 실제 가능성들로 번역하는 것입니다.

번역할 때 스스로에게 던지는 세 가지 질문을 습관으로 만드세요.

• 이건 원인인가 증상인가 — 고객이 말한 것이 "안 됨"(증상)인지 "서버가 죽었다"(원인 추정)인지. 원인 추정은 검증 전까지 믿지 않는다.
• 범위가 얼마인가 — 나 혼자인가, 우리 팀인가, 전 직원인가. 범위가 곧 장애/개별 이슈를 가른다.
• 업무가 멈췄는가 — 불편한 것과 못 하는 것은 다르다. 멈췄으면 속도를, 불편하면 우선순위를 매긴다.

핵심 원칙: 고객의 초반 표현에는 항상 "현상 확인 후 원인 구분이 필요합니다"로 응답합니다. "오류나요"를 듣고 "서버 오류네요"라고 받으면, 알고 보니 권한 문제였을 때 당신의 신뢰가 깎입니다. 반대로 "확인해 보니 서버가 아니라 접근 권한 문제였고, 권한을 부여하니 해결됐습니다"라고 마무리하면, 같은 요청도 PM이 원인을 짚어낸 일이 됩니다. 증상을 진단으로 착각하지 않는 것이 번역의 시작입니다.

신입이 가장 쉽게, 가장 크게 사고 치는 지점이 성급한 확답입니다. 고객 앞에서 "가능할 것 같은데요", "금방 됩니다", "간단한 수정이니 패치할게요"라고 말하는 순간, 그건 위로가 아니라 약속이 됩니다. 개발팀에 물어보니 3일짜리 작업이었거나, 알고 보니 계약 밖 추가개발이었어도, 고객은 이미 "PM이 된다고 했다"를 근거로 잡습니다.

안전한 표현의 공통점은 세 가지입니다 — ① 지금 확답하지 않는다, ② 무엇을 확인할지 밝힌다, ③ 언제 회신할지 약속한다. 이건 발뺌이 아니라 정확성에 대한 책임입니다. 고객이 진짜 원하는 것은 "네"라는 즉답이 아니라 틀리지 않는 답입니다. "확인 후 오늘 오후까지 회신드리겠습니다"가 "가능할 것 같아요"보다 훨씬 신뢰를 줍니다. 확답은 확인 다음에 옵니다.

고객 메시지를 개발팀 채팅방에 복사·붙여넣기 하는 순간, 당신은 PM이 아니라 전달 케이블이 됩니다. 개발자는 그 한 줄로는 일을 시작할 수 없어 되묻고, 그 질문이 다시 고객에게 가고, 반나절이 왕복으로 증발합니다. PM의 일은 요청을 개발자가 곧바로 판단·착수할 수 있는 형태로 정리하는 것입니다.

나쁜 예 (그대로 전달):

[개발팀 채팅방]
고객이 조직도 미사용 부서 안 보이게 해달래요. 이거 처리 가능한가요?

이 한 줄에는 어느 환경인지, 누구 계정인지, 원래 스펙에 있던 건지, '미사용' 기준이 뭔지가 전부 빠져 있습니다. 개발자는 "미사용이 뭘 기준으로요?", "운영기예요 검수기예요?", "원래 숨기게 돼 있었어요?"를 되물을 수밖에 없습니다.

좋은 예 (구조화해서 전달):

[조직도 - 미사용 부서 노출 관련 확인 요청]

- 고객 요청: 폐지된 부서가 조직도에 계속 노출됨. 숨김 처리 원함
- 현재 동작: 조직도에 모든 부서(폐지 포함) 노출 중 (운영기, 관리자 계정 기준)
- 고객 기대: 폐지(미사용) 부서는 조직도에서 자동 제외
- 확인 필요: 원 요구사항에 '폐지 부서 숨김'이 정의돼 있었는지 (스펙 확인)
- 구분 필요: 스펙에 있으면 버그(무상), 없으면 개선/추가개발 — '미사용' 판단 기준 정의 필요

같은 요청인데도, 개발자는 좋은 예를 받으면 되물을 것 없이 "스펙 문서 3.2에 있네요, 버그 맞습니다" 또는 "스펙에 없어서 개선 건입니다"로 바로 답할 수 있습니다. 정리의 뼈대는 고객 요청 / 현재 동작 / 고객 기대 / 확인 필요 / 구분 필요 다섯 칸입니다. 이 다섯 칸을 채우는 동안 당신 스스로도 "아, 이건 스펙부터 봐야겠네"를 깨닫게 됩니다. PM의 가치는 질문을 늘리는 데 있지 않고, 질문을 줄이는 정리력에 있습니다.

요청을 유형으로 갈랐어도, 정작 개발자에게 넘길 때 세 가지를 빼먹으면 그 요청은 반드시 되돌아옵니다. 신입이 가장 자주 빠뜨리는 축입니다.

① 환경 구분 — "어디서 그런 건가요"

같은 증상도 어느 환경이냐에 따라 원인이 완전히 다릅니다. 개발기에서만 나는 오류를 운영기 장애로 착각해 밤새 뛰는 일이 실제로 벌어집니다.

② 재현 여부 — "다시 해도 그런가요"

개발자가 고칠 수 있는 유일한 조건은 재현되는 것입니다. 재현되지 않는 버그는 유령과 같아서 손댈 수가 없습니다.

③ 완료 기준 — "무엇을 보면 해결된 건가요"

의외로 가장 많이 빠뜨리는 것이 이것입니다. "고쳐주세요"만 받고 착수하면, 다 고친 뒤에 "이게 아닌데요"가 나옵니다. 착수 전에 무엇을 기준으로 완료로 볼지를 고객과 합의해야 합니다.

• 정렬 요청이라면 → 무슨 컬럼을 기준으로 정렬하는 게 맞는가(이름? 등록일? 사번?)
• 데이터 보정이라면 → 샘플 3건을 고객이 직접 확인해 맞다고 하면 완료로 본다
• 운영 반영이라면 → 운영에 반영한 뒤 현업이 검수해 확인서를 받으면 완료

완료 기준이 없으면 그 요청은 끝나지 않습니다 — 고칠 때마다 새로운 기대가 붙기 때문입니다. "무엇을 보면 해결된 것으로 볼까요?"라는 질문 하나가 무한 반복 작업을 막습니다.

고객에게 자료를 요청할 때, 신입은 흔히 "캡처 주세요", **"로그 주세요"**처럼 짧게 말합니다. 그러면 고객은 엉뚱한 화면을 캡처해 보내고, 다시 요청하고, 왕복만 늘어납니다. 요청에는 왜 그게 필요한지를 붙여야 합니다. 이유를 알면 고객이 스스로 정확한 자료를 골라 줍니다.

마지막 행이 특히 중요합니다. 상태코드(HTTP status code) 하나가 원인 범위를 크게 좁힙니다 — 403이면 권한, 404면 주소·배포, 500이면 서버 앱, 502나 504면 게이트웨이·타임아웃입니다(다음 절에서 정리합니다). 이유를 붙인 요청은 고객을 귀찮게 하는 게 아니라, 고객과 개발자 사이의 왕복 횟수를 줄이는 가장 효율적인 도구입니다.

PM은 코드를 짜지 않습니다. 하지만 고객의 증상을 듣고 **"이건 대략 어느 영역 문제겠다"**를 짐작할 수 있으면, 요청을 훨씬 정확히 번역하고 개발자와 같은 언어로 대화할 수 있습니다. 그 출발점이 웹 서비스가 요청을 처리하는 기본 흐름입니다.

[웹 서비스 요청 흐름]

브라우저 / 앱
   │  (사용자가 버튼 클릭)
   ▼
DNS  ──► 도메인 이름을 서버 주소로 변환
   ▼
방화벽 / WAF / 프록시  ──► 접근 차단·보안 필터
   ▼
로드밸런서(LB)  ──► 여러 서버로 요청 분배
   ▼
Web / WAS(애플리케이션 서버)  ──► 실제 로직 처리
   ▼
DB / 외부 API / 스토리지  ──► 데이터 조회·저장·파일
   ▼
응답이 위 경로를 거꾸로 돌아 화면에 표시

이 흐름을 알면, 증상을 듣고 어느 층을 의심할지가 보입니다. 아래 표는 신입 PM이 외워두면 좋은 '증상 → 의심 영역' 대응입니다. 정확한 진단은 개발자가 하지만, 이 표만 있어도 요청을 넘길 때 "이건 권한 쪽일 수 있어요"처럼 방향을 얹을 수 있습니다.

환경(운영기 · 개발기 · 검수기) 개념도 반드시 알아야 합니다. 하나의 서비스는 보통 여러 벌로 존재합니다.

• 운영기(Production) — 실제 고객이 쓰는 진짜 서비스. 여기서 나는 문제는 곧 장애.
• 개발기(Development) — 개발자가 만들고 실험하는 곳. 깨져 있어도 정상.
• 검수기(Staging) — 운영에 반영하기 전 고객·현업이 확인하는 곳. 운영과 거의 같게 맞춰둔 환경.

"오류나요"를 받으면 **가장 먼저 물어야 할 것이 "어느 환경인가요"**인 이유가 여기 있습니다. 검수기 오류를 운영 장애로 착각하면 헛심을 쓰고, 운영 장애를 검수기 문제로 넘기면 고객이 멈춥니다.

마지막으로, 개발자·운영자와 대화할 때 자주 나오는 기본 용어만 익혀두면 회의에서 길을 잃지 않습니다.

이 절의 목표는 당신을 개발자로 만드는 게 아닙니다. 증상을 듣고 대략의 방향을 얹을 수 있는 것, 그래서 요청을 더 정확히 번역하고 개발자의 설명을 알아듣는 것 — 그거면 신입 PM으로서 충분합니다.

개발팀에 이슈를 넘겼을 때 가장 자주 돌아오는 답이 **"저는 재현이 안 되는데요"**입니다. 신입 PM은 이때 "개발자가 성의가 없나?" 하고 오해하기 쉽지만, 사실은 다릅니다 — 재현되지 않는 문제는 고칠 수단 자체가 없습니다.

개발자가 버그를 고치는 방식은 이렇습니다: 문제를 자기 환경에서 똑같이 재현시키고 → 코드를 한 줄씩 따라가며 어디서 어긋나는지 관찰하고 → 고친 뒤 다시 재현시켜 안 나는지 확인합니다. 이 세 단계 전부가 '재현'을 전제로 합니다. 재현이 안 되면 개발자는 눈을 감고 허공을 더듬는 셈이 됩니다. 그래서 "안 잡힌다"는 무능이 아니라 정보 부족의 신호입니다.

여기서 PM이 결정적 역할을 합니다 — 재현 조건을 좁혀 주는 것입니다. 고객과 개발자 사이에서, 어떤 조건이 갖춰지면 문제가 나타나는지를 함께 특정합니다.

• 무엇이 다른가를 대조한다: 되는 계정과 안 되는 계정의 차이(권한·소속·데이터), 되는 문서와 안 되는 문서의 차이(크기·형식·상태값), 되는 시간과 안 되는 시간의 차이(마감 시간대·배치 실행 시각).
• 경계를 조인다: "전부 안 됨"인지 "이 조건에서만 안 됨"인지. 특정 브라우저에서만? 특정 데이터 건수 이상에서만? 특정 권한에서만? 조건이 좁혀질수록 원인 후보가 줄어듭니다.
• 타이밍·순서를 기록한다: "A를 하고 바로 B를 하면 난다"처럼 동작 순서가 조건인 경우가 많습니다. 고객이 무심코 지나친 직전 행동이 열쇠입니다.
• 환경·시점을 고정한다: 언제(정확한 시각), 어디서(환경·기기), 무엇을 한 직후인지. 로그를 대조하려면 정확한 발생 시각이 결정적입니다.

정리하면, 재현은 개발자의 일이지만 재현 조건을 좁히는 것은 PM의 일입니다. "안 된대요"를 "○○ 권한 계정으로, 운영기에서, 1만 건 이상 문서를 열 때, 3초 뒤에 504가 난다"로 좁혀 주는 순간, 개발자는 비로소 손을 댈 수 있습니다. 좋은 PM은 개발자에게 문제를 던지는 사람이 아니라, 개발자가 재현할 수 있는 조건을 함께 만들어 주는 사람입니다.