리멤버 지원자분들이 묻는 질문 Top 4

안녕하세요 정말 오랜만에 쓰는 글입니다. 글이 안올라와서 “이 회사 망한거 아니야?”라는 생각을 갖으셨을수도 있겠지만 그런건 아니고 지난 기간동안 리멤버는 큰 성장을 만들어내는데 정말 많이 바빴습니다. 핑계지만 바쁘다는 이유로 글을 거의 쓰지 못했습니다^^;

드라마앤컴퍼니도 대부분의 IT 업체와 마찬가지로 훌륭한 동료분을 모시기 위하여 개발자 채용에 매우 열심히 노력하고 있고 그 결과 면접도 많이 보고 있습니다. 면접에서 대부분의 지원자분들이 항상 공통적으로 물어봐주시는 질문이 있습니다. 지원하시기 전에 제대로 알려드리지 못한 저희의 잘못도 크고 매번 같은 얘기를 하는 것 보다는 글로 정리하는 것이 훨씬 효율적일 것 같다고 생각하여 이번 글에서는 서버 파트 지원자분들께 자주 받는 질문 4개와 그에 대한 답변을 정리해보고자 합니다.

[질문 1] 왜 Ruby on Rails를 사용하나요?

우선 드라마앤컴퍼니에서는 API, 어드민, 리멤버 Web 버전을 포함한 거의 모든 백엔드 프로젝트에 Ruby 언어와 Ruby on Rails(이하 RoR) 프레임워크를 사용하고 있습니다. 이 질문은 “저 Ruby 안 해봤는데 괜찮은가요?”, “언제 다른 언어로 바꾸나요?” 등의 질문과 함께 가장 많이 받는 질문입니다. 아무래도 국내에서는 Java가 압도적으로 대세인 언어이고, Ruby보다는 Python이나 Node.js가 더 인기가 많다 보니 Ruby라는 언어를 굉장히 생소하고 낯설게 느끼시는 분들이 많은 것 같습니다. 물론 저도 처음에는 그랬고요.

드라마앤컴퍼니는 회사를 처음 시작할 때부터 RoR을 사용했습니다. 기존에 Java 개발자셨던 분이 리멤버를 만들 때쯤 RoR를 접하고 엄청난 생산성에 반해 API, 타이피스트, 어드민 등 모든 시스템을 RoR로 만드셨습니다. 이분 이후로도 드라마앤컴퍼니에서 RoR를 사용하셨던 개발자분들이 10명이 넘는데, 한 분을 제외하고는 Ruby에 대해 거의 아무것도 모르는 상태로 입사하셨습니다.

저희는 언어와 프레임워크는 모두 “도구”일 뿐이라고 생각합니다. 그리고 “뛰어난 개발자는 어떤 도구를 사용해도 잘한다.”라는 생각이 있죠. 물론 언어와 프레임워크에 대한 이해도도 매우 중요하기 때문에 그 도구를 제대로 사용하기 위해서는 어느 정도의 숙련이 필요한 것이 사실입니다. 따라서 아무리 뛰어난 개발자여도 처음 하는 언어와 프레임워크를 접하면 처음에는 좋은 품질의 코드를 만들기 힘들다고 생각합니다.

하지만 저희는 기존 코드도 계속 리팩토링하면서 완성도를 높여왔으며 테스트 코드와 문서화도 꽤 잘되어있는 편이기 때문에 한 가지 이상의 언어에 능통하시고 뛰어난 개발자라면 1주일도 안 돼서 좋은 코드를 만드실 수 있는 환경이라고 생각합니다.

“RoR은 매우 느리기 때문에 바꿔야 하지 않는가?”라는 질문도 있습니다. 물론 같은 로직을 구현하는 경우 C나 Java에 비해 느린 것이 사실입니다. 하지만 애플리케이션이 느린 원인은 언어의 성능보다는 사람이 만든 로직이나 설계에 있는 경우가 훨씬 많습니다. 그리고 리멤버가 온라인 게임이나 대규모 메시징 앱처럼 실시간 속도가 엄청나게 중요한 서비스가 아니기 때문에 이 부분은 크게 문제 되지 않는다고 생각합니다.

GitHub, Airbnb, Twitter, Twitch 등 세계적으로 큰 회사들이 지금도 혹은 국내에서 접할 수 있는 것보다 훨씬 큰 규모의 서비스가 될 때까지 RoR를 메인 프레임워크로 사용한 것을 보면 한동안은 계속 사용할 수 있다고 생각합니다. 그리고 무엇보다도 사내에서 RoR을 제대로 사용해보신 분들은 모두 RoR의 편의성과 생산성에 대해 매우 만족해하고 있습니다.

[질문 2] 기술 스택이 어떻게 되나요?

우선 앞서 말씀드린 것처럼 웹 프레임워크로는 Ruby on Rails를 사용하고 있습니다. 그리고 인프라는 AWS, 인 메모리 DB는 Redis, 로그 관리는 ELK stack, APM은 NewRelic, 비동기 job 처리는 Sidekiq, 테스트 프레임웍은 Rspec을 사용하고 있습니다. 그리고 이 기술들을 어느 정도는 잘 쓰고 있다고 생각합니다.

예를 들어 RoR과 같은 경우 여러 번 리팩토링을 거치면서 더 나은 코드 구조를 만들기 위해 노력하고 있으며 거의 모든 경우 테스트 코드를 작성하고 있습니다. 그 결과 API의 메인 프로젝트의 테스트 코드의 수만 7,000개가 넘습니다.

AWS의 경우 기본적인 EC2와 S3부터 Lambda, SQS, Route 53, API Gateway, CloudWatch, CodeDeploy, CodePipeline, CodeBuild, ElastiCache, ElasticBeanstalk, ECR 등 많은 서비스를 사용하고 있습니다. 다음은 저희가 AWS를 잘 활용하고 있다고 생각하는 몇 가지 예시들입니다.

• Auto Scaling으로 API 서버의 인스턴스의 수가 매일 3대에서 70대까지 변합니다.
• 데일리 컨텐츠 푸시를 위하여 주중 아침마다 AWS SNS를 이용하여 200만 개 이상의 디바이스에 푸시를 한 번에 발송합니다.
• 테스트 코드가 많다 보니 테스트 코드를 실행하는 데만 2시간이 걸리기 때문에 Jenkins, CodeBuild, ECR을 이용하여 BuildFarm을 만들었습니다. CodeBuild를 이용하여 원하는 수 만큼의 Slave를 만들어 병렬로 테스트 코드를 돌립니다.

[질문 3] 어떤 개발 문화를 갖고 있나요?

우선 첫 번째 회고와 오버 커뮤니케이션을 굉장히 중요하게 생각합니다. 저희는 팀의 규모가 작을때 부터 커진 지금도 주기적인 회고를 통하여 어떤 문제점이 있는지 발견하고 그 문제점을 개선하기 위하여 계속 노력합니다. 그 결과 개발팀이 5명도 안되게 작을때부터 20명이된 지금까지 끊임없이 현재 저희에게 맞는 업무 구조와 프로세스를 찾기 위하여 많은 변화를 시도했습니다.

오버 커뮤니케이션을 위해 매일 아침마다 제품 개발에 관련된 모든 인원이 모여 데일리 스크럼 미팅을 진행합니다. 개발, 기획, 디자인 팀 구성원들이 보여서 회사에 크게 진행되고 있는 이슈들에 대해서 진행 상황과 문제 상황등을 동기화하는 시간을 갖습니다. 그리고 업무시간 종료 직전에 하루 일과에 대한 공유 시간을 갖습니다. 오늘은 어떤 일이 진행됐고 어떤 문제가 있는지를 동기화하면서 서로 도움을 줄 수 있는 부분을 찾습니다.

회고와 오버커뮤니케이션에 대해서는 드라마앤컴퍼니 CTO이신 세준님의 사내 인터뷰에(https://post.naver.com/viewer/postView.nhn?volumeNo=17104973&memberNo=39874958)서 더 자세하게 확인하실 수 있습니다.

두 번째 페어 프로그래밍, 코드 리뷰를 적극 활용합니다. 페어 프로그래밍과 코드 리뷰 모두 장단점을 갖고 있는 방법입니다. 개발자가 한 명이 개발에 집중할 수 있는 시간이 줄어든다는 단점이 있지만 업무 스타일이나 코딩 스타일, 다른 사람이 작업한 영역 등을 굉장히 효율적으로 동기화할 수 있고 까다로운 작업을 할 땐 버그의 위험성을 매우 낮춰주는 등 많은 장점들이 있습니다. 모든 일에 대해 적용한다면 매우 비효율적이겠지만 특정 상황에서는 이만큼의 좋은 효율성을 내는 방법도 없다고 생각합니다. 저희는 이 방법론이 가장 큰 효율을 낼 수 있을 때마다 잘 사용하고 있습니다.

세 번째 문서화가 매우 잘 되어있습니다. 웬만한 업무는 다 Jira 이슈로 관리되며 처리된 내용은 Jira 이슈나 Confluence Wiki 페이지로 관리됩니다. Wiki 페이지, Git 커밋 메시지, Pull Request, 릴리즈 노트 등 모든 곳에 지라 이슈 번호가 따라다닙니다. 서식을 맞추는 데 힘을 빼는 문서화가 아닌 기록을 위한 문서로 만듭니다. 최대한 힘을 안 들이고 쓰되 나중에 이 이슈를 다시 봐야 하는 경우 이 당시 상황을 이해할 수 있을 정도로만 문서를 작성합니다.

마지막으로 기술을 제대로 사용할 줄 아는 팀이라고 생각합니다. 개발자가 더 나은 기술을 좇는 것은 좋은 자세지만 이 자세가 과하면 일을 망치는 경우가 많습니다. 기술은 개발자 개인의 만족감을 채워주는 것이 아니라 우리 이루고자 하는 목적을 위해 필요한 것입니다. 따라서 많은 개발자가 쉽게 빠질 수 있는 오버 엔지니어링과 Hype Driven Development(설레발 주도 개발)은 피합니다. 그렇다고 절대로 과거 기술에만 머물러있지는 않습니다. 신기술들을 계속 살펴보며 우리에게 정말 도움이 된다면 바로 사용합니다. 예를 들어 몇 년전 Electron의 아직 정식 버전이 나오기도 전에 리멤버 웹 버전의 데스크톱 개발을 위하여 사용하여 좋은 리텐션 증가를 만들어낸 이력이 있습니다. 기술을 사용하는 이 부분에 대한 보다 자세한 내용은 제가 한 사내 인터뷰 글(https://post.naver.com/viewer/postView.nhn?volumeNo=17322226&memberNo=39874958)에서 더 자세하게 확인하실 수 있습니다.

[질문 4] 앞으로 리멤버의 계획은 어떻게 되나요?

지금까지의 리멤버는 명함관리 유틸리티일 뿐이었지만 저희는 단 한 번도 명함관리앱을 최종 목표로 삼은 적이 없습니다. 이미 그 다음 단계로 넘어가기 위한 작업이 한창입니다. 여기서 모든 내용을 설명하자면 글이 너무 길어질 것 같으니 자세한 건 다음 기사들을 읽어보시면 도움이 될 것 같습니다.

[단독] 네이버 리멤버, 명함관리 넘어 ‘한국판 링크드인’ 띄운다 (https://news.joins.com/article/23401613)

믿을만한 전문가 찾는다면…명함 앱 리멤버, 매칭 서비스 출시 (http://www.etnews.com/20181119000331)

[히든히어로즈(39)] “앞으론 리멤버에서 인맥 찾으세요” (http://view.asiae.co.kr/news/view.htm?idxno=2019020715282622041)

[마무리]

이 글을 보시고 리멤버에 대한 궁금증이 조금 풀리셨길 기대해봅니다. 혹시 이 글을 보시고 리멤버에서 함께 일하고 싶은 마음이 생기셨다면 주저말고 지원 해주시길 바랍니다. http://dramancompany.com/joinus/ 페이지에서 리쿠르팅중인 포지션에 대한 보다 자세한 내용을 확인하실 수 있습니다.