면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
MSA 환경에서 다른 팀과 협업할 때 가장 주의해야 하는 것은 서비스 경계를 명확히 합의하는 것이라고 생각합니다. API 인터페이스 정의가 모호하면 양쪽 팀이 서로 다른 가정을 가지고 개발하다가 통합 시점에 문제가 발생합니다. 계약 우선 설계(Contract-First) 방식으로 먼저 OpenAPI 스펙을 확정하고, 양쪽이 그 스펙을 기준으로 개발하면 의존성을 최소화하면서 병렬 개발이 가능해집니다. 팀 간 커뮤니케이션 비용을 줄이는 가장 효과적인 방법은 코드보다 계약서를 먼저 쓰는 것이라고 생각합니다.
계약을 먼저 쓰는 습관이 개발 속도를 오히려 높인다는 것을 팀 프로젝트를 통해 직접 확인하였습니다.
MSA에서 다른 팀 서비스에 의존하면, 그 팀의 장애가 내 서비스까지 번지는 연쇄 문제가 생길 수 있어요. 서킷 브레이커 패턴이나 타임아웃 설정을 협업 초기에 같이 논의해두는 게 중요해요. 제가 팀 프로젝트에서 외부 API를 호출하는 서비스를 만들었을 때, 상대 서비스가 느려지자 내 서비스 요청이 쌓이면서 전체가 중단된 경험이 있었거든요. 그때부터 Fallback 전략을 미리 설계하는 것이 의존성 있는 서비스 개발의 기본이라는 걸 알게 됐습니다.
장애는 언제든 날 수 있고, 중요한 건 그때 시스템이 어떻게 반응하느냐라는 걸 그 경험에서 배웠습니다. 장애 시나리오를 설계 단계에서 미리 논의한 팀과 그렇지 않은 팀은, 운영 중에 반응 속도가 확연히 달랐어요.
MSA에서 메시지 큐 기반으로 팀 간 통신할 때, 스키마 변경이 예고 없이 이루어지면 소비 측 서비스가 조용히 깨지는 문제가 생겨요. Avro나 Protobuf 같은 스키마 관리 도구를 쓰더라도, 버전 변경 정책을 팀 간에 미리 합의해두지 않으면 운영 중에 충돌이 납니다. 배포 주기가 다른 팀들이 같은 이벤트를 소비할 때, 하위 호환성 유지 기간을 명시하고 레거시 필드 삭제 정책을 공유해두는 것이 협업의 기본이라고 생각해요.
메시지 기반 협업에서 스키마 관리는 API 문서만큼 중요하다는 걸, 운영 중에 터진 문제를 통해 배웠어요. API와 이벤트 스펙은 코드보다 더 오래 남는다는 걸, 그 경험을 통해 깊이 실감했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.