brunch

매거진 IT회사에서 PM으로 일합니다

라이킷 13 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이서 Sep 24. 2021

그건 제발 개발자에게 맡겨주세요

"아뇨, 그 컬럼은 varchar로 해주세요. 코드 테이블은 분리해서 별도로 만들어주시구요."

이제와서 돌이켜 생각해보면, 참 낯부끄러운 멘트다.

왜 그랬을까?

서비스 PM으로 일하면서 했던 수많은 고민들이 있다. 도메인 정책과 방향에 대한 고민은 물론이고, 팀원 분들의 성장과 자기 계발에 대한 고민도 많이 했다. 어떻게 하면 모두가 행복하게 일하며 멋진 서비스를 만들 수 있을지 생각해보기도 했다. 물론 정답은 없었다. 결론이 나지도 않았고, 결과물이 좋지도 않았다. 그래도 고민은 했다. 고민해야 1cm라도 발전하니까.

그 수많은 고민 중에, '개발자와 어느 정도까지 깊은 대화를 해야 할지'에 대한 고민도 들어있다. PM으로서 개발자와 이야기하며 개발 스펙 이야기를 많이 나눈다. 이건 이렇게, 저건 저렇게 구현하고, 타 서비스와 연계는 어떻게 하며, 예상 되는 문제는 무엇인지 등등. 그런데 이런 이야기를 길게 하다보면 내용이 참 깊어진다. 결국 개발측면에서의 영역까지 들어가게 된다. 로그를 어떻게 쌓고, 캐시를 쓸지, 카프카를 사용할지, 배치는 어떻게 구동하며, API 통제는 어떻게 해야 할 지 등등. (심지어 구현 방식에 대한 아키텍쳐 설계 의견도 냈다.) 개발자가 아니면 잘 모를 내용까지도 대화의 주제로 꺼내들었다. 나는 세상 무서운 줄 모르고 막무가내로 의견을 주장했다.

내가 멋모르던 시절에 가장 집착했던 건 바로 테이블이었다.

적재되는 정보의 수준과 퀄리티가 그 도메인의 수준을 나타낸다고 생각했었기에, 더욱 신경을 썼던 것 같다. 혹시나 같은 내용이 두번 적재된다던가, 정합성이 맞지 않는다던가, 뜻모를 코드로 관리되고 있다거나 하면 끝까지 물고 늘어져서 해결을 해야 직성이 풀렸다. 하나하나 다 관심을 갖고 파고 들었다. 새로운 기능을 만들고 붙일땐, 테이블 스키마 까지 이야기 했다. 정규화 까지 요구했으니 말 다했지. 듣는 개발자는 얼마나 어이가 없었을까 싶다. 그런 마음가짐이었기에 저 위 첫번째 줄의 멍청한 요구사항을 창피한 줄도 모르고 내뱉었던 것이다.

이젠 그러지 않는다.

왜냐하면,

전문 영역은 전문가에게 맡기는 것이 가장 효과적이기 때문이다.

나는 개발자가 아니고, 구현에 대한 지식이 없다. 아니 없다기보단 얕다. 얕은게 문제다. 차라리 모르는게 낫다. 얕은 지식이 훨씬 더 무섭다. 자기가 뭘 모르는지 조차 모른채 알량한 지식을 가지고 마치 다 안다는 듯 설치는 사람이 가장 위험하다. 어느 정도 어깨 너머로 보고 들은 개발지식으로, 이래라 저래라, 감놔라 배놔라 하는 PM이 되어버린다. 게다가 연차가 쌓였으니 조직내의 하마(HIPPO, Highest Paid Person's Opinion)가 되어 권력을 마음껏 휘두른다.

그래서 요새는 누가 물어봐도 '저는 잘 모릅니다' 라고 대꾸한다. 대답하고 싶으면 참는다. 조금 알아도 모른다고 한다. 확실하게 모르는데, 아는 척 하는 사람이 제일 위험하다.

곤경에 빠지는 건 뭔가를 몰라서가 아니다. 뭔가를 확실히 안다는 착각 때문이다.
-마크 트웨인-

나보다 개발자들이 훨씬 효율적인 방식으로 설계한다. 도메인에 대한 주인 의식이 있기 때문에 절대로 허투루 구현하지 않는다. 유지보수에 대한 책임감을 가지고 코드를 짠다.

개발자들이 맞다.

실무를 제대로 모른다면, 구현에 대해서 만큼은 귀기울여 그들의 의견을 들어야 한다.

공감해야 한다.

더군다나 정답이 없는 개인 취향이라면 더욱더 전문가의 의견을 듣는게 맞다.

'그렇게 하는게 더 깔끔하잖아.' , '나중에 보기가 좋잖아' 식의 어설픈 개인 취향 고백은 잠시 넣어두시라. 당신보다 훨씬 더 고민하는, 하루 대부분의 시간을 코드와 씨름하는 훌륭한 개발자들이 최적의 방안으로 설계하고 구현해줄테니.

그건 제발 개발자에게 믿고 맡겨주자.

대기업 IT부서에는 소위 '임원'이라고 불리는 꼰대들이 많다. (꼰대라는 단어도 참 올드하긴 한데, 그보다 더 그들을 잘 표현하는 단어를 아직 찾지 못했다.) 그들은 실무에서 손을 놓은지 족히 10년은 넘었음에도 불구하고 하나하나 다 시시콜콜 참견하고 지시한다. 마이크로매니징의 차원을 넘어선 월권 행위를 창피한지도 모르고 마음껏 저지른다. 어디서 책을 한권 읽고 와서 일장 연설로 프로세스를 뒤집어 엎는가 하면, 그럴듯한 형이상학적 이론을 들고 와서, 사업을 가로막고 방해한다. 예를 들면 이런 식이다. '그건 우리 회사의 데이터 방향성과 맞지 않아요. 그런 방식의 구현은 절대 안됩니다.' 방향성이 뭔지 아는 사람은 없다. 그냥 그렇게 말하는 거다. 실제로 누군가 명확한 논리로 반박하면, 대응도 못한다. 자기가 한 말에 걸려들어, 창피한 꼴을 당해도 고집과 자존심으로 끝까지 밀어붙인다. 의견을 내도 듣지 않는다. '그냥 안된다면 안되는 줄 알지 왜 말이 많아요!' 라고 역정 내는 것으로 정책 회의는 마무리 된다.

그래놓고,

우리는 수평적인 커뮤니케이션을 지향하며 구글이나 페이스북과 같은 문화를 만들자고 공염불한다. 개그콘서트도 아니고 도대체 왜 이러는 걸까.

제발 전문 영역은 전문으로 일하고 있는 실무자들의 말을 듣자. PM 혹은 개발자들이 그럴만 하니까 그러자고 하는거다. 그렇게 구현해야 하는 이유가 있다. 이해가 안간다고? 이해하려고 하지 마라. 당신은 이해 못한다. 당신은 개발자가 아니잖아요. 실무를 모르잖아요.

당신이 한 마디 하지 않는다고 그 누구도 당신을 우습게 보지 않는다.

미안하지만 당신은 그것보다 조직의 발전과 구성원들의 성장, 행복하게 집중해서 일할 수 있는 환경 그리고 사내외 정치공학적 이슈를 해결하는 역할에 힘써달라. 당신이 그런 일을 해야, 조직의 생산성이 향상되어 성과가 올라간다. 구성원들의 만족도가 올라가는 건 덤이다. 좋은 문화는 그렇게 만들어진다.

제발, 개발 구현 방식이나 아키텍쳐 설계, 데이터 적재 방식에는 신경 꺼 달라. 훨씬 더 잘하는 개발자들이 밤새 고민하고 애쓰고 있다. 그들이 힘 낼 수 있게 도와달라. 엷은 미소를 짓고, "고생이 많습니다. 잘 부탁드립니다. 제가 잘 모르니 여러분들이 맡아서 잘 진행해주시지요." 라고 권한을 멋지게 위임하라.

모르는 걸 모른다고 하고, 가르쳐 달라고 정중히 부탁하는 것.

그게 진정한 용기이고 배움의 자세다.

keyword