이야기의 시작은 The Work Shop이라는 글로벌 개발기업에서 출발합니다. 저는 '쌤'이라는 이름으로 게임 서버 엔지니어로 일했습니다. 당시 제가 맡았던 중요한 프로젝트 중 하나는 C++로 작성된 IOCP 기반의 고성능 서버를 웹 환경에 맞추어 Java로 리빌딩하는 작업이었습니다. 이 작업은 성공적으로 마무리되었고, 이후 스페인 말라가의 개발팀에 해당 기술 지식을 이전하고 전파하는 일을 맡았습니다.

그때가 2010년 무렵이었으며, Java의 안정적 버전은 7이었습니다. Java는 C++만큼의 고성능 네트워크 처리를 제공하기에는 한계가 있었습니다. 이 문제를 해결하기 위해 선택한 대안은 JVM 진영의 'Akka'라는 액터 기반의 프레임워크였습니다. 제가 속한 한국팀은 Akka를 이용해 서버 리빌딩을 성공적으로 마쳤습니다. 만약 이 기술이 없었다면, IOCP를 사용한 고성능 서버 1대를 대체하기 위해서 최소 10배 이상의 서버가 필요했을 것입니다.

당시 클러스터 테스트에 사용했던 엔터프라이즈급 JMeter도 C++ 서버의 최고 로드 수준에 도달하기 전에 먼저 한계를 드러내곤 했습니다. 이는 로드 테스트 기기를 분산 확장하는 데 많은 비용을 들이게 만들었습니다. C++로 작성된 멀티플레이어 게임 서버는 액티브 오브젝트 패턴을 활용해 IOCP로 분산 처리되었는데, 이러한 설계가 Akka의 액터 모델과 Netty를 통한 Remote 레이어와 유사했습니다. Akka는 우리가 그동안 내부적으로 유지하던 분산 처리 엔진을 오픈된 형태로 툴킷화해 사용할 수 있다는 점에서 큰 이점이 있었습니다. 포인트 관리나 멀티스레드 프로그래밍을 신경 쓰지 않고도 분산 처리를 가능하게 했죠. 당시 Java 7 환경에서는 Akka가 유일한 대안이었습니다.

Akka는 임백준 님에 의해 국내에 소개되었지만, 그 소개 이전에 이미 한국의 개발팀이 글로벌 트래픽을 감당하기 위해 Akka를 활용해 최초의 상용화에 성공했습니다. 특히 특정 분야에서는 영국 1위, 북미 10위 내에 드는 글로벌 트래픽을 처리해야 했기 때문에 Akka의 안정성과 확장성이 필수적이었습니다.

이미 성공한 The Work Shop (Bodog)은 국내 동일 비즈니스 카테고리에서도 벤치마크를 하거나 이 분야에서 성공한 프로젝트를 개발하는 곳이었습니다. 이러한 개발 경험을 바탕으로 저는 VGW라는 호주 퍼스에 위치한 글로벌 개발기업에 합류할 기회를 얻었습니다. 이곳은 영어 기술 인터뷰가 필수였던 기업이었으며, 호주에 있는 회사 건물에 처음 들어갔을 때 "이곳에 영어를 못하는 사람은 나 하나뿐이구나"라는 두려움을 느꼈던 기억이 아직도 생생합니다. 이 팀에서의 도전기는 저에게 큰 의미로 남아 있습니다.

이후 저는 스페인과 호주 개발 문화를 비교하고, 그때 경험했던 방법론들을 공유하고자 합니다. 스페인의 개발팀과 협력하며 배운 점, 그리고 호주에서 영어라는 장벽 속에서 애자일 방식이 작동하는 글로벌 환경에서의 경험을 통해 배운 점들을 자세히 이야기해 보려 합니다.

점심문화와 회식

먼저 스페인의 점심문화를 이해하기 위해서는 시에스타라는 스페인의 문화를 이해할 필요가 있습니다. 이곳은 날씨가 더워 점심때 국내로 치면 군대에서 오후 활동을 중단하고 잠을 자는 오침 문화와 비슷합니다. 하지만 시에스타라는 문화는 전통적인 면이 있어, 외부 활동을 하지 않는 오피스 근무 환경에서도 이 문화가 개발팀에 반영되어 있었습니다. 즉, 점심 외에 시에스타 시간에 별도의 휴식 활동이 더 주어지며, 이 시간을 모르고 담당자를 찾아가면 한국에서 점심시간에 업무 담당자를 찾는 것과 유사한 실례를 범할 수 있었습니다.

반면 호주의 경우 점심시간이라는 별도의 시간이 존재하지 않았으며, 샌드위치를 먹으며 일을 쉬지 않고 하는 주변 팀원들을 많이 보았습니다. 그러나 자율적 책임에 따라 오늘 할 일을 빨리 끝내면 빨리 퇴근하기도 했습니다. 퇴근 후에도 팀에 문제가 발생하면 업무 메신저를 통해 적극적으로 대응하고 문제를 해결하는 모습을 자주 볼 수 있었습니다. 그리고 금요일은 항상 재택 근무로, 금요일에 발생하는 모든 미팅은 온라인으로 진행되었습니다.

점심시간에 대한 여유 및 업무 강도는 호주 > 한국 > 스페인 순이었습니다.

회식 문화에서도 차이가 있었습니다. 스페인의 경우 저녁 10시가 되어도 해가 지지 않는 경우가 많았습니다. 스페인의 개발팀 회식은 1차로 팀원과 함께하는 것으로 끝나며, 대부분 가족이나 연인과 함께하는 시간으로 흩어집니다. 그러나 3차 시점에 길을 가다 서로 마주치면 흩어진 구성원의 지인들이 새로운 파티를 구성하며 만남을 가지기도 합니다. 이러한 과정이 몇 차례 반복되면서 만나는 사람의 구성이 계속 바뀌게 됩니다. 1차에서 시작해 같은 구성원으로 진행하며 구성원이 빠지는 한국과는 다른 모습입니다.

호주에서는 회식도 업무의 연장이기 때문에 철저하게 회의 스케줄을 잡는 것 이상으로 스케줄 등록 및 관리가 이루어집니다. 여기서는 저녁 시간은 주로 가족과 함께 보내는 것을 선호하며, 가끔 주말에 자유로운 모임을 기획하기도 하지만 가족이 함께 참여하는 경우가 많습니다. 그 그룹에 끼어 어색하기도 했지만, 이러한 문화 속에서 새로운 경험을 할 수 있었습니다.

이러한 문화적 차이가 IT가 발전하고 개인화가 이루어지는 상황에서도 어느 정도 반영되는 것을 볼 수 있었습니다.

출근길과 퇴근길

말라가의 경우 다소 외곽의 장소에 자연친화적인 곳에 IT 단지가 형성되어 있어 주변에 오리와 같은 방목 동물들이 돌아다녔습니다. 호주 퍼스의 경우 신도시로 모던한 건물과 퍼스 앞에 있는 스완 강(Swan River) 전경을 볼 수 있었습니다. 두 도시 모두 인근 관광도시로, 퇴근 후에는 관광을 하는 느낌으로 주변을 둘러보곤 했습니다.

말라가는 피카소의 고향인 만큼 유적지가 많았으며, 호주 퍼스의 경우 도시 자체가 다국적 문화를 수용하는 컨셉의 도시였기 때문에 다양한 세계의 음식을 경험할 수 있었습니다.

한국의 경우 "지옥철"이라는 별도의 설명이 필요 없을 정도로 출퇴근 시간이 혼잡합니다. 출근과 퇴근의 여유로움은 스페인 > 호주 > 한국 순서였습니다.

호주에서는 데일리 미팅 내용을 영어로 준비해야 했기 때문에 개인적인 관점에서는 출근길의 압박감이 호주가 가장 높았습니다. 출근 후 스페인과 한국의 경우 업무 준비를 위한 커피 타임을 갖는 편인데, 호주에서는 정시에 미팅을 시작해야 했기 때문에 커피 타임은 업무 시작 30분 전에만 가능했습니다.

도메인주도 개발편

국내에서 DDD(도메인 주도 개발)라는 단어가 거의 알려지지도 않고 도입 사례도 없던 시점에, 호주에서 도메인 주도 개발 방법을 팀에서 채택하고 아키텍처를 개선하려는 활동에 참여하면서 인상 깊었던 점이 있습니다.

"아키텍처는 얼마나 멋진지 판단하기 위한 척도가 아니다. 아키텍처 스타일과 패턴은 모든 가능한 위치마다 적용해야만 하는 멋진 도구들을 담아둔 복주머니가 아니다. 적용 가능한 가운데, 프로젝트나 시스템의 실패 리스크를 줄여주는 위치에서만 사용해야 한다." - DDD 구현하기 178, 반 버논

국내의 경우 아키텍처가 상위에서 내려오는 탑다운 방식으로 진행되는 것이 일반적이지만, 위와 같은 원칙을 준수하며 팀이 학습하고 수준을 끌어올리는 데 상당히 신경을 쓰는 모습을 보았습니다.

현재는 이벤트 소싱이라는 단어가 익숙할 수 있지만, 정확히 8년 전 당시에는 이벤트 소싱을 활용해 월렛의 성능을 획기적으로 개선하고 프로덕트에 반영해 성공한 사례가 있었습니다. 특정 팀이 이 성공을 이루었고, 그 성공 사례를 통해 옆 팀에 전파하며 좋은 기술을 주고받는 이상적인 팀의 모습을 보게 되었습니다.

우리는 '기획'이라는 명칭하에 기획이 완료되어야 개발이 시작되는 모습이 아닌, 초기부터 프로덕트 책임자, 비즈니스 분석가, 도메인 전문가가 함께 문제를 논의하고 설계하는 다소 특이한 형태의 개발 방식을 사용했습니다.

개발팀은 이를 위해 우리 수준을 끌어올리기 위해 필수 도서를 학습하고 학습 내용을 공유하며 서로가 이해하는 수준을 맞추는 활동을 꾸준히 했습니다. 이러한 활동은 회사의 중요한 자산으로 여겨졌으며, SMART 목표 설정 기법을 사용해 팀의 능력을 끌어올리는 활동을 스프린트와 별개로 함께했습니다.

CTO와 개발팀 리더는 CQRS(명령-질의 책임 분리)/이벤트 소싱을 활용해 우리 프로덕트에서 발생하는 문제를 해결하는 샘플 코드를 작성하고 퍼포먼스 테스트를 지속적으로 수행했습니다. 이러한 노력은 아직도 인상에 남아 있습니다.

이후 국내로 복귀해 DDD를 살펴보기 시작했으며, 그때 배운 점을 팀에도 소개하기 시작했습니다. 하지만 DDD를 도입하려면 지금까지 이상의 개발 수준과 철학이 필요하다는 전제조건이 있었습니다. 팀이 공부하고 학습하며 능력을 끌어올려야 한다는 전제조건을 달성하지 못한 이유로 여러 가지 핑계가 있었지만, DDD를 함께 공부하고 싶어 'Domain-Driven Design Distilled'라는 가장 얇은 책 20권을 자비로 주문해 대표님, CTO, 영업 책임자, 기획자, 개발자에게 배포했던 적이 있습니다. DDD를 도입하려면 개발자만이 아니라 모두가 참여하고 이해해야 한다는 조건이 있었기 때문입니다.

우리 수준을 돌아보았을 때, 우리는 그문제가 워터폴 방식이라고 문제를 돌리지만, 사실 워터폴의 절차도 제대로 수행하지 못한 점을 DDD를 통해 반성하기도 했습니다. DDD에서 이야기하는 CQRS는 CRUD를 제대로 하고 그 한계점을 이해했을 때 다음 단계로 넘어가는 것이지, CRUD를 제대로 하지 못한 채로 CQRS로 넘어가는 것은 있을 수 없다고 고민했습니다.

워터폴을 이해하려면 "고약한문제 합당한 해결" 이라는 책을 추천합니다. 애자일이 만능약이라고 외치는것이 아닌 우리는 워터폴부터 다시배워야할수도 있습니다.

어쨌든 수준 높은 개발팀이 되기 위한 노력으로 우리 팀의 수준을 측정하고 그 수준에 머무르지 않고 다음 단계로 나아가기 위해 했던 노력들은 인상 깊었습니다. 실제로 그러한 활동을 스프린트에 추가하면서 달성했다는 점은 좋은 팀의 모습이었던 것 같습니다.

이때 팀 리더가 피지컬적으로도 뛰어났던 점이 기억에 남습니다. 그는 기술적인 리딩뿐만 아니라 아마추어 철인 3종 경기 챔피언이기도 했습니다. 여러 가지로 배울 점이 많았던 팀과 리더의 모습이었습니다.