문제를 고쳤는데 왜 다른 곳이 망가질까요

문제를 고쳤는데 왜 다른 곳이 망가질까요

IT & AI 뉴스 썸네일

한 팀의 지표가 좋아졌는데 고객 문의는 늘고, 자동화를 도입했는데 운영 부담은 더 커질 때가 있어요. 문제를 없앤 줄 알았지만 실제로는 다른 부서로 옮겼거나, 기존 문제를 유지할 유인이 남았거나, 해결책이 새 골칫거리를 만든 경우예요. 조직 개선을 맡는 개발자와 제품 팀이 자주 마주치는 세 가지 패턴을 짚어봐요. 1

핵심 요약

구분	어떤 일이 생기나요	무엇을 확인해야 하나요
문제 이동	한 팀의 비용이나 업무가 다른 팀으로 넘어가요	전체 처리 시간과 부서 간 비용을 함께 봐요
문제 보존	문제로 예산·역할·권한을 얻는 구조가 남아요	문제가 사라질 때 손해 보는 주체를 찾아요
새 문제 승격	해결 뒤 차순위 문제가 가장 큰 병목이 돼요	도입 전 부작용과 후속 운영 비용을 적어요

1. 조직은 문제를 풀면서도 문제를 옮기거나 남겨요

원문 저자 브라이언 커는 문제 해결 외에 세 가지 반응이 반복된다고 설명해요. 문제를 다른 곳으로 밀어내고, 문제에 의존하는 구조를 보존하고, 해결 과정에서 새 문제를 앞자리로 올리는 방식이에요. 셋 다 무조건 나쁜 선택은 아니에요. 다만 팀이 무엇을 선택했는지 모르면 개선 결과를 잘못 평가하기 쉬워요. 2

한 팀의 성공이 전체 시스템의 손해가 될 수 있어요

가장 흔한 사례는 국소 최적화예요. 개발팀이 배포 횟수를 늘리려고 검수 절차를 줄이면 개발 속도는 빨라질 수 있어요. 대신 장애 대응과 고객 지원 업무가 늘 수 있어요. 인프라팀이 비용을 낮추려고 로그 보관 기간을 줄이면 월별 청구액은 줄지만, 장애 원인을 찾는 시간은 길어질 수 있어요.

728x90

이때 개발팀을 탓하는 것만으로는 반복을 막기 어려워요. 각 팀은 자신에게 주어진 목표와 평가 기준에 맞춰 움직이기 때문이에요. 배포 속도만 평가하면서 장애 비용은 다른 부서 예산으로 처리한다면 같은 결정이 다시 나와요. 팀별 지표와 함께 고객 대기 시간, 재작업량, 장애 복구 시간처럼 조직 전체의 결과를 봐야 해요.

해결 책임을 맡은 조직이 문제에 의존하기도 해요

문제를 담당하는 팀은 시간이 지나면서 그 문제를 중심으로 예산, 인력, 전문성을 쌓아요. 문제를 완전히 없애면 팀의 역할이 줄어들 수 있다는 불안도 생겨요. 누군가 일부러 문제를 키운다고 단정할 수는 없어요. 기존 업무를 계속 처리하는 편이 근본 원인을 없애는 것보다 안전하게 평가받는 구조라면, 표면적인 대응이 반복돼요.

변경 전에 이해관계자를 그려보면 이런 저항을 일찍 찾을 수 있어요. 문제가 사라질 때 예산이 줄어드는 팀, 승인 권한을 잃는 관리자, 새 도구를 배워야 하는 운영자를 적어보세요. 반대 의견을 설득의 장애물로만 보면 중요한 비용을 놓쳐요. 역할 전환과 평가 기준 변경까지 계획에 넣어야 실제 개선으로 이어져요.

해결책은 다음 병목과 운영 부담을 만들어요

가장 큰 문제를 없애면 두 번째 문제가 눈에 띄기 시작해요. 자동 배포를 도입한 뒤 배포 대기 시간은 줄었지만, 테스트가 병목이 될 수 있어요. 고객 문의를 챗봇으로 분류한 뒤 상담원은 단순 문의 대신 복잡한 사례만 맡게 돼요. 처리 건수는 줄어도 건당 난도와 피로도는 오를 수 있어요.

새 문제가 생겼다고 앞선 해결이 실패한 것은 아니에요. 도입 전 예상한 부작용인지, 감수할 만한 비용인지, 별도 대응이 필요한 새 병목인지 구분하면 돼요. 기능 출시 문서에 기대 효과만 쓰지 말고 운영 주체, 되돌리는 조건, 새로 생길 수 있는 업무를 함께 적으면 판단이 쉬워져요.

왜 중요한가요

개발과 제품 조직은 빠른 실행을 강조할수록 측정하기 쉬운 팀별 숫자에 끌리기 쉬워요. 하지만 비용이 다른 팀으로 넘어가면 대시보드에는 성공으로 남고, 조직 전체의 처리 시간은 오히려 길어질 수 있어요. 개선안을 검토할 때는 해결 전후의 전체 흐름과 이해관계자를 한 장에 그려보는 편이 좋아요. 원문도 좋은 다이어그램으로 문제를 함께 보고, 고칠 가치가 있는 일부를 고르는 방법을 제안해요. 2

실무에서는 세 가지 질문으로 시작할 수 있어요. 이 변경으로 일이 늘어나는 팀은 어디인지, 문제가 사라지면 역할이나 예산을 잃는 주체가 누구인지, 해결 뒤 가장 먼저 드러날 다음 병목이 무엇인지 확인해 보세요. 답이 불편하더라도 출시 전에 드러나는 편이 훨씬 싸요. 모든 문제를 한 번에 끝내려 하기보다, 조직 전체의 비용을 실제로 줄이는 문제부터 고르는 기준이 필요해요.

참고 자료

1. 문제를 해결하지 않고 대응하는 세 가지 방식 — GeekNews
2. Three ways people respond to a problem (other than solving it) — Improve Something Today
3. Hacker News discussion — Hacker News