기능 요청이 실제로는 버그 신고일 때

“내보내기 한도를 늘리는 설정을 추가해줄 수 있나요”는 기능 요청처럼 읽히고, 대부분의 분류 시스템은 그 자리에서 그렇게 라벨을 붙인다. 때로는 정말 그렇다. 때로는 내보내기가 버그 때문에 문서화된 한도보다 낮은 숫자에서 실패하고 있으며, 코드를 볼 수 없는 고객은 설명할 수 있는 가장 그럴듯한 해결책을 지어낸다. 더 큰 숫자를 주면 어쩌면 작동할지도 모른다는 식으로. 어떤 라벨이 가치 있는가는 백로그를 기능 요청과 버그로 나누는 유형 라벨을 다룬다. 이것은 고객 자신의 말이 그 라벨을 엉뚱한 방향으로 향하게 하는 경우이며, 잘못 판단한 대가는 아래를 들여다보면 아무도 정말로 원하지 않는 요청들로 가득 찬 백로그로 서서히 흘러가는 것이다.

실제로는 버그인 기능 요청은 어떤 모습인가

문제 대신 우회 방법을 지목한다. 진짜 기능 요청은 보통 제품이 전혀 지원하지 않는 결과를 설명한다. “이걸 나중으로 예약할 수 있게 해달라”, “다크 모드를 추가해달라” 같은 식이다. 잘못 분류된 버그는 빠진 설정처럼 들리지만 실제로는 증상인 구체적인 숫자, 임계값, 동작을 설명한다. “타임아웃을 늘려달라”, “재시도 옵션을 추가해달라”, “한 번에 더 많은 행을 내보내게 해달라” 같은 식이다. 신호는 요청자가 목표를 설명하는 대신 구현, 설정, 스위치, 오버라이드를 제안한다는 점이다. 이미 문서대로 그 기능을 시도해봤고, 문서가 해야 한다고 말하는 것을 하지 않았기 때문이다.

이것이 왜 보이는 것보다 더 중요한가

두 큐는 다른 담당자, 일정, 성공 기준을 가지며, 기능 요청으로 등록된 버그는 기능 요청들에 대해 우선순위가 매겨져, 버그가 받아야 할 일정에 고쳐지는 대신 진짜 제품 공백과 관심을 두고 경쟁하기 때문이다. 기능 요청을 추적하는 방법은 버그와 기능을 하나의 큐에 섞는 것이 왜 가장 시끄러운 불만이 진짜 요청을 앞지르게 하는지를 다룬다. 몰래 버그인 기능 요청은 반대 방향의 피해를 준다. 근본 버그가 고쳐지는 순간 사라질 “기능”에 대한 표를 모으며 제품 백로그에 계속 머물러, 그 백로그를 읽는 모두에게 우선순위 신호를 낭비하게 만든다.

고객 자신의 말이 엉뚱한 방향을 가리킬 때 어떻게 구별하는가

무엇을 추가해달라고 하는지가 아니라, 무슨 일이 일어날 것으로 기대했는지 물어라. “내보내기가 500행에서 막혔고 2,000행이 필요한데 한도를 올려줄 수 있나요”는 후속 질문 “500이 문서화된 한도인가요”가 문서화된 숫자는 5,000이었고 내보내기가 일찍 실패하고 있다는 것을 밝혀낼 때까지는 한도 상승 기능 요청처럼 들린다. 무엇을 기대했는지 대 무엇이 일어났는지, 그 한 가지 질문만으로 분류 작업의 대부분이 끝난다. 진짜 기능 요청에는 미치지 못하는 문서화된 동작이 애초에 없기 때문이다. 아직 그 능력 자체가 존재하지 않으므로 기대할 것이 없다.

지원 담당자와 엔지니어 중 누가 이것을 결정해야 하는가

지원 담당자가 티켓을 먼저 보므로 첫 번째 검토를 하지만, 라벨은 바꾸기 쉽고 틀려도 비용이 적어야 하며, 그 항목을 영원히 잘못된 큐에 고정시키는 일회성 결정이어서는 안 된다. 매주 새로운 “기능 요청” 라벨을 훑어보며 위장한 버그 냄새가 나는 것을 찾는 엔지니어라는 가벼운 이차 점검은, 코드베이스 맥락이 없는 지원 담당자가 알아볼 수 없었던 것들을 잡아낸다. 이것이 공식적일 필요는 없으며, 검토 프로세스라기보다 5분짜리 훑어보기에 가깝다.

진짜 버그를 찾은 후 순환을 닫는 방식이 바뀌는가

그렇다, 그리고 보낼 수 있는 메시지가 개선된다. 고객 피드백 순환 닫기는 요청이 출시될 때 요청자에게 알리는 것을 다룬다. 재분류된 버그는 그 메시지의 더 나은 버전을 얻는다. “이 뒤에 있는 버그를 찾아서 고쳤습니다”는 유능함처럼 들리는 반면, “요청하신 기능을 만들었습니다”는 오직 우연으로만 사실이었을 것이기 때문이다. 진짜 기능 요청, 즉 실제로 더 높은 내보내기 한도는 버그가 사라지고 원래의 5,000행 한도로 충분해지면 결코 만들어지지 않을 수도 있다.

잘못된 분류가 한 번도 발견되지 않으면 어떻게 되는가

백로그는 진짜 수요처럼 보이지만 그렇지 않은 요청들로 채워지고, 그 백로그에 대해 내려지는 우선순위 결정은 왜곡을 물려받는다. 표 마흔 개짜리 “기능”은 실제로는 같은 버그에 부딪힌 마흔 명일 수 있으며, 문자 그대로의 요청, 즉 실제로는 한 번도 진짜 제약이 아니었던 한도를 올리는 설정을 만드는 것은 아무것도 고치지 못하는 복잡성을 전달하는 동안, 근본 버그는 아직 이 스레드를 찾지 못한 고객들로부터 새로운 “기능 요청”을 계속 만들어낸다.

FAQ

모든 기능 요청을 알려진 버그와 대조하는 공식 단계를 추가할 가치가 있는가? 공식 단계가 아니라 습관에 가깝다. 새 기능 요청을 분류하는 사람은 라벨을 적용하기 전에 “문서화된 동작이 이미 이걸 한다고 주장하는가”를 물어야 한다. 그 한 가지 질문만으로도 프로세스 부담을 늘리지 않고 대부분의 잘못된 분류를 잡아내기 때문이다.

버그를 찾은 후에도 고객이 기능 요청이라고 계속 주장하면 어떻게 하는가? 무엇을 찾았는지, 그리고 버그가 고쳐지면 고객이 제안한 설정이 더 이상 필요하지 않을 이유를 설명하라. 대부분의 고객은 진짜 수정이 불가능하다고 짐작했기 때문에 우회 방법을 요청하는 것이지, 특별히 그 설정을 원해서가 아니다.

재분류된 항목은 기능 요청으로 모은 표나 댓글을 잃는가? 보이게 유지해야 한다. 그 표들은 애초에 버그를 찾게 만든 증거이며, 그 흔적을 숨기면 다음번에 다른 티켓에서 같은 잘못된 분류를 잡아내기 더 어려워지기 때문이다.

이것이 반대로도 일어날 수 있는가, 실제로는 기능 요청인 버그 신고는? 덜 흔하지만 그렇다. “이게 고장 났다”는 때로 “이게 제가 짐작했던 대로 작동하지 않는다”는 뜻이며, 이는 결함이 아니라 빠진 능력이다. 무엇을 기대했는지 대 무엇이 문서화되어 있는지, 같은 질문이 이 방향으로도 분류한다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 도구 비교