시니어 개발자가 말하는 나만의 원칙, 10월 COMMIT 현장 스케치

지난 10월 19일, 구름 COMMIT이 열렸습니다. 구름 세미나에서 구름 COMMIT으로 새롭게 브랜딩한 후 처음 열린 행사였는데요. ‘시니어 개발자가 말하는 나만의 원칙’을 주제로 3분의 시니어를 한 자리에 모셨습니다.

마켓컬리 박성철 시니어 리더와 코드스쿼드 김정 CEO, 그리고 몰로코 박종천 헤드 오브 솔루션스 아키텍처가 연사로 참여해 이야기를 들려주셨어요. 오랜 시간 업계에서 성장을 거듭해 온 분들이죠. 덕분에 많은 분이 관심을 갖고 자리해 주셨습니다. 준비한 자리가 모자랄 만큼 많은 주니어와 시니어가 모였던 10월 COMMIT 현장을 공유합니다.

🎤 이 아티클은 박성철, 김정, 박종천 님의 10월 COMMIT 강의 내용을 바탕으로 재구성되었습니다.

Session 1. 개발을 통한 자기 발견 – 박성철

은둔기 – 직업 선택

저는 중학교 2학년 때부터 프로그래밍을 시작했습니다. 80년대 초반 정도겠네요. 개인용 컴퓨터(Personal Computer)가 처음 나왔던 PC 혁명기였습니다. 사회적으로 PC에 관심이 모이던 분위기였어요.

저도 그때 컴퓨터에 관심이 생겼습니다. 컴퓨터를 실제로 본 적은 없지만, 친구들을 만나도 컴퓨터 이야기만 했어요. 미래나 직업에 대한 별다른 고민 없이 컴퓨터와 놀던 시기였습니다. 나중에 게임을 만들고 싶다는 정도의 생각만 갖고 있었어요.

대학에서는 토목 공학을 전공했어요. 건설·토건 호황기에 대학을 다녔거든요. 토목 공학을 전공하면 취업이 100% 보장되던 때였습니다. 컴퓨터는 대학에서 더 공부할 필요가 없다고 생각했어요. 즐거운 취미일 뿐 직업으로 생각해 본 적이 없기도 하고요. 무엇보다 그 당시에는 소프트웨어 산업이 없었습니다. 컴퓨터를 직업으로 삼으려면 창업해야 했죠.

그럼에도 저는 컴퓨터를 직업으로 선택했습니다. 전공인 토목 공학과 취미인 컴퓨터 사이에서 진로를 고민하던 중 군대에 가게 됐는데요. 혼자 컴퓨터만 만지다가 뒤늦게 다른 사람과 엮여서 살 수 있다는 걸 처음 느끼게 됐습니다. 뒤늦게 사회성이 만들어진 거죠. 입대 전에는 3명 이상 모이는 곳에는 안 갔거든요.

비슷한 시기에 행주대교가 붕괴되는 사고가 발생하기도 했습니다. 제가 설계하고 지은 건축물이 무너졌을 때를 상상하니 건축은 못 하겠더라고요. 결국 지금까진 나만을 위한 취미로 생각한 컴퓨터도 쓸모 있는 소프트웨어를 만들어 다른 사람들에게 도움이 된다면 프로그래머도 어엿한 직업이 될 수 있겠다는 생각이 들었습니다.

사회 적응기 – 첫 번째 실패

막 대학을 졸업하고 취업할 때 저는 제가 컴퓨터를 잘하는 줄 알았습니다. 첫 회사는 저와 사장님만 있는 곳이었는데 그 분께 엔지니어링 스킬을 많이 배웠어요. 시킨 일만 하는 게 아니라 일을 만들어내는 관점을 배울 수 있었습니다.

어느 날 사장님이 ‘너는 아직 전문가가 아니야’라고 하셨는데, 그 말이 뇌리에 박혀서 혼자 고민에 빠졌죠. 아직 개발 능력이 부족하다는 뜻으로 판단해 저만의 성장 공식을 만들었습니다.

쓸모 있음
= 역량
= 개발 역량 + 일반 역량

첫 회사에서 개발하던 제품들은 기대치는 높은데 쓸모가 없었습니다. 이미지 데이터베이스, CD 버너, JPEG 디코더 등 다양한 제품을 만들었는데 쓰는 사람이 없었어요. 거기서 오는 괴리감이 있었죠. 마침 인터넷이 보급되면서 새로운 기회들이 많이 생기는 시기였고, 많은 사람에게 영향을 미칠 만한 기술은 인터넷이라는 생각이 들어 회사를 나왔습니다.

테라포밍 – 두 번째 실패

인터넷은 폭발적으로 성장했습니다. 가능성 있는 분야라고 생각했지만, 사회적으로 준비가 부족했어요. 직접 환경을 만들어가야겠다고 결심했죠. 일종의 테라포밍*이었습니다.

* 지구 외 다른 행성에 인간이 살 수 있도록 환경과 생태계를 구축하는 작업을 말한다.

두 번의 창업을 통해 다양한 웹 서비스를 만들었습니다. 소프트웨어 개발 컨설팅도 진행했고요. 사장이 되고 나니 직원을 동기 부여하는 게 무엇보다 중요했습니다. 그래서 성장 공식을 바꿨어요.

쓸모 있음
= 역량 X 동기

역량은 일종의 가능성입니다. 가능성이 효과를 내려면 동기가 있어야 하죠. 7:3 원칙을 만들어 동기를 관리하기 시작했습니다. 프로젝트를 진행할 때 고객이 원하는 걸 7, 제가 하고 싶은 걸 3의 비중으로 섞었습니다. 이렇게 관리하니 저도 즐거우면서 고객이 원하는 일도 하고 있다는 느낌이 들더라고요.

일이 즐거울 수 있다는 걸 알게 됐습니다. 생각보다 개발자가 일을 통해 얻는 게 많더라고요. 지식, 즐거움, 성과, 기술 등인데요. 개발자는 과정을 통해 비금전적 보상을 얻는 사람이라는 생각이 들었습니다.

피터 드러커가 쓴 ‘프로페셔널의 조건’에 이런 말이 나옵니다. 지식 근로자는 스스로 성과의 방향을 설정해야 하기 때문에, 자신에게 어떤 성과가 기대되고 있는지 그리고 자신에게 그러한 성과가 기대되고 있는 이유가 무엇인지를 이해하지 않으면 안 된다. 이 책을 읽고 아래 그래프도 만들었어요.

A는 제가 한 일, B는 저에게 기대하는 성과를 의미합니다. 제가 인정받을 수 있는 성과는 A와 B의 내적 코스 라인뿐이죠. 저 각도를 줄여야 제가 한 일을 온전히 인정받을 수 있게 됩니다. 여기서 공식을 한 번 더 바꿨습니다.

쓸모 있음
= 역량 X 동기 X 방향

방향은 곧 고객인데요. 항상 고객의 입장에서 생각하려고 노력했습니다. 고객의 니즈가 숨어 있을 때는 발굴하려고 했고요. 계속해서 피드백을 받을 수 있는 방법을 찾아 방향을 맞추려고 했습니다. 개발 방식도 바꾸었어요. 이전에는 한 번에 잘 만드는 데 초점을 맞추었다면, 빨리 만들어서 고객이 경험하게 한 후 개선해 나갔죠.

테크 리드의 길

공식도 세우고 그래프도 만들면서 열심히 했는데 결국 운영하던 회사가 망했습니다. 곰곰이 생각해 보니 저는 사업을 하면 안 되는 사람이었어요. 사업을 하는 사람은 서비스나 재화로 돈을 벌 방법을 고민해야 하는데, 저는 개발을 잘하고 싶어서 사업을 시작했거든요. 사업자는 아닌 거죠.

이 시기에 아이폰이 출시되면서 개발자를 필요로 하는 분위기가 형성됐습니다. 기회를 잘 잡으면 개발자도 전문가로 인정받을 수 있다고 생각했어요. 그때부터 블로그, SNS, 커뮤니티 활동을 시작했습니다. 일종의 연대를 만들어 나간 거죠. 같은 생각을 가진 분들과 교류하면서 우리 업이 인정받을 수 있는 방법을 찾아보게 됐습니다. 좋은 팀을 만드는 데 관심을 갖게 됐어요.

쓸모 있음
= 역량 X 동기 X 방향 X 환경

소프트웨어 개발자가 전문가로 인정받고 있느냐고 묻는다면 아니라고 생각합니다. 개발자도 온전히 맡은 바 역할을 하고 있지 않은 것 같고요. 개발자 붐이 한창이지만 영원한 건 없습니다. 따뜻한 물에 안주한다면 도태될 거예요.

발표 주제가 ‘자기 발견’이죠. 매슬로의 욕구단계설 피라미드에는 1가지 문제가 있습니다. 최상위에 있는 ‘자아실현’은 다른 욕구가 모두 충족돼야 채울 수 있는 고급 욕구라는 착각을 불러일으킨다는 점인데요.

위 그래프처럼 5가지 욕구는 어느 단계에서든 발생합니다. 특히 나 자신을 만들어 가려는 욕구는 본능적인 거예요. 나를 알아가는 과정을 게을리하지 않으셨으면 좋겠습니다.

지금까지 저를 찾아 떠났던 여정을 전해드렸는데요. 여러분도 하루빨리 각자의 답을 찾아 떠나보시길 바랍니다.

Session 2. 메이저 버전을 업그레이드하는 나의 마이너 원칙들 – 김정

version 0.1.0
두리번거리면서 속력과 방향을 자주 확인하기

저도 PC와 소프트웨어 산업이 성장하던 초등학생 때 프로그래밍을 시작했습니다. 대학에서는 프로그래밍을 전공하지 않았지만, 프로그래밍 언어를 다룰 줄 아니 재미있는 프로젝트를 많이 했죠. 그러다 회사에 들어갔더니 마치 정글 같았습니다. 누군가 저를 키워주는 게 아니라 제 성장은 제가 챙겨야 하더라고요.

회사에서 일하면서 저는 굉장히 잘하고 있다고 생각했는데, 알고 보니 아는 것만 알고 모르는 건 모르고 있었습니다. 혹은 알고 있기만 한 걸 잘한다고 착각하기도 했고요. 일 외적으로 무언가를 더 해야겠다고 결심했습니다.

블로그가 없던 시절이라 ‘월간 마이크로소프트웨어’ 같은 프로그래밍 잡지를 정기 구독하면서 스크랩하기 시작했죠. 업무와 관련은 없지만 배우고 싶고, 해보고 싶은 것들을 찾아 나가는 시기였습니다.

version 0.2.0
익숙한 것을 대신해서 낯선 방식으로 해결하기

지식을 배울 때는 다양한 해답이 오고 가는 학습 환경을 만드는 게 중요합니다. 내가 알고 있는 것만이 전부가 아니기 때문인데요. 지식을 오롯이 흡수하려면 알고 있는 걸 설명할 수 있어야 하고, 다른 사람이 설명한 걸 이해할 수도 있어야 합니다. 서로의 피드백을 교환하는 과정에서 온전히 내 것으로 만들 수 있어요.

교육은 사회적입니다. 혼자 배우면 내가 잘하고 있는지, 못하고 있는지 몰라요. 누군가와 이야기를 주고받는 과정이 필요합니다. 여러분은 지금 그런 환경에서 성장하고 계신가요?

version 0.3.0
개구리를 해부하지 말고, 직접 만들기

이미 만들어진 것만 찾아보지 말고, 직접 만들어 보세요. 개구리에 비유해 볼까요? 개구리를 해부해서 어디에 어떤 장기가 있는지 보는 데서 그치면 안 됩니다. 진짜 개구리를 만들어 보세요. 그러려면 많은 걸 공부해야 합니다. 개구리가 점프하는 법, 우는 법, 사냥하는 법 등 모든 습성을 파악해야 하죠.

무엇이든 스스로 만들어 보려고 노력해보세요. 엔지니어 입장에서는 디지털 시스템을 따라 만들어 볼 수도 있고, 운영체제처럼 만들 수도 있고, AWS나 구름IDE 같은 걸 만들 수도 있겠죠.

version 0.4.0
남을 향한 자존심을 버리고
나를 향한 자존감 채우기

항상 나보다 잘하는 사람은 있기 마련입니다. 저도 학교에서는 잘한다고 생각했는데, 사회에 나오니 어딜 가나 천재가 있더라고요. 어떻게 하면 천재를 이길 수 있을지 고민했는데요. 그런 방법은 없더라고요.

3년 차 이후부터는 제 일만 했습니다. 남이 아닌 저 자신과 비교했어요. 제가 어제보다 무엇을 더 알게 됐고, 무엇을 더 잘하게 됐는지를 본 거죠.

version 0.5.0
결과를 향하면서 과정을 기록하기

우리는 결과만 보는 데 익숙해져 있습니다. 특히 시험 같은 경우는 점수에 목숨을 걸죠. 달성하지 못하면 자괴감에 빠질 때가 많고요. 그럴 필요 없습니다. 각자의 성장 과정은 다 따로 있거든요.

개발자라면 개발 과정 전체를 보면서 시야를 넓히면 좋겠습니다. 우리 팀의 일을 넘어 우리 회사의 비즈니스 전체를 이해하려고 노력해 보세요. 성장할 수 있는 포인트가 훨씬 더 많아질 겁니다.

version 0.6.1
의도한 실수를 반복하면서
작은 부분을 개선하기

반복적으로 하는 일이 있습니다. 일기 쓰기, 출퇴근하기, 주간 보고 하기, 커밋하기 등이죠. 똑같은 일을 기계적으로 하다 보면 성장이 더뎌지는 순간이 옵니다. 이때 의도적으로 개선할 부분을 찾지 않으면 성장 포인트를 잃어버릴 수 있는데요.

템플릿을 만들거나, 회고하거나, 자동화할 수 있는 부분을 찾으면서 개선해야 합니다. 여기서 개선은 반복하는 업무를 줄이는 1차원적인 개선이 아니라, 2차원적인 개선이에요.

특히 회사 생활을 하다 보면 개선할 수 있는 부분이 많습니다. 개발 환경, 업무 기록, 버전 관리, 협업 방법 혹은 코딩 스타일일 수도 있는데요. 이런 부분을 찾아내 해결하려고 노력하면 좋겠습니다.

version 0.7.0
기준을 정하기 전에 여러 답을 찾아서 공유하기

일을 하다 보면 이분법적으로 생각할 때가 많은데요. 사실 0과 1 사이에는 무수한 값이 있죠. 다양한 기준에서 해답을 찾아보시길 바라요.

저는 프로그래밍을 배울 때 오픈소스를 적극적으로 활용하길 권합니다. 우리는 정답이 하나인 문제에 익숙하지만, 소프트웨어 문제는 정답이 하나만 있지 않아요. 수많은 정답 가운데 하나를 찾아서 끝냈다고 안주하지 말고, 다양한 선택지를 검토해 보세요. 다른 사람에게 과정을 공유하면 더 좋습니다. 소프트웨어 개발자들이 30년 동안 성장한 방식이기도 하거든요.

version 1.0.0
배포하기
그리고 다음 버전 준비하기

한 번 배포했다고 끝이 아닙니다. 바로 다음 버전을 준비해야죠. 끊임없이 버전을 업그레이드하면서 비슷한 고민을 가진 분들과 경험을 나눠보세요. 커뮤니티에서 활동하셔도 좋고, 회사 안에서 진행하는 작은 스터디도 좋습니다.

팔로알토 연구소에 계셨던 앨런 케이 박사님이 하신 이야기인데요. The music isn’t in the piano. 아름다운 음악은 피아노가 아니라, 연주하는 사람에게 달려 있습니다. 여러분도 컴퓨터를 도구 삼아 자신만의 곡을 연주하길 바랍니다.

Session 3. 목표와 문제를 바라보는 나의 기준, GPAM 원칙 – 박종천

어떻게 하면 일을 더 잘할 수 있을까?

사회 초년생일 때는 일에만 집중했다면 시니어가 되니 강연, 코칭, 커뮤니티 활동을 하며 다른 분을 돕는 데 집중하게 됐는데요. 특히 ‘목표’에 대한 고민을 많이 했습니다.

왜 우리는 작심 3일을 극복하지 못할까요? 목표가 흐지부지되는 이유는 계획이 없기 때문입니다. 살을 빼고 싶다는 목표를 세웠으면 매일 4시간씩 걷겠다는 구체적인 계획이 필요하죠.

계획을 세운 다음 액션까지 가기는 더욱 어렵습니다. 한 조사 결과에 따르면 전체 인류 중 80%만 목표를 세우고, 그중 30%만 계획을 세운다고 해요. 실천하는 건 10% 남짓이고요.

실천까지 해도 종종 실패합니다. 주사위를 굴린다고 해볼까요? 주사위를 굴려서 한 번에 6이 나오긴 힘들죠. 그러면 6이 나올 때까지 반복해야 하는데요. Goal – Plan – Action – Measure도 한 번 하고 끝이 아닙니다. 회고를 통해 개선해 나가면서 반복해야 해요.

계획이 가능한 목표
실행이 가능한 계획
측정이 가능한 행동
다음이 가능한 측정
다시 반복

저는 GPAM(Goal, Plan, Action, Measure)이라는 프레임워크를 만들어 활용하고 있습니다. 15년 정도 됐는데요.

각 항목은 유기적으로 돌아갑니다. 가장 먼저 목표는 계획을 세울 수 있어야 해요. ‘행복하자’나 ‘훌륭한 사람이 되자’는 목표는 두루뭉술합니다. 모든 목표는 작게 쪼갤 수 있어요. 목표를 세울 때는 S.M.A.R.T를 참고하면 좋겠습니다.

• Specific : 구체적인
• Measurable : 측정할 수 있는
• Assignable : 책임자가 분명한
• Realistic : 현실적인
• Time-related : 기간이 명확한

계획은 실행할 수 있어야 해요. 살을 빼려고 하루에 20km씩 걷는 건 불가능합니다. 실천할 수 없는 계획은 의미가 없어요. 실천한 다음에는 측정해야 합니다. 20km를 걷는다는 계획은 측정할 수 있지만, 많이 걷자는 계획은 측정할 수 없죠.

여러분이 세운 목표는 계획할 수 있는지, 계획은 실천할 수 있는지, 실천한 다음에는 측정할 수 있는지 생각해 보세요.

우리가 원하는 큰 그림에 도달하려면 목표는 작을수록 좋습니다. 10kg를 빼겠다는 목표보다 일주일에 500g을 감량하는 게 현실적이죠. 목표는 작게 세우고 계획도 쉽게 세울 수 있어야 합니다. 목표와 계획이 아무리 쉬워도 실행할 수 없다면 의미가 없어요. 살을 빼려고 하루에 3km씩 걷겠다는 계획을 세웠는데, 일이 너무 바빠 걸을 수 없다면 목표와 계획이 다 어그러집니다. 가장 중요한 건 실천이에요.

일반적으로 개발은 아래 순서로 진행하는데요. GPAM 프레임워크와 같습니다.

1. 요구사항 분석하기(Goal)
2. 시스템 구조 설계하기(Plan)
3. 구현하기(Action)
4. 테스트하고 출시하기(Measure)
5. 피드백으로 업데이트하기(Measure)

좀 더 어려운 주제에 적용해 볼게요. 많은 개발자분이 하고 계신 고민을 성장 과정 순서대로 추려봤습니다.

1. 다음에 뭘 하지?
2. 나는 성장하고 있나?
3. 신기술이 너무 많아요.
4. 한 번 창업을 해 볼까?
5. 왜 이렇게 개발 진행이 안 되지?
6. 내가 관리자 역할을 잘하고 있나?

이 중 3가지 고민을 GPAM으로 분석해 볼게요.

고민 1. 다음에 뭘 하지?

다음에 무엇을 할지 결정하는 걸 목표로 삼으면 안 됩니다. 너무 크고 뭉툭하기 때문인데요. 다음에 무엇을 할지 결정하려면 현재 상황을 파악해야겠죠. 지금 나는 어떤 상황인지 파악하는 걸 목표로 잡아볼게요.

이런 계획을 세워볼 수 있습니다. 지금 하고 있는 일, 새로운 일이나 직군, 새로운 회사를 분석해보는 거죠. 주변에 어떤 옵션이 있는지 정보를 수집해 보는 겁니다.

정보를 모은 다음에는 분석 결과를 논의하는 단계를 거쳐야죠. 믿을 만한 지인과 결과를 함께 이야기해 보면 좋습니다. 일종의 피드백을 받아보는 거예요.

• Goal : 현재 상황 파악
• Plan : 지금 일, 새로운 일/직군, 새로운 회사 분석
• Action
• Measure : 분석 결과에 대한 논의

고민 2. 창업을 해볼까?

목표는 간단한 제품 기획서를 써보는 게 될 수 있을 것 같습니다.

계획은 내가 만들고 싶은 제품이 무엇인지, 경쟁자는 누구인지, 그리고 경쟁자는 어떤 상황인지 등을 적어보는 게 되겠죠. 제품 기획서는 사업 기획서가 아닙니다. 내가 만들고 싶은 제품으로 매출이 얼마나 나올지, 직원은 몇 명이나 채용할 수 있을지 등 전망은 고려할 필요가 없어요.

일주일 정도 제품 기획서를 써보고 발표해 보세요. 믿을 만한 지인을 10명 정도 모아서 피드백을 들어보는 단계가 필요합니다.

• Goal : 제품기획서
• Plan : 제품기획, 경쟁자상황, 그리고 역량여부
• Action
• Measure : 발표와 피드백

고민 3. 관리자 역할을 잘 하고 있나?

일단 좋은 관리자가 무엇인지 확인하는 걸 목표로 삼아야 해요.

그러려면 면담을 통해 구성원들 간의 차이를 확인해야 합니다. 구성원들이 원하는 관리자, 행복, 성장은 무엇인지 알아보는 거죠.

수집한 의견을 모아서 나름대로 분석해 보세요. 구성원들의 니즈를 당장 해결해 줄 수는 없지만, 듣는 것만으로 그들이 원하는 미래와 제가 생각하는 미래를 얼라인할 수 있습니다.

• Goal : 좋은 관리자란 무엇인가 확인
• Plan : 면담에서 차이확인(행복, 성과, 성장)
• Action
• Measure : 적용가능한 데이터 수집

모든 걸 목표, 계획, 실행, 측정할 필요는 없습니다

모든 목표의 계획을 세우거나, 목표를 세운 다음 바로 계획하지 않아도 괜찮습니다. 실행까지 했는데 아닌 것 같다는 생각이 들 때도 과감하게 측정하지 말고 버리세요.

GPAM을 순서대로 다 따르지 않아도 됩니다. 눈앞에 있는 모든 산을 GPAM으로 풀지 마시고, 오늘 하루 혹은 한 달 중 제일 중요하다고 생각하는 몇 가지만 시도해 보세요. 1~2개만 고민해보셔도 재미있는 결과가 나올 거예요.

우리는 목표를 달성하면 행복한 삶을 살 수 있다고 믿습니다. 1년 내내 고민만 하는 건 의미가 없어요. 한 번만 이렇게 정리해 보시면 다음 그림을 수월하게 그릴 수 있습니다. 삶, 개발, 연애 등 다양한 분야에 GPAM을 적용해 보세요.

세미나가 끝나고 들려온 소식 하나, 강사님들의 이야기는 12월 중 골든래빗에서 「개발자 원칙」으로 출간됩니다. 신간과 다음 COMMIT 모두 많은 기대 부탁드립니다.