[톡터뷰 : 백엔드팀] 채널톡 개발의 심장 백엔드팀

안녕하세요! 채널팀에서 채용을 담당하고 있는 한스입니다👨🏻‍💻

’톡터뷰’ 네번째 이야기!

저는 이번에는 채널톡 서버를 든든하게 책임지고 있는 백엔드팀 이야기를 소개해보려 합니다.

이런 분에게 이 글을 추천합니다!

✅ 채널톡 ‘백엔드팀’ 문화/직무에 대해 알고 싶은 분

✅ 채널톡 백엔드 개발자가 하고 있는 경험에 대해 알고 싶은 분

Q. 두기, 카멜 안녕하세요~ 자기소개 부탁드려요.

• 두기 : 안녕하세요! 저는 채널팀에서 백엔드 엔지니어로 일하고 있는 두기라고 합니다.

  채널팀에 합류한 지는 벌써 3년 6개월 정도 되었어요. 처음에는 프론트엔드 팀으로 입사해서 2년 정도 업무를 하다가, 백엔드 팀으로 옮겨 지금까지 열심히 일하고 있습니다.

  백엔드 팀에서는 크게 ‘도큐먼트’라는 제품 개발, 그리고 내부적으로는 ‘메시지 큐’와 ‘스트리밍 시스템’을 담당하고 있어요. 저희 팀에서 큐와 스트리밍 시스템을 사용하는 패턴을 잘 정의하고 다른 팀원들이 잘 활용할 수 있도록 돕는 역할이라고 설명드릴 수 있을것 같아요.

• 카멜 : 안녕하세요! 저도 두기와 마찬가지로 채널팀에서 백엔드 엔지니어로 일하고 있는 카멜이라고 합니다. 저는 채널팀이 저의 첫 회사이고, 2년이 조금 넘어가는 시간 동안 함께하고 있어요.

  가장 큰 작업으로는 전화연동, 구체적으로는 ‘DSP(Demand Side Platform) 파이프라인’에 대한 작업을 진행했어요. 최근에는 ‘앱스토어’라고 해서 서드파티 앱과 채널톡을 연동할 수 있게 하는 플랫폼을 만드는 작업을 진행하고 있어요.

Q. 두기~ 프론트엔드 개발자에서 백엔드 개발자로 전환하게된 배경이 있을까요?

• 두기 : 프론트 팀에서 다양한 경험을 했지만, 이제는 더 넓은 영역에서 기회를 받고 싶다는 생각을 막연히 하게 된 거 같아요. 그런 기회를 채널팀에서 얻고 싶었는데, 다행히 저희 의사를 팀에서 존중해주었고 백엔드팀으로 전환하면서 여러 경험의 기회를 받을 수 있었어요.

  팀 변경이 자주 있는 일은 아니지만 구성원의 니즈를 최대한 고려하는 팀이고, 팀 변경이 되면 새롭게 지식을 습득해야 하는 것들이 있는데 그에 대한 시간적 배려도 있는 팀이라는 것을 알 수 있는 계기가 되었었어요.

Q. 두기는 채널팀에 어떻게 합류하게 되셨나요?

• 두기 : 저는 학교에 다니면서 인턴십을 두 번 했었고, 산업기능요원으로 복무하기 위해 다른 회사에서 첫 커리어를 시작했어요. 이 후 채널톡으로 합류하게 되었는데요.

  채널톡에 일하고 있는 지인이 있어서 좋은 점을 많이 들을 수 있었어요. 여러 좋은 점을 들을 수 있었는데, 그중 멤버 하나하나에 많은 기회를 부여한다는 점, 그리고 만드는 제품을 직접 사용한다는 점(채널톡 제품을 팀 메신저로 사용)이 가장 마음에 들었고 다양한 기술적인 경험을 하며 성장할 수 있을 거 같다는 확신이 들어 합류하게 되었어요.

Q. 카멜은 첫 직장을 선택할 때 많은 고민이 있었을 거 같은데, 어떻게 합류를 결정하게 되셨나요?

• 카멜 : 사실 많이 고민하지 않았던 것 같고, 오히려 정보를 바탕으로 제 직감을 믿었던 거 같아요.

저는 평소에 기술 블로그를 많이 챙겨보는 편인데요. 채널톡 테크 블로그의 다양한 기술 문제를 해결하는 과정에 대한 내용을 보면서 기술적으로 깊게 고민하는 팀이라는 생각이 들었고, 코드 리뷰와 같은 개발문화도 잘 자리 잡고 있다는 생각이 들어 합류를 결정하게 되었어요.

아, 그리고 대표님이 개발자 출신이라는 점에서 개발자 친화적인 회사일 것 같다는 생각도 한몫했습니다!

Q. “이것만은 채널팀의 명확한 장점이다!”라고 소개해주 실 만한게 있을까요?

• 두기 : 우선 장점으로 스마트한 분들이 정말 많은 것 같아요. 스마트하다는 정의가 각각 다르겠지만 저는 개발과 컴퓨터의 기본기가 탄탄하고 본인의 생각을 잘 전달하는 분이라면 스마트한 분이라고 생각하는데, 그런 분들이 많이 모여있는 조직이에요.

• 카멜 : 팀원들과 기술적인 이야기를 깊이 있게 나눌 기회가 많은 부분이 장점이에요. 내부적으로 정해놓은 규칙에 따라 코드 리뷰를 잘 지키고 있어 코드를 작성했을 때 여러 개발자의 피드백을 받을 수 있는 점이 좋아요.

  매주 금요일 전체 개발직군이 모여 ‘엔지니어링 세션’을 진행하고 있는데요. 구성원들이 자유롭게 주제를 정해 같이 이야기를 나눠보기도 하고 외부의 개발자분을 모시기도 해요. 이처럼 개발자분들의 다른 시각이나 관점으로 논의하며 서로가 서로에게 배울 기회가 있어 좋은 것 같아요.

Q. 엔지니어링 세션에서 두 분 중 주제를 정해서 발표를 하셨던 경우가 있다면 소개해주세요.

• 두기 : 아! 이건 제가 말씀드릴게요. 부끄럽지만 많은 개발자분이 관심 가져주셨던 발표가 있었는데요. 백엔드 팀으로 옮긴 후 처음으로 맡았던 주제인 메시지 큐에 대해 발표했었어요.

  많은 팀원이 재미있게 들어주셔서 저희 기술 블로그로도 공개된 글인데(👉🏻 AWS SQS를 도입하면서 했던 고민을 소개합니다.), 쓴 지 1년이 넘은 글이지만 여전히 저희 기술 블로그에서 가장 많은 조회수가 나오고 있고 꾸준히 읽히는 것을 보면 사람들이 궁금해했던 주제인 것 같아요.

  이 주제로 Amazon Seoul Summit 2024에서 500명이 넘는 사람들 앞에서 발표도 할 수 있었어요^^

  

Q. 두기, 카멜이 채널팀에서 기술적으로 가장 어렵게 해결한 문제라고 생각하거나 기억에 남는 프로젝트가 있나요?

• 두기 : 백엔드 팀에서 했던 일은 아니지만, 웹 프론트엔드 팀에서 위지위그(WYSIWYG) 에디터를 다시 설계했던 프로젝트가 기억에 남아요.

  에디터에 대한 우선순위가 내려가서 깔끔하지 않은 코드가 쌓여있던곳이 있었어요. 6개월 정도 시간을 들여 기초를 다시 잡고, 팀에서 프로젝트를 잘 관리할 수 있도록 하위 라이브러리를 추상화하여 복잡도를 낮추거나, 온보딩 문서와 가이드를 작성했어요.

  지금은 이 프로젝트를 직접 보고 있지 않지만 프론트엔드 팀에서 에디터를 만져본 멤버들이 많이 생겼고, 새로운 요구사항도 척척 만들어갈 수 있도록 깊이가 쌓인 상태예요. 프로젝트가 잘 관리되는 덕분에 도큐먼트라는 기능도 수월하게 출시할 수 있었네요.

  정리하자면 팀에서 잘 관리되고 있지 않던 영역을 다시 관리가 잘되도록 가져오는 데 성공했던 프로젝트이기 때문에 제 경험 중에서 큰 의미가 있었어요.

• 카멜 : 가장 기억에 남는 프로젝트라고 하면 전화연동을 꼽을 수 있을 것 같아요. 제가 처음 작업했던 부분은 WebRTC SFU 서버와 통신사 사이에서 음성 패킷을 중계하는 DSP 파이프라인이었어요.

  좀 더 구체적으로 설명하면, 여러 Peer 로부터 받은 WebRTC 스트림들을 버퍼링→믹싱→리샘플링 하는 과정을 통해 통신사로 전송하고, 반대로 통신사로부터 오는 패킷을 WebRTC 로 중계하는 파이프라인을 말해요.

  아무래도 general domain 에 속하는 문제는 아니다 보니까 음성 처리에 대한 기초적인 이론들부터 리서치하면서 배웠는데, 그중에서도 가장 기억에 남는건 Jitter buffer 와 DTMF detection 알고리즘에 관한 논문을 읽고 구현과 성능 테스트를 진행했던 부분이었던 것 같아요.

Q. 두기, 카멜은 앞으로 어떤 커리어 패스를 만들어 가고 싶으신가요?

• 두기 : 사회에 선한 영향력을 끼칠 수 있는 개발자로 성장하고 싶다는 바람이 있어요.

  저는 지금 시대가 운이 좋게도 개발자들이 가진 능력을 활용한다면 사회를 좋은 쪽이든 나쁜 쪽이든 바꿀 힘이 있다고 생각해요. 그래서 개발자로 일하면서 사회에 문제를 만들기보다는 해결하는 사람이 되어야겠다고 생각해요.

  저의 롤모델로 구글의 최초 시니어 펠로우 직급인 제프 딘을 삼고 있는데요. (사실 많은 개발자들이 이분의 영향을 많이 받고 있을 거예요 ㅎㅎ) 제프 딘이 이력서를 쓰면 하지 않았던 것을 쓰는 게 더 빠를 정도라는 말이 있을 정도로 구글의 대부분의 영역에서 핵심 기능을 개발한 분이에요. 제프 딘처럼 특정 영역을 가리지 않고 이것저것 해낼 수 있는 개발자라는 것이 제가 닮고 싶은 점이에요.

• 카멜 : 지금은 채널팀에서 기능 개발 위주로 작업을 하고 있는데요. 앞으로는 좀 더 기술집약적인 도메인에 대해 다양한 경험을 해보고 싶다는 바람이 있어요.

  요즘에는 분산 데이터베이스 이론에 관해 관심이 생겨서 사이드 프로젝트를 해보고 있어요.

  Stateless 한 API 서버를 개발할 때보다 활용되는 CS 지식이 많아 배운 내용을 활용하는 데에 도움이 되는 것 같아요. 채널팀도 자체적으로 만든 DB가 있고, 많은 트래픽을 받는 상황인 만큼 기회가 있다면 해당 분야에서 실무에 적용해 보고 싶어요.

Q. 채널팀의 백엔드팀은 어떤 기술 스택을 활용하고 있나요?

• 두기/카멜 : 백엔드 팀은 메인 API 서버의 프로그래밍 언어로 Java를 사용하고 있고, 그 주위에 새롭게 만드는 마이크로서비스에는 Go를 활용하고 있어요.

  실시간 채팅과 메시지 전파를 담당하는 서버는 Node.js로 되어있고, 이 밖에도 필요에 따라 다양한 기술을 활용하고 있어요. 기본적으로는 채널팀이 기술을 정하는 방향은 요구 상황을 해결하기 위한 최적의 기술이 무엇일지 팀에서의 논의를 통해 정하고 있어요.

  일반적인 웹 서비스를 개발하기 위함이라면 기술 스택 선택은 크게 중요한 부분이 아니라고 생각해요. 이런 부분은 사람들이 많이 사용하고 대중적인 기술을 선택하고, 요구사항이 특별한 특정 영역에 고민할 시간을 투자해서 적절한 결정을 내리는 것이 중요한 것 같아요.

  저희 기술 블로그에서도 다뤘던 대용량 실시간 메시지 전파를 위한 Socket.io와 Redis Adapter (👉🏻 Socket.io Redis Adapter 구현을 통한 트래픽 개선), 비정형 쿼리를 자유롭고 빠르게 지원할 수 있는 인메모리 데이터베이스(멤디비, memdb)와 같은 특별한 영역이 고민이 필요하다고 생각하는 영역의 예시예요.

  

Q. 채널팀의 백엔드 개발자로 일하면서, ‘이런 경험은 채널에서만 할 수 있다’고 느끼신 순간이 있을까요?

• 두기 : 직접 사용할 것을 만든다는 점을 짚고 싶어요. 저희는 팀 메신저로 슬랙, 팀즈 대신 채널톡을 사용하는데, 매일 사용하는 서비스인 만큼 불편한 점을 직접 개선하거나 팀원에게 피드백을 주고, 자잘한 기획을 직접 개발자가 챙길 수 있는 점이 좋아요.

  내가 만드는 서비스에 관심이 없다면 그냥 남이 주는 요구사항을 해결하는 것에서 그치는 경우가 많은데, 저희 팀은 관심이 없을 수가 없다 보니 디테일을 잘 잡는 습관을 들일 수 있다고 생각해요.

• 카멜 : 대용량 트래픽을 경험할 수 있다는 점이 가장 좋아요. 트래픽과 복잡한 요구사항이 많아질수록 개발자에게 주어지는 부담도 높아지지만, 역량을 높여갈 기회 또한 많아진다고 생각해요.

  또 개발 문화도 잘 갖춰져 있는 것 같아요. 구성원들이 코드 리뷰에 꽤 많은 시간을 할애하는 만큼 코드 퀄리티 유지에 큰 노력을 한다는 인상을 받고 있어요.

Q. 백엔드 개발자로서 좋은 성과를 내는 기준은 무엇이라고 생각하나요?

• 두기 : 엇! 최근에 딱 이런 질문에 대한 주제로 감명 깊게 읽었던 글이 하나 있는데요. 저도 내용에 너무 공감해서 해당 글의 내용을 요약해서 답변드릴 수 있을 것 같아요.

  • 팀에서 발생하는 반복적인 실수를 챙기는 개발자

  • 트레이드 오프를 고려해서 균형 있는 선택을 잘하는 개발자

  • 쓸 수 있는 스킬을 계속해서 갈고 닦는 개발자

  • 복잡한 것을 쉽게 설명할 수 있는 개발자

  • 문제를 표면적으로 해결하는 게 아니라 진짜 원인을 찾고 해결하는 개발자

  • 이론적 근거에만 매몰되지 않고, 당면한 문제를 해결하기 위해 효과적인 방식을 찾아 해결하는 개발자…

  • 👉🏻 글 전문 읽어보러 가기 (15년 전의 자신에게 해주는 충고)

• 카멜 : 저는 사실 설계에 대해 고민할 때 실버 불릿을 찾으려는 고집이 좀 있었는데요. 첫 회사로 채널팀에 합류해 실무를 경험하면서 조금 생각이 바뀌고 있는 것 같아요.

  두기가 인상 깊게 읽었다던 좋은 개발자의 여러 조건 중 특히 트레이드 오프를 고려해서 균형 있는 선택을 잘하는 것이 가장 중요하다고 생각하고 있어요.

  실무에서는 여러 기능적/비기능적 요소에서 가장 중요한 부분들을 판별하고 그렇지 않은 요소들과 잘 트레이드 오프하는 것이 생산성을 높이고 최선의 결과를 가져오는 것 같아요.

  개발하면서 흔히 마주치는 트레이드오프의 예시로는 읽기와 쓰기 시점에 사용하는 리소스 사이의 저울질이나, 모듈성과 성능, 또는 일관성(정합성)과 성능 사이의 교환 등을 예시로 들 수 있을 것 같아요.

JOIN OUR TEAM!

Q. 백엔드팀만이 가진 장점이 있다면 무엇인가요?

• 두기 : 백엔드 팀으로 국한하지 않고, 전체 제품팀으로 보더라도 리더 한 명 한 명이 다 신뢰할 수 있는 사람인 게 가장 큰 강점이자 장점이라고 생각해요.

  누구보다 적극적으로 모범을 보이고, 기술적으로도 배울 수 있는 분들이 많아서 자연스럽게 신뢰가 생기고 함께 일하는 것이 재미있어요.

• 카멜 : 첫 번째는, 개발 인력이 풍부해서 서로가 서로를 통해 배울 수 있다는 점이 좋은 거 같아요. 채널팀은 전체 구성원 중 개발자의 비율이 50%가 넘어갈 만큼 기술을 중요하게 생각하는 회사인데요.

  개발자 비율 중에서도 특히 백엔드 개발자의 인원이 가장 많다 보니 기술적인 이야기를 나눌 기회도 자연스럽게 많은 거 같아요. 두 번째는, 채널팀의 일하는 방식의 특징 중 하나인 기획자의 역할을 엔지니어가 할 수 있다는 점인데요.

  그렇다 보니 문제가 있을 때 기획자가 분리되어 있을 때와 비교해서 복잡한 설득의 과정 없이 빠르게 공감대를 얻어서 일을 진행할 수 있는 점도 좋은 거 같아요.

Q. 어떤 분들이 백엔드팀으로 오시면 잘 맞을까요? 함께하고 싶은 동료에게 한마디 부탁드려요!

• 두기 : 한 문제를 깊이 생각하며 제대로 풀다 보면 자연스럽게 뾰족한 자신만의 강점이 생겨난다고 생각해요.

  채널팀에는 이러한 본인만의 강점을 가지신 분들이 많고, 어려운 문제도 정말 많기 때문에 저는 하나의 경험을 A to Z까지 담당하면서 깊이 있는 고민을 통해 좋은 결과를 만들어 내어 본 분이라면 채널팀에 너무 잘 맞을 거 같아요.

• 카멜: 문제를 해결할 때 왜 그렇게 해야 하는지에 대한 근거를 찾으면서 개발하시는 분이면 좋을 것 같아요. 그러기 위해서는 풍부한 CS 지식도 필요하지만, 당연하게 알고 있던 것에 의문을 품고 계속 공부하는 태도도 중요하다고 생각해요.

• 두기/카멜 : 저희 채널팀의 개발자들과 협력하며 서로의 성장과 발전을 도모하고, 깊이 있는 고민을 바탕으로 다양한 문제를 해결해 나갈 열정적인 개발자분들의 많은 지원을 기다릴게요~🥰 [이런 글도 추천드려요👍]

• 채널톡 탐정사무소

• [개발문화] 채널팀의 엔지니어 세션을 소개합니다!