8년 근속 후 아틀라시안 해고? 좌절 딛고 일어선 저의 이야기 🌟

8년 동안 Atlassian에서 내가 만든 것들 (그리고 배운 것들)

안녕! 나 Atlassian에서 일하다가 나오게 됐는데, 8년 동안 거기서 뭘 했는지, 뭘 만들었는지 좀 얘기해볼까 해. 혹시 나랑 비슷한 상황에 있는 사람한테 도움이 되거나 영감을 줄 수 있으면 좋겠어. 기술적인 내용도 많겠지만, 중간중간 안 기술적인 이야기도 좀 할게. 영상은 챕터별로 나눠놨으니까 관심 있는 부분만 골라 봐도 돼!

1. Atlassian 입사: 면접부터 첫 프로젝트까지

8년 전 면접 봤던 기억이 아직도 생생해. 지금이랑 좀 다르긴 한데, 그때 나를 뽑아준 이유, 그리고 내가 처음부터 뭘 했는지 얘기해줄게.

면접 과정:

• HackerRank 코딩 테스트: 이걸 만점으로 통과했어.
• 1차 기술 면접: 두 분의 면접관이 계셨는데, 나한테 Cloudflare에서 만든 '커스텀 도메인'에 대한 백서를 주고 10분 동안 읽어보라고 하셨어. 그리고 백서 내용을 설명하고, 마이크로서비스, 아키텍처, 컨테이너 같은 것들에 대해 질문하셨지. 다행히 만족스러워하셨어.
• 2차 기술 면접: 이건 좀 재밌는 트러블슈팅 연습이었어. Atlassian에서 실제로 있었던 서비스 거부(Denial of Service) 공격 같은 실제 장애 상황을 주고, 내가 면접관한테 질문하면서 원인을 찾아내는 방식이었지. DNS 지연 시간 기반 라우팅에 대한 질문도 있었는데, 내가 생각했던 거랑 좀 달랐지만 나름 잘 설명했던 것 같아.
• 인성 면접 (Values Interview): 솔직히 질문 내용은 잘 기억 안 나는데, 딱 하나 기억나는 건 내가 면접관한테 "1년 뒤에 제가 뭘 해내야 제가 당신들한테 좋은 결정이었다고 생각할까요?"라고 물어봤던 거야. 그때 Atlassian 내부 개발자들이 쓸 수 있는 '셀프 서비스 로드 밸런서'를 만드는 애플리케이션이 필요하다고 하셨어. 아마존 로드 밸런서 같은 걸 내부적으로 쓸 수 있게 해주는 거지. 내가 파이썬으로 웹 앱 만드는 데 자신 있다고 했고, 그걸 믿고 날 뽑아줬어.

입사 후 첫 프로젝트: 오픈 서비스 브로커 (Open Service Broker)

Atlassian에 오면 '소방 호스에서 물 마시는 것 같다'는 말이 있어. 처음 몇 주, 몇 달 동안 엄청나게 많은 정보를 쏟아붓는다는 뜻이지. 내가 스스로에게 준 첫 번째 임무는 면접 때 말했던 그 '셀프 서비스 로드 밸런서'를 만드는 애플리케이션을 만드는 거였어.

이게 바로 오픈 서비스 브로커(Open Service Broker)라는 거야. 간단히 말하면, 플랫폼에서 필요한 자원을 자동으로 만들어주는 웹 앱이랑 API라고 생각하면 돼. 쿠버네티스 같은 환경에서 많이 쓰이는데, 데이터베이스 같은 걸 요청하면 그걸 알아서 만들어주고, 내 서비스랑 연결해주는 거지.

• 기술 스택: 처음에는 connection이라는 파이썬 라이브러리를 썼는데, 나중에는 Flask를 거쳐서 FastAPI로 바꿨어.
• 동작 방식:
  1. 클라이언트(개발자)가 로드 밸런서 같은 걸 만들어달라고 요청해.
  2. FastAPI 앱은 이 요청을 바로 처리하지 않고, SQS라는 메시지 큐에 작업을 넣어둬.
  3. 별도의 워커(Worker)가 SQS에서 작업을 가져와서 실제 로드 밸런서 생성 같은 일을 해. (이건 비동기적으로 처리돼)
  4. 작업이 끝나면 결과를 데이터베이스에 저장해.
  5. 클라이언트는 계속 상태를 확인하다가, 작업이 완료되면 결과를 받아봐. 실패하면 오류 메시지를 받게 되지.

이걸로 개발자들이 직접 로드 밸런서를 설정하는 수고를 덜어줄 수 있었어.

2. Envoy 프록시와 관리 서버 구축

그다음으로 내가 맡았던 건 Atlassian의 기존 로드 밸런서를 Envoy 프록시라는 오픈소스 솔루션으로 바꾸는 거였어. Envoy는 Nginx랑 비슷한데 좀 더 최신 기술이라고 생각하면 돼.

• 목표: 비싼 라이선스 비용이 드는 기존 로드 밸런서를 대체하고, 개발자들이 직접 로드 밸런싱을 설정할 수 있게 하는 것.
• Envoy의 특징: 동적으로 설정을 변경할 수 있어서, 실행 중에 설정을 바로바로 업데이트할 수 있어.

이걸 가능하게 하기 위해 내가 만든 게 바로 Envoy 관리 서버 (Envoy Control Plane), 코드 이름은 Sovereign이야.

• 기술 스택: 이것도 FastAPI로 만들었어.
• 동작 방식:
  1. Sovereign은 템플릿과 컨텍스트(Context)를 설정으로 받아들여.
  2. 템플릿은 Envoy의 설정 요소들(클러스터, 라우트, 리스너 등)을 정의해.
  3. 컨텍스트는 데이터베이스나 S3 같은 곳에서 동적으로 가져와.
  4. Sovereign은 이 템플릿과 컨텍스트를 합쳐서 Envoy가 이해할 수 있는 설정 파일을 만들어.
  5. Envoy 프록시는 이 설정을 주기적으로 가져와서 적용해.
  6. 개발자가 로드 밸런서 설정을 변경하면, 그게 데이터베이스에 반영되고, Sovereign이 이걸 읽어서 Envoy 설정을 업데이트하는 식이지.

결과적으로, 개발자가 요청하면 자동으로 로드 밸런서가 설정되고, Envoy 프록시가 그 설정을 받아서 트래픽을 처리하게 된 거야.

3. 인프라 구축: CloudFormation, Packer, SaltStack

이 Envoy 프록시들이 실제로 어떻게 만들어지고 운영되는지도 내가 관여했던 부분이야.

• CloudFormation: AWS의 인프라를 코드로 관리하는 도구인데, 이걸로 VPC, 서브넷, 보안 그룹, 오토 스케일링 그룹 같은 수많은 AWS 리소스들을 자동으로 만들어줬어. 수천 개의 프록시를 여러 리전에 걸쳐서 배포하는 데 쓰였지.
• AMI (Amazon Machine Image) 제작: 프록시들이 실행될 가상 머신 이미지를 만들어야 했어. 이걸 위해 Packer라는 도구를 사용했고, SaltStack이라는 설정 관리 도구로 Envoy, 로깅 에이전트, 보안 설정 등을 미리 설치하고 구성했어.
  • Packer: EC2 인스턴스를 만들고, SaltStack 설정을 적용한 뒤, 그걸 이미지로 만드는 역할을 했어.
  • SaltStack: 마치 윈도우에 프로그램 설치하고 설정하는 것처럼, 서버에 필요한 패키지를 설치하고 파일을 배치하고 서비스를 실행하는 과정을 자동화해주는 도구야.
• 결론적으로: 개발자가 "내 서비스 인터넷에 공개하고 싶어!"라고 하면, 우리가 만든 시스템이 자동으로 로드 밸런서를 설정해주고, 그 로드 밸런서 역할을 하는 Envoy 프록시들이 이미 만들어져서 트래픽을 처리하는 구조가 완성된 거지. 이게 내가 Atlassian에서 처음 2년 동안 했던 일들이야.

4. 플랫폼 확장 및 주요 서비스 마이그레이션

그다음 단계는 우리가 만든 이 중앙 집중식 로드 밸런싱 플랫폼을 Atlassian의 다른 큰 서비스들(Jira, Confluence, Bitbucket 등)이 사용하도록 만드는 거였어.

• 목표: 모든 마이크로서비스가 우리 플랫폼을 통해 로드 밸런싱되도록 강제하고, 보안 및 라우팅 설정을 중앙에서 관리하는 것.
• 효과: 이전에는 실수로 서비스가 외부에 노출될 수도 있었는데, 이제는 명시적으로 설정해야만 외부에서 접근할 수 있게 되어 보안이 강화되었어.

5. Envoy 기능 확장 및 중앙 집중식 로직 구현

이제 플랫폼의 기반이 마련되었으니, Envoy 프록시가 제공하는 더 많은 기능들을 활용하고 개발자들이 쉽게 사용할 수 있도록 만드는 데 집중했어.

• Envoy의 복잡성: Envoy는 라우팅, 헤더 조작, 인증, 권한 부여 등 정말 많은 설정을 할 수 있어. 이걸 개발자들이 직접 다루기에는 너무 복잡했지.
• 템플릿 기반 추상화: 그래서 우리는 개발자들이 간단한 입력값만 주면, 그게 템플릿을 통해 복잡한 Envoy 설정으로 바뀌도록 만들었어. 예를 들어, 개발자가 JSON 파일 하나만 보내면, 우리가 알아서 접근 로그, 인증, DDoS 방어 같은 기능들을 설정해주는 거지.
• 중앙 집중식 로직: 이렇게 하면 회사 전체적으로 반복되는 작업(인증, 권한 부여, DDoS 방어, 속도 제한 등)을 한 곳에서만 처리하면 되니까, 엄청난 시간과 비용을 절약할 수 있었어. 수많은 백엔드 서비스마다 이런 기능을 따로 구현하는 건 비효율적이잖아.
• 구현 방식:
  • DDoS 방어: CloudFront를 활용했어.
  • 접근 로그: Envoy의 HTTP 연결 관리자(HCM) 필터를 사용해서 프록시 자체에서 처리했어.
  • 인증/권한 부여/속도 제한: 이건 사이드카(Sidecar)라는 모델을 사용했어. Envoy 옆에 별도의 작은 컨테이너(서비스)를 두는 건데, 인증 사이드카는 내가 Rust로 직접 만들었고, 권한 부여와 속도 제한은 다른 팀에서 만들었어. 이 사이드카들도 AMI 제작 과정에서 자동으로 설치되도록 했지.

결과적으로, 개발자는 간단한 설정만으로도 강력하고 안전한 로드 밸런싱을 사용할 수 있게 된 거야.

6. 비기술적인 경험: 외교술, 유지보수, 멘토링

기술적인 이야기만 하면 좀 지루하니까, 8년 동안 Atlassian에서 겪었던 비기술적인 경험들도 좀 얘기해볼게.

• 외교술, 갈등 관리: 다양한 상사, 동료들과 일하면서 성격이나 일하는 방식이 다른 사람들과 부딪히기도 했어. 하지만 이런 경험들을 통해 갈등을 피하거나 해결하는 능력, 다른 사람을 설득하고 가르치는 능력 같은 외교술이 많이 늘었지.
• 소프트웨어 유지보수: 처음에는 새로운 걸 만드는 게 재밌지만, 시간이 지나면서 기존 시스템을 유지보수하는 게 얼마나 중요한지 깨달았어. 사람들이 계속 바뀌고, 코드가 계속 수정되면서 복잡해지는 걸 보면서, 어떻게 하면 이런 복잡성을 줄이고 오래도록 관리하기 쉬운 시스템을 만들 수 있을지 고민하게 됐지. 특히 코드가 계속 바뀌는 부분(churn)을 보면 뭔가 문제가 있다는 신호라고 생각했어.
• 멘토링: 동료들을 가르치고 어려운 개념을 쉽게 설명해주는 건 잘하는 편이었는데, 멘토링은 좀 달랐어. 한 인턴 친구를 지도했는데, 결과는 아주 좋았어. 하지만 멘티에게 얼마나 시간을 할애해야 할지, 어떤 방식으로 도와줘야 할지(답을 바로 주는 게 아니라 스스로 해결하도록 유도하는 것) 균형을 맞추는 게 쉽지 않았지. 내가 직접 멘토링을 받아본 경험이 없어서 더 그랬던 것 같아. 그래도 동료들의 도움 덕분에 인턴 친구가 좋은 결과를 낼 수 있었고, 나도 이 경험을 통해 많이 배울 수 있었어.

마무리

이렇게 Atlassian에서 8년 동안 내가 했던 일들과 배운 것들을 이야기해봤어. 처음에는 기술적인 내용이 많았지만, 결국 사람들과 함께 일하고 시스템을 유지보수하는 과정에서 많은 걸 배웠던 것 같아.

혹시 내가 만든 것들을 직접 만들어보는 걸 보고 싶다면, 아니면 더 궁금한 점이 있다면 댓글로 알려줘! 수요가 많으면 스트리밍이나 영상으로 다시 만들어볼 수도 있을 것 같아.

긴 영상 끝까지 봐줘서 고맙고, 도움이 되었으면 좋겠어! 다음에 또 보자!