잘 나가는 개발자가 대기업을 뛰쳐나온 이유

좋은 개발 문화는 새로운 지식이 주입되고, 계속 발전하는 문화에요.

안녕하세요. 메디블록 CTO 차민규라고 합니다. 네이버 개발팀에 7년, 메디블록 팀과 함께한 지 3년 좀 넘은 10년 차 개발자입니다.

안녕하세요. 민규쌤, 꽤 오래 네이버에 계셨네요. 네이버 어떤 팀에 있으셨나요?

네이버로 모이는 데이터를 저장하는 분산저장플랫폼 개발팀에 있었어요. 네이버에는 저장소가 몇 가지가 있는데 대용량 데이터를 저장하는 파일저장소, 데이터 요청을 매우 빠르게 처리하는 메모리 저장소, 정형화된 데이터를 저장하는 분산 데이터베이스 저장소 등이 있어요. 저는 7년 동안 이 3가지 저장소 업무를 모두 담당했고, 이 세 저장소는 모두 사내 기술상을 받았죠. 물론 혼자 한 것은 아니지만 2-3명이 맡았었기 때문에 각자 중요한 개발들을 했었어요.

중요한 개발들 중 하나만 저희에게 공유해주실 수 있나요?

모두 중요하다고 생각하는데 기억에 남는 경험은 있어요. 당시 신규 프로젝트였던 메모리 기반의 매우 빠른 저장소를 개발하는 것이었고, 저도 나름 꽤 중요한 부분들을 맡았어요. 검증하는 테스트를 열심히 짜서 안정적으로 굴러갔어요. 제 코드가 그렇게 아름답지는 않았지만, 문제없이 잘 돌아갔고, 부하를 많이 받는 서비스들에도 많이 들어갔죠. 지금 보면 사소한 기능들이지만 제가 개발한 그 프로젝트가 있어서 돌아가는 서비스들도 있었어요. 그런데 갈수록 아름답지 않은 코드 때문에 스트레스를 받기 시작했죠.

예를 들면, 중고나라 카페에서 키워드 알림설정을 하면 푸시 메세지가 오잖아요. 푸시메세지 기능이 일반적으로 어려운 기능은 아니지만 중고나라처럼 회원 수가 많고, 특정 게시판에 대해 알림을 거는 사람이 많으니까 고속으로 데이터를 처리해야 일이 발생하는 거에요. 부하가 걸리는 거죠. 이 와중에 추가기능 요청이 올 때마다 머리가 너무 복잡해지고, 너무 불안한 거에요. 지금 이미 잘 돌아가고 있는 서비스인데 고치거나 기능을 추가했다가 장애가 나면 파급력이 너무 컸거든요.

그래서 리팩토링을 결심했고, 6개월 걸려서 다시 짰어요. 10년이 지난 지금 생각해도 정말 아름다운 코드를 짰어요. 엄청 많이 배운 것 같아요. 공부도 많이 하고, 더 찾아서 알아보고 그랬어요. 이미 정말 잘 굴러가고 잘 나가는 서비스의 코드잖아요. 24시간 돌아가고 있는 기계에서 핵심 부품을 고치는 작업인 거에요. 개발자에게 내가 짠 코드를 내가 다시 아름답게 고칠 기회는 잘 오지 않아요. 이 경험이 저에게 많은 배움을 준 것 같아요.

‘코드가 지금 봐도 아름답다’ 너무 멋진 말인 것 같아요. 그런데 코드가 처음부터 아름다울 수는 없나요?

이제 경험이 있으니 아름다운 코드를 짜는 방법을 항상 고민하죠. 그런데 방금 말씀드린 경우가 왜 생기냐면 미래를 알면 처음부터 고려해서 개발하는데 미래를 아무도 모르잖아요. 처음에 개발을 하다 보면 ‘조금 귀찮은데 대충 이렇게 하고 넘어갈까? 이렇게까지 해야 하나?’ 라고 생각해서 넘기거나 오히려 너무 오버를 해서 개발을 하는 경우도 있어요. 그런데 경험이 없는 사람들은 보통 ‘지금 잘 모르는데 왜 이렇게까지 해야 하냐’ 혹은 ‘이거 지금 매우 사소한 것인데 너무 어렵게 하는 것 아니냐’라는 의견을 가지기도 해요. 왜냐하면, 그것 하나가 사소해 보이거든요. 앞으로 엄청나게 많은 코드가 나올 텐데 처음 작성한 코드 일부만 보고 너무 의존관계가 복잡하다 이렇게 저렇게 하기가 더 쉽다고 말할 수 있어요. 하지만 이 사소한 것들이 계속 쌓이다 보면 그물망처럼 얽히게 돼요. 그걸 보통 풀 수가 없거든요. 저는 그걸 경험해서 알고 있는데 이런 경험이 없으면 ‘나중에 개발하면 된다, 지금은 다른 중요한 걸 개발을 하자’라는 생각이 들기도 할 거에요. 그런데 기능 요청은 계속 들어와요. 이건 모든 개발자에게 해당하는 일이죠. 또 개발을 하다 보면 모든 것이 결정되지 않은 채 개발을 시작하기도 하고, 그렇다고 미래를 예측해 섣불리 개발하는 것도 문제가 되요. 그래서 기준을 잘 잡아야 해요.

제가 잡는 기준은 각각의 레이어별로 역할 분담을 잘하고 각각의 컴포넌트별로 정보숨김(Information hiding)을 잘한다는 것이에요. 예를 들어, 팀장이 팀원에게 일을 시키잖아요. 팀장은 팀원에게 역할을 부여해야 하고, 팀원은 팀장이 알고 싶은 결과만 알려주면 되죠. 팀장이 세세하게 많은 걸 지시하려고 하면, 팀의 규모가 커질수록 복잡해지는 거에요. 소프트웨어도 비슷해요. 각각의 컴포넌트가 각자의 역할을 책임지지 못하고, 서로 간에 많은 지시를 해야할 수록 복잡해지죠. 이건 모든 업무에서 해당할 수도 있는 얘기겠네요(웃음). 팀원을 관리하는 것과 똑같이 메디블록 개발팀은 그렇게 개발을 하고 있어요. 역할을 주고 개발 스펙을 주고, 맡기는 거죠.

정보숨김(Information Hiding)이 민규쌤이 지금 CTO로서 생각하는 중요한 가치겠네요.

네, 데이비드 파르나스(David Parnas)라는 소프트웨어 엔지니어링의 아버지로 불리는 분이 계신데 그 분이 70년대 초 쓴 논문이 있어요. 거기서 정보숨김(Information Hiding)이라는 용어가 나와요. 우리는 각각 기능을 하는 코드를 모듈이라고 부르는데, 모듈이 잘 나누고, 모듈 간의 연동이 잘 되려면 모듈 간의 정보숨김이 잘 되어 있으면 된다는 것이 핵심 중 하나에요. 이 기준 하에 여러 가지 상황별로 전술적인 기교가 있지만, 저의 큰 기준은 이거 같아요.

의료IT라는 기존과 다른 방식의 솔루션 도전을 잘 할 수 있다고 생각한 이유가 있었나요?

개발자들은 모두 각자의 꿈이 있는 사람들이에요.막연히 꿈꾸는 사람도 있고, 실행계획을 구체적으로 가지고 있는 사람도 있어요. 전 막연하게 꿈꾸고 있는 사람이었는데, 구체적인 꿈의 제안이 들어왔던 거죠. 의료는 우리 일상 속에 멀리 있지 않은 영역이고, 의료 쪽으로 기회가 많다고 생각했어요. 개발자로만 의료 쪽 앱이나 솔루션을 만든다는 것은 어렵지만 의료 쪽 도메인 지식을 가진 팀원과 협업을 한다면 충분히 가능해요. 메디블록은 공동대표 두 명 모두 의료인이고, 저희 팀원 중에 의료 도메인 지식을 가진 분들이 있어요. 같이 협업을 하는 거죠.

그리고 우리가 가는 곳은 기회의 땅인 것 같아요. 솔직히 말하면 개발자들에게 의료 쪽이라고 하면 개발 환경이 낙후되어 있다고 생각하기 때문에 의료 쪽 개발 경험을 갖고 싶지 않을 수도 있어요. 그런데 지금 의료 쪽이 바뀌고 있어요. 비슷한 환경을 예를 들어 보면, ‘은행 앱 개발한다’고 하면 좋아하지 않을 개발자가 과거에 많이 있었을 거에요. 그런데 요즘 ‘카카오뱅크에서 개발자를 채용한다’라면 카카오뱅크도 은행 앱임에도 불구하고 다들 너나 나나 지원을 해요. 저는 지금 의료 쪽도 환경이 그렇게 바뀌고 있고 메디블록이 만들어나가는 방향도 비슷하다고 생각해요. 기존 도메인의 의료플레이어와는 다르게 좋은 개발문화를 가지고 진행하고 있고, 여기서 더 인지도를 쌓고 저희 제품을 사용해보면 인식이 많이 바뀔 것 같아요.

저는 메디블록의 비전을 믿고 그 성공을 확신하고 있어요. 하면 할수록 뭘 하면 성공할 것 같다는 것이 눈에 보여요. 저는 존버를 한다면 메디블록의 비전 정도는 가져야 한다고 생각해요.

우리는 어떤 일하는 방식을 가지고 있나요?

지금 일하는 방식은 2-3주에 한 번씩 앞으로 진행할 업무를 의논해요. 스프린트(Sprint) 회의도 있고, 데일리 스크럼(Daily scrum)도 진행하고 있어요. 데일리 스크럼을 하는 이유는 개발을 하다보면 자잘하게 함께 결정 해야하는 순간도 있고, trade off 를 해야하는 경우도 있기 때문에, 현 시점에 맞는 적절한 스펙을 결정하기 위함이에요. 개발이 되고 나면 코드리뷰를 하는데 많은 분들이 코멘트를 하지만 기본적으로 1명의 리뷰어를 정해서 돌아가면서 리뷰하는 방식을 채택하고 있어요. 코드를 서로 알게 되고, 리뷰한 코드는 메인 브랜치에 반영하기 때문에 각자 책임감을 가지고 개발할 수 있죠.

민규쌤이 생각하는 좋은 개발 문화는 어떤 것인가요?

제 생각에는 새로운 지식이 주입되고, 계속 발전을 하는 문화에요.

어떤 언어나 프레임워크를 고집하면 안 된다고 생각해요. 조금 과거로 돌아가면 PHP가 누구나 사용하는 안전한 선택지였어요. 그리고 지금은 웹서비스를 개발하는데 자바가 안전한 선택지라고 생각하는 경우가 많아요. 하지만, 계속 이런 선택을 고집하는 회사는 새로운 지식을 주입받지 못하는 위험이 있어요. 물론 새로운 기술을 사용하는 것도 리스크가 많이 있어요. 당연히 오래된 기술보다 검증받지 못했고, 각종 이슈가 많을 수 있어요. 하지만 그 리스크가 하던 방식을 고집하고 발전하지 못하는 것보다 적다고 생각해요.

특히, 메디블록 개발팀은 새로운 어떤 것에 대한 관심이 대부분 많아요. 막무가내로 온갖 새로운 기술을 도입할 수는 없지만 새로 떠오르는 어떤 것이 있다면, 계속 검토하고 개발에 도입도 하고 있어요. 물론 새로운 기술을 사용하는 것은 리스크가 있지만, 이건 팀에 개발지식을 주입해 고인물이 되지 않는 방법이고, 발전에 중요한 역할을 한다고 생각해요. 요즘 잘 나가는 스타트업은 이런 문화를 많이 가지고 있을 것 같아요.

민규쌤은 어떤 동료를 찾는지 가능한 구체적으로 말씀해주세요.

시니어라면 겸손함이 중요한 것 같아요. 겸손함을 가지면 열린 마인드를 가질 수 있을 것 같고, 새로운 개발지식에 관심을 많이 가지게 되는 것 같아요. 또, 지속가능한 제품을 만들기 위한 자신만의 훌륭한 기준이 있으면 좋을 것 같아요. 아까 말씀드렸던 정보숨김과 비슷한데, 개발 스펙을 명확하게 정리하고, 결과물을 잘 검증할 수 있는 체계를 갖추는 역량을 가진 분과 함께하고 싶어요.

주니어라면 개발 지식을 계속 쌓는 자세를 가지는 것이 가장 중요한 것 같아요. 그리고 손들기를 잘하는 분이 좋을 것 같아요(웃음). 손들기가 진짜 중요한데 ‘하나하나 알려줘’라기 보다 시니어가 필요한 순간에 손을 딱 드는 분이 있어요. 개발을 잘하는 분들이 손들기를 잘 하시더라구요.

그리고 요즘 드는 생각은 우리 팀으로 온다면 존버를 잘 하면 좋겠어요. 제가 생각하는 존버는 저희 팀의 비전을 믿고 묵묵히 버티는 꾸준함이에요. 개발 하다보면 모호한 순간들이 찾아올 때가 있어요. 그 때 저희 팀의 비전을 믿는 꾸준함이 있었으면 좋겠어요. 메디블록은 그렇게 할 만한 비전이 정말 있거든요.

앞으로 이 글을 보게될 개발자 분들에게 메디블록 개발팀 어필 한 번 부탁드릴게요.

메디블록은 좋은 개발자가 많이 있다는 것이 자랑이에요. 그리고 함께 일하는 다른 쌤들도 실력으로나 사람으로나 우수하신 분들과 함께하고 있어요. 저희가 서로를 쌤으로 부르면서 존중하고, 수평적으로 소통하죠. 각자의 역량이 훌륭하기 때문에 서로 자극을 주고 받는 건강한 팀이에요. 메디블록은 좋은 쌤들과 함께 성장하고 발전하고 있어요. 앞으로 함께 하시는 분들도 저희와 같이 성장하면 좋겠어요.