웹서비스 기획자가 회사에서 '버려지는' 이유

매일 느끼는 건 '이 조직에서 나는 필요 없는 사람'이라는 냉혹한 현실입니다. 오늘은 제가 겪고 있는 조직의 문제점들을 정리하면서, 같은 고민을 하는 기획자들에게 '어떻게든 살아남는' 방법을 공유하고자 합니다.

긴급, 긴급, 긴급… 무한루프에 갇힌 조직 지난주에 등록한 개발 요청 3건 중 1건은 이번 주에 취소되었습니다. 이유는 "외부 협력사 일정이 안 맞아서"입니다. 그런데 이미 개발팀은 3일간 작업을 진행했고, QA팀은 테스트 케이스를 작성했습니다. 아무도 그 팀원들의 시간을 되돌려주지 않습니다.

 

우리 조직에서는 "급하게", "내일까지", "다음주 화요일까지"가 일상입니다. 작년 한 해 동안 취소된 개발 건수만 20건이 넘습니다. 선(先)개발 후(後)기획은 기본이고, 개발이 시작된 후에도 요청이 바뀌거나 취소되는 일이 반복됩니다.

 

문제의 핵심: 검토 없는 긴급 요청 모든 요청은 Slack으로 날아옵니다. "급하니까 바로 개발 부탁해요"라는 메시지와 함께. 그런데 이 '급함'의 정당성은 아무도 묻지 않습니다. 실제로 급한 게 맞는지, 대안이 없는지, 서비스가 중단되는지. 그냥 요청자가 급하다고 하면, 그게 곧 법이 됩니다. 결과는 뻔합니다. 개발 리소스 낭비, 팀원들의 사기 저하, 그리고 "왜 이렇게 일은 안 되는 거냐"는 임원진의 질책만 되풀이됩니다.

 

'그거 또 물어보세요?' 반복되는 지옥의 커뮤니케이션 외부 협력사와 시스템 연동 작업을 진행할 때마다 느끼는 점입니다. 제가 기획한 기능을 설명하는 메일을 4번이나 보냈는데, 협력사 담당자는 매번 같은 질문을 되돌려보내요. "아까 답변드린 내용인데요, 혹시 마지막 메일 확인 부탁드립니다"라고 쓰고 싶지만, 그럼 '협업 태도 불량'이 됩니다. 이중, 삼중 커뮤니케이션이 일상입니다. 요청서는 Jira에 올리고, 슬랙으로 다시 보내고, 이메일로 또 전달합니다. 왜 이렇게 하는지 모르겠습니다. "확인했습니다"라는 답장이 와야 비로소 요청이 시작되는 조직이니까요. 로컬 파일 경로가 그대로 노출된 문서를 보낸 적도 있습니다. "C:\Users...\Documents\기획서_최종_진짜최종.hwp" 같은. 협력사 대표가 "우리 시스템에서 이런 경로는 인식이 안 됩니다"라고 답장 올 때마다 얼굴이 화끈거립니다.

 

외부 의존 100%, 그리고 위험 관리 0% 지난달 '외부 협력사 A'의 서비스가 2시간 동안 중단되었습니다. 우리 서비스의 핵심 결제 기능이 그쪽 API에 의존하고 있었기 때문에, 고객센터는 항의 전화로 멘붕이었고, 개발팀은 "협력사에 연락해도 답이 없다"는 말만 반복했습니다. 그런데 이 위험을 사전에 관리하는 프로세스는 전혀 없습니다. 협력사가 서버 주소를 바꾸면 그때서야 "주소 좀 알려주세요"라고 물어보고, 연동이 안 되는 걸 뒤늦게 발견하면 "왜 안 되는 거죠?"라고 합니다. 약정된 SLA는 있지만, 실제 장애 대응은 우리가 더 초조해하는 구조입니다.

 

메뉴는 늘어만 가는 중복 개발의 지옥 관리자 페이지에 '상세 보기' 메뉴가 3개 있습니다. 통합 플랫폼 관리에서 보는 상세, 지역별 운영에서 보는 상세, 그리고 특정 이벤트 관리에서 보는 상세. 기능은 거의 같습니다. 개발자분이 "이거 중복 아니냐"고 물어보면, 제 대답은 "그냥 두세요. 나중에 정리할게요"입니다. 나중은 오지 않습니다. 새로운 요청이 들어오면 그냥 또 만들고, 1년 뒤엔 "이 메뉴는 왜 있는 거죠?"라는 질문만 남습니다.

 

기획자로서 내가 할 수 있는 '작은 저항' 이런 조직에서 3년을 버티면서 깨달은 게 있습니다. 시스템을 바꾸는 건 불가능하지만, '내가 죽지 않는' 방법은 존재합니다.

 

1. 긴급 요청, 정말 긴급한지 '3번 물어보기' "급하시다고 하셨는데, 혹시 대안이 있으신가요?" "서비스 중단이 발생하나요? 아니면 단순히 빠르게 보고 싶으신 건가요?" "개발 중 취소될 가능성은 없을까요?" 이 3가지 질문을 포함해서 요청서를 올립니다. 처음엔 "괜히 까다롭다"는 눈초리를 받았지만, 2개월이 지나자 "계획 기획자는 확실하네요"라는 말을 듣기 시작했습니다. 오히려 저를 신뢰하는 사람들이 늘었습니다.
2. 반복되는 질문, 템플릿으로 만들어 두기 외부 협력사에게 보내는 API 문의 메일은 5가지 템플릿으로 정리했습니다. "인증 토큰 요청", "엔드포인트 확인", "에러 코드 문의", "서버 주소 변경", "긴급 장애 공유". 답변도 FAQ 형식으로 정리해서 팀 공유 폴더에 넣어뒀습니다. 이제는 메일 쓰는 시간이 절반으로 줄었습니다.
3. 중복 개발 방지 '용어집' 만들기 "상세 보기"라는 용어가 3개 메뉴에서 쓰이니, 구분되는 네이밍을 직접 정의했습니다. "통합대시보드 상세", "지역운영 상세", "이벤트관리 상세"처럼요. 개발자들이 "이거 중복 아니냐"고 물어보면, 이 용어집을 보여주며 "기획 의도가 다릅니다"라고 답합니다. 적어도 개발 전에 논의가 시작되니, 중복을 줄일 수 있습니다.
4. 협력사 위험, 직접 모니터링하기 매일 아침 10분, 협력사들의 서비스 상태 페이지를 체크합니다. 장애가 없는지, 예정된 점검이 있는지. 그리고 슬랙에 "오늘 A사 점검 있으니 결제 모니터링 부탁드립니다"라고 자동으로 메시지를 남깁니다. 아직까지는 제가 하는 일이지만, 한 달 후엔 이슈 트래커에 자동화할 계획입니다.