기획자가 개발을 공부해야 하는 이유

기획자는 개발을 몰라도 괜찮아요.

 

처음 실무에 발을 들였을 때, 가장 자주 들었던 말이다.
그리고 나도 꽤 오랫동안 그 말에 고개를 끄덕였다.

 

개발은 개발자 몫이고, 기획자는 사용자의 요구를 잘 정리해서 전달하면 된다고.
그래서 나는 사용자 흐름을 정리하고, 정책을 문서화하고, 스프레드시트로 조건을 나열하면서 꽤 유능한 기획자가 된 것 같은 착각을 하곤 했다.

 

그런데 이상하게도, 프로젝트가 반복될수록

 

‘내가 뭘 놓치고 있는 거지?’ 하는 찜찜한 순간이 하나둘 생기기 시작했다.

 

---

“이 기능 구현하는 데 왜 이렇게 오래 걸리죠?”

한 번은 그랬다.
내가 보기엔 정말 단순해 보이는 조건 필터였는데,
개발자 입에선 “이건 백엔드 구조를 바꿔야 가능해요”라는 말이 나왔다.

 

나는 어안이 벙벙했고, 개발자는 답답해했고, 프로젝트 매니저는 당황했다.

 

‘왜 간단한 걸 이렇게 어렵게 말하지?’ 라는 내 속마음은
결국 ‘왜 복잡한 걸 이렇게 쉽게 생각하지?’라는 개발자의 반격을 불러왔다.

결국 그날 회의는 감정이 상한 채로 끝났고,
기획서의 수많은 조건들은 전면 수정됐다.

 

그때 처음 깨달았다.

기획자는 기술을 몰라도 일은 할 수 있지만,
기술을 모르고 하면 사람을 놓친다는 것.

 

---

기획서에 ‘말’만 있고, ‘이해’는 없었다

그 이후로, 나는 내 기획서를 다시 보기 시작했다.
그 안에 담긴 수많은 "한다"와 "되어야 한다” 문장들.

 

그 중엔 실제론 구현이 매우 복잡한 것들도 있었고,
비용 대비 효용이 크지 않은 요구도 많았다.

 

이해 없이 적은 문장은, 결국 ‘기대’만 키우는 말이 된다.

기술적인 구조와 제약을 조금이라도 이해하고 나니,
나는 점점 ‘무리한 요구’ 대신 ‘실행 가능한 제안’을 하게 됐고,
팀은 나를 ‘요구하는 사람’이 아니라 ‘같이 고민하는 사람’으로 바라보기 시작했다.

 

---

기획자는 ‘코드를 짜는 사람’이 아니라, ‘대화를 잇는 사람’

나는 여전히 개발자가 아니다.
그렇다고 앞으로 개발자가 될 계획도 없다.

하지만 기획자로서

 

 “그 기능 구현은 얼마나 복잡한가요?”  
 “지금 구조에서 이 조건을 붙이면 어떤 문제가 생길까요?”

라는 질문을 던질 수 있게 된 건 큰 변화였다.

그리고 더 중요한 건,  
그 질문을 ‘개발자의 언어’로,  
‘공감하는 태도’로 할 수 있게 되었다는 점이다.

나는 지금, 방송통신대학교 컴퓨터과학과에 다니고 있다.  
기획자가 더 깊이 기술을 이해하고 싶다는 마음 하나로, 늦은 나이에 학부 공부를 다시 시작했다.

물론 쉽지는 않다.  
함수, 포인터, 알고리즘… 처음엔 하나하나가 낯설고 어렵다.  
하지만 이 과정을 거치며 내가 기획하는 기능의 구조가,  
개발자의 코드 너머에서 어떤 식으로 흘러가는지를 조금씩 이해하게 된다.

아직은 공부 중이다.  
하지만 분명한 건 기술을 배우기 시작한 이후로  
기획에 임하는 내 태도 자체가 달라졌다는 것.

기획자는 연결자다.  
그리고 연결자는, 양쪽의 언어를 모두 들어봐야 진짜로 ‘듣는 사람’이 된다.

---

결국, 기술은 ‘도구’가 아니라 ‘이해의 언어’

어떤 기획자는 말한다.  
“그건 개발이 알아서 할 일이죠.”  
맞는 말이다. 정말로.

하지만 나는 그럴 때마다 이런 생각이 든다.  
“내가 이걸 조금만 더 알았더라면, 지금 대화는 조금 더 부드러웠을 텐데.”

기획자가 기술을 배운다는 건,  
직무를 넘나드는 슈퍼 능력을 얻겠다는 것도 아니고,  
개발자의 일을 대신하겠다는 것도 아니다.

단지, 더 잘 들을 수 있게 되겠다는 다짐이다.
그리고 더 잘 설계하고, 더 잘 연결하겠다는 태도다.

 

---

내가 추천하는 기술 공부법

기획자로서 기술을 이해하고 싶다면,  
전부 다 파고들 필요는 없다고 생각한다.  
대신, 아래 세 가지만 시작해도 충분히 ‘대화가 통하는 사람’이 될 수 있다.

1. 용어 먼저 익히기 – “말이 안 통하는” 상황을 줄이자**  
   REST API, 비동기/동기, 클라이언트-서버 구조 같은 개념부터.  
   대화 중 “이게 무슨 말이지?” 싶으면 바로 검색해보는 습관이 중요하다.  
   _(나는 MDN 문서나 Velog 글을 많이 참고했다. 요즘은 ChatGPT에 물어보면 너무 편함..ㅎ)_

2. 간단한 기능 흐름을 그려보자 – 기술은 흐름 속에서 이해된다   
   예: “사용자가 버튼을 누르면 어떤 흐름으로 데이터가 움직이는가?”  
   이걸 직접 다이어그램으로 그려보면, 백엔드-프론트-DB 간의 관계가 눈에 들어오기 시작한다.

3. 개발자에게 자주 묻자 – 구글보다 현업이 빠를 때도 있다   
   모르면 그냥 물어보자.  
   “이런 기능 구현에 뭐가 복잡할까요?”  
   “이런 구조에서 무슨 제약이 있을까요?”  
   생각보다 많은 개발자들은 기획자에게 설명해주는 걸 즐긴다. 정말로.

 기술 공부는 ‘정답’을 아는 게 아니라,  
‘좋은 질문’을 할 수 있게 되는 것에서 시작된다.

 

---

 마무리하며

 

요즘 나는 기술을 배우는 기획자들을 자주 본다.  
그건 참 반가운 풍경이다.

기획은 설계이고, 설계는 결국 구조를 이해하는 일이다.  
그리고 구조는 기술 위에 서 있다.

그렇기에 나는 믿는다.  
기획자가 기술을 이해하려는 순간,  
기획은 비로소 진짜 팀워크의 중심이 된다.