pile·
아키텍처·라포랩스 (퀸잇)라포랩스 (퀸잇)·

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

라포랩스 Server Platform Team 이 조직 성장에 맞춰 배포·권한·이벤트·부팅 같은 플랫폼 기반을 계속 다시 설계한 이야기를 인터뷰 형식으로 다룬다. "좋은 플랫폼은 책에서 가져올 수 없고 회사 규모·팀 구조·제품 이터레이션을 관찰한 결과로만 나온다"는 철학 아래, 자율성과 안정성의 균형을 맞춘 사례들을 짚는다.

핵심 포인트
  • ArgoCD 기반 자율 배포로 주 2~3회를 일 2~30회로 늘리되, Grafana+Slack 으로 배포 가시성을 강제했다.
  • 어드민 권한을 API별 allowlist 에서 크리티컬·일반 액션 분류로 바꿔 Keycloak 토큰 페이로드 폭증을 해결했다.
  • Debezium 강결합으로 인한 이벤트 SPOF 를 플랫폼 표준 파이프라인 통합으로 개선 중이다.
  • Spring Boot 부팅 시간을 50% 이상 줄여 HPA·스팟 인스턴스 교체 시 가용성을 높였고 Spring Data Commons 버그를 기여했다.
  • ADR·정기 sync 로 자율성이 흩뜨리는 의사결정 맥락을 다시 모은다.
상세 정리
  • 배경: 조직 확대로 배포 병목, 마이크로서비스 전환에 따른 서버 급증, 어드민 권한 확장 한계, 이벤트 전달 SPOF 가 동시에 불거졌다.
  • 설계 철학: 초기 가정이 시간과 함께 무효화되므로 기술 의사결정을 지속 재평가하고, 정책과 기술을 병행 개선한다.
  • CI/CD: ArgoCD 로 중앙 배포를 자율 배포로 바꿔 주 2~3회를 일 2~30회로 늘렸으나 장애가 늘자, Grafana 대시보드+Slack 으로 누가·언제·어떤 형상으로 배포했는지 가시화하고 ArgoCD UI 에 Canary 제어를 통합했다.
  • 권한 시스템: API마다 사용자 allowlist 를 수동 추가하다 토큰 페이로드가 폭증해, 보안팀과 크리티컬 액션(정산금·개인정보)과 일반 액션을 분류해 토큰 크기와 개발자 부담을 함께 줄였다.
  • 이벤트 메시징: Debezium 강한 의존으로 SPOF 위험이 있어, 서비스별 메시지 재처리·로깅 로직을 플랫폼 표준 파이프라인으로 통합하는 작업을 진행 중이다.
  • 부팅 최적화: Spring Boot 부팅 시간을 50% 이상 줄여 HPA 확장·스팟 교체 시 응답 지연을 낮췄고, 그 과정에서 발견한 Spring Data Commons 버그를 오픈소스에 기여했다.
  • AI 활용: VictoriaMetrics·Log·Trace 를 MCP 로 연결해 일주일 걸리던 분석을 1~2시간으로 줄이고, 코딩 작업도 한 달치를 일주일로 단축했다.
  • 가드레일: AI 자율성이 커지며 자율과 통제의 균형이 핵심 과제가 됐고, 4월 인프라 삭제 장애 후 구글 SRE 사례를 참고해 포스트모템 양식을 개편하고 협업 가드레일을 재수립 중이다.
  • 협업: 자율성이 동료 작업의 가정·방향을 흐리는 걸 막으려 목요일 Server Platform Sync, ADR 도입, 테크 스펙 공유로 의사결정을 한자리에 모은다.
왜 읽나성장하는 조직에서 배포·권한·이벤트 플랫폼을 책임지는 플랫폼 엔지니어에게, 자율성과 안정성을 함께 끌어올린 구체적 의사결정 레퍼런스.
라포랩스 (퀸잇)
라포랩스 (퀸잇) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 아키텍처·aws-architectureAWS Architecture·

    일관성이 새로운 지연이다: 데이터 레이어에서의 AI

    AI 에이전트가 데이터베이스 레이어에서 겪는 데이터 정합성 문제를 다룬다. 비동기 복제 지연(replication lag)으로 stale 데이터를 읽은 에이전트가 잘못된 판단을 내리는 "조용한 독"을 AWS 서비스 기반 세 가지 아키텍처 패턴으로 해결하는 방법을 제시한다. "빠르지만 틀린 답이 약간 느리지만 맞는 답보다 비싸다"는 주장 아래, 데이터베이스 아키텍처를 AI 신뢰성의 기반으로 재정의한다.

    요약 이어보기
    #ai-agent#data-consistency#aurora+2
  2. 아키텍처·flexflex·

    사람도 에이전트도, 덜 읽을수록 더 잘 고칩니다

    flex 팀이 코드베이스의 모듈 경계 설계가 AI 에이전트의 코드 탐색 효율에 미치는 영향을 실측한 글이다. 193개 에이전트 작업 로그를 분석하고, 잘 나뉜 모듈과 뭉친 모듈을 비교한 결과 — 도메인이 물리 모듈로 분리된 저장소에서 에이전트가 불필요한 파일을 덜 읽고 목표 코드에 더 집중했다. 사람도 에이전트도 컨텍스트 한도가 있어, 무관 코드를 덜 읽을수록 수리 성공률이 높다는 것이 핵심 결론이다.

    요약 이어보기
    #llm-agent#context-window#modular-architecture+1
  3. 아키텍처·aws-architectureAWS Architecture·

    데이터 거주 요건을 충족하는 재해 복구 전략

    데이터 거주(data residency) 규정을 지키면서 재해 복구(DR)를 구현해야 하는 조직을 위해 AWS가 세 가지 전략 프레임워크를 제시한다. 금융, 의료, 공공 부문처럼 지리적 데이터 보관 의무가 있는 환경에서도 복구 목표(RTO/RPO)를 달성할 수 있는 아키텍처 선택지를 비교한다.

    요약 이어보기
    #multi-cloud#compliance#disaster-recovery+2