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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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