안녕하세요, 배민프론트서버개발팀의 개그 신동이자 귀염둥이 이신은입니다.

저는 작년 12월 신입 개발자 공채를 통해, 백엔드 개발자로 우아한형제들에 합류했습니다. 취업준비생에서 7개월 차 삐약삐약 병아리개발자가 된 지금까지, 지난 1년을 돌아보며 제가 했던 고민을 나누고자 합니다. 한글보다는 수식이나 JAVA 언어로 표현하는 것이 더 편한 수학전공 개발자이지만, 저의 의도가 왜곡되지 않고 이 글을 보시는 분들에게 잘 전달되기를 바라며 펜을, 아니 키보드를 두드립니다.

왜 하필 우아한형제들이었나요?

요즘 취업준비생들은 적게는 1~20개, 많게는 100여 개의 이력서를 제출합니다. 이력서를 제출한 모든 회사에 전력투구할 순 없을뿐더러 채용일정이 겹치는 경우가 왕왕 있기 때문에, 자신의 기준에 따라 회사들의 우선순위를 매기게 됩니다. 물론 서류, 인·적성/코딩테스트, 면접 등의 단계를 거치면서 이 우선순위가 뒤바뀌는 경우도 많죠.

우아한형제들의 입사를 확정했을 때 저는, 취업준비 시작부터 거의 마지막까지도 최우선으로 생각했던 회사에 최종합격한 상태였고, 합숙면접까지 거쳐서 힘겹게 올라간 회사의 임원면접을 앞둔 상태였습니다. 자랑하고 싶어서 밝히는 것이 아니라, 이러한 상황에서 한 치의 망설임도 없이(사실 약간 망설였…) 우아한형제들을 선택한 이유를 얘기하려고 합니다.

배달의민족 서비스는 알고 있었지만 한 번도 이용해보지 않았고, 4년 동안 (망령처럼) 연구실에만 틀어박혀 있던 대학원생에겐 너무나도 생소했던 우아한형제들이라는 회사 이름…. 광고 쪽 일을 하던 선배에게 신입 개발자 공채 소식을 전해 들었을 때만 해도, ‘내가 고작 배달 앱 만들려고 머리카락까지 빠져가면서 연구했나?’ 라는 생각이 들더군요(건방이 극에 달했…). 밑져야 본전이라는 생각으로, 회사 이름을 가볍게 검색해보다가 낯익은 이름을 발견했습니다. 꽤 오래전 어떤 경로에서였는지 기억나진 않지만, 김범준 CTO님의 개인 블로그를 방문한 적이 있었습니다.

나는 하나의 기계에서 어떻게 하면 최적화할 지를 고민하면서, 연속해서 읽어야 할 데이터는 X, X+1 주소에 저장하는 것이 아니라 memory bus bottleneck를 막기 위해 X, X+8에 저장해서 읽어 내고 있고, lock만 하더라도 spinlock을 쓸 지, readers-writer lock을 쓸 지, 그리고 lock을 거는 단위도 hash bucket head에 걸 때와 실제 hash bucket node에 걸 때를 구분해서 쓰고 있는데, 구글은 그런 류의 최적화가 아니라 몇 천대, 몇 만대의 서버를 분산 시스템으로 연결해서 서비스를 제공하고 있던 것이다. 그 순간 내가 하는 고민들이 너무 국지적인 최적화에 대한 고민이 아닐까 하는 생각과 내가 지금 열심히 쌓아 올린 지식들이라는 것이 상당히 많은 부분 쓸모없어질지도 모른다는 생각, 그리고 앞으로의 변화에 적절히 대응하지 않으면 도태되어 버릴 것 같다는 생각이 들었었다.

[출처: 김범준 블로그]

당시에 저도 대학원에서 통신 미들웨어 연구를 하면서 비슷한 고민을 하고 있었습니다. ‘내 연구가 시대의 흐름에 너무 뒤처지는 것은 아닌가?’, ‘내가 연구하던 프로토콜이 아닌 MQTT 및 CoAP가 IoT 표준, 이른바 대세 프로토콜이 되었다는데…. 앞으로 내가 해야 할 것은 무엇이지?’. 개인적으로 고민이 많은 편인데, 고민은 부정적인 것이 아니라 더 생산적이고 의미 있는 결과를 만들 수 있는 긍정적인 것이라고 생각합니다. 물론 좋은 결과를 만들기 위해서는, 고민하는 데 그치지 않고 해결하고자 하는 의지가 수반되어야 하죠. 따라서 지금 어떤 고민을 하는 건, 절대적으로 안 좋은 상황이 아니라 성장하고 있는 과정이라 믿고 있습니다.

CTO님의 개인 블로그 글을 다시 찾아보면서, ‘이렇게 자아 성찰을 게을리하지 않으시는 분(게다가 엄청나게 똑똑하신 분! 딸랑딸랑)이 수장으로 계시는 개발조직은 어떤 모습일까?’ 하는 호기심이 생겼습니다. 면접을 앞두고 찾아보았던 기술 블로그에 있는 서비스와 기술에 대한 고민 그리고 면접 자리에서 마주한 면접관님들과의 심도 있는 대화를 통해, 호기심은 어느새 확신으로 바뀌어있었습니다. 다른 회사의 많은 개발자 또한 우리와 비슷한 고민을 하며 다양한 방식으로 성장하고 있을 것으로 생각합니다. 하지만 혼자 숨어서 하는 고민이 아니라 드러내놓고 공유하며, 자신만의 방식을 찾아내고 회고하는 모습이 제겐 참 인상적이었습니다.

  • 나: 교수님, 우아한형제들이라는 회사 아시나요?
  • 교수님: 몰라.
  • 나: 저 거기 가고 싶어서 지원서 냈어요. 우아한형제들은 배달의민족이라는 서비스를 하는 회사이고…. (블라블라)
  • 나: 교수님, 저 면접 다녀오겠습니다.
  • 교수님: 면접? 어디?
  • 나: 우아한형제들이요. 제가 저번에 말씀드렸는데….
  • 교수님: 그래, 면접을 경험해보는 것도 나쁘진 않지.
  • 나: 교수님, 정말 가고 싶었던 회사에 최종합격했어요. 축하해주세요.
  • 교수님: ADD? ETRI? 아니면 대기업?
  • 나: 우아한형제들이요. 제가 여러 번 말씀드렸는데….
  • 교수님: 거길 진짜 들어간다고?

[내가 겪은 우아한형제들 인지도의 현주소]

회사에 대한 어르신들의 낮은 인지도, 신입은 무조건 큰 회사를 가야 한다는 생각 등으로 인한 주변의 우려들이 있었지만, 제 선택을 좌지우지할 만한 요인들은 아니었습니다. 입사한 지 7개월이 지난 지금, 그 선택에 아주 만족하고 있습니다 :) 아직 회사 뽕에 취해있어서 그런가?

선생님, 제가 프론트서버개발팀이라니…. 실화인가요?

우아한형제들에 입사하자마자 2개월 동안 신입 개발자 교육을 받은 후, 배민프론트서버개발팀에 배정받았습니다. 저는 분명 백엔드 개발자로 입사했는데, 프론트라는 단어를 듣고 직무가 바뀌었거나(프론트엔드를 교육해주셨던 코드스쿼드 크롱님이 Pick Me?) 행정 오류일 것으로 의심했습니다. 사실 팀 배정을 받기 몇 주 전에, 가벼운(줄 알았던) 식사 자리에서 CTO님께 ‘어떤 팀에서 어떤 일을 해보고 싶은지’ 에 대한 질문을 받은 적이 있습니다. 신입 개발자 교육은 외부 전문기관에서 진행했기 때문에, 회사의 조직도도 모르고 각 팀의 R&R도 모르던 상태라 당당하게 평소 생각을 말씀드렸죠. “많은 일을 하면서 빨리 성장하고 싶고, 배달의민족의 (엄청난) 트래픽을 경험해보고 싶습니다! 정적인 팀은 제게 맞지 않죠. 우후훗”. 이 트랩 대화가 팀 배정에 지대한 영향을 미치리라고는 미처 생각하지 못한 채, 해맑은 얼굴로 초밥을 참 맛있게 먹었더랬습니다.

그렇게…. 저는 그토록 꿈꾸던(?) 팀의 일원이 되었고, 팀장님과의 첫 미팅에서 ‘바빠서 못 챙겨주니 알아서 잘해라’ 는 막말 조언을 듣게 됩니다. 여기가 술을 퍼마시게 된 별 다섯 개의 뽀인트! 사실 말씀은 그렇게 하셨지만, 팀원들이 아마 팀장님만 빼고. ㅋㅋㅋ 많이 챙겨주셨습니다. 저를 왜 이 팀에 보내셨냐고 나중에 항의 여쭤봤더니, ‘그 팀에서 살아남을 신입이 신은님밖에 없을 것 같았다’ 며 어째서?!!! 왜?!!! 위로 아닌 위로를 해주셨던 CTO님.

배달의민족 앱을 실행하면, 처음 호출하게 되는 것이 바로 우리 팀에서 제공하는 API들입니다. 가장 앞단에 위치하다 보니 트래픽에 적극적으로 대응해야 하는 것은 필수 불가결한 사실이고, 앱에서 필요로 하는 API들을 제공하는 역할이다 보니 하나의 도메인을 깊게 파고들기보다는 다양한 도메인을 동시다발적으로 진행해야 하는 경우가 많습니다. [우리 팀에서 제공하는 일부 API들 - 배너 및 카테고리 / 이런 것도 배달돼요?! / 주소]

처음에는 특정 도메인의 신규 로직을 개발하는 업무가 제게 주어졌지만, 시간이 지나면서 점차 운영 이슈와 장애 대응, 여러 도메인으로의 업무 확장이 진행되고 있습니다. ‘신입이라는 이유로 계속 단순 업무만 주고 중요한 업무에서는 배제하는 거 아닐까?’ 하는 제 고민은 보기 좋게 빗나갔죠 :) 아직 인프라 지식이 부족하기 때문에 트래픽 이슈를 다루기도 너무 어렵고, (멀티코어를 장착하고 싶은 싱글코어러이다 보니) A를 개발하다가 급하게 B를 처리해야 할 때 Context Switching이 신속 정확하게 이루어지지 않습니다. 이럴 땐 ‘정말 개발자를 그만둬야 하나?’, ‘난 역시 개발자와 맞지 않아’, ‘무슨 부귀영화를 누리겠다고 서비스 회사에 들어왔나?’ 싶은 고민과 좌절을 경험합니다. 그렇지만, 배포에 성공했을 때, 어려운 업무를 해냈을 때, 동료들이 기술에 대한 조언을 구할 때, 기획자에게 감사 인사를 받았을 때 등등 스스로가 대견하게 느껴질 정도의 성취감을 느끼는 순간도 많습니다. 이러한 성공과 실패, 좌절과 성취를 느끼는 과정들을 통해, 더욱더 성장할 수 있으리라는 흔들림 없는 믿음이 생겼습니다.

6분간의 악몽과 다시 돌아온 현실

지난 7월 22일, 제2회 배민 치믈리에 자격시험이 성황리에 마무리되었습니다. 이를 홍보하기 위해서 앱 스플래시 화면에서 보여주던 치믈리에 포스터를 이제 내려달라는 업무 요청이 있었고, 스플래시 교체 건은 평소에도 제가 담당하던 익숙한 업무였죠. 스플래시 API는 모바일 기기의 정보를 받아 해상도에 맞는 이미지 URL을 반환하는 API입니다. 이번에는 스플래시 교체가 아닌 페이드아웃 요청이었지만, 교체할 이미지 URL 대신 빈 값을 넣어 반환하면 자연스럽게 스플래시가 페이드아웃 될 것이라는 가설을 세웠습니다. 가설에 맞게 코드를 수정한 후 제가 사용하는 아이폰에서 베타테스트를 해 보니, 매우 깔끔하게 메인화면에 진입되는 것을 보고 ‘역시 내 생각이 맞았어! 룰루랄라’ 하는 자화자찬과 함께 해당 이슈의 상태를 배포 대기로 옮겼습니다.

[바로 그 치믈리에 포스터]

사실은 응답 데이터가 설계 목적과 달라지는 상황이라, iOS 및 안드로이드 개발자들과 적극적으로 업무를 공유하고 의견을 나눴어야 합니다. 하지만 협업 경험이 적고 소심한 성격 탓에 다른 팀에게 먼저 얘기를 꺼내기가 쉽지 않다는 이유로, ‘크게 바뀐 것도 아니고 사소한 기능인데 별일 없겠지!’ 하는 말도 안 되는 생각을 하게 됩니다. 또한, 업무에 익숙하지 않던 초기에는 간단한 로직 수정에도 동료들의 코드리뷰를 받고 여러 번의 테스트를 거쳤지만, 이제 업무가 조금씩 익숙해지고 바빠지면서 번거로운 단계는 알게 모르게, 은근슬쩍 생략하고 있었습니다. 각자의 업무는 스스로 해내는 것이 동료들을 편하게 해주는 것이라고 합리화하면서 말이죠. 이렇게 여러 단계의 안전장치를 무시해버린 채 운영에 배포되었고, (제가 테스트해보지 않았던) 안드로이드 기기의 사용자들은 장장 6분간 (무려 컵라면을 2개나 만들 수 있는 시간) 배달의민족 앱에 접속할 수 없는 사태가 발생했습니다. 예상치 못한 사태에 가슴이 먹먹하고 팔다리가 저리는 멘붕에 빠져있는 동안, 팀원들과 앱 개발자들이 발 빠르게 대처해주셔서 장애 상황이 더 길어지는 것은 막을 수 있었습니다.

모든 장애를 미리 방지할 수 있으면 좋겠지만 사람이 하는 일이라 실수는 발생할 수 있다. 실수한 것에 대해 비난하지 않으니 너무 자책하지는 말되, 재발 방지를 위해 프로세스를 점검하고 문제점을 개선해야 한다. 같은 실수를 반복한다면 그것이 정말 부끄러워해야 할 일이다.

[장애 후 들었던 조언]

영화나 드라마를 보면, 경력 많은 주연급의 배우가 주인공이 아니고 몇 컷 등장하지도 않는 역할을 맡는 경우가 가끔 있습니다. 왜 이 역할을 수락했냐는 인터뷰어의 질문에 ‘시시한 역할은 없다. 시시한 배우만 있을 뿐’이라고 답하곤 합니다. 이는 비단 영화나 드라마계에만 해당하는 얘기가 아니라 우리 필드에도 적용되는 얘기입니다. 사소한 기능은 없고, 어떤 업무를 사소하다고 치부해버렸을 때 큰 문제가 되어 돌아올 수 있음을 느끼게 된 경험이었습니다.

길었던 글을 마무리하며….

지난 몇 년간 내버려 두었던 SNS를 입사하면서 다시 시작했습니다. 고민이 있을 때마다 형식도 없고 맥락도 없이 편하게 글을 남기면, 다음날 동료들이 다가와서 수다 타임을 제안합니다. 리빙 포인트! 커피가 마시고 싶을 땐, 고민이 있는 척을 한다. 제가 우아한형제들에 들어와서 가장 감사한 것은, 바로 이러한 동료들을 만난 것입니다. 나의 고민을 나눌 수 있는 동료, 나를 믿어주는 동료, 내가 성장할 수 있도록 도와주는 동료들이 있기에, 마음껏 고민할 수 있고 마음껏 도전할 수 있습니다. 지금 여러분의 고민은 무엇인가요?