🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

I was laid off by Atlassian은 정리해고 이후의 개인 회고를 출발점으로, Atlassian에서 8년간 구축한 중앙화 로드밸런싱·프록시 플랫폼과 그 과정에서 배운 운영·협업의 현실을 정리한 이야기다.

📌 핵심 요점

1. 발표자는 Atlassian 정리해고의 영향을 받은 뒤, 약 8년간 회사에서 만들었던 기술적 산출물과 개인적으로 의미 있었던 경험을 돌아본다.
2. 입사 과정에서는 HackerRank, Cloudflare 관련 기술 설명, 마이크로서비스·아키텍처·컨테이너 논의, 실제 장애 상황 기반 트러블슈팅, 가치 면접이 이어졌고, 내부 개발자를 위한 셀프서비스 로드밸런서 필요성이 초기 과제로 제시됐다.
3. 입사 후 첫 핵심 작업은 Open Service Broker 기반의 프로비저닝 웹앱을 만드는 것이었으며, 이후 FastAPI, SQS, DynamoDB 등을 활용해 시간이 오래 걸리는 인프라 변경을 비동기로 처리하는 구조로 발전했다.
4. 기존 엔터프라이즈 로드밸런서를 Envoy 기반 오픈소스 프록시 구조로 대체하면서, Sovereign이라는 Envoy control plane이 만들어졌고, 템플릿과 컨텍스트를 통해 동적 프록시 설정을 생성하는 방식이 자리 잡았다.
5. 시간이 지나며 Jira, Confluence, Bitbucket, Status Page 등 주요 제품이 중앙화 로드밸런싱 플랫폼 뒤로 이동했고, 이후에는 설정 검증, 공통 보안 기능, 문서화, 온보딩, 갈등 관리, 멘토링 같은 운영·조직 역량이 중요한 과제로 부상했다.

🧩 배경과 문제 정의

• Atlassian에서 정리해고의 영향을 받은 뒤, 발표자는 약 8년간 회사에서 일하며 직접 만들고 운영했던 기술적 산출물을 돌아본다.
• 회고의 초점은 개인적인 감상보다 Atlassian 내부 플랫폼, 로드밸런싱, 프록시 인프라가 어떻게 설계되고 확장되었는지에 맞춰져 있다.
• 초반에는 입사 과정, HackerRank 평가, 기술 면접, 가치 면접, Open Service Broker 관련 과제 등 Atlassian에 합류하게 된 배경이 설명된다.
• 이후 FastAPI 기반 브로커, SQS를 활용한 비동기 프로비저닝, Envoy 기반 셀프서비스 로드밸런싱, Sovereign 관리 서버, CloudFormation·Packer·SaltStack 기반 인프라 구성으로 논의가 확장된다.
• 후반부에서는 Jira, Confluence, Bitbucket, Status Page 같은 주요 제품이 중앙화된 엣지 인프라 뒤로 이동하면서 발생한 검증, 확장, 운영, 문서화, 온보딩 문제를 다룬다.
• 마지막에는 기술 시스템을 구축하는 일뿐 아니라 코드 churn, 유지보수 부담, 갈등 관리, 멘토링 같은 비기술적 역량이 장기적인 플랫폼 운영에서 얼마나 중요한지로 이어진다.

🕒 시간순 섹션별 상세정리

1. 정리해고 이후 8년간의 경험을 회고하는 출발점

• Atlassian 정리해고의 영향을 받은 뒤, 약 8년 동안 회사에서 만들었던 것들과 개인적으로 흥미롭거나 자랑스러웠던 작업을 중심으로 회고를 시작한다. [00:21]
• 이 영상은 단순한 이직 후기라기보다, 자신이 실제로 구축한 시스템과 그 과정에서 배운 점을 기록하려는 회고에 가깝다. [00:21]

2. HackerRank부터 가치 면접까지 이어진 채용 과정

• 초기 면접에서는 지적으로 인상 깊은 면접관들을 만났고, HackerRank 코딩 퀴즈에서 만점을 받은 것이 첫 기술 평가의 핵심 근거가 됐다. [01:18]
• 첫 기술 면접에서는 Cloudflare의 커스텀 도메인 관련 백서를 읽고 내용을 설명해야 했으며, 이어서 마이크로서비스, 아키텍처, 컨테이너 같은 주제까지 다뤘다. [01:39]

3. Open Service Broker 과제와 플랫폼 프로비저닝 구조

• 면접에서 익숙하지 않은 프레임워크 기반 과제를 받았지만, Python 웹앱 구축 경험을 바탕으로 구현 가능성을 설명했고 그 자신감이 채용 결정으로 이어졌다. [04:00]
• 이 과제는 Open Service Broker API와 관련되어 있었으며, 입사 후 실제로 맡게 될 내부 플랫폼 프로비저닝 문제를 미리 보여주는 단서가 됐다. [04:00]

4. OSB API 구현 방식과 FastAPI로의 전환

• OSB 명세는 GitHub에 공개되어 있고, catalog endpoint는 사용 가능한 서비스·플랜·메타데이터를 제공해 내부 콘솔이나 개발자 도구가 프로비저닝 선택지를 표시할 수 있게 한다. [05:42]
• Atlassian에서는 콘솔에서 클릭해 설정하는 방식이 아니라, 버전 관리에 커밋된 설정 파일을 빌드 서버가 업로드하며 서비스 배포와 프로비저닝 흐름을 구성했다. [06:16]

5. 비동기 프로비저닝 브로커 구조

• 클라이언트가 FastAPI 기반 웹 워커에 프로비저닝을 요청하면, 웹 워커는 작업을 직접 처리하지 않고 세부 정보를 SQS에 넣어 별도 워커가 수행하도록 한다. [08:09]
• 프로비저닝에는 DNS 레코드 생성, CloudFront 배포 생성, 여러 API 호출 같은 인프라 변경이 포함되며, 시간이 걸릴 수 있기 때문에 비동기 처리 구조가 필요하다. [08:31]

6. Envoy 기반 셀프서비스 로드밸런싱 전환

• 요구사항을 진행하며 문제를 더 깊이 파악하게 되자, 기존 엔터프라이즈 로드밸런서를 오픈소스 클라우드 네이티브 프록시로 대체할 필요성이 커졌다. [09:59]
• 기존 Atlassian 로드밸런서는 라이선스 비용이 드는 엔터프라이즈 제품이었고, 이를 Envoy proxy 같은 범용 오픈소스 프록시로 바꾸면 비용과 운영 의존성을 줄일 수 있었다. [10:11]

7. Sovereign 관리 서버의 동적 Envoy 설정 생성 구조

• Sovereign은 FastAPI 앱으로 동작하며, 템플릿과 컨텍스트를 입력받아 Envoy 프록시가 사용할 설정 API 형태로 제공한다. [12:04]
• 템플릿은 Envoy의 clusters, routes, listeners 같은 리소스 유형을 나타내며, 관리 서버는 시작 시 템플릿과 컨텍스트를 읽어 프록시 요청에 응답할 준비를 한다. [12:28]

8. AWS CloudFormation 기반 프록시 프로비저닝

• broker, 관리 서버, 클라이언트, 프록시의 전체 구조가 정리된 뒤, 프록시가 무엇이며 어디에 존재하고 어떻게 프로비저닝되는지가 다음 인프라 과제로 제기된다. [14:39]
• 프록시는 대규모로 존재하며, AWS CloudFormation 템플릿을 통해 반복적으로 프로비저닝된다. [14:58]

9. AWS 기본 리소스를 조합해 다지역 프록시 인프라를 구성한다

• EC2 인스턴스를 만들기 위해 Auto Scaling Group에는 AMI가 필요하고, 각 인스턴스에는 IAM 역할, 키 페어, 보안 그룹 같은 기본 AWS 리소스가 연결된다. [16:01]
• 보안 그룹은 Auto Scaling Group에 연결되고 EC2 인스턴스가 이를 상속하는 구조로 설명되며, 여러 리소스 블록을 묶어 반복 가능한 템플릿이 구성된다. [16:21]

10. Packer와 SaltStack으로 프록시용 표준 AMI를 만든다

• AMI는 템플릿이 직접 생성하기보다 참조하는 대상이므로, 프록시들이 공통으로 사용할 표준 이미지를 별도 파이프라인에서 준비해야 한다. [17:23]
• HashiCorp Packer 저장소와 SaltStack 설정을 사용해 개발 계정의 EC2를 생성하고, 해당 인스턴스에 구성 파일을 업로드한 뒤 프로비저닝을 수행한다. [17:48]

11. 중앙화 로드밸런싱 기반과 Atlassian 서비스 마이그레이션

• 프록시가 리소스를 가져와 구성되고 트래픽을 받기 시작하면서, 개발자가 인터넷 접근, 라우팅, 고급 기능을 요청하면 플랫폼이 프로비저닝과 데이터베이스 기록을 통해 준비 상태를 만들 수 있었다. [20:00]
• 관리 서버와 브로커는 현재 상태 데이터를 다른 데이터와 결합해 템플릿에 주입하고, Envoy 요청 시 필요한 리소스를 제공했다. 이 구조는 CloudFormation과 AMI에 의존하는 사전 프로비저닝형 장기 실행 인프라였다. [20:31]

12. 주요 제품 이전 이후 Envoy 설정 복잡성과 검증 필요성

• Jira, Confluence, Bitbucket, Status Page 등 주요 제품이 엣지 인프라 뒤로 이동하면서, 중앙화 로드밸런싱 플랫폼의 적용 범위가 핵심 Atlassian 제품군으로 확대됐다. [22:32]
• 개발자의 기본 입력을 템플릿 기반 설정으로 변환하는 기반 위에서 Envoy 설정 논의가 이어졌고, Envoy는 도메인 수락, 라우팅, 가상 호스트 등 많은 설정 지점을 제공했다. [22:43]

13. 동적 구성과 확장 구조가 멀티테넌트 플랫폼의 기반을 만든다

• 개발 작업은 파라미터 검증과 리소스 생성 로직에 집중됐으며, 검증된 파라미터가 리소스 로직을 통과했을 때 유효한 리소스가 만들어지도록 보장하는 것이 핵심이었다. [24:07]
• 확장 영역에는 listener나 cluster에 적용할 수 있는 여러 extension이 있었고, network filter와 HTTP connection manager를 통해 라우팅, 프록시 처리, 웹소켓 같은 기능을 구성할 수 있었다. [24:38]

14. 공통 관심사를 프록시 계층에서 처리해 비용과 지연을 줄인다

• 제품들이 플랫폼으로 이전된 뒤에는 동적 구성 기반 위에서 로직을 중앙화하고, 요청 체인의 앞단에서 공통 문제를 처리할 기회가 생겼다. [25:41]
• 고객 요청이 NLB를 거쳐 프록시와 백엔드 서비스로 흐르는 구조에서, 문제가 백엔드에 도달하기 전에 처리되면 회사 비용과 고객 대기 시간을 함께 줄일 수 있다. [26:04]

15. 중앙화된 프록시가 공통 플랫폼 기능을 흡수한다

• 백엔드 서비스별로 공통 기능을 따로 구현하면 고객이 필요한 기능을 제때 받지 못할 수 있기 때문에, 플랫폼과 중앙 관리 방식이 리소스와 기능 구현을 흡수한다. [28:01]
• DDoS 보호는 CloudFront가 담당하고, NLB와 양방향 통신 구조를 통해 백엔드 서비스 앞단에서 해당 위험을 처리한다. [28:17]
• 중앙화된 프록시 계층은 보안, 트래픽 제어, 요청 처리 정책 같은 공통 기능을 제품팀 대신 제공할 수 있다. [28:17]
• 이를 통해 제품팀은 핵심 제품 기능에 집중하고, 플랫폼팀은 공통 인프라 기능을 일관되게 제공하는 구조가 된다. [28:17]

16. 사이드카 확장과 컴플라이언스 이후 비기술 역량으로 초점이 이동한다

• 인증, 인가, rate limiting처럼 더 복잡한 기능은 Envoy 옆에서 로컬 서비스로 실행되는 사이드카 모델로 처리되며, 프록시와 별도 로직을 가진 컨테이너 형태로 구성된다. [29:41]
• 인증 사이드카는 Rust로 구현됐고, 인가와 rate limiting은 다른 팀이 담당했으며, 여러 팀의 사이드카는 AMI 프로비저닝 흐름에서 다운로드·설정된다. [30:01]

17. 운영 가능한 시스템을 만들기 위한 문서화와 온보딩

• 교육, 멘토링, 문서화는 팀원이 시스템을 이해하고 기여하며 디버깅할 수 있게 만드는 핵심 유지보수 역량이다. [32:02]
• 서비스 초기에는 온콜 담당자가 어디를 봐야 하는지, 무엇이 고장 날 수 있는지, 어떤 로그와 지표를 확인해야 하는지 알 수 있도록 온보딩과 훈련이 필요하다. [32:37]

18. 시간이 지날수록 커지는 코드 churn과 유지보수 부담

• 시간이 지나면 입사와 퇴사가 반복되며 온보딩 부담이 계속 생기고, 새 구성원은 기존 코드베이스를 개선하려는 의견과 변경을 추가한다. [33:48]
• 특정 영역에서 반복적인 코드 churn이 보이면 그 부분은 크기와 복잡성이 계속 커질 가능성이 높으며, 방치하면 서비스나 프로젝트의 구조적 혼란으로 이어진다. [34:12]

19. 관계 갈등은 성과 저하와 자기 변화의 계기가 된다

• 성격이 맞지 않는 사람과의 갈등은 어느 정도 피하기 어려운 문제로 다뤄지며, 이런 차이를 책임 있게 인식하고 예상되는 충돌을 관리하는 능력이 필요해진다. [36:00]
• 갈등을 줄이려면 자기 인식, 상대에 대한 이해, 사람의 심리를 읽는 능력이 함께 필요하며, 관계가 작동하도록 선제적으로 행동해야 한다. [36:10]

20. 멘토링은 설명 능력과 다르게 균형 잡기가 어렵다

• 복잡한 시스템을 쉽게 설명하고 동료가 이해할 수 있는 정신 모델을 만들도록 돕는 능력은 강점으로 제시되지만, 멘토링은 단순한 설명이나 교육과는 다른 과제로 구분된다. [37:02]
• 멘토링에서는 상대가 직접 생각하고 결정하도록 도와야 하며, 지나치게 지시하지도 너무 방치하지도 않는 균형이 필요하다. [37:02]

21. 마무리 소감

• 발표자는 Atlassian에서 만든 기술 시스템과 그 과정에서 배운 운영·협업상의 교훈을 돌아보며 이야기를 정리한다. [40:01]
• 영상은 기술적 성과뿐 아니라 운영, 문서화, 사람 간 협업에서 얻은 깨달음이 전달되었기를 바라는 소감으로 마무리된다. [40:01]

22. 작별 인사

• 추가 설명 없이 대화를 정리하며 다시 보자는 작별 인사가 이어진다. [40:03]
• 마지막 발화는 짧은 인사로 끝나고, 영상의 본문 논의가 종료된다. [40:05]

🧾 결론

• 이 영상의 핵심은 단순한 정리해고 소감이 아니라, 한 엔지니어가 Atlassian에서 대규모 내부 플랫폼을 만들고 운영하며 겪은 기술적·조직적 학습의 회고다.
• 기술적으로는 Open Service Broker, FastAPI, SQS, DynamoDB, Envoy, CloudFormation, Packer, SaltStack, AMI, AWS 리소스 조합을 통해 중앙화 로드밸런싱 플랫폼이 어떻게 구성됐는지가 주요 흐름이다.
• 플랫폼의 가치는 개발자가 인프라 팀과 직접 조율하지 않아도 로드밸런싱, 라우팅, 접근 제어, 로그, 보안 기능을 셀프서비스로 사용할 수 있게 만드는 데 있었다.
• 그러나 플랫폼이 커질수록 단순한 기능 추가보다 설정 검증, 권한 통제, 장애 대응, 문서화, 온보딩, 유지보수 가능한 구조 설계가 더 큰 과제가 됐다.
• 발표자는 기술 구현 능력뿐 아니라 갈등을 관리하고, 아이디어를 설득하고, 동료가 복잡한 시스템을 이해하도록 돕는 역량도 8년간의 중요한 성장 지점으로 정리한다.

📈 투자·시사 포인트

• 대규모 SaaS 기업에서는 개별 제품 기능만큼이나 내부 플랫폼, 셀프서비스 인프라, 중앙화된 트래픽 제어 계층이 생산성과 안정성에 큰 영향을 준다는 점을 보여준다.
• Envoy 같은 오픈소스 클라우드 네이티브 프록시와 동적 설정 기반 control plane은 비용 절감, 운영 표준화, 공통 보안 기능 확장 측면에서 전략적 가치가 크다.
• 중앙화 플랫폼은 인증, 인가, DDoS 보호, rate limiting, access logs 같은 공통 기능을 백엔드 서비스마다 반복 구현하지 않게 해 개발 비용과 지연 시간을 줄일 수 있다.
• 반대로 멀티테넌트 플랫폼이 커질수록 설정 자유도와 안전성 사이의 균형, 검증 로직, 권한 경계, 장애 대응 체계가 핵심 리스크가 된다.
• 투자 관점에서는 클라우드 인프라 자동화, 프록시·서비스 메시, 보안 게이트웨이, 관측성, 정책 검증 도구처럼 복잡한 플랫폼 운영을 단순화하는 영역의 수요가 계속 커질 가능성이 있다.
• 추가 검증 필요: 영상은 Atlassian 내부 경험을 개인 회고로 설명한 것이므로, 언급된 시스템의 현재 운영 상태, 비용 절감 규모, 조직 내 공식 평가, 정리해고의 구체적 배경은 별도 자료 없이는 단정하기 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• Atlassian 정리해고의 구체적 배경, 규모, 기준, 시점별 내부 의사결정은 영상의 회고 맥락에서는 언급되지만, 제공된 내용만으로는 단정할 수 없다.
• Sovereign이 오픈소스로 공개되었다는 설명은 나오지만, 현재 저장소 상태, 유지보수 여부, 실제 Atlassian 내부 사용 범위는 별도 확인이 필요하다.
• 약 2,000개 프록시와 13개 리전 규모가 제시되지만, 이 수치가 특정 시점의 운영 규모인지, 최대치인지, 전체 Atlassian 엣지 인프라 범위인지까지는 제공된 내용만으로 확정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Atlassian의 중앙화 로드밸런싱 구조를 참고해, 현재 조직 또는 프로젝트에서 로드밸런싱·라우팅·공개 접근 설정이 팀별로 중복 구현되고 있는지 점검한다.
• Envoy, Open Service Broker, FastAPI, SQS, DynamoDB, CloudFormation, Packer, SaltStack이 각각 어떤 역할을 맡았는지 아키텍처 다이어그램으로 재구성해 본다.
• 셀프서비스 인프라를 설계할 때 개발자 입력값을 어디에서 검증하고, 어떤 리소스 생성 로직을 통해 안전한 설정으로 변환할지 명확히 정의한다.
• 멀티테넌트 프록시 플랫폼에서 라우트가 임의의 클러스터로 트래픽을 보낼 수 없도록 권한·소유권·대상 검증 규칙을 설계한다.

❓ 열린 질문

• Atlassian 내부에서는 Envoy 기반 중앙화 로드밸런싱 전환 이후 실제 비용 절감, 장애 감소, 개발자 생산성 향상을 어떻게 측정했을까?
• Sovereign 같은 Envoy control plane을 직접 구현하는 방식과 상용 서비스 메시·API 게이트웨이·관리형 로드밸런서 사용 사이의 장단점은 무엇일까?
• 대규모 멀티테넌트 플랫폼에서 개발자에게 충분한 설정 자유도를 주면서도 위험한 라우팅이나 권한 우회를 막는 최적의 검증 모델은 무엇일까?