세 번째 인터뷰의 주인공은 오픈소스 개발자 이희승 님입니다. 비동기를 사랑하는 오픈소스 개발자, 희승 님의 이야기를 만나 보시죠.
Q. 희승 님 안녕하세요. 먼저 간단하게 자기소개 부탁드립니다.
A. 안녕하세요. LINE에서 Armeria, Central Dogma와 같은 오픈소스를 개발하고 있는 이희승입니다. LINE에 오기 전, Twitter에 있을 때는 Netty라는 오픈소스의 메인터넌스와 새로운 기능 개발, 차기 버전 개발을 겸했습니다.
Q. 희승 님은 Netty 프로젝트를 통해 오픈소스 개발자로 유명해졌다고 볼 수 있을 것 같은데요. 요즘 Netty 프로젝트 근황은 어떤가요?
A. Netty 프로젝트의 리드 역할은 현재 Apple에서 근무하는 Norman이라는 분에게 넘겨주었습니다. 오랫동안 프로젝트를 함께 개발해왔던 분이라서 그런지 잘 운영해 주고 계십니다. 다만 아직 Netty에 제가 작업한 부분이 상당히 많이 남아있기 때문에 시간 날 때 주요 PR(Pull Request)을 리뷰하는 정도로는 계속 참여하고 있습니다.
Q. 그렇군요. 그러면 혹시 지금도 리뷰하지 못한 PR이 좀 쌓여 있나요?
A. PR은 항상 쌓여있습니다. :) Netty는 로우(low) 레벨 프로젝트라서 시니어 개발자들이 많이 참여하는 편인데요. 그래서 PR 리뷰가 오래 걸릴 수도 있고 프로젝트 방향과 맞지 않는 PR은 거절될 수도 있다는 걸 개발자들이 어느 정도 인지하고 있습니다. 예전과 비교하면 훨씬 더 많은 개발자들이 오픈소스 프로젝트의 개발 프로세스를 이해하고 있는 것 같아요.
Q. LINE과 Twitter에서 '회사에 속한 오픈소스 개발자'로서 일을 해 오셨는데요. 오픈소스 프로젝트 관리자의 입장에서 옳다고 생각하는 방향과 회사가 원하는 오픈소스의 발전 방향이 달라 중립을 지키기 어려운 경우가 있지는 않았나요?
A. 요즘 회사들은 주로 순수한 엔지니어링 관점에서 오픈소스에 접근합니다. 그렇기 때문에 '회사에 속한 오픈소스 개발자'에게 어떤 방식으로 오픈소스에 기술적 변화를 적용할 것인지에 관하여 상당히 높은 자율성을 부여하는데요. 그래서인지 중립을 지키는 데 크게 어려움을 느낀 적은 없습니다.
Q. 기업들이 오픈소스 개발자를 굳이 직접 채용하는 이유는 무엇이라고 생각하시나요?
A. 사실 오픈소스 프로젝트는 누구나 기여할 수 있기 때문에 오픈소스 개발자를 직접 고용하지 않아도 PR을 보내는 방식 등으로 원하는 기능을 구현할 수 있습니다. 실제로 제가 Twitter에 입사하기 전에 Twitter의 다른 엔지니어가 Netty에 SPDY 프로토콜 구현을 기여한 적이 있어요. 따라서 엄밀히 말하자면 오픈소스에 원하는 기능을 구현하기 위해 개발자를 직접 고용할 필요는 없습니다. 하지만 현실적으로 동일 분야의 유능한 개발자를 찾는 게 쉽지 않아서 기업 입장에서도 만약 사람을 채용한다면 현재 그 프로젝트에 참여하고 있는 사람을 채용하는 쪽이 당연히 낫다고 생각합니다. 실제로 제가 Twitter에서 근무하면서 사내 엔지니어들이 필요하다고 했던 비동기 DNS(Domain Name System) 클라이언트나 SOCKS 프로토콜 같은 기능을 구현했던 일을 돌이켜 보면, 해당 전문가를 직접 채용해서 특정 기능을 먼저 개발해달라고 부탁할 수 있다는 점이 오픈소스 개발자를 직접 채용할 때 얻을 수 있는 큰 장점이 될 수 있을 것 같습니다.
Q. 예전에 오픈소스 프로젝트에서는 의사소통 도구로 전통적인 형태인 메일링 리스트를 사용했는데요. 요즘은 어떻게 하고 있나요?
A. 오픈소스 프로젝트마다 조금씩 다를텐데요. 역사가 깊은 프로젝트에서는 아직 메일링 리스트를 사용하고 있지만 최근 프로젝트에서는 잘 사용하지 않는 것 같습니다. 최근엔 Slack이나 Gitter를 많이 사용하는 것 같아요. 현재 Netty에서는 질문을 Stack Overflow에 올리도록 안내하고 있고요. Armeria에서는 질문을 GitHub에 이슈로 등록해 달라고 안내하고 있습니다. 질문이 이슈로 등록되면 저나 프로젝트 멤버가 해당 이슈에 'question'이라는 라벨을 달아 누구나 쉽게 질문을 모아서 볼 수 있도록 해 둡니다. 프로젝트가 더 커지면 다른 방법을 생각해 보겠지만 아직까지는 이슈 트래커(issue tracker) 본연의 기능을 해치는 정도가 아니어서 괜찮은 것 같습니다.
Q. 오픈소스 프로젝트에 참여하면서 겪은 어려움이 있다면 무엇인가요?
A. 간혹 단시간에 성공하는 프로젝트도 있긴 하지만, 대체로는 성공하기까지 오랜 시간이 걸리는 경향이 있습니다. Netty만 하더라도 프로젝트가 어느 정도 궤도에 오르기까지 꽤 오랜 시간이 걸렸습니다. Apache MINA의 후속작이라는 후광 효과가 있었음에도 불구하고 사용자가 충분히 모이기까지 몇 년의 시간이 필요했으니까요. 그래서 꾸준히 하는 게 정말 중요한 것 같아요.
Q. 희승 님의 업무를 '코딩'과 '코드 리뷰', '기타'로 나누어 본다면 각각에 시간을 어떻게 분배하고 있나요?
A. 저는 코드 리뷰에 가장 많은 시간을 쏟습니다. 그 다음이 직접 개발하는 것이고요.
Q. 그렇군요. 코드 리뷰할 때 주로 어떤 코멘트를 남기시나요?
A. 저는 전체 구조에서 시작해 구체적으로 가독성 측면에서 최적화하는 방향으로 코멘트합니다. 가독성 측면에서는 코드가 더 예뻐보이는(가독성이 좋은) 코딩 방식을 코멘트하거나 네이밍(naming) 컨벤션이나 인덴테이션(indentation, 들여쓰기) 컨벤션 측면에서 코멘트합니다. 그리고 또 하나, 에러 메시지에도 컨벤션이 있는데요. 이 라이브러리를 사용하면 에러 메시지가 이러한 형태로 나온다는 일종의 암묵적인 규칙이 있거든요. 규칙과 다른 형태로 에러 메시지가 나오면 사용자가 놀랄 수 있기 때문에 에러 메시지 컨벤션 측면에서도 코멘트를 남깁니다.
Q. 코드 리뷰 도중 의견이 충돌하면 어떻게 하시나요?
A. 보통 서로 의견이 다를 때 'agree to disagree'라고 하죠. 너와 내가 서로 의견이 다르다는 것에 동의하는 겁니다. 두 의견 다 각각 장단점이 있으니 최대한 합의해서 기술적으로 하나의 선택을 합니다. 물론 속으로 '나는 그래도 이게 맞다고 생각하지만 네가 그렇다면 뭐...'라고 생각하긴 합니다. :)
Q. 저는 글로 논의하다 보면 직접 만나서 얘기하면 좀 더 쉽게 풀릴 것 같다는 생각이 들 때가 종종 있는데요. 희승 님은 어떤 스타일이신가요?
A. 저는 만나서 이야기하는 것보다는 글로 엄밀하게 정리해서 논의하는 것을 선호합니다. 말로 하다보면 말이 꼬일 수도 있고 정제되지 않은 비문을 뱉을 수도 있으니까요. 그리고 오픈소스 프로젝트에 참여하는 모두가 영어로 실시간 커뮤니케이션하는 것에 능통하지 않기도 하고, 그 자리에 없던 사람은 나중에 어떤 논의가 이루어졌는지 파악하기 어렵기도 합니다. 따라서 어떤 사안을 만나서 결정했다고 하더라도 결국에는 글로 정리해 두어야 합니다. 특히나 커뮤니티는 이런 투명성이 보장되어야 잘 운영될 수 있다고 생각합니다.
Q. 본격적으로 Armeria에 관한 질문을 드리기 전에 가벼운 질문 하나 드리고 가겠습니다. 개발자의 취미는 개발이라는 이야기가 있던데 희승 님은 어떠신가요?
A. 하하. 예전에는 그런 편이었는데요. 요즘엔 남는 시간에 가족과 시간을 많이 보내는 편입니다. 집에서 샤오미 워킹패드 위에 올라가 운동하며 유튜브로 개발 컨퍼런스 영상을 보기도 합니다.
비동기 마이크로서비스 프레임워크, Armeria
Q. Armeria는 LINE에 온 뒤에 시작하신 프로젝트인가요? 어떻게 시작하게 됐나요?
A. Netty로 로우 레벨을 닦아놨으니 그 위에 좀 더 편리하게 서버를 만들 수 있는 무언가가 있으면 좋겠다는 생각은 막연히 가지고 있었습니다. 하지만 제가 구체적으로 무언가를 직접 만들어야겠다고 생각하지는 않았어요. Netty만으로도 충분히 바빴거든요. :) 그런데 LINE에 오니 그런 게 필요하다는 명확한 니즈(needs)가 있어서 본격적으로 시작하게 되었습니다.
Q. Armeria에 대해 간단히 설명해 주시겠어요?
A. Netty가 다양한 프로토콜을 교환할 수 있는 일종의 로우 레벨 범용 프레임워크라면, Armeria는 그 위에 구현한 좀 더 높은 레벨의 웹 기반 마이크로서비스 프레임워크입니다. Armeria를 이용하면 고성능의 비동기 리액티브(reactive) 웹 서비스를 손쉽게 개발할 수 있습니다. 세션 계층에서는 HTTP/1, HTTP/2뿐만 아니라 HAProxy 프로토콜까지 지원하고요. 애플리케이션 계층에서는 REST API 외에도 gRPC와 Thrift 양쪽을 모두 지원하는 유일한 오픈소스 프레임워크입니다. 심지어는 기존에 작성한 Java EE(Enterprise Edition) 기반의 웹 애플리케이션도 함께 구동할 수 있어 기존 시스템에서 점진적으로 마이그레이션하는 것도 가능합니다. 그 외에도 마이크로서비스 아키텍처를 구현할 때 필수 기능인 service discovery, circuit breakers, client-side load-balancing, metrics 등의 다양한 기능을 제공합니다.
Q. 웹 서비스를 구현할 때 아직은 동기 방식의 API가 널리 사용되고 있는데요. 반면 Armeria는 비동기로 동작하는 데 초점이 맞춰져 있습니다. 어떤 이유 때문인가요?
A. 전통적인 웹 프레임워크에서 제공하는 동기 방식의 API를 사용한 서비스가 점차 그 규모가 커지게 되면 동기 방식만으로는 처리하기 어려운 상황을 만나게 됩니다. 그래서 서비스가 성장하면 자연스럽게 비동기 방식이나 리액티브한 형태로 진화할 필요가 있습니다. Armeria와 같은 리액티브 프로그래밍 패러다임이나 비동기 패러다임을 지원하는 웹 프레임워크가 필요하게 되는거죠.
Q. 비동기 방식으로 처리하면 더 많은 요청을 처리할 수 있는 건가요?
A. 이 질문엔 상황에 따라 다양한 대답을 할 수 있을 것 같습니다. 그래도 최대한 일반적인 관점에서 답변해 보자면, 스토리지(storage)의 응답 시간이 길어지면 길어질수록 비동기 방식이 월등히 유리해집니다. 특히 백엔드(back-end)의 일부에 장애나 과부하 등이 발생해 응답 속도가 느려지면, 동기 방식은 문제가 발생한 백엔드를 거치지 않는 요청까지도 함께 피해를 보기 때문에 전면적인 장애로 번지게 되는 경우가 많습니다. 반면 비동기 방식은 문제가 발생한 백엔드를 거치지 않는 요청은 특별한 튜닝 없이도 깔끔하게 처리해 낼 수 있어 장애가 크게 번지지 않겠죠. 데이터를 분산 저장하는 요즘 구조에선 중요한 차이라고 말할 수 있습니다.
Q. 그래도 아직까지는 동기 방식의 API가 주를 이루는데요. 비동기 방식이 빠르게 퍼지지 않는 이유는 무엇일까요?
A. 일단 비동기 방식의 아키텍처가 효과를 보기 위해서는 서비스의 스케일이 일정 규모 이상으로 커져야 한다는 이슈가 있습니다. 100명 정도가 접속하는 서비스라면 비동기로 구현하나 동기로 구현하나 큰 차이가 없을 수 있습니다. 서버의 성능이 충분히 좋고 메모리 용량도 충분하다면 동기 방식으로 구현한 서비스도 큰 문제 없이 요청을 처리할 수 있을 테니까요. 문제는 서비스가 성장해서 훨씬 많은 사용자가 접속할 때 발생합니다. 특히 동기 방식으로는 특정 시간대 혹은 갑자기 짧은 시간에 많은 사용자가 몰릴 때 이를 제대로 처리하기 어려울 수 있습니다. 이런 종류의 이슈는 비동기 방식을 사용하면 수월하게 해결할 수 있죠. 따라서 처음부터 비동기 방식으로 개발하면 추후 서비스가 성장했을 때 좀 더 쉽게 대처할 수 있을 겁니다. 그래서인지 최근에는 프로그래밍 언어나 라이브러리 측면에서도 점점 비동기 방식을 지원하고 있는 추세입니다. 요즘 많이 쓰고 있는 Node.js도 기본적으로 비동기 방식이죠. 개발자들 사이에서 전반적으로 비동기 방식이나 리액티브 프로그래밍 방식에 대한 관심이 점점 더 높아지고 이해도도 깊어지고 있다고 느낍니다.
Q. Spring 프레임워크 기반으로는 비동기 API를 만들 수 없나요?
A. 예전에는 어려웠습니다. 그런데 최근에 Spring WebFlux가 등장하면서 Spring 프레임워크 기반으로도 비동기 방식의 웹 애플리케이션이나 리액티브 웹 애플리케이션을 개발할 수 있게 되었습니다. 생각해 보니 비동기 방식에 대한 관심이 확산되고 있다는 좋은 예로 Spring 프레임워크를 들 수 있겠네요. 예전에는 비동기라는 개념을 개발자들이 이해하는 게 쉽지 않았기 때문에 Spring 프레임워크는 대부분 동기 방식으로 구현되어 있었는데요. 그런 Spring 프레임워크에 비동기 방식이 도입되었다는 것은 최근 웹 서비스 규모가 점점 커지면서 개발자들이 비동기 방식에 좀 더 관심을 갖고 깊게 이해하게 되었다는 뜻인 것 같습니다.
Q. LINE에서도 Armeria를 사용하고 있는 서비스들이 많은데요. 희승 님이 생각하는 Armeria의 로드맵과 당장 LINE 서비스에 필요한 요구 사항 사이에서 우선순위나 방향성에 대해 고민한 적은 없으신가요?
A. 오픈소스 프로젝트는 기본적으로 고객, 즉 해당 소프트웨어를 사용하는 다른 개발자들의 피드백에 반응하여 움직이기 마련입니다. 그렇기 때문에 어떤 피드백이든 피드백은 그 자체로 좋은 것이죠. 사랑의 반대말은 증오가 아니라 무관심이란 말도 있으니까요. 그래서 어떤 요청이 들어오면 너무 오래 기다리지 않게 대응하고, 필요한 기능을 구현하고, 전체 로드맵을 지켜가면서 조화로운 그림을 그리는 게 좋다고 생각합니다. 오픈소스는 무엇을 언제까지 반드시 해야만 한다는 게 없어요. 물론 원하는 로드맵이 있을 수는 있지만 만약 고객이 어떤 기능이 빨리 필요하다고 하면 그 일을 먼저 진행할 수도 있습니다. 다만 고객 요청이라도 프로젝트가 근본적으로 추구하는 목표나 프로젝트의 기본 뼈대를 벗어나는 작업은 하면 안 되겠지요. 그런데 그런 수준의 충돌은 잘 일어나지 않습니다. 보통 프로젝트의 범위를 벗어나는 기능 개발을 굳이 저희 쪽으로 요청하지는 않거든요.
Q. 서비스는 서로 경쟁하면서 성장하는 경우가 많습니다. 예를 들면 Uber랑 Lyft처럼요. 그렇다면 Armeria의 경쟁 상대는 누가될까요? 아까 언급되었던 Spring WebFlux일까요?
A. 경쟁 상대라고 할 수도 있고 어떻게 보면 서로 협력하는 관계라고 할 수도 있겠죠. 비동기 방식의 프로그래밍이 점점 성장하고 있다고 해도 아직은 동기 방식의 프로그래밍과 비교해 규모가 작은 게 현실이니까요. 그렇다면 더욱 다양한 선택지를 갖출 수 있도록 생태계가 풍부한 게 서로에게 이득이 될 겁니다. 또한 Armeria는 실제 웹 서비스, 그중에서도 마이크로서비스를 쉽게 구현하는 걸 돕는 데에 집중하지만, Spring은 그것보다 훨씬 더 많은 기능을 제공합니다. 그래서 Armeria는 Spring과 쉽게 통합할 수 있도록 통합 모듈도 제공합니다. 예를 들어 Spring Web의 리액티브 버전인 Spring WebFlux를 사용하면서 HTTP 통신 계층만 Armeria를 사용할 수도 있습니다. LINE에도 Spring 기반으로 만들어진 애플리케이션이 많이 있는데요. Thrift나 RPC 통신은 Armeria가 담당하고 Java EE 기반의 웹 애플리케이션은 Spring이 담당하도록 구성하는 경우가 많습니다.
Q. 그런데 'Armeria'라는 이름은 어떻게 정해졌나요?
A. Armeria를 시작하게 된 계기는 LINE에서 사용하고 있던 Thrift RPC 스택을 좀 더 현대적인 HTTP/2 기반의 비동기 방식으로 변경해 LINE이 겪고 있던 스케일 문제를 해결하기 위해서였습니다. 그래서 이 'Thrift'라는 단어가 중요했죠. Thrift라는 단어를 사전에서 찾아보면 '절약'이라는 뜻도 갖고 있지만 야생화의 한 종류인 'armeria'를 일컫기도 합니다. 이 두 번째 뜻에서 착안하여 프로젝트 이름을 'Armeria'로 정했습니다. 프로젝트 로고는 도식화한 꽃 세 송이가 맞물려있는 모양인데요. 각각의 꽃이 마이크로 서비스를 뜻합니다. 여러 마이크로 서비스가 한데 모여 하나의 큰 서비스를 이룬다는 의미를 담고 있습니다.
LINE에서 함께 일해요!
Q. 희승 님은 어떤 계기로 LINE으로 오게 되었나요?
A. Twitter에서 몇 년 일하고 나니 Netty 메인터넌스도 좋지만 새로운 일도 한번 해보고 싶다는 생각이 들었습니다. 그래서 찾다 보니 LINE은 개발팀도 많고 기술적으로도 흥미로운 일들을 많이 하고 있었습니다. 실력있는 지인들이 이미 다니고 있어서 편하게 일할 수 있겠다는 생각도 했고요. :)
Q. 희승 님 팀에서는 어떤 분과 함께 일하고 싶으신가요?
A. 저희 팀은 Armeria와 Central Dogma를 모두 다루고 있습니다. 오픈소스 개발 경험이 있으면 좋겠지만 사실 이 부분을 크게 기대하지는 않고요. 프레임워크나 라이브러리 개발을 해 보신 분이면 좋을 것 같습니다. 그리고 새로운 API를 디자인할 때는 언어에 대한 조금 더 깊은 이해가 필요하기 때문에 자바 프로그래밍 언어를 잘 이해하고 계신 분이라면 좋겠습니다. 또한 꼼꼼한 분을 선호합니다. 예를 들어 어떤 PR이 있다면 비슷한 수정 사항이 여러 군데 있을 수 있는데요. 코멘트된 부분만 수정하는 분 보다는 일일이 짚어주지 않아도 전체적으로 수정하는 분과 함께 일하고 싶습니다. 마지막으로 텍스트로 커뮤니케이션할 때 어려움이 없는 분이면 좋겠습니다. 메신저로 이야기하다 보면 '비동기'로 일하게 될 때가 많은데요. 따라서 텍스트로 자신의 생각을 표현할 때 인과 관계를 명확하고 자세하게 이야기해 주시는 분이 좋습니다.
Q. 일처리가 꼼꼼하다는 건 사실 같이 일해 보기 전엔 검증하기 어려운 부분인데요. 주로 어떤 방식으로 확인하세요?
A. 맞아요. 아무래도 그저 기본적인 수준의 코딩 테스트만으로 꼼꼼한 사람인지 아닌지를 검증하는 건 조금 어렵죠. 그래서 GitHub 포트폴리오를 살펴보거나 다른 프로젝트에 보냈던 PR을 살펴보는 등의 절차를 거칩니다. 만약 자신만의 오픈소스 프로젝트가 있다면 이런 부분을 좀 더 잘 확인할 수 있겠죠.
Q. 마지막으로 한 말씀 부탁드립니다.
A. 오픈소스 개발자로 활동하다 보면 '오픈소스 프로젝트에 참여하고 싶은데 어떤 프로젝트에 어떻게 참여해야 할지 모르겠다'는 질문을 많이 받습니다. 가장 중요한 건 계속 질문에만 머물러 있기 보다는 자신이 할 수 있는 일을 일단 시작하고 거기서부터 꾸준히 자신을 한계로 밀어붙이는 것입니다. 무엇이든 해 보아야 방향이 보이는 법입니다. '어디가 좋은 길일까?'라는 질문에 너무 오래 사로 잡혀있는 건 좋지 않습니다. 오늘 바로 Armeria나 Central Dogma에 보낼 PR을 준비해 보시면 어떨까요? :)