장태환

Fireside — 콘텐츠 중심 B2B 메신저 서비스

Spring Boot Java RabbitMQ MyBatis OCI Prometheus Grafana

기업 고객을 위한 B2B 메신저 서비스입니다. 멀티테넌시 아키텍처 설계부터 조회 성능 개선, CI/CD 구축, 챗봇 기능 및 라이브러리 개발까지 백엔드 전반을 담당했습니다.

멀티테넌시 아키텍처 설계

클라우드(멀티테넌시), 단일 설치형, 온프레미스까지 세 가지 환경을 모두 지원해야 했기 때문에, 하나의 코드베이스로 다양한 운영 형태에 대응할 수 있는 서버 구조를 설계하는 것이 핵심 과제였습니다.

멀티테넌시 구현 방식으로 DB 인스턴스 분리, Row-level 격리, 스키마 단위 격리 세 가지를 검토했습니다. DB 인스턴스 분리는 고객사가 늘수록 비용이 선형적으로 늘어났고, Row-level 격리는 MyBatis 환경에서 모든 쿼리에 테넌트 조건을 개발자가 직접 관리해야 하는 부담이 있었습니다.

결국 스키마 단위 격리를 선택했습니다. 온프레미스나 단일 클라우드로 마이그레이션이 필요한 고객사가 생기더라도, 스키마 단위로 덤프를 이관한 뒤 서버 설정만 싱글 테넌시로 바꾸면 전환할 수 있기 때문입니다. 인증 단계에서 테넌트를 식별하고, MyBatis 쿼리 실행 시 자동으로 스키마를 바인딩하는 식으로 구현해, 이후 개발자들이 멀티테넌시를 별도로 의식하지 않아도 되는 구조를 만들었습니다.

신규 테넌트 생성은 신규 고객사의 결제 이벤트를 수신하면 management 서버가 테넌트 스키마와 초기 데이터를 자동으로 구성하는 방식으로 자동화 했습니다.

멀티DB 환경에서의 조회 성능 개선

Fireside는 MySQL, MSSQL, Oracle을 동시에 지원하는 구조였습니다. 메시지 테이블에 데이터가 쌓이면서 특정 대화방 조회 시 Full Scan이 발생해 API 응답이 600~800ms까지 느려졌습니다. 인덱스 설계와 반정규화로 50~200ms 수준까지 개선했지만 근본 원인은 따로 있었습니다.

멀티DB를 지원하는 구조 때문에 DB 종류마다 분기 처리가 필요했고, MyBatis 쿼리는 <if test="_databaseId == ~"> 형태의 중첩 블록으로 복잡해져 쿼리를 분석하기 어려웠습니다. QA도 DB별로 분리해 진행하기 어려웠고, 실제로 QA는 Oracle 환경에서만 수행되고 있었지만 운영 환경은 모두 MySQL이었습니다.

실제 운영 중인 고객사를 직접 조사한 결과, MSSQL이나 Oracle을 사용하는 고객사는 없었습니다. 이 데이터를 근거로 MySQL 단일화를 제안했고, 처음에는 “미래 고객사를 포기할 수 없다”는 이유로 거절되었습니다. 앞서 인덱스 설계만으로 응답속도를 600~800ms에서 50~200ms까지 단축한 사례를 제시하며, MySQL 단일화로 쿼리 구조와 QA 범위를 단순화하면, 성능뿐 아니라 유지보수성과 운영 안정성까지 함께 개선할 수 있다는 점을 구체적으로 설득했습니다. 결과적으로 MySQL 중심의 운영 전략으로 기술 방향을 전환하는 의사결정을 이끌어냈습니다. 이를 통해 쿼리 구조와 QA 범위를 단순화하는 기반을 마련했습니다.

CI/CD 파이프라인 구축 및 컨테이너 전환

사내 Jenkins는 외부망이 차단된 온프레미스 환경이었습니다. 빌드에는 20분이 걸렸고, 새 라이브러리가 필요할 때마다 관리자에게 수동 요청을 해야 했습니다.

문제의 근본은 의존성 관리 구조에 있었습니다. 먼저 사내에 Nexus를 구축해 특정 outbound만 허용하는 방식으로 보안 정책을 유지하면서도 라이브러리를 자율적으로 관리할 수 있도록 했습니다. 이어서 팀 내 유휴 장비였던 iMac을 GitLab Runner로 구성하고, war 배포 방식을 Docker Compose 기반 컨테이너 배포로 전환했습니다. 모니터링 스택(Prometheus, Grafana, Loki)도 별도 Compose로 분리해 필요할 때 즉시 실행할 수 있도록 구성했습니다.

제약을 우회하기보다, 그 안에서 가장 효과적인 CI/CD 구조를 설계하는 데 집중했습니다. 개발·QA 기간에는 하루 20~30회 이상 빌드가 이루어지는데, 빌드 시간을 20분에서 8분 이하로 단축해 팀 전체의 대기 시간을 크게 줄였습니다.

AI 도구를 활용한 개발 생산성 개선

서비스 확장에 따라 프로젝트(repository)가 늘어나면서, 프로젝트마다 코드 스타일과 컨벤션이 달라지는 문제가 생겼습니다. GitLab issue board를 kanban 방식으로 운영하고 있었지만, 중요도·진행상황 라벨 부착, 이슈 설명 및 작업 내용 기재 같은 컨벤션을 팀 전체가 일관되게 지키게 하기 어려웠습니다.

이를 해결하기 위해 Claude Code의 skill 기능을 활용했습니다. 이슈 작성, 코드 리뷰, 문서화 같은 반복 작업을 skill로 정의하고, 이를 플러그인 형태로 패키징해 팀 레포지토리에 배포했습니다. 플러그인 업데이트 시 팀원 전체가 자동으로 최신 버전을 사용하는 마켓플레이스 구조로 구성해, 문서를 읽고 따르는 방식이 아니라 도구가 컨벤션을 강제하는 방식으로 전환했습니다.

여기서 더 나아가 Claude Code의 channel 기능을 활용해 Discord 봇을 구성했습니다. 봇은 팀 플러그인을 그대로 탑재하고 있으며, 진행 중인 프로젝트 정보와 API 문서·서비스 사양도 함께 보유합니다. 개발자뿐 아니라 디자이너·기획자도 봇을 통해 구현 사양을 직접 확인할 수 있어, 개발팀 외부와의 커뮤니케이션 구조를 개선하고 있습니다.

DigitalPage — AI 메모 서비스

Spring Boot Java MyBatis MySQL AWS

DigitalPage는 쉽고 빠르게 기록하는 AI 메모 서비스입니다. 인프라 마이그레이션과 인증 구조 통합 등 백엔드 개발을 담당했습니다.

레거시 인프라 마이그레이션 (Lambda → EC2)

서비스의 API 서버가 AWS Lambda 위에서 돌아가고 있었는데, Java 런타임 특성상 Cold Start가 심각했습니다. 사용자가 요청을 보낼 때마다 수 초씩 기다려야 하는 상황이 빈번했고, 상시 가동이 필요한 메모 서비스의 특성과 맞지 않았습니다.

Serverless가 상시 가동이 필요한 서비스 특성에 맞지 않다고 판단하여, EC2 기반 API 서버로의 마이그레이션을 수행했습니다. Cold Start 문제를 근본적으로 해결하며 평균 API 응답속도를 3배 이상 향상시켰습니다.

멀티 플랫폼 인증 구조 통합

DigitalPage는 웹, 모바일(iOS/Android), Chrome Extension과 같이 다양한 플랫폼을 지원합니다. 하지만 각 플랫폼마다 인증 방식이 제각각이어서, 변경이 생기면 여러 곳을 함께 수정해야 했고 일관성을 유지하기 어려웠습니다. 플랫폼별로 분산된 인증 로직을 하나의 흐름으로 통합하여, 인증 변경 시 단일 지점에서 관리할 수 있도록 개선했습니다.

DigitalPage Web Clipper — Chrome Extension

React TypeScript Zustand

DigitalPage의 Chrome Extension입니다. 채용 연계형 인턴으로 입사하여 프로젝트를 수행했습니다.

DigitalPage의 모토는 “쉽고 빠른 기록”이었지만, 정작 웹에서 콘텐츠를 바로 메모할 수 있는 경로가 없었습니다. 웹 서핑 중 마음에 드는 글이나 이미지를 저장하려면 앱을 열고, 복사하고, 붙여넣는 과정을 거쳐야 했습니다.

이 문제를 해결하기 위해 Chrome Extension 형태의 Web Clipper 개발을 직접 제안했습니다. 기획, 디자인 협의, React/TypeScript/Zustand 기반 개발, Chrome Web Store 배포까지 전 과정을 전담했습니다. 사내 우수 과제로 선정되어 전사 발표를 진행했고, 이 프로젝트를 계기로 정규직으로 전환되었습니다.

Work Experience