플랫폼은 왜 계속 다시 설계되어야 할까 - Server Platform Team 이야기

라포랩스 Server Platform Team은 제품 조직이 더 빠르게 실험하고 안정적으로 운영될 수 있도록, 엔지니어링 환경과 플랫폼을 설계하는 팀입니다.

플랫폼은 한 번 구축했다고 끝나지 않습니다. 조직 구조와 제품의 성장 속도, 기술 환경의 변화에 맞춰 끊임없이 다시 설계되고 진화해야 하니까요. 그래서 Server Platform Team은 서비스 안정성과 개발 생산성은 물론, AI 시대에 맞는 새로운 개발 경험과 운영 방식까지 함께 고민하고 있습니다.

이번 인터뷰에서는 라포랩스 Server Platform Team이 어떤 엔지니어링 철학을 가지고 플랫폼을 설계하는지, 그리고 지금 어떤 문제들을 풀어나가고 있는지 함께 이야기했습니다.

Q1. 간단히 자기소개 부탁드려요.

강산

안녕하세요, Server Platform Team 의 장강산입니다. 라포랩스에 합류한 지 곧 5년이 되어가요. 이전에는 전기차 관련 보안 스타트업에서 일을 했고, 이후 커리어의 대부분을 라포랩스에서 보내고 있습니다. 처음에는 스쿼드의 백엔드 엔지니어로 시작해서, 지금은 서버 플랫폼 팀에서 일하게 되었어요. Engineer 라는 유저를 위한 제품을 만드는 일이라, 오너십을 발휘할 수 있는 영역이 넓다는 점에서 이 일에 매력을 느끼고 있어요.

찬희

안녕하세요, Server Platform Engineer 이찬희입니다. 라포랩스에 합류한 지 약 2년이 되었어요. 이전에는 주로 금융 / 핀테크 도메인에서 체크카드 서비스와 투자 플랫폼 백엔드를 개발했고, 라포랩스에서는 비동기 메시징과 캐싱처럼 모든 서비스가 공통으로 쓰는 영역을 주로 맡고 있습니다. Engineer 들이 겪던 공통된 문제를 풀었을 때, 크게 기뻐하고 속 시원해하는 모습을 가까이서 볼 수 있는 점이 좋아요.

성준

안녕하세요, Server Platform Engineer 하성준입니다. 합류한 지 약 1년이 되었어요. 이전에는 토스뱅크에서 DevOps 엔지니어로 일했고, 이후 스타트업 초기 멤버로 개발부터 유저 인터뷰, 제품 기획까지 폭넓게 경험했습니다. 라포랩스에서는 시스템의 안정성과 가시성을 높이는 SRE 업무를 주로 하고 있어요. 아무리 좋은 피처가 있어도 앱이 자주 멈추거나 느리면 유저가 떠나잖아요. 신뢰성으로 고객 경험에 기여하는 역할이라는 점에서 이 일에 매력을 느낍니다.

Q2. Server Platform Team 은 어떤 일을 하는 팀인가요?

성준

저희 팀은 서비스 안정성과 가시성을 책임지고 있습니다. 수백만 명의 사용자가 매일 끊김 없이 서비스를 이용할 수 있도록, 복잡한 분산 환경에서 모니터링과 추적 시스템을 설계해요. 장애가 나면 빠르게 인지·대응하고, 같은 장애가 재발하지 않도록 포스트모템 문화를 정착시키고 있어요. 또 마케팅 이벤트로 트래픽이 몰릴 때를 대비한 자동 서버 증설, 비정상 Latency 분석, Profiling 기반 리소스 최적화도 함께 맡고 있습니다.

강산

팀의 또 다른 핵심 역할은 사내 개발자들의 개발 생산성과 경험(DX)을 향상시키는 일이에요. 각 스쿼드에서 발생하는 페인포인트를 발굴해 개선하고, 여러 팀에서 중복으로 구현하는 기능들을 공통 라이브러리와 내부 도구로 만들고 관리하고 있어요. 각 제품 팀 내 조직들이 비즈니스 로직에 더 집중할 수 있도록, 도구와 라이브러리를 제공하는 역할이라고 생각하시면 돼요. 그러다 보니 제품팀이 일하는 방식과 팀에서 제공하는 플랫폼이 서로 영향을 주고받게 되더라고요. 한 번 만들면 끝나는 게 아니라, 시간이 지나고 조직이 변하면서 갈아엎고 다시 만드는 일도 적지 않고요.

Q3. 제품팀이 일하는 방식에 영향을 준다고 하셨는데, 구체적으로 서로 어떤 영향을 주고받는 건가요?

강산

라포랩스 제품팀은 빠르게 가설을 세우고 실험하며 제품을 만들어가고 있어요. 그래서 기능이 출시된 직후, 데이터를 보고 방향이 바뀌는 경우도 많아요. 플랫폼팀은 이러한 제품 조직의 빠른 실행 속도를 뒷받침하는 역할이라, 제품팀이 매일 어떻게 일하는지를 가까이서 관찰하는 게 중요하더라고요. 처음 플랫폼을 만들때 했던 가정이나 요구사항들이 현재 조직이 커지고, 환경이 바뀌는 상황에서도 유효한지 알아채는게 중요한 것 같아요.

생각나는 건, 배포 파이프라인의 변화가 그런 식으로 진행돼 왔어요. 기존에 조직이 작았을 때는 플랫폼팀이 주 2~3회 정도 정기 배포를 수행하고 있었어요. 하지만 조직이 커지면서 스쿼드 단위로 세분화되고, monolith 에서 마이크로서비스로 전환되면서 관리해야 할 서버가 빠르게 늘어났습니다. 더 이상 중앙화된 배포 방식으로는 생산성이 너무 떨어졌었죠. 새로운 배포 방식은 엔지니어 누구나 자율적이면서도 더 빠르고 안정적인 배포가 가능하도록 설계해야 했어요. 그래서 ArgoCD 기반의 CI/CD 배포 파이프라인을 구축했습니다. 그 결과 하루에도 2~30번씩 배포가 일어나게 됐어요.

배포의 속도가 빨라지면서 새로운 문제가 등장했는데, 자율적으로 배포하는 분들이 늘어나면서, 배포 시점에 크고 작은 장애들이 자주 발생했거든요. 그래서 다음으로는 누가 / 언제 / 어떤 PR 형상으로 배포했는지를 Grafana 대시보드와 Slack 에서 바로 확인할 수 있도록 만들었어요. 지금은 DevOps 팀과 함께 ArgoCD UI 에 배포된 서비스의 Grafana 대시보드와 Canary 배포 제어 화면을 함께 띄워둬서, 모니터링과 traffic 제어를 자연스럽게 유도하고, 배포로 인한 사고를 최소화할 수 있도록 다듬어가고 있어요.

찬희

그래서 우리가 만든 도구는 단순히 기능을 넘어 제품팀이 일하는 방식 자체를 변화시키고 있어요. 바뀐 방식 위에서 또 새로운 문제가 보이면 그걸 다시 고쳐가는 사이클이 계속 이어지는 식이에요. 한 번 만들고 끝나는 게 아니라 같이 진화하는 흐름이거든요.

다른 사례로는, 어드민 권한 시스템을 개선했던 작업이 생각나요. 초기에는 각 백엔드 엔지니어가 새로운 어드민 API 를 만들 때마다, 어떤 사용자가 이 API 를 호출해도 되는지를 엔드포인트별 allowlist 에 한 명 한 명 직접 추가해야 했어요. 새 기능이 나올 때마다 이 작업을 반복했고요. 조직이 작을 때는 견딜만했지만, 권한과 기능이 늘면서 Keycloak 인증 토큰 페이로드가 감당이 안 되는 시점까지 왔어요. 저희는 이 문제를 기술적으로만 해결하기보다, 보안팀과의 협업을 통해 근본적인 정책적 개선을 병행했어요. 정산금을 다루는 크리티컬한 액션이나 고객의 개인정보를 다루는 액션들을 식별하여 별도로 분리하고 나머지는 간소화하는 방향으로 바꿔서, 백엔드 엔지니어가 어드민 API 마다 사용자별 allow list 를 손으로 채우는 일을 줄였고, 토큰 크기 문제를 자연스럽게 풀어냈습니다.

Q4. 그렇다면 세 분이 각자 요즘 가장 몰입하고 있는 일은 무엇인가요?

찬희

저는 서비스간 이벤트를 전달하는 구조를 다시 짜고 있어요. 지금의 구조는 특정 도구(Debezium)에 강하게 의존하고 있어서, 그 부분이 흔들리면 여러 서비스가 한꺼번에 영향을 받는, 사실상 단일 장애점(SPOF) 구조였거든요. 그 리스크를 없애고 더 유연하고 가벼운 구조로 전환하는 작업이에요.

거기에 더해 각 제품 서비스마다 개별적으로 구현하던 메시지 재처리, 메시징 시스템 로깅/모니터링 로직을 플랫폼 단의 표준 파이프라인으로 옮기고 있습니다. 이런 공통 관심사를 표준 기술로 정리하면 각 스쿼드에서 매번 똑같은 코드를 다시 짜지 않아도 되거든요. 시스템은 더 안전해지고, 개발 속도는 더 빨라지는 흐름을 제 손으로 만들고 있다는 점이 재미있어요.

강산

저는 우리 팀이 제공하는 라이브러리와 도구들을 AI 친화적으로 만드는 일에 집중하고 있어요. 이걸 고민하다 보니 백로그로만 쌓여 있던 레거시 청산과 파편화된 개발 패턴들을 표준화하는 작업들의 가치가 높아졌다는 생각이 들었어요. Agentic 코딩을 하지 않던 시절에는 개발자의 인지부하를 줄이는 정도였지만, 이제는 Agent 가 더 잘 수행할 수 있는 환경을 만들 수 있다는 가치가 더해져 더 임팩트가 커졌다고 생각했습니다.

마찬가지로 E2E 테스트를 위해 Platform 팀이 제공했던 개발 환경 테스트 도구들도, 이제 사람이 아니라 에이전트가 사용한다는 관점으로 다시 보니까 고칠 만한 부분이 많이 보이더라고요. 도구들의 사용 방법과 입출력 방법을 Agent 가 더 쉽게 이해할 수 있는 방향으로 바꾸고 있어요. AI 가 점점 더 똑똑해져서 지금 만들고 있는 이것도 1년 뒤에 또 빼야 할지도 모르지만요. 하하

성준

저는 최근에 Spring Application의 초기 부팅 시간을 줄이는 작업에 시간을 쓰고 있어요. 부팅 시간이라는 게 사소해 보일 수 있지만, 실제로는 운영 안정성과 사용자 경험에도 직결됩니다. 트래픽이 몰려 서버가 자동으로 확장(HPA)될 때 부팅이 느리면 사용자 응답이 지연되고, Karpenter가 노드를 정리하거나, 스팟 인스턴스가 교체될 때 서비스 가용성도 떨어지거든요. 그래서 이 부분을 한 번 제대로 파헤쳐보고 싶었습니다.

원인을 찾기 위해 부팅 과정의 병목이 될 만한 부분들을 하나씩 모두 뜯어봤어요. 초기화 중간의 외부 API 호출, Java Agent의 Class 조작, JPA 초기화처럼 익숙한 영역을 차례로 다시 정리했는데, 양파 껍질을 까듯 한 단계를 풀면 또 다른 병목이 튀어나오는 식이라 예상보다 긴 릴레이였죠. 그 과정에서 저희가 쓰는 Spring Data Commons 오픈소스 자체의 버그를 발견해 기여하는 뜻깊은 경험도 있었습니다. 결과적으로 부팅 시간이 절반 이상 줄었는데, 그 수치 자체보다도 우리가 매일 일상적으로 다루던 기술의 속을 한 겹 더 깊게 이해하게 되었다는 점이 가장 기억에 남습니다.

이 과정의 디테일이 더 궁금하시다면?
👉 아티클 보러가기 : Spring Boot Startup Time 최적화

Q5. 일을 하시면서 기억에 남는 일이나 어려웠던 순간이 있다면 들려주실 수 있을까요?

강산

저는 팀에 상대적으로 오래 있었다 보니, 우리가 설계했던 여러 구현들이 시간이 지나면서 처음 가정과 어긋나는 모습을 많이 볼 수 있었어요. 처음 만들 때는 분명 합리적인 가정이 있었는데, 대비했던 시나리오가 실제 발생하지 않거나, 1년만 지나도 use case 가 바뀌는 경우도 많더라고요. 결국 만들어 둔 것을 지우거나 통째로 갈아엎는 작업도 적지 않게 했었어요. 그런 과정들을 보게 된 순간이 가장 기억에 남는 일이에요.

마이크로서비스 분리를 유행처럼 따라가던 시절에는 조직 사이즈를 못 따라가서 우후죽순 비효율을 만든 적도 있었고요. 그 시간이 가르쳐준 한 가지는, ‘100% 이상적인 시스템은 없다’ 였습니다. 좋은 플랫폼은 책에서 그대로 가져올 수 있는 게 아니라, 회사 규모·팀 구조·제품 이터레이션이 어떻게 굴러가는지를 면밀히 관찰한 결과로만 나올 수 있다고 생각하는 계기가 되었어요.

찬희

저는 올해 4월에 있었던 사고가 가장 어려웠던 순간으로 남아요. AI 를 활용해 사용하지 않는 인프라 자원을 삭제하는 작업을 진행했는데, 그 과정에서 의도하지 않은 핵심 리소스까지 함께 삭제되면서 전사적인 큰 장애가 났습니다. 복구에도 시간이 꽤 걸렸어요.

사실, 사고 그 자체보다 사후 진행했던 포스트모템 회의가 더 기억에 남아요. AI 로 빠르게 문서를 만들 수 있다는 이유로, 기존 양식을 맞추기 위해 핵심이 없는 글을 빠르게 만들어내고 회의를 진행해 보니 이 포스트모템의 본질을 잊게 되었습니다. 무엇을 할지, 무엇을 배웠는지가 한눈에 보이지 않았어요.

팀에서 장애 회고 과정까지 다시 회고하면서 장애 대응 경험들이 앞으로 실질적인 기술 자산이 될 수 있는 방향을 고민했어요. 구글 SRE book 의 포스트모템 사례들을 다시 읽고, 양식을 통째로 갈아엎었습니다. 무엇이 통했고 무엇이 통하지 않았는지, 다음에 무엇을 바꿔야 할지가 분명하게 드러나는 양식으로요. 새 가이드를 챕터 전체에 공유하면서 SRE 원칙을 다시 잡아가는 중이고, AI 와 일할 때의 가드레일을 어디에 어떻게 둘지도 같이 고민하고 있어요.

Q6. AI 의 생산성 만큼이나 위험성도 고민되실 것 같아요. AI 시대는 서버플랫폼 팀이 일하는 방식을 어떻게 바꾸고 있나요?

성준

시스템을 분석하는 업무에서의 변화가 가장 컸어요. Application들이 남기는 수많은 메트릭과 로그, 덤프 속에서 병목과 문제의 근본 원인을 찾는 게 저희 팀의 주 업무인데요, 예전에는 직접 메트릭 쿼리를 날리고, 로그를 하나하나 검색하고, 기가바이트 단위 덤프 파일 속에서 단서를 찾느라 길면 일주일이 걸렸어요.

지금은 VictoriaMetrics · Log · Trace MCP 를 연결해두면, AI 에이전트를 통해, 자연어로 쉽게 로그와 메트릭을 분석할 수 있어요. AI 에이전트 없이 사람의 힘만으로는 물리적으로 불가능한 일들도 할 수 있고요(예를 들어 일 년 치 로그를 모두 뒤져보는 식이죠). 가끔은 "이질적인 두 지표의 상관관계를 보니 이 구간이 비정상적입니다" 같이 제가 주입한 노하우를 넘어서는 인사이트를 던져줄 때도 있어요. 일주일 걸리던 분석이 1~2시간이면 끝나는 경우가 많아졌습니다.

강산

코딩에 들이는 시간이 확실히 많이 줄었어요. 한 달 내내 했을 마이그레이션 작업이 일주일이면 끝나는 식이거든요. 남는 시간이 늘어난 만큼, 우리 팀 입장에선 더 많은 문제를 동시에 들여다볼 수 있게 됐어요.

한편, AI 가 자율적으로 작업하는 영역이 넓어질수록 가드레일을 어디에 어떻게 잘 세워둘지가 점점 더 중요해지는 것 같아요. 생산은 충분히 빨라졌지만, 사람의 검증은 결국 병목이 되고 있고, 자율로만 가면 사고가 나기 쉽고, 통제로만 가면 속도가 안 나오니까요. 그 사이의 균형을 어떻게 잡을지를 팀 안에서 같이 고민하는 중입니다.

Q7. 서버플랫폼팀이 내부에서 같이 일하는 방식은 어떤지도 궁금해요.

강산

사실 서버 플랫폼 팀의 일은 미리 짜둔 로드맵 위에서 예상대로 진행되지 않을때가 많아요. 다른 팀에서 들어오는 협업 요청이나, 갑작스러운 문의나 장애 대응이 끼어드는 일이 잦기 때문에, 각자 잡고 있던 일의 우선순위가 뒤바뀌는 경우가 종종 있어요. 자연스럽게 서버플랫폼 팀 개개인이 "내가 지금 해야 할 가장 중요한 일"을 스스로 판단하고, 팀 내에서 논의나 공유가 필요한 결정이 생기면 그때그때 동료들과 즉석으로 sync 를 잡는 식으로 업무를 진행하고 있어요.

다만 이 방식만으로 오래 가다 보니, 동료가 지금 무슨 가정 위에서 무엇을 만들고 있는지가 서로 흐려지는 순간들도 누적되더라고요. 자율의 부작용이라고 해야 할까요. 그 부분을 보완하기 위한 고민들도 함께 하고 있어요.

찬희

매주 목요일에는 Server Platform Sync 라고 부르는 미팅이 있어요. 강산님이 말한 문제를 보완하기 위해서 최근에 새로 만든 자리인데, 각자의 작업 속도는 가능한 한 떨어뜨리지 않으면서 최소한의 방향만 같이 맞춰보자는 취지로 시작했어요. 누군가 가져온 안에 대해 다른 팀원이 "이 가정이 깨지면 어떻게 되나요?" 같은 질문을 자연스럽게 던지면서, 서로 작업하며 설계한 방향과 가정들이 적절한지 함께 리뷰하는 자리예요.

테크 스펙과 ADR(Architecture Decision Record, 아키텍처 결정 기록) 도 비슷한 결로 실험적으로 도입해보고 있어요. 그동안은 설계적 의사결정이 슬랙, 노션, 코드 저장소처럼 여러 곳에 파편화되어 있었거든요. 이걸 한 자리에 모아두고 들고 와서 같이 다듬는 흐름을 만들어보는 중입니다. 이 자리도 처음 만들었을 때와 지금이 꽤 달라요. 직접 PoC 해보면서 효과가 없는 부분을 그때그때 갈아엎으면서 모양이 잡혀가는 중이거든요.

Q8. 마지막으로, 어떤 분이 우리 팀과 잘 맞을 것 같으세요?

강산

서버 플랫폼 팀은 오너십을 발휘할 수 있는 영역이 정말 넓은 환경이에요. 직접 손을 움직여서 문제를 해결하는 걸 좋아하는 분이라면, 설계부터 구현, 배포, 운영까지 전 과정을 경험할 수 있어요. 우리 팀이 만든 도구들을 제품팀이 실제로 어떻게 쓰는지 가까이서 관찰하고, 되돌아보면서 고쳐나가는 것. 그 사이클 자체가 매번 즐거운 자극이 되어주기도 하고요.

지금 우리가 만든 플랫폼도 어디까지나 현재 stage 에 맞는 형태라고 생각해요. 회사가 성장하고 비즈니스 요구사항이 바뀌면 또 거기에 맞춰 바꿔나가야 할 거고요. 그런 변화 속에서 기존 시스템을 끊임없이 재해석하고 발전시키는 과정을 즐길 수 있는 분이라면 잘 맞을 것 같습니다.

찬희

저는 결국 끝까지 완수해 내는 끈기를 중요하게 보고 있어요. 정해주는 사람이 없는 환경이라, 스스로 문제를 정의하고, 합리적으로 소통하면서 끝까지 끌고 가는 일이 많거든요. 기술적으로 구현하는 걸 넘어, 왜 이 문제가 발생했는지 근본 원인까지 깊게 파고들고 동료들과 공감대를 만들어가는 과정을 즐기실 수 있는 분이라면 잘 맞을 것 같아요.

성준

저희 팀의 일은 결국 하나의 큰 사이클이에요. 문제를 발견하고 진짜 해결해야 할 문제인지 정의하고, 장기적인 방향을 설계하고 무중단 마이그레이션과 원인 분석까지 이어지거든요. 복잡한 문제를 긴 호흡으로 끝까지 해결해나가는 과정 자체를 즐길 수 있는 분이라면 잘 맞을 거라고 생각합니다.