Q. 간단한 자기소개와 팀에서 맡고 있는 역할을 알려주세요.
안녕하세요. 기반기술팀에서 프로그래머들이 사용하는 도구를 만들고 고도화하고 있는 서버 개발자 배현우입니다. 서버 챕터에서는 리드 역할을 하고 있어요.
Q. 팀과 챕터, 소속이 2개이신데 조직이 어떻게 구성되어 있나요?
기본적으로 저희 제품개발본부원들은 스쿼드와 챕터 각 2개의 조직에 소속되어 있어요. 스쿼드는 다기능 팀으로 서로 다른 직무를 가진 팀원들이 모여있고요, 챕터는 동일 직무를 가진 사람들이 모입니다. 피처 배포를 하는 등 실제 제품과 관련한 업무를 진행하는 건 스쿼드에서, 한 제품을 만들며 함께 관리하고 정해가고 성능을 고도화하는 일들은 챕터를 중심으로 해나가고 있습니다.
저는 독특하게 스쿼드에 속해있지 않고 기반기술팀이라는 별개의 팀 소속인데요, 스쿼드에 속한 팀원들이 사용자에게 근접한 도메인을 중심으로 업무를 한다면 저는 프로그래머들의 도구를 만든다고 할 수 있어요. 지금은 동영상 인코딩 기능 개선 작업을 하고 있습니다.
Q. 서버 챕터는 어떤 역할을 하고 어떤 방식으로 운영되나요?
저는 서버 챕터를 제품의 안정성을 책임지는 조직이라고 생각해요. 각 스쿼드에서 매 스프린트 단위로 새로운 피처를 출시하다 보면 기존에 운영 중인 제품에 변화가 생기고 균열이 발생하기도 합니다. 모든 스쿼드 구성원은 스프린트에 몰입해야만 합니다. 서버 개발자분들도 당연히 마찬가지고요. 그러다 보면 필연적으로 코드 작성 과정에서나 구조적으로 부족한 영역이 생길 수밖에 없는데요, 그런 사각지대나 사이드 이팩트를 챕터에서 챙기려고 하고 있습니다. 챕터 리드로서는 새로운 기능이 추가될 때마다 안정성과의 균형을 찾아가는 조력자의 역할을 하려고 합니다.
사고가 없을 수는 없잖아요. 프로덕션 배포를 할 때 문제가 생길 수도 있고, DB에 신규 칼럼을 추가하는 과정에서 무언가 잘못될 수도 있는 거고. 이렇게 사고가 발생했을 때 어떻게 문제를 파악하고 전파하고 대응해야 하는지 규칙을 정하는 것도 챕터의 역할입니다. 제가 리드라고 규칙을 정해서 공유하는 것은 아니고요, 이슈나 아젠다가 생기면 서버 챕터 미팅에서 모두 함께 논의하고 있습니다.
매주 1회 진행하는 챕터 미팅에서는 서로가 업무를 하며 겪는 어려움과 아이디어를 적극적으로 공유하고 있어요. 각자 속한 스쿼드가 있기 때문에 업무의 영역이 분리되어 있는데요, 평상시에 다른 직무를 가진 구성원들과 일을 진행하며 겪은 문제들을 풀어놓고 해결 방법을 논의하는 자리가 됩니다. 제품이 고도화될수록 다른 스쿼드의 업무에 대한 정답을 다른 개발자가 찾아주기는 어려워요. 챕터 구성원들이 논의한다고 해도 누가 정답을 가르쳐준다기보다는 혼자만의 고민이 되지 않도록 하는 거죠. 서버 개발자로서 각 직무 전문가와 커뮤니케이션하고 협업하는 과정에서의 어려움에 대해 공감하고, 맞닥뜨린 문제를 풀어낼 실마리를 찾아가고 있습니다.
개발하다 보면 미묘한 지점이 있잖아요. 원래도 정답이라는 건 없기도 하고요. 우리에게 맞는 답을 찾아가는 과정에서 고민을 나누고 서로를 응원하고 있습니다.
Q. 큐리어슬리 근속햇수로 치면 제품개발본부 내에서 손에 꼽는 팀원이신데요, 그간 회사가 변화한 부분이 있을까요?
2년 전까지는 3~6개월 단위로 기획-디자인-개발을 순차적으로 진행하는 방식으로 일했어요. 2022년부터 애자일 프레임워크를 도입했는데요, 엄청난 차이를 느끼고 있습니다. 한 회사에 4년을 몸담았으니 꽤 긴 기간인데 이직 고민을 크게 하지 않았던 게 바로 이런 변화 때문이었어요.
워터폴 방식으로 일을 할 때에는 밀려있는 업무를 처리한다는 갑갑함이나 압박감이 있었어요. 모든 것이 논의되고 빈틈없이 정책이 세워져야만 개발을 시작할 수 있는데, 개발하는 과정에 와서야 발견될 수 있는 문제들이 있잖아요. 그건 IT제품을 만들어보신 분이라면 누구나 알 거예요. 실제로 배포까지 해서 결과를 보는 데까지 시간이 너무 오래 걸렸어요.
작은 단위에서 시작하고 처음부터 기획-디자인-개발이 함께 논의할 수 있는 체제에서 일을 한다는 게 조금 과장하면 감동적이기까지 했어요. 프로그래머로서 내가 작성한 코드가 작동하고 그 결과가 실제 사용자한테 영향을 준다는 것을 2주, 3주 단위로 확인할 수 있다는 건 크더라고요. 워터폴이든 애자일이든 개발 과정이 고통스러운 것은 같은데, 일의 결과가 빠르게 눈에 보인다는 게 저한테는 정말 큰 장점이었어요.
Q. 애자일로서의 변화가 이직 고민을 잠재워준 이유 중에 하나라고 하셨는데요, 또 다른 이유가 있을까요?
누구나 누구에게든 질문할 수 있다는 점이요. 그리고 서로를 각 직무에 있어 자신보다 잘 아는 전문가로 존중하고 대우한다는 점.
제품을 만들다 보면 ‘막혔다’고 느끼는 순간을 반드시 경험하게 됩니다. 저는 이럴 때 가장 좋은 해결 방법이 이 고민을 해본 사람한테 물어보고 같이 토론하는 것이라 생각합니다. 제품이 어떻게 만들어져 있는지, 앞으로 어떻게 만들어져야 하는지는 같이 일하고 있는 사람이 제일 잘 알아요. 저희 제품개발본부원들은 서로 질문하고 의견을 내놓는 걸 두려워하지 않는다고 느껴요.
개인의 역량에 차이가 없는 조직 간 성과가 다른 이유가 “심리적 안정감”이라는 것을 밝힌 프로젝트 아리스토텔레스라는 연구를 인상 깊게 봤어요. 우리 제품개발본부가 심리적 안정감이 높은 조직인 것 같아요. 아무도 질문을 귀찮아하지 않습니다. 질문을 하는 사람 스스로도 자신과 팀에게 도움이 되는 질문을 하려고 노력하고, 질문이 곧 소통이라는 점을 모두가 잘 알아요. 이런 문화가 개인이 성장할 수 있는 배경이 된다고 생각합니다. 자신이 아는 범위에서만 개발하는 게 아니라 모르는 것도 개발할 수 있게 되니까요.
조직원들이 건강하게 커뮤니케이션할 수 있는 이유는 서로를 그 직무의 전문가로서 함께 일하고 있다고 생각하고 존중하고 있기 때문입니다. 누가 어떤 직위니까, 연차가 높으니까 더 많은 의사결정권을 가지지 않아요. 자신의 전문 분야에 대해서는 그 사람이 더 많이 생각하고 더 많은 경험이 있으니 서로 다른 시각을 가진 사람으로서 그의 의견을 경청하고 존중합니다. 의견이 다르면 가장 좋은 방법을 찾아가기 위해서 토론도 하고요. 이 문화를 유지하고 발전시켜가기 위해서 구성원 모두가 신경 쓰고 노력하고 있다고 생각합니다.
Q. 근무하면서 가장 기억에 남는 일을 알려주세요.
큐리어슬리에 재직하는 동안 사용하는 언어를 변경하게 됐습니다. 새로운 프로젝트를 시작하며 Python Django에서 Koltin, Spring으로 전환했어요. 솔직히 시작할 때는 꼭 해야 하는지, 잘 할 수 있을지 모르겠다고 생각했어요. 반신반의했습니다. 언어를 바꾼다는 것이 손바닥 뒤집듯 할 수 있는 일은 아니기에 고통스럽기는 했습니다. 지금은 정말 만족스러워요.
중요한 건 어떤 언어로 개발하는지가 아닌 것 같습니다. 프로그래머가 하는 일의 70%는 로직과 커뮤니케이션이라 생각해요. 실제로 언어를 변경해 보고 나니 언어에 구애받는 영역이 적다는 걸 더 잘 알게 됐습니다. 언어적인 부분은 다른 사람에게 도움을 받아도 되고, 테스트 중에 버그가 나오면 수정할 수도 있어요. 어떤 언어를 쓰는지보다는 일에 대한 관점이 어떤지가 훨씬 중요한 것 같습니다.
저희가 2022년부터 DDD와 TDD, 클린 아키텍처를 시도하고 있어요. 처음에는 도입을 위해서 스터디를 함께했고요, 어떻게 하면 적용해 가며 제품을 개발할지 지속적으로 논의하며 진행하고 있습니다. 회사에서는 실현이 불가능하다고 생각하시는 분들 많을 거예요. 테스트 코드를 작성하다 보면 정말 한도 끝도 없고, 어디까지가 적정한 선인지 찾아가는 것도 무척이나 어려운 일입니다. 어렵다는 부분에는 동의합니다. 그렇지만 회사/제품의 목표를 달성하면서도 DDD와 TDD를 해나갈 수 있고, 그 길을 저희가 만들어가고 있다는 점을 말씀드리고 싶어요.
지금 동작하는 코드를 작성하는 것은 누구나 할 수 있는 일일 거예요. 그러나 내일도 새로운 기능을 추가할 수 있는 코드를 만들어가는 것은 쉽지 않습니다. 하지만 반드시 추구해야 해요. 비즈니즈 로직의 규모가 커질수록, 제품이 고도화될수록 중요해집니다. 회사도 개발자 개개인도 의지가 있어야만 할 수 있는 일이라 이해와 공감, 의지가 모두 필요해요. 그래서 이 부분에 공감하시는 분이 오신다면 정말 많은 걸 느끼실 수 있을 거라 생각해요.
Q. 팀에서나 커리어적으로 이루고 싶은 것은 무엇인가요?
제가 이 회사에 몸담고 있으면서 가장 어렵지만 가장 가치 있다고 느낀 것이 ‘협업’이었어요. 개발자들은 보통 더 좋은 코드를 작성하고 싶어 하잖아요. 눈에 보이는 버그는 바로 꼭 잡고 가고 싶어 하고요. 개발할 시간이 충분치 않다거나, 비즈니스적 가치를 위해 의사결정이 개발자가 보기에 적합하지 않은 구조로 가야만 할 때 마음이 힘들어지는 것 같아요. 한 회사 내에도 운영, 영업, 마케팅 등 다양한 조직이 있고 각 조직의 중요 가치가 다른 게 당연합니다. 저는 이런 이해관계 속에서 개발의 입장만을 고집하는 게 아니라, 회사와 제품의 입장에서 모두에게 최적의 의사결정을 할 수 있도록 하는 조율자가 되고 싶어요. 이를 위해 프로그래머로서의 깊이 있는 전문성을 갖추는 것은 필수적이겠죠? 기술적 역량 강화는 당연하고 다른 직무나 부서와의 의사소통 능력을 키우는 일도 필요하다고 생각해요. 앞으로 갈 길이 머네요(웃음).
Q. 지원을 망설이는 분들에게 하고 싶은 말이 있다면?
이미 충분히 저희가 어떻게 일하고 어떤 문화를 만들어가려는지 말씀을 드려서… 추가로 설명하기보다는 요약을 해서 말씀을 드려볼게요.
우리 제품개발본부는 연차와 관계없이 서로에게 스스럼없이 질문하고 이에 대해 진지하게 답하며 함께 답을 찾아가는 조직이에요. 직접 비즈니스 로직에 대해서 토론하며 개발자로서 성장하고 싶으신 분이시라면 저희와 잘 맞을 거라 생각합니다. 평소에 클린 아키텍처나 DDD에 관심이 있지만 과연 회사에서 가능할지 의문을 품고 계신다면, 저희와 함께 도전해 보실 수 있을 것 같습니다. 개발자로서의 목표를 달성하며 회사에 기여할 기회가 되실 거라 생각해요. 많은 관심 부탁드립니다.
배현우
기반기술팀 서버개발자
“[내가 즐거운] 서비스를 만들자. [내가] 즐거운 서비스를 만들자.”