
왜 팔도감은 마이크로서비스에서모놀리스로 전환했을까?
팔도감은 작은 조직 규모와 운영 복잡도를 고려해 MSA 대신 모듈리스 구조로 전환했습니다. Git Submodule, Gradle Composite Build, 코드 리팩터링 도구로 마이크로서비스 코드를 통합했습니다.

팔도감은 작은 조직 규모와 운영 복잡도를 고려해 MSA 대신 모듈리스 구조로 전환했습니다. Git Submodule, Gradle Composite Build, 코드 리팩터링 도구로 마이크로서비스 코드를 통합했습니다.

헥사고날 아키텍처를 빌링 서비스에 도입한 경험과 구조를 정리했습니다. 외부 의존성을 분리해 유지보수성과 확장성을 높였지만, 초기 설계와 팀 합의가 중요했습니다.

책임을 분리하면 코드가 더 깔끔해질 것 같지만, 제약 조건과 의존성이 오히려 흩어질 수 있었습니다. 클래스 분할뿐 아니라 호출자 부담과 결합도까지 함께 살펴야 했습니다.


플렉스팀이 5년간 Monolith에서 MSA까지 아키텍처를 진화시키며 레거시를 줄인 과정을 공유했습니다. 변경 파급효과를 줄이기 위한 구조 분리와 Auto Configuration 활용이 핵심이었습니다.

WMS의 입고·재고·출고가 얽힌 구조를 재고 도메인부터 분리해 안전하게 개선했습니다. 헥사고널 아키텍처, 피처 플래그, 테스트와 문서화로 큰 변경을 점진적으로 배포했습니다.

두 상속 트리의 암묵적 대응 관계가 타입 안전성 문제를 만들 수 있음을 설명했습니다. 상속 대신 컴포지션을 쓰거나 제네릭으로 반환 타입을 명시하는 방법을 제안했습니다.


대량 데이터를 효율적으로 나누는 파티셔닝과 Z-order curve 개념을 설명했습니다. 날짜·플레이어 같은 다양한 탐색 조건에 맞춰 저장 구조를 설계하는 방법을 다뤘습니다.

카카오페이 여신코어를 DDD와 멀티모듈 구조로 내재화한 과정을 공유했습니다. 도메인 경계, 공통 언어, Entity 분리를 통해 복잡한 여신 업무를 견고하게 설계한 사례입니다.

가변 속성을 개별적으로 바꾸면 이전 값이 남아 버그가 생길 수 있었습니다. 정책 객체로 묶어 상태 갱신 시점과 조합을 제한하는 방식이 더 안전했습니다.

MCP 서버와 AI 에이전트의 역할을 명확히 구분해야 한다는 설계 원칙을 정리했습니다. 실행 통제와 감사 가능성을 위해 별도 보안 계층이 필요하다고 설명했습니다.

MCP 서버와 AI 에이전트의 역할을 분리해 보안 설계 원칙을 설명했습니다. 실행 통제와 감사 가능성을 위해 MCP Agent PAM 같은 보완 계층의 필요성을 강조했습니다.

카카오뱅크 Oslo 시스템의 도입, 운영, 종료 과정을 통해 기술적 선택의 유한성과 가역성을 돌아보았습니다. 장애 격리에는 성공했지만 장기 운영 비용과 Bus Factor 문제로 EOS를 결정했습니다.