*모 매거진에 제출하려고 작성했던 글인데 제출하는걸 깜빡해서 브런치에라도 올려둡니다.

간단하게 자기 소개 부탁드립니다.

안녕하세요. AB180에서 백엔드 개발을 총괄하고 있는 정주홍입니다. 디지털 마케팅 성과 측정을 도와주는 도구인 Airbridge라는 서비스를 개발하고 있습니다.

지금 계신 곳에서 개발을 하기 전까지 어떤 일을 하셨나요? 어디에서 어떻게 개발자로서의 이력을 쌓아오셨나요? 개발자가 되고 싶게 만든 특별한 동기가 있으셨나요?

코딩을 시작한 것은 고등학교 때부터였습니다. 어렸을 때 게임을 너무 좋아했었는데 내 손으로 게임을 만들고 싶다는 생각에 관련 학과가 있는 학교로 진학했었어요. 대학교에 진학한 후에도 실무에 관심이 많아서 방학에는 회사에서 일을 했었습니다. 학기 중에는 공부하고, 방학에는 회사를 다니고, 학기가 시작되면 다시 공부를 하는 식이었습니다.

원래는 주로 게임 회사에서 게임 클라이언트를 개발했었는데 외주를 하거나 다른 일을 하다보니 게임이 아니라 다른 분야에서도 일하는 경험이 점점 더 많아졌습니다. 지금은 저를 백엔드 개발자라고 소개하는게 맞을 것 같은데, 현재 일하고 있는 AB180에서 처음으로 백엔드 개발에만 집중하기 시작했습니다. 그렇게 이제 곧 5년이 되어갑니다.

내가 게임을 만들고 싶다는 생각 때문에 개발을 시작했던 것이지, 개발자라는 직업을 갖고 싶었던 것은 아니었습니다. 하지만 코딩을 계속 하다보니 그 자체로도 굉장히 재밌더라고요. 무엇보다도 내가 만든 소프트웨어가 의미있는 역할을 하고 있다는 것이 재밌습니다.

원래의 질문에 답하자면, 내가 원하는 것, 필요한 것을 직접 만들고 싶다는 것이 개발자가 되고 싶게 만드는 동기인 것 같습니다.

개발자로 일하면서 관찰자의 눈으로 IT 업계에서 목격한 최근의 가장 중요한 변화는 무엇인가요?

인공지능이 점점 더 생활 속으로 들어오고 있는 것이 가장 중요한 변화라고 생각합니다. 너무 뻔한가요?

옛날에 인공지능 하면 생각나는 그것과는 조금 다릅니다. 과거에는 인공지능 하면 터미네이터나 블레이드 러너, 아이 로봇과 같은 사람과 같은 인공지능을 먼저 떠올렸습니다. 사람과 같은 수준의 인공지능은 아직 만들어지지 않았지만 특별한 목적을 가진 인공지능들은 이미 우리의 생활 속을 침투하고 있습니다.

Youtube의 추천 컨텐츠, 쿠팡과 같은 쇼핑몰에서의 추천 상품, 곳곳에서 보이는 타겟팅 광고 등 온갖 것들이 내부적으로는 인공지능을 활용하고 있습니다. 일반적으로 코딩을 하듯이 rule에 따라 작동하게 프로그램을 만드는게 아니라 데이터를 넣어서 학습시키면 상황에 따라 잘 작동하는 프로그램을 만드는 식으로 바뀐거죠. 말하자면 프로그램을 만들던 때에서 프로그램을 하는 프로그램을 만들도록 바뀐 것입니다.

소프트웨어 시장에서도 변화가 일고 있습니다. 얼마 전에는 Github에서 Copilot이라는 서비스를 발표했습니다. 코딩을 대신해주는 서비스였어요. 물론 지금은 초창기인만큼 정말 개발자를 대체할 수 있는 수준이 되지 않습니다. 하지만 미래에는 간단한 프로그램 정도는 이런 서비스의 힘을 빌려도 될 지도 모릅니다. 개발자도 인공지능으로부터 일자리의 위협을 받지 않는 직업이 아닌거죠.

개발자의 구체적인 하루가 궁금합니다.

저는 개인 작업자보다 매니저 역할을 하고 있는 개발자라는 것을 먼저 말씀드리고 싶습니다. 미팅과 커뮤니케이션이 업무의 대부분을 차지하는데 특정 시간에만 미팅을 잡을 수 없다보니 일반적인 시간표를 말하기 어렵습니다.

출근하면 먼저 커피를 준비합니다. 하루를 시작하는 의식 같은거죠. 그리고 오늘 해야할 일을 파악합니다. 캘린더를 보고 언제 미팅이 있는지 확인하고요. 제가 진행해야할 티켓들을 다시 점검합니다. Slack에 아직 확인하지 않은 메세지들도 확인합니다.

미팅으로는 주기적인 One on one과 주간 미팅, 새로 진행할 작업에 대한 kick off, 면접, review 등이 있습니다. 업무 시간의 30% 정도는 미팅, 50% 정도는 커뮤니케이션, 나머지 20% 정도는 제 개인 작업에 쓰는 것 같아요. 개인 작업은 미팅과 커뮤니케이션이 없는 빈 시간에 합니다.

개발자로서 자신만의 원칙, 신념은 무엇인가요? 개발할 때 가장 중요한 가치는 무엇이라고 생각하시나요?

저는 무엇이든간에 축적되는 방향으로 일해야 한다고 생각합니다. 개발자라면 모두들 하는 경험이 바로 자동화일거예요. 똑같은 작업을 반복하지 않고 프로그램으로 최대한 자동화하면 소모되는 시간을 줄이고 그 시간에 다른 가치있는 일을 더 할 수 있습니다. 자동화 뿐만 아니라 비슷한 질문 답변을 반복하는 것을 줄이기 위해 문서화를 하는 것 등이 축적하기 위한 노력과 같은 맥락이라 생각합니다. 다르게 말하면 앞으로의 레버리지가 더 큰 활동을 하는 것이 중요하다고 생각합니다.

제가 생각하는 개발자라는 업의 본질은 예쁜 프로그램을 만드는게 아니라 컴퓨터를 활용하여 문제를 해결하는 것입니다. 내 눈에 예쁜 코드를 짜느라 문제 해결이 늦어져선 안 됩니다. 즉, 코딩은 목적이 아니라 수단이어야 합니다.

업의 본질이 컴퓨터를 활용하여 문제를 해결하는 것이기 때문에 코드를 작성하는 행위에 너무 매몰되선 안 됩니다. 가끔 기획에 참여하는 것을 꺼리는 개발자 분들이 계신데요. 저의 가치관은 다릅니다. 기획 또한 문제 해결 과정의 일부이기 때문에 적극적으로 참여해야한다고 생각합니다. 커뮤니케이션, 문서화 등도 신경 써야한다는 것은 당연하겠죠.

지금 계신 그 곳의 개발 문화는 어떤가요? 좋은 개발 문화라는 것은 무엇일까요?

제가 생각하는 개발 문화의 목표는 두 가지 입니다.

더 좋은 프로덕트를 만드는 것

구성원들의 성장

이 두 가지 목표가 서로 잘 조화를 이뤄야 합니다. 좋은 프로덕트를 만드는 것은 당연히 해야할 일이고, 구성원들이 성장하면 프로덕트를 더 잘 만들 수 있기 때문입니다.

저희 팀의 개발 문화를 소개할 때 자주 이야기하는 문화가 몇 개 있습니다.

리뷰: 코드 리뷰, 테크 스펙 리뷰 등 결과물을 다른 사람이 리뷰하면서 더 퀄리티를 높이는 문화입니다. 리뷰어로부터 받은 피드백이 성장에 도움 되기도 합니다. AB180의 리뷰 문화에 대해서는 회사 블로그에 공유한 것이 있으니 참고하셔도 좋을 것 같습니다.

포스트모텀: 문제가 발생했을 때 근본 원인을 파헤치고 고쳐서 문제가 재발하지 않도록 노력하는 문화입니다. 문제가 재발하지 않게 보완함으로써 프로덕트는 더 견고해집니다. 또한, 근본 원인을 찾고 재발 방지 액션 아이템을 생각하는 과정 자체가 많은 고민을 요구하기 때문에 포스트모텀을 하는 개개인에게 성장의 기회가 됩니다.

KT(Knowledge Transfer): 매주 1~2시간 정도씩 지식 공유 세션을 진행하는 문화입니다. 주제로는 새로 학습한 것, 포스트모텀 내용 공유 등이 있습니다. 발표자가 정리한 내용을 단시간에 가져갈 수 있기 때문에 청중들에게 도움될 뿐만 아니라 발표자도 발표를 위해 자세히 공부를 해야하기 때문에 학습에 도움됩니다.

사실 그리 새로울 것은 없습니다. 저는 독특한 개발 문화보다 개발 문화가 정말로 작동하게 만드는 것이 중요하다고 생각합니다. 코드 리뷰를 한다고 하면서도 실제로는 하지 않는 회사들의 이야기는 많이 들어보셨을겁니다. 그런 경우 리뷰 문화가 있다고 보기 어려울 것입니다.

요약하자면 개발 문화의 목표 달성에 도움되는 문화들을 잘 실천하는 것이 좋은 개발 문화라고 생각합니다.

개발자의 기본기, 혹은 좋은 프로그래머의 자질은 무엇이라고 생각하시나요?

좋은 프로그래머의 자질은 무엇인가에 대해 오래 고민해왔는데요. 요즘은 커뮤니케이션 스킬이 중요하다는 생각을 자주 하고 있습니다. 코딩 스킬 자체는 어느 정도 수준까지 올라가는데 긴 시간이 걸리지 않지만 커뮤니케이션 스킬은 쉽게 개선되기 어렵기 때문입니다.

혼자가 아니라 팀으로 일하면 다른 사람들과 커뮤니케이션이 필수적입니다. 다른 사람들에게 생각을 잘 구조화해서 전달하지 않으면 커뮤니케이션에 많은 비용이 들 수 밖에 없습니다. 상대방이 내 생각을 이해하는데 많은 노력을 기울여야 하기 때문입니다. 내가 1의 노력을 들여서 만든 메세지를 같이 일하는 10명이 각자 1의 노력을 들여야 이해할 수 있다면 총 11의 리소스가 쓰입니다. 하지만 내가 2의 노력을 들여서 만든 메세지를 같이 일하는 10명이 각자 0.5의 노력만 들여도 이해할 수 있다면 총 7의 리소스만 쓰입니다. 당연히 후자가 더 낫습니다.

개발자의 업무에 코딩 못지 않게 많은 부분을 차지하는 것이 커뮤니케이션인데, 커뮤니케이션이 좋지 않은 경우 함께 일하는 모든 사람들이 영향을 받습니다. 개발자들의 커뮤니케이션 문제는 꽤 옛날부터 화두였다고 생각합니다. 컴퓨터와의 대화에 익숙한 대신 사람과의 대화에 약한 모습을 보이는 것을 당연하게 느낄 정도로요. 커뮤니케이션 스킬 요구치가 낮다는건 오히려 더 슬퍼해야할 일입니다. 말이 잘 통하지 않는 상대와 일하고 싶은 사람은 없을테니까요.

그렇기 때문에 좋은 프로그래머의 자질로 훌륭한 커뮤니케이션 스킬을 들고 싶습니다.

개발 관련해서 기술부채의 해결이나 자기계발은 어떻게 하고 계신가요?

기술 부채 해결과 자기 계발은 꽤 다른 주제라서 각각 생각을 말해보겠습니다.

스타트업 입장에서 기술 부채는 생존의 증거라고 생각합니다. 기술 부채를 만들면서도 댓가로 얻은 무언가가 분명 있을겁니다. 저희도 여러가지 기술 부채를 갖고 있습니다. 대표적인게 하드 코딩입니다. 하드 코딩을 하지 않았더라면 고객에게 가치를 빨리 제공할 수 없었을겁니다.

하드 코딩을 없애려면 리팩토링을 잘 해야 합니다. 하지만 리팩토링할 시간이 항상 충분한건 아닙니다. 게다가 리팩토링한 코드를 배포한 뒤 문제가 다시 생기지 않는다는 보장도 없습니다. 또는, 리팩토링을 하는 것보다 중요한 일들이 쌓여 있을 수도 있습니다.

냉정하게 말해서 하드 코딩 때문에 문제가 다시 생기는 경우는 그 코드를 수정할 일이 또 생겼을 때 입니다. 하드 코딩을 했을 때 문제 없는걸 확인하고 배포 했었을테니까요. 하지만 만약 코드 수정을 해야할 일이 생겼을 때 하드 코딩으로 인해 유지 보수성이 매우 떨어지는 상황이라면 리팩토링을 적극 고려해야 합니다. 이런 경우에는 리팩토링을 위한 시간을 굳이 따로 잡기보다는 원래 해야할 작업 내에 포함하도록 하는 편입니다. 이 의사 결정을 할 수 있는 명확한 기준을 말하기는 어렵네요.

자기 계발의 경우 저는 다른 분들과 많이 다른 편입니다. 많은 분들이 퇴근 후 업무와 관련 없는 취미 프로젝트를 하면서 새로운 학습을 하는 것을 선호하는걸로 알고 있는데요. 저는 업무와 최대한 관련된 학습을 하는 것을 좋아합니다. 이 방식을 선호하는 것에는 두 가지 이유가 있습니다.

첫 번째 이유는 제가 동시에 여러 일에 집중을 잘 못하기 때문입니다. 취미 프로젝트를 한다면 퇴근 시간 후에 그 일을 해야할텐데 업무 시간 중에는 회사 일에 집중하고 퇴근 후에는 취미 프로젝트에 집중하는 것을 잘 병행할 자신이 없습니다.

두 번째 이유는 업무와 관련된 공부를 하면 더 구체적인 요구 사항을 생각할 수 있을 뿐만 아니라 목표도 잘 잡을 수 있기 때문입니다. 예를 들면, 저희 팀의 중요한 목표 중 하나는 더 저렴한 비용으로 트래픽을 처리하는 것인데요. 기존 시스템의 어떤 부분에 새로운 기술을 적용하여 비용 개선을 할 수 있을지 알아본다면 요구 사항을 더 구체적으로 생각할 수 있습니다. 적용 후 감소되는 비용도 계산 가능할 것이구요. 프로덕트에 적용한다면 실제로 비용 절감에 도움이 됩니다. 당연히 그 과정에서 많은 학습을 합니다.

이러한 이유들 때문에 너무 회사 일에 매몰된다는 생각만 버리면 업무와 관련지어 자기 계발을 하는 것이 훨씬 효과적인 방법이라 생각합니다.

그동안 읽었던 책들 중에서 개발하는데 가장 도움을 준 책 또는 가장 좋았던 책은 어떤 책인가요?

저는 흔히 말하는 공룡책을 꼽고 싶습니다. 풀네임은 Operating System Concepts 이라는 책입니다.

개발자가 개발한 프로그램은 대부분 운영체제 위에서 실행됩니다. 운영체제를 몰라도 작동하는 프로그램을 개발할 수 있지만 내가 만든 프로그램이 어떻게 실행되는건지는 흐릿합니다. 프로세스와 쓰레드는 어떻게 관리되는건지, 메모리를 할당 받으면 그 뒤에서 어떤 일들이 일어나는건지, 파일 시스템은 어떻게 작동하는지 등 요즘에는 많은 것들이 하이 레벨 API로 추상화 되어 있습니다. 잘 몰라도 쓸 수 있죠.

운영체제를 공부하고나면 많은 프로세스들이 어떻게 동시에 실행될 수 있는지, 가상 메모리를 이용하여 프로세스마다 독립된 메모리 공간을 활용하는 방법, 파일 시스템에서 파일을 다루는 원리 등을 알게 됩니다. 드디어 프로그래밍과 관련된 것들을 귀납적으로 아는 것이 아니라 연역적으로 이해할 수 있습니다.

Kafka, Elasticsearch 등 현란한 기술들도 그 안은 기본 원리들로 이뤄져있습니다. 저 또한 분산 처리 시스템을 개발하면서 새로운 기술들을 많이 학습했는데, 기본 원리에 대한 이해가 있었기 때문에 새로운 것을 공부해야할 때도 빠르게 학습할 수 있었습니다. 뿐만 아니라 트러블 슈팅을 해야할 때도 상상을 하는게 아니라 논리적으로 추론할 수 있었습니다.

기본 원리 중에서도 운영체제에 대한 이해가 가장 도움됐다고 생각하기 때문에 가장 도움 됐던 책으로 공룡책을 꼽고 싶습니다.

주변의 개발자 동료 혹은 후배에게 권하고 싶은 책 5권을 추천해주세요.

기술서와 자기 경영서 몇 권을 권하고 싶습니다.

엔터프라이즈 애플리케이션 아키텍처 패턴(저자: 마틴 파울러): 간단한 애플리케이션 개발을 넘어서 엔터프라이즈 수준의 애플리케이션 개발을 하려면 어떤 고민을 해야할 지, 어떻게 개발해야할 지 배울 수 있는 책입니다.

데이터 중심 애플리케이션 설계(저자: 마틴 클레프만): 분산 처리 시스템에 대한 개론서입니다.

사이트 신뢰성 엔지니어링(저자: 벳시 베이어 외): 프로덕션 운영을 잘 하기 위한 구글의 노하우들을 배울 수 있는 책입니다.

자기 경영 노트(저자: 피터 드러커): 지식근로자로서 살아가기 위한 지침서입니다.

원칙(저자: 레이 달리오): 인생을 살면서, 일을 하면서 어떤 원칙을 갖고 살아야 할 지 고민할 때 도움을 줄 수 있는 책입니다. 원칙 없이는 매번 의사 결정을 할 때마다 흔들릴 수 밖에 없다는 생각을 하곤 했는데요. 내 인생에서의 원칙을 세울 때 참고할만한 레이 달리오의 원칙들이 정리되어 있습니다.

올해의 계획을 들려주세요.

AB180이라는 회사를 더 많은 개발자 분들에게 알리고 싶습니다. AB180이 마케팅, 그로스 해킹과 관련된 일을 많이 하는 회사다보니 마케터 분들에게는 알려진 반면 개발자 분들에게는 여전히 생소한 회사라고 생각합니다.

마케팅 성과 측정을 위해 그 뒤에서는 생각보다 많은 엔지니어링을 하고 있습니다. 단적인 예가 트래픽 처리입니다. 아직 작은 회사임에도 불구하고 하루에 10억건 이상의 이벤트를 받아서 처리하는 시스템을 운영하고 있습니다. 앞으로 늘어날 고객을 고려했을 때 몇 십 배, 몇 백 배 더 많은 양을 처리하게 될 예정이고요. 특히 시스템을 비용 효율적으로 만들기 위해 많은 고민을 하고 있습니다.

트래픽 처리가 아니더라도 새로운 성과 분석 기법을 적용하기 위해 머신 러닝을 적용하는 등 다양한 엔지니어링을 하고 있습니다. 앞으로 해보고 싶은 것도 많고요. 그 과정에서 알게 되는 것들과 경험담들을 더 많이 외부에 알리고 싶습니다.

지금 책상 위에 어떤 책이 있나요?

앞으로 더 커질 팀을 잘 운영하고 싶어서 요즘은 High Output Management를 다시 읽고 있습니다.

만약 개발 관련된 책을 직접 집필한다면 어떤 주제로 책을 써보고 싶으신가요?

작은 스타트업에서 유니콘 스타트업이 되기까지 개발자로서 프로덕트를 만들어나가는 이야기를 주제로 책을 써보고 싶습니다. 제가 지금도 고민하고 있는 주제이기도 한데요. 점점 더 많은 사람들이 함께 프로덕트를 만들게 되면서 생기는 문제들에 대해 분명 앞선 회사들에서도 경험을 했을텐데 보고 배울 수 있는 책이 마땅히 없었습니다.

최근에 제가 저희 팀의 코드 리뷰 문화를 만들기까지의 여정을 소개하는 글을 배포했었습니다. 개발자가 5명도 안 되는 팀일 때부터 15명이 넘는 팀이 될 때까지 코드 리뷰 문화가 어떻게 바뀌었고, 얻었던 교훈들을 썼었는데요. 돌이켜 생각해보면 그 교훈들을 배울 수 있었던 책이 있었다면 더 빨리 잘 할 수 있지 않았을까 하는 생각이 들더라고요.

작은 팀일 때 유효한 전략에서부터 10~20명, 50명 이상의 팀을 운영할 때 필요한 전략들과 그 이유에 대해 배울 수 있는 책이 만들어진다면 앞으로도 생겨날 많은 스타트업들에게 큰 도움이 될 것 같아요.

개발자의 일

댓글