8년 다닌 회사에서 어느 날 갑자기 정리해고 통보를 받았다고 해 보자. 짐을 챙기고 나면 이력서를 다시 써야 하는데 막상 빈 화면 앞에 앉으면 손이 멈춘다. 매일 정신없이 바빴던 건 분명한데 그 긴 시간 동안 무엇을 만들었고 무엇을 배웠는지 몇 줄로 정리하기가 생각보다 만만치 않다.
인프라 엔지니어 바실리오스 시라키스(Vasilios Syrakis)는 아틀라시안의 정리해고 명단에 오른 뒤 이 질문에 40분짜리 영상으로 답했다. 화이트보드에 직접 그림을 그려 가며 8년 동안 만든 시스템을 하나씩 짚어 보고 끝에는 코드 밖에서 겪은 갈등과 멘토링 이야기까지 솔직하게 털어놓는다. 같은 처지에 놓인 누군가에게 작은 실마리라도 되었으면 하는 마음으로 남긴 기록이다.
시라키스가 다룬 영역은 Jira와 Confluence 같은 제품 맨 앞에서 트래픽을 받아내는 엣지 인프라다. 면접 자리에서 약속한 작은 웹앱 하나가 수천 대의 프록시를 움직이는 전사 플랫폼으로 자라나는 과정을 따라가다 보면 한 엔지니어의 경력이 어떤 모양으로 쌓이는지도 자연스럽게 그려진다.
면접에서 1년 뒤 성공 기준을 거꾸로 물었다
8년 전 아틀라시안의 면접 풍경은 지금과 사뭇 달랐다. HackerRank 코딩 시험을 만점으로 통과하자 면접관 두 명이 Cloudflare의 커스텀 도메인 백서를 건네고 10분 동안 방을 비우더니 돌아와서는 백서 내용을 설명해 보라고 한 뒤 마이크로서비스와 컨테이너에 관한 질문을 이어 갔다. 이어진 두 번째 기술 면접은 아틀라시안에서 실제로 겪었던 장애 사례를 두고 면접관에게 단서를 하나씩 물어 가며 원인을 좁혀 가는 방식이었다.
물론 모든 답을 맞히지는 못했다. 지연 시간 기반 DNS의 동작 원리를 묻는 질문에는 Route 53이 클라이언트의 실제 응답 지연 시간으로 위치를 삼각 측량할 거라고 추론했는데 실제로는 지리 위치 데이터베이스를 조회하는 방식에 가깝다. 그래도 정답을 외워서 대는 대신 기본 원리부터 차근차근 따져 본 태도 덕분에 좋은 점수를 받았다.
마지막 가치관 면접에서는 오히려 면접관에게 질문을 던졌다. 12개월 뒤를 돌아봤을 때 이 사람이 무엇을 해냈어야 뽑길 잘했다고 말하겠느냐는 물음이었다. 면접관들은 사내 개발자가 직접 로드밸런서를 만들어 쓰는 셀프서비스 앱이 시급하다고 답했고 생소한 프레임워크였지만 Python 웹앱 개발에는 자신이 있었기에 해낼 수 있다고 답해 합격을 거머쥐었다.
개발자가 JSON만 보내면 로드밸런서가 생기는 구조
입사 첫 2주 동안 매달린 과제는 면접에서 약속했던 바로 그 앱, 즉 플랫폼 자원을 API 요청 하나로 만들어 주는 표준 규격인 Open Service Broker였다. 처음에는 OpenAPI 문서를 읽어 라우트를 자동으로 묶어 주는 Connexion 라이브러리로 출발해 순수 Flask를 거쳐 지금은 FastAPI 위에서 돌아간다. 개발자가 요청을 보내면 웹 서버는 작업을 SQS 큐에 넣고 백그라운드 작업자가 DNS 레코드나 CloudFront 배포를 비동기로 생성한 뒤 결과를 DynamoDB에 기록하는 동안 클라이언트는 준비가 끝났는지 주기적으로 확인하는 구조다.
현장 요구사항을 파고들수록 판이 커졌다. 한 아키텍트가 비싼 라이선스 비용이 나가는 엔터프라이즈 로드밸런서를 오픈소스 프록시인 Envoy로 바꾸자고 제안한 것이다. Envoy는 Nginx와 비슷하지만 프로세스를 다시 띄우지 않고도 실행 중에 API로 설정을 갈아 끼울 수 있어서 프록시를 미리 잔뜩 띄워 두고 서비스가 바뀔 때마다 설정만 흘려보내면 된다.
그 설정을 동적으로 찍어 내는 관리 서버 Sovereign은 시라키스가 직접 만들어 오픈소스로 공개했다. Envoy의 클러스터·라우트·리스너 같은 자원을 템플릿으로 미리 짜 두고 브로커 데이터베이스나 S3 버킷에서 읽어 온 값을 끼워 넣어 최종 설정을 렌더링하는 방식이다. 덕분에 사내 개발자는 꼭 필요한 몇 가지 값만 담은 작은 JSON만 보내면 되고 접근 로그를 비롯한 복잡한 설정은 템플릿이 알아서 채워 넣는다.
바닥에 깔릴 프록시 인프라는 CloudFormation 템플릿으로 구축했다. VPC와 서브넷, 오토스케일링 그룹, NLB를 한데 묶어 13개 안팎의 리전에 약 2,000대의 프록시를 띄웠고 이 서버들이 쓰는 머신 이미지(AMI)는 HashiCorp Packer로 구웠다. 개발 계정에 EC2를 하나 띄운 뒤 SaltStack으로 Envoy와 로깅·추적 에이전트, 보안 설정, 네트워크 튜닝까지 모두 설치하고 그대로 스냅샷을 뜨는 식인데 여기까지 마치는 데 입사 후 꼬박 24개월이 걸렸다.
인증과 로그를 엣지에서 한 번에 처리하기
기반을 다진 뒤에는 덩치 큰 주력 제품들을 이 플랫폼 위로 옮기는 작업이 기다리고 있었다. Jira, Confluence, Bitbucket, Statuspage 같은 제품마다 저마다의 예외 상황이 얽혀 있어서 범용 멀티테넌트 플랫폼에 올리기까지 필요한 기능을 하나씩 보태느라 몇 년이 훌쩍 지나갔다. 오히려 사내 마이크로서비스들을 옮기는 편이 수월했는데 기존 플랫폼이 기본으로 내주던 단순 로드밸런서로는 더 이상 서비스를 외부 인터넷에 열 수 없도록 정책으로 막았기 때문이다. 외부에 공개하려면 새 엣지 인프라에 명시적으로 등록해야 했고 그 과정에서 실수로 바깥에 열려 있던 내부 서비스들까지 자연스럽게 걸러졌다.
이전이 마무리되자 미리 깔아 둔 동적 설정 구조가 진가를 발휘했다. 인증과 권한 확인, DDoS 방어, 속도 제한, 접근 로그는 어느 서비스에나 꼭 필요한 기능이지만 사내 천 개 팀이 이를 각자 구현하면 비용이 새고 제품 출시도 늦어질 수밖에 없다. 요청이 백엔드 서비스에 닿기 전에 맨 앞단인 엣지에서 한꺼번에 처리하면 회사 전체가 그 비용을 한 번만 치르면 된다.
우선 DDoS 방어는 동료 엔지니어가 앞단에 CloudFront를 세워 해결했고 접근 로그는 프록시 내부에서 Envoy의 네트워크 필터 설정으로 흡수했다. 그보다 복잡한 로직은 프록시 바로 옆에서 컨테이너로 도는 사이드카에 맡겼는데 시라키스가 Rust로 직접 작성한 인증 사이드카에 더해 다른 팀들이 만든 권한 확인과 속도 제한 사이드카가 차례로 합류했다. 사이드카까지 AMI에 함께 구워 넣고 설정을 실시간으로 밀어 넣는 구조가 자리 잡으면서 프록시 계층 전체가 필요에 따라 기능을 프로그래밍해 넣는 무대가 되었다.
플랫폼이 성숙기에 접어든 뒤로는 긴 컴플라이언스 대응이 이어졌다. 새로운 기능을 만드는 대신 이미 돌아가는 시스템이 각종 보안·규제 기준을 충족하는지 점검표를 하나씩 채워 넣는 작업이었는데 시라키스 스스로도 이 시기만큼은 솔직히 지루했다고 돌아본다.
8년 동안 지켜본 유지보수의 어려움
코드를 짜는 일 바깥에서 가장 크게 얻은 자산은 시스템을 오랜 시간 살아남게 하는 감각이었다. 무언가를 처음 만들어 내놓으면 문서를 쓰고 팀원들을 교육해 당직을 설 때 어디부터 살펴야 하는지 길을 터 줘야 한다. 이 로그 메시지가 무슨 뜻인지, AWS 장애로 데이터베이스 연결이 끊기거나 SQS가 멈추면 시스템이 어떻게 반응하는지, 프록시에 내려간 설정이 문법은 멀쩡한데 실제 트래픽을 망가뜨릴 때 어떤 지표로 알아챌지까지 모두 챙겨야 비로소 운영이 굴러간다.
진짜 시험대는 몇 년이 흐른 뒤에 찾아온다. 팀원이 바뀌면 온보딩을 처음부터 다시 해야 하고 새로 합류한 사람은 기존 코드를 보며 자기 방식으로 더 깔끔하게 고치고 싶어 한다. 그렇게 손을 대다 보면 코드 변경이 유독 특정 영역에만 반복해서 몰리는 현상(churn)이 나타나는데 시라키스는 이를 위험 신호로 읽었다. 변경이 한곳에 몰린다는 건 그 모듈의 덩치와 복잡도가 조만간 감당하기 어렵게 불어날 거라는 예고이기 때문이다.
이런 시선은 요즘 유행하는 바이브 코딩으로 빠르게 찍어 낸 앱을 볼 때도 그대로 이어진다. 갓 만든 앱은 아직 변경 이력이 충분히 쌓이지 않아 유지보수 비용이 겉으로 드러나지 않을 뿐이다.
Building something is easy.
처음 만드는 일은 쉽지만 시간이 지나도 계속 고쳐 쓸 수 있는 상태를 지켜 내기는 훨씬 어렵다. 손을 댈수록 코드 조각들이 서로 엉겨 붙고 한쪽을 고치면 전혀 상관없어 보이던 다른 쪽이 깨지기 시작한다. 언젠가 LLM이 그 복잡한 얽힘까지 알아서 풀어 줄 날이 올지도 모르지만 현장에서 8년을 보낸 엔지니어는 성급한 낙관을 경계한다.
갈등과 인턴 멘토링에서 배운 것
한 회사에 8년 몸담는 동안 거쳐 간 관리자와 동료들의 성향도 제각각이었다. 성격이 맞지 않아 세게 부딪힌 사람도 있었는데 돌이켜보면 그중에는 지금도 깊이 존중하는 동료가 섞여 있다. 당시에는 인간관계에서 오는 갈등이 큰 스트레스였고 실제로 업무 성과가 흔들릴 만큼 영향을 받기도 했지만 상대방과 자기 자신의 성향을 객관적으로 들여다보려 애쓰면서 갈등이 터지기 전에 기류를 먼저 읽는 법을 배웠다.
마지막 해에 맡았던 인턴 멘토링도 만만치 않은 숙제였다. 그 인턴이 최고 등급 평가를 받아 정규직 전환이 사실상 확정되었는데도 시라키스는 끝까지 멘토링이 어렵게 느껴졌다고 고백한다. 정답을 바로 떠먹여 주고 싶지는 않지만 그렇다고 인턴이 혼자 너무 오래 막혀 좌절하게 내버려 둘 수도 없어서 어느 선에서 개입해야 할지 끝내 확신이 서지 않았다는 것이다. 정작 본인은 주니어 시절 체계적인 멘토링을 받아 본 경험이 없었기에 참고할 만한 기준점이 없었던 탓도 컸다.
반면 동료들과 머리를 맞대고 문제를 풀거나 복잡한 개념을 알기 쉽게 풀어 설명하는 일은 경력 후반부를 지탱한 가장 큰 보람이었다. 함께 일한 동료들도 시라키스를 두고 언제든 기꺼이 도울 준비가 되어 있고 까다로운 기술 주제를 명쾌하게 정리해 주는 사람이었다는 평가를 남겼다. 영상 말미에 그는 보는 사람들의 관심이 있다면 이번에 칠판 위에서 설명한 엣지 인프라를 처음부터 다시 구현하는 과정도 후속 영상으로 찍어 올리고 싶다고 덧붙였다.
면접장에서 1년 뒤 성공 기준부터 거꾸로 물었던 엔지니어는 그렇게 약속했던 작은 웹앱을 수천 대 규모의 프록시 플랫폼으로 키워 냈고 그 세월 속에서 코드를 고쳐 쓰는 법과 사람 사이에서 일하는 법을 함께 배웠다. 오랜 직장을 떠나 새 이력서를 써야 하는 순간이 온다면 무엇을 만들었는지 못지않게 무엇을 버텨 내며 배웠는지를 돌아보는 일이 그 첫걸음이 될 수 있다.
출처: Vasilios Syrakis, Laid off from Atlassian after 8 years — what I built and learned, YouTube.