개발자에서 기획자로: 완벽을 버리고 실행을 설계하다

개발자에서 기획자로: 완벽을 버리고 실행을 설계하다

개발자는 정답을 찾지만,
기획자는 불확실한 상황에서 방향을 제시합니다.
그리고 그 방향은 제품을 조금씩 앞으로 나아가게 만듭니다.

---

개발자 사고방식, 기획에서 처음 부딪히다

처음 제품 기획자가 되었을 때, 저도 매 순간 당황했습니다.

개발자 시절엔 명확한 명세서와 결과가 있었죠.
"이 기능은 이렇게 동작해야 한다"라는 식으로요.
하지만 기획은 그렇지 않았습니다.

요구사항은 명확하지 않았고,
조직마다 이해관계가 달랐고,
상황은 하루가 다르게 변했습니다.

특히 B2B·B2G 제품 기획은 기술적 완성도만으로는 해결할 수 없었습니다.
정답보다 합의,
기능보다 실행 가능성이 훨씬 더 중요했거든요.

---

완벽한 설계는 왜 실패했을까

처음엔 ‘모든 경우의 수를 커버하는 기획서’를 만들려고 했습니다.
하지만 시간이 지날수록 깨달았어요.

• 아무리 구조가 완벽해도,
• 현장에서는 쓰기 어려웠고,
• 정책이 바뀌면 처음부터 다시 짜야 했습니다.

특히 공공기관 프로젝트에서는 변수가 너무 많았습니다.

정책 변화, 예산 변동, 담당자 교체...
이런 것들이 매 프로젝트마다 당연한 듯 일어났고,
저는 그때마다 '완벽한 기획'이 얼마나 무력한지 체감했습니다.

---

기획은 정답이 아니라 '움직이는 기준'입니다

그때부터 생각을 바꿨습니다.

기획서는 확정된 답이 아니라,
논의를 열어주는 기준이어야 한다고요.

• 필요하면 조정할 수 있어야 하고,
• 현장 상황에 따라 수정할 수 있어야 했습니다.

그래서 기획서를 만들 때
조건부 시나리오, 단계별 우선순위, 기능별 영향도 등을 같이 제시하기 시작했습니다.

이 방식은 특히 B2G 프로젝트처럼 조건이 자주 바뀌는 환경에서 큰 힘이 되었습니다.

---

실행을 중심에 두는 사고 전환

기획자로서 저는 이제 매번 이렇게 자문합니다.

"이 기능은 실제로 사용될까?"
"이 플로우는 현장 담당자가 무리 없이 소화할 수 있을까?"
"조직 내 결재라인을 통과할 수 있을까?"

기획자는 완벽한 로직을 설계하는 사람이 아니라,
현장에서 살아남는 구조를 만드는 사람이어야 합니다.

기능 하나하나를 멋지게 짜는 것보다
조직, 사용자, 정책 사이를 통과하는 흐름을 짜는 것이 훨씬 중요하다는 걸
조금씩 배워가고 있습니다.

---

개발자 사고를 넘어서: 설계자이자 조율자로

개발자였을 때는
"이게 논리적으로 맞다"고 주장하면 충분했습니다.

하지만 기획자로서 필요한 건
"지금 이 방향이 모두에게 납득될 수 있다"고 설득하는 힘이었습니다.

• 기술적 타당성은 기본이고,
• 정책적 방향성,
• 조직 내 의사결정 흐름까지 고려해야 했습니다.

특히 B2G 사업에서는
사용자보다 발주처 담당자의 결재 과정이 더 중요한 경우도 많았습니다.

---

기획자는 완성형이 아니라 시작형입니다

기획은 '끝난 상태'로 만드는 문서가 아닙니다.

• 논의가 시작될 수 있도록 열어두고,
• 변경이 가능하도록 여지를 남기고,
• 팀이 함께 완성할 수 있도록 설계하는 것.

그게 진짜 기획자의 역할이라는 걸 이제는 알게 되었습니다.

완벽을 목표로 하는 게 아니라,
실행할 수 있는 기준을 만드는 것.
그것이 개발자에서 기획자로 넘어오며 제가 가장 크게 배운 변화입니다.

---

완벽한 설계 대신,
움직이는 기획을 만드는 사람.
그게 지금의 나입니다.