개발자의 정체성 위기

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

• 소프트웨어 아키텍처 및 DevOps 분야의 개발자, 팀 리더
• 중급 이상의 기술 이해도를 가진 개발자

핵심 요약

• 모노리스에서 마이크로서비스로의 전환은 개발자의 역할을 건축자에서 유지보수자로 변화시켰다
• 마이크로서비스는 스케일링 가능성을 제공하지만, 시스템의 역사와 이유를 잃는다
• 시스템의 탐색 가능성(discoverability)과 스토리텔링이 중요한 디자인 원칙으로 부상했다

섹션별 세부 요약

1. 모노리스 시대의 장점

• 시스템의 통합성을 통해 개발자는 전체 아키텍처를 이해할 수 있었다
• 코드베이스의 변화의 흐름을 직접적으로 파악할 수 있었음
• 개인의 역할이 명확하여 문제 해결이 직관적

2. 마이크로서비스로의 전환

• 서비스 분리로 인해 개발자는 특정 서비스(service-accounts-api-v2)만을 담당하게 됨
• 자율성의 이론적 장점이 실제로는 팀 간 의존성 증가로 이어짐
• 기능 변경을 위한 다중 승인, PR 병합, DevOps 협업이 필수적

3. 자율성의 UX 문제

• 마이크로서비스는 상태 없는 시스템(stateless)으로 설계되어 역사 추적 불가능
• 개발자는 스토리텔링과 전체 시스템 이해를 어렵게 만듦
• 도구의 모듈화가 오히려 시스템 이해를 복잡하게 만듦

4. 해결 방향 제시

• 시스템의 탐색 가능성을 위한 문서화 및 도구 개발 필요
• 아키텍처 다이어그램이 단순한 시각 자료가 아닌 시스템의 역사를 담는 방법 제안
• 스토리텔링 중심의 설계가 개발자에게 정체성 회복을 가능하게 함

결론

• 마이크로서비스 아키텍처는 스케일링을 허용하지만, 시스템의 역사와 개발자 정체성을 잃지 않도록 탐색 가능성과 스토리텔링을 핵심 설계 원칙으로 삼아야 한다.
• 도구와 문서화는 단순한 유지보수 도구가 아닌, 개발자에게 의미를 전달하는 매개체로 설계되어야 한다.