리얼월드에서 프로그래머로 살아내기

[코딩을 넘어 비즈니스로] #3. 박성철 컬리 풀필먼트&딜리버리 본부장

코드는 현실 세계를 반영해야 합니다. 비즈니스의 요구 사항과 사람은 컴퓨터의 작동 방식대로 움직이지 않습니다. 현실 세계는 컴퓨터의 작동 방식과는 무관하게 바뀌는 공간이죠. 우리 프로그래머가 현실의 문제를 외면한다면 컴퓨터는 사람의 사고와 행동을 제대로 반영하지 못할 것이고, 고객은 떠나갈 것입니다. 고객이 떠난 자리에는 프로그래머가 설 자리도 없습니다.

그래서 비즈니스를 코드로 구현하기 위해 분투하고 있는 다양한 프로그래머의 고민, 문제 해결, 성장 이야기를 들어보고자 합니다. 앞으로 인터뷰나 에세이 등 다양한 형식을 통해 코딩과 비즈니스의 관계를 톺아보려 합니다. 시리즈 세 번째로, 박성철 컬리 풀필먼트&딜리버리 본부장을 만났습니다.

꾸준히 적응하고 살아남는 힘

박성철 님은 필자가 한국 스프링 사용자 모임(KSUG) 활동을 통해 처음 인연을 맺었습니다. 그 후 꽤 긴 시간이 흐르는 동안 알고 지냈는데, 소속한 조직이 바뀌는 변화에도 꾸준히 환경에 적응해온 사람이라는 생각이 들었습니다. 그 과정에서 배운 바는 무엇인지 궁금했고, 이를 기록하는 일이 독자님들께 영감을 줄 수 있다는 생각에 인터뷰를 시도했습니다.

놀랍게도 인터뷰 과정에서 가장 중요한 것은 변화하는 환경 속에서도 생존하는 일이란 표현을 들을 수 있었습니다. 필자의 의도가 잘 통했다는 안도감도 있었지만, 지인으로 알고 지내면서도 몰랐던 가치관을 들을 수 있어서 좋았습니다. 인터뷰 하는 중에 명강의를 듣는 것처럼 몰입할 수 있었기에 자랑스럽게 내놓을 수 있는 글이 될 듯합니다.

프로그래머가 된 이유

안영회(이하 안): 오랫동안 쭉 환경에 적응을 잘 해오셨다는 생각이 드는데요, 먼저 언제부터 개발을 시작하셨는지 여쭙고 싶어요. 

박성철(이하 박): 처음 코딩을 시작한 건 1982년, 중 2때에요. 컴퓨터를 본 적도 없었는데 갑자기 친구들이랑 같이 컴퓨터에 꽂혔어요. 당시 우리나라에서 교육용 컴퓨터라는 게 처음 만들어졌어요. 여러 대기업에서 8비트 컴퓨터를 만들어 팔기 시작했죠. 그런 붐이 있던 시기라 저도 모르게 그 분위기에 휩쓸렸던 것 같아요.

친구들이랑 신문에 있는 ‘해외 토픽’란이나 외국 영화에 나오는 컴퓨터에 대해 이야기를 나누고는 했어요. 600만불의 사나이에 나오는 컴퓨터 같은 것에 대해 떠들었죠. 그러다 당시 <라디오와 모형>이라는, 전자회로랑 프라모델을 다루는 소위 ‘오덕’들이 보는 잡지에서 “마이컴 입문 교실”이라는 강좌를 보게 됐어요. 당시에는 PC를 마이컴이라고 불렀거든요. 거기서 처음 프로그래밍이란 걸 배웠어요. 컴퓨터는 없었으니, 그냥 강좌에서 알려주는 BASIC을 손으로 한줄씩 써본 거예요.

지금의 용산전자상가와 같았던 세운상가에 가서 전시된 컴퓨터를 훔쳐서 써보다가 1983년도 부터는 우리나라에서도 교육용 컴퓨터가 대기업에서 출시되면서 직접 사용해볼 수 있게 되었죠.

안: 그러면 실제 프로그래머로 활동을 시작하신 건 언제예요? 프로그래밍으로 돈을 벌기 시작하신 거요.

박: 취업 전에도 몇몇 업체에서 만들어달라고 하는 거 만들어주고, 게임을 만들어서 판 적도 있었어요. 전문적인 직업인으로서는 아니지만, 간간히 아르바이트하는 형태로 어떤 회사에 들어가 일을 도와주면서 용돈벌이도 했고요. 그런데 본격적으로 돈을 번 건 대학교 졸업하고나서죠. 첫 직장을 프로그래머로 입사했어요.

안: 전공이 컴퓨터공학이셨어요?

박: 토목공학 전공했어요. 원래 저는 프로그래밍을 직업으로 삼을 생각이 전혀 없었어요. 프로그래밍은 그냥 내 취미라고 생각할 뿐이었죠. 그런데 군대 전역하고 졸업할 때쯤 프로그래머를 직업으로 생각해볼 정도로 세상 분위기가 달라졌어요. 제가 대학교 졸업할 때가 92, 93년도인데, 비전공자가 정보처리기사 자격증 시험에 응시하는 경우도 많아졌어요.

안: 완전 초창기네요. 사실 전산직이라는 게 이제 막 만들어지던 시기에 졸업하신 거네요. 

박: 그렇죠. 그런데 당시 대기업 전산직으로 들어가면 프린터 용지 나르는 일을 시킨다고 하더라고요. 그래서 프로그래머들이 그때 창업을 많이 했죠. 한글과컴퓨터 같은 회사가 그때쯤 생겼고요. 이런 변화 때문에 프로그래머를 직업으로 고려해보게 된 게 한 가지 이유였어요.

또 하나는, 졸업할 때쯤 여기저기서 대형 건설 사고가 일어났어요.* 내가 지은 건축물이 막 무너진다고 생각하니까 너무 싫더라고요. 토목공학을 공부하다 보니 절대로 안 무너지는 것을 짓는 게 아니더군요. 적당히 무너지지 않을 것 같으면서 경제적인 건축물을 짓는 거예요.

당연한 말이지만, 피라미드처럼 수천 년 동안 무너지지 않을 걸 짓는 게 아닌 거죠. 그렇게 보니까 너무 자신이 없더라고요. 제 성향과 안 맞는 거예요. 내가 지은 댐이나 다리가 무너져서 사람이 죽는다고 생각하면, 못 견디겠더라고요. 그래서 “안전한 컴퓨터 세상에 머물자, 리얼 월드에 나갈 자신 없다.”해서 프로그래머가 되기로 결정했어요.

*1992년 신행주대교가 건설 중에 무너져서 충격을 주었고, 1993년 청주 우암 상가 아파트가 붕괴돼 29명이 사망하고 48명이 부상을 입는 사고가 있었다. 그 뒤로 약 5년 사이 성수대교 붕괴, 삼풍백화점 붕괴 등의 건설 사고가 연이어 일어났다.

프로그래머가 혼자 일할 수 없게 된 이유

안: 90년대 초반부터 시작하셨다 해도, 업계에서 굉장히 긴 시간을 일해오셨잖아요. 걸어오신 시간을 돌아보면, 의미 있는 변곡점이 어떤 게 있으셨나요?   

박: 컴퓨터야 늘 더 빨라지고 더 많은 것을 처리하고 더 작아졌지만, 저는 크게, 소프트웨어가 배포되는 매체의 변화에 따라 프로그래머의 삶에도 큰 변화가 있었다고 생각해요. 첫 변화는 CD로 대표되는 광매체의 등장입니다. 그 전에 있던 플로피 디스크는 용량이 1.44메가 정도였거든요. 게임이나 소프트웨어를 만들어서 배포하려면 미디어에 담아야 하는데, 미디어 용량에 한계가 있으니까 결국 소프트웨어가 거기 맞춰지는 거예요. 그런데 CD가 만들어지면서 동영상 같은 콘텐츠를 엄청 많이 담아낼 수 있게 된 거죠. 그러면서 컴퓨터의 성격이 달라졌다고 생각해요. 그 전에는 컴퓨터란 게 그저 계산을 하고 데이터를 처리하는 시스템에 불과했다면, CD가 만들어지면서 엔터테인먼트가 된 거죠. 그래서 컴퓨터가 방이 아니라 거실로 나온 거예요.

안: 멀티미디어 시대가 된 거죠. 

박: 그 계기가 됐죠. 그러다가 인터넷이 만들어지면서 완전히 바뀌었어요. 기존에는 소프트웨어를 딜리버리할 때 물리적인 매체가 필요하다 보니 몇 년에 한 번씩 업그레이드했지만, 인터넷 시대에는 수시로 업그레이드 될 수 있게 됐어요. 또 소프트웨어 개발 방법도 변했죠. 그 전에는 개발자가 기획자나 디자이너와 같이 일할 일이 없었어요. 프로그래머들이 요구사항 분석하고 정리하고 설계해서 만들었죠. 음악이나 미디어 디자인이 필요하더라도, 그걸 하는 분들에게 하청을 주거나 요구사항을 보내주고, 완성되면 나중에 통합할 뿐이지, 같이 팀을 이루어 일하지는 않았어요.

안: 지금은 빠르게 업데이트되니까 같이 일할 필요가 생긴 거겠네요. 

박: 맞아요. 그래서 인터넷 때문에 기획자, 디자이너, 개발자가 같이 팀을 이뤄서 한 팀으로 일하거나 지근거리에서 일하거나, 일하는 형태가 달라지게 됐어요. 그런데 이제 더 큰 변화는 모바일이죠. 모든 사람들이 자기 주머니에 컴퓨터를 가지고 다니게 된 거잖아요. 그러면서 접근성이 훨씬 좋아졌고, 컴퓨터도 그에 따라 바뀌었죠. 클라우드 컴퓨팅도 활성화됐고요. 빅데이터나 AI도 모바일의 등장에 맞물려 있어요. 저는 이걸 ‘근접학’ 관점에서 보거든요.

안: 근접학이 뭔가요?

박: 사람이나 물체 사이의 거리와 상호 작용에 대한 연구인데요. 이런 도표가 있어요.

사람이 사적인 공간으로 느끼는 아주 작은 공간(Intimate space)이 있고, 그다음으로 아주 친한 사람들이 들어올 수 있는 ‘사적 공간’이 있어요. 그게  반경 1.2m정도예요. 이 범위 내에는 아주 친한 사람이 아니면, 누군가 들어오면 부담스러워지죠. 그다음 사회적 공간은 반경 3.6m정도이고, 회의실 공간 정도는 되죠. 방 하나 정도인 거예요. 이 방 안에서는 익숙한 사람이 아니면 조금 불편하죠. 그래서 서로 모르는 사람들이 같은 엘리베이터에 타면, 다른 방향을 바라보고 서요. 그다음 공적 공간은 그냥 불특정 다수가 있는 공간이죠. 이렇게 친숙도에 따라서 공간 크기가 달라지는데, 컴퓨터의 관점에서도 이런 게 있어요.

예를 들어, 저는 아버지가 회사를 경영했는데, 큰 사무실에 컴퓨터가 한 대 였어요. 사무실 구석에 컴퓨터가 하나 있고, 오퍼레이터가 따로 있었죠. 사무 보좌하는 사람이 데이터도 입력하고 전표 출력하는 일을 도맡아 했어요. 집에서도 컴퓨터가 거실에 하나 있거나 하는 시대였던 거죠. 그런데 누구나 자기 책상에 컴퓨터를 두고 일하는 시대가 됐고, 이제는 누구나 주머니에 컴퓨터를 갖고 다니는 거죠. 컴퓨터가 점점 더 친숙해지면서 작은 공간으로 오게 된 거예요.

이렇게 되면 무엇이 달라지냐면, 주머니에 갖고 다니는 소프트웨어는 친한 친구처럼 내 마음을 알아야 해요. 쓰기 아주 편해야 하죠. 컴퓨터라는 게 이렇게 우리와 가까워지면, 그에 따라 유저 인터페이스나 사용성이 굉장히 좋아야 돼요. 반응도 빨라야해서 리액티브 시스템 같은 얘기가 나오는 거에요. 나를 잘 알아줘야 하니 데이터나 AI가 필요해지는 거고요.

정리하자면, 돌아봤을 때 가장 큰 변곡점이었던 건, 미디어가 달라지면서 대용량 처리가 가능해지고, 그러면서 특별한 일만 할 수 있었던 컴퓨터가 제가 취업할 때쯤에는 멀티미디어 세상이 열리며 엔터테인먼트 기기가 된 거예요.

안: 취업과도 상관이 있었나요?

박: 첫 회사가 멀티미디어 회사였어요. 그때 이미지 프로세싱이나 CD 레코딩, VOD 기반의 교육용 시스템을 만들었어요. 대학에서 멀티미디어 기반으로 교육을 시작하던 때였거든요. 그러다 인터넷이 상용화되면서 사람들이 컴퓨터에 더 친숙해졌고, 그때 비로소 대부분의 사람이 컴퓨터를 갖기 시작했어요. 다들 메일 계정을 하나씩 갖게 됐죠. 그러다 이제 모바일이 되면서 누구나 컴퓨터를 소지하고 다니죠.

이 세 단계를 거치면서 컴퓨터가 점점 더 우리 개인의 영역으로 들어오게 됐다고 생각해요. 그러면서 프로그래밍이라는 것도 점점 더 복합적인 일, 여러 사람이 융합되어 해야 하는 일이 됐죠. 그래서 목적조직이나 린스타트업 같은 방법론이 요즘에 필요해진 거고요. 컴퓨터 프로그래밍을 하는 사람들만이 아니라 관련된 사람이 다같이 일해야 하는 상황이 되어버린 거죠.

프로그래머란 무엇인가

안: 질문의 의도보다 풍부하게 말씀해주셔서 강의 듣는 느낌이었어요. 오랫동안 계속 변화에 적응해오신 게, 결국에는 프로그래머로서 세상의 흐름을 잘 이해해왔기 때문이 아닌가 싶어요. 이런 변화 상황에서 개발자들이 가져야 할 태도로는 어떤 게 있을까요?

박: 먼저 프로그래머를 정의내려보고 싶어요. 제가 90년대 후반에 가졌던 질문이 있어요. ‘프로그래머랑 고급 사용자는 뭐가 다르지?’ 라는 질문이었죠. 고급 사용자란, 컴퓨터를 굉장히 잘 써서 깊이 파고드는 사람들이에요. 예를 들어 MSCP(Microsoft Certified Professional, 마이크로소프트 인증 프로페셔널) 자격증을 가진 사람들은 기술적 문제를 해결할 수 있거든요. 윈도우 레지스트리도 수정하고 DLL 버전도 맞춰요. 직접 만들지는 않지만 어떻게 구성되어 있는지를 이해하고 조작해볼 수 있는 사람이죠. 그런데 그 사람을 프로그래머라고 부르지는 않아요. 컴퓨터나 어떤 솔루션의 전문가는 사용 과정에서 생기는 문제를 해결할 수 있는 능력을 가지고 있는 사람이거든요.

제가 처음 ASP 프로그래머들을 만났을 때, 프로그래밍을 잘 못 하는 것 같아 보이더라고요. 그 사람들은 아주 간단한 스크립팅만 하면서 여기저기서 컴포넌트를 가져다가 조립해서 뭔가 유용한 것을 만들었어요. 당시 제 기준으로 그 사람들은 프로그래머가 아닌 고급 사용자에 더 가까워 보였어요. 낯선 부류의 프로그래머를 만나고 어떻게 바라봐야 할지 오랫동안 고민했습니다.

어떤 관점에서는 요새 이런저런 오픈소스를 가져다가 통합해서 뭔가를 돌아가게 만드는 방식과 비슷하다고 볼 수 있어요. 깊이 있는 기술 문제를 해결하는 능력은 약하지만 여러 컴포넌트를 끌어모아서 사용자가 원하는 기능을 만들어내는 거죠. 당시에는 이런 사람들도 프로그래머인가, 이런 생각을 했던 거예요. 어찌됐든 돈을 받고 일했고, 심지어 저보다 더 많이 벌었어요. 가치 있는 일을 하고 있다는 것이죠.

그 의문을 품고 일하던 사이에 닷컴 버블이 꺼지고 다시 모바일 붐이 일면서 지금까지 왔어요. 그런데 지금 보면, 대부분 디지털 서비스 회사에서 일하는 개발자가 그런 사람이라고 말할 수 있어요. 옛날에는 코딩테스트할 때 알고리즘 테스트하는 게 당연했어요. 그런데 요즘에는 알고리즘 문제 왜 푸냐는 얘기가 나오죠. “라이브러리 갖다 쓰면 되는데 알고리즘은 뭐하러 알아야돼?” 이런 생각을 하는 거죠. 물론 조금만 준비하면 다 풀 수 있을 거에요. 다만, 대부분은 그게 자기가 하는 일과 상관 없는 평가 기준이라고 보는 겁니다.

이런 모습을 보면서 다시 옛날에 가졌던 그 질문을 떠올리게 되죠. “고급 사용자랑 프로그래머는 뭐가 다르지?” 생각해보면, 제가 프로그래머가 아닌 것 같다고 생각했던 사람들이 이제는 더 일반적인 프로그래머의 유형이 되었다고 볼 수 있어요.

안: 저는 좀 충격적이네요. 저도 ASP 하시는 분들은 실제로 겪어봤어서 공감했는데, 거기서 또 스스로 실존적인 질문을 던지셨고, 그 질문을 지금까지 이어서 갖고 오신 거잖아요. 

박: 결국은 우리가 프로그래머라고 부르는 사람이 사실은 굉장히 폭넓은 부류의 여러 사람을 총칭한다는 거예요. 프로그래머 중에는 하드웨어도 이해하고, 완전히 풀스택인 사람도 있지만, 어떤 사람은 그냥 사용자가 필요로 하는 결과물을 빨리빨리 만들어내는 정도의 기술 지식만 갖고 있는 사람도 있는 거죠. 프로그래머라는 직군을 하나로 볼 수 없다고 생각해요. 그런데 생각해보니, 컴퓨터에 대한 학문적인 관심 보다는 호기심의 대상으로 깊이 파면서 컴퓨터를 이용해서 뭔가를 만들어내는데 더 흥미를 가진 유형의 사람을 예전부터 부르는 용어가 있었어요. 바로 ‘해커’예요.

안: 굉장한 관점 전환이네요. 

박: 그러니까 여기서 해커란 게 보안을 뚫고 정보를 빼내고 하는 일반적으로 쓰는 의미의 해커가 아니고요. 원래 의미의 해커는 아마추어 컴퓨터 광이라고 말할 수 있습니다. 컴퓨터가 좋고 신기해서 파고 들면서 어떻게 써먹으면 재미있고 신기한 일을 할 수 있을지 골몰했던 사람인 거예요.

안: 그렇네요. 해커네요. 그런데 달라진 게 있다면 이전에는 그 사람들이 재미를 위해서 일했는데, ASP 프로그래머들 같은 경우에는 재미보다는 생업으로 일했다는 점이겠어요. 

박: 해커들이라고 무조건 아마추어이기만 한 건 아니예요. 다만 저는 ASP 프로그래머를 통해서 처음으로 해커라는 부류의 사람을 인지한 겁니다. 고급 사용자와 프로그래머를 구분하는 경계는 없다는 생각을 하게 되었고요. 그리고 지금 이 세계에서는 이렇게 컴퓨터로 뭔가를 만들어내는, 해커라고 부를 수 있는 사람들이 높은 평가를 받아요. 회사에서 뽑으려고 안달하고 경쟁적으로 뽑으려 하는 사람들이 요즘엔 해커인 거예요. 일종의 직업 해커 또는 대중화된 해커라고 할까요.

안: 프로그래밍은 아까 말씀하셨던 대로 점점 고도화되고 있고, 또 거꾸로 그만큼 개인화되고 복잡해지고 있는데, 그 말인 즉 결국 응용에 고려해야 할 요소가 많다는 것이고, 그렇다면 해커 성향을 가진 사람들이 도움이 되겠네요. 다시 원래 질문으로 돌아가자면, 그러면 프로그래머에 대해 이렇게 내린 정의와 프로그래머가 가져야 할 태도는 어떻게 이어지나요?

박: 그러니까, 요즘 우리가 프로그래머라고 부르는 이들 중에서 우대받는 사람이 누구냐, 봤을 때 그게 해커라는 거고요, 그렇다면 지금의 프로그래머들은 어떤 태도를 가져야 할지가 이어지겠죠.

결국에는 프로그래머는 복잡한 문제를 해결해야 해요. 내가 가진 기술을 적절하게 써먹어야 하는 거죠. 프로그래밍이라는 도구만 열심히 잘 깊게 판다고 되는 게 아닌 거예요. 내가 어떤 유용한 결과, 어떤 변화를 만들어낼 것인지, 어떤 편의성을 만들어낼 것인지에 관심을 가져야 합니다.

세상이 너무 빨리 변하고 있어요. 어떤 걸 할지 고민하는 사람과 어떻게 할지 고민하는 사람이 굉장히 가까워지거나 하나가 돼야 해요. 커뮤니케이션에 허비할 여유가 없어요. 그래서 풀스택 개발자라는 게 대두되기도 한 거고요.

어떤 프로그래머로 성장해야 하는가

안: 너무 좋은 이야기인데, 조금은 거시적인 이야기라서, 이 이야기를 듣고 누군가가 “그럼 전 뭘 하면 되나요?”라고 물을 수도 있을 것 같아요. 조금 더 개발자 개인에게 밀착한 조언도 있을까요?

박: 그건 쉽게 답할 수가 없는 게, 그 사람이 어떤 사람인지에 따라 달라요. 제가 이야기한 건 큰 흐름이고, 모든 사람이 이 흐름에 맞춰서 표준화된 삶을 살 필요는 없다고 생각해요. 이번에 저희 회사에서 서버를 ARM 기반으로 전환하고 있는데요, 그렇게 하면 전기도 더 적게 먹고 성능도 좋아진다고 합니다. 이렇게 플랫폼이나 인프라 영역의 일을 하는 사람이 여전히 있어야 해요. 카프카를 만드는 사람이 있어야 카프카를 쓰는 사람이 있잖아요. 그래서 모든 사람이 같은 사람이 되어야 할 필요는 없어요. 개개인은 자기가 뭘 하고 싶고 어떤 걸 할 때 즐거움을 느끼는지 알고 그런 일에 더 집중해야죠.

안: 결국에는 트렌드는 해커같은 프로그래머들이 우대받는 추세이지만, 그런 흐름 아래서 내가 어떤 역할을 하는 건지를 이해하면 된다는 걸로 정리할 수 있을까요?

박: 일단 전체 지형을 이해해보려고 제가 사회가 어떻게 변했는지를 이야기한 것이고요, 그럼에도 내가 하고 싶은 일은 그게 아닐 수 있잖아요. 개인 수준에서는 내가 뭘 하고 싶고 어떤 것에 동기 유발이 되는지를 이해하고 선택해야죠. 이런 선택을 할 때 세상을 어떻게 이해하고 있는지에 따라 선택에 도움이 될 것 같아요.

안: 내가 하고 싶은 일이 세상의 흐름과 맞지 않는 사람은 어떻게 해야 하나요? 경험상 대략적으로 어떤 개발자의 성향이 어떤 직능에 어울리더라, 이런 것도 있으신가요?

박: 시대의 요구를 개인이 다 담아낼 수는 없다고 생각해요. 그래서 팀으로 일하는 게 중요해요. 지금 사회가 필요로 하는 어떤 서비스를 만드는 역량이 1부터 100이라고 하면 한 사람이 그걸 다 잘할 수가 없잖아요. 누구는 1부터 10까지, 누구는 99부터 100까지만 잘할 수도 있죠. 그렇다면 결국 모여서 일해야 하는 거예요.

직군이 다른 사람과 모여서 일하는 것도 중요하지만, 같은 백엔드 개발자끼리도 인프라를 좀 더 이해하는 사람, CI/CD 경험이 있는 사람, 아니면 여러 트래픽을 처리할 수 있는 사람, 트러블슈팅 해본 경험이 있는 사람 등 다양하거든요. 그중에는 또 열정과 에너지가 넘쳐서 장애가 나면 누구보다 먼저 나타나 문제를 해결하는 사람도 있어야 하는 거죠.

그러니까, 결국 우리는 어느 누구도 세상이 필요로 하는 역량을 다 가질 수 없어요. 그렇기 때문에 팀으로 일해야 하고, 팀에는 다양한 사람이 있어야 해요. 과거에 대기업을 잠깐 경험했었는데, 대부분의 조직이 개인 단위로 일하더라고요. 각자 맡은 일만 해요. 팀이라는 이름으로 묶여 있기는 하지만 각자의 목표가 주어지고, 각자 자기 일만 합니다. 평가도 개인 단위로 하더라고요. 그래서 정말 팀으로 일하는 곳이 많지는 않다는 걸 느꼈어요. 이직할 때 그 곳이 자신이 팀으로 일할 수 있는 곳인지 생각해야 하고, 스스로도 팀을 만들려고 노력해야 한다고 말할 수 있을 것 같습니다.

안: 어떤 사람들은 이런 거시적인 트렌드 앞에서 깊이 파고 싶어도 시장 트렌드 때문에 주저하거나 불안감을 느낄 수도 있을 것 같아요.

박: 우리는 그냥 살아남을 생각을 해야 돼요. 지구상에 있는 모든 생물은 변화하는 세상에서 생존하는 것이 가장 중요한 목표예요. 우리의 미래는 변하고 예측 불가능하고 통제할 수도 없어요. 우리 인간은 그런 환경에 그냥 던져졌을 뿐이죠. 불안을 인정하고 앞으로 나아가야 합니다.

요새 ‘로드맵’ 같은 걸 만들어주는 사람들도 있잖아요. 저는 로드맵은 없다고 생각해요. 어떤 성공도 반복되지 않아요. 남의 성공을 따라할 필요는 없죠. 중요한 건 내가 살아남아야겠다는 엄연한 사실을 따르는 것이죠. 저는 산다는 것이  탐색 문제라고 생각해요. 모든 노드를 다 따라가 탐색하고 정답을 알 수 있는 방법은 없어요. 그러니 가능성이 높은 쪽을 선택해야 하는 거죠.

내 앞에 펼쳐진 선택지가 뭐고, 내가 선택할 수 있는 게 무엇인지, 그것뿐이에요. 선택에 정답은 없어요. 거기에 내가 먼 미래를 보고 유리한 쪽으로 선택할 거냐, 아니면 지금 당장 바라는 것을 선택할 거냐, 하는 건 내 알고리즘의 특성일 뿐이죠. 어떤 게 맞다 틀리다 할 수 없어요. 만약에 이 길 갔다가 아니다 싶으면 딴 길로 가면 되잖아요. 그냥 살아남으면 돼요.

안: 그러면 채용을 하실 때는 어떤 기준으로 하시나요?

박: 일단은 기술력보다 태도와 가치관을 봅니다. 스스로 동기부여된 사람, 보통 내적 동기가 있는 사람들이라고 하죠. 이런 사람을 뽑고 싶어요. 또 협력할 수 있는 사람, 동료와 함께 일하는 걸 좋아하는 사람인지를 봐요. 또 어떤 상황에서도 배울 수 있는 사람인지도 중요하게 봐요.

안: 그런 걸 가려내려고 자주 던지는 질문도 있으신가요?

박: 개발 관련된 책이나 글이나 영상 세 가지 기억나는 것을 이야기해달라고 해요. 그러면 굉장히 다양한 답이 나와요. 하버드 비즈니스 리뷰 이야기하는 사람도 있고 기초 자바 입문서를 말하는 사람도 있죠. 10년차 개발자가 자바 입문서 를 언급하더라고요. 그때 나오는 답변을 통해서 여러가지를 알 수 있는데, 개발을 얼마나 좋아하고 폭넓게 바라보는지 알 수 있어요. 또 아키텍처에 대해서도 질문하죠. 당신이 만든 아키텍처는 왜 그렇게 했고 어떤 부분에서 마음에 들었는지 물어요. 또 한 가지는 어떤 업무 환경이나 조건에서 가장 좋은 성과를 내냐고 물어요. 여기도 다양한 답이 나와요.

성장하는 리더란

안: 화제를 좀 바꿔볼게요. 컬리에서 프로그래머로서 비즈니스에 기여하고 있는 것은 어떤 것이 있나요? 

박: 컬리는 비즈니스가 급격히 성장한 회사잖아요. 개발 역량도 그 규모에 맞출 수 있도록 노력하고 있어요. 성장통을 겪고 또 이겨내는 과정에 있고, 개발 조직 또한 그 과정에 있습니다. 그래서 아직 채워나가야 할 여지가 많고 해결해야 할 레거시도 많지만 조직 역량이 계속 더 좋아질 여지도 그만큼 많이 있어요. 정리하자면, 비즈니스와 간격이 있는 내부 역량을 채워나가는 과정에 있다고 볼 수 있고요, 한편으로는 비즈니스를 견인할 수 있는 작업 아이디어도 계속 내놓고 있어요.

안: 컬리에 계신 지는 2년 정도 되셨죠. 그동안 컬리에서 배운 점이 있으신가요?

박: 저로서는 제가 맡은 일의 범위가 넓어지면서 배우는 게 많아요. 순수 개발 영역을 벗어나서 여러 차원의 커뮤니케이션도 하고, 의사결정도 하고요. 예전에는 내 역할이 아니라고 생각했던 것을 내 역할이라고 받아들이고 실행해가는 과정에 있어요.

조직 인원 수도 많고 업무 범위도 넓어지면서 책임의 범위도 넓어졌어요. 저는 기술 리더의 역할도 굉장히 중요하다고 생각하는데요. 많은 개발자가 예전에는 나이가 들면 원치 않아도 코딩에서 손을 놓고 관리자가 되어야 한다는 자조적인 생각을 갖고는 했거든요. 그런데 이제는 기술 리더가 정말 중요해요. 팀을 만들고 엮어서 조직화하고, 조직과 비즈니스가 맞물려 움직이게 하고, 효과적으로 일하고 계속 성장하도록 하는 데 기술 리더의 역할이 큽니다. 단순히 나이가 들어서 코딩할 짬밥이 아니니까 맡아야 한다는 생각으로 할 일이 아니죠. 기술 리더의 일 또한 전문적인 영역에 속하고 학습과 훈련이 필요하다고 생각해요. 저는 그런 영역에서 훈련하고 있다고 볼 수 있을 것 같아요.

안: 기술리더란 게 흔히 말하는 CTO하고 거의 같다고 보면 되나요?

박: CTO는 직책이고요, 직책이 없어도 기술 리더, 시니어 개발자, 스태프 개발자 이런 사람들은 리더십을 발휘해야 하잖아요. 그렇게 직책 여부와 상관 없이 리더십을 발휘하는 사람이 기술 리더죠.

제가 기술 리더십을 인식하기 시작한 건 한 10년 정도 되어가는데, 그동안 계속 기술 리더로서 역량을 넘어서는 역할을 부여받았고, 거기에 맞춰서 제가 스스로 역량을 키워가는 과정에 있어요. 이번에도 과거에 비해 큰 역할을 부여받았어요. 예전에는 한 프로덕트만 전담했다면 이제는 더 많은 프로덕트를 관리해야 하고 여러 조직을 이끌어야 하죠. 여기에 맞는 고민과 책임이 있어요. 또 저는 여기에 맞게 역량을 끌어올려야 하죠. 최근 10년은 이렇게 기술 리더로서의 역량을 키우는 데 집중해왔어요.

안: 더 큰 역할을 부여받아왔다고 하셨는데, 그러면 내 역량을 벗어나는 일들을 어떻게 습득해오셨나요? 

박: 사람은 결국 자기가 알지 못하는 건 인지하지 못하거든요. 이해하지도 못하고요. 그런 면에서 아는 게 중요하다고 생각해요. 책을 통해 알 수도 있고 존경하는 어떤 사람들의 모습을 통해서도 알 수 있어요. 어쨌든 배워서 아는 거죠. 다른 사람들의 선택이나 행동을 배워나가기도 하고요. 제가 예전 같으면 읽지 않았던 책이나 사람들에 관심을 갖기도 하고요. 그 총체를 존경할 수는 없지만 어떤 면은 존경할 수 있는 사람이 있다면, 그 존경할 수 있는 면에서 배우는 거고요. 제가 기존에 가지고 있던 문제 해결 방법을 다른 영역에 적용해서 효과를 보기도 해요.

예를 들어 아키텍처와 관련된 많은 지식이 조직에도 영향을 미치는 것 같아요. 조직 구성이나 운영에요. 결국 기존의 지식을 전용하거나 새로 책이나 문서를 읽거나 다른 사람에게 배우고, 배운 것을 이해하고 활용하려는 노력이 있죠. 그러면서 조금씩 배워가는 것 같아요.

안: 마지막으로, 프로그래머라면 이 정도는 주목을 하면 좋을 것 같다는 주제가 있나요? 

박: 저는 굳이 따지면 백엔드 개발자 출신이니까 그 관점에서 말하자면, 백엔드 개발자나 일반 애플리케이션 개발자들이 기본적으로 갖추면 좋겠다고 생각하는 건 데이터예요. 데이터를 이해하고 또 처리할 수 있는 방법을 연구하면 좋지 않을까 해요. 요새는 API 형태로 제공되는 기계학습 모델들이 많잖아요. 그걸 활용해서 뭔가 결과물을 내놓을 수 있는 경험이나 지식을 갖추는 게 좋지 않을까 하는 생각이 있습니다.

여기서 이야기하는 데이터는 고객을 이해할 수 있는 수단이에요. 고객이 남긴 흔적에서 인사이트를 도출하고, 그걸 활용해서 고객이 사용하기 좋은 애플리케이션을 만들어내는 건데요, 이런 건 대부분 데이터 분석가나 데이터 엔지니어, 머신러닝 엔지니어 같은 분들이 전문성을 갖고 있죠. 그런데 그 분들 도움 없이도 여러 클라우드 서비스에서 제공하는 API를 활용해서 낮은 수준이지만 적당한 수준의 결과물을 내놓을 수도 있거든요. 남의 영역이라고 선을 긋기 보다 그런 것에도 관심을 가져보면 좋겠어요.

안: 팀에 데이터 전문 인력이 없으면 로그 열어보고 가공해서 사용해볼 수 있는 정도의 노력은 필요하다는 말씀으로 이해하면 되나요?

박: 본인이 직접 가져다 쓸 수 있는 것도 좋고, 데이터 사이언티스트랑 같이 협업하려고 해도 어느 정도 이해는 해야 할 거예요. 내가 뭘 요구하고 뭘 받아야 하는지는 알아야 하니까요. 데이터를 처리하는 다양한 전략에 대해 이해하고 다양한 아키텍처를 탐색해보라는 얘기를 하고 싶어요.

또 한가지는 모든 개발자가 읽어야 한다고 생각하는 책이 있어요.

<구글 엔지니어는 이렇게 일한다>라는 책인데요, 책에 있는 내용은 많은 사람들이 기본적으로 상식처럼 알아야 한다고 생각합니다. 요즘에는 소프트웨어 엔지니어링에 대한 관심이 너무 낮아요.

마치며

워낙 주옥같은 이야기가 많아서 사족이 될까봐 코멘트도 자제했습니다. 다만, 해커에 대한 박성철 님의 관점이 너무나 강렬해서인지 최근 있었던 다른 일과 제 머릿속에서 상승작용을 일으킨 부분을 언급하며 마치고 싶습니다. 이전에 쓴 테스트 관련 글이 인연이 되어 Kent Beck에게서 다음과 같은 메시지를 받은 일이 있습니다.

DeepL을 이용한 자동 번역 결과는 다음과 같습니다.

“오늘 아침에 일어나면서 이런 생각이 들었습니다. 제 인생의 전반적인 사명은 괴짜들이 세상에서 안전하다고 느끼도록 돕는 것입니다. 인종, 종교, 헤어스타일, 음악적 취향, 언어에 관계없이 모든 괴짜들이요. 그렇기 때문에 여러분의 피드백이 매우 소중합니다. 피드백은 제가 더 많은 사람들과 소통하는 데 도움이 되니까요.”

인터뷰 내내 강렬한 인상을 주었던 해커란 표현과 Kent Beck이 돕고 싶어하는 Geek 사이에는 어떠한 연관성이 있다는 생각이 들었습니다. 그리고 여력이 된다면 이 시리즈 이후에 이에 대한 견해를 가진 분들을 찾아 영감을 기록할 수 있는 새로운 도전을 해 볼까 합니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.