‘리스펙트’ 받는 개발 리더란? 라인게임즈 이도행 테크니컬 디렉터

[커리어 리팩토링: 개발자의 성장법] 10. 라인게임즈 이도행 테크니컬 디렉터 인터뷰

‘좋은 리더’란 어떤 사람일까요? 경청, 직관, 논리력, 분석력, 커뮤니케이션, 피드백 등 좋은 리더가 갖춰야 할 다양한 역량이 있지만, 무엇보다 함께 일하는 팀원들의 ‘신뢰’를 얻는 것이 중요할 겁니다. 이번에 소개할 개발자 역시 좋은 리더란 무엇인지, 어떤 리더가 될 것인지에 대한 고민을 거듭한 인물입니다. 직방, 엔씨소프트, 넥슨코리아 등 IT 기업을 거쳐 온 10년 차 소프트웨어 엔지니어이자, 현재 라인게임즈에서 ‘테크니컬 디렉터’로 활동 중인 이도행 개발자가 그 주인공인데요.

그는 개발 경력으로는 6년 차가 되던 해, 29살이라는 비교적 이른 나이에 리더를 맡게 됐습니다. 팀의 리더가 된 후, 그가 처음 받았던 미션은 바로 팀원들의 ‘리스펙트를 받는 것’이었는데요. 이 리스펙트의 의미를 깨닫기까지도 생각보다 오랜 시간이 걸렸다고 합니다. 그저 ‘혼자서만 열심히 일하는 리더’가 된 적도 있고요. 그래서 선택한 방법이 바로 팀원들에게 먼저 ‘리스펙트를 주는 것’이었는데요. 팀원들이 가진 각자의 장점을 발굴하고 적극적으로 소통한 결과, ‘리스펙트’를 받는 리더가 될 수 있었습니다.

이처럼 한 단계씩 차근차근 리더십 경험을 쌓아온 이도행 개발자는 현재 개인 블로그, SNS에도 ‘좋은 팀이 최고의 프로덕트를 만든다’라는 메시지를 전하고 있는데요. 최근 라인게임즈에 합류하여, ‘테크니컬 디렉터’로 활동 중인 이도행 개발자에게 리더십의 의미와 개발자 커리어에 관한 이야기를 들어봤습니다.

‘리더십’을 고민하는 개발자

Q. 29살에 처음 리더 역할을 맡으셨어요. 팀을 리딩하면서 가장 어려웠던 점은 무엇이었나요? 이를 어떻게 극복해 나가셨는지도 궁금해요.

아무래도 ‘피드백’하는 과정이 가장 어려웠죠. 특히 저보다 연차도, 나이도 많은 팀원들에게 안 좋은 피드백을 줘야 할 때 힘들었어요. 어떻게 해야 이 사람의 기분이 상하지 않으면서도, 제 의견을 잘 전달할 수 있을지 고민이 많았어요. 그래서 우선 리더십 관련 책들을 읽었던 것 같아요. 저는 뭔가 궁금하거나 해결하고 싶을 때, 책에서 힌트를 얻는 편이거든요. 그중에서도 ‘실리콘밸리의 팀장들’과 ‘리더의 용기’라는 책에서 많은 도움을 받았고요.

Q. 책과 경험에서 얻은 ‘피드백을 잘하는 방법’은 무엇이었나요?

리더로서 피드백을 어떻게 솔직하게 줄 수 있을지와, 내 피드백이 ‘이 사람에게 좋은 영향을 줄 수 있다면’ 피드백하는 게 맞고, 그저 ‘기분 나쁜 공격으로 끝날 것 같다면’ 안 하는 게 맞다는 사실을 깨달았어요. 이를 판단하는 저만의 기준을 세울 수 있었고, 또 리더로서 인정받기 위해선 팀원들의 ‘리스펙트’가 무엇보다 중요하다는 점도 알게 됐죠.

Q. 어떤 점에서 ‘리스펙트’가 중요할까요?

팀장은 결국 팀원들의 리스펙트가 있어야 ‘리더십’이 완성된다고 생각해요. 이게 없으면 자칫 “네가 왜 지시를 해? 나보다 잘났어?”로 이어질 수 있거든요. 그래서 리스펙트를 채우는 과정이 중요하고 생각보다 오래 걸렸어요. 사실 리더라는 직함은 위에서 주어질지 몰라도, 진짜 팀원들이 따르는 리더가 되려면 적어도 1년 안에는 실력을 증명해야 해요. 

다만 리스펙트를 못 받았다고 권한으로 압박하려고 해선 안 돼요. 그런 분들도 종종 봤는데, 최악의 방법이라고 생각하거든요. 저는 리더와 팀원 간에도 서로 ‘배우는 관계’가 되는 것이 중요하다고 봤는데, 우선 “나에게는 이러한 장점이 있어서 이런 피드백을 잘 줄 수 있다”로 접근했어요. 또 반대로 제가 팀원들에게 배운 점이 있다면, “덕분에 좋은 영향을 받았다”라고 먼저 리스펙트를 보냈습니다. 이런 상호작용이 꼭 필요하다고 봐요.

Q. 도행 님이 생각하는 ‘리더십’이란 무엇인가요?

제 생각에 리더십이란 ‘심리적 안정감’을 얼마나 잘 구축할 수 있느냐에 달린 것 같아요. 저에게도 큰 영향을 준 리더분이 있는데, 그분은 팀에 ‘심리적 안정감’을 잘 세팅해 주셨어요. 사실 이 개념은 ‘두려움 없는 조직’이라는 책에 나오는데, “구성원이 업무와 관련해 그 어떤 의견을 제기해도 벌을 받거나 보복당하지 않을 거라고 믿는 조직 환경”을 뜻해요. 최소한 리더에게는 솔직히 말할 수 있는 토대가 마련되어야 한다는 것이죠. 이런 과정을 통해 리더로서 팀워크가 좋은 팀을 만들 수 있다고 생각해요. “좋은 팀이 최고의 프로덕트를 만든다”라는 게 제 신조이기도 하고요.

Q. ‘심리적 안정감’은 어떻게 세팅할 수 있나요?

다양한 방법이 있을 텐데, 제 경험을 말하자면 저는 팀원들에게 최대한 정보를 투명하게 주려고 노력했어요. ‘지금 회사가 이런 상황이고, 우리 팀에서 A님에게 바라는 건 이러한 것들이니 이렇게 해주면 좋겠다.’라고 최대한 투명하게 얘기했죠. 물론 진짜 엠바고는 공개할 수 없었지만, 그래도 최소한 ‘지금 어떤 상황이고 이런 일들이 있을 수 있다.’ 정도는 팀원들도 알아야 한다고 생각했어요. 이렇게 하다 보니, 자연스럽게 동기부여도 되고 팀원들도 저한테 솔직하게 얘기해 주는 스타일이 된 것 같아요.

Q. “좋은 팀이 최고의 프로덕트를 만든다.”라는 생각은 어떻게 갖게 되셨는지 궁금해요. 팀 빌딩에서 어떤 비하인드가 있었나요?

일하면서 개발이 엎어지거나, 내부 사정으로 인해 프로젝트가 와해된 적이 종종 있어요. 그때 아쉬웠던 점이 합이 잘 맞는 팀들이 해체되는 거였죠. 팀이 해체되면 다른 팀에 면접을 보고 들어가야 하는 형태였는데, 그렇게 팀에 합류하는 분들은 적응도 잘 못하고 힘들어하기도 했어요.사실 프로젝트가 드랍되는 이유는 다양한데, 좋은 팀을 꾸리는 건 정말 귀중한 경험이거든요. 

특히 전 개인적으로 모든 노하우는 개인이나 팀에 남는다고 생각해요. 프로젝트나 회사에 남는 게 아니라요. 그래서 팀을 좀 더 소중히 여겨야 한다고 생각하는데요. “좋은 팀이 최고의 프로덕트를 만든다”라는 문장 자체는 ‘슈퍼셀’이라는 게임 회사의 신조에서 가져온 거예요. 슈퍼셀은 프로젝트의 드랍은 물론, 론칭에 대한 결정까지 팀으로 하는 문화를 가졌는데 그로 인해 지속적으로 좋은 결과를 내고 있죠. 개인적으로 정말 공감하는 철학이라서, 저 또한 이런 생각을 전하게 된 것 같아요.

Q. 그럼 리더로서 팀원들에게 바라는 점이 있다면 어떤 걸까요?

리더십을 회고하면서 느낀 점이 있어요. 첫 번째로 저는 리더로서 궂은 일을 맡아서 하고 팀원들에게는 좀 재밌는 일들을 주려고 했거든요. 그게 1년까지는 좋았어요. 그런데 1년이 지나니까 오히려 역효과가 생기더라고요. 회사 생활에서 늘 재밌는 일만 할 수 없는데, ‘재미없는 일은 별로 하고 싶지 않다’가 돼버린 거죠. 그래서 어떻게 하면 이걸 개선할 수 있을지 많이 고민하다가, ‘디스어그리 앤 커밋(disagree and commit)’이라는 아마존 구성원들의 문화를 퍼뜨렸어요. “동의하지 않아도 헌신한다.”라는 뜻인데요. 우리는 회사라는 조직에서 함께 일하고 있기 때문에, 언제나 재밌는 일만 할 순 없어요. 내가 잘하는 일에만 몰입하기보다는 다양한 일에 마음을 열고 도전할 수 있길 바라죠.

두 번째로는 의외로 개발자 중에서는 리더가 되고 싶어 하는 분들이 없는 것 같아요. 그냥 ‘나는 개발만 하고 싶다.’, ‘리더가 되면 커뮤니케이션하기 어려울 것 같다.’라는 편견에 빠져 있는 점이 아쉬워요. 리더십 쪽으로는 더 성장하려고 하지 않는데, 리더십을 공부하고 함께 고민할 수 있는 젊은 리더들이 더 많아졌으면 좋겠어요.

Q. 아직 리더가 아닌 상황에서 리더십을 경험해 보거나, 준비할 수 있는 방법이 있을까요?

현재 주니어들만 있는 팀이거나, 중니어(미드레벨) 정도의 팀에서 리더십을 경험해 보려면 서로에게 멘토가 되어 주는 방법이 있어요. 저도 업계에서 만난 동기들 중 좋은 영향력을 주는 친구들이 있거든요. 어떨 땐 제가 배우기도 하고, 알려주기도 하죠. 그러다 보면 개인의 역량도 성장하지만, 어느 정도의 리더십도 배울 수 있다고 생각해요. 

간혹 주니어 레벨이 많은 회사에 일하는 분들과 대화해 보면 팀에 리드급, 시니어급을 뽑으면 모든 일이 해결될 거라고 믿는 경우가 있어요. 근데 사실 모든 걸 해결해 주는 리더를 찾는 건 매우 어려운 일이거든요. 만약 그런 리더를 만났다면 정말 행운이지만, 못 만났더라도 서로가 서로에게 좋은 리더가 되어줄 수 있어요. 우리 팀에 어떤 리더가 필요한지 고민해 보면서, 내가 리더라면 어떻게 할 수 있나 함께 의논해 보세요. 개인적으로도 성장할 수 있고, 리더십을 미리 경험해 볼 수 있을 거예요.

‘게임’부터 ‘메타버스’ 개발까지

Q. 개발자로서 첫 경력을 ‘게임 회사’에서 시작하셨어요. 특별한 이유가 있었나요?

사실 다양한 길이 있었는데 저는 ‘로망’을 따라갔던 것 같아요. 어렸을 때부터 게임을 좋아해서 직접 만들어 보기도 했었고, 장래 희망에 ‘게임 프로그래머’를 적어서 내는 학생이었거든요. 대학 졸업 전에 병역 특례 산업체를 찾다가, ‘마이에트 엔터테인먼트’라는 게임 회사를 알게 됐고, 거기서 게임 개발을 시작하게 됐어요. 생각해 보면 주변 지인들과 게임이라는 공통점으로 뭉칠 때가 많았거든요. 단순히 플레이어들이 아니라 메이커들도 있었는데, 직업적으로 선택하기 전부터 이미 많은 영향을 받지 않았나 싶어요. 

Q. 게임 개발자가 되어 보니 어떠셨나요? 이후에도 이스트소프트, 넥슨 등에서 쭉 게임 프로그래머로 활동하셨어요.

게임을 좋아하니까 만드는 작업도 역시 재밌었어요. 마이에트 다음으로 간 이스트소프트는 원래 ‘알집’, ‘알약’으로 유명한 회사인데요. 게임도 만든다고 하길래 흥미가 생겼어요. 그때 만든 게 ‘카발2’라는 게임이고, 라이브러리 개발을 했어요. 내부적인 툴을 만들거나, 게임 콘텐츠 중에 일부를 담당했었죠. 그런데 여기선 게임 개발 외에도 직업적인 성장을 할 수 있었어요. (어떤 점에서요?) 역사가 꽤 오래된 회사인만큼, 승진 시스템이 체계적으로 잘 갖춰져 있었거든요. 자연스럽게 ‘커리어적으로 어떻게 성장해야겠다’라는 생각을 자주 한 것 같아요. 

그리고 다음 회사인 넥슨에서부터 본격적으로 게임을 만들기 시작했어요. 사실 이전에는 게임의 핵심을 만든 건 아니었는데, 넥슨에서는 데브캣 스튜디오로 넘어가 ‘마비노기 모바일’도 만들고, 신규 프로젝트에도 많이 참여했어요. 프로그래머로서 코딩을 가장 많이 했던 시기였죠. 또 데브캣에서는 처음으로 리더를 맡기도 했고, 어떻게 하면 더 좋은 게임을 만들 수 있을지 고민하면서 게임 제작 파이프라인에 대해 많이 배웠죠. 

Q. 좋아하는 분야를 선택했어도 어려운 점은 있었을 것 같아요.

물론 어려운 점도 많았는데 우선 게임 제작 업계가 프로덕션에 약하다는 걸 느꼈죠. 예를 들어, 프로그래밍 잘하는 사람, 아트를 잘하는 사람은 많은데 이걸 종합해서 론칭까지 이끌어가는 과정을 할 줄 아는 사람이 많이 없었어요. 이게 PD의 역할인데, 그 수가 적기도 하고 이 직군을 키우려는 프로세스도 부족했던 것 같아요. 그냥 잘하는 프로그래머를 뽑아야지, 잘하는 기획자를 뽑아야지 해서 성장해 온 느낌이라 아쉬웠죠.

그리고 종종 커뮤니케이션에서 문제가 발생할 때도 있었는데, 흔히 ‘독성 말투’라고 하는 시니컬한 화법을 쓰는 분들이 있거든요. IT 커뮤니티에서도 “독성 말투 고쳐야 합니다.”라는 주제로 여러 번 올라오기도 했고요. 아무래도 원활한 커뮤니케이션이 어려울 때, 그 지점에서 고민이 많았던 것 같아요.

Q. 게임 업계에서 쭉 계시다가, 2021년에는 프롭테크 기업인 ‘직방’을 선택하셨는데 어떤 계기가 있으셨나요?

직방에 가기 직전에는 잠깐 엔씨소프트에 있었어요. 그때 고민했던 게 ‘비즈니스적 마인드를 어떻게 하면 키울 수 있을까?’였는데 제 나름대로 리더도 해봤고, 게임 개발도 해봤고, 이제는 비즈니스적인 면에서 더 성장하고 배우고 싶었거든요. 그래서 CEO의 바로 밑에서 일하는 프로젝트를 진행해 보고 싶다는 생각이 있었고, 직방에서 좋은 기회를 얻게 됐어요. ‘CEO는 어떤 마인드로 일할까? 개발자들에게 어떤 생각을 갖고 있을까?’ 같은 궁금증으로 선택했던 것 같아요. 

(궁금증은 해결되셨나요?)‘CEO의 마인드란 무엇인가’를 많이 배웠다고 생각해요. 특히 회사의 비전과 반대되는 VOC(Voice of Customer)가 많을 때 어떤 선택을 내려야 할지 몰랐거든요. 그런데 유저의 목소리는 근거가 되고, 결국 강력한 비전이 있어야 한다는 걸 알았죠. VOC는 서비스 도입 이후부터 쌓이는데, 우리는 그걸 예측해서 우려하는 일이 많잖아요. ‘이건 좀 위험하지 않을까? 유저들이 싫어하지 않을까?’라는 생각이 드는데, 이때 CEO의 입장은 아직 도입을 안 해봤는데 어떻게 알 수 있냐는 거죠. 일단 도입해서 반응을 보고 결정해도 된다는 점을 깨달았어요. 사실 게임을 만들 땐 그렇게 하기 힘들거든요. 그래서 실제로 우려했던 걸 도입했을 때, VOC가 긍정적인 방향으로 바뀌는 것도 여러 번 경험했죠.

Q. 직방에서는 ‘소마(Soma)’라는 메타버스 가상 오피스 플랫폼을 개발하셨어요. 게임 개발과는 또 다른 경험이었을 것 같은데 어떠셨나요?

생각보다 다른 점이 많았어요. 우선은 사업팀과 같이 일한다는 점에서도 달랐고, 가장 큰 차이점은 VOC에서 온 것 같아요. 게임은 보통 몇 년이 걸려서 만들어지고, 론칭하고 나면 그때부터 결과가 쭉 나오는데요. ‘소마’ 같은 서비스의 경우 오픈 후, VOC가 들어오면서 사업 방향성에 맞춰 업데이트를 계속해요. 이런 점에서 게임이랑 좀 달랐고, 생각보다 더 다양한 VOC가 들어오기도 했죠. 

예를 들어, 저희는 메타버스를 하나의 게임처럼 만들었는데 생각보다 유저들이 조작을 잘 못해서 이걸 어디서부터 알려줘야 할지 고민이 많았죠. 가령 오류가 났을 때도 이게 소프트웨어의 문제인지, 장비의 문제인지, 와이파이 환경이 문제인지 이런 것들을 식별하는데 거의 1년을 쓴 것 같아요. 이런 점에서 저에겐 신선한 경험이었죠.

Q. 게임 프로그래머와 소프트웨어 엔지니어는 어떤 차이점이 있나요?

제 경험에 빗대어 얘기하면, 게임 프로그래머의 경우 고객이 명확하지 않아요. 그래서 본인의 ‘에고’를 반영하는 분들도 있고, ‘재밌는 게임’이라는 추상적인 개념을 쫓을 때가 더 많죠. 그래서 게임을 론칭했을 때 게임이 잘 될지, 안 될지 결과를 예측하기 어렵고 그에 따른 타격도 있죠. 게임을 개발할 때 대부분은 ‘워터폴’ 방식을 따릅니다. 게임을 완성하고 론칭해야 수익이 나는 구조이기 때문에 그럴 수밖에 없고요. 프로그래밍적으로 봐도 큰 시스템을 만들어서 하나의 게임이 완성되는 과정을 겪습니다. 

반면, 소프트웨어 엔지니어는 ‘애자일’ 방식을 선호하는 편이죠. 제품을 만들고 배포한 다음 계속 업데이트를 하잖아요. 비교적 타깃도 분명하고요. 소프트웨어 엔지니어는 보통 ‘문제 해결’에 더 초점을 맞춥니다. 예를 들어, “2주 단위로 배포하면서 문제가 해결되는지 보자.”가 되는 거죠. 그래서 VOC 체크도 더 중요하고요. 게임 개발과 소프트웨어 개발은 개발 방식부터 타깃까지 다른 점이 꽤 많다고 생각해요.

Q. 현재는 다시 게임 업계로 복귀하셨어요. 라인게임즈에서 ‘테크니컬 디렉터’를 맡으셨는데, 구체적으로 어떤 일을 하시나요?

‘테크니컬 디렉터’는 한마디로 리드 엔지니어라고 생각해 주시면 됩니다. 책임과 영향력을 가지고 팀의 엔지니어링을 총괄하는 역할이에요. 현재 저희 팀의 경우, 이제 막 세팅됐기 때문에 지금은 엔지니어링과 관련된 모든 일을 하고 있어요. 개발, DevOps, 데이터 구조, 프로젝트 세팅 등 기술이 들어가는 모든 걸 담당해요. 여기서 팀이 더 커지면 주로 엔지니어링 팀의 문화를 발전시키는 일, 기술이 올바른 방향으로 나아갈 수 있게 비전을 제시하고, 기술 관련 비즈니스를 책임지는 역할을 합니다. 

특히 엔지니어링 팀의 문화는 코드리뷰, 팀에서 생각하는 좋은 코드에 대한 합의, 코드 퀄리티를 높이는 방향으로 이끄는 것이라고 생각해요. 제가 잘할 수 있는 일이라서 기대하고 있고요. 앞서 “최고의 팀이 최고의 프로덕트를 만든다”라는 좌우명이 있다고 말했는데요. 실제로 제가 ‘최고의 팀’을 경험해 본 적이 있는데, 다양한 이유로 아직 ‘최고의 프로덕트’를 만들진 못했어요. 이번에 라인게임즈에 합류하게 된 건, 그때 ‘최고의 팀’이라고 생각했던 사람들과 다시 뭉칠 수 있다는 제안을 받았기 때문인데요. 이번에야말로 최고의 프로덕트를 만들어 내는 일을 해보고 싶어요. 

Q. 게임 개발자가 되려면 어떤 준비가 필요할까요? 게임 개발자를 꿈꾸는 분들에게 해주고 싶은 조언이 있다면요.

당연한 얘기겠지만 우선 게임을 좋아해야겠죠. 10년 이상 이 업계에 있으면서 게임을 좋아하지 않는 개발자는 못 본 것 같아요. 아, 참고로 게임을 잘해야 한다는 뜻은 아니에요. 저도 브론즈라서요. (웃음) 게임 개발자에게 또 하나 중요한 게 있다면, 바로 본인이 만들고 싶은 게임을 한번 깊이 있게 만들어 보라고 하고 싶어요. 최근에 게임 개발자 지망생들을 만난 적이 있는데, 호기심이 많이 없는 것 같아 아쉬웠어요. 

예를 들어, ‘마비노기 영웅전’ 모작을 만드는데 클라이언트-서버를 MORPG 구조로 만들고 끝을 내요. 저는 마비노기 영웅전은 논타겟 액션이 핵심이라고 생각하거든요. 거기까지 안 가는 거죠. 그리고 마인크래프트의 모작이라고 하면서, 정육면체 블록을 설치하는 걸 보여줘요. 마인크래프트의 핵심은 무한한 자동 생성과 시작하면 땅을 파고 들어가면서 다이아를 캐는 재미라고 생각하거든요. 물론 다른 재미도 있겠지만, 이렇게 핵심을 터치하는 최소한의 기능까지는 만들어봐야 하는 거죠. 이런 방향으로 포트폴리오를 구성하면, 본인이 원하는 게임 회사에 들어갈 확률도 높아지고, 앞으로 좋은 게임 개발자가 될 수 있다고 생각해요.

“앞으로 더 좋아질 수 있다”고 믿는 개발자

Q. 개발자로 활동한지 이제 10년 차가 넘으셨는데요. 개발자에게 ‘커리어’란 무엇일까요?

개발자에게 커리어란 ‘성장’인 것 같아요. 제가 멘토링을 해줄 때도 항상 하는 얘기가 “어떻게든 배울 만한 사람 밑에서 많은 것을 얻어가야 한다.”라는 말인데요. 개발자가 커리어를 잘 쌓으려면 성장이 필수라고 생각하거든요. 그런데 성장하는 방법 중 자기보다 나은, 더 실력 있는 사람을 통해 배우는 게 가장 빠르고요. 그다음엔 독학으로도 성장할 수 있는데 책이나 글, 영상 등을 보고 느낀 점을 정리하고, 나만의 것으로 구체화하는 과정이 필요해요. 이렇게 한 걸음씩 성장하면서 “나는 앞으로 더 좋아질 수 있다.”라고 믿는 게 중요합니다.

Q. 도행 님이 지금도 성장을 위해 노력하고 있는 것이 있다면요?

저는 책을 정말 많이 읽었고, 지금도 자주 읽으려고 노력해요. 사실 책을 좋아하던 학생은 아니었는데, 대학생 때부터 본격적으로 읽기 시작했어요. 그리고 주변에 커리어적으로 잘 된 분들을 보면 꼭 책을 추천해 주시더라고요. 저는 그중에서도 인문학과 관련된 개발 책을 많이 읽었어요. (어떤 책들인가요?) 대표적으로 <테크니컬 리더>, <생각하는 프로그래밍>, <읽기 좋은 코드가 좋은 코드다> 같은 책이 있고요. 리더십과 관련해서는 <개발 7년차, 매니저 1일차>라는 책을 추천해요. 독서 외에도 SNS, 블로그에 글을 쓰거나, 강의를 제작하는 일도 꾸준히 하려고 해요.

Q. 블로그에는 어떤 글을 올리세요?

주로 개발, 게임 개발, 리더십, 애자일, 읽은 책 등에 대해 쓰고 있어요. 저도 처음부터 다양한 글을 쓴 건 아니에요. 어느 순간 스스로 성장이 느려졌다고 느꼈는데, 평소 책을 많이 읽으니까 ‘이 내용을 글로 정리해 보자’ 하다가 시작하게 됐죠. (개발자에게 블로그 운영을 추천하시나요?) 개발자가 블로그를 운영하면 좋은 점이 많아요. 글로 생각을 정리하면 개인적인 성장은 물론 퍼스널 브랜딩에도 활용할 수 있죠. 제 경우엔 블로그를 보고 강의 제안도 들어와서 강의도 시작하게 됐어요. 다만 블로그를 단순히 수익 측면에서 접근하는 분들에겐 추천하지 않아요. 그렇게 하면 오래 운영하기 어려워요.

Q. 강의 제안은 어떻게 받아들이게 되셨나요?

고1 때 꿈이 선생님이었어요. 잠깐 그런 꿈을 가졌었는데, 제안을 받고 나니 코딩이라는 걸 한번 가르쳐 보고 싶다는 생각이 들었죠. 몇 년 전에 한창 코딩 붐이 있었을 때, 비전공자분들이 가장 많이 물어봤던 질문이 “부트캠프에 다니면 프로그래머가 될 수 있나요?”거든요. 사실 저는 냉정하게 생각해서 어렵다고 대답해요. 물론 그게 시작점은 될 수 있지만, 프로그래머가 되는 과정은 진짜 어려운 일이라고 생각하거든요. 대신 무조건 된다고만 하는 강의보다는 현실적으로 ‘파이썬’부터 맛보기 해보자는 마음에서 파이썬 강의를 시작하게 됐어요. 이걸 들었을 때 너무 어렵거나, 이해가 안 된다면 개발자의 길은 안 맞을 수도 있으니 고민해 보면 좋을 것 같아요.

Q. 멈추지 않고 무언가를 계속해 나갈 수 있는 동력은 어디서 나오나요? 

저는 마인드셋에서 동력이 나오는 것 같아요. 그중 하나가 자녀에게 떳떳하고 싶은 게 있었어요. “아빠는 프로그래머였어.”라는 과거형보다는 “아빠는 프로그래머야.”라고 말하고 싶은 거죠. ‘나는 이걸 끝까지 해봤어’를 보여주고 싶은 로망이 있었어요. 그리고 두 번째로는 발전하는 것 자체가 재밌다고 느껴요. 제가 느끼는 보상의 만족감 중에서 ‘성장’한다는 느낌이 가장 좋았거든요. 개발자로서 자기를 증명하는 것, 성장하는 것 자체가 동력이 된달까요. 세상엔 물론 뛰어난 사람들이 많지만, 그 사람들이랑 비교하기보다는 작년의 나 자신과의 비교를 좋아하는 편이에요.

Q. 무엇이 성공한 개발자라고 생각하시나요?

성공한 개발자는 결국 ‘프로덕트’가 있어야 할 것 같아요. 자기가 만든 대표적인 프로덕트가 있어야 하고, 그런 프로덕트를 만들 기회가 있다면 도전해야 하고요. 첫 번째로는 그런 비즈니스적인 성공이 중요하다고 생각하고, 두 번째로는 믿고 기댈 수 있는 팀원들이 있는 것도 성공한 개발자라고 생각해요. 그만큼 좋은 팀을 만나는 건 쉽지 않은 일이기 때문에, 팀을 잘 매니징해서 기대한 만큼의 성과를 낼 수 있다면 성공한 개발자의 모습이 아닐까 싶어요.

Q. 앞으로 어떤 직업인이 되고 싶으신가요? 꿈이 있다면요.

일단 성공하는 프로덕트를 만드는 직업인이 되고 싶고, 그 과정에서 영향력을 줄 수 있는 개발자가 되고 싶어요. 저를 통해 누군가가 더 좋은 개발자로 성장했으면 좋겠다는 꿈이 있어요. 지금도 멘토링을 하면서 그런 피드백을 받으면 동기부여가 많이 되는데, 앞으로도 강의, 블로그 등 어떤 채널을 통해서든 제가 가진 것들을 나눠줄 수 있는 좋은 영향력을 가진 사람이고 싶습니다.

김소희 에디터 [email protected]

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