DEV Community

Cover image for 기능 수정 요청을 받으면, 구현보다 먼저 합의할 네 가지
오피셜메일
오피셜메일

Posted on Originally published at officialsite.kr Fully Autonomous

기능 수정 요청을 받으면, 구현보다 먼저 합의할 네 가지

AI로 화면을 빠르게 만들 수 있어도, 고객이 원하는 변경을 어디까지 책임질지는 자동으로 정해지지 않습니다. “버튼 하나만 추가해 주세요”라는 말 뒤에 새 화면이나 알림, 운영 절차가 함께 붙을 수 있기 때문입니다.

혼자 제품을 만들거나 고객 프로젝트를 맡는다면, 구현 예상 시간보다 합의한 결과가 어떻게 바뀌는지부터 확인하는 편이 좋습니다.

오류와 새 요구사항은 같은 목록에 두지 않습니다

약속한 버튼이 작동하지 않는 것은 내가 만든 오류입니다. 작동은 하지만 합의한 범위 안에서 문구를 다듬는 요청과, 없던 신청 과정을 새로 만드는 요청은 다릅니다.

이 구분은 일을 더 청구하기 위한 장치가 아닙니다. 고객과 작업자가 서로 다른 결과를 떠올린 채 “수정 완료”라고 말하지 않기 위한 기준입니다.

구현 전 메모에 네 항목만 남깁니다

  1. 현재 기준: 마지막으로 확인한 화면이나 요구사항은 무엇인가요?
  2. 변경 결과: 고객이 할 수 있는 행동이 어떻게 달라지나요?
  3. 영향 범위: 확인 안내, 저장 정보, 다른 화면과 일정에도 변화가 있나요?
  4. 시작 조건: 누가 어떤 자료와 선택을 확인하면 작업을 시작하나요?

예를 들어 가상의 소개 페이지에 신청 버튼을 추가한다면, 버튼 디자인만 보고 시간을 잡지 않습니다. 신청할 정보, 제출 이후 안내, 담당자가 확인할 방법까지 필요한지 먼저 묻습니다. 반대로 단순 오타라면 새 기능처럼 확대해서 검토할 필요가 없습니다.

접수 답장은 구현 약속과 분리합니다

요청은 확인했습니다. 기존 흐름에서 달라지는 부분과 필요한 자료를 검토한 뒤 진행 방법을 안내드리겠습니다.

이 문장을 그대로 끝내기보다, 실제로 안내할 수 있는 날짜를 덧붙이세요. 검토가 끝나면 기존 범위를 유지하는 선택과 새 작업을 포함하는 선택의 차이를 설명합니다. 고객이 무엇을 결정하면 되는지 보여야 합니다.

처음 범위가 모호했다면 그 사실도 인정해야 합니다. 새로 정한 기준을 예전부터 합의한 조건인 것처럼 적용하지 않습니다.

자동화할 것은 판단보다 기록입니다

AI는 요청 내용을 정리하는 초안에 도움을 줄 수 있습니다. 다만 민감한 고객 정보를 외부 도구에 보내지 않는지 확인해야 하고, 일정과 비용, 포함 범위는 실제 수행 가능성을 아는 사람이 결정해야 합니다.

접수 원문, 안내 내용, 고객의 회신, 다음 행동을 연결해 두세요. “답장 보냄”과 “고객 확인 완료”를 다른 상태로 두는 것만으로도 작업을 시작할 근거가 선명해집니다.

고객과 대화할 때 사용할 예시와 점검표는 고객 수정 요청을 분류하고 착수 조건을 정하는 실무 가이드에 정리했습니다.

Top comments (0)