개발을 모르는 IT기획자는 한계가 있을까?
1. 기획자의 역할
"코딩을 할 줄 알면 좀 더 도움이 될까요?"
요즘 주변 기획자, 혹은 PM들이 나에게 많이 묻는 질문 중에 하나다. 나에게 많이 묻는 이유는 내가 개발자 출신이라서다. 난 총 경력 10년 중, 개발자 경력이 5년, 개발 겸 PL 경력이 2년, IT기획자(Tech PM) 으로 일한지 2년이 되간다. 그래서 비개발자인 PM이나 기획자들보다는 조금은 IT기술에 대해서 더 알고 있다.
그렇다면 개발은 기획자에게 어느정도로 중요할까? 잘 모른다면 정말 한계가 있을까?
기획자업무의 종류부터 알아보자.
여기서 기획자는 일반적으로 IT기획직군을 의미한다.
- 시스템 기획 (무엇을, 왜 만들 것인가)
- 시스템 설계 (어떻게 만들 것인가)
- 시스템 구현 관리 (잘 만들어지고 있는가)
- 시스템 배포 및 운영 지원 (실제 배포 및 효용성 검증)
세부직무 별 디테일한 부분의 관점은 다르지만 근본적으로는 저 정도의 범주가 기획자의 역할일 것이다.
2. 기획자에게 개발지식이 필요한 이유
기획자는 개발자가 아니기에 구현을 스스로 할 정도의 개발지식은 필요 없다.(물론 그 정도라면 더 좋긴 하다. 효용성의 문제다) 하지만 개발을 아예 모른다면 그건 얘기가 다르다.
여기에 조회 될 때 데이터 하나만 더 추가해주세요.
이런 요청을 했을 때, 개발자가 "그러려면 데이터 구조를 싹 바꿔야되서 엄청 오래 걸려요" 라는 대답이 오는 것은 흔한 광경이다. 아예 IT와 무관한 직원이라면 저렇게 요청하고 저게 왜 오래 걸리는지 몰라도 된다.
하지만 IT기획자라면 저 요청을 했을 때, 개발자가 어떤 작업들을 수행 할지 직관적으로 알아야 한다.
" 데이터 호출하는 API도 호출해야되고, 그 데이터를 보여지게 할 화면도 수정해야되고, 백엔드에서는 쿼리랑 일부 로직도 수정을 해야겠구나 "
최소한 이 정도로는 이해를 해야된다.
더 좋은 수준은
"저 데이터를 갖고오려면 A테이블이랑 조인해야되는데, A테이블에는 데이터가 워낙 많으니 쿼리 속도 저하 이슈가 생길 수 있겠다. A테이블을 직접 조인하지말고 내가 필요한 데이터만 주기적으로 적재하는 B테이블을 하나 만들고 여기에 데이터 서빙을 해서 B테이블과 조인을 걸어 조회하도록 요청해야겠다"
정도의 생각까지 도달한다면 훌륭한 기획자이다.
만약 개발 지식을 모른다면 아래와 같은 문제가 발생한다.
- 일정 산출이 불가능해진다. (혹은 일정을 결정하는게 개발자가 되버린다)
- 그 변경이 시스템에 어떤 영향도를 끼칠지 판단을 못 한다. -> 즉, 시스템의 안정성 이슈가 생긴다.
- 서로가 서로를 답답해하는 상황에서 개발자와 관계의 갈등이 생긴다.
- 시스템을 주도적으로 기획/설계 할 수 없게 된다.
그래서 기획자는 개발을 직접 할 줄 모른다고 하더라도, 시스템 간 코드가 어떻게 연결되어 있는지 큰 숲은 볼 줄 알아야 한다.
3. 어느정도까지 알아야 될까?
그럼 어느 정도 수준까지 알면 될까? 개인적으로는 개발자와 '개발의 언어'로 커뮤니케이션이 가능할 정도면 된다고 생각한다. 더 나아가 인프라 담당자와 소통할 수 있는 인프라 지식까지 겸비한다면 금상첨화다.
아래는 대략적인 영역별 체크리스트를 뽑아봤다.
IT 지식, 얼마나 갖고 있나? - 체크리스트
| 영역 | 필수 이해 포인트 | 공부 키워드 |
|---|---|---|
| 프론트엔드 | css/html 구조, React/Vue의 컴포넌트 개념, 백엔드와 통신하는 과정, 브라우저 작동 원리 | React, Vue, 컴포넌트, API 호출, Hook, 세션/쿠키/로컬스토리지, SSR, 렌더링, 동기/비동기 |
| 백엔드 | API 구조, REST API 개념, 데이터 추출가공하는 작동원리, DB 쿼리 | API, REST API, SQL, Springboot, 컴파일, 빌드, PK/FK, JOIN, 인덱스, 객체, 암복호화 |
| 인프라 | 배포 프로세스, 보안과 네트워크에 대한 개념 | Git, Svn, 방화벽, 클라우드 |
위 키워드와 개념을 위주로 공부하면 개발자와 소통에는 문제가 없을 것이다. 더 나아가 경험까지 쌓이면 시스템 전체를 설계할 수 있는 기획자가 될 것이다.
코드를 보면 달라지는 것들
1. 코드를 보면 리스크가 보인다
코드를 직접 짜지 않더라도, 위에서 설명한 개념들에 대한 이해를 바탕으로 시스템을 기획설계 하면 기존에 보이지 않던 것들이 보이게 된다. 그러면서 프로젝트 혹은 시스템의 관리를 훨씬 정밀하고 체계적으로 할 수 있게 된다.
대표적으로
- 일정관리가 훨씬 현실적으로 가능해진다.
- 장애 대응 시 원인 추정 속도가 빨라진다.
- 요구사항 충돌 시, 구현 우선순위를 정확하게 정립할 수 있게 된다.
- 각 관계자(개발자, 디자이너, 인프라담당자, 서비스기획자)들 간의 소통에서 주도적인 역할을 할 수 있게 된다.
결론적으로 내가 아주 중요한 사람이 된다!(난 관종이라 내가 중요한 사람이 되는게 좋다..)
결론 : 기획자는 시스템을 설계하는 사람
"기획자는 코드를 몰라서가 아니라, 코드를 모른 채 결정을 내려서 실패한다.”
우리는 하나의 시스템의 어찌보면 결정권자다. 결정권자가 내용을 이해 못한채 결정하는 것만큼 리스키한 행동이 어디있을까?
고로 우리는 최소한 시스템을 설계할 때 이에 대한 내용을 이해하고, 각 관계자들을 하나로 통합시켜 프로젝트를 성공으로 이끌어야 한다.
그래서 다시 처음 질문 'IT기획자(혹은 PM)은 코딩을 할 줄 알아야 할까?' 에 대한 나의 대답은
"코딩은 할 줄 몰라도 되지만, 코드를 이해하고 코드로 사고할 줄 알아야 한다" 이다.