신입 PM 첫 1년 생존기 - (4)
기획자를 위한 개발 지식
개발을 얼마나 알아야 할까?
“너 코딩 할 줄 알았어?” PM으로 직무 전환 한 다음에 가장 많이 들은 질문 중 하나이다. 이에 대한 대답은 “아니오” 이다. PM이 직접적으로 개발을 하는 것은 아니기에 구체적으로 코딩을 할 줄은 몰라도 된다. 그러나 나는 개인적으로 간단하게 코딩과 SQL 공부를 하는 것은 추천한다.
1. 개발 관련한 책을 읽었다.
제일 유명한 책인 ‘비전공자를 위한 이해할 수 있는 IT 지식’이라는 책을 읽었다. 개념부터 천천히 설명해주기에 개념을 쌓기에는 매우 좋았으며, 아직도 책을 자리에 두고 가끔 꺼내본다. 읽을 때마다 이전에는 내가 미처 이해하지 못했던 부분들이 눈에 들어와서 다회독을 권장한다. 하지만 그래도 무언가 이해될 듯, 이해 안되는 것들이 많아서 직접 개발에 도전해보게 됐다.
(1) API, Json, Java, HTML, CSS 와 같이 자주 사용되는 용어의 개념을 잡고 이해하는 데 도움이 됐다.
(2) 클라이언트와 서버가 있어서 통신을 하는데 빠르게 페이지 로딩을 하기 위하여 쿠키를 사용 한다든지, lazy-loading을 한다든지 조금 더 세심하게 기획할 수 있었다.
2. 파이썬을 공부해 봤다.
공부해 “봤다” 라고 말하는 건 실력이 미천하기 때문이다... 인프런 오리지널 파이썬 강의를 들었는데 레벨 2까지는 기운차게 들었으나 레벨 3에 일년 째 멈춰있다. (머쓱하다)
레벨1: 영어를 처음 배울 때 알파벳부터 시작하듯이 변수, 자료형(숫자, 텍스트, 집합, 튜플, 딕셔너리), 흐름 제어(if, for, while), 함수, 클래스, 함수에 대해서 배운다.
레벨1.5: 문제 풀이를 통해 레벨 1에서 배운 것을 되돌아본다. 레벨 1 강의를 몇 번 돌려보면서 문제를 풀었는데 그래도 못 풀고 해답을 본 게 많았다.
레벨2: 클래스, 메소드, 시퀀스, 일급 함수, 병행성에 대해서 배운다. 사실 내용은 이제 거의 생각이 안나지만 ‘객체 지향’이라는 개념을 잡을 수 있어서 좋았다.
(1) 개발자의 말을 이해하는 데 도움이 됐다. 개발자가 안된다고 할 때 왜 안되는 지 이해하고, 다른 대안을 같이 생각 해볼 수 있었다.
(2) 기획을 ‘구체적으로 한다’ 는 것이 어떤 것인지 알게 됐다. 코딩을 하면서 생각보다 노가다 같다는 생각을 했다. 마법처럼 모든 것이 짜자잔 해결될 것 같지만, 실제로는 한땀한땀 개발을 해야 했다. 나의 기획서를 보고 어떻게 개발을 하면 될 지 쉽게 이해할 수 있도록, 나도 케이스 별로 나눠서 기능 설명을 넣어야 겠다는 생각이 들었다.
(3) 개발의 구조를 생각하게 됐다. A라는 액션을 할 때 이를 구현하는 방법은 여러가지인데, 현재의 구조를 최대한 활용할 수 있는 방안이나 혹은 서버 부하가 가장 적은 방법으로 기획할 수 있어야 한다. 구체적인 안은 개발에서 제안을 해주겠지만, 이를 이해하고 기획에 반영하는 것은 PM의 역량이라고 생각한다. 예를 들어 100만 번 루프를 돌면서 작업하면 시간이 오래 걸리겠지만, 100만 건을 한 번에 처리하면 빠르게 작업할 수 있는데. 그렇게 개발 할 수 있도록 기획 방향성을 잡아야 한다.
3. SQLD 공부를 했다.
PM이 직접 데이터를 추출하고 가공하기도 한다. 우리 회사의 경우에는 DW 권한을 주지 않아서(...) 내가 직접 데이터를 추출하는 경우는 없지만, 개발자 혹은 마케터들이 적은 쿼리를 같이 보기는 한다.
독학으로 2달 정도 공부를 했는데, 온라인에 있는 요약본을 다운받아서 공부하고 SQLD 자격 검정 실전문제(유명한 노랑이 책)를 풀었다.
(1) 데이터 모델에 대한 개념을 잡을 수 있었다. 개별 데이터는 다른 것들과 구별되는 고유한 값이 필요한데 키(key) 값으로 사용할 것을 기획 시 정의해줘야 한다.
(2) 쿼리를 대략적으로나마 이해할 수 있게 됐다. 개발자에게서 쿼리를 받아서 보면 어떤 테이블에서 어떤 데이터를 가지고 온 것인지, 어떤 테이블들을 조인한 것인지 등을 알 수 있다.
개발자와 일하면서 느낀 점은
(1) 구체적인 개발 방법은 개발자가 정하겠지만, 해당 구조를 이해하고 활용하는 것이 정말 중요하다. 기획이 잘 되어 있어야 유연하고 효율적으로 개발할 수 있다.
(2) 대용량 처리를 하는 것이 생각보다 어렵다. 서버에 부하를 주고 시간이 오래 소요된다. 대용량 작업을 할 때는 배치로 처리하고, 트래픽이 적은 새벽 시간에 진행하는 것이 좋다.
(3) 개발자들 간에도 잘 모른다. 프론트 개발자, 백 개발자, DB, DW, 퍼블리셔 등 모두 나뉘어져 있기 때문에 본인 담당 업무 외에는 정확하게 알기가 어렵다. 그러니 부끄러워 하지 말고 계속 물어보고, 미스커뮤니케이션이 발생하지 않도록 하는 것이 중요하다.
정말 많이 고민하고 마음 졸였던 한 해 였다. 앞으로 얼마나 더 많은 어드벤쳐(라고 쓰고 역경이라고 읽는다)가 기다릴지!
