기획 변경이 반복되면, 개발자가 사과한다

🔎 유용한 정보

기획이 왔다.
✔ 기능 흐름 정리해옴
✔ 화면 구성도 있음
✔ 일정도 맞춰보자고 함

개발팀은 그대로 개발 시작.
그런데… 이틀 뒤 연락 옴.
“저기요… 기획이 좀 바뀌었어요.”
“저 버튼 위치랑 로직 흐름 조금 수정됐어요~”

“그 정도야 뭐~” 하고 넘어간다.
근데 다음 주 또 바뀐다.
그리고 또.
또.
또.

결국 QA에선 말 나온다.
“이거 왜 이렇게 꼬였어요?”

답변하는 사람: 개발자

✔ 구조 한 번 바뀌면 다 갈아야 하고
✔ 연결된 기능 다 영향 가고
✔ 화면 수정이면 스타일 다시 짜야 함
✔ API 흐름 바뀌면 백엔드도 같이 손 봐야 함

근데 기획은 이런 말 한다.
“그거 살짝만 수정하면 되는 거 아닌가요?”
아니…
이게 어떻게 ‘살짝’이냐고요.

✔ QA 터짐 → “이거 왜 안 되지?”
✔ 운영팀 항의 → “버그인가요?”
✔ 대표 호출 → “이거 요구사항이랑 달라요”

그때 기획자는 말한다.
“그건 제가 예전 버전 기준으로 드렸던 거고요~”
“변경된 건 전달했는데… 반영이 안 됐나 봐요”

결국 누가 사과하냐고요?
“아… 제가 확인을 덜 했네요”
개발자가 사과한다.

처음엔 꼼꼼히 물어봤다.
✔ “이 흐름 확정인가요?”
✔ “예외 상황은 이거까지 맞죠?”
✔ “변경 가능성은 없죠?”

근데 바뀔 때마다 무너짐
✔ 귀찮음
✔ 감정 고갈
✔ ‘어차피 바뀔 거잖아’

결국은 그냥 아무 말도 안 하고 코드 짠다.
그리고 그게 또 터진다.

✔ 바뀌는 건 이해함
✔ 시장도 변하고
✔ 니즈도 바뀌고
✔ 고객 피드백도 있으니까

근데 그로 인해 생긴 리스크와 혼란
그건 누가 감당해야 할까?
왜 항상 개발자가 막아야 되냐고.

변경 자체가 문제는 아니다.
그걸 어떻게 전달하고,
그 영향은 누가 책임지는가.
이게 문제다.

기획 변경의 결과를
개발자한테만 떠넘기는 조직은,
결국 아무도 주도하지 않는 시스템이 된다.

#기획변경지옥 #개발자사과담당 #프로그래머비극
#요구사항자주바뀜 #팩폭블로그 #IT팀현실
#팀워크실종 #기획의책임 #변경은괜찮다책임이문제다
#개발자멘탈관리

🔎 유용한 정보

Code Forest