애플리케이션 플랫폼: 전달, 트래픽 관리, 캡슐화 등

전달 (Delivery)

• 전달 파이프라인 개선은 기존 시스템 장애 가능성을 줄이고, 문제 발생 시 빠른 롤백이 가능하게 함.
• CI(지속적 통합) 와 CD(지속적 전달) 의 경계는 흐릿하지만, 개념적으로 명확히 구분해야 함:
  • CI는 산출물을 저장소에 저장할 때 종료
  • CD는 그 시점부터 시작
• 목적의 차이:
  • CI: 빠른 피드백, 자동 테스트, 병합 장려
  • CD: 릴리스 주기 단축, 보안 준수, 유연한 배포

트래픽 관리

• 복원력은 장애를 예측하고 보상하는 구조에서 나옴
  • 가용성 모니터링: 장애 발생 지점 파악
  • 디버깅 가능성 모니터링: 장애 원인 분석
  • 전달 자동화: 증분 릴리스에 대한 장애 억제
• 트래픽 관리 패턴은 실시간으로 장애에 대응할 수 있게 돕는 기술

모니터링 시스템 > 테스트 자동화

• 테스트는 완전하지 않으며, 커버리지 100%는 실현 불가능에 가까움
• 프로덕션 환경은 항상 다르게 행동함
• 모니터링 시스템은 예상 못한 장애까지도 포착 가능
• 테스트는 우리가 아는 것을 증명, 모니터링은 실제로 벌어지는 일을 보여줌
• 따라서 테스트보다 모니터링이 더 필수적

개인적으로 테스트 커버리지 100%를 지향하지만, 실무에서 프로덕션 환경에서만 드러나는 문제들을 경험하며 한계를 체감함. 성능 문제는 특히 코드만으로는 검증이 어려움.

캡슐화

• 캡슐화: 상태와 동작을 하나로 묶고 외부에 감추는 구조 (ex. 자바 클래스)
• 플랫폼 엔지니어링도 이와 유사:
  • 개발팀(고객)의 책임을 줄이기 위해 정보를 은닉
  • 최고의 칭찬: “그쪽 일은 신경 쓸 필요 없어요”

명시적 종속성 관리

• 런타임 종속성
  • 주요 라이브러리는 메트릭, 태그, 트래픽 관리 패턴을 함께 구성
• 서비스 클라이언트 종속성
  • 장애 대응 로직(fallback, retry 등)은 서비스 개발팀이 책임지는 것이 좋음
• 런타임 종속성 주입
  • 배포 표준화가 전제
  • 예: 스프링부트 앱에 플랫폼 메트릭 주입
• 도입 전략
  • 파일럿 팀/앱 선정 → 원칙 적용 및 연습 → 일반화

서비스 메시

• 제어 플레인 + 사이드카를 아우르는 인프라 계층
• 트래픽 관리, 서비스 탐색, 모니터링을 담당하여, 애플리케이션은 비즈니스 로직에 집중 가능
• 복잡도와 운영 비용을 줄여줌

❗ 사이드카에는 도메인 지식을 넣지 말자
복잡성 증가 및 유지보수 어려움 발생
➝ 공통 기능만 최소한으로 구현

결론

• 플랫폼 엔지니어링은 개발팀을 통제하는 것이 아님
• 고객 중심으로 도움을 주는 역할이어야 하며, 모든 도구와 프로세스는 관문이 아닌 가드레일이 되어야 함