현업에서 PM이라는 용어를 많이 쓰는데요, PM에는 두 가지 뜻이 있습니다. 프로젝트 매니저(Project Manager)와 프로덕트 매니저(Product Manager)입니다. 프로덕트 매니저를 프로덕트 오너(Product Owner, PO)라고도 부릅니다. 혼란을 막고자 제품의 총책임자를 PO, 프로젝트 책임자를 PM으로 부르며 설명하겠습니다.
PM은 제품에 대해서도 신경을 쓰고 관리하기 때문에 PO 역할을 겸하기는 합니다. 이 두 직책의 차이는 회사마다 다르기 때문에 명확하게 정의하기가 쉽지 않습니다. 단적으로 이야기하면 PO는 제품만 신경쓰고, PM은 개발해서 출시하는 전체 일정과 리소스를 관리합니다. 참고로 우리나라 기업은 대개 프로젝트 매니저와 프로덕트 매니저를 한 사람이 맡아서 진행합니다. 미국 기업은 회사 규모가 작으면 한 사람에게 다 맡기지만 커지면 분리합니다. 지금부터 다룰 프로젝트 리드는 PO 역할도 하지만 전반적으로는 PM 쪽에 더 집중하는 역할이라고 보면 됩니다.
프로젝트 리드는 기술을 제외한 모든 것을 챙겨야 합니다. 개발 계획을 세우고 나면 부족한 인력과 다가오는 출시 일자와 구현할 수많은 기능을 두고 저글링합니다. 다양한 역할의 사람과 소통하며 교통정리를 하면서도 중요하지 않은 일에 시간을 쓰지 않도록 시간 관리에 신경을 써야 합니다. 지속적으로 생기는 다양한 문제를 관리하며 중요한 일에 리소스가 투입되도록 우선순위도 관리합니다.
• 《Debugging the Development Process》 •
《Debugging the Development Process》라는 책이 있습니다. 우리나라에 《프로그램 개발의 비결》이라는 제목으로 번역되기도 했는데요, 원서 제목을 직역하면 ‘개발 과정을 디버깅하자’입니다. 제목에서 유추할 수 있듯이 개발 과정 자체를 계속 살펴보면서 개선해야 좋은 제품을 만들 수 있다는 메시지를 던져주는 책입니다. 프로젝트 리드라면 제품과 코드뿐만 아니라 개발 과정 전체를 다 신경 써야 한다는 이야기입니다. 이제 이런 개발 과정에서 벌어지는, 그래서 프로젝트 리드가 챙겨야 하는 일들을 살펴봅시다.
1. 개발 계획 세우기
개발 주기는 요구사항을 분석하고, 시스템 구조를 설계하고, 개발하고, 테스트와 출시하고, 피드백을 받아서 업데이트하는 전체 과정입니다. 언제까지 기획하고, 무엇을 개발할지, 아키텍처는 언제 설계하는지 계획을 마련해야 합니다. 1년 치가 어렵다면 6개월이든 1개월이든 최소한의 개발 계획이 있어야 합니다. 계획 안에서 실행해야 리소스가 관리됩니다. 일정이 있어야 일정에 맞춰서 일을 끝내는 데 필요한 채용 규모와 시기를 정할 수 있습니다. 개발과 계획 모두 PM의 소관입니다. PM은 전체 과정을 이해하고 목표를 이해하고 리소스를 관리해야 합니다. PO를 포함한 사람들이 그림 안에서 소통할 수 있도록 도움을 줘야 하고 스스로도 소통을 해야 합니다. 프로젝트 관리도 하고, 연 단위, 월 단위 계획, 일 단위 계획을 세워야 합니다.
계획을 세우는 것도 중요하지만 준수하는 것도 중요합니다. “작전계획을 세우는 것은 누구나 할 수 있다. 그러나 전쟁을 할 수 있는 사람은 적다. “ 나폴레옹 말입니다. 계획을 세우고 실천해야 의미가 있습니다.
계획을 세우는 이유는 완벽하게 준수하기 위해서가 아닙니다. 성공을 위해 세우는 겁니다. 그러므로 계획을 세워두고 상황에 맞게 수정하고 대비해야 합니다. 계획을 세우고 3일만 지나도 상황은 바뀝니다. 그럼 다시 계획을 세워야 합니다. 원래부터 계획은 세우고 고치고 다시 세우고 고치기를 반복해야 하는 겁니다. 작심삼일이면 어떻습니까? 3일마다 계획을 세워 3일 동안 실행하면 되지 않습니까? PM은 계획을 세워서 전체 그림을 정리하고 시장, 개발, 제품에 맞춰서 계획을 업데이트해야 합니다. 쉽지 않은 일입니다. 하지만 이렇게 정리하는 사람이 있어야 프로젝트가 안정적으로 진행됩니다. PM은 시간, 인원, 비용이라는 제약을 고려해서 개발 범위를 설정해야 합니다.
블리자드 채용 면접에서 필수 질문이 있습니다. “시간과 품질 중 무엇을 선택할 건가요?” 10월 말까지 제품을 출시하기로 했다고 가정합시다. 이 일정은 시장 상황 때문일 수도 있고, 마케팅 플랜 때문일 수도 있습니다. 일정은 정해져 있는데 기능에 문제가 있습니다. 그냥 출시할 것(on time)이냐, 아니면 일정을 늦추고 품질을 높일 것인가(on quality) 선택하라는 질문입니다.
이 질문에 정답은 없습니다. 지원자의 성향을 보려는 질문입니다. 어떤 답변을 하든 지원자에게 철학이 있으면 됩니다. 실무에서는 둘 다가 정답일 수 있고 오답일 수도 있습니다. 블리자드는 항상 품질을 선택했습니다. 아무리 ‘오래 걸려도 좋은 품질의 게임만을 출시한다’가 회사의 철학이었지요. 하지만 모든 게임에 이를 적용할 수는 없습니다.
예를 들어 스파이더맨 영화가 개봉되고 영화 줄거리를 바탕으로 한 게임이 나온다면 영화와 동시에 출시하는 것이 최선이겠지요. 이 경우 품질도 중요하지만 타임 투 마켓(Time-to-Market), 즉 최적의 시기에 맞추는 일이 품질보다 더 중요합니다.
하지만 일반적인 서비스라면 품질과 시간 사이에서 밸런스를 잡아야 합니다. 적절한 품질로 최대한 늦지 않게 지속적으로 시장에 출시하는 것이지요. 스타트업에서는 최소기능제품이라는 개념이 활발히 사용됩니다. 따라서 최소기능제품 전략이 가능하려면 최소한의 시간에 사용자가 사용하기에 충분한 품질을 만들고 제품 범위를 최대한 줄여야 합니다. 요즘 게임은 최소기능제품의 표본입니다. 모든 콘텐츠를 다 만들어서 출시하는 것이 아니라 게임의 10%만 만들어서 출시하고 시장의 반응을 보면서 나머지를 구현합니다.
‘시간도 부족하고 리소스도 부족하니, 무조건 기능을 줄여서 출시한다’는 정답이 아닙니다. 더 높은 차원에서 프로젝트 관리를 하려면 애초에 이런 상황이 오지 않게 주어진 시간과 리소스를 효과적으로 써야 합니다. 팀이 효율적으로 돌아가도록 계획을 세우는 겁니다. 모든 기능이 필수는 아니므로 범위를 조금은 줄여야 합니다. 결국 우선순위 정하기가 절반, 시간을 효율적으로 관리하기가 절반입니다. 이걸 잘 섞고 조율해야 프로젝트 관리를 잘해서 성공적으로 제품을 출시할 수 있습니다.
2. 역할 나누기
PM은 인적 자원을 역할 기준으로 관리합니다. 사람들이 어떤 역할을 맡고 어떤 일을 하는지 조율하는 코디네이터 역할을 하는 거죠. 전체 프로젝트로 보면 PO와 어떤 기능을 넣어달라고 요구하는 이해관계자(Stakeholder), 실제 기능을 개발하는 개발팀이 있습니다. 그리고 팀에는 프로젝트 리드(언제까지 만들고 뭘 할 건지 결정하는 사람), 테크니컬 리드(기술을 관리하는 사람), 피플 매니저가 있습니다. 세 역할을 한 사람이다 맡기에는 버거운 면이 있습니다. 마이크로소프트나 블리자드를 비롯한 미국 회사는 엔지니어링 매니저를 따로 두기도 합니다. 심지어 각각을 세 명에게 맡기기도 합니다.
역할은 팀 크기에 따라 달라질 수 있습니다. 역할을 맡은 사람이 일을 잘할 수 있게 코디네이션하려면, PM은 사람들이 적절히 부딪히며 일할 수 있게 역할을 정의해야 합니다. 역할을 나눈다는 것은 바둑판처럼 격자를 그려놓고 사람들을 하나하나 넣어서 할 일을 정해주는 게 아닙니다. 야구에서의 1루수, 2루수, 3루수 같이 포지션을 정해야 합니다. 급할 때는 1루수가 2루수 자리로 옮기기도 하니까요. 서로 포지션을 약간씩 겹치면서 충돌하면서 일해야 합니다.
예를 들어 ‘프로덕트 오너는 요구사항을 만들지마’, ‘이해관계자만 요구사항을 줄 거야’, ‘엔지니어는 그냥 시키는 일만 해’ 이런 식으로 역할을 나누면 망합니다. 완벽히 격리된 역할을 주면 의욕이 떨어지고, 역할 이기주의에 빠질 수 있습니다. 그러면 큰 그림에서 협동이 어렵습니다. 모든 사람에게 기본 역할을 정리해주되, 약간은 자기 범위 밖에 나와서 일할 수 있도록 자유를 제공해야 합니다. 앞부분에서 이야기했던 투명성, 예측 가능성 같은 것을 발현하여, 사람들이 자연스럽게 자기 밖으로 나와서 이야기하고, 생산적인 충돌이 일어나도록 해야 합니다.
3. 시간 아끼기
시간을 아끼는 최고의 방법은 낭비를 없애는 겁니다. 시간을 잡아먹는 요인으로는 ➊ 필요 없는 코드, ➋ 개발 과정에서 기다림(다음 과정이 준비되지 않았기 때문에), ➌ 불명확한 요구사항, ➍ 내부 정치, ➎ 느린 내부 소통 이렇게 다섯 가지가 있습니다.
생소한 이야기가 아닐 겁니다. 이미 많은 회사에 만연하죠. 지금 이 순간에도 도처에서 시간이 버려집니다. 성공적으로 프로젝트를 완료하고 싶다면 낭비를 막아야 합니다. 물론 모두 없앨 순 없습니다. 하지만 줄이는 건 가능합니다. 해결책은 단순합니다. 계획을 세워서 명확한 요구사항을 만들고, 관리자가 큰 틀에서 목표와 비전을 가지고 정리해 내부 소통을 개선해서 내부 정치를 사라지게 하면 됩니다. 소통이 원활해지면 투명성이 높아지니까 엉뚱한 정치가 안 먹히게 되는 겁니다.
프로세스 자체가 느리다면 시스템을 개선해야 합니다. 빠르게 빌드하고, 테스트를 자동화하고, QA를 빠르게 진행하는 등 개발 과정을 최적화해야 합니다. 필요 없는 코드는 요구사항이 명확하지 않을 때 또는 기술 구조를 잘 정의하지 않았을 때 발생합니다. 따라서 요구사항을 명확히 정의하고 기술 구조를 초기에 제대로 잡아둬야 합니다.
가벼운 캔미팅이나, 대대적인 워크숍으로 낭비 요소를 찾고 해결책을 함께 모색할 수도 있습니다. 하지만 직장인이라면 낭비되는 요소를 누구나 너무 잘 압니다. 거창한 이벤트보다는 일상에서 꾸준히 하나씩 낭비를 줄이는 방식이 낭비가 낭비를 만들지 않는 방법입니다. 때로는 돈을 더 많이 버는 것보다 덜 쓰는 게 쉽습니다. 아예 돈을 덜 쓰면 낭비를 안하게 되거든요.
시간도 마찬가지입니다. 낭비를 줄이면 업무 효율이 올라갑니다. 당연히 생산성도 높아지게 됩니다. 아주 중요한 내용이라서 다시 한번 강조합니다. 생산성을 올리는 방법은 모두를 바쁘게 하는 것이 아니고 낭비를 없애는 겁니다. 모두가 바쁘고 진척이 안 된다면 사실상 낭비하고 있을 가능성이 높습니다. 서로가 서로에게 병목이 되어서 전체 진행 속도가 느려졌을 겁니다. 가능한 모든 곳에서 낭비와 병목 요소를 없앱시다. 그러면 빠르면서도 모두가 적절한 업무량으로 일할 수 있게 됩니다. 효율적이며 생산성이 높아지는 거죠.
4. 문제 해결 6단계
프로젝트를 진행하다 보면 문제가 계속 발생합니다. 어느 날 한 직원이 “왜 출근하면 항상 밤새 시스템이 망가져 있는 걸까요. 슬픕니다”라고 하는 겁니다. 그래서 제가 말했습니다. “이게 안 망가져 있으면 우리가 출근을 안 했겠지. 잘렸겠지. 매일 뭔가가 망가지니까 우리가 즐겁게 매일 일하는 거야.” 문제는 항상 발생합니다. 일이란 문제를 잘 정리하고 계산하고 해결하는 행위입니다. 문제가 재발되지 않게 해결하는 게 중요합니다. 고로 문제 자체를 싫어하면 안 됩니다.
위기관리 프로세스를 예로 들어보겠습니다. 위기관리 프로세스를 준비하면 위기가 발생하지 않습니다. 준비를 했으니까요. 우산을 계속 들고 다니면, 비가 와도 위기가 아닙니다. 들고 다니다가 쓰면 되니까요. 그런데 우산을 가지고 다니지 않으면, 비가 올 때 위기 상황이 되는 겁니다. 그래서 위기관리를 하면 위기가 안 오고, 위기관리를 안 하면 위기가 옵니다.
문제는 필연적으로 계속 발생하므로 문제 해결 시스템을 갖추면 시간 낭비를 줄일 수 있습니다. 문제 해결 시스템을 어떻게 만들어야 할까요? 시스템을 만들려면 문제 해결을 단계별로 나눠야 합니다. 문제 정의부터 문제가 해결되었는지 확인하기까지 과정을 총 6단계로 나눠봅시다.
문제 해결 단계
- 1단계: 문제 고르기
- 2단계: 고른 문제를 정의하기
- 3단계: 문제 분석하기
- 4단계: 해결책을 찾고 그중에서 최선의 해결책 선택하기
- 5단계: 선택한 해결책을 실행해도 되는지 결정권자에게 승인받기
- 6단계: 문제가 해결되었는지 확인하기
문제는 도처에 도사립니다. 그리고 한둘이 아닙니다. 어떤 문제를 먼저 해결할지 우선순위를 정해야 합니다. 모든 문제를 완벽하게 해결할 수는 없기 때문입니다. 그래서 1단계는 ‘문제 고르기’입니다. 2단계는 ‘고른 문제를 정의하기’입니다. 예를 들어 ‘너무 더워서 일할 수 없다’라는 문제가 있다면, ‘더위란 무엇인지, 몇 도가 되면 더운지, 원하는 온도는 몇 도인지’, 이런 식으로 문제를 정의합니다. 3단계는 ‘문제 분석하기’입니다. ‘더워서 생산성이 떨어진다, 땀이 흘러 수건으로 닦아야 된다’ 등 문제의 원인과 결과를 분석합니다.
4단계는 ‘해결책 찾기’입니다. ‘더우니까 선풍기 갖다 놓을까, 에어컨 갖다 놓을까, 밖에 나가서 일할까?’ 고민하는 겁니다. 해결책은 여러 가지여야 합니다. 해결책이 하나만 있어서는 안 됩니다. 저는 해결책이 단 하나일 때는 그 해결책을 적용하지 않는 편입니다. 만약에 그걸 적용했다가 해결이 안 되면 더 위험한 상황이 될 수 있기 때문입니다. 여러 가지 해결책이 있어야, 하나가 실패했을 때 잽싸게 다른 해결책을 시도할 수 있습니다. 문제 하나에 해결책이 하나만 있을 수는 없습니다. 문제 하나에 여러 해결책을 고안한 뒤 제일 좋은 해결책을 골라야 합니다. 이것이 문제 해결의 핵심입니다.
5단계는 ‘선택한 해결책을 실행해도 되는지 결정권자에게 승인받기’입니다. 제일 좋은 방안을 골랐다고 곧바로 실행하면 안 됩니다. 결정권자와 이야기한 뒤 실행해야 합니다. 결정권자에게 해결책을 보여주고 이해와 동의를 구한 뒤 진행합시다. 그렇지 않으면 우리가 해결책을 선택할 때 고려하지 못했던 결정권자만 아는 이유로 모든 일을 처음부터 다시 해야 할 수도 있습니다.
마지막 6단계는 ‘문제가 해결되었는지 확인하기’입니다. 에어컨과 선풍기 중 고민하다가, 에어컨으로 결정했다고 해봅시다. 결정권자가 돈이 많이 들어도 에어컨 설치에 동의했으면, 이제 시원하게 모두가 즐겁게 일하면 됩니다. 그런데 설치했다고 끝이 아닙니다. 얼마간은 계속 확인해야 합니다. 온도가 낮은지, 모두가 행복한지, 문제 해결 상태가 지속되는지 측정해야 합니다.
참고로 문제 해결뿐 아니라 모든 일에서 목표(Goal), 계획(Plan), 실행(Action), 측정(Measure) 이 네 가지는 중요합니다. 목표가 있어야 의미가 있는 것이고, 계획이 없으면 무엇도 할 수가 없으며, 실제 실행해야만 뭐든 결과가 나옵니다. 모든 결과를 측정/분석해서 더 좋은 목표로 수정하거나 아니면 계획을 더 좋게 바꾸어서 다시 실행해 원하는 결과가 나올 때까지 이 과정을 반복해야 합니다. 이 방법론은 지금까지 이야기한 문제 해결 방식에도 동일하게 녹아 있습니다. ‘목표는 문제 해결하기’, 계획은 ‘여러 해결책 마련하기’, 실행은 ‘일부 해결책을 골라서 행동하기’, 측정은 ‘문제가 해결됐는지 확인하기’입니다. 문제 해결 상태는 반드시 유지되어야 합니다. 안 그러면 의미가 없습니다. 만약에 해결된 상태가 유지되지 않는다면 다시 문제를 풀어야 합니다.
5. 선별해 문제 풀기
제한된 시간을 효과적으로 사용하려면 산적한 문제를 효과적으로 분류하고 대응해야 합니다. 현재 역량으로 풀 수 있는 문제와 풀 수 없는 문제가 있습니다. 따라서 문제를 발견했다면 경중과 해결 가능성을 따져야 합니다. 예를 들어 직원들이 연봉이 낮다고 항의한다고 합시다. 회사가 돈이 없다면 더 줄 수 없으니 현실적으로 해결할 수 없는 문제가 됩니다. 중요하고 풀 수 있는 문제는 풉시다(do it). 중요한데 풀 수 없다면 미래로 미뤄둬야 합니다(postpone). 풀 수는 있지만 중요하지 않다면 위임합니다(delegate). 할 수 있는 일이라고 다 해야 하는 건 아닙니다. 중요하고 풀 수 있는 일의 우선순위가 높습니다. 다음 그림은 우선순위를 정할 때 사용하는 시간 관리 매트릭스를 문제 선별용으로 약간 변형한 버전입니다(우선순위에서는 X 축이 ‘긴급도’입니다).
이 도표의 핵심은 중요하지 않고 할 수 없는 일을 무시(Ignore)하는 영역입니다. 해결 못할 일에 시간을 낭비하지 않도록 아예 뇌에서 지워버리는 겁니다. 존재하지 않는 것처럼요.
블리자드에서는 아침마다 버그 리뷰를 했습니다. 아침 리뷰 때마다 30개 정도씩 버그가 새로 추가됩니다. 매일 고쳐도 매일 버그가 늘어나니 항상 500개 정도가 유지됩니다. 그중 400개는 몇 달째 쌓여 있는 겁니다. 중요성이 낮고 해결까지 드는 시간을 확보하기도 어려운 문제들이죠. 그래서 400개를 지우자고 했습니다(무시하기), 괜히 리뷰하는 데 시간만 들어간다고요. 그래서 정말로 지웠냐고요? 지웠습니다. 그리고 평소와 같이 매일 30개 버그가 쌓였고, 일부 버그는 고치고(문제 풀기), 일부 버그는 수정하지 않기로 결정하고(무시하기), 일부 버그는 추가 테스트 요청을 했습니다(위임하기). 중요하다고 판단한 100개만 리뷰하면 되기 때문에 시간을 절약할 수 있었습니다.
이처럼 중요도가 낮거나 해결할 수도 없는 일이라면 (리소스 때문이든 능력 때문이든) 머릿속에서 지워버리는 것도 방법입니다. 그렇지 않으면 낭비로 연결되기 때문입니다. 할 수 있는 일, 중요한 일, 해결할 수 있는 문제에 집중합시다. 재발하지 않도록 해결책을 만듭시다. 그래야 시간을 효율적으로 쓰면서 프로젝트를 제대로 리드했다고 말할 수 있습니다.
6. 우선순위 정하기
우선순위대로 일하고, 문제를 해결하고, 낭비를 없애고, 사람들의 역할을 연결해야 합니다. 단순히 일정 잡고 열심히 일하도록 격려하는 역할이 프로젝트 관리라고 오해하기 십상입니다. 하지만 프로젝트 관리는 생각보다 많은 일을 포함합니다.
핵심은 ‘우선순위 정하기’입니다. 우선순위의 기본은 ‘급한가 급하지 않은가?’, ‘중요한가 중요하지 않은가?’에 있습니다. 앞서 얘기한 ‘중요한데 할 수 있는가 없는가’와 비슷하게 들립니다만, 약간 다른 측면에서 보는 겁니다. 급한 거는 바로 느껴지지만 중요도는 잘 느껴지지 않습니다.대개는 생각할 시간이 없고, 눈앞에서 당장 닥친 일만 하다 보니까 급한 것 위주로 일하게 됩니다.
찰스 험멜이 쓴 《늘 급한 일로 쫓기는 삶》이라는 책이 있습니다. 우리는 늘 급한 일로 쫓깁니다. 만약에 여러분이 매일 너무 급하게 살고 계속 시간에 쪼들린다면, 뭔가 잘못되고 있다는 겁니다. 중요한 일을 해야지 급한 일의 늪에 빠져서는 안 됩니다. 할 일을 고를 때 급한가 급하지 않은가를 따지지 말고, 한 발 물러서서 ‘중요한가 중요하지 않은가’를 먼저 생각해야 합니다. 급한데 중요하지 않은 일에 시간을 다 써버리면, 그 사이에 급하지 않았지만 중요했던 일이 아주 시급하고 중요한 일로 다가오게 됩니다. 중요한 데 시급한 일이라니! 상상만 해도 무섭군요. 그러니 ‘중요하고 급한’ 일로 분류될 일은 초기에 처리해서 없애버려야 합니다. 그러고 나서는 ‘중요하지만 안 급한 일’ 위주로 처리하면 됩니다. 그래야 자신이 삶을 주도하고 시간을 주도하면서 프로액티브(Proactive)하게 살아갈 수 있습니다. 급한 일만 하면 일에 쫓겨다니고 끌려다니게 됩니다.
예를 들어 이야기해봅시다. 업무 중에 여기저기서 전화가 오고, 이메일이 옵니다. 그러면 당장 그 일들을 처리하느라 너무 바쁩니다. 그러다가 하루를 다 써버립니다. 이는 외부에서 오는 것에 반응하는 리액티브(Reactive)한 삶입니다. 원래 직장 생활이 그런 거 아니냐고 생각할 수 있지만, 이걸 뒤집을 수 있습니다. 이메일이 오면 언제까지 하겠다고 답장하고, 전화가 오면 지금 다른 일을 하고 있으니 언제 다시 연락을 주겠다고 하는 거죠. 아니면 다른 사람에게 일을 넘겨줄 수도 있습니다. 업무 요청을 전부 즉시 처리하는 게 아니라 마감일을 정하거나, 거부하거나, 위임해서 관리해야 합니다. 일종의 대기열을 만들어서 하나씩 차근차근하면 됩니다. 중요한 일은 앞으로, 덜 중요한 일은 뒤로.
우선순위 정리는 시간과 업무 두 측면 모두에 필요합니다. PM이라면 팀 전체의 시간과 업무의 우선순위를 정리해야 합니다. PM이 우선순위를 제대로 정하지 못하고 헤매면 팀 전체가 헤맵니다.
◆◆◆
프로젝트 리드는 역할, 낭비, 문제, 우선순위 이 모든 것을 총체적으로 관리해야 합니다. 그래야 큰 그림 안에서 안정적으로 일할 수 있습니다. 이 모든 것을 관리하므로 바쁩니다. 원래 바빠야 합니다. 본인은 바빠도 프로젝트 안에서 일하는 사람들은 안정적으로 일할 수 있게 해줘야 합니다.
성공적인 커리어를 돕는
골든래빗 테크 에세이 시리즈
박종천
한글과컴퓨터, 블리자드, 넥슨, 삼성전자를 거쳐 머신러닝 기반의 광고 플랫폼 유니콘 기업 몰로코에서 헤드 오브 솔루션스 아키텍처로 일한다. 30여 년 동안 한국과 실리콘밸리를 오가며 개발자, 개발 리더, 탑 레벨 매니저 등으로 활약했다. 〈스타크래프트〉 한글 지원 기능을 제작한 일은 평생의 자랑거리다. 그동안 쌓은 노하우를 개발자 커뮤니티에 풀어놓고자 애쓰고 있다.
