기획하는 개발자, 개발공부하는 기획자

---

목차

 

👩‍💻개발자가 바라보는 기획, 기획자

내 첫 번째 회사(지금 이름은 한화 시스템)는 대기업 IT계열사이다. 대기업 계열사에서 IT를 담당하고 있는 회사들은 다른 계열사에 IT 시스템을 유지보수하는 업무를 주로 하게 된다. 나는 '한화투자증권'에 증권 서비스를 담당했었다. (이게 내 금융 IT 커리어의 시작..)

 

이런 대기업 IT 계열사들의 특징은 하청느낌으로 일을 한다는 것이다. 다른 계열사들이 '갑'이 되고 개발을 진행하는 계열사는 '을'이 된다. 나의 경우 한화투자증권 직원들이 '갑'이었고, 한화 시스템에서 한화투자증권 관련 서비스를 유지보수하는 팀이 '을'인 것이다. 따라서 대부분의 업무는 '갑'쪽의 기획 인력들이 요구사항을 전달하면, 그것을 만들어주거나, 서비스가 이상 없이 동작하는 것을 모니터링 및 유지보수하는 방식으로 진행된다. 이때는 기획자가 개발 지식이 필요하다고 느끼지 못했다.

 

내 두 번째 회사는 작은 스타트업이다. 10명 이하의 직원이 있었고, 개발자 3명, 마케팅 3명, 디자이너 1명, 기획/운영 1명 구성으로 꾸려진 회사다. 여기서는 따로 정해진 기획자가 없다. 누구나 앱에 대한 의견을 낼 수 있었고, 원하면 기획을 할 수 있었다. 빠르게 의사결정해서 피쳐를 내야 하기 때문에 개발자들은 모든 회의에 들어갔고, 자연스럽게 비 개발자들과 개발자들은 많은 시간을 같이 얘기하면서 보낼 수 있었다. 그 결과 모든 사람들이 개발적인 지식을 가지게 되었다. 아니 사실 가지게 된 건지는 모르겠지만, 된다 안된다 소리를 많이 들으니까 이제 뭐가 되고 안되는지 아는 수준까지 도달했다 ㅋㅋ 

 

세 번째 회사는 카카오 계열사였다. 카카오페이증권에서 초기 증권시스템 구축일을 하게 되었다. 팀구조는 사실 첫회사와 비슷했지만, '카카오' 계열사 특성상 개발자들도 기획에 많이 참여하게 되었고, 오히려 기획자보다 개발자의 의견이 더 존중되는 회사였다. 개발자가 의견을 더 많이 제시하고, 기획자는 컨펌하는 느낌? 사실 기획자라는 포지션보다 PM이라는 포지션이 카카오에 더 잘 어울린다고 생각한다. 

 

마지막으로 지금 다니는 회사는, 가파르게 성장한 회사다. 2022년 1월 입사했을 때 200명 정도였던 회사는 2023년 10월 기준 600명이 넘는다. 스타트업 형태로 시작한 회사가 점점 대기업스러워지고 있는 상황이다. 그래서 그런지 여기는 아직 문화가 정착되지 않았다. IT기반 스타트업으로 시작했기 때문에 오래된 사람들 중에는 개발자가 많고, 그렇게 때문에 도메인도 개발자들이 더 많이 알고 있다. 개발자들이 더 잘 알기 때문에 개발자들이 힘이 센 구조다. 

 

다른 회사에서 경력으로 온 기획자들은 이 문화에 잘 적응하지 못하는 것 같다. 특정 서비스를 만들 때 기획자가 준비해 온 기획안에 대해서 신랄하게 비판하는 개발자들이 있기 때문이다. 물론 우리 팀 개발자들도 예외는 아니다 ㅋㅋ 어떤 기획자가 일하기 좋은지, 어떤 기획자랑은 일하기 너무 싫은지는 항상 우리의 재밌는 이야깃거리가 된다. 

 

대부분의 팀원들은 '개발 지식이 어느 정도 있는' 기획자를 원한다. 아마 말은 이렇게 하지만 실제로 원하는 건 '말이 통하는' 기획자일 것 같다. 

 

🤷‍♀️🤷‍♂️언제부터 기획자가 개발 지식을 알아야 했을까?

2015년 첫회사에 있을 때만 해도 기획자의 기본 소양중 '개발 지식'은 포함되지 않았다. 하지만 어느 세부 터인가? '오늘도 개발자가 안된다고 말했다.', '기획자를 위한 개발지식', '개발자와 협업을 위한 개발지식' 등과 같은 책들이 출간되기 시작했고, 개발 지식이 없는 기획자들을 무시하는(?) 사람들도 등장하기 시작했다. 

 

오늘도 개발자가 안 된다고 말했다

 

과연 언제부터 기획자가 개발지식까지 알아야 하는 시대가 온 것인가!?!?!?

 

 

이건 아무래도 개발자와 기획자라는 직업의 위치와 관련이 있을 것 같다. 옛날만 해도 개발자는 아주 고달픈 직업이라는 인식이 강했다. 시키대로 하는 직업, 밤새 야근하는 직업, 주말 작업하는 직업이라는 느낌이 강했었는데, 한때 IT 개발 열풍이 불면서 개발자들 연봉이 올라가더니, 개발자라는 직업 자체의 위치가 수직상승하게 되었다. 물론 아무 이유 없이 수직상승한 것은 아니다. 스마트 기기가 널리 보급되고, 인터넷을 접속할 수 있는 인프라가 발달하면서 요즘에는 IT관련 서비스가 아니어도 IT 인프라가 필요하다. 예를 들어 커피점을 한다고 해도, 쿠폰시스템이나 주문시스템이 필요하기 때문에 개발자가 필요하다. 거기에 IT기반 기업들 (흔히 네카라쿠배....라고 말하는) 대거 등장하면서 IT개발자의 필요성이 증가되면서 기획자보다는 개발자가 더 중요한 직업이 되어버렸다. 한마디로 개발자만 있어도 서비스를 만들 수 있는 시대가 온 것이다.

 

하지만 그렇다고 기획자가 필요 없는 것은 아니다. 단지 개발자들끼리 어느 정도 돌아가는 서비스를 만들 수 있다는 소리다. 사용자가 많기 전까지는 기획은 큰 의미를 갖지 못한다. 일단 돌아가는 서비스를 만들고, 그 후 가다듬으면 된다. 따라서 작은 기업이나 스타트업들은 기획자보다는 개발자 비중이 높다. 초기단계에서는 개발자는 필수지만 기획자는 옵션인 것이다.

 

 

🤝 기획자님 이게 더 좋을 것 같은데요?

 

이렇게 개발자들끼리 개발도 하고 기획도 하다가, 추후 회사가 커지고 기획자가 충원되면 이런 상황이 자주 나온다.

 

"기획자님 이거 사용자한테는 이게 더 좋지 않을까요?"

 

경력으로 들어온 기획자 입장에서는 어리둥절할지도 모른다. 열심히 기획해서 준비해 온 문서를 개발자들이 평가한다? 어떻게 보면 선 넘은 것처럼 보인다. 이런 상황이 발생하는 이유는 개발자들이 도메인지식이 더 많기 때문이다. 우리 회사가 제공하는 서비스에 대한 이해도가 처음부터 만든 사람과, 중간에 들어온 사람을 비교해 보면 당연히 처음부터 만든 사람이 더 많은 지식을 가지고 있을 것이다. 개발자들은 흔히 '내가 만든 내 새끼'라는 생각(or 오너쉽)을 가지고 있기 때문에 내가 만든 서비스가 잘 되길 바라고 있으며, 자신의 사상과 의견을 넣으려고 한다. 하지만 기획자는 객관적인 시장 평가나 사용자 경험을 토대로 서비스를 수정하려고 한다. 

 

이러다 보니 서비스의 방향을 정하기 위한 회의가 많아지고, 개발자와 기획자 간의 의사소통 기회가 많아진다. 하지만 여기에 한 가지 문제가 있다. 서비스에 대한 이해도는 개발자와 기획자 둘 다 비슷하다. 개발자 역시 초기부터 서비스를 개발해 왔기 때문에 서비스에 대한 이해도가 높으며, 기획자는 본업이기 때문에 이해도가 높다. 하지만 개발 지식이 추가되면 어떨 까? 변경되는 화면 구성에 대해 개발적으로 가능한지, 불가능한지를 판단하기 위해서는 개발지식이 필요하다. 개발자 본업이 개발이다 보니 되고 안되고 가 바로 보인다. 하지만 개발지식이 없는 기획자 입장에서는 가능 여부를 알 수 없기 때문에 개발자에게 물어볼 수밖에 없다.

 

기획자: "이거 돼요?"

개발자: "음... 안 돼요"

기획자: "이거는요?"

개발자: "이거는 당연히 안되죠"

기획자: "힝구 ㅠ"

 

👨‍💻 개발공부를 하는 기획자들

 

개발자와 기획자의 불편한(?) 불균형에 대해 알아보았다. 기획은 직업에 상관없이 누구나 할 수 있는 제네럴 한 스킬이다. 반면 개발자는 전공지식이 있어야만 가능하다. 따라서 기획자가 개발자들과 동등한 위치에 있기 위해선 여태까지 몰랐단 개발지식이 필요하다. 

 

냥냥 개발공부다냥

 

하지만 최근에는 개발지식도 제네럴의 영역에 들어오고 있다. 초등학교 과목에 코딩이 들어갈 정도로 한국에서는 개발이 교양이 되고 있다. 따라서 새롭게 기획자로 발을 들이는 주니어 기획자들은 어느 정도 개발지식이 있을 것이라고 생각된다. 하지만 연차가 있는 기획자는 따로 시간을 내어 공부해야 한다. 

 

 

💬 이게 맞나? 

 

기획에 관여하는 개발자, 개발공부를 하는 기획자. 과연 이게 맞는 것일까? 스타트업과 같은 특별한 상황에서 기획은 하는 개발자는 아주 필요하다. 그리고 그런 개발자들과 협업하기 위해서는 개발지식이 있는 기획자 역시 필요하다.

 

하지만 우리는 모두 스타트업이 아니다.

 

사람은 변화를 싫어한다. 개발지식이 있는 기획자들과 협업한 경험이 많은 개발자들은 항상 개발지식이 있는 기획자를 원하며, 개발지식이 없는 기획자를 꺼려한다. 실제로 우리 팀 사람들은 회사규모가 작을 때부터 일했던 사람들인데, 그때 기획자는 개발자들과 딱 달라붙어서 일을 진행했다고 한다. 그래서 그때 기획자들은 개발지식이 빠삭하다. 하지만 최근 경력 기획자들이 들어오면서 우리 팀의 불만은 자연스럽게 기획자들의 '능력부족'을 지적한다. 기획자의 기획능력이 아닌 개발능력을 말이다.

 

 

 

지난주에 사내 어드민을 만들기 위한 API 만들 때 변수명을 정할일이 있었다. '소수점 고정자리'와 '고정 수수료'라는 두 가지 필드가 필요했는데, 서버 코딩상 둘 다 Fixed라는 필드를 사용했다. (소수점 고정자리 = A모델. Fixed, 고정 수수료 = B모델. Fixed) 

이번에 만드는 사내 어드민은 사용자가 직접 API를 불러와서 화면을 구성할 수 있는 유연한 시스템이다. 따라서 필드명에 의미를 담아야 사용자가 화면을 구성하는데 편리하게 된다. 따라서 나는 소수점 고정자리는 decimal_place, 고정 수수료는 fixed_fee라고 지을 예정이다. 하지만 옆에 있던 팀원은 이렇게 말했다.

 

팀원: "저라면 A_Fixed, B_Fixed라고 지을 것 같아요. 다른 개발자가 이 코드를 봤을 때 파악하기 쉽게요"

나: "그건 개발자 입장이고 사용하는 입장에서는 모르지 않을까요? 명확하게 변수명으로 나타내는 게 좋을 것 같은데, "

팀원: "이거 쓰는 사람이 누군데요?"

나: "어드민 쓰는 운영팀?"

팀원: "그분들은 이거 다 알아요."

 

대화를 하면서??? 가 많이 생겼다. 이 팀원은 사용자를 이미 특정 대상으로 좁히고, 그 사용자를 위해서만 서비스를 만들고 있다. 물론 정확하게 특정 사용자만 사용한다면 올바른 방향일 수도 있다. 하지만 회사에서도 인력 순환이 되고, 모든 사용자를 확실하게 알지 못하는 한 사용자가 명확하게 알 수 있도록 만드는 것이 좋다고 생각한다. 이 팀원은 왜 이런 생각을 하게 됐을까?

 

그 팀원은 회사에 오래 일하면서 운영팀과 잦은 커뮤니케이션을 해왔다. 함께 일하면서 자신이 알고 있는 도메인을 많이 고 융해 줬다고 생각하기 때문에 당연히 이거는 알 거다라는 고정관념이 박혀있다. 아마 그 팀원은 모든 협업을 그런 식으로 했을 것이다. 자신이 알고 있는 용어를 쓰고 그 용어를 모르면 도메인을 공유하면서 알려줬을 것이다. 물론 이 방법은 좋은 방법이다. 하지만 그 팀원이 회사의 모든 사람에게 지식을 공유할 수는 없다. 신규 입사자도 있을 것이고, 다른 팀에서 넘어온 사람도 있을 것이다. 매번 이런 설명을 하기는 힘들기 때문에 '이미 알고 있는' 직원들과 일하기를 선호할 것이다. 그 팀원의 말버릇은 이거다.

 

"아 왜 이걸 하는지 모르겠네, "

 

내 주변에, 기획자에 개발능력에 불만을 느끼는 개발자들은 대부분 같은 생각을 가지고 있었다. 다들 자신이 생각하는 방향이 있고, 그렇게 되지 않으면 불만을 느끼고 있다. 

 

 

🙄우리는 어떤 자세를 취해야 하나

 

나의 개인적인 생각은, "기획자가 개발지식을 알면 편하지만 몰라도 된다"라고 생각하는 쪽이다. 더 정확히 말하면, "기획자가 개발지식을 안다면 편할 것이고, 모르면 내가 더 노력하면 되지~"라는 생각이다. 개발 지식을 모르면 더 쉽게 설명하면 된다. 개발용어를 굳이 석어 가면서, DB 필드니 락이니 하는 개발 용어를 굳이 쓰지 않아도 기획자와 의사소통을 할 수 있어야 한다고 생각한다.

 

하지만 내 주변 몇몇 개발자들은 기획자랑 이야기할 때도 서슴없이 개발용어를 사용한다.

 

"해당 오류가 발생한 이유는 XXX모델에 콜백으로 YYY가 실행됐기 때문입니다"

 

처음에 나는 너무 당황했다. 저런 얘기를 기획자에게 한다고? 물론 개발지식이 있는 기획자에게는 아주 빠르고 쉽게 내용을 전달할 수 있다. 하지만 모두가 개발지식이 있지는 않다. 이게 회사에서 개발자들에게 커뮤니케이션 능력을 요구하는 이유 중에 하나다. 개발자는 누구에게나 쉽게 자신이 만든 코드를 설명할 수 있는 능력이 요구된다. 기획자에게 개발지식을 요구하는 것은, 다르게 표현하면 "나는 그것을 설명할 능력이 안된다"라고 보일 수 있다.

 

나는 상대방이 어느 정도의 이해력이 있는지를 항상 체크한다. 현재 업무에 대한 이해도나 배경지식, 용어에 대한 이해력 등을 판단하여 어떻게 설명해야 내 말이 잘 전달될지를 생각하고 말하는 편이다. 이건 내가 어렸을 때부터 발표하는 것을 좋아해서 쌓인 버릇 같은 것이다. 커뮤니케이션 능력이 부족한 개발자들은 이런 것에 약하다. 그들은 대부분 자신들이 알고 있는 것을 다른 사람도 알기를 원한고, 내가 아는 것을 상대방도 알고 있을 거라는 기대를 가지며 대화를 한다. 마치 '지식의 저주'에 걸린 것처럼 말이다.

-> 지식의 저주에 대한 지난 포스팅

 

 

기획자든 개발자든 서로의 영역을 알면 협업하기 편하다. 이건 기획자와 개발자에 국한된 것이 아니다. 협업을 하는 카운터 파트너에 대한 이해도는 항상 일 진행을 수월하게 만들어준다. 기획자에게만 개발 지식을 강요하는 것은 너무 이기적인 생각은 아닐까? 

 

나는 개발자도 UI/UX에 대한 공부나 마케팅과 같은 기획적인 요소를 공부하는 것을 추천한다. 나 역시 UI/UX에 대한 책이나 글들을 많이 찾아보는 편이다. 즉, 기획자에게 개발적인 지식을 요구하기 전에 우리도 기획적인 지식을 쌓자는 소리다. 가장 좋은 것은 양쪽 다 서로의 지식을 공부하는 것이지만, 상대가 못할 경우 내가 준비하면 된다는 마인드를 갖자. 

 

그리고 가장 중요한 것은 유연함, 진리의 케바케다. 어떤 회사에서는 개발자는 개발만 하고, 기획자는 기획만 하고 있을 수 있다. 또 어디에서는 기획자들이 개발을 관여하고 있을 수 있고, 어디는 개발자가 기획과 개발을 동시에 하고 있을 수 있다. 세상은 다양하다. 내가 속한 조직에 알맞은 방향을 찾아 적용하는 유연성을 기르자.