R.I.P. 내가 만든 시스템이 무지개 다리를 건넌 이야기 🪦🍂

안녕하세요, 카카오뱅크 뱅킹서버팀에서 수신 & 결제 서비스 개발을 담당하고 있는 Kenny입니다. 오늘은 저희가 직접 개발하고 운영했던 Oslo 프로젝트의 3년간의 여정과 그 과정에서 얻은 실무적 교훈을 공유하려고 합니다. 특히 Oslo 시스템의 설계와 운영, 그리고 서비스 종료까지의 실제 경험을 바탕으로, 새로운 시스템 도입을 고민하거나 운영 중인 분들께 도움이 될 만한 인사이트를 드리고 싶었습니다.

이 글을 통해 하나의 시스템을 만들고, 이를 유지보수하고, 때로는 정리하면서 비슷한 고민을 했을 수 있는 개발자 분들께 작은 길잡이가 되기를 바라며 시작해보겠습니다.

들어가며

한때 카카오뱅크에서 Best Practice로 불리며 카카오 기술 컨퍼런스 ‘if (kakao) 2021’에서 발표되었던 시스템이 있습니다. 카카오뱅크의 핵심 서비스 중 하나로 자리 잡을 것이라 믿었던 이 시스템은 단 3년 만에 서비스 종료되었습니다. 오늘 소개드릴 이 시스템의 이름은 ‘Oslo’입니다. 그럼 카카오뱅크는 왜, 그리고 어떻게 이 시스템을 과감히 EOS(End Of Service)할 수밖에 없었을까요?

Oslo는 단순한 기술적 실패가 아니었습니다. 오히려 당시로서는 최선의 선택이었고, 실제로 성공적인 결과도 만들어냈습니다. 그럼에도 불구하고 저희는 없애야 한다는 결단을 내렸습니다. EOS라는 결정을 하고 스스로도 많은 고민이 있었습니다. ‘한때 최선이라고 믿었던 기술 선택이 지금은 다른 결과를 가져오는 이유는 무엇일까요?’ 그리고, ‘기술적 의사결정의 옳고 그름은 시간이 흐르며 변할 수 있는 것일까요?’ 이 글은 바로 그 질문에 대한 답이 될 것이라고 생각합니다.

세 가지 관점으로 살펴보는 Oslo의 여정

이 글에서는 다음 세 가지 관점에서 Oslo 시스템의 도입부터 종료까지의 여정을 돌아보려 합니다.

1. 과거의 정답이 오늘의 정답은 아닐 수 있다.
   • 아무리 좋은 해결책도 모든 상황에 적용되는 은탄환(Silver Bullet)은 없습니다.
   • 시스템 아키텍처도 시간과 상황에 따라 최적의 형태가 달라질 수 있습니다.

2. 최적의 기술적 의사결정이란 무엇일까?
   • 기술적 결정은 언제나 조직의 리소스, 개발역량, 상황의 한계에 따라 달라집니다. • 절대적인 ‘옳은’ 결정보다는 ‘그 상황에서 최선의’ 결정이 중요합니다.

3. 시스템은 언제든 이전의 상태로 돌아갈 수 있어야 한다.
   • 기술은 유연하고 가역적이어야 합니다.
   • 변화는 언제든 올 수 있으며, 이전 상태로 돌아가거나 새로운 방향으로 전환할 수 있는 유연성이 필요합니다.

위의 관점들은 사실 누구나 알고는 있지만 쉽게 실천하기 어려운 이야기입니다. 하지만 저희는 Oslo의 사례를 통해 그 어려움을 직접 겪어보며 상황에 맞춰 선택한 결정과 과정에 대한 기록을 공유하고 싶었습니다. 이 글을 통해 ‘만약 나라면 이 상황에서 어떤 결정을 내렸을지’를 한 번 생각해보시면 읽어주시면 감사하겠습니다.

Phase 1. 서비스 도입

Oslo 시스템이 탄생하게 된 배경은 당시 카카오뱅크가 직면했던 중요한 문제에서 시작되었습니다. 2017년 7월 27일, 카카오뱅크는 공식 서비스를 시작하며 많은 고객들의 기대 속에 빠르게 성장했습니다. 그러나 3년이 지난 2020년 5월, 저희는 해결해야 할 큰 고민에 직면했습니다. 바로 급증한 고객 접속량을 감당하기 위해 백엔드 시스템의 장애 내성을 높이고, 장애 전파를 해결하는 문제였습니다.

2020년 초, 카카오뱅크 모바일 앱 첫 화면은 계정계 시스템과 강하게 결합되어 있었습니다. 사용자가 앱을 열면 가장 먼저 계정계에서 계좌 정보를 가져와 첫 화면을 구성했습니다. 그렇다보니, 계정계 시스템의 장애는 서비스 전반에 치명적인 영향을 줄 수 있는 중요한 문제였습니다. 장애가 발생하면, 카카오뱅크 앱에 접속했을 때 마주하는 첫 관문인 ‘로그인’과 ‘전체 계좌 목록 불러오기’ 기능이 멈춰버릴 수 있기 때문입니다.

💡 계정계 시스템이란?

• 은행의 필수 비즈니스를 처리하는 시스템입니다
• 계좌를 만들고, 돈을 보관하고 찾고, 대출을 받고, 이자를 내는 등 ‘은행’하면 떠오르는 핵심 업무를 처리합니다.

문제는 이것만이 아니었습니다. 계정계 시스템과는 무관한 ‘도메인 로직’이나 ‘데이터베이스’에 문제가 발생하면 장애가 전체 시스템으로 확산될 가능성도 있었습니다. 이는 모든 도메인이 하나의 시스템에 구현된 모놀리식 아키텍처(Monolithic Architecture)의 전형적인 문제였습니다. 이러한 장애의 위험은 더 이상 방치할 수 없었습니다.

이런 상황은 당연히 사용자 경험에 매우 부정적인 영향을 미치게 됩니다. 간단한 정보 확인을 위해 앱을 열었는데 아예 접속이 안 된다면 사용자들은 당연히 불편함을 느낍니다. 이는 더 나아가 비즈니스 관점에서도 문제였습니다. 첫 화면에 접속할 수 없다는 것은 카카오뱅크의 모든 서비스 진입점이 차단된다는 의미가 되므로, 꼭 해결해야 되는 문제였습니다.

해결 방안 모색

이 문제를 해결하기 위해 기술조직에서는 심도 깊은 논의를 거쳤고, 두 가지 해결 방향을 도출했습니다.

저희는 오랜 고민 끝에 두 번째 방법인 ‘완전 독립 방식’을 선택했고, 그것이 바로 Oslo 시스템의 도입이었습니다.

💡 왜 시스템 이름이 Oslo인가?

• 카카오뱅크의 채널서버 시스템들은 각각 코드네임(프로젝트명)을 가지고 있습니다.
• 처음에는 ‘Sumatra’, ‘Kreta’처럼 섬 이름으로 서버의 코드네임을 지었습니다. 🏝️
• 하지만 Oslo는 채널서버 시스템이지만 계정계에서 분리되어 구성된 차별점을 가지고 있어서 다르게 작명하고 싶었고,
• 이에 수도/도시 시리즈 중 노벨 평화상의 수상지인 노르웨이의 수도 ‘Oslo’로 명명하게 되었습니다.

Oslo 시스템의 탄생

Oslo는 계정계 시스템의 일부 도메인을 분리(정확히는 이중화)하여 ‘전체 계좌 목록 불러오기’ 기능을 독립적으로 운영할 수 있도록 하는 시스템입니다. 따라서 계정계 시스템의 장애가 발생하더라도, 전체 계좌 목록 불러오기 기능의 안정성을 높이는 것이 Oslo의 궁극적인 목표였습니다. 즉, 카카오뱅크 앱을 켰을 때 보이는 첫 화면은 계정계 시스템의 상황과 별도로 항상 안정적으로 보일 수 있도록 해주는 ‘방패막🛡️’을 만든 것이었습니다.

Oslo의 핵심 아이디어는 간단했습니다. 카카오뱅크 첫 화면에 보여줄 필요한 최소한의 정보만 미리 준비해두고, 계정계에 장애가 생겨도 앱 접속은 가능하도록 하자는 것이었습니다.

구체적으로는 다음과 같은 방식으로 동작했습니다:

• • 계정계에서 Near Real Time으로 계좌 정보와 잔액을 Oslo로 복제
• • 사용자가 앱을 열면 Oslo에서 데이터를 조회해 첫 화면 구성
• • 계정계에 장애가 발생해도 Oslo는 독립적으로 동작

이렇게 하면 계정계 장애 시에도 사용자는 앱에 접속할 수 있고, 기본적인 정보 확인은 가능한 상태가 됩니다.

최초 프로젝트 시작 당시, 1단계, 2단계, 3단계의 마일스톤(Milestone)이 존재했습니다. [그림 2]의 ‘Milestone 1’과 ‘Milestone 2’는 각각 1단계와 2단계에 해당하는 Oslo 시스템의 아키텍처 구성도입니다.

• • Milestone 1 (1단계): 계정계 시스템을 대상으로 Read Only API를 제공
• • Milestone 2 (2단계): 계정계 외 시스템(펀드, 마이데이터 등)을 대상으로 Read Only API를 제공

Oslo 시스템의 성과

Oslo는 서비스 오픈 이후, 다음과 같은 가시적인 성과를 달성했습니다. (2021.02.09 기준)

✔️ 계정계 시스템 트래픽 대폭 감소를 통한 안정성 확보

• • 계정계 시스템이 받던 전체 트래픽의 10.22%에 달하는 17,278,416건의 트래픽이 Oslo로 전환되었습니다.

✔️ 서버처리시간 감소

• • 동일한 기능을 하는 계정계 시스템 API의 처리시간은 400ms였지만, Oslo는 70ms로 기존의 약 18% 수준으로 속도가 개선되었습니다.

✔️ 불필요한 코드 제거를 통한 코드 가독성 확보

• • 트랜잭션 스크립트 패턴으로 구성되어 있던 코드를 도메인 모델 패턴(역할/책임/협력 관점의 객체지향설계 방식) 구조로 변경했습니다.
• • 이 과정에서 전체 계좌 목록 불러오기 기능과 관련 없는 기존 레거시 코드들은 모두 삭제했습니다.

여기까지가 if (kakao) 2021에서 공유한 <Oslo 시스템의 탄생과 성과>를 담은 내용의 요약입니다. 그렇다면 성공적인 오픈과 그로 인한 시스템 개선으로 인해 Oslo 시스템은 이후에도 순탄한 길만이 기다리고 있었을까요? 안타깝게도 그렇지 않았습니다. 오히려 이 시점부터 새로운 문제들이 나타나기 시작했습니다.

Phase 2. 서비스 운영

2021년 11월, Oslo는 본격적인 운영 단계에 들어갔습니다. 그 당시 카카오뱅크의 모바일 앱은 매달 새로운 상품과 서비스를 출시하기 위해 1개월 주기로 릴리즈가 이루어지고 있었습니다. 이에 발맞춰 Oslo가 담당하던 ‘전체 계좌 목록 불러오기’ 기능은 릴리즈 주기에 맞춰 신규 기능 개발, 계정계 시스템과의 데이터 정합성 확인, 운영 모니터링 등 다양한 작업을 수행해야 했습니다.

초기 Oslo 시스템의 운영은 비교적 안정적이었습니다. Oslo는 복잡한 비즈니스 로직보다는 데이터 복제와 조회에 초점을 맞췄기 때문에, 초기 운영 부담은 크지 않았습니다. 새로운 기능에 대한 대응도 크게 부담스럽지 않았고, 다른 업무와 병행하면서도 충분히 관리할 수 있는 수준이었습니다.

하지만 Oslo 시스템에는 심각한 문제가 하나 있었습니다. 바로 Bus Factor of 1 문제였습니다.

💡 Bus Factor of 1

• Bus Factor란 “특정 인원이 버스에 치이거나 복권에 당첨되어 갑자기 팀을 떠났을 때,
• 프로젝트가 중단될 위험성”을 나타내는 지표입니다.
• 즉, 프로젝트의 핵심 지식이나 역할이 특정 한 사람에게만 집중되어 있는 상황을 의미합니다.
• 이 당시 Oslo는 시스템의 높은 이해도를 가진 1명이 개발을 했기에 의사결정과 커뮤니케이션 비용을 0으로 줄일 수 있었지만,
• 이 점이 결국 지속적으로 시스템을 운영해 나갈 수 있는 가능성을 0으로 만들었습니다.
• Bus Factor가 1이면 빠르게 개발은 할 수 있어도 장기적인 유지보수는 불가능하니 반드시 피해야 합니다.

그 당시 Oslo의 초기 설계부터 운영까지 대부분의 과정을 1명이 전담하고 있었으며, 초기에는 시스템에 대한 깊은 이해와 경험을 바탕으로 안정적인 운영이 가능했습니다. 물론 개발 과정에서 동료들의 리뷰와 피드백이 있었지만, 시스템의 핵심 구조와 운영 노하우는 1명에게 집중되어 있었습니다. 이런 중요한 정보들이 한 사람에게만 집중되어 있다는 것은 분명히 위험한 상황이었습니다.

• • 시스템 아키텍처에 대한 이해
• • 데이터 동기화 로직의 세부사항
• • 장애 대응 매뉴얼과 경험
• • 성능 최적화 포인트들

사실 많은 개발팀에서 이런 상황은 어느 정도 불가피한 측면이 있습니다. 프로젝트 초기에는 빠른 개발과 출시가 우선이고, 지식 공유나 문서화는 상대적으로 후순위가 되기 쉽습니다. 하지만 이런 상황이 계속되면, 나중에 큰 문제가 될 수 있습니다.

1️⃣ 경험과 직관의 전수 어려움

2022년 2월, 카카오뱅크에서는 대규모 조직 개편이 이루어졌습니다. 이로 인해 여러 시스템들의 오너십(Ownership)과 담당자 역할(R&R)이 조정되었고, Oslo도 그 대상이 되었습니다. 당시 저희는 Oslo 시스템을 다른 조직과 새로운 담당자에게 인계해야 했습니다.

이 과정에서 여러 어려움이 발생했습니다. 본인이 만든 시스템이 아닌 상태에서 계정계의 변화를 그대로 따라가는 Oslo 시스템을 유지보수하고 운영하는 방법을 완벽하게 인수인계하는 것은 쉽지 않았습니다. 수차례의 대면 인수인계와 상세한 문서화에도 불구하고, 실제 업무에서의 맥락과 경험을 전달하기에는 부족할 수밖에 없었습니다.

문서로 전달할 수 있는 것과 실제 운영에서 필요한 감각은 다릅니다. 예를 들어:

• • “이 부분에서 성능 이슈가 생길 가능성이 높다”
• • “이런 패턴의 에러가 나타나면 보통 이게 원인이다”
• • “데이터 동기화가 지연될 때 이렇게 대응하는 것이 효과적이다”

이런 종류의 노하우는 문서만으로는 전달하기 어렵습니다.

2️⃣ 반복되는 인수인계 비용

2023년에는 또 한 번의 조직 개편이 있었습니다. 기존의 ‘기능 중심’ 조직에서 ‘목적 중심’ 조직으로의 큰 전환이 이루어졌고, Oslo의 담당자도 다시 변경되었습니다. 이로 인해 다시 한번 인수인계 과정이 필요했고, 신규 기능 개발과 운영을 위해 추가적인 인력이 투입되었습니다.

2년 연속으로 담당자가 바뀌면서, 인수인계에 들어가는 비용도 계속 누적되었습니다. 이는 단순히 시간적 비용뿐만 아니라, 시스템에 대한 이해도 저하와 운영 효율성 감소로도 이어졌습니다.

3️⃣ 운영 비용 증가와 우선순위 문제

운영 비용 증가만이 문제가 아니었습니다. Oslo를 인수받은 개발자들의 개발자 경험과 업무 만족도 또한 하락하기 시작했습니다. 무엇보다 Oslo는 카카오뱅크의 메인 화면에 노출되는 중요한 기능을 담당하고 있었기에 시스템의 민감도가 높았지만, 그 중요성에 비해 Oslo를 지속적으로 운영해야 하는 당위성이나 우선순위에 대해 충분한 공감대를 형성하기 어려웠습니다.

자신이 만들지 않은 시스템을 운영한다는 것은 분명히 부담스러운 일입니다. 특히 그 시스템이 중요한 기능을 담당하고 있다면 더욱 그렇죠. Oslo를 인수받은 개발자들 입장에서는 아래와 같은 상황들이 누적되면서 개발자 경험이 저하될 수밖에 없었습니다.

• • 시스템의 전체적인 맥락을 이해하기 어려움
• • 장애 발생 시 빠른 대응에 대한 부담
• • 새로운 요구사항에 대한 대응 어려움

또한, 이러한 변화로 인해 Oslo 시스템의 운영비용은 점차 선형적으로 증가하고 있었습니다.

• • 반복적인 인수인계 비용
• • 시스템 이해도 부족으로 인한 개발 효율성 저하
• • 장애 대응 시간 증가
• • 새로운 기능 개발에 필요한 추가 학습 시간

여러 요인들이 복합적으로 작용하면서, Oslo 시스템을 유지하는데 드는 비용이 점점 증가했습니다.

Phase 3. EOS(End of Service) 결정과 교훈

Oslo 운영 비용의 증가는 지속되었습니다. 이제는 더 이상 이 상황을 방치할 수 없었고, 결단을 내려야 할 시점이 되었습니다.

운영 비용 증가와 개발자 경험 약화 문제는 더 이상 미룰 수 없는 수준에 이르렀고, 변화된 상황 속에서 Oslo 시스템의 존재 이유는 사라졌습니다. 결국 가장 합리적인 선택은 EOS(End of Service)였습니다.

상황 재평가 및 현황 분석

Oslo 시스템 도입 당시처럼 문제를 해결하기 위해 다시 한번 조직과 계정계 시스템의 상황을 정확히 파악하고 실질적인 해결 방안을 고민해야 했습니다. 그 과정에서 저희는 도입 준비 당시 대비해 몇 가지 긍정적인 변화를 발견할 수 있었습니다.

1. 백엔드 시스템 안정성 확보

• • Oslo 도입 당시 가장 큰 문제였던 백엔드 시스템의 안정성이 이미 확보되어 있었습니다. 유사한 장애는 1~2년간 발생하지 않았고, 시스템은 충분히 안정된 상태였습니다.
• • 그동안 계정계 시스템은 트래픽 증가에 대응하기 위해 지속적으로 스케일아웃(Scale-out) 되었고, 장애 전파를 방지하기 위한 도메인 단위의 인스턴스 분리도 이루어졌습니다.

2. 원본 시스템 병행 유지

• • Oslo는 이관(Migration)된 시스템이었고, 원본 시스템인 계정계 시스템은 여전히 존재했습니다.
• • 전체 계좌 목록 불러오기는 Oslo와 계정계 시스템에서 동일한 기능을 제공하는 API가 병행하여 제공되고 있었습니다.
• • 따라서 지금이라도 바로 계정계 API로 회귀할 수 있는 상태였습니다.

과감한 선택: Oslo EOS 결정

이러한 상황을 바탕으로 저희는 조금은 급진적인 선택지를 검토하게 되었습니다. 바로 Oslo를 종료하고, 과거의 계정계 시스템만 존재했던 구조로 되돌아가는 것이었습니다. 당시 저희가 고민했던 핵심 질문은 다음과 같았습니다.

결론과 판단 근거

검토 결과, 다음과 같은 결론에 도달했습니다.

• • 현재의 계정계 시스템은 Oslo 도입 전보다 더 안정적이며 트래픽 처리 능력도 충분히 갖추고 있었습니다.
• • 과거와 같은 장애가 다시 발생할 가능성은 낮아졌고, 만약 발생하더라도 영향 범위는 제한적일 것으로 예상되었습니다.
• • 또한, Oslo 서비스 중단 작업은 클라이언트 시스템의 피처 토글(Feature Toggle)을 통해 비교적 간단히 수행할 수 있었습니다.

이러한 판단을 바탕으로, 우리는 Oslo 시스템을 종료하기로 최종 결정했습니다.

서비스 종료 실행

2024년 4월 6일, 클라이언트 시스템에서 Oslo를 호출하지 않도록 피처 토글을 비활성화했습니다. 그 순간, Oslo의 TPS는 0이 되었습니다. 3년 동안 운영되어 온 Oslo 시스템은 이렇게 조용히, 그러나 의미 있는 방식으로 역할을 마감했습니다. 그 순간은 단순한 기능 종료가 아니라, 조직이 지속적인 개선과 변화를 통해 더 나은 방향으로 나아가고 있다는 것을 보여주는 중요한 이정표였습니다. 그렇게 Oslo는 카카오뱅크의 시스템이 걸어온 역사의 일부가 되었습니다.

에필로그: “기술적 선택에 정답은 없다.”

그렇게 2024년 4월 6일부로 Oslo 시스템은 더 이상 카카오뱅크의 시스템 안에 존재하지 않게 되었습니다. 저희는 2021년 9월 30일 이전, Oslo가 도입되기 전의 구성으로 되돌아갔습니다. 약 4년 동안 쌓아왔던 개발, 성능 테스트, 데이터 정합성 검증, 운영 그리고 EOS까지의 모든 노력은 그 날을 기점으로 하나의 사이클을 마무리했습니다.

Oslo 시스템은 종료되었지만, 저희는 이 프로젝트를 통해 많은 것을 배울 수 있었습니다. 기술적 선택에는 정답이 없으며, 상황에 따라 최선의 선택은 달라질 수 있다는 것을 깨달았습니다. 중요한 것은 그 과정에서 얻은 경험과 교훈을 바탕으로 더 나은 시스템을 만들어가는 것이라는 생각이 들었습니다.

과거로의 퇴보인가, 합리적 진화인가

여기서 한 가지 의문이 생깁니다.

저희는 과연 과거로 퇴보한 것일까요? 그동안의 노력은 무의미했던 것일까요? 4년 전의 의사결정이 잘못되었던 것일까요?

결론부터 얘기하면, 저희는 그렇다고 생각하지 않습니다. 올바른 기술적 의사결정에 절대적인 정답은 없습니다. 각자의 상황이 다르고, 해결하고자 하는 문제가 다양할 수 있기에 여기에는 보편적인 진리가 존재하지 않습니다. 많은 사람들이 정답이라고 말하는 방법도 저희에게는 정답이 아닐 수 있습니다. 저희가 하는 기술적 선택은 언제나 당시 상황, 주어진 리소스, 조직의 한계에 따라 달라질 수 있습니다.

만약 Oslo가 조직 개편의 영향에서 자유로웠거나 초기 계획대로 지속적인 고도화가 이루어졌다면, 마일스톤1에서 2,3으로 시스템이 진화하는 방향성을 지지해 줄 컨센서스가 유지됐다면, Oslo는 지금도 카카오뱅크의 중요한 시스템 중 하나로 남아 있을 수도 있었습니다. 하지만 현실은 그렇지 못했습니다. 그리고 지금의 옳아 보이는 이 결정도, 어쩌면 언젠가는 잘못된 의사결정으로 평가될 수도 있습니다. 하지만 이것이 지극히 정상적인 흐름인 것입니다.

유연함과 가역성의 중요성

이에 우리는 어떤 한 가지 해결책과 방법을 맹신하면 안 됩니다. 우리가 만드는 시스템은 언제나 적은 비용으로 과거의 상태로 돌아갈 수 있도록 ‘유연’하고 ‘가역적’이어야 합니다. 그리고 우리의 기술적 의사결정에는 왜 우리가 이러한 결정을 하게 되었는지, 기술적인 측면과 함께 우리와 조직이 마주한 한계(Limit)를 반드시 기술해야 합니다.

예를 들어, ADRs(Architecture Decision Records)은 이러한 맥락을 기록하는 좋은 방법일 수 있습니다.

새로운 시스템 도입 전 고려사항

Oslo 프로젝트를 통해 얻은 교훈을 바탕으로, 새로운 시스템을 도입하기 전에 반드시 고려해야 할 사항들을 정리해보았습니다.

Bus Factor를 최소화하기 위한 전략으로는 다음과 같은 방법들이 있습니다. 먼저 지식 공유 문화를 구축하는 것이 중요합니다. 이를 위해 정기적인 지식 공유 세션을 마련하고, 페어 프로그래밍이나 코드 리뷰를 통해 지식을 분산시키며, 상세한 문서화를 지속적으로 업데이트해야 합니다. 또한 다중 담당자 체계를 도입하여 처음부터 2명 이상이 시스템을 이해할 수 있도록 설계하고, 순환 근무나 백업 담당자를 지정하며, 신규 구성원 온보딩 프로세스를 구축해야 합니다.

또한, 조직 변화에 대비하기 위해서는 시스템의 독립성을 확보하는 것이 필요합니다. 특정 조직이나 팀에 과도하게 의존하지 않는 구조를 만들고, 명확한 인터페이스와 의존성을 관리하며, 조직 변화 시 인수인계 가능한 수준의 문서화를 준비해야 합니다. 또한 장기적 로드맵을 수립하여 조직 변화를 고려한 3-5년 단위의 계획을 세우고, 시스템의 진화 방향과 우선순위를 명확히 하며, 조직의 지속적인 컨센서스를 확보해야 합니다.

기술적 의사결정의 지속가능성을 위해서는 비용-효과 분석을 철저히 해야 합니다. 초기 개발 비용뿐만 아니라 장기 운영 비용을 고려하고, 대안 솔루션과의 비교 분석을 통해 정기적인 효과성 검토 프로세스를 마련해야 합니다. 또한 단순함의 가치를 중시하여 복잡한 솔루션보다는 단순하고 이해하기 쉬운 구조를 선택하고, 과도한 추상화나 일반화를 지양하며, 필요에 따른 점진적 발전 전략을 채택해야 합니다.

마지막으로 팀과 조직의 역량을 고려하기 위해 현재 역량 수준을 파악해야 합니다. 팀의 기술적 역량과 경험 수준을 평가하고, 새로운 시스템 운영에 필요한 스킬셋을 분석하며, 교육이나 역량 개발 계획을 수립해야 합니다. 또한 지속가능한 운영 체계를 구축하여 일상적인 운영 업무의 부담 수준을 예측하고, 장애 대응 프로세스와 역량을 확보하며, 지속적인 개선과 발전을 위한 여유를 마련해야 합니다.

마무리하며

Oslo 시스템의 3년간의 여정을 돌아보면, 기술적으로는 분명히 성공적인 프로젝트였습니다. 설계 목표였던 장애 격리는 실제로 달성했고, 사용자 경험도 개선시켰습니다. 하지만 동시에 Bus Factor of 1 문제, 조직 변화, 장기적인 운영 비용 증가 등의 문제도 명확하게 드러났습니다. 이런 문제들은 기술적인 우수성만으로는 해결할 수 없는 것들이었습니다.

정답이 있는 문제는 간단합니다. 그저 그 정답만 기억하면 되기 때문입니다. 하지만 소프트웨어 엔지니어링 분야에서 ‘개발자’라는 이름으로 살아가는 우리들에게는 절대적인 정답이 존재하지 않습니다. 시간과 상황, 맥락에 따라 변화하는 ‘정답에 가장 가까운 그 무언가’만이 있을 뿐입니다.

Oslo 시스템의 여정은 저희에게 기술적 결정의 유한성과 가역성의 중요성을 일깨워주었습니다. 한때는 최선이었던 선택이 시간이 흐름에 따라 재고되어야 하는 순간이 온다는 것, 그리고 그러한 변화를 수용할 수 있는 시스템의 유연성이 얼마나 중요한지를 몸소 경험했습니다.

결국 기술은 비즈니스 목표를 달성하기 위한 도구입니다. 아무리 뛰어난 기술이라도 조직의 상황이나 비즈니스 환경에 맞지 않으면 지속하기 어렵습니다. Oslo의 경우도 초기 목표는 달성했지만, 변화된 환경에서는 더 이상 최적의 솔루션이 아니었던 것이라고 생각합니다.

개발자로서 앞으로도 우리는 계속해서 새로운 시스템을 만들고, 운영하고, 때로는 정리해야 할 것입니다. 그 과정에서 Oslo의 경험이 조금이라도 도움이 되기를 바라며 글을 마치겠습니다. 감사합니다.