사내 그룹웨어 플랫폼

메일, 게시판, 전자결재, 캘린더, 근태 등 서로 다른 업무 도메인을 하나의 플랫폼 안에서 일관되게 제공해야 했습니다.

기업별 데이터와 권한이 분리되는 멀티 테넌시 구조를 기반으로, 개발자에게는 찾기 쉬운 코드 구조를, 사용자에게는 학습이 적은 인터페이스를 목표로 삼았습니다.

낮은 결합도를 목표로 11개의 마이크로서비스를 구성했지만 개발 중 OutOfMemory와 CPU 사용량 증가로 기동이 멈추는 현상이 발생했습니다.

자원 모니터링과 로그를 확인한 뒤 유사 도메인 한 쌍을 통합해 서비스 수를 11개에서 10개로 조정하고, 서비스 구성과 DB 커넥션 구조를 함께 리팩터링했습니다. 낮은 결합도와 현실적으로 활용 가능한 자원의 한계를 함께 고려해야 한다는 점을 배웠습니다.

메인 기능 트랜잭션에 푸시 알림과 메일 발송 로직이 동기적으로 묶여 있어 연동 지연이나 실패가 핵심 기능의 오류로 전파되고, 긴 발송 로직을 함수마다 재작성하는 중복이 발생했습니다.

Kafka와 RabbitMQ를 비교한 뒤 대규모 스트리밍보다 이벤트 라우팅이 중요한 프로젝트 특성에 맞춰 RabbitMQ를 선택했습니다. 각 서비스에는 이벤트 발행 모듈을, Notification 서비스에는 처리 모듈을 구성했습니다.

메일·전자결재·게시판에 더해 근태와 연차 업무를 하나의 플랫폼에서 처리할 수 있도록 인사 담당자와 협업했습니다.

연차·반차 반영 방식, 연차 차감 기준과 근태 인정 범위의 기본 규칙 및 예외 조건을 정리하고, 복잡한 예외를 흡수하는 정책 생성 프로세스와 비즈니스 로직을 설계했습니다. 프로세스에 따라 근태·연차 데이터가 그룹웨어에 자동 반영되도록 구현했습니다.

외부 메신저 솔루션 도입이 어려워져 사내 실시간 소통 기능을 별도로 마련해야 했습니다.

그룹웨어 안에서의 위치와 사용 흐름을 먼저 정하고 1:1 채팅, 파일 첨부, 클립보드 이미지 붙여넣기를 MVP 범위로 정의했습니다. AI 도구를 활용해 Node.js와 WebSocket 기반 기능을 구현하고 3일 안에 필요한 범위의 MVP를 완성했습니다.

AI 도구 활용이 늘면서 팀원마다 다른 코드 패턴과 중복 함수·컴포넌트가 생성되기 시작했습니다.

폴더 구조, 컴포넌트 재사용 기준, API 호출 패턴과 커밋 규칙을 주제별 Markdown 문서로 명문화하고, 관련 문서의 경로와 참조 순서를 안내하는 인덱스를 구성했습니다. 프롬프트에는 인덱스 번호를 전달해 AI가 필요한 문서만 선택적으로 참고하도록 했습니다.

완료된 기능이 검증 단계를 거쳐 가오픈 환경에 안정적으로 반영되도록 GitHub 브랜치 흐름을 정리했습니다.

인프라팀이 제공한 가이드에 따라 Helm 차트 기반 GitOps 배포 구성을 작성하고, development에서 통합한 기능을 stage에서 검증한 뒤 production에 반영했습니다. 브랜치 merge 후 Jenkins에서 빌드·이미지를 푸시하고 ArgoCD가 배포하는 흐름을 시스템에 적용했습니다.