
웹서비스 기획 현장에서 가장 위험한 신호는 무엇일까요? 기술적 난제? 부족한 예산? 아닙니다. 진짜 위기는 조직 내에 '책임 없는 중재자'와 '권한 없는 집행자'가 만났을 때 시작됩니다.
분명 다들 열심히 일하는 것 같은데, 왜 사소한 API 연동 하나가 6개월씩 지연되고 파트너사의 신뢰는 바닥을 치는 걸까요? 오늘은 우리 주변(혹은 우리 자신)에 숨어있는 두 가지 독성 업무 패턴을 분석하고, 이를 타파하기 위한 솔루션을 제시합니다.
1. ‘죄송합니다’라는 무책임한 방패 (The Sorry-Looper)
첫 번째 유형은 성실해 보이지만 실질적인 진전이 없는 '사과 반복형'입니다.
패턴: FTP 전송 실패, 컨텐츠 ID 누락, 테스트 오류가 발생할 때마다 "본의 아니게 죄송합니다", "불편을 드려 죄송합니다"라며 고개를 숙입니다.
문제의 본질: 사과는 신속하지만, '왜 같은 실수가 반복되는가'에 대한 프로세스 개선이 없습니다. "개발실에 확인하겠다"는 말은 기획자로서의 직무 유기입니다. 스스로 기술적 명세를 파악하지 않고 중계만 하다 보니, 단순 등록 누락으로 프로젝트가 4개월 이상 표류하게 됩니다.
부작용: "수동 작업이 번거로우니 권하지 않는다"거나 "조언 부탁드린다"는 식의 화법으로 결정의 책임을 타인에게 떠넘깁니다. 결국 복잡성을 해결하지 못하고 설명만 늘어놓다 프로젝트를 미궁으로 빠뜨립니다.
2. ‘경영진 지시’라는 무소불위의 칼날 (The Management-Shield)
두 번째 유형은 자신의 논리가 아닌 타인의 권위에 기대어 업무를 밀어붙이는 '권위 의존형'입니다.
패턴: 정책 변경 요청에 "경영진 지시사항이라 변경 불가"라는 말을 전면에 내세웁니다. 거의 모든 메일에 "확인 부탁드립니다"를 남발하며 공을 상대방에게 던집니다.
문제의 본질: 당장 해결하기 어려운 이슈는 "내년도부터"라는 마법의 단어로 무한히 연기합니다. 그러면서도 "설정만 하면 바로 적용된다"는 지나친 기술 낙관론을 펼쳐 개발팀과 파트너사를 압박합니다.
부작용: 비용 압박과 강압적 협상을 통해 단기적인 이익은 챙길지 모르나, 논리적 근거(And/Or 조건조차 혼동하는 등)가 부족하여 조직 전체의 의사결정 수준을 하락시킵니다.
3. 최악의 시너지: 책임 공백과 관료주의의 탄생
이 두 유형이 한 프로젝트에서 만나면 조직은 '무주공산(無主空山)' 상태가 됩니다.
악순환의 고리: 문제가 터지면 한쪽은 사과하며 개발팀에 책임을 돌리고, 다른 한쪽은 경영진의 뜻이라며 요지부동입니다. 파트너사는 "확인 중"이라는 답변만 6개월째 듣게 됩니다.
신뢰의 붕괴: 외부 협력사는 더 이상 이 조직의 일정을 믿지 않습니다. "아직도 개발 중인가요?"라는 질문은 이 조직의 무능을 증명하는 뼈아픈 수식어가 됩니다.
혁신의 사멸: 기술적 개선이나 근본적 해결책보다는 '기안 상신'과 '사과문 작성'에 더 많은 에너지를 씁니다. 혁신은 사라지고 관료주의만 남습니다.
[Solution] 메신저가 아닌 ‘오너’가 되는 법
이 늪에서 탈출하기 위해 기획자는 다음 세 가지를 반드시 실천해야 합니다.
첫째, 사과 대신 '재발 방지 대책'을 기획하십시오. 실수는 누구나 합니다. 하지만 기획자라면 "죄송합니다" 뒤에 "이런 실수가 반복되지 않도록 API 등록 프로세스를 이렇게 자동화/체크리스트화 했습니다"라는 답변이 따라와야 합니다.
둘째, '왜(Why)'를 설명하십시오. 경영진의 지시라도 그 배경에 깔린 비즈니스 로직을 이해하고 설득해야 합니다. "지시사항이라 안 된다"가 아니라 "현재 비즈니스 우선순위와 비용 구조상 A안이 최선입니다"라고 말할 수 있어야 합니다.
셋째, 의사결정의 마침표를 찍으십시오. "확인 부탁"으로 메일을 끝내지 마세요. "X일까지 피드백이 없으시면 제안드린 B안으로 확정하여 배포하겠습니다"라고 주도권을 쥐어야 합니다.
기획자는 정보를 전달하는 통로(Pipe)가 아니라, 정보를 정제하고 가치를 만드는 필터(Filter)가 되어야 합니다. 당신의 메일함에 "확인 부탁"과 "죄송합니다"만 가득하다면, 지금 당장 업무 패턴을 재설계해야 할 때입니다.
'지푸라기 > 웹서비스기획자의 일상' 카테고리의 다른 글
| 공급망의 채찍효과, 그리고 기획 부채의 복리 (0) | 2026.01.03 |
|---|---|
| 같은 부대와 타 부대, 그리고 SQL 인젝션 (0) | 2026.01.02 |
| 개발자의 도메인 지식, 그리고 기획자의 브릿지 ROI (0) | 2025.12.31 |
| 세 개의 서버, 그리고 파편화된 스토리보드의 대가 (0) | 2025.12.29 |
| 웹서비스 기획자가 회사에서 '버려지는' 이유 (0) | 2025.12.28 |
댓글