개발자 원칙

 

‘시니어 개발자' 라고 불리는 사람들의 ‘업(業)’에 관한 이야기.
개발자 커리어에서 겪을 수 있는 현실적인 고민을 볼 수 있다. 엔지니어와 서비스개발자 사이에서 균형잡기, 코드 매니징에서 휴먼 매니징으로 확장하기, 자신에게 잘 맞았던 성장방법 찾기
개발자 임원면접 준비하는 취준생이라면 읽어볼 만 하다. 임원면접의 면접관으로 들어갈 만한 경력과 위치에 있는 사람들의 생각이기 때문.

 

주니어 개발자 입장에서 재미있게 읽었다. ‘시니어 개발자'라는 키워드로 묶여 있지만, 각각 마주한 문제와 해결하기 위한 논리적 사고의 출발점이 달랐기 때문이다. 각 챕터에 할당된 9명의 인터뷰이 성향이나 특색도 글에 그대로 반영돼 있어서 읽는 맛이 있었다. 예컨대 첫 장의 박성철 님과 마지막장의 박동수 님의 글은 같은 책이라는 생각이 들지 않을 정도로 글 톤이 다르다.

9명의 인터뷰이가 다루는 화제가 다르지만, 몇 가지 키워드로 책의 내용을 요약한다면 아래와 같이 나눌 수 있을 것 같다.

자신만의 성장방법

강대명 님: 가장 크게 성장할 수 있는 순간은 ‘오류를 만났을 때' 라고 생각한다. 오류를 만나면, 소스 코드 레벨까지 들어가서 원인을 확인해보자. 보통 서비스 운영에서 발생하는 에러는 스택오버플로우에서 검색하면 해결할 수 있긴 하지만, 거기서 멈추면 지식을 얻지 못한다. 소스코드까지 들어가서 탐구할수록 깊이있는 지식을 얻을 수 있다.

그렇게 배운 지식은 글로 공개하고 결과를 남겨보자. 타인의 조언을 듣고 더 성장할 수 있다.

 

박미정 님: 이직도 적당한 순간에 사용하면 훌륭한 성장 방법이다. 주니어라면 업무 자체에서, 회사 내부에서 기술교류를 통해 성장하는 게 보통 효율이 높다. 몰입해서 업무해야 문제를 해결할 수 있는 시기이며, 회사 내부 문제는 동료들과 풀어내는 것이 제일 효과적이기 때문이다. 기존 환경에서 변화를 먼저 모색해보고, 그게 어렵다면 책임감 있는 모습으로 다음 스텝을 밟자.

 

 

---

이 부분은 사실 정답이 없다. 테크 컨퍼런스에 참석하는 것도, 오픈소스 프로덕트에 기웃거리는 것도, 강의를 듣고 책을 보고 사이드 프로젝트를 해보는 것도, 이직처럼 환경을 바꾸는 것도 다 성장 방법이라고 생각한다. 이 부분만큼은 소위 ‘최선의 방법' - 시간대비 가장 효율이 좋은 방법 - 을 찾겠다며 시도는 안 해보고 밍기적대는 것만 피하면 된다고 생각하기 때문. 뭐든 해보고, 자신에게 맞는 것 같지 않을 때 다른 사람은 어떻게 했는지 둘러보면 된다.

자신의 개발 / 인생 원칙

박종천 님: SW Develop LifeCycle을 인생에서도 범용적으로 적용 할 만하다. 소프트웨어 개발 방법의 키워드를 인생에 맞게 수정한 GRAM 프레임워크를 제안한다 - Goal을 정하고, Plan을 세운 뒤, Action 수행하고, Measure 기록한다 (목표를 정하고 계획을 세운 뒤 실행하고 기록한다).

여기서 제일 중요한 건 ‘목표를 잘 세우는 것'인데, 좋은 목표를 정하기 위한 원칙으로 다섯 가지 키워드를 소개한다. 구체적으로(Specific) / 측정 가능하도록 (Measurable) / 실행 가능한 것으로 (Actionable) / 현실적인 수준의 (Realistic) / 기한을 정해서 (Time-Related). 

 

이동욱(향로) 님: ‘제어할 수 없는 것에 의존하지 않기'. <실용주의 소프트웨어> 에서 제안하는 개발원칙 중 하나인데, 외부의 변화에 휘둘리지 않을 수 있는 방법론을 개발 외적으로도 적용할 수 있었다. 시리즈A 이하 스타트업으로 이직하려 할 때에도, 통제할 수 없는 외부변수인 ‘투자시장의 분위기' 때문에 서비스 개발 일정이나 계획이 영향을 받지 않을 수 있는 곳을 기준으로 삼았다. 유니콘이라는 평가를 받으며 투자금으로 급성장하는 회사보다는 자생적으로 매출을 내고 있는 회사가 기준에 부합했고, 결과적으로 선택한 회사는 투자시장이 얼어붙은 현 시점에서도 서비스의 로드맵은 크게 바뀌지 않았다.

규모가 작은 스타트업의 관리직으로 이직한 후, 조직 매니징에도 ‘제어할 수 없는 것'과 ‘제어할 수 있는 것'을 철저히 구분한 뒤 ‘제어할 수 있는 것'에 집중하고 있다. 어떤 상황에서도 앞으로 나아갈 수 있는 방법이라고 생각하기에, 단순한 소프트웨어 개발이 아니라 인생에서 마주할 문제 해결 원칙으로 적용하고 있다.

---

소프트웨어 개발방법론을 인생에도 적용한 예시를 설명하는 모습이야말로 퍽 개발자스럽다고 해야 할까.. 이 책의 아이덴티티로 정의할 수 있을 만큼 재미있는 접근이었다. 특히 이 부분은 컴퓨터 바깥에서 일어나는 문제 - 예컨대 코드로 구성된 프로그램이 아니라 사람으로 구성된 조직 매니징하기 - 를 시니어 개발자가 어떤 사고 흐름으로 해결하는지를 볼 수 있었다. 자신에게 익숙한 프로그래밍 지식과 원칙을 가지고, 익숙하지 않은 상황에 적용하는 사례로 재미있게 읽었다.

 

---

좋은 프로덕트를 개발하려면?

이동욱(네피림) 님: 코드를 잘 짜는 게 목표가 아니라, ‘좋은 프로덕트를 만드는 것'을 목표로 삼자. 예컨대 Spring Framework를 배우는 걸 목표로 삼는 대신 API 서버를 Spring Framework로 만드는 걸 목표로 정해보자. 프로덕트인 ‘API 서버'를 구체화하다 보면 처음 목표를 세울 때 고려하지 못했던 것 - 설계 시점에서 생각 못했던 결함이라거나, 배워야 할 것들 - 을 마주하게 된다.

목표를 정했으면, 한 번에 완성할 생각하지 말고 반복적으로 완성해가자. 짧은 주기로 결과물을 만들고 개선하는 작업을 반복할수록 좋은 프로덕트가 되어간다. 빨리 완성하고 싶은 욕심에 반복작업 없이 많은 코드를 한번에 작성할 수도 있지만, ‘좋은 소프트웨어' 관점에서는 이 방법이 오히려 개발속도를 늦춰버린다. 

반복적으로 완성해가는 작업은 크게 두 가지 장점이 있다. 하나는 ‘프로젝트가 변화해야 할 때 좀더 유연하게 대응 가능하다'는 것, 다른 하나는 ‘프로덕트의 완성도를 좌우하는 디테일을 손볼 기회가 생긴다'는 것. 특히 ‘디테일'은 프로덕트가 지향해야 할 가치와 목표가 명확할 때 비로소 개발자의 눈에 띄는데, 개발팀이 반복적으로 프로덕트를 완성해가며 가치와 목표를 달성하고 컨센서스로 자리잡았을 때 비로소 손댈 수 있는 부분이기 때문. “빠르게 시도하고 실패한다"는 개발 방법에서 간과할 수 있는 부분인데, ‘빠르게’가 목적이 되어버리면 기능구현만 완성하고 디테일을 손보기 어렵기 때문. 빨리 만든 프로덕트가 반드시 ‘좋은 프로덕트'인 건 아니다.

공용준 님: 좋은 코드를 만들기 위한 원칙, 훌륭한 객체지향 프로그래밍 원칙을 준수한다고 ‘좋은 프로덕트'가 완성되는 게 아니다. 원칙은 잘 지켰는데 결과물로 나온 프로덕트는 엉망일 수 있기 때문이다. 일반적인 공학에서는 제대로 된 설계도가 있으면 어디에서든 같은 제품을 만들 수 있지만, 소프트웨어 프로덕트는 아직 설계나 제작도구의 표준이 없다. 2000년대 즈음에 소프트웨어 프로덕트의 디자인 도구로 UML이 이 역할을 해줄 거라 기대했지만 실패했고, 반대급부로 ‘제약없이 자유롭게 만들면 된다', ‘코드만 잘 짜면 된다'는 주장이 통하면저 지금까지도 코드 단위의 ‘DRY / KISS’ 원칙이나 객체지향의 ‘SOLID’ 원칙 정도만 통용되고 있다. 좋은 프로덕트를 만드려면 좋은 설계도, 즉 ‘디자인(설계) 원칙'이 필요하다. 

이후 명시적 설계항목 / 암묵적 설계항목에는 어떤 것들이 있고, 무엇을 고려해야 하는지 설명하는 데 지면을 할애한다.

 

---

내가 취준생이었다면 이 부분을 전략적으로 읽었을 것 같다. 개발자 임원면접에서 마주하게 될 사람들이 대개 이 정도 경력과 위치에 있게 될 텐데, 이 위치에 있는 사람의 관심사가 바로 ‘좋은 프로덕트'일 거라 생각하기 때문이다. 이걸 읽고 임원면접에서 지식을 뽐내라는 게 아니라, ‘좋은 프로덕트란 무엇인가’, ‘어떻게 해야 좋은 프로덕트를 만들 수 있는가’ 라는 고민을 스스로 해보고 나름의 논리를 생각해보는 것이다. 

‘좋은 프로덕트’는 돈을 잘 벌어다주는 프로덕트일 수도 있고, 디자인적으로 아름다운 프로덕트일 수도 있고, 유지보수가 쉬운 프로덕트일 수도 있다. 이걸 스스로 고민해서 나름의 기준을 설명할 수 있고, 자신이 생각한 ‘좋은 프로덕트'를 만들기 위해 무엇을 해왔는지 신입면접의 면접관으로 들어온 임원 앞에서 설명할 수 있다면? 면접관이 생각한 ‘좋은 프로덕트' 개념과 정면으로 충돌하는 수준만 아니면 (소위 ‘컬쳐 핏'이 안 맞다는 사유로) 탈락사유가 되진 않을 거라 생각한다.

 

 

개발자 원칙

“나도 테크 리더가 될 수 있을까? 어떻게 선배 개발자들처럼 성장할 수 있을까? 3년 10년 후에도 개발자로 살아갈 수 있을까? 팀워크는 도대체 어떻게 맞춰야 하는 걸까?” 개발자로 살아가면서 하루에도 천 번을 되묻는 물음에 컬리, 레몬트리, 카카오, 코드스쿼드, 무신사, 몰로코, 데이블, 인프런, 패스트캠퍼스 테크 리더 9명이 답합니다. 지금까지 만나 볼 수 없었던 생존과 성장의 원칙에서 자신만의 해답을 찾아보세요.

저자

박성철, 강대명, 공용준, 김정, 박미정, 박종천

출판

골든래빗(주)

출판일

2022.12.20