안녕하세요. 저는 카카오톡 톡플랫폼개발팀에서 백엔드 서버 개발자로 일하고 있는 nano.son(손은호)입니다. 2023년 1월 16일, 제 모교인 경북대학교의 학생들과 판교 아지트에서 멘토링을 진행했습니다. 멘토링을 진행하면서 학생들이 갖고 있는 현업에 대한 궁금증을 해결해 주었고, 학생들의 시야를 넓힐 수 있도록 현업 개발자가 일하는 방식, 개발자가 가져야 할 마인드, 개발자가 되기 위해서 공부의 방향성 등 다양한 주제에 대해 많은 이야기를 나눴습니다. 제가 멘토링을 진행했던 학생들과 비슷한 고민과 궁금증을 갖고 있는 분들에게 도움이 될 수 있도록, 멘토링을 진행하면서 나누었던 이야기들을 공유드리고자 합니다.

건강한 멘토링 계획하기

저는 건강한 멘토링은 “대화”와 같아야 한다고 생각합니다. 멘토가 자신이 하고자 하는 이야기를 일방적으로 전달하고 멘티는 수동적으로 멘토의 이야기를 경청하는 형식의 멘토링은, 잘 진행된 건강한 멘토링이라고 하기 어렵다고 생각합니다. 그래서 최대한 멘티와 눈높이를 맞추고 서로의 생각을 자유롭게 교환하는 대화가 될 수 있도록 멘토링을 계획했습니다. 멘토링을 진행하기 전에 저의 간단한 이력을 학생들에게 공유했고, 학생들에게는 질문을 미리 받아서 멘토링의 방향성을 정했습니다.

질문을 받아보니, 학생들이 주로 궁금해하는 것과 고민을 알 수 있었고, 예전의 제 모습도 떠올리게 했습니다. 저도 대학생에서 개발자가 되면서 비로소 “우물 밖 세상”을 마주했고, 그러면서 시야가 넓어지기 시작했습니다. 사람들은 각자 자기만의 우물을 갖고 있습니다. 그리고 그 우물의 크기는 제각각입니다. 학생들이 저마다 갖고 있는 우물의 존재를 인식하고 바깥세상을 관찰할 수 있다면 많은 동기부여가 될 것 같았습니다. 그래서 이번 멘토링은 ‘우물 밖의 세상은 어떠한지’ 그리고 ‘어떤 대비를 하는 게 좋은지’에 초점을 맞췄습니다.

멘토링을 진행하면서 정말 많은 이야기를 주고받았는데요, 모든 질문과 답을 다 공유할 수 없어서 아쉽습니다. 최대한 많은 분들이 궁금해하실 것 같은 질문과 답변 몇 가지를 정리해 보았습니다.

Q. 프로젝트 수행 시 개발자가 서비스 기획까지 함께하는지, 아니면 기획 후 개발 과정만 전담하는지?

결론부터 말하자면, 개발, 기획, 디자인, QA 등 여러 직군이 초기 기획 과정부터 함께합니다. 직군마다 역할과 성격이 다르기 때문에, 직군별로 작업 과정을 나누고 엄격하게 구분하는 것이 합리적이고 효율적으로 보일 수도 있습니다. 또한 타 직군의 의사결정 과정에 의견을 내는 게 월권처럼 느껴지기 때문에, 타 직군이 담당하는 분야에 대해 의견을 내는 게 조심스럽습니다. 하지만 프로젝트의 규모가 커지고 복잡성이 올라갈수록, 이런 프로젝트 운영 방식은 장점보다 단점이 더 많아집니다.

기획 과정을 거친 후에 개발과정을 진행하게 된다면, 기획 단계에서 개발자의 의견이 반영되기가 어렵습니다. 이런 방식으로 프로젝트가 진행된다면, 개발자는 이미 결정된 사항에 따라 코드를 짜게 됩니다. 프로젝트에 대해서 어떤 의견도 낼 수 없기 때문에, 점점 수동적으로 일을 하게 되겠죠. 수동적인 자세로는 기획 결정, 작성한 코드의 문제를 발견하기 어렵습니다. 그렇게 작성된 코드들은 시간이 지나면 우리의 발목을 잡게 됩니다. 결국 프로젝트에 소요되는 시간은 점점 길어지고, 품질은 저하되기 쉽습니다.

이는 비단 개발자에만 적용되는 내용은 아닙니다. 개발자를 비롯한 모든 직군 담당자들은 결코 수동적인 존재여선 안 됩니다. 주체적으로 프로젝트를 이해하고 기여해야 합니다. 이 과정에서 수많은 논의와 질문이 오갑니다. 요구 사항이 이해한 것이 맞는지, 요구 사항에서 간과한 점은 없을지, 개선하기 위해서 어떻게 해야 하는지 등 여러 가지 내용을 체크해야만 프로젝트에 더 적합한 설계를 적용할 수 있고, 코드를 작성할 수 있습니다. 우리는 개발자이자 동시에 프로젝트를 성공으로 이끌어야 하는 프로젝트의 구성원임을 계속 인지해야 합니다.

Q. 개발자로 일하면서, 입사 전에 생각했던 것과 가장 다르다고 느낀 점은?

코드만 잘 작성하면 된다고 생각했다

저는 학생 때, 개발자는 코드만 잘 작성하면 된다고 생각했습니다. 그러면 업무를 할 때 전혀 지장이 없을 거라고 생각했습니다. 이런 생각은 개발자로 일하면서 크게 바뀌었습니다. 코드를 잘 작성하는 건 개발자로서 지녀야 할 기본 소양입니다. 코드 작성만큼이나 커뮤니케이션 능력도 정말 중요합니다. 과장처럼 들릴 수도 있지만, 기술력과 커뮤니케이션 능력의 중요도를 비교하자면 최소한 5:5는 된다고 생각합니다. 가끔은 커뮤니케이션 능력이 더 중요하게 느껴지는 경우도 많습니다.

현업에서 개발자로 일을 하다 보면, 커뮤니케이션을 해야 하는 일이 많습니다. 저도 처음에는 상대방의 의견을 경청하고, 의도를 파악하고, 의견차를 이해하고, 그리고 결론을 내리기 위해 대안을 제시하고, 타협하는 이 많은 과정이 난해하게 느껴졌습니다. 가끔은 말하고자 하는 의견을 제대로 피력하지 못해 무기력해지기도 했습니다. 그래서, 여러분은 학생 때 진행하는 프로젝트에서 마주하는 수많은 논의와 갈등을 소중히 여기셨으면 좋겠습니다. 그 내용이 대단하지 않더라도 괜찮습니다. 그런 작고 사소한 경험들이 모여서 현업에서 탄탄한 기반이 되어줄 거라고 믿습니다.

사실 현업에서 일하기 위해서는 커뮤니케이션 능력 외에도 많은 능력들이 필요합니다. 그런데 이런 능력들을 학생 때 모두 경험하고 익히기는 어렵습니다. 탄탄한 전공지식과 커뮤니케이션 능력이 있다면, 현업에 들어와서 다른 능력들을 익혀도 충분합니다.

큰 회사일수록 시스템이 완벽할 거라고 생각했다

카카오라는 인지도 높은 회사의 시스템은 모든 것이 정교하게 갖춰져 있을 거라고 생각했습니다. 부서에 와보니, 의외로 부족한 부분이 많았습니다. 톡플랫폼개발팀의 시스템을 5년 전과 비교하자면 완전히 다른 시스템입니다. 시스템은 아직도 많은 부분을 개선하고 있고, 새롭게 개선해야 하는 부분도 계속 발견하고 있습니다.

분명 여러분도 현업에서 일하게 되면 비슷한 상황을 마주하게 될 것입니다. 지금은 거대한 시스템을 뜯어고치는 게 막연하고 두렵게 느껴질 수도 있습니다. 그때 여러분들 곁에 믿을만한 든든한 동료들이 함께한다면, 여러분도 시스템을 개선해 나갈 수 있습니다. 시간이 다소 걸릴 수는 있겠지만요. 그리고 이러한 경험은 여러분이 개발자로서 성장하는데 아주 큰 자산이 될 것입니다. 개선은 정말 끝이 없는 것 같습니다. 중요한 건 개선을 하고자 하는 의지의 여부라고 생각합니다.

간단한 기능도 고려해야 할 점이 정말 많다

2022년 11월 7일에 오픈한 카카오톡 프로필의 공감 스티커 기능에 대해서 얘기해 보겠습니다. 공감 스티커는 여러 번 클릭이 가능해야 했고, 드래그해서 공감도를 나타낼 수 있도록 제작돼야 했습니다. 이렇게 설명드리니, 개발하는데 별다른 어려움이 없는 단순한 기능처럼 느껴집니다. 사실 이 기능을 구현하기 위해서는 동시성, 트래픽 등등 사용성을 위해서 고려할 점이 정말 많았습니다.

클릭할 때마다 서버 API를 호출하면 부하는 심하지 않을까?
공감 내역을 얼마나 오래 저장해야 할까?
새로운 공감이 있으면 어떻게 알려줄까?
새로운 공감이 취소되면 알림을 회수해야 할까?
메인, 서브 기기에서 동시에 공감 취소를 하는 경우 문제는 없을까?
API를 분석하여 타인의 스티커를 도용하려는 시도는 어떻게 막을까?
어느 정도의 트래픽이 들어올까? 그리고 그에 적합한 설계는 무엇일까?

이 외에도 다양한 고민들이 있었습니다. 공감 스티커 기능을 많은 크루들이 함께 고민했고, 기능을 구현하기 위해서 함께 노력해 준 덕분에 무사히 오픈할 수 있었습니다.

이처럼, 간단한 것 같은 기능도 프로젝트를 진행할 때 수많은 논의와 조율이 필요합니다. 개발자도 주체적으로 프로젝트를 이해하고 있어야 하고, 의견을 피력할 수 있어야 합니다. 그리고 제일 중요한 건 이 험난한 과정 속에서 나 자신이 무너지지 않도록 잘 케어하는 것입니다. 여러분도 앞으로 프로젝트를 진행할 때, 작은 기능을 개발하게 되더라도 이 기능을 구현함으로써 발생할 수 있는 여러 가지 문제와 가능성을 상상해 보면서 진행해 보시기 바랍니다. 막연하고 힘든 과정이겠지만 프로젝트를 끝낼 때마다 한 단계 성장한 모습을 마주하실 수 있을 겁니다.

마지막으로 프로젝트가 끝났다면, 회고를 꼭 하셨으면 합니다. 프로젝트를 진행하면서 잘한 점은 무엇이고, 아쉬운 점은 무엇인지 솔직하게 얘기하고 피드백하는 것이 중요합니다. 회고에 대한 내용까지 말하면 내용이 길어질 것 같으니 간단히 줄입니다.

레거시 코드에서도 배울 점이 많다

학생 때 경험하는 프로젝트는 늘 바닥부터 직접 구현하고 프로젝트와 함께 통째로 폐기되는 경우가 많아서, 이를 유지 보수한 경험이 거의 없었습니다. 그러다 보니 레거시 코드라는 걸 들어만 보고 실제로 접하진 못했습니다. 어깨너머로 들은 레거시라는 존재는 마치 악처럼 느껴졌습니다. 그저 잘못 작성하거나 가독성 낮은 코드만이 레거시라고 생각했습니다.

레거시 코드가 존재하는 이유는 다양합니다. 그 이유를 이해해야만 올바른 개선점을 찾을 수 있습니다. 난해한 코드들도 있기 때문에, 레거시 코드를 개선하는 과정은 쉽지 않을 겁니다. 그러나 개선하는 과정에서 느끼거나 배우는 점이 분명히 있습니다. 현업에서 일을 하시게 되면 레거시 코드를 개선하는 경험을 꼭 가져보시길 바랍니다. 기회가 된다면 학생 때 프로젝트의 기능을 추가하거나 개선하면서 유지 보수하는 경험을 하는 것도 매우 좋습니다.

Q. 카카오톡의 대용량 트래픽 처리는 서버 개발자에게는 큰 고민거리와 문제일 것. 트래픽을 어떻게 관리하는지?

중요한 질문입니다. 트래픽을 ‘잘’ 운영하기 위해서는 먼저 시스템을 처음부터 끝까지 전반을 잘 알고 있어야 하며, 시스템을 구성하는 각 요소에 대해서 알고 관련된 지식과 테크닉을 알고 있어야 합니다. 그래야 상황에 따라 다양한 선택지를 생각할 수 있기 때문입니다. 다음은 서비스가 확장되는 과정과, 각 과정마다 생각해야 하는 고민을 정리한 그림입니다. 다음 다이어그램을 보면서 서비스의 확장 단계에 따라 어떤 고민과 선택이 필요한지 살펴보겠습니다.

실제로는 훨씬 더 많은 개념과 고민이 필요합니다. 처음 보는 생소한 용어나 개념이 있으신가요? 너무 걱정하지 않으셔도 됩니다. 서비스가 확장됨에 따라 위와 같은 고민들이 필요하다는 사실을 한번 훑어본 것만으로도 의미가 있습니다. 가장 중요한 것은, 이런 개념을 스펀지처럼 흡수할 수 있는 탄탄한 기본기입니다.

Q. 백엔드 개발에 코틀린을 사용하는 추세지만 여전히 자바 기반이 많다고 들었다. 코딩 테스트 준비 시 자바로 할지, 코틀린으로 할지?

성급한 일반화일 수 있지만, 제가 있는 파트와 제 주변 파트에선 자바 보다는 코틀린을 더 선호합니다. 실제로 톡플랫폼개발팀은 대부분의 코드를 코틀린으로 작성, 운영하고 있습니다. 확실히 코틀린은 자바 진영에서 강함 존재감을 드러내고 있습니다.

하지만 언어는 중요하지 않습니다. 오히려 앞서 언급한 전공 지식과 커뮤니케이션 능력이 훨씬 중요하다고 생각합니다. 현재 자바를 공부하고 계신다면, 자바를 더 깊게 공부하는 것을 권합니다.

이는 언어에만 국한되지 않습니다. 가끔은 최신 트렌드 기술을 다 알고 있어야 하고, 기술을 익혀야만 한다는 강박이 들기도 합니다. 여러 번 말해서 지겨울 수 있지만, 감히 단언컨대, 신입 개발자에게 필요한 역량은 다양한 언어나 기술에 대한 경험보다는 탄탄한 전공지식과 커뮤니케이션 능력이라고 확신합니다.

Q. 백엔드 개발자의 매력은 뭐라고 생각하는지?

이미 위의 이야기에서 백엔드 개발자의 많은 매력들을 이야기했기 때문에, 여기서는 간단하게 나열해 보겠습니다.

첫째, 대규모 트래픽을 경험해 볼 수 있습니다. 사실 모든 백엔드 서비스가 대규모 트래픽을 감당하는 건 아니라서 장점이라고 쓰기가 조금 망설여졌습니다만, 다른 파트와 다르게 백엔드 개발자는 대규모 트래픽을 직접 다루기 때문에 그 부분이 큰 매력이라고 생각합니다. 그리고 대규모 트래픽을 관리하고, 유지 보수하는 경험은 백엔드 개발자의 커리어에 큰 자산이 될 수 있는 경험이라고 생각합니다.

둘째, 백엔드는 비즈니스 서비스의 중심입니다. 그래서 저는, 이건 매우 주관적인 생각입니다만, 서비스가 악단이라면 백엔드 개발자는 지휘자라고 생각합니다. 대부분의 비즈니스 규칙들은 백엔드 코드에 녹아있기 마련입니다. 카카오의 멀티프로필 개수 제한에 대해서 생각해 볼까요? 멀티프로필 개수는 지금은 제한되어 있지만 언젠가는 변경될 수도 있는 여지가 있습니다. 그렇다면 멀티프로필 개수를 어떻게 관리해야 할까요? 클라이언트에서만 개수 체크를 하는 건 안전하지 않습니다. 서버에서 체크하지 않는다면 조작된 요청에 속수무책이 됩니다. 이런 이유 때문에 중요한 비즈니스 규칙들은 주로 백엔드에서 관리합니다. 백엔드에서 중요한 비즈니스 룰을 구현하고 관리하기 때문에, 비즈니스 상황이 변하면 백엔드가 먼저 바뀐 상황에 맞춰서 변화하고, 이어서 다른 여러 외부 시스템(클라이언트, 서드파티 서버 등)을 조율하고 변경하는 데 많은 역할을 수행합니다. 그런 부분이 굉장히 매력적입니다.

멘토링을 마치며

멘토링을 진행하면서 이렇게 딱딱한 내용만 얘기한다면 다들 금세 지치고 피곤하겠죠? 그래서 멘토링 시간을 좀 더 즐겁게 보내기 위해서 다 함께 카카오 판교 아지트를 돌아보면서 구석구석 탐방했습니다. 현업 개발자들이 일하는 모습도 보고, 커피를 마시면서 가벼운 담소도 나누었습니다. 또한 사옥의 숨은 보석인 북아지트에서 보드게임을 하며 아이스브레이킹도 했습니다. 먼 길을 온 학생들이 의미 있는 시간을 보낼 수 있도록 멘토링을 준비하고 진행했는데, 학생분들이 유익한 시간을 보냈다고 기억할 수 있었으면 좋겠습니다.

이 글을 읽는 학생 분들도 불안한 구직 시장과 치열해지는 경쟁 속에서 불안감이 자주 엄습할 수 있습니다. 공부할 것도 많아서 조급함이 느껴질 수도 있습니다. 구직 시즌에는 준비가 부족한 것 같다는 생각도 들 겁니다. 분명히 말씀드릴 수 있는 건 준비가 된 것 같다는 순간은 없습니다. 있더라도 착각일 겁니다. 부족해 보이더라도 부딪혀보세요. 수많은 스트레스 요소가 있지만 하나씩 그리고 꾸준히 나아간다면 분명 좋은 결과를 보게 될 거라고 믿습니다. 여러분은 꽤 괜찮은 개발자일 겁니다.

대학생 멘토링: 우물 밖 내다보기