마케팅의 패러다임이 바뀌었습니다. 과거의 마케팅이 “최대한 많은 사람에게 메시지를 뿌리는 것(Mass Marketing)”이었다면, 현대의 마케팅은 “데이터가 예측한 특정 사용자에게, 가장 적절한 타이밍에, 개인화된 메시지를 전달하는 것(Hyper-Personalization)”입니다.

바비톡은 글로벌 CRM 솔루션인 Braze를 도입하여 다음과 같이 성공적인 성과를 거두고 있습니다.

• 브레이즈 Webhook 캠페인으로 맞춤형 배너 기반 A/B 테스트 운영하기
• 브레이즈 Webhook으로 최적의 쿠폰 조건 발굴을 위한 A/B 테스트 운영하기
• 자체 AI 예측 모델로 브레이즈에서 초개인화된 재시술 카카오톡 알림 메시지 발송하기

하지만 강력한 외부 솔루션만으로는 부족합니다. 이를 뒷받침할 내부의 기술적 인프라가 없다면, 마케팅은 개발팀의 리소스를 잡아먹는 하마가 되거나, 서비스 장애를 유발하는 폭탄이 될 수 있습니다.

오늘 소개할 이야기는 바비톡 기술팀이 마케팅의 속도(Automation)와 안정성(Stability)이라는 두 마리 토끼를 잡기 위해 구축한 서버리스 기반의 MarTech 엔진, crm_box에 대한 기록입니다.

1. What is crm_box?

crm_box는 바비톡의 마케팅 테크놀로지를 지탱하는 AWS Serverless 기반의 통합 마이크로서비스입니다. 이 시스템은 크게 3가지 기술적 특징을 갖고 있습니다.

1. Hyper-Automation: 개발자 개입 없는 마케팅 운영 자동화 (S3 → Lambda) → 마케팅 운영자를 위한 별도의 운영 웹콘솔을 매번 만드는 것은 유지보수 측면에서 매우 번거로운 일입니다. 따라서 바비톡에서 운영 정보를 추상화하여 json으로 작성 후, s3 bucket에 upload하면 자동으로 반영되는 방식을 채택하였습니다.
2. Traffic Control: 마케팅 트래픽 폭주 제어 및 시스템 보호 (Braze → SQS → Lambda) → 타겟팅되어 쿠폰이나 채널 발송이 이뤄질 때 바비톡 시스템으로 그 트래픽이 짧은 시간에 그대로 유입되면 서버가 감당할 수 없습니다. 그래서 바비톡은 처리할 수 있는 만큼만 처리할 수 있도록 큐기반 비동기 방식을 채택하였습니다.
3. Auto Data Load: 바비톡 가공 데이터를 Braze와 연동 → 바비톡 aws 데이터 계정에서 분석 완료된 개인 프로파일 정보 및 모델링 정보를 자동으로 Braze에 적재할 수 있도록 자동화된 Pipeline을 구축하였습니다.

우리는 이 세축을 통해 마케터에게는 무한한 자유를, 엔지니어에게는 견고한 안정성을 제공합니다.

2. Pillar 1: 초자동화(Hyper-Automation)로 개발자 의존성 끊기

Challenge: “배너 하나 바꾸는데 개발자가 매번 지원해야 하나요?”

마케터가 앱 내 배너를 수정하거나 특정 타겟에게 문자를 보내려 할 때마다 개발자에게 티켓을 발행하고 배포를 기다려야 한다면, 마케팅의 골든타임은 이미 지나가 버립니다.

Solution: JSON 기반의 Self-Service (S3 Trigger)

우리는 “설정(Configuration)이 곧 실행(Action)이다”라는 컨셉을 도입했습니다. 복잡한 어드민 페이지 대신, 약속된 포맷의 JSON 파일을 AWS S3 버킷에 업로드하는 것만으로 모든 마케팅 액션이 트리거됩니다.

• 앱 배너 Live Ops: 마케터가 banner_config.json을 S3에 올리면, crm_box 람다가 즉시 트리거되어 DB를 갱신합니다. 앱 재배포 없이 실시간으로 운영이 가능합니다.
• 옴니채널 발송: 타겟 유저 리스트(target.json)를 S3에 넣으면, 람다가 유저별 최적 채널(알림톡/SMS/이메일)을 판별하여 메시지를 발송합니다.

이로써 마케팅 팀은 개발자의 일정에 구애받지 않고 스스로(Self-Service) 캠페인을 운영하는 ‘Marketing as Code’를 실현했습니다.

“개발자는 채널 연동 API만 유지보수합니다. 캠페인 운영은 마케터가 데이터(JSON)만 준비하면 끝나는 구조입니다. 이를 통해서 서버를 계속 유지할 필요도 없고 마케팅 요청에 아삽으로 지원할 필요도 없게 되었습니다.”

3. Pillar 2: 성공한 마케팅은 디도스(DDoS)와 같다

Challenge: 트래픽 스파이크의 공포

CRM 팀이 Braze를 통해 “전 국민 대상 푸시 발송” 버튼을 누르는 순간, 서버 개발자들은 긴장합니다. 수십만 명의 유저가 동시에 앱을 켜고 접속을 시도하기 때문입니다. 이러한 Traffic Spike는 예측이 불가능하며, 몇 초 만에 0에서 수만 RPS로 치솟아 메인 서비스를 마비시킬 수 있습니다.

Solution: 유연한 완충 지대 (Braze → API Gateway→ SQS → Lambda)

우리는 crm_box 내에 트래픽을 제어하는 댐(Dam)을 건설했습니다.

1. Ingest (API Gateway): Braze Webhook이나 앱의 마케팅 반응 요청을 가장 먼저 받아냅니다. 서버 관리 없이 무제한에 가까운 트래픽을 수용합니다.
2. Buffer (Amazon SQS): 받은 요청을 즉시 처리하지 않고 SQS(Queue)에 쌓습니다. 여기가 핵심입니다. SQS는 갑자기 밀려드는 요청을 안전하게 저장하여 뒷단 시스템을 보호합니다.
3. Process (Throttling): 람다 함수가 SQS에서 메시지를 하나씩 꺼내 처리합니다. 이때 **동시 실행 수(Concurrency)**를 조절하여, 레거시 DB나 API 서버가 감당할 수 있는 속도로만 요청을 흘려보냅니다.

결과적으로 마케팅 트래픽이 아무리 폭주해도, 메인 서비스는 평온함을 유지합니다.

4. Pillar 3: 룰(Rule)을 넘어 AI로 (Data & Intelligence)

자동화와 안정성 위에 ‘지능’을 더했습니다. 단순한 조건문(“20대 여성”)으로는 고객의 마음을 움직일 수 없기 때문입니다.

• Automated Data Pipeline: 운영 DB의 데이터는 매일 AWS 데이터 분석 계정으로 자동 적재(ETL)되어 데이터의 사일로(Silo) 현상을 막습니다.
• MLOps & Personalization: 머신러닝 모델이 “이탈할 것 같은 유저”, “성형 정보에 관심 있는 유저”를 예측하여 그룹핑합니다.
• Actionable Insight: 이 예측 데이터는 다시 crm_box와 Braze로 동기화되어, “이탈 고위험군에게만 할인 쿠폰 자동 발송”과 같은 정교한 시나리오를 가능하게 합니다.

5. Impact: 기술이 증명한 비즈니스 성과

이러한 crm_box 중심의 아키텍처는 단순한 ‘시스템 구축’을 넘어 놀라운 비즈니스 지표로 증명되었습니다.

• Performance: AI 모델 기반 타겟팅 캠페인의 경우, 기존 룰 베이스 대비 전환율(CVR) 13.4% 상승, 조회율(CTR) 6.5%, 결제 26.5% 상승
• Stability: 수백만 건의 대규모 푸시 발송 시에도 메인 서비스 다운타임 0% 달성
• Efficiency: 개발자 도움 없이 마케터가 스스로 배너를 수정하고 캠페인을 집행 (Time-to-Market 단축)

(참고: Ab180 Customer Case Studies — Babitalk)

마치며: Marketing Engineering

지금까지의 crm_box를 정리하면 다음과 같습니다. MarTech는 결과적으로 data에서 시작하여 channel로 끝나는 여정을 얼마나 데이터 기반으로 자동화하면서 그 정교함을 AI로 극대화할 수 있느냐로 정리할 수 있는 것 같습니다.

바비톡의 마케팅은 더 이상 ‘감’으로 하는 예술이 아닙니다. 데이터로 검증하고 기술로 실행하는 엔지니어링입니다.

우리는 crm_box를 통해 마케터에게는 강력한 무기를, 개발자에게는 평화로운 주말을 선물했습니다. 서버리스(Serverless)의 유연함과 데이터(Data)의 정확성으로 무장한 바비톡의 MarTech 도전은 계속됩니다.

마케팅이 기술을 만났을 때: 초자동화와 안정성을 모두 잡은 MarTech 마이크로서비스, crm_box was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

1편에서는 AI를 활용해 4개 레포지토리에 파편화된 비즈니스 로직을 분석하는 방법을 다뤘고, 2편에서는 테스트 코드를 자유롭게 작성할 수 있는 환경을 구축했습니다.

이제 본격적으로 테스트라는 안전망 위에서 레거시 코드를 리팩터링할 차례입니다. 이번 글에서는 하나의 버그 수정에서 출발해, AI와 함께 단계적으로 코드를 개선해 나간 실제 과정을 공유합니다.

단 하나의 API 엔드포인트를 리팩터링하는 과정이지만, 여기에 레거시 코드를 도메인 중심의 견고한 구조로 바꾸는 과정을 담았습니다.

모든 것은 간단한 버그 리포트에서 시작되었습니다.

“미리결제 후기가 블라인드 처리되었는데, 후기 사진 리스트에서는 여전히 노출됩니다”

블라인드된 리뷰의 이미지가 필터링되지 않는 버그였습니다. 수정 자체는 간단했지만, 해당 코드를 열어보니 문제의 규모가 보였습니다.

# 기존 코드: prepayment_events_detail.py
# 이 하나의 파일에 10개 이상의 API 클래스가 존재
class PrepaymentEventsReviewsBrief(Resource):
    @auth.check_token
    def get(self, prepayment_event_id):
        # 100줄이 넘는 하나의 메서드 안에:
        # - DB 쿼리 직접 실행
        # - 비즈니스 로직 처리
        # - 이미지 URL 변환
        # - 응답 데이터 조립
        # 모든 것이 한 곳에 혼재
        base_query = (
            db.session.query(BTPrepaymentEventReviewImage)
            .join(BTPrepaymentEventReview, ...)
            .filter(...)
        )
        total_image_count = base_query.count()
        # ... 100줄의 로직 ...
        return {"data": result}

여러분은 요즘 버그픽스를 어떻게 하시나요? 처음부터 눈으로 찾아가면 쉽지만, AI에게 에러 메시지를 붙여넣으면 바로 원인을 찾아줍니다. 물론 수정 후에 이 수정으로 인한 사이드이펙트가 있을지 확인하는것은 필수적입니다.

or_(
        BTPrepaymentEventReview.blind_type == BlindType.DEFAMATION_BLIND,
        BTPrepaymentEventReview.blind_type.is_(None),
    ),
)

이제 버그를 수정하는 것은 쉽지만, 이 코드가 계속 이 상태로 남아 있으면 같은 종류의 버그가 반복될 것이 분명했습니다. 하지만 덩어리진 코드를 함부로 건드리면 기존 동작이 깨질 수 있습니다.

우선 버그 수정 커밋은 오직 버그만 수정합니다. 리팩터링은 별도의 커밋으로 분리합니다. 이렇게 하면 문제가 생겼을 때 버그 수정과 리팩터링 중 어디서 문제가 발생했는지 명확하게 파악할 수 있습니다.

2. 테스트 코드로 안전망 구축

버그를 수정한 뒤, 리팩터링을 시작하기 전에 가장 먼저 한 일은 기존 동작을 보장하는 테스트 코드를 작성하는 것이었습니다. 2편에서 구축한 테스트 환경이 여기서 빛을 발합니다.

AI에게 다음과 같이 요청했습니다:

“이 API의 전체 응답값을 검증하는 테스트를 작성해줘. 이미지가 없는 경우, 이미지가 있는 경우, 블라인드된 리뷰가 제외되는 경우를 모두 커버해줘”

AI는 코드를 분석하여 모든 시나리오를 커버하는 테스트를 생성했습니다. 외부 의존성이 존재하는 코드들은 우선 mocking을 통해서 테스트를 돌아가게 해야합니다.

@pytest.mark.usefixtures("db_session")
class TestPrepaymentEventsReviewsBrief:
  def test_default_get(self, db_session, test_client, monkeypatch):
          """기본 미리결제 이벤트 후기 요약 조회 테스트 (이미지 없는 경우)"""
          # Given: 테스트 데이터 준비
          self._setup_base_data(db_session)
          with patch(
              'prepayment_events.prepayment_events_detail.PrepaymentReviewReport'
          ) as mock_review_report:
              mock_review_report.return_value.get_report_coupon_book_ids.return_value = []
              # When: API 호출
              result = test_client.get("prepayment_events/1/reviews/brief")
          # Then: 전체 응답 데이터 검증
          assert result.get_json() == {
              'data': {
                  'title': '실경험 인증 후기',
                  'sub_title': '미리결제로 구매하여,\\n실제 병원에서 시술받은 바비들의 후기입니다',
                  'review_count': 0,
                  'review_score': 0.0,
                  'total_image_count': 0,
                  'remain_image_count': None,
                  'images': None,
              }
          }
      def test_blinded_reviews_are_excluded(self, db_session, test_client):
          """블라인드 처리된 리뷰는 후기 이미지에서 제외되는지 검증"""
          # Given: 블라인드된 리뷰 포함 데이터 준비
          # When: API 호출
          # Then: 블라인드된 리뷰의 이미지는 응답에 포함되지 않음

여기서 중요한 포인트는 API의 전체 응답값을 비교하는 assert입니다. 단순히 status_code만 검증하는 것이 아니라, 응답의 모든 필드를 검증합니다. 하나의 테스트를 이렇게 만들어 놓으면:

• 회귀 테스트: 리팩터링 후에도 응답이 동일한지 자동으로 검증됩니다
• API 계약 보장: 클라이언트가 기대하는 응답 형식이 유지됩니다
• 비즈니스 로직 검증: 내부 구현이 바뀌어도 결과는 같아야 합니다

이 테스트가 통과하는 한, 안심하고 코드를 리팩터링 할 수 있습니다.

3. 클래스 분리: 단일 책임 원칙

테스트가 준비되었으니, 이제 본격적인 리팩터링을 시작합니다.

첫 번째 단계는 클래스를 별도 파일로 분리하는 것입니다. 기존에는 prepayment_events_detail.py 하나의 파일에 10개 이상의 API 클래스가 몰려 있었습니다.

AI에게 요청했습니다:

“PrepaymentEventsReviewsBrief 클래스를 별도 파일로 분리해줘. import 관계도 정리해줘"

AI는 import 의존성을 분석하여 안전하게 클래스를 분리했습니다.

Before:
prepayment_events/
  └── prepayment_events_detail.py  # 10개+ 클래스, 800줄+

After:
prepayment_events/
  ├── prepayment_events_detail.py          # 나머지 클래스들
  └── prepayment_events_reviews_brief.py   # 분리된 단일 클래스

분리 후 테스트를 실행합니다:

$ pytest tests/unit/prepayment_events/ -v
PASSED test_default_get
PASSED test_get_with_images
PASSED test_blinded_reviews_are_excluded

모든 테스트가 통과합니다. 테스트가 있으니 분리가 정상적으로 되었다는 것을 즉시 확인할 수 있습니다.

4. API 스키마 분리: Pydantic으로 계약 정의

다음 단계는 API의 요청/응답 스키마를 명시적으로 정의하는 것입니다. 기존 코드에서는 딕셔너리로 응답을 직접 조립하고 있었습니다:

# Before: 응답 구조가 코드 속에 숨어 있음
result = {
    "title": "실경험 인증 후기",
    "sub_title": "미리결제로 구매하여,\\n...",
    "review_count": prepayment_event.total_review_count,
    "images": images,  # 이 images의 구조는?
}
return {"data": result}

이 코드만 보고는 API 응답의 정확한 구조를 파악하기 어렵습니다. AI에게 기존 응답 구조를 분석하여 Pydantic 스키마로 변환해달라고 요청했습니다:

# After: Pydantic으로 명확한 응답 계약 정의
class ReviewImageSchema(BaseModel):
    type: str
    image: str
    small_image: str
    surgery: Optional[int]
    order: Optional[int]
    scheme: str

class ImagesSchema(BaseModel):
    data: List[ReviewImageSchema]

class PrepaymentEventsReviewsBriefResponse(BaseModel):
    title: str
    sub_title: str
    review_count: int
    review_score: float
    total_image_count: int
    remain_image_count: Optional[int]
    images: Optional[ImagesSchema]

class PrepaymentEventsReviewsBriefApiResponse(BaseModel):
    data: PrepaymentEventsReviewsBriefResponse

FastAPI와 연동되는 Pydantic으로 작성된 스키마를 정의하면:

• API의 요청/응답 구조를 코드 자체가 문서가 됩니다
• 향후 Swagger 연동 시 바로 활용할 수 있습니다
• 타입 검증이 자동으로 이루어집니다

또한 이미지 처리 로직도 별도 함수로 분리했습니다:

def create_images_schema(review_images):
    """후기 이미지 리스트를 ImagesSchema로 변환"""
    if not review_images:
        return None
    image_list = []
        for image in review_images:
            image_schema = ReviewImageSchema(
                type="raw.image",
                image=make_image_url(image.url),
                small_image=make_image_url(image.url, size="small"),
                surgery=image.surgery,
                order=image.order,
                scheme=PrepaymentEventsScreen.reviews_images_scheme(
                    review_id=image.review_id,
                    query_parameter=f"?order={image.order}&all_review=1",
                ),
            )
            image_list.append(image_schema)
        return ImagesSchema(data=image_list) if image_list else None

UI 표현 로직을 분리하면, 비즈니스 로직의 재사용성이 높아지고 UI 변경이 비즈니스 로직에 영향을 주지 않습니다.

5. 서비스 레이어 분리

이제 핵심입니다. API 컨트롤러에 혼재되어 있던 비즈니스 로직을 서비스 레이어로 분리합니다.

AI에게 다음과 같이 요청했습니다:

“현재 get 메서드에 있는 비즈니스 로직을 서비스 클래스로 추출해줘. DTO를 만들어서 서비스와 뷰 사이의 데이터 전달을 명확하게 해줘”

DTO(Data Transfer Object) 도입

서비스와 뷰 사이에 데이터를 전달하기 위한 불변 객체를 정의합니다:

@dataclass(frozen=True)
class PrepaymentEventReviewBriefDTO:
    prepayment_event: BTPrepaymentEvent
    total_image_count: int
    remain_image_count: Optional[int]
    review_images: List[BTPrepaymentEventReviewImage]

서비스 클래스

# Before: API 메서드 안에 비즈니스 로직이 100줄+
class PrepaymentEventsReviewsBrief(Resource):
    def get(self, prepayment_event_id):
        # DB 쿼리 + 비즈니스 로직 + 응답 조립이 모두 여기에...


# After: 서비스 클래스에서 비즈니스 로직만 담당
class PrepaymentEventReviewBriefService:
    def get_review_brief_data(
        self,
        prepayment_event_id: int,
        blocked_user_list: List[int],
        report_coupon_book_ids: List[int],
    ) -> PrepaymentEventReviewBriefDTO:
        """후기 요약 데이터를 조회하고 DTO로 반환"""
        prepayment_event = self.__prepayment_repository.get_prepayment_event_by_id(
            prepayment_event_id
        )
        total_image_count = self.__prepayment_repository.get_review_image_total_count(
            prepayment_event_id, blocked_user_list, report_coupon_book_ids
        )
        review_images = []
        remain_image_count = None
        if total_image_count > 0:
            review_images = self.__prepayment_repository.get_representative_review_images(
                prepayment_event_id, blocked_user_list, report_coupon_book_ids
            )
            review_image_count = self.__prepayment_repository.get_representative_review_image_count(
                prepayment_event_id, blocked_user_list, report_coupon_book_ids
            )
            if total_image_count > 10 and review_image_count > 10:
                remain_image_count = self.__prepayment_repository.get_remain_review_image_count(
                    prepayment_event_id, blocked_user_list, report_coupon_book_ids
                )
        return PrepaymentEventReviewBriefDTO(
            prepayment_event=prepayment_event,
            total_image_count=total_image_count,
            remain_image_count=remain_image_count,
            review_images=review_images,
        )

API 컨트롤러는 이제 요청/응답 처리에만 집중합니다:

class PrepaymentEventsReviewsBrief(Resource):
    def get(self, prepayment_event_id):
        # 1. 요청 파싱
        user_context = PrepaymentEventsReviewsBriefRequest.from_request()

        # 2. 서비스 호출  
        report_ids = review_report_service.get_report_coupon_book_ids(user_context.user_id)
        review_data = review_brief_service.get_review_brief_data(
            prepayment_event_id, user_context.blocked_user_list, report_ids
        )
        # 3. 응답 조립
        images = create_images_schema(review_data.review_images)
        response = PrepaymentEventsReviewsBriefResponse(
            title="실경험 인증 후기",
            review_count=review_data.prepayment_event.total_review_count,
            total_image_count=review_data.total_image_count,
            images=images,
            # ...
        )
        return PrepaymentEventsReviewsBriefApiResponse(data=response).model_dump()

각 레이어의 역할이 명확해졌습니다:

• View: HTTP 요청/응답 처리, 인증/권한 확인
• Service: 비즈니스 로직, 도메인 규칙 적용
• Repository: 데이터 접근 (다음 단계에서 도입)

6. DI 컨테이너와 Repository 패턴 도입

마지막 단계입니다.

수년간 기능이 쌓이면서 서비스 클래스들의 외부 의존성이 덕지덕지 붙어갔고, 이를 정리할 수단으로 DI를 실험적으로 도입했습니다. 전체를 한 번에 바꾸는 게 아니라, 의존성 분리가 필요한 지점부터 점진적으로 적용해나가는 방식입니다.

서비스 클래스가 db.session을 직접 참조하고 있던 것을 Repository 패턴으로 추상화하고, DI(Dependency Injection) 컨테이너로 의존성을 관리합니다.

Repository 패턴: 데이터 접근 추상화

# 인터페이스 정의
class IPrepaymentRepository(ABC):
    @abstractmethod
    def get_prepayment_event_by_id(
        self, prepayment_event_id: int
    ) -> Optional[BTPrepaymentEvent]:
        pass

    @abstractmethod  
    def get_review_image_total_count(
        self, prepayment_event_id: int, blocked_user_list: List[int],
        report_coupon_book_ids: List[int]
    ) -> int:
        pass
    # ...

# 구현체
class PrepaymentRepository(IPrepaymentRepository):
    def __init__(self, session):
        self.session = session
    def get_review_image_total_count(self, ...):
        return self._get_base_review_image_query(...).count()
    def _get_base_review_image_query(self, prepayment_event_id, blocked_user_list, report_coupon_book_ids):
        """공통 필터링 쿼리를 중앙화"""
        return (
            self.session.query(BTPrepaymentEventReviewImage)
            .join(BTPrepaymentEventReview, ...)
            .filter(
                BTPrepaymentEventReview.prepayment_event_id == prepayment_event_id,
                BTPrepaymentEventReview.coupon_book_id.notin_(report_coupon_book_ids),
                BTPrepaymentEventReview.user_id.notin_(blocked_user_list),
                # 블라인드 필터링도 여기서 일괄 처리
            )
        )

기존에 API 메서드 곳곳에 흩어져 있던 쿼리 로직이 Repository에 중앙화되었습니다. _get_base_review_image_query라는 공통 메서드로 필터링 조건을 한 곳에서 관리하기 때문에, 블라인드 필터링 같은 조건을 추가할 때도 한 곳만 수정하면 됩니다.

DI 컨테이너 설정

# configs/Container.py
class Container(containers.DeclarativeContainer):
    config = providers.Configuration()
    db_session = providers.Factory(lambda: db.session())

    # Repository
    prepayment_repository = providers.Factory(
        PrepaymentRepository, session=db_session
    )
    # Services
    prepayment_review_report_service = providers.Singleton(
        PrepaymentReviewReportService, prepayment_repository=prepayment_repository
    )
    prepayment_review_brief_service = providers.Singleton(
        PrepaymentEventReviewBriefService, prepayment_repository=prepayment_repository
    )

@inject 데코레이터로 의존성 주입

class PrepaymentEventsReviewsBrief(Resource):
    @auth.check_token
    @inject
    def get(
        self,
        prepayment_event_id: int,
        review_report_service: PrepaymentReviewReportService = Provide[
            Container.prepayment_review_report_service
        ],
        review_brief_service: PrepaymentEventReviewBriefService = Provide[
            Container.prepayment_review_brief_service
        ],
    ):
        # 서비스들이 DI 컨테이너에서 자동으로 주입됨

테스트 코드가 간결해지다

DI 도입의 가장 체감되는 변화는 테스트 코드의 간소화입니다:

# Before: 복잡한 패치와 목킹 필요
with patch(
    'prepayment_events.prepayment_events_detail.PrepaymentReviewReport'
) as mock:
    mock.return_value.get_report_coupon_book_ids.return_value = []
    result = test_client.get("prepayment_events/1/reviews/brief")

# After: 의존성이 분리되어 단순한 API 호출만으로 테스트 가능
result = test_client.get("prepayment_events/1/reviews/brief")

기존에는 테스트 대상 코드가 다른 API 클래스를 직접 참조하고 있어서 복잡한 목킹이 필요했습니다. DI를 통해 의존성을 분리하니, 테스트 환경에서는 테스트용 의존성이 자동으로 주입되어 테스트 코드가 비즈니스 로직 검증에만 집중할 수 있게 되었습니다.

7. 리팩터링 전후 비교

코드 구조 변화

# Before:
prepayment_events/
  └── prepayment_events_detail.py    # 800줄+, 10개 API 클래스와 비즈니스 로직 혼재

# After:
prepayment_events/
  ├── prepayment_events_detail.py                    # 나머지 API들
  ├── prepayment_events_reviews_brief.py             # View (요청/응답 처리)
  ├── services/
  │   ├── prepayment_event_review_brief_service.py   # Service (비즈니스 로직)
  │   └── prepayment_review_report_service.py        # Service (리포트 로직)
  ├── repository.py                                  # Repository (데이터 접근)
  └── base.py                                        # Repository 인터페이스

각 레이어의 역할

레이어 역할 의존성 View HTTP 요청/응답, 인증, 스키마 변환 Service Service 비즈니스 로직, 도메인 규칙 Repository Repository DB 쿼리, 데이터 접근 추상화 DB Session

핵심 개선 지표

항목 Before After API 메서드 길이 100줄+ 20줄 비즈니스 로직 위치 API 메서드 내부 전용 서비스 클래스 DB 쿼리 위치 API 메서드 내부 Repository로 추상화 응답 스키마 딕셔너리 직접 조립 Pydantic 모델 테스트 목킹 복잡한 패치 필요 DI로 자동 주입 블라인드 필터링 쿼리마다 직접 추가 Repository에서 중앙 관리

8. AI와 함께한 리팩터링, 무엇이 달랐나

이번 리팩터링의 모든 단계에서 AI가 핵심적인 역할을 했습니다. 각 단계에서 AI가 도운 것들을 정리하면:

• 테스트 코드 작성: 기존 API의 응답 구조를 분석하여 모든 시나리오를 커버하는 테스트를 생성
• 클래스 분리: import 의존성을 분석하여 안전하게 클래스를 별도 파일로 분리
• Pydantic 스키마 생성: 기존 딕셔너리 응답을 분석하여 타입이 정의된 스키마로 자동 변환
• 서비스/Repository 생성: 비즈니스 로직을 서비스로 추출하고, 쿼리 로직을 Repository로 분리
• DI 설정: Container 설정, 와이어링, @inject 데코레이터 적용
• 테스트 업데이트: 매 단계마다 변경된 구조에 맞게 테스트 코드를 업데이트

개발자가 한 일은 아키텍처 방향을 결정하고, AI의 결과물을 검증하는 것이었습니다. “서비스 레이어로 분리해줘”, “Repository 패턴을 도입해줘”와 같이 방향을 지시하면, AI가 기존 코드를 분석하여 구조를 변환하고, 테스트 코드까지 업데이트합니다.

특히 레거시 코드처럼 복잡한 의존성이 얽힌 코드를 리팩터링할 때 AI의 가치가 극대화됩니다. 사람이 100줄짜리 메서드에서 어떤 부분이 비즈니스 로직이고, 어떤 부분이 데이터 접근이며, 어떤 부분이 응답 조립인지 분류하는 데는 상당한 시간과 집중력이 필요합니다. AI는 이 분류를 빠르고 정확하게 수행합니다.

단, 중요한 전제가 있습니다. 테스트 코드가 있어야 AI의 리팩터링 결과를 신뢰할 수 있습니다. AI가 아무리 잘 분리해도, 기존 동작이 유지되는지는 테스트로 검증해야 합니다. 2편에서 구축한 테스트 환경이 없었다면, 이 리팩터링은 불가능했을 것입니다.

9. 다음 단계: AI 워크플로우 자동화

이 시리즈에서 다룬 분석 → 테스트 → 리팩터링의 전 과정에서 AI는 단순한 도구를 넘어 개발 파트너로 활약했습니다. 그런데 여기서 한 가지 의문이 생깁니다. 매번 같은 맥락을 AI에게 처음부터 설명해야 할까요?

답은 skills와 agent 파일로 자동화하는 것입니다.

과정에서 얻은 지식을 재사용 가능한 자산으로

1편에서 4개 레포지토리의 비즈니스 로직을 분석하면서, 그동안 몰랐던 도메인 지식들이 대량으로 발견되었습니다. 이런 발견들을 단순히 머릿속에 남겨두는 것이 아니라, AI가 참조할 수 있는 문서와 규칙 파일로 체계화할 수 있습니다. 다음에 같은 도메인을 다룰 때, AI가 이 문서를 컨텍스트로 활용하면 분석 단계를 크게 단축할 수 있습니다.

2편에서 구축한 테스트 환경과 작성 패턴(Given-When-Then, factory 패턴, fixture 설계 등)은 테스트 코드 작성용 skill 파일로 만들 수 있습니다. “이 프로젝트에서 테스트를 작성할 때는 이런 패턴을 따라”라고 AI에게 알려주면, 일관된 품질의 테스트 코드가 자동으로 생성됩니다.

3편의 리팩터링 패턴(SRP, 서비스 레이어, Repository, DI)도 마찬가지입니다. 프로젝트의 아키텍처 규칙을 agent 파일에 정의해두면, AI가 새로운 코드를 작성하거나 기존 코드를 수정할 때 자동으로 이 규칙을 따릅니다.

AI 시대의 문서화

과거에는 문서화가 번거로운 추가 작업이었습니다. 하지만 AI와 함께라면 작업 과정 자체가 문서화됩니다. 코드를 분석하며 나눈 대화, 리팩터링하며 정한 규칙들을 AI가 정리하여 문서로 만들어줍니다. 문서화의 비용이 획기적으로 낮아진 것입니다.

이제는 “문서화할 시간이 없다”가 아니라, **”문서화하지 않을 이유가 없다”**는 시대입니다. 그리고 그 문서들이 다시 AI의 컨텍스트가 되어, 더 정확하고 일관된 결과를 만들어내는 선순환이 시작됩니다.

분석 → 문서화 → skills/agent 파일 → AI 자동화 → 더 나은 분석 → ...

마무리

하나의 버그 수정에서 시작해, 7개의 커밋을 거쳐 레거시 코드를 견고한 구조로 탈바꿈시켰습니다.

버그 수정 → 테스트 작성 → 클래스 분리 → 스키마 정의 → 서비스 분리 → 구조 개선 → DI 도입

이 과정에서 얻은 가장 중요한 교훈은 ”리팩터링은 한 번에 하는 것이 아니라, 작은 단계를 반복하는 것” 이라는 점입니다. 각 단계마다 테스트를 실행하여 기존 동작이 유지되는지 확인하고, 문제가 없으면 다음 단계로 넘어갑니다.

AI는 이 반복 과정에서 강력한 파트너입니다. 방향을 정해주면 코드 분석, 구조 변환, 테스트 업데이트를 빠르게 수행합니다. 하지만 AI에게 자신감을 주는 것은 결국 테스트 코드입니다. 테스트라는 안전망이 있기에 AI도, 개발자도 과감하게 코드를 바꿀 수 있습니다.

레거시 코드 앞에서 막막함을 느끼고 있다면, 이 글이 도움이 되었으면 합니다. 시작은 작은 버그 수정이었지만, 끝은 도메인 중심의 견고한 아키텍처였습니다.

[시리즈]

• 1편: AI와 함께한 레거시 탈출: 파편화된 비즈니스 로직 꿰뚫기
• 2편: AI와 함께한 레거시 탈출: 안전망 깔기 (pytest 도입기)
• 3편: 기술 부채 청산: AI와 함께 도메인 중심의 견고한 코드로 리팩터링하기 ← 현재 글

AI와 함께한 레거시 탈출: 테스트라는 용기로 레거시를 해체하기 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI로 코드를 작성하는 시대가 되면서 테스트코드가 더 중요해지고 있습니다. 테스트코드를 먼저 작성하고 테스트코드가 통과할 때까지 코드를 고치는 TDD 방법이 AI 도구를 통해서 코딩을 할 때 이전보다 훨씬 안정성을 더해주죠. 이전 포스팅에서 말씀드렸듯, 바비톡의 레거시 서버는 Python 기반의 Django, Flask로 되어있습니다.

프레임워크 역할 ORM Flask 앱 API 서버 SQLAlchemy Flask 배치/크론 서버 SQLAlchemy Django 병원 관리자 서버 Django ORM Django 운영 관리자 서버 Django ORM

이 4개 프로젝트 모두 테스트코드가 전무한 상태에서 출발해 pytest 기반의 테스트 환경을 구축한 과정을 공유합니다.

1. 공통 전략

• SQLite 인메모리 데이터베이스를 테스트 DB로 사용합니다.
• 가볍고, 의존성이 없는 테스트 환경을 구축할 수 있습니다.
• pytest를 사용합니다.
• Django 프로젝트의 경우 pytest-django를 추가로 설치해야 합니다. Django의 DB 트랜잭션 관리, 설정 파일 연동 등을 pytest에서 자연스럽게 쓸 수 있게 해주는 플러그인입니다.
• pytest를 설치한 후 간단한 테스트코드를 생성해서 실행시켜 보면서 의존성 문제를 먼저 해결하는 것이 좋습니다.
• pytest 설치 → 테스트코드 없이 pytest 명령어를 돌려서 시스템 의존성 문제 확인 (import 문제 등)
• 간단한 테스트코드 작성 후 pytest 실행 → 코드 의존성 확인 및 제거

2. 시스템 의존성 제거하기

서버를 정상적으로 실행할 때는 오류가 안 나는데, 테스트코드를 실행시키면 오류가 나는 경우가 있습니다. 일반적으로 main 함수로 서버를 돌릴 때와는 실행 순서가 달라져서 순환참조 같은 의존성 문제가 발생하는 것인데요, 이를 위해 테스트 환경 설정을 먼저 잡아줘야 합니다.

핵심은 conftest.py입니다. pytest가 테스트를 실행하기 전 가장 먼저 로드하는 파일이기 때문에, 여기서 외부 의존성을 차단하고 테스트 환경을 구성합니다.

# conftest.py (Flask 프로젝트 예시)
import os, sys
from unittest.mock import MagicMock, patch
os.environ['APP_ENV'] = 'testing'
os.environ['AUTH_BYPASS'] = 'true'
# ... 기타 환경변수 설정
sys.modules['DB.orm_config'] = MagicMock()
sys.modules['DB.elasticsearch'] = MagicMock()
sys.modules['utils.aws_handler'] = MagicMock()
sys.modules['utils.datadog_apm'] = MagicMock()

Django 프로젝트의 경우, 프레임워크 자체가 설정 파일 기반으로 동작하기 때문에 settings_test.py를 분리하는 방식으로 같은 목적을 달성합니다.

# settings_test.py (Django 프로젝트 예시)
from babitalk_admin_backend.settings import *

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": ":memory:",
    },
}
# 멀티 DB 라우터 비활성화 (테스트에서는 단일 DB 사용)
DATABASE_ROUTERS = []
REPLICA_DATABASES = []
# 인증/권한 체크 비활성화
REST_FRAMEWORK = {
    **REST_FRAMEWORK,
    "DEFAULT_PERMISSION_CLASSES": ["rest_framework.permissions.AllowAny"],
    "DEFAULT_AUTHENTICATION_CLASSES": [],
}
# 외부 서비스 비활성화
DATADOG_TRACE = {'ENABLED': False}

방식은 다르지만 목적은 같습니다: 프로덕션 리소스에 접근하지 않고, 외부 의존성을 차단하는 것.

3. 테스트 DB 구성

기본적으로 테스트코드는 아래와 같은 흐름으로 실행됩니다.

1. 서버에 의존하는 모든 테이블 생성
2. 테스트코드에 의존하는 데이터 생성
3. 테스트코드에서 데이터 조회 및 생성
4. 데이터가 일치하는지 확인

여기서 1번, 테이블을 생성하는 방법이 프레임워크마다 다릅니다.

Flask + SQLAlchemy에서는 fixture로 SQLite 인메모리 엔진을 만들고, 모델의 메타데이터로부터 테이블을 직접 생성합니다.

# conftest.py
@pytest.fixture(scope='class')
def db_engine(app):
    """클래스 단위로 공유되는 데이터베이스 엔진"""
    with app.app_context():
        engine = create_engine("sqlite:///:memory:", echo=False)
        db.metadata.create_all(bind=engine)
        yield engine
        engine.dispose()

바비톡에서 사용하는 Django에서는 한 가지 더 넘어야 할 허들이 있습니다. 바비톡의 Django 모델은 기존 MySQL 테이블을 참조만 하는 구조라 managed=False로 선언되어 있습니다. 이 설정은 Django에게 "이 모델의 테이블은 Django가 관리하지 않는다"는 뜻이기 때문에, 테스트 DB를 만들 때도 해당 모델의 테이블이 생성되지 않습니다. 마이그레이션 파일도 없고, 테이블 자동 생성도 안 되는 상황인 거죠.

이를 해결하기 위해 conftest.py에 세션 스코프 fixture를 작성했습니다. 테스트 시작 시점에 모든 managed=False 모델을 찾아 managed=True로 변경하고, 테이블을 직접 생성합니다.

# conftest.py
@pytest.fixture(scope="session", autouse=True)
def enable_db_access_for_all_unmanaged_models(django_db_setup, django_db_blocker):
    """
    테스트 실행 시 모든 unmanaged 모델(managed=False)을 managed=True로 변경.
    이렇게 하면 테스트 DB에 테이블이 생성됩니다.
    """
    from django.apps import apps
    with django_db_blocker.unblock():
            from django.db import connection
            unmanaged_models = []
            for model in apps.get_models():
                if not model._meta.managed:
                    model._meta.managed = True
                    unmanaged_models.append(model)
            # 테이블 생성
            with connection.schema_editor() as schema_editor:
                for model in unmanaged_models:
                    try:
                        schema_editor.create_model(model)
                    except Exception:
                        pass  # 이미 존재하는 경우 무시

autouse=True이기 때문에 모든 테스트에 자동으로 적용되고, scope="session"이라 전체 테스트 세션에서 한 번만 실행됩니다. 프로덕션 코드의 managed=False는 건드리지 않고, 테스트 런타임에서만 동적으로 변경하는 것이 포인트입니다.

여기에 pytest-django의 --nomigrations 플래그를 함께 사용합니다. 마이그레이션 파일 자체가 존재하지 않기 때문에, 이 플래그로 마이그레이션 단계를 건너뛰고 모델 클래스의 필드 정의를 직접 읽어 테이블을 생성하도록 합니다.

# pytest.ini
[pytest]
DJANGO_SETTINGS_MODULE = babitalk_admin_backend.settings_test
addopts = --nomigrations

4. 테스트 데이터 팩토리

테이블이 생성되면 다음은 테스트에 필요한 데이터를 만드는 과정입니다. “given, 이러한 데이터가 있을 때, 함수를 실행시키면, 어떠한 결과가 나와야 한다” — 여기서 “이러한 데이터가 있을 때”의 조건을 만들 때 사용됩니다.

레거시 모델들은 필드 수가 수십 개에 달하는 경우가 많습니다. 테스트마다 모든 필드를 일일이 채워야 한다면 테스트코드의 복잡성만 늘어나겠죠. 그래서 각 모델마다 기본값이 채워진 팩토리를 만들어두고, 테스트에서는 필요한 필드만 오버라이드하여 사용합니다.

Flask 프로젝트에서는 make_user(), make_hospital() 같은 팩토리 함수를 직접 작성했고, Django 프로젝트에서는 factory_boy의 DjangoModelFactory를 활용했습니다.

# Django - factory_boy 예시
class BtEventFactory(DjangoModelFactory):
    class Meta:
        model = BtEvent
        cid = 123
        hid = 1
        text = 'Default Event Description'
        tim = factory.LazyFunction(get_naive_now)
        # ... 각 필드의 기본값 정의

AI를 활용하면 모델 정의를 기반으로 Factory를 빠르게 생성할 수 있어 큰 부담 없이 만들 수 있었습니다.

5. 실제 테스트 코드 (Given-When-Then)

환경이 갖춰지면, 실제 테스트 코드는 Given-When-Then 패턴으로 간결하게 작성할 수 있습니다.

# Flask 프로젝트 예시
@pytest.mark.usefixtures("db_session")
class TestPrepaymentReviewService:
    def test_get_review_and_event_info_no_mapping(self, db_session):
        """맵핑된 일반 이벤트가 없을 때 미리결제 이벤트 정보를 올바르게 반환하는지 테스트"""
        # given: make_xxx() 함수로 테스트 객체 생성
        user = make_user(id=1, name="test_user")
        hospital = make_hospital(id=1, name="테스트 병원")
        prepayment_event = make_prepayment_event(
            id=101, client_id=1, hospital_id=1,
            name="오리지널 미리결제 이벤트", matching_event_id=None,
        )
        review = make_prepayment_event_review(
            id=1001, user_id=user.id, prepayment_event_id=prepayment_event.id,
        )
        db_session.add_all([user, hospital, prepayment_event, review])
        db_session.commit()
# when: 서비스 메소드 호출
        service = PrepaymentReviewService()
        review_result, event_data = service.get_review_and_event_info(
            review_id=review.id, user_id=user.id
        )
        # then: 결과 검증
        assert review_result.id == review.id
        assert event_data["data"]["name"] == "오리지널 미리결제 이벤트"

# Django 프로젝트 예시
@pytest.mark.django_db
def test_create_category(api_client, mocker):
    """카테고리 생성 API가 SQLite 테스트 DB에서 정상 동작하는지 검증"""
    # given: 외부 의존성 Mock 처리 후 테스트 데이터 준비
    dummy_redis = mocker.Mock()
    mocker.patch("api.category.service.redis", dummy_redis)
    parent = Category.objects.create(
        id=1, name="Parent Category", type=1, parent=None, order=0, depth=0,
    )
    # when: API 호출
        payload = {
            "id": 2, "name": "Child Category", "type": 1,
            "parent_id": parent.id, "order": 1, "depth": 1,
        }
        response = api_client.post("/categories/", data=payload, format="json")
        # then: 응답 및 DB 상태 검증
        assert response.status_code == 201
        assert response.json() == {"message": "카테고리가 생성되었습니다."}
        child = Category.objects.get(id=2)
        assert child.name == "Child Category"
        assert child.parent_id == parent.id

Django에서는 @pytest.mark.django_db 데코레이터만 추가하면 테스트마다 독립된 트랜잭션이 자동으로 보장됩니다. Flask에서는 db_session fixture를 통해 직접 세션을 관리해야 하는 차이가 있지만, 테스트 코드 자체의 구조는 동일합니다.

6. CI/CD 통합: GitHub Actions

테스트 코드를 작성하는 것만으로는 충분하지 않습니다. 코드가 배포되는 환경에서 기존 테스트가 항상 통과하는지 자동으로 확인해야 합니다. 그렇지 않으면 테스트가 깨진 채로 머지되거나, 아무도 테스트를 실행하지 않게 됩니다. GitHub Actions를 통한 CI 연동은 선택이 아니라 필수입니다.

기본적인 흐름은 checkout → Python 설정 → 의존성 캐싱 → 테스트 실행 → 커버리지 코멘트입니다. push 시에는 테스트만, PR 시에는 커버리지 리포트까지 생성하도록 분기합니다. py-cov-action/python-coverage-comment-action을 사용하면 PR에 커버리지 코멘트를 자동으로 달 수 있습니다.

이렇게 설정하면:

• PR을 올릴 때마다 자동으로 전체 테스트가 실행됩니다
• 커버리지 리포트가 PR 코멘트로 표시됩니다
• 테스트가 실패하면 머지가 차단됩니다

7. 마주친 문제들과 해결법

MySQL 종속성 제거

테스트 환경을 구축하면서 가장 많이 마주친 문제는 MySQL에 종속된 스키마와 코드였습니다. SQLite에서 테스트를 돌리려면 이 종속성을 제거해야 했고, 실제로 상당한 양의 모델 수정이 필요했습니다.

MySQL 전용 데이터 타입을 표준 타입으로 변경:

# Before: MySQL 전용 타입
text: Mapped[str] = mapped_column(db.Text(collation="utf8mb4_unicode_ci"))
bulk_reporter: Mapped[int] = mapped_column(TINYINT)
story: Mapped[str] = mapped_column(MEDIUMTEXT)

# After: 표준 타입으로 통일
text: Mapped[str] = mapped_column(db.Text)
bulk_reporter: Mapped[int] = mapped_column(db.SmallInteger)
story: Mapped[str] = mapped_column(db.Text)

SQLite에서 중복 불가능한 인덱스명 개선:

SQLite는 데이터베이스 전체에서 인덱스명이 유일해야 합니다. MySQL에서는 테이블 단위로 인덱스명이 관리되기 때문에 "cid_2", "suid" 같은 모호한 이름이 허용되지만, SQLite에서는 충돌합니다.

# Before: 모호하고 중복 가능한 인덱스명
db.Index("cid_2", "cid", "mid")
db.Index("suid", "suid", "duid")

# After: 테이블명을 포함한 명확한 인덱스명
db.Index("idx_bt_backuped_model_cid_mid", "cid", "mid")
db.Index("idx_bt_memo_suid_duid", "suid", "duid")

복합 PrimaryKey를 UniqueKey로 변경:

# Before: 복합 PrimaryKey
class BTBanner(db.Model):
    __tablename__ = "BT_Banner"
    __table_args__ = (
        UniqueConstraint("id", "isall"),
    )
    id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True)
    isall = db.Column(db.Integer, nullable=False, primary_key=True)  # 복합 PK

# After: 단일 PrimaryKey + UniqueConstraint
class BTBanner(db.Model):
    __tablename__ = "BT_Banner"
    __table_args__ = (
        UniqueConstraint("id", "isall", name="uq_bt_banner_id_isall"),
    )
    id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True)
    isall = db.Column(db.Integer, nullable=False)  # primary_key=True 제거

SQLite는 복합 PrimaryKey를 지원하지 않기 때문에, id 컬럼에 PrimaryKey를 걸고 기존 복합키는 UniqueConstraint로 변경했습니다.

이런 작업은 단순히 테스트를 통과시키기 위한 조치가 아닙니다. ORM을 사용하는 이유 중 하나가 DB 벤더 독립성인데, MySQL 전용 타입이나 문법을 사용하면 그 이점을 스스로 포기하는 셈입니다. 테스트 환경 구축은 이런 숨어있던 종속성을 발견하고 정리하는 좋은 기회였습니다.

멀티 데이터베이스 라우터

프로덕션에서는 읽기/쓰기 DB가 분리되어 있지만, 테스트에서는 단일 SQLite DB를 사용합니다. Django에서는 DATABASE_ROUTERS = []로 라우터를 비활성화하고, Flask에서는 slave_session도 같은 세션으로 교체했습니다.

8. 중요한 것들

완벽한 환경보다 돌아가는 환경이 먼저

처음부터 높은 커버리지를 목표로 하지 않았습니다. 먼저 pytest가 에러 없이 실행되는 환경을 만드는 것에 집중했고, 이후 하나씩 테스트를 추가해나갔습니다.

레거시 코드의 테스트는 격리가 핵심

10년 가까이 운영된 코드베이스에는 수많은 외부 의존성이 얽혀 있습니다. 이 모든 것을 실제로 연결하려 하면 끝이 없습니다. 대신 외부 의존성을 철저히 Mock/Fake로 교체하고, 비즈니스 로직만 집중적으로 테스트하는 전략을 택했습니다.

GitHub Actions로 안전장치 만들기

이렇게 테스트 환경을 구축한 뒤에 꼭 중요한 것이 있습니다. 새로운 코드를 추가할 때마다 테스트를 돌려봐야 한다는 것이죠. 그런데 사람이 하는 일이다 보니 놓칠 수도 있고, 검증 없이 커밋하는 경우도 생깁니다. 그래서 GitHub Actions로 안전장치를 꼭 구축해놔야 합니다. PR마다 자동으로 테스트가 돌고, 실패하면 머지가 차단되도록 설정하면 검증을 빠뜨릴 일이 없습니다.

마무리

4개 프로젝트에 테스트 환경을 구축하면서 느낀 점은, 테스트 환경 구축 자체가 코드베이스에서 의존성 문제를 확인할 수 있다는 점입니다.

하지만 한번 구축되면, 이후의 개발 속도와 안정성은 확연히 달라집니다. 새로운 기능을 추가할 때 기존 코드가 깨지지 않는지 자동으로 확인할 수 있고, 리팩토링도 자신감 있게 진행할 수 있습니다. 실제로 다음 편에서 다룰 대규모 리팩토링은 이 테스트 환경이 없었다면 시도조차 하기 어려웠을 것입니다.

레거시 프로젝트에 테스트를 도입하는 것은 쉽지 않지만, 가장 가치 있는 기술 부채 상환 중 하나입니다.

다음 글에서는 이렇게 구축한 테스트 환경을 기반으로, AI를 활용해 레거시 코드를 도메인 중심의 견고한 구조로 리팩터링한 과정을 공유합니다. 테스트 코드라는 안전망 위에서 어떻게 자신감 있게 코드를 바꿔나갔는지, 그 여정을 함께 살펴보겠습니다.

[시리즈]

• 1편: AI와 함께한 레거시 탈출: 파편화된 비즈니스 로직 꿰뚫기
• 2편: AI와 함께한 레거시 탈출: 안전망 깔기 (pytest 도입기) ← 현재 글
• 3편: AI와 함께한 레거시 탈출: 테스트라는 용기로 레거시를 해체하기

AI와 함께한 레거시 탈출: 안전망 깔기 (pytest 도입기) was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

여러분들은 AI를 실무에서 어떻게 활용하고 계신가요? 백엔드 개발자라면 최근 실무 환경이 놀라울 정도로 편해졌음을 체감하고 계실 겁니다. 모든 비즈니스 로직이 백엔드에 집중되어 있기 때문에, 아무리 복잡하고 사람이 읽기 어려운 레거시 코드일지라도 AI가 그 맥락을 정확하게 파악해주기 때문입니다.

바비톡은 현재 MSA(Microservice Architecture)로의 전환이라는 중요한 기술적 도전을 진행하고 있습니다. 이 과정에서 우리는 어쩔 수 없이 이전의 레거시 코드와 마주해야 합니다.

2. 바비톡의 도전: 비즈니스의 세 축을 잇는 4개의 레포지토리

바비톡의 비즈니스는 사용자, 병원, 그리고 플랫폼(바비톡)이라는 세 축을 중심으로 돌아갑니다. 하지만 이를 뒷받침하는 기존 코드는 특별한 아키텍처 없이 빠르게 구현하는 데 집중했던 Django 기반의 레거시로 이뤄져 있습니다. 하나의 클래스에 모든 비즈니스 로직과 DB 연결까지 포함된 거대한 코드들이 주요 네 개의 레포지토리에 분산되어 있죠.

• App: 모바일 앱에서 사용하는 API를 담당하는 서버.
• Client: 병원 관계자들이 사용하는 관리자 페이지.
• Admin: 바비톡 운영팀(직원)이 사용하는 내부 관리 도구 및 정산 로직.
• Cron: 주기적인 데이터 계산 및 배치 스크립트가 모여있는 레포지토리.

정책 하나를 파악하려면 이 네 개의 레포지토리를 모두 확인 해봐야 합니다. 신규 입사자에게는 그야말로 거대한 미로와 같았습니다. 어떠한 기능이 어떻게 동작하는지 알기 위해 네 개의 레포지토리를 하나하나 다 확인 해야 했으니까요.

3. 사례: ‘이벤트 결제’와 ‘인기 점수’의 연결고리

도메인 파악의 시작

입사 후 처음 맡은 업무는 인기점수 산정 방식의 변경 구현이었습니다.

인기점수는 바비톡의 이벤트의 노출 순서를 보여주는데에 사용되고 있습니다. 이를 구현하기 위해서는 당연히 기존 인기점수가 어떻게 산정되고 있는지부터 확인해야 했죠. 기존대로라면 코드의 구현을 확인하고, ERD를 확인하고, 그 관계를 하나하나 이해해야 했습니다. 하지만 이제는 도메인 파악을 Cladue와 함께합니다. 크론 스크립트가 위치한 경로에서 Claude에게 이렇게 물었습니다.

파일 경로를 포함한 이 간단한 질문만으로도 Claude는 코드 간의 관계를 분석하여 비즈니스 로직을 체계적으로 정리해 줍니다.

관련 로직 전체 탐색

이전 방식이라면 테이블 명세서를 펼쳐놓고 모델 간의 관계, 흩어져있는 비즈니스 로직을 수동으로 하나하나 추적해야 했습니다. 하지만 Claude에게는 아래와 같이 질문하는 것만으로 충분합니다.

미처 확인하지 못한 로직이 존재할 수 있으므로, 해당 테이블을 참조하는 모든 로직을 빠짐없이 분석하는 것이 중요합니다.

실행 위치 선정의 중요성

대략적인 관계를 파악한 뒤, 구현 방법을 모색하는 단계로 넘어갔습니다. 이때 Claude의 실행 위치를 어디로 잡느냐가 핵심입니다.

바비톡의 주요 비즈니스 로직은 약 4개의 레포에 걸쳐 있습니다. 평소에는 하나의 레포 내부에서 AI를 돌리지만, 도메인 단위로 분리되지 않은 구조에서는 하나의 도메인에 대한 로직이 여러 레포에 흩어져 있을 수 있습니다. 따라서 4개의 레포가 모두 포함된 상위 경로에서 Claude를 실행하는 것이 좋습니다. Claude가 참조할 수 있는 범위가 넓어질수록, 더 정확한 분석과 제안을 받을 수 있기 때문입니다.

구현 방향 설계

충분한 컨텍스트가 확보된 상태에서 다음과 같이 요청했습니다.

Claude는 여러 가지 구현 플랜을 제시합니다. 이 중 가장 적합한 방법을 골라 구현을 진행하면 됩니다. 만약 선택한 방법이 복잡하거나 이해가 어렵다면, 반복적인 질문을 통해 구현 세부 사항을 충분히 파악한 뒤 진행하는 것이 좋습니다.

4. 기획 문서부터 코드까지, AI로 연결하기

여러분은 기획 문서 관리에 어떤 툴을 사용하고 계신가요? 바비톡은 Notion을 적극적으로 활용하고 있습니다. PO분들이 Notion에 요구사항을 상세히 적어주면, 저희는 이를 단순히 읽는 데 그치지 않고 AI와 함께 분석합니다.

Notion MCP를 활용한 요구사항과 코드 검증

MCP(Model Context Protocol)를 활용하면 Notion에 기록된 기획 문서와 실제 코드를 실시간으로 비교할 수 있습니다.

• 기획 확인: 기획자가 정의한 새로운 이벤트 결제 정책이 무엇인지 AI가 Notion에서 읽어옵니다.
• 코드 대조: 해당 정책이 현재 레거시 코드의 도메인 로직과 충돌하는 지점은 없는지, 혹은 이미 구현된 로직 중 재사용 가능한 부분은 무엇인지 AI가 분석합니다.

바비톡에서는 개발을 시작 하기전에, 스코프리뷰를 통해서 영향범위를 사일로멤버들(목적 조직) 및 백엔드팀(기능 조직)에게 공유하고 있습니다. 원래는 노션과 피그마를 통해서 하나하나 요구사항을 파악해야 했는데요, 이제는 Claude를 통해서 그 과정을 간소화 하고있습니다. 그리고 아래와 같이 SKILL을 만들어서 그 과정을 자동화 하고 있습니다.

이 과정을 통해 기획과 개발 사이의 간극을 줄이고, “코드는 이렇게 되어 있는데 기획은 왜 이렇지?”라는 의문을 개발 착수 전 단계에서 빠르게 해소할 수 있었습니다.

5. 결과: 자연어 파악을 넘어 코드로 녹여내기

AI를 통해 도메인 로직을 자연어로 파악하는 것은 첫 단추일 뿐입니다. 진짜 중요한 것은 파악된 내용을 바탕으로 새로운 코드를 추가하고, 기존 코드를 비즈니스 로직에 맞게 정리하여 녹여내는 과정입니다.

이 과정에서 리팩터링은 필수적입니다. 하지만 레거시 코드를 건드리는 것은 언제나 두려운 일이죠. 리팩터링을 하기 전에는 반드시 기존 로직이 여전히 잘 돌아간다는 것을 보장해야 합니다. 즉, 테스트 코드가 필수적이라는 뜻입니다.

사실 바비톡의 주요 레포지토리들에는 아직 테스트 코드가 충분히 갖춰져 있지 않은 상태였습니다. 도메인을 파악하고 리팩터링을 하려니, 이 안전장치의 부재가 가장 큰 걸림돌이 되었습니다.

6. 마무리: 다음 여정을 향하여

AI 덕분에 우리는 레거시라는 거대한 미로에서 빠르게 탈출할 수 있었습니다. AI로 코드를 파악하고, 기획자의 의도를 쉽게 파악하고, 코드와 비교할 수 있었습니다. 하지만 파악된 지식을 코드로 안전하게 옮기기 위해서는 또 다른 도전이 필요했습니다.

다음 글에서는 바비톡의 주요 레포지토리에 테스트 코드 환경을 구축한 생생한 구축기를 담아보겠습니다. 또한, 테스트 코드를 기반으로 어떻게 안심하고 코드를 수정하고 리팩터링했는지 그 과정도 함께 공유해 드릴게요.

[시리즈]

• 1편: AI와 함께한 레거시 탈출: 파편화된 비즈니스 로직 꿰뚫기 ← 현재 글
• 2편: AI와 함께한 레거시 탈출: 안전망 깔기 (pytest 도입기)
• 3편: AI와 함께한 레거시 탈출: 테스트라는 용기로 레거시를 해체하기

AI와 함께한 레거시 탈출: 파편화된 비즈니스 로직 꿰뚫기 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

이전 글에서 바비톡의 앱 현대화 여정의 큰 그림(Macro View)을 보여드렸다면, 이번 글에서는 그 중심에 있는 서버리스 기반 마이크로서비스(MSA) 전환의 구체적인 전략과 실행 과정(Micro View)을 공유하려 합니다.

많은 스타트업이 서버리스의 장밋빛 미래만 보고 섣불리 도입했다가, 예상치 못한 비용 증가나 Cold Start로 인한 성능 저하, 그리고 디버깅의 어려움 때문에 다시 기존 방식으로 회귀하곤 합니다. 이번 포스팅에서는 바비톡이 이러한 시행착오 없이, 어떻게 안정적이고 실용적으로 서버리스를 도입하여 안착시켰는지 그 치열한 기술적 여정(Migration Journey)을 상세히 공유합니다.

[Technical Deep Dive] 적재적소에 서버리스를 적용하여 이벤트 기반 마이크로서비스 생태계 구축

지난 포스팅에서는 거대한 모놀리스를 AWS ECS 기반의 마이크로서비스로 분해하는 ‘주력 부대’의 이야기를 다뤘습니다. 하지만 현대화된 시스템에서 모든 서비스가 24시간 내내 실행되는 무거운 컨테이너일 필요는 없습니다.

사용 빈도가 불규칙하거나, 메인 비즈니스 로직과 비동기로 분리되어야 하는 ‘보조 서비스’들은 더 가볍고 유연해야 합니다. 오늘은 AWS Lambda와 EventBridge를 활용해 구축한 서버리스 기반의 이벤트 구동형(Event-Driven) 아키텍처와, 자칫 파편화되기 쉬운 서버리스 생태계를 “CDK와 CDD(Configuration Driven Development)”로 어떻게 플랫폼 엔지니어링했는지 공유합니다.

1. Why Serverless? (왜 서버리스인가)

우리가 메인 서비스는 컨테이너(ECS)로, 보조 서비스는 서버리스(Lambda)로 이원화 전략을 취한 이유는 명확합니다.

1. 동적 트래픽 대응 (Elasticity): 마케팅 알림 발송(Message)나 데이터 분석 동기화 트리거 같은 기능은 트래픽이 0이었다가 순간적으로 수만 건이 몰리는 ‘스파이크’ 패턴을 가집니다. 서버리스는 별도의 오토스케일링 설정 없이도 즉각적으로 반응합니다.
2. 비용 효율성 (Cost): 항상 켜져 있어야 하는 EC2/ECS와 달리, 요청이 없을 때는 비용이 정확히 ‘0원’입니다.
3. 운영 해방 (NoOps): 조직이 커감에 따라 소수의 DevOps 인원으로 모든 서버를 관리하고 업데이트하기는 불가능합니다. 서버리스는 OS 관리나 보안 패치 없이 비즈니스 로직(Code)에만 집중할 수 있습니다. 즉 클릭 몇번이면 관련된 리소스들을 생성하고 오토스케일링할 수 있습니다.

💡 Kafka vs MSK vs EventBridge?

PubSub 기반으로 이벤트 메시지를 주고 받기 위해서 이벤트 버스는 필연적으로 선택해야 합니다. 직접 설치하거나 관리형 서비스를 사용하거나 클릭 한번으로 생성 가능한 서버리스를 고려할 수 있습니다. 바비톡은 아래 솔루션들의 장단점 비교를 통해서 AWS EventBridge를 선택했습니다. 선택은 그리 어렵지 않았습니다. 왜냐하면 바비톡은 Serverless First 전략을 취하고 있기 때문입니다.

따라서 시스템적인 기능 제약이나 트래픽/성능에 대한 성능 제약이 없다면 서버리스를 먼저 고민합니다. AWS EventBridge는 클릭 한번으로 수분만에 이벤트 버스를 생성할 수 있으며, 추가적인 복잡한 유지보수(오토스케일링, 서버 구축, 보안 설정, 패치 업데이트)를 할 필요가 없습니다. 특히 바비톡의 트래픽 범위와 유스케이스를 고려한다면 단연 최고의 선택이었습니다.

• Kafka/MSK: 인프라 관리가 필요하고 기본 비용이 높습니다. 물론 최적화 측면에서 비용과 보안 그리고 성능에 대한 노하우가 많이 필요합니다.
• EventBridge: 완전 관리형(Serverless)이며, 사용한 만큼만 지불합니다. 무엇보다 AWS 생태계(Lambda, S3, DynamoDB)와의 연동성이 압도적입니다.

2. Implementation Approach: 아키텍처 개요

우리는 Pub/Sub 이벤트 모델에 몇가지 규칙을 정해서 시스템을 구성했습니다.

• Publisher: ECS 컨테이너나 다른 Lambda 함수가 이벤트를 발행합니다. 주로 앞단의 메인 API 서버들이 이벤트를 발생시킵니다.
• Event Bus: AWS EventBridge가 이벤트를 받아 규칙(Rule)에 따라 라우팅합니다. 이때 규칙 설정은 외부에서 쉽게 json으로 일관된 규약을 선언형으로 지정하면 내부적으로는 AWS CDK로 모듈화되어 동작합니다.
• Subscriber: 가장 일반적인 케이스들은 Lambda 함수로 이벤트를 직접 받아 로직을 수행합니다. 람다 서비스 내에서 직접 이벤트 구독 기능을 제공하기 때문에 구독 관리를 할 필요가 없어서 매우 편리하고 안정적입니다. 물론 복잡한 로직을 수행해야할 경우는 Lagacy Conterner들이 이벤트를 직접 구독 관리해야 합니다. 하지만 이럴 경우에 직접 이벤트 구독 관리를 해야하기 때문에 Proxy Lambda를 앞단에 정의하고 이 람다 함수가 이벤트를 먼저 받은 후 API 호출로 컨테이너에 중계합니다.

3. 핵심 전략 1: 이벤트 메시지의 표준화 (Standardization)

이벤트 기반 아키텍처(EDA)의 가장 큰 위험은 “메시지 포맷의 파편화”입니다. 각 팀이 제멋대로 이벤트를 던지면 소비(Subscribe)하는 쪽은 지옥이 됩니다. 우리는 Strict한 JSON 스키마를 정의하여 이를 해결했습니다.

💡표준 메시지 구조

EventBridge의 기본 포맷(DetailType, Source) 안에 우리만의 Detail 구조를 심었습니다.

• Source: 마이크로서비스 이름 (enum 관리, 예: app_api)
• DetailType: 1차 구독 토픽으로써 Usecase나 Event 기반으로 정의 (예: batch_completed message_requested)
• Detail: 커스톰하게 정의할 수 있는 영역으로써 우리는 내부에 Kind와 Body를 정의하였습니다. Kind는 2차 분류 토픽 (촘촘한 구독 필터링용)으로 동작하고, Body는 Payload로써 다시common(공통 필드) + specific(이벤트 특화 필드)으로 이뤄집니다.

{
    "version": "0",
    "id": "5fb1f9a2-6e7d-b60d-7332-801d5dd3e46b",
    "detail-type": "1st_level_topic_completed",
    "source": "xxx_yyy_service",
    "account": "account_number",
    "time": "2024-07-04T16:01:18Z",
    "region": "region_name",
    "resources": [],
    "detail": {
        "Kind": "2nd_level_topic_v1",
        "Body": {
            "common": {
                "com_key1": "xxx"
                "com_key2": "yyy"
            },
            "specific": {
                "spec_key1": "xxx",
                "spec_key2": "yyy"
            }
        }
    }
}

4. 핵심 전략 2: IaC와 CDD를 통한 서버리스 인프라 템플릿화 (Serverless Infrastructure Templates)

수백 개의 서버리스 함수를 관리하면서 가장 큰 문제는 “구성의 파편화”였습니다. 어떤 함수는 S3 업로드를 감지해야 하고, 어떤 함수는 EventBridge 메시지를 받아야 하며, 또 어떤 함수는 VPC 내부의 RDS에 접근해야 합니다.

우리는 이 모든 요구사항을 단 하나의 CDK 스택 클래스(One Stack Source)로 통합하고, 외부 설정 파일(JSON) 주입만으로 “다양한 형상의 람다(Multiple Configurations)”를 찍어낼 수 있는 CDD(Configuration Driven Development) 환경을 구축했습니다. 즉 아래 그림과 같이 람다 함수를 추상화하고 이를 트리거하는 외부 요소들을 표준화하여 JSON 규격에 선언하여 주입만하면 다양 조합의 람다 함수를 구성 및 배포할 수 있도록 하였습니다.

① 필수 이벤트 트리거의 표준화

우리는 가장 빈번하게 사용되는 4대 이벤트 트리거를 표준화하여 CDK 모듈에 내재화했습니다. 이들은 자유롭게 조합 가능합니다.

1. EventBridge: BusArn, Source, DetailType만 입력하면 자동 연결
2. S3 Bucket: 버킷 이름과 Prefix만 지정하면 파일 이벤트 감지
3. DynamoDB Stream: 테이블 변경 사항(Stream) 감지
4. Time Schedule: Cron 방식이나 일정한 Rate로 감지

② One Source, Multiple Configurations (실전 CDD 예시)

아래는 실제로 우리가 사용 중인 복합 구성 JSON의 전체 예시입니다. 개발자는 복잡한 인프라 코드를 한 줄도 건드리지 않고, 이 JSON 파일 하나만 작성하면 [VPC + 복합 트리거 + IAM 권한 + Layer]이 완벽하게 세팅된 서버리스 환경을 배포할 수 있습니다.

{
      "BaseName": "BannerOperation",
      "VpcEnable": true,
      "Triggers": [
          {
              "TriggerType": "TriggerS3Bucket",
              "BucketName": "xxx-yyy-zzz",
              "TriggerPrefix": "feature_name/live/config/"
          },
          {
              "TriggerType": "TriggerEventBridge",
              "BusArn": "arn:aws:events:region:account:event-bus/bus_name",
              "Source": ["app_api", "cron_batch"],
              "DetailType": "1st_level_topic",
              "Detail": {
                "Kind": "2nd_level_topic"
              }
          },
          {
              "TriggerType": "TriggerS3Bucket",
              "BucketName": "babitalk-resource-crm",
              "TriggerPrefix": "white_sentence/live/config/"
          },
          {
              "TriggerType": "TriggerTimeScheduler",
              "Type": "CronExpression",
              "CronExpression": "0 1* * ? *",
              "Description": "매일 새벽 1시에 실행"
          }
      ],
      "LambdaFunction": {
          "BaseName": "XxxYyyFunc",
          "CodePath": "repo_name/domain_name/feature_name/src",
          "Environment": {
              "DdbTableName": "table_name",
              "StageName": "Live"
          },
          "LayerVersionArns": [
              "BBT-DevOpsCommon-Dev-XxxYyy1",
              "BBT-DevOpsCommon-Dev-XxxYyy2"
          ],
          "ReservedConcurrentExecutions": 1,
          "Timeout": 10,
          "JsonIamPolicies": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "dynamodb:PutItem",
                      "dynamodb:GetItem",
                      "dynamodb:Query",
                      "dynamodb:BatchWriteItem"
                  ],
                  "Resource": "arn:aws:dynamodb:region:account:table/table_name"
              }
          ]
      },
      "SubnetIds": [
          "subnet-0000000aaaaaaaaaa",
          "subnet-1111111bbbbbbbbbb"
      ],
      "SecurityGroupIds": [
          "sg-0000000000000000"
      ]
  }

③ 이 설정 파일이 처리하는 마법

위 JSON이 환경 변수를 통해 위부 주입되면, AWS CDK 내부에서 다음과 같은 작업을 자동으로 수행합니다.

• Multi-Trigger Binding: Triggers 배열을 순회하며 각 조건에 맞는 Trigger들을 동록합니다.
• Secure Networking: VpcEnable: true를 감지하여 람다를 인터넷이 차단된 Private Subnet에 배치하고 RDS 접근 경로를 엽니다.
• Least Privilege IAM: JsonIamPolicies를 파싱하여 정확히 필요한 테이블에 대한 접근 권한만 부여합니다.

5. 핵심 전략 3: 비즈니스 로직 템플릿화

인프라가 자동화되었다면, 그 안에서 돌아갈 애플리케이션 코드의 생산성을 높여야 합니다. 바비톡은 python을 기본 언어로 사용하기 때문에 python 템플릿 코드를 구성하여 다음과 같이 기본 기능을 제공합니다. 각 백엔드 개발자는 핵심 로직만 템플릿에 추가하는 형태로 애플리케이션 코드 작업을 하게 됩니다.

• 기본 뼈대 코드: 람다 입력값에 대한 유효성을 검증한 후, topic 별 라우팅 기능을 제공합니다. 구독하는 topic 별로 tempalte method pattern을 적용하여 실제 비즈니스 로직을 구현합니다. 이때 입출력 데이터들을 Pydantic을 이용하여 전달됩니다.
• Utility Pack: AWS Secrets Manager 연동(DB 암호 관리), MySQL Connection Pool, Event Publish 기능을 헬퍼로 제공합니다.
• Local Test Environment: pipenv와 pytest를 통해 AWS 배포 없이 로컬에서 완벽하게 디버깅할 수 있는 환경을 제공합니다.

6. 적용 사례 (Use Cases)

서버리스 적용은 철저히 메인 서비스보다는 보조 서비스들에 적용되고 있습니다. 여기서 보조 서비스들의 특징은 트래픽 증가가 순식간에 수백배 늘어나 예측하기 어렵거나 반대로 트래픽 자체가 매우 간헐적으로 호출되어 서버를 항시 준비할 필요가 없는 케이스들입니다.

• 💬 message_box (통합 메시징): API 서버나 배치 서버가 “메시지 발송 요청” 이벤트를 던지면, 람다가 이를 받아 알림톡/SMS/이메일/Push 등 채널 별로 발송합니다. 이렇게 이벤트 기반 비동기 처리로 메시지들을 핸들링하면 메인 서비스 서버 요청의 응답 속도를 단축하고 3rd Party 솔루션의 종속성을 제거하기 때문에 매우 안정적으로 서비스를 운영할 수 있게 됩니다.

• 🎯 crm_box (마케팅 자동화): CRM 팀이 타겟 유저를 설정하면, 동시 다발적으로 웹훅이 발동되어 람다가 동작하며, 이를 통해서 맞춤형 쿠폰 지급이나 배너 광고를 세팅합니다. 이런 마케팅 트래픽은 매우 다이나믹하여 기본적으로 오토스케일링이 내장된 람다에서 매우 유지보수가 편합니다. 관련된 사항은 브레이즈 고객 사례에 소개되었습니다.

• 📊 data_box (데이터 파이프라인): 데이터 분석 팀의 통계/추론/추천 작업이 끝나면 이벤트를 트리거하여, 람다가 운영 DB에 통계 데이터를 적재합니다. 이 경우는 아주 간헐적으로 트리거되기 때문에 굳이 서버를 7/24 내내 운영할 필요가 없는 케이스라서 비용 절감에 큰 장점이 있습니다.

마치며: 기술의 변화는 문화의 변화를 동반한다!

이번 서버리스 마이그레이션 프로젝트를 통해 얻은 가장 큰 인사이트는 두 가지입니다.

첫째, “Serverless와 CDK는 최고의 파트너”라는 점입니다. 서버리스 아키텍처는 수많은 작은 리소스(Function, Role, Rule, Trigger, Layer)들의 집합입니다. 이를 사람이 손으로 관리하는 것은 불가능에 가깝습니다. 특히 유사한 구성을 알파/배타/감마와 같은 배포 단계에 구성해야할 경우에는 더욱 그렇습니다. AWS CDK를 통해 인프라를 코드로 정의하고 모듈화했기에, 우리는 복잡한 서버리스 생태계를 통제 가능한 수준으로 유지할 수 있었습니다.

둘째, 기술보다 어려웠던 것은 “팀의 인식 변화(Mindset Shift)”였습니다. 우리 개발팀은 오랫동안 “서버는 24시간 켜져 있고(EC2/Container), 내가 접속해서 로그를 볼 수 있는(Stateful) 대상”이라는 인식이 강했습니다.

• “서버가 없는데 로그는 어디서 봐요?”
• “요청이 없을 때 꺼지면, 다시 켜질 때 느리지 않나요?(Cold Start)”

이런 의구심을 해소하기 위해 수많은 기술 세션과 핸즈온(Hands-on)을 진행했습니다. 서버리스가 주는 ‘비용 효율성’과 ‘운영 해방(NoOps)’의 가치를 팀원들이 체감하고, 아키텍처에 자연스럽게 녹여내기까지는 꽤 긴 설득과 학습의 시간이 필요했습니다. 예를 들어 구체적으로 다음과 같은 세션들을 Server Community Session을 통해서 BE 개발자, 플랫폼 개발자, DevOps 개발자분들에게 전파하였습니다.

• AWS CDK 소개
• 현재 우리의 서버 구성 상태
• 서버리스 크론 도입 소개
• 서버리스와 자동화
• 이벤트 기반 비동기 처리
• 람다 함수 템플릿 로직과 헬퍼 제공

하지만 지금, 우리 팀은 메인 로직은 단단한 컨테이너로, 보조 로직은 유연한 서버리스로 구현하는 ‘하이브리드 마이크로서비스’를 자유자재로 구사하고 있습니다. 이것이 진정한 앱 현대화(App Modernization)의 완성이 아닐까 합니다.

서버리스 기반 마이크로 서비스(MSA) 전략과 마이그레이션 여정 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

도입 배경

이 글에서는 Next.js App Router 기반의 글로벌 서비스에서 RSC(React Server Components)와 TanStack Query를 함께 활용해 이벤트 상세 페이지의 LCP를 약 38% 개선한 경험을 공유하려고 합니다.

문제 상황을 어떻게 정의했고, 어떤 기술적 선택을 통해 성능을 개선했는지 과정을 중심으로 정리해보았습니다.

현재 바비톡 글로벌 서비스는 Next.js 13부터 도입된 App Router 기반으로 구성되어 있습니다. 기본적으로 SPA 환경에서는 페이지 이동 시 CSR(Client-Side Rendering) 방식으로 동작하기 때문에, 서버 컴포넌트를 사용하지 않거나 별도의 대응이 없다면 데이터 페칭 과정에서 레이아웃 시프트가 발생할 가능성이 있습니다.

레이아웃 시프트(Layout Shift)에 대한 고민

실제 예시로 데이터 패칭 관련해서는 현재 TanStack Query를 사용중입니다. TanStack Query를 사용할 경우 클라이언트 훅(useQuery)을 포함하므로 ‘use client’를 명시해 주어야 합니다. 이러한 과정에서 서버에서 렌더링되어 내려올 때 useQuery 훅이 클라이언트에서만 실행되므로, SSR 시점에는 데이터가 없어 isLoading 상태로 사용자에게 첫 페이지가 보여지게 됩니다.

사용자 입장에서는 Skeleton ui처럼 별도의 loading 처리가 없는 경우에 페이지가 로딩되는 과정을 그대로 노출되게 되고 레이아웃 시프트가 일어나기 때문에 사용자 경험 측면에서 상당히 부정적인 경험으로 받아 들여지게 됩니다. 이러한 부정적 경험이 쌓여 서비스의 품질을 결정하고 나아가서는 서비스의 이미지에 영향을 줄 수 있다고 생각하기 때문에 새로 오픈하는 글로벌 서비스에서 사용자들에게 좋은 인상을 남겨주고 싶었습니다.

사용자가 불편함을 느끼지 못하게 사이트 탐색을 할 순 없을까?

위에 고민과 더불어 서비스를 운영하는 개발자라면 사용자가 서비스를 이용함에 있어 불편함 없이 페이지 렌더링이나 진입 속도를 최적화하고 0.1초라도 빠르게 서비스를 구성하려는 목표를 갖고 있을 것입니다. 렌더링 1초 차이에 따라 사업적인 관점에서는 페이지가 빠르면 사용자는 자연스럽게 더 많은 페이지를 둘러보고, 사이트에 더 오래 머무르게 됩니다. 이는 곧 콘텐츠 소비량 증가로 이어지는 과정이라고 생각합니다. 반대로 사용자에게 빠른 페이지 전환은 서비스 이용 만족도를 높이는 중요한 요소가 됩니다.

따라서 사용자 입장에서 가장 중요하다고 볼 수 있는 이벤트 상세 페이지 렌더링 관련하여 기술적으로 변경이 필요하다고 생각이 들었습니다.

기술/프랙티스/방법론 검토

레이아웃 시프트(Layout Shift)와 FCP 외에도 SEO도 고려해야 했기 때문에 서버 렌더링을 필수로 적용하기로 고려했고 결과적으로 2가지 방식으로 방법을 추릴 수 있었습니다.

SSR(Server Side Rendering)을 활용한 방식

첫번째로는 SSR(Server Side Rendering)을 활용하여 HTML을 서버에서 렌더링해서 완성된 형태로 클라이언트에 전달하는 방식으로 초기 HTML이 이미 완성된 형태로 전달받기 때문에 레이아웃 시프트를 방지할 수 있습니다.

## CSR (React CRA 등)
1. HTML은 <div id="root"></div> 뿐.
2. JS가 로드될 때까지 빈 화면.
3. JS가 실행되면 한꺼번에 렌더 → 레이아웃 시프트 발생 가능.

## SSR (Next.js 등)
1. 서버에서 완성된 HTML이 전달됨.
2. 브라우저가 즉시 레이아웃 계산 가능 → 초기 시프트 적음.

또한 CSR과 비교했을 때 초기 렌더링이 빠르고, 콘텐츠가 즉시 보이기 때문에 FCP(First Contentful Paint)가 개선되어 사용자 입장에서도 빠른 페이지 렌더링을 통한 좋은 경험을 줄 수도 있습니다.

하지만 완전한 방지는 아쉽게도 불가능합니다. SSR을 해도 다음과 같은 이유로 레이아웃 시프트는 여전히 발생할 수 있습니다.

1. 이미지 크기가 미리 지정되지 않음

• <img>에 width/height 속성이 없으면 로드 후 공간이 밀립니다.

2. 웹폰트 FOUT/FOIT

• 폰트가 늦게 로드되면 글씨 크기가 바뀌면서 시프트가 생깁니다.

3. 동적 콘텐츠 삽입

• 광고, Lazy-loaded 컴포넌트, 비동기 데이터 등으로 레이아웃이 바뀔 수 있습니다.

4. Hydration 시점 차이

• SSR된 HTML과 클라이언트 렌더 결과가 다를 경우, React나 Next.js가 재조정(reconciliation)하면서 살짝 흔들릴 수 있습니다.

RSC(React Server Component)를 활용한 방식

두번째로는 RSC(React Server Component)를 활용하여 FCP 속도 개선과 레이아웃 시프트를 방지하는 것입니다. RSC는 SSR와 동일하게 서버에서 동작하는 방식이지만 렌더링 방식 자체는 완전히 다릅니다. RSC 같은 경우는 SSR처럼 페이지 전체를 HTML로 만드는 게 아니라 React 컴포넌트 자체를 서버에서 실행하고, 결과를 클라이언트에 컴포넌트 트리 구조로 전달 합니다.

즉 페이지 단위 렌더링이 아닌 컴포넌트 단위로 렌더링이 이루어지며, RSC는 서버 컴포넌트를 렌더링한 결과를 Streaming SSR을 활용하여 SSR보다 빠른 렌더링을 제공합니다.

자세한 RSC의 렌더링 방식은 아래와 같이 동작하게 됩니다.

서버에서의 렌더링 동작

1. RSC는 서버로 요청이 들어오면 React Server Component 트리를 렌더링한 뒤, 그 결과를 RSC Payload로 생성합니다. 이 Payload는 React Flight Protocol이라는 전용 스트리밍 프로토콜을 통해 직렬화되어 클라이언트로 전답 됩니다.
2. 이 과정에서 서버는 컴포넌트 트리를 HTML로 통째로 변환하지 않고, 클라이언트의 React 런타임이 컴포넌트 결과를 재구성할 수 있는 정보만을 스트리밍합니다. 결과적으로 브라우저는 서버에서 내려온 Payload를 바탕으로 필요한 DOM을 점진적으로 구성하게 됩니다.
3. 생성한 RSC Payload 와 클라이언트 컴포넌트 자바스크립트 인스트럭션(웹페이지에 동적 기능을 추가하기 위해 사용되는 js 명령어, setState에 들어가는 기본 init값을 생각하면 쉬움)을 활용하여 최종 HTML을 스트리밍 형태로 생성합니다

RSC Payload 구성

• 서버 컴포넌트의 JSX 렌더링 결과
• 빈자리 (placeholder 처리)
  서버 컴포넌트는 클라이언트 컴포넌트 포함이 가능하므로 해당 클라이언트 컴포넌트와 그에 필요한 자원을 응답받아야 하기 때문에 이를 기억해야 합니다. 즉 클라이언트의 렌더 파일 위치를 기억하게 됩니다.
• props (서버 컴포넌트(SC)가 클라이언트 컴포넌트(CC)에 전달하는 props들)

따라서 1~3번 과정이 서버에서 일어난 이후에 클라이언트에서는 아래와 같이 동작하게 됩니다.

클라이언트에서의 렌더링 동작

1. html을 응답 받으면, 먼저 즉시 보여준다(Streaming SSR)
2. 기존 SSR은 모든 준비가 끝나고 완성된 페이지를 보여주지만 스트리밍 기능을 활용하면 먼저 생성된 html을 보여주고 생성된 순서대로 순차적으로 페이지를 보여주게 됩니다. 렌더링이 끝나지 않은 부분은 Suspense로 대처 가능합니다.

<Page>
  <Header /> // 즉시 렌더링됨 → 먼저 전송             
  <Suspense fallback={<Skeleton />}> // 데이터 대기 중
    <Posts />             
  </Suspense>
</Page>

3. RSC Payload 를 가지고 reconcile(재조정) 단계가 발생하게 됩니다. 왜냐하면 클라이언트 컴포넌트를 포함하고 있으면 이러한 빈자리를 채워서 트리 구조를 형성하기 때문입니다.

4. hydration 과정이 일어나게 됩니다. html에 리액트를 끼얹어서 상호작용이 가능하도록 합니다. 해당 과정에서 클라이언트 컴포넌트의 상호작용이 들어가게 됩니다.

하지만 RSC도 레이아웃 시프트를 완전히 방지할 수 있는 것은 아닙니다. 물론 next/fetch를 사용하여 서버에서 api를 호출하여 미리 데이터를 활용 할 수 있게 추가적인 세팅을 통해 해결할 수 있긴 합니다. 그럼 해당 방식을 조금 더 편안하게 핸들링할 수 있도록 TanStack Query를 통한 방법을 알아 보겠습니다.

TanStack Query와 같이 RSC를 활용하는 방법

fetch 대신에 TanStack Query를 사용하는 이유는 크게 3가지로 생각을 했었고 아래와 같습니다.

1. fetch()는 “요청 한 번 → 응답 한 번” 단순한 네트워크 호출

const res = await fetch('/api/posts'); const data = await res.json();

이렇게 하면 데이터를 불러오긴 하지만 로딩 중이나 다른 상태값을 처리하려고 하면 useState와 useEffect등 직접 설정이 필요하고 에러 발생 시 try/catch 수동 처리, 다른 컴포넌트에서 같은 데이터를 다시 fetch 등 중복 요청이 발생하게 됩니다.

2. TanStack Query는 데이터 상태에 대하여 기본적으로 처리할 수 있는 기능이 있어 별도 설정이 필요 없습니다.

• 로딩 / 에러 / 성공 상태 자동 관리
• 데이터 캐싱 + 중복 요청 방지
• 탭 전환 시 자동 리패칭
• 캐시 시간(TTL) 설정 가능
• Optimistic Update, Infinite Query 등 기능 제공

3. TanStack Query는 서버에서 데이터를 쿼리 캐시에 담은 뒤 dehydrate 상태로 직렬화하여 클라이언트로 전달하고, 클라이언트에서는 HydrationBoundary를 통해 해당 상태를 복원(hydrate)하는 구조로 서버 데이터를 클라이언트 캐시에 전달할 수 있습니다.

// 서버에서 미리 fetch
const queryClient = new QueryClient();
await queryClient.prefetchQuery(['posts'], fetchPosts);

return (
 <HydrationBoundary state={dehydrate(queryClient)}>
  <Posts />
 </HydrationBoundary>
);

가장 중요한 내용으로 서버에서 데이터 호출하고 그 캐시를 클라이언트로 **직렬화(dehydrate)**해서 전달하게 되면 클라이언트에서는 **재활성화(rehydrate)**해서 그대로 쓸 수 있습니다.

fetch와 TanStack Query는 간략하게 아래 표로 정리하였습니다.

최종 선택/확정

최종적으로 위와 같은 내용을 토대로 RSC와 TanStack Query를 활용하여 prefetch하는 방식이 최적의 방법이라 생각을 했습니다.

따라서 바비톡 글로벌 이벤트 상세 페이지에 적용하기로 결정하였고 TanStack Query의 Hydration 부분은 HydrationBoundary, dehydrate, prefetch 호출단을 각각 기능에 따라 나눠서 관리하고 있습니다. 이유는 역할을 분리해서 RSC 데이터 파이프라인을 예측 가능하고 확장 가능하게 만들기 위해서 입니다.

실제로 해당 호출단을 분리해서 dehydrate 하는 부분에 Promise.all을 활용하여 여러 API 호출을 병렬 처리함으로써 서버 응답 시간을 단축시켰습니다.

현재 모습

RSC로 변경 후 실제 렌더링 성능 차이

기존 CSR 기반 구조에서는 클라이언트가 페이지를 요청한 뒤 API 응답을 기다리는 동안 빈 화면(white screen) 상태가 노출되었습니다. 이로 인해 초기 렌더링 지연과 레이아웃 시프트(Layout Shift) 문제가 발생했습니다.

하지만 RSC와 서버 prefetch(dehydrate) 를 결합한 이후에는 데이터가 서버에서 미리 패칭되어 HTML에 포함된 상태로 전달되므로, 클라이언트에서는 별도의 데이터 로딩 지연 없이 즉시 콘텐츠를 확인할 수 있었습니다.

특히 LCP가 약 7.7초 → 4.8초로 38% 개선된 점은 특히 의미가 있다고 생각합니다. Lighthouse의 LCP 측정 로직은 “브라우저가 인식 가능한 최종 페인트 타이밍” 기준이기 때문에 실제로 사용자 입장에서 페이지가 더 빠르고 안정적으로 로드되는 체감 개선이 이루어졌다고 볼 수 있습니다.

트리맵만 확인하더라도 개선 후에는 레이아웃 시프트 없이 보다 빨리 페이지가 렌더링 되는 부분을 확인할 수 있었습니다. 그럼 마지막으로 실제 live 서버에서 렌더링 속도를 확인 하는 것으로 마무리 하겠습니다.

두 비교 GIF에서 확인할 수 있듯이 개선 후에는 페이지 진입 시 첫 콘텐츠가 즉시 표시되고 주요 이미지와 텍스트가 자연스럽게 로드되어 사용자가 ‘기다린다’는 느낌 없이 콘텐츠를 소비할 수 있는 흐름이 만들어졌습니다.

단순히 수치상의 개선뿐만 아니라, 실제 체감 속도와 상호작용 반응성이 모두 향상 되었으며 이는 곧 사용자 경험(UX) 품질의 실질적 향상으로 이어졌습니다. 앞으로도 이러한 성능 최적화 방향을 유지하며, 사용자 입장에서 더 빠르고 안정적인 웹 환경을 지속적으로 제공할 계획입니다.

향후 진행

RSC는 공짜가 아니다. 성능과 비용 사이의 선택

RSC 방식은 서버 사이드에서 컴포넌트 단위로 React를 실행하고, 이를 직렬화하여 클라이언트로 전달하기 때문에 일반 CSR 또는 SSR보다 서버 리소스를 상대적으로 더 많이 소모합니다.

특히 RSC는 요청이 발생할 때마다 서버에서 렌더링 로직이 수행되며, 서버에서의 CPU 연산 및 네트워크 I/O 부하가 증가하게 됩니다. 트래픽이 높은 서비스에서는 이러한 부하가 누적되면 서버 스케일링 비용과 응답 지연(latency) 문제로 이어질 수 있습니다.

따라서 모든 페이지에 RSC를 일괄 적용하는 것은 비효율적이라고 판단했습니다.

RSC의 주요 장점은 초기 렌더링 속도 개선과 JS 번들 사이즈 감소에 있지만, 모든 페이지가 이 최적화의 우선순위를 필요로 하는 것은 아닙니다. 예를 들어 사용자 진입 빈도가 낮거나, 서버 데이터 의존도가 낮은 정적 페이지는 기존 SSG(Static Site Generation)나 CSR만으로도 충분히 좋은 성능을 낼 수 있습니다.

이러한 이유로, 서비스 트래픽 데이터 기반의 선택적 적용 전략을 계획하고 있습니다.

구체적으로는 아래와 같은 방식으로 진행할 예정입니다.

1. 사용자 탐색 데이터 분석

• 내부 로그를 활용해 사용자 진입 빈도와 체류 시간, 전환율이 높은 페이지를 식별합니다.
• 예를 들어 이벤트 상세 페이지나 홈 피드처럼 유입률이 높고, 콘텐츠 노출 속도가 UX에 직접 영향을 주는 영역이 우선 적용 대상이 됩니다.

2. RSC 적용 기준 수립

• 서버 렌더링 비용 대비 렌더링 성능 향상 폭을 정량적으로 측정합니다.
• CLS, FCP, TTFB 등의 Web Vitals 지표를 기준으로 개선 효과가 명확한 페이지에만 RSC를 적용합니다.
• 반대로, 정적 데이터 위주의 페이지나 잦은 서버 재요청이 필요 없는 페이지는 SSG로 유지합니다.

3. 서버 부하 관점의 모니터링 및 점진적 확장

• RSC 적용 후에는 서버 자원 사용량(CPU, 메모리, 응답 시간)을 지속적으로 모니터링하며 서버 부하가 임계값을 넘지 않는 선에서 점진적으로 확장 적용할 계획입니다.
• 이를 통해 RSC의 장점을 극대화하면서도 서버 운영 비용을 안정적으로 유지할 수 있습니다.

요약하자면, RSC는 분명히 성능과 사용자 경험 측면에서 강력한 장점을 제공합니다.

그러나 그만큼 서버 자원 소비와 인프라 비용도 함께 늘어나기 때문에, 모든 페이지가 아닌 “렌더링 품질이 직접적인 UX 지표에 영향을 주는 주요 페이지” 중심으로 선택적 적용하는 전략이 가장 현실적이라고 판단했습니다.

이런 접근을 통해 RSC의 장점을 효율적으로 활용하면서도 서비스 안정성과 비용 효율성을 동시에 확보할 수 있을 것입니다.

참고 문서

Getting Started: Server and Client Components | Next.js

https://tanstack.com/query/latest/docs/framework/react/guides/prefetching

사용자가 페이지 로딩을 눈치채지 못하게 만들기 — RSC 도입 이야기 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

이전 글에서 바비톡의 앱 현대화 여정의 큰 그림(Macro View)을 보여드렸다면, 이번 글에서는 그 중심에 있는 컨테이너 기반 마이크로서비스(MSA) 전환의 구체적인 전략과 실행 과정(Micro View)을 공유하려 합니다.

특히, 스타트업 환경에서 “이상적인 MSA”를 쫓다가 오버엔지니어링의 늪에 빠지지 않고, “현실적이고 실용적인 MSA”를 어떻게 구축했는지, 그 치열한 고민의 과정(Case Study)을 상세히 담았습니다.

[Technical Deep Dive] 컨테이너 기반 실용주의적 MSA: AWS ECS와 Clean Architecture로 모놀리스 분해하기

스타트업의 초기 시스템은 빠르게 기능을 찍어내기 위해 ‘역할 기반’의 거대한 모놀리스로 시작하는 경우가 많습니다. 우리도 예외는 아니었습니다. 각각의 앱 서버, 운영 관리자 서버, 병원 운영 서버 등 소위 ‘3대장 서버’가 모든 트래픽과 로직을 감당하고 있었습니다.

하지만 조직이 커지면서 이 구조는 한계에 봉착했습니다. 오늘은 우리가 이 거대한 모놀리스를 어떻게 AWS ECS 기반의 마이크로서비스로 쪼개고, 그 내부를 Clean Architecture로 단단하게 채웠는지 이야기합니다.

1. 문제점: 고민의 시작

① “역할 기반” 서버의 한계

우리의 레거시 시스템은 도메인(or 기능)이 아닌, 사용 주체(Role)에 따라 서버가 나뉘어 있었습니다. 즉 현재 상황은 앱 유저용 API 서버, 운영자용 Admin 서버, 병원용 Partner 서버가 각각 존재합니다.

이로 인해서 다음과 같은 Pain Point가 지속적으로 발생하게 되었습니다.

중복 개발: 예를 들어 ‘후기’ 기능은 유저도 쓰고 운영자도 관리해야 합니다. 하지만 서버가 다르니 프레임워크도 다르고, Database ORM 방식도 다르고, 결국 유사한 코드를 두벌 이상 개발(Double Coding)해야 했습니다.

하드 카피의 악몽: 공통 로직을 공유할 방법이 마땅치 않아, 코드를 복사-붙여넣기(Hard Copy)하여 관리했습니다. 버그가 생기면 양쪽 다 수정해야 하는 유지보수의 지옥이 펼쳐졌습니다. 물론 프레임워크와 ORM이 서로 상이하여 구현과 쿼리 결과도 미세하게 다르게 적용되어 품질에도 이슈가 발생했습니다.

불분명한 오너십: ‘충전금’ 기능이 터졌을 때, 앱 서버 담당자가 봐야 할지 관리자 서버 담당자가 봐야 할지 모호했습니다. 도메인 오너십이 산발적으로 흩어져 있었습니다.

② 왜 AWS ECS인가?

우리의 레거시 시스템은 AWS Elastic Beanstalk으로 구성되어 있었습니다. 이 서비스는 DevOps 멤버가 없는 경우에 Backend 개발자가 선택할 수 있는 가장 쉽고 편리한 최선의 선택입니다. 특히 모놀리스 방식으로 로드밸런서와 EC2 인스턴스만 구성하는 심플한 경우에 매우 매력적입니다. 하지만 그만큼 구성 자체가 정형화되어 있어 커스토마이징하기가 어렵고 확장하는데 한계가 있습니다.

우리는 AWS ECS와 EKS 중에서 선택이 필요하였으며, 다음과 같은 이유로 최종적으로 AWS ECS를 선택하였습니다.

AWS 통합: 기존 AWS 서비스들과 손쉽게 통합 가능하여 AWS Cloud 친화적으로 구성 가능함

기술적 요구사항: 핵심적인 기술적 요구 사항(안정성/확장성/유지보수성)을 총족하면서 동시에 필요 이상의 것들을 유지보수할 필요 없음

간결함과 유지보수 편리함: 러닝 커브가 매우 낮으며, AWS CDK로 매우 쉽게 커스토마이징과 확장이 가능함

물론 저희가 EKS를 사용하지 않는 것은 아니며, 오픈 소스 기반으로 에코 시스템들이 잘 제공되는 케이스들에 대해서는 자체적으로 서비스를 EKS 기반으로 운영하고 있습니다.

2. 전략: 현실적인 분해 원칙 (Principles)

우리는 “모든 것을 처음부터 다시 만들자”는 빅뱅 방식을 거부했습니다. 스타트업의 특성 상 기술 개발에 몰입하여 사업적인 개발을 뒤로 미룰 수 없기 때문입니다. 대신 “기존 것은 유지하되, 공통 기능부터 뜯어내자”는 실용적 원칙을 세웠습니다. 즉 우리는 무작정 서비스를 쪼개는 것이 아니라, “어떻게 안전하게 떼어내고(Decompose)”, “어떻게 효율적으로 연결할 것인가(Integrate)”에 대한 명확한 기술적 가이드라인을 세우고 시작했습니다. 이를 위해 검증된 MSA 패턴들을 우리 상황에 맞춰 재해석하고 조합했습니다.

① 분해 전략 (Decomposition Strategy)

• 비즈니스 능력에 따른 분해 (Decompose by Business Capability): 기존의 ‘앱/웹 서버’, ‘운영 서버’ 같은 기술적/역할적 경계를 허물고, ‘충전금’, ‘검색’, ‘인증’과 같이 비즈니스 가치를 창출하는 도메인 단위로 서비스를 정의했습니다. 이는 콘웨이 법칙(Conway’s Law)에 따라 조직 구조와 시스템 구조를 일치시키는 첫걸음이었습니다.
• 도메인 주도 설계 (Domain Driven Design, DDD): 각 마이크로서비스 내부는 철저히 DDD 원칙을 따랐습니다. 서비스 간의 결합도를 낮추기 위해 Bounded Context(제한된 문맥)를 정의하고, 그 안에서 보편적 언어(Ubiquitous Language)를 사용하여 기획-개발-운영의 간극을 줄였습니다.

② 마이그레이션 전략 (Migration Strategy)

• 스트랭글러 패턴 (Strangler Fig Pattern): 거대한 레거시 시스템을 한 번에 교체하는 빅뱅 방식은 실패 확률이 높습니다. 우리는 덩굴 식물이 숙주 나무를 서서히 감싸 안아 결국 대체하듯, 점진적으로 두 단계로 나눠서 마이그레이션을 진행했습니다. 첫번째 단계에서는 기존 도메인/기능들을 공통의 마이크로서비스로 분리시켜 참조하도록 하고, 두번째 단계에서는 새로운 도메인/기능을 마이크로서비스로 추가하여 기존 트래픽을 점진적으로 이관했습니다.

③ 통합 및 라우팅 전략 (Integration & Routing Strategy)

MSA 도입 시 가장 큰 난관은 “수많은 서비스 엔드포인트를 클라이언트가 어떻게 관리할 것인가?”입니다. 우리는 다음 3가지 패턴을 복합적으로 고려했습니다.

• API 게이트웨이 패턴 (API Gateway Pattern): 클라이언트가 수십 개의 마이크로서비스를 직접 호출하는 대신, 단일 진입점(Gateway)을 거치게 합니다. 이를 통해 인증(Auth), 로깅, 라우팅을 중앙화하여 클라이언트의 복잡성을 낮췄습니다.
• 게이트웨이 집계 패턴 (Gateway Aggregation Pattern): 하나의 UI 화면을 그리기 위해 여러 서비스를 호출해야 할 때(예: 상품 정보 + 리뷰 + 추천), 클라이언트가 N번 요청하는 대신 게이트웨이가 이를 모아서(Aggregation) 한 번에 응답해 주는 구조를 지향했습니다. 이를 통해 네트워크 Latency를 획기적으로 줄였습니다.
• API 라우팅 패턴 (Path-Based Routing): 가장 현실적인 구현 전술로, AWS ALB(Application Load Balancer)의 Listener Rule을 활용했습니다. HTTP 요청의 URL Path를 기반으로 트래픽을 적절한 마이크로서비스(Target Group)로 분배하는 방식으로, 별도의 고비용 게이트웨이 솔루션 없이도 효과적인 라우팅을 구현했습니다.

3. 네트워크 아키텍처: 어떻게 연결할 것인가? (The Case Study)

가장 치열하게 고민했던 것은 “클라이언트(App/Web)가 어떻게 마이크로서비스를 호출하게 할 것인가?”였습니다. 우리는 앞서 설계한 전략을 구현하기 위해 4가지 아키텍처를 검토했고, 비용과 효율성 그리고 실현 가능성을 모두 잡은 Case 4를 최종 선택했습니다.

❌ Case 1: ALB to ALB Routing (기술적 불가)

• 개념: 기존 Public ALB 뒤에 내부용 Internal ALB를 두어 라우팅하는 방식
• 제약: AWS 아키텍처상 ALB가 다른 ALB를 Target으로 잡는 것을 직접 지원하지 않아 구현이 불가능했습니다.

❌ Case 2: 별도의 Public ALB 추가 (비용/복잡도 증가)

• 개념: 마이크로서비스 전용 Public ALB를 하나 더 신설
• 단점: 클라이언트(App/Web)가 두 개의 엔드포인트(Legacy용, MSA용)를 관리해야 하므로 코드 복잡도가 증가하고, ALB 비용이 이중으로 발생합니다.

❌ Case 3: 별도의 API Gateway 추가 (성능/비용 이슈)

• 개념: AWS API Gateway를 앞단에 두고 트래픽을 분기 처리
• 단점: API Gateway는 강력하지만 단순 라우팅 용도로 쓰기엔 비용(Request당 과금)이 높고, 홉(Hop)이 늘어나면서 추가적인 Latency(지연)가 발생할 우려가 있었습니다.

✅ Case 4: Public ALB + Multi Target Group (최종 선택)

우리는 기존 자원을 100% 재활용하면서 API Routing Pattern을 가장 효율적으로 구현한 Case 4를 선택했습니다. 이 방식의 가장 큰 특징은 내부 숨겨진 마이크로서비스들은 Internal ALB를 통해서 제공하는 동시에, 직접 외부 노출이 필요할 경우에는 Public ALB를 통해서 제공할 수 있다는 것입니다.

• 구현 방식:

1. 기존 Public ALB의 리스너 규칙(Listener Rule)을 활용합니다.
2. 특정 Path(예: /api/v1/money/*)로 들어오는 요청을 감지합니다.
3. 해당 요청을 기존 ECS Service가 아닌, 신규 ECS Service가 연결된 Target Group으로 라우팅합니다.

• 장점:
• Zero Cost: 추가적인 로드밸런서나 게이트웨이 비용이 없습니다.
• Transparent Migration: 클라이언트는 엔드포인트 변경 없이 기존 도메인 그대로 호출하면 됩니다.
• High Performance: ALB의 고성능 라우팅을 그대로 이용하며 지연 시간을 최소화했습니다.

4. 내부 아키텍처: Clean Architecture & Template Repo

인프라가 준비되었다면, 그 안을 채울 코드의 ‘표준’이 필요합니다. 우리는 마이크로서비스가 난립하는 것을 막고 동일한 개발자 경험(DX: Developer Experience)을 제공하기 위해 표준 템플릿 프로젝트를 만들에 Git 저장소로 제공하였습니다. 따라서 신규 서비스 개발이 필요하면 템플릿 저장소를 Fork하여 빠르게 서비스 개발에 집중할 수 있게 되었습니다.

🛠 Template Project: Python + Hexagonal/Layered Architecture

• Architecture Concept: 외부(Web, DB)와 내부(Domain Logic)를 분리하여, 프레임워크가 바뀌어도 비즈니스 로직은 보호받도록 설계
• Tech Stack: FastAPI, Pydantic, SQLAlchemy, Redis, AWS Adaptor, dependency-injector
• Logging & APM: Sentry, Datadog, Hackle
• Build Tool: pipenv, uv
• Environment Configuration: pyenv + Pydantic Settings + AWS SecretsManager
• Deployment: Docker, AWS ECR & ECS, AWS CodePipeline
• Naming Convention: PEP 8, snake_case

5. 실행 로드맵: 단계별 확산 (Milestone)

우리는 이 전략을 5단계에 걸쳐 점진적으로 실행했습니다.

Phase 1: 기존 서비스들로 기반 구축 (Foundation)

• 비즈니스 로직이 구현된 기존 서비스들을 독커 기반으로 재정비하고, 환변 변수들을 추출하여 외부에서 관리하도록 하였습니다.
• AWS 클라우드에서 운영하기 위해 DevOps 측면에서는 다음과 같은 AWS Cloud Resource들을 추상화하여 AWS CDK로 템플릿화하여 스택 단위로 재사용가능하도록 했습니다.

서비스 스택: Route53, WAF, ALB, TargetGroup, ECS, ECR

배포 스택: CodePipeline, CodeBuild, CodeDeploy, GitHub, Slack Lambda

모니터링 스택: CloudWatch, Metric, Alarm, Event Rule, Dashboard, Slack Lambda

Phase 2: 신규 서비스로 파일럿 수행 (Pilot)

• MSA로 도입을 위해 “충전금 도메인 서비스”를 첫 타자로 선정했습니다. 회사의 매출과 직결되는 서비스인만큼 신중한 도입이 필요했습니다. 안전한 도입을 위해 두단계로 나눠서 진행했습니다.
• 첫 단계는 PoC 기반으로 빠르게 서비스를 런칭하기 위해서 비즈니스 로직을 마이그레이션하지 않고, 충전금이 사용되는 곳곳에서 이력만 로깅할 수 있도록 로깅 API만 제공하고 Microservice를 위한 전용 도메인 데이터용 테이블들만 정의하여 데이터를 쌓기만 하였습니다.
• 두번째 단계는 곳곳에 로깅하던 부분의 비즈니스 로직들을 신규 API를 만들고 마이그레이션하였습니다. 이 과정에서도 이미 만들어 놓은 로깅과 비교하면서 데이터 누락을 검증할 수 있었습니다.

Phase 3: 신규 서비스 확대 가속화 (Expansion)

• 새로운 서비스들도 쉽고 빠르게 MSA를 시작할 수 있도록 “충전금 도메인 서비스”에서 충전금 관련된 비즈니스 로직을 제거하고 기본 기능들만을 분리하여 template project를 만들고 git repository로 제공하도록 하였습니다.
• 이제 검증된 템플릿을 바탕으로 신규 서비스들는 template repository를 fork하는 방식으로 빠르게 찍어내기 시작했습니다. 검색 서비스를 필두로 AI 서비스, 인증 서비스 그리고 채팅 서비스들을 순차적으로 런칭했습니다. (마이그레이션 마이크로서비스: 충전금 서비스, 검색 서비스 / 신규 마이크로서비스: AI 서비스, 인증 서비스, 채팅 서비스)

Phase 4: 모놀리스 해체 (Decomposition)[진행 중]

• 이제 칼을 들어 기존 모놀리스 서버를 더욱 강하게 도려내기 시작했습니다. 각 컨텐츠 API 서버들과 관리자 백오피스 서버들에 공통으로 얽혀있던 로직들을 하나씩 떼어내어 새로운 서비스로 분리하기 시작했습니다.
• 또한 네트워크 구성적으로 ALB → Multiple Target Group →ECS Service 연결의 안정성을 검증했습니다.

Phase 5: 고도화 (Service Mesh)[진행 중]

• 서비스 간 통신이 복잡해짐에 따라, 향후 Istio나 App Mesh 같은 Service Mesh 도입을 고려하여 관측성(Observability)을 강화하고 있습니다.

6. 마치며: 기술은 비즈니스의 속도를 위해 존재한다!

우리의 MSA 전환은 “넷플릭스가 하니까” 혹은 “멋있어 보여서” 시작한 것이 아닙니다. “중복 코드를 없애고, 재사용성을 높여 개발 속도를 높이고, 배포의 공포를 없애기 위해” 시작했습니다.

이 과정에서 현재 운영 및 개발 중인 사일로(스쿼드) 배포를 멈추지 않으면서 동시에 MSA화하는 것이 스타트업 비즈니스에서 매우 중요합니다. 바비톡이 선택한 방식은 비즈니스 속도를 유지하면서 안정적으로 진행되었다는 것입니다. 특히 무작정 모든 영역에 MSA화하는 것은 추후 유지보수가 더 어려워질 수 있기 때문에 조직의 성장과 조직 구성에 맞춰서 점진적으로 이뤄지고 있습니다.

AWS ALB/ECS와 CDK를 활용한 우리의 ‘Case 4 전략’은 교과서에 나오는 가장 우아한 아키텍처는 아닐지 모릅니다. 하지만 비용을 아끼고, 클라이언트의 변화를 최소화하며, 가장 빠르게 MSA로 넘어갈 수 있었던 가장 현실적인 정답이었습니다.

현재 1)AWS ECS 기반으로 서비스를 운영하고 계시고, 2)필요 이상의 DevOps 유지보수를 들이지 않으면서 동시에 3)빠르고 안정적으로 MSA화하고 싶으시다면 바비톡이 제안하는 아케텍처를 한번쯤 레퍼런스로 고민해보시면 좋을 것 같습니다.

7. 레퍼런스

• AWS ECS Multiple Target Group: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html
• 서비스 분해: https://medium.com/byungkyu-ju/마이크로서비스패턴-2-2장-2-2-53e7bd6c6ebf
• Domain Driven Design: https://kkimsangheon.github.io/2019/06/06/msa1/
• API Gateway Pattern: https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern
• Gateway Aggregation Pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation
• Strangler Pattern: https://learn.microsoft.com/ko-kr/azure/architecture/patterns/strangler-fig
• API Routing Pattern: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/api-routing-path.html

컨테이너 기반 마이크로 서비스(MSA) 전략과 마이그레이션 여정 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

지난 3년, 우리 조직은 폭발적으로 성장했습니다. 하지만 비즈니스의 속도가 빨라질수록, 초기에 구축했던 시스템은 거대한 ‘기술 부채’가 되어 우리의 발목을 잡기 시작했습니다.

이 글은 거대하고 불투명했던 Monolithic 시스템을 AWS Cloud Native 환경으로 전환하며 겪었던 치열한 기술적 의사결정과 구체적인 실행 전술, 그리고 그 결과에 대한 기록입니다.

1. 배경: “누가 배포했는지 아무도 모른다”

3년 전, 우리의 백엔드 시스템은 거대한 Monolithic 구조였습니다. 하지만 진짜 문제는 구조 자체가 아니라 ‘확장 불가능한 운영 방식’에 있었습니다.

• Shadow IT & Manual Deployment: 개발자가 개인 PC에서 Elastic Beanstalk CLI를 통해 EC2에 직접 배포했습니다. 배포 이력은 남지 않았고, 누가 언제 무엇을 수정했는지 추적할 수 없는 '블랙박스' 상태였습니다.
• 인프라의 한계: 개발/QA/Live 환경의 경계가 모호했고, 소수의 인원이 ‘감’으로 유지하는 구조였습니다. 트래픽이 급증하거나 동시 개발 인원이 늘어날 때마다 인프라 리소스 부족과 충돌 문제에 시달렸습니다.

우리는 결단이 필요했습니다. 단순히 서버의 구성을 변경하거나 옮기는 것이 아니라, 앱 현대화(App Modernization)를 통해 지속 가능한 성장 기반을 만들어야 했습니다. 비즈니스 성과를 만들내기 위해 성공적인 앱 현대화는 다음 항목들에 대한 총체적인 접근과 지원이 필요합니다.

• 비즈니스 민첩성: 비즈니스 요구사항을 실제 기능으로 전환하는 속도로써 개발 조직이 비즈니스 요청에 얼마나 빠르게 대응하는지, 기능을 프로덕션에 배포하는 과정을 비즈니스가 얼마나 통제할 수 있는지를 의미합니다.
• 조직 민첩성: 애자일 방법론과 DevOps 문화를 포함하는 전달 프로세스 성숙도 정도로써 조직 전반에 걸친 명확한 역할 분담과 원활한 협업 및 커뮤니케이션을 지원합니다.
• 엔지니어링 효율성: 얼마나 빠르고 안전하고 효율적으로 개발할 수 있는지에 대한 척도로써 품질 보증, 테스트, CI/CD, 구성 관리, 애플리케이션 설계, 소스 코드 관리의 개선을 포함합니다.

2. 전략: 4가지 현대화 전술의 조화 (The 4 R’s)

우리는 무작정 MSA로 직행하는 위험한 도박 대신, AWS의 앱현대화 전략을 우리 상황에 맞춰 4가지로 분류하고 적재적소에 배치했습니다.

1. Lift & Shift: 데이터센터 자원을 클라우드로 옮기는 1차적 이동 → 이미 AWS Cloud에서 운영 중이라서 미대상
2. Re-Platform (VMs → Containers): 비즈니스 로직 수정 없이 컨테이너화를 통해 운영 효율성을 높이는 단계 → 복잡하고 무거운 monolithic 서버들이 대상
3. Refactor (Monolithic → Microservices): 핵심 도메인을 분리하여 결합도를 낮추는 단계 → 중요하고 여러 곳에서 반복 사용되는 관련도 높은 도메인들이 대상
4. Re-Invent (Host fleets → Serverless): 클라우드 네이티브의 장점을 극대화하는 단계 → 운영 부담을 줄이면서 가볍고 독립적인 신규 서비스들 대상

이 4가지 전략을 바탕으로 ‘어떤 서비스’를 ‘어떤 방식’으로 전환할지 결정하는 구체적인 전술을 수립했습니다.

3. 전술: 악마는 디테일에 있다 (Specific Tactics)

전략이 방향성이라면, 전술은 생존 방식입니다. 우리는 다음과 같은 5가지 핵심 전술을 통해 마이그레이션을 완수했습니다.

① Infra as Code: CDK를 통한 플랫폼 엔지니어링

우리는 모든 인프라를 단순한 설정 파일(YAML)이 아닌, AWS CDK(Cloud Development Kit)를 사용하여 OOP(객체 지향 프로그래밍) 방식으로 구현했습니다.

• 추상화와 모듈화: 자주 사용하는 인프라 구성을 패턴으로 추상화시켜 OOP 기반으로 모듈화하고, 스택 기반으로 템플릿화하여 재사용성을 극대화했습니다. 따라서 바비톡의 DevOps엔지니어는 기본적으로 OOP 경험을 필수입니다.
• CDD (Configuration Driven Development): 서버마다 다른 리소스 스펙이나 환경 변수는 Configuration으로 주입받게 설계했습니다. 이를 통해 ‘One Source Multiple Deploy’를 실현, 하나의 코드로 다양한 환경을 손쉽게 재배포할 수 있는 플랫폼 엔지니어링 기반을 마련했습니다. 예를 들어 ECS 기반 컨테이너 서빙과 Lambda 기반 서버리스 서빙하는 모든 영역을 하나의 CDK Stack으로 서로 다른 프로젝트/서비스/팀에 배포 가능합니다.

② “Dual Track” 아키텍처: Container vs Serverless

우리는 서비스의 성격에 따라 컴퓨팅 환경을 이원화했습니다.

• Track A. 안정성 중심 (ECS/Fargate): 트래픽이 예측 가능하고 무거운 비즈니스 로직을 수행하는 핵심 서비스는 Container 기반으로 전환했습니다.
• Track B. 민첩성/효율성 중심 (Serverless): 트래픽이 들쑥날쑥하거나 독립적인 보조 서비스(액세서리 기능)는 AWS Lambda + API Gateway/Event Bridge 조합의 서버리스를 채택했습니다.

③ 스트랭글러(Strangler) 패턴의 정교한 적용

시스템을 한 번에 끄고 새로 켜는 빅뱅 방식 대신, 기존 시스템 주위에 새로운 MSA를 덩굴처럼 키워나가는 방식을 택했습니다.

예를 들어 money Box(충전금 도메인)의 경우, 가장 민감한 돈 관련 로직은 여러 모놀리식 서버들에서 하드코딩되어 중복 코드들이 서로 미묘하게 다르게 구현되어 있었습니다. 이에 대한 마이그레이션 단계는 아래와 같이 2단계로 나눠서 진행되었습니다.

1. Logging Phase: 초기 릴리즈에서는 로직 실행 없이, 각 서버의 충전금 증감 내역을 무결하게 기록(Logging)하는 기능만 수행하며 데이터 누락과 동시성 검증을 거쳤습니다.
2. Migration Phase: 검증 완료 후 가상충전 → CPA/CPV → 부가상품 구매 순으로 Usecase를 하나씩 이관했습니다.

또한 search Box (검색 도메인)의 경우, CRUD 중 데이터 변경 위험이 없는 Read(조회) 쿼리부터 분리하고, 이후 CUD(인덱싱/업데이트) 이벤트를 최종적으로 마이그레이션했습니다.

④ 데이터 스토리지 최적화 (Polyglot Persistence)

RDB 만능주의에서 벗어나 데이터의 목적에 맞는 저장소를 적재적소에 배치했습니다. 예를 들어 실시간 로깅을 위해서는 AWS Kinesis를, 대용량 데이터 수집을 위해서는 DynamoDB를, 데이터 캐싱은 ElasticCache와 memoryDB를 선택적으로 도입하였습니다.

⑤ 거버넌스와 DevOps 역할의 재정의

AWS 계정을 목적(운영/데이터/분석/관리)에 따라 물리적으로 분리하고, 개발자(CI 집중)와 DevOps(CD 전담)의 역할을 명확히 나누어 배포의 투명성과 추적성을 보장했습니다.

4. 성과 및 임팩트

3년의 치열한 여정 끝에 우리는 명확한 기술적 성취를 달성했습니다. 단순한 인프라 변경이 아닌, 비즈니스 속도를 가속화하는 엔진을 교체한 결과입니다.

🛠️ 마이그레이션 현황 (Implementation Status)

우리는 각 서비스의 특성에 맞춰 3가지 현대화 전략을 차별적으로 적용했습니다.

1. Re-Platform (VMs → Containers)

• 대상: 주요 API 서버, Utility 서버, Batch 서버
• 성과: 기존 Elastic Beanstalk(EC2)에서 운영되던 서비스들을 독커 컨테이너로 패키징한 후 AWS ECS(EC2/Fargate)로 이관을 완료했습니다. 가장 큰 수확은 ‘안전장치 확보’였습니다. 컨테이너 환경의 안정성 덕분에, 이후 내부 구조를 Layered Architecture로 리팩토링하고 재배포하는 과정을 두려움 없이 반복할 수 있었습니다.

2. Refactor (Monolithic → Microservices)

2.1 레거시 분리를 분리한 케이스들

• 대상: 무겁고 중복이 심했던 핵심 도메인을 Clean Architecture 기반의 MSA로 분리했습니다.
• 성과: money_box (충전금 전담), search_box (검색 전담)

2.2 신규 서비스로 런칭한 케이스들

• 대상: 새로운 기획된 서비스들은 Microservice First 전략으로 설계하여 빠르게 런칭했습니다.
• 성과: aiml_box (AI Agent), auth_box (인증), chat_box (채팅)

3. Re-Invent (Host fleets → Serverless)

• 대상: 트래픽 예측이 불가능하고 메인 서비스와 의존성이 낮은 보조(Accessory) 서비스
• 성과: message_box (알림톡/이메일), crm_box (마케팅 자동화), data_box (통계/분석)

📈 정량적 성과 (Quantitative Impact)

• 배포 파이프라인: 0개(수동) → 300개 이상의 자동화된 CI/CD 파이프라인 구축
• 배포 속도: 1시간 이상 소요 → 수 분 단위로 단축
• 확장성: 3개의 Monolithic 서버 → 5개의 API 서버 + 20여 개의 MSA 서버로 분화
• Observability: 인프라/운영 알람 수백 개 신설하여 장애 가시성 확보
• Time-to-Market: 신규 MSA 서비스 런칭 준비 기간 1주일 → 1일로 단축

🚀 정성적 성과 (Organizational Impact)

가장 드라마틱한 변화는 조직의 ‘일하는 방식’에서 일어났습니다.

• 병렬 개발(Parallelism) 실현: 과거에는 하나의 코드를 수정하기 위해 모두가 대기해야 했지만, 이제는 앞단의 API 서버 팀과 뒷단의 공통 MSA 서버 팀이 병렬적으로 개발합니다. 전문성은 높아지고, 의존성은 낮아졌으며 생산성은 높아졌습니다.
• 조직의 확장: 초기 2개의 사일로(Silo)였던 개발 조직이 9개 사일로(Silo)까지 늘어났음에도, 운영상의 복잡도 증가나 병목현상 없이 기민하게 움직이고 있습니다.

5. 회고, Lessons Learned

물론 기술적 전환보다 더 어려웠던 것은 ‘문화’와 ‘관성’을 바꾸는 일이었습니다.

1. 속도와 표준화의 균형 MSA 도입 초기, 제로 베이스에서의 시작은 오히려 속도를 늦췄습니다. 이를 해결하기 위해 재사용 가능한 코드와 모듈을 템플릿화하여 레포지토리로 제공하는 ‘내부 표준화’ 작업에 집중했습니다. 파편화된 개발 경험을 하나로 묶는 것이 효율성의 핵심이었습니다.

2. Conway의 법칙 (조직 구조의 재편) “시스템 구조는 조직 구조를 닮는다”는 말처럼, 아키텍처 변화에 맞춰 조직도 개편했습니다. 비즈니스 로직을 전담하는 ’서비스 개발팀’과 공통 모듈/인프라를 지원하는 ’MSA 플랫폼팀’으로 나누어 전문성을 강화하고 역할(R&R)을 명확히 했습니다.

3. 리더가 먼저 깨트리는 관성 익숙한 레거시 방식이 편한 것은 당연합니다. 이를 타파하기 위해 저는 Self-Reference(자기 참조) 전략을 택했습니다. CTO인 제가 먼저 새로운 기술을 직접 시도하고, 멤버들에게 전파하는 순환고리를 만들었습니다. 리더가 먼저 움직일 때, 팀은 변화를 ‘숙제’가 아닌 ‘즐거운 도전’으로 받아들였습니다.

마치며

이론적으로 완벽한 아키텍처는 많습니다. 하지만 “우리 비즈니스 상황과 우리 팀의 역량에 맞는가?”라는 질문에 답을 내리고, 결단력 있게 실행에 옮기는 것이 CTO의 역할이라 생각합니다. 우리의 현대화 여정은 이제 막 첫 단추를 끼웠을 뿐이며, 앞으로도 우리는 계속해서 진화할 것입니다.

본 글이 이미 스타트업으로써 서비스를 시작하였으나 정체 기간을 거쳐 서비스와 조직이 한 스텝 점프하길 원하시는 조직들에게 좋은 경험담이 되었으면 합니다. 또한 AWS 기반으로 Cloud Native(클라우드 친화적인) 전개를 고민하시는 조직들에게도 유익한 글이 되었으면 합니다.

후속 블로그들(컨테이너 기반 마이크로서비스, 서버리스 기반 마이크로서비스)에서 관련된 상세 경험들이 시리즈 형태로 제공될 예정입니다.

6. 레퍼런스

• AWS 앱 현대화 권장 가이드: https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-modernizing-applications/targeted-business-outcomes.html
• 바비톡의 클라우드 친화적인 Data 기반 AI와 앱현대화 전략 : https://www.youtube.com/watch?v=FFYiSysy-o0
• 현대적 애플리케이션 길잡이, AWS Cloud Development Kit: https://www.youtube.com/watch?v=6i7DgQzYYAo
• AWS CDK Project Template for DevOps: https://github.com/aws-samples/aws-cdk-project-template-for-devops
• Amazon Cognito and API Gateway based machine to machine authorization using AWS CDK: https://github.com/aws-samples/amazon-cognito-and-api-gateway-based-machine-to-machine-authorization-using-aws-cdk

앱 현대화(App Modernization) 전략과 아키텍처 개선 여정 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

테스트 자동화 도입 배경

안녕하세요! 바비톡 QA팀의 곽선명 입니다.

바비톡은 2주 단위로 업데이트를 하며, 크고 작은 변화들이 생깁니다.
QA 팀은 업데이트된 앱에서 사용자가 문제를 겪지 않도록 배포 주기에 맞추어 stage 환경에서 통합 테스트를 수행하는데, 앱의 주요 기능들을 꼼꼼히 확인하다 보니 아래의 같은 문제들이 발생하였습니다.

• 매뉴얼 테스트 수행 시간이 지나치게 길었습니다. 현재 바비톡에서 베타 배포 전 확인 하는 체크리스트 370여 개를 iOS/AOS 각각의 플랫폼에서 수행해야 하고, 다른 업무도 병행해야 하니 병목 현상을 일으켰습니다.
• 테스트 결과의 일관성이 저하될 리스크가 있었습니다. 테스터 마다 수행 방식과 결과 해석이 다를 수 있는 여지가 있었습니다.
• 휴먼 에러가 발생할 리스크가 있었습니다. 다수의 케이스를 매뉴얼로 테스트 하게되면 자연스럽게 집중력이 저하되어 버그를 놓칠 가능성이 없다고 할 수 없습니다.

이와 같은 문제들은 테스트 자동화 도입을 고려하고 있거나, 생각해 본 적이 있다면 공감하실 부분이라고 생각합니다. 바비톡 QA 팀 역시 위와 같은 문제에 대해 인지하고 있었기 때문에 테스트 자동화를 도입하기로 결정 하였습니다.

이 글은 자동화 테스트 도입에 대해, 또는 도입을 결정하였으나 구축 방법에 대해 고민하는 분들을 위해 작성되었습니다.

자동화 케이스 선정

QA 팀은 바비톡 배포가 있을 때마다 stage 환경에서 서비스 핵심 기능 기준으로 작성된 통합 테스트 케이스를 수행합니다. 문제가 발생할 경우 사용자와 비즈니스적 측면에서 높은 영향도를 주는 케이스들로 선정되어 있고, 다른 업무와 병행하며 매뉴얼 테스트로 수행하는 경우 약 8시간 정도가 소요되는 것으로 측정되어 하루 업무 시간을 모두 소진해야 했습니다.

바비톡의 주요 기능들에 대한 케이스이면서 반복적으로 수행하는 케이스이기에, 자동화 케이스로 적절하다고 판단하였습니다.

구현 방법

바비톡 QA 팀에서 사용하는 툴 및 프레임워크에 대한 간단한 설명과 구현 방법에 대해 설명하겠습니다.

각 플랫폼별로 사용 하는 툴과 담당자가 다릅니다.

• AOS : 파이썬 기반의 appium + robotframework
• iOS : 파이썬 기반의 appium + gague
• Web : 파이썬 기반의 selenium

환경 별 툴 및 프레임워크를 다르게 사용한 이유는 아래와 같습니다.

• 플랫폼 별 담당자가 분리되어 있어 각자 선호도와 숙련도에 따른 툴 선택
• 플랫폼 별 독립적인 테스트 운영으로 유연성 확보
• 플랫폼 별 독립적인 유지보수로 코드 관리가 더 명확
• 각 플랫폼의 버전 업데이트나 변경사항에 더 유연하게 대응
• 플랫폼 별 테스트 코드의 책임 소재가 명확

툴 및 프레임워크의 설정과 구현 방법은 macOS와 brew 가 설치된 상태로 가정하였으며 실제 기기에서 동작하도록 작성되었습니다.

iOS

• Appium 설치

# Node.js & Appium 설치
brew install node
npm install -g appium
# appium 상태 확인
npm install -g appium-doctor

# Appium Inspector 설치
brew install --cask appium-inspector 또는
<https://github.com/appium/appium-inspector> 에서 설치

• Xcode 에서 WebDriverAgent 설정

# 1. Xcode 및 Command Line Tools 설치 확인
xcode-select --install

# 2. WebDriverAgent 설정
cd /usr/local/lib/node_modules/appium/node_modules/appium-webdriveragent
open WebDriverAgent.xcodeproj

# 3. Xcode에서 설정
- Signing & Capabilities에서 Team 선택
- Bundle Identifier 설정
- 타겟 디바이스 선택

# 4. 실제 디바이스에서 WDA 빌드 테스트
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination 'id=<device_udid>' test

WebDriverAgent(WDA)는 iOS 앱 자동화 테스트를 위한 WebDriver 서버입니다. Facebook이 개발했으며, Appium이 iOS 디바이스와 통신하기 위해 사용하는 프록시 역할을 합니다. XCTest framework를 기반으로 하여 실제 디바이스나 시뮬레이터의 UI 요소를 찾고 조작할 수 있습니다.

• Gauge Framework 설정

# Gauge CLI 설치
brew install gauge

# 언어 러너 설치 (python 사용 시)
gauge install python

# IDE 플러그인 설치 (VSCode 사용 시)
gauge install vscode

Gauge Framework는 테스트 시나리오를 누구나 읽기 쉬운 문서 작성 방식으로 작성할 수 있게 해주는 테스트 자동화 도구입니다. 테스트 결과를 보기 좋은 HTML 리포트로 자동 생성하고 실패한 테스트에 대한 스크린샷과 로그를 자동으로 수집하여 문제 파악이 쉽다는 장점이 있습니다.

• Capabilities 예시

{
    'platformName': 'iOS',
    'deviceName': '실제 디바이스명',
    'udid': '디바이스 UDID',
    'automationName': 'XCUITest',
    'app': '앱 경로.app',
    'bundleId': 'com.example.app',
    'xcodeOrgId': '개발자 계정 Team ID',
    'xcodeSigningId': 'iPhone Developer'
}

Capability는 테스트 자동화 세션의 설정을 정의하는 키-값 쌍의 JSON 객체입니다. 테스트할 플랫폼, 디바이스, 앱 정보 등 테스트 환경과 동작 방식을 Appium 서버에 전달하는 역할을 합니다. 실제 Capability는 테스트 환경에 따라 달라질 수 있습니다.

AOS

• 기본 도구 및 Appium 설치

# 1. 기본 도구 설치
brew install node python openjdk android-sdk android-platform-tools ruby
pip install --upgrade pip

# 2. Appium 관련 설치
npm install -g appium appium-doctor
npm install appium-uiautomator2-driver
brew install --cask appium-inspector

• Robotframwork 설정 및 실행 방법

# 1. Robot Framework 설치
pip install robotframework robotframework-appiumlibrary pytest robotframework-seleniumlibrary robotframework-debuglibrary

# 2. 환경변수 설정 (~/.zshrc)
export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools
export JAVA_HOME=$(/usr/libexec/java_home)

# 3. 디바이스 설정 및 테스트
adb devices  # 디바이스 확인
appium --base-path /wd/hub  # Appium 서버 실행
robot test.robot  # 테스트 실행

• Capabilities 예시

{
    'platformName': 'Android',
    'deviceName': '디바이스명',
    'udid': '디바이스 ID',
    'automationName': 'UiAutomator2',
    'app': '앱 경로.apk',
    'appPackage': 'com.example.app',
    'appActivity': 'com.example.app.MainActivity',
    'noReset': True,
    'autoGrantPermissions': True
}

Capability는 테스트 자동화 세션의 설정을 정의하는 키-값 쌍의 JSON 객체입니다. 테스트할 플랫폼, 디바이스, 앱 정보 등 테스트 환경과 동작 방식을 Appium 서버에 전달하는 역할을 합니다. 실제 Capability는 테스트 환경에 따라 달라질 수 있습니다.

Selenium

• 기본 도구 및 라이브러리 설치

# Python & pip 설치
brew install python

# Selenium 설치
pip install selenium

# WebDriver 설치
brew install --cask chromedriver  # Chrome용
brew install --cask geckodriver   # Firefox용

# 필요한 추가 라이브러리
pip install pytest  # 테스트 프레임워크
pip install pytest-html  # HTML 리포트
pip install selenium-page-factory  # Page Object 패턴 지원

구현

Stage 통합 테스트 케이스 중 일부인 바비톡에서 이메일로 로그인 하는 flow를 자동화해 보겠습니다. 기본적으로 자동화 구현은 Appium Inspector 또는 개발자 도구에서 정의된 elements를 찾고 해당 elements를 원하는 flow로 구현하는 방식입니다.

• 암호 등의 일부 민감 정보는 제외되어 있습니다.

iOS

import logging
import time

from appium import webdriver
from appium.webdriver.common.appiumby import AppiumBy
from appium.options.ios import XCUITestOptions
from getgauge.python import step
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.common.exceptions import TimeoutException, NoSuchElementException, StaleElementReferenceException

# 로깅 설정
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)

class WebDriverHelper:
   def __init__(self):
       self.driver = None
       self.wait = None
       self.DEFAULT_WAIT_TIME = 6
       self.SHORT_WAIT_TIME = 3

   def initialize_driver(self):
       """WebDriver 초기화 및 최적화된 설정"""
       options = XCUITestOptions()
       # 기본 capabilities
       base_caps = {
           'platformName': 'iOS',
           'platformVersion': '18.1',
           'automationName': 'XCUITest',
           'deviceName': 'smgwakiphone',
           'udid': '-',
           'xcodeSigningId': 'iOS Developer',
           'xcodeOrgId': '776KKAJ27S',
           'bundleId': '-',
           # 세션 안정성을 위한 추가 설정
           'newCommandTimeout': 3600,
           'wdaStartupRetries': 4,
           'wdaStartupRetryInterval': 20000,
           'shouldTerminateApp': False,
           'webviewConnectTimeout': 90000,
           'clearSystemFiles': True,
           '“connectHardwareKeyboard':True

       }
       
       # 성능 최적화 capabilities
       performance_caps = {
           'fullContext': False,
           'autoAcceptAlerts': True,
           'reduceMotion': True,
           'useNewWDA': False,
           'waitForQuiescence': False,
           'useJSONSource': True,
           'elementResponseAttributes': 'type,label',
           'shouldUseSingletonTestManager': False,
           'maxTypingFrequency': 10,
           'includeNonModalElements': False
       }
       
       # Capabilities 설정
       for k, v in {**base_caps, **performance_caps}.items():
           options.set_capability(k, v)

       appium_server_url = '<http://localhost:4723>'
       self.driver = webdriver.Remote(appium_server_url, options=options)
       self.wait = WebDriverWait(self.driver, self.DEFAULT_WAIT_TIME)
       return self.driver

   def wait_and_find_element(self, locator, timeout=None):
       """요소를 찾을 때까지 대기"""
       wait_time = timeout if timeout else self.DEFAULT_WAIT_TIME
       try:
           element = WebDriverWait(self.driver, wait_time).until(
               EC.presence_of_element_located(locator)
           )
           return element
       except Exception as e:
           logger.error(f"요소가 노출되지 않음: {locator}")
           raise e

   def wait_and_click(self, locator, timeout=None):
       """요소를 찾아서 클릭"""
       try:
           element = self.wait_and_find_element(locator, timeout)
           element.click()
       except Exception as e:
           logger.error(f"element 선택 실패: {locator}")
           raise e

# WebDriver 헬퍼 인스턴스 생성
helper = WebDriverHelper()
driver = helper.initialize_driver()

  @step("이메일 로그인")
def emaillogin():
   try:
       helper.wait_and_click((AppiumBy.IOS_CLASS_CHAIN,'**/XCUIElementTypeStaticText[`name == "다른 방법으로 시작하기"`]'))
       helper.wait_and_click((AppiumBy.ACCESSIBILITY_ID, 'icn email login'))
       helper.wait_and_click((AppiumBy.ACCESSIBILITY_ID, '로그인'))
       
       # 이메일 입력
       email_field = helper.wait_and_find_element((AppiumBy.ACCESSIBILITY_ID, 'a_emaillogin_input_email'))
       email_field.send_keys('-')
       
       # 비밀번호 입력
       password_field = helper.wait_and_find_element((AppiumBy.ACCESSIBILITY_ID,'a_emaillogin_input_password'))
       password_field.send_keys(- + '\\n')  # \\n으로 리턴키 입력
       logger.info("이메일 로그인 성공")
   except Exception as e:
       logger.error(f'이메일 로그인 실패: {e}')

Android

Click Element With Wait
    [Arguments]    ${locator_type}    ${locator_value}    ${TIMEOUT}=10    ${RETRY_COUNT}=3
    ${index}    Set Variable    0
    FOR    ${index}    IN RANGE    ${RETRY_COUNT}
        Run Keyword If    '${locator_type}' == 'id'              Wait Until Element Is Visible    id=${locator_value}    ${TIMEOUT}
        Run Keyword If    '${locator_type}' == 'xpath'           Wait Until Element Is Visible    xpath=${locator_value}    ${TIMEOUT}
        Run Keyword If    '${locator_type}' == 'text'            Wait Until Page Contains Element    ${locator_value}    ${TIMEOUT}
        Run Keyword If    '${locator_type}' == 'resource-id'     Wait Until Element Is Visible    id=${locator_value}    ${TIMEOUT}
        Run Keyword If    '${locator_type}' == 'accessibility_id'     Wait Until Element Is Visible    accessibility_id=${locator_value}    ${TIMEOUT}

        ${result}    Run Keyword And Ignore Error    Click Element    ${locator_type}=${locator_value}
        Exit For Loop If    '${result[0]}' == 'PASS'

        Log    StaleElementReferenceException occurred, retrying...    WARN
    END
    
# 클릭 및 입력 액션
Click And Input Text With Wait
    [Arguments]    ${locator_type}    ${locator_value}    ${text_to_input}
    Run Keyword If    '${locator_type}' == 'id'              Wait Until Element Is Visible    id=${locator_value}    ${TIMEOUT}
    Run Keyword If    '${locator_type}' == 'xpath'           Wait Until Element Is Visible    xpath=${locator_value}    ${TIMEOUT}
    Run Keyword If    '${locator_type}' == 'accessibility_id'           Wait Until Element Is Visible    accessibility_id=${locator_value}    ${TIMEOUT}
    Click Element    ${locator_type}=${locator_value}
    Input Text    ${locator_type}=${locator_value}    ${text_to_input}
    
    
로그인> 이메일
    Click Element With Wait    id    com.sleet.beautyplastic.dev:id/email_login
    Click Element With Wait    xpath    //android.widget.TextView[@text="로그인"]
    Click And Input Text With Wait  accessibility_id    a_emaillogin_input_email    ${email}
    Click And Input Text With Wait  accessibility_id    a_emaillogin_input_password    ${password}
    Hide Keyboard
    Click Element With Wait    id    com.sleet.beautyplastic.dev:id/login

Selenium

def click_login_join(wait): 
    login_join_div = wait.until(
        EC.presence_of_all_elements_located((By.CSS_SELECTOR, "div.flex.flex-none"))
    )       
    #login_join_div = driver.find_elements(By.CSS_SELECTOR, "div.flex.flex-none")
    # "로그인 및 회원가입" 버튼 클릭
    for login_signup_button in login_join_div:
        if login_signup_button.text == "로그인 및 회원가입":
            login_signup_button.click()
            time.sleep(3)  # 필요한 경우 대기
            break
    print("로그인 및 회원가입으로 이동했습니다.")
    

def click_join_emali(wait):       
    join_emali_buttons = wait.until(
        EC.presence_of_all_elements_located((By.CSS_SELECTOR, "button.flex.justify-center"))
    )   
    #join_emali_buttons = driver.find_elements(By.CSS_SELECTOR, "button.flex.justify-center")
    for join_emali_button in join_emali_buttons:
        if "이메일로 시작하기" in join_emali_button.text:
            join_emali_button.click()  # 부모 button 클릭            
            time.sleep(3)  # 필요한 경우 대기
            break

def input_field_text(wait, input_text):  
       
    if '이메일을 입력해주세요' in input_text:
        input_field = wait.until(
        EC.presence_of_all_elements_located((By.CSS_SELECTOR, f"div > input[placeholder='{input_text}']"))
        )
        input_field[0].send_keys(-)
        time.sleep(2)  # 필요한 경우 대기
        
        
    if '비밀번호를 입력해주세요' in input_text:
        input_field = wait.until(
        EC.presence_of_all_elements_located((By.CSS_SELECTOR, f"div > input[placeholder='{input_text}']"))
        )
        input_field[0].send_keys(-)
        time.sleep(2)  # 필요한 경우 대기
        input_field[0].send_keys(Keys.ENTER) 
        time.sleep(2)

현재까지의 성과

현재 자동화 커버리지는 약 16%이며, 이는 60개의 테스트 케이스(TC)에 해당합니다. 이 60개 TC의 자동화 테스트 수행 시간은 약 10초 정도로, 수동 테스트에 비해 상당한 시간 단축 효과를 가져올 것으로 예상합니다.

1. 예상 절감 리소스

• 테스트 투입 공수(Man/Hour) 37.5% 절감
• 수동으로 테스트(매뉴얼) 시, 2명이 8시간씩 소요 = 총 16시간 소요
• UI 테스트 자동화 적용 후 인당 3시간씩 절감 = 총 6시간 절감
• 총 테스트 시간 약 37.5% 절감
• 결과적으로 6시간(man-hour) 절감

수행 시간 단축 외에도, 자동화 도입으로 인해 휴먼 에러가 감소하고 업무 병목 현상 또한 미미하게나마 줄어들었다고 판단하고 있습니다. 자동화 커버리지가 높아질수록 이러한 긍정적인 성과들이 더욱 증폭될 것으로 기대하고 있습니다.

어려웠던 문제

바비톡에는 고객 편의를 위해 노출 되는 바텀시트나 팝업들이 있는데요, 이 부분들을 자동화 하기가 쉽지 않았습니다. 마찬가지로 웹뷰로 되어 있는 화면을 자동화할 때도 어려움을 겪었습니다.

처음에는 모든 바텀시트나 웹뷰를 강제로 닫아버릴까도 생각했지만, 기능들이 정상 동작하는지 확인하려는 목적을 가진 테스트에서 적합하지 않다고 판단했습니다.

따라서 현재 context 를 확인하고 바텀시트나 웹뷰의 context 로 전환하여 기능을 수행을 하는 방법을 적용하었습니다. 혹은 해당 요소의 좌표를 직접 받아와서 선택하는 방식으로 문제를 해결했습니다.

1. 요소의 위치와 크기 정보로 자동화한 케이스

• Safari 의 닫기(완료) 버튼을 위치로 특정하여 선택하도록 하였다.

def click_safari_done_button(helper): #사파리 완료 버튼 선택 #고정
    try:
        # 완료 버튼 찾기
        element = WebDriverWait(helper.driver, 5).until(
            EC.presence_of_element_located((AppiumBy.IOS_CLASS_CHAIN, '**/XCUIElementTypeButton[`label == "완료"`]'))
        )
        
        # 요소의 위치와 크기 정보 가져오기
        location = element.location
        size = element.size
        
        # tap 스크립트로 클릭 실행
        helper.driver.execute_script('mobile: tap', {
            'x': location['x'] + size['width']/2,
            'y': location['y'] + size['height']/2
        })
        logger.info("safari 완료 버튼 선택 성공")
        return True
        
    except Exception as e:
        logger.error(f"safari 완료 버튼 선택 실패: {e}")
        return False

elements를 찾고 기능을 수행할 때 context 도 전환해야 할 때와 그렇지 않을 때가 아직 완벽하게 구분되지는 않습니다. 하지만 이 과정에서 어느 정도 핵심을 파악했고, 앞으로도 계속해서 탐구해야 할 부분이라고 생각합니다.

앞으로의 목표

아직 자동화 커버리지도 낮고 효율을 높이기 위해 해야 할 일이 많지만,
바비톡 QA 팀은 다음과 같은 명확한 목표를 가지고 있습니다.

1. 통합 테스트 케이스 커버리지 상향 및 유지

현재 커버리지를 하반기 내로 30% 이상으로 높이고 기능 추가나 변경이 있을 때도 이 커버리지를 꾸준히 유지하는 것을 목표로 합니다. 이는 단순히 수치를 높이는 것을 넘어, 변화하는 서비스 환경에서도 테스트 자동화의 품질을 일관되게 관리하겠다는 의미입니다.

2. 개발 빌드 CI/CD 연동

개발 빌드 단계에서 수동 테스트를 시작하기 전에, 기본적인 기능에 대한 자동화 테스트를 수행하여 서비스의 안정성을 조기에 검증할 계획입니다. 이를 통해 개발 과정의 효율성을 높이고 잠재적인 문제를 미리 발견할 수 있을 것입니다.

3. 라이브 모니터링 도입

라이브 환경에서 바비톡 서비스의 핵심 기능들이 얼마나 안정적으로 작동하는지 지속적으로 모니터링하고, 문제가 발생할 경우 빠르게 탐지하여 선제적으로 대응하기 위해 라이브 모니터링 시스템을 도입할 예정입니다.

현재로서는 자동화된 테스트 케이스가 많지 않고, 구현 과정에서 예상치 못한 어려움에 직면할 때도 많습니다. 그럼에도 불구하고 바비톡 QA팀은 서비스 품질의 안정성을 확보하기 위해 꾸준히 노력하고 있습니다.

앞으로 이 목표들을 달성하여 기술 블로그를 통해 다시 좋은 소식을 전해드릴 수 있도록 최선을 다하겠습니다.

참고 링크

• Appium 공식 문서 : https://appium.io/docs/en/latest/
• Appium Discuss Forum https://discuss.appium.io/
• Robot Framework 가이드 문서 : https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html
• Selenium 공식 문서 : https://www.selenium.dev/

바비톡 QA 팀 테스트 자동화 구축기 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요! 바비톡 제품 플랫폼팀의 정원철 입니다.

바비톡은 수년간 유지되어 온 레거시 검색 시스템을 운영해오면서 여러 가지 어려움에 직면해 있었습니다.

주요 이슈는 다음과 같았습니다:

검색 품질 저하

• 사용자 경험을 충분히 만족시키지 못하는 검색 결과
• 정확히 일치하는 단어가 포함되어야 검색됨, 2단어 이상 검색이 어색함 등

불안정한 인프라

• Elasticsearch 2.3.0이라는, 2016년에 릴리스된 버전을 기반으로 하고 있어 장애 발생 시 대응이 어렵고, Kibana와의 호환성에도 문제가 발생

보안 및 유지보수 한계

• 더 이상 공식적인 패치나 보안 업데이트를 기대하기 어려움
• AWS에서도 지원을 하지 않아, 서버가 내려가면 복구 불가 확률이 높았음

기술 부채

• 초기 구현 이후 수년간 업데이트 없이 방치된 코드베이스, 명확한 문서화 없이 ES에 의존하고 있는 다양한 모듈

또한, 기존 시스템은 단일 인스턴스 형태로 운영되고 있었으며, 이를 전담하는 사일로 팀조차 존재하지 않아, 전체 서비스 구조에서 검색은 ‘블랙박스’에 가까운 존재가 되어 있었습니다. 신규 서비스 기획이나 개선을 논의할 때, 매번 해당 기능의 동작 원리를 파악하고 코드를 뒤적여야 하는 상황이 반복되었고, 이는 생산성과 품질 모두에 큰 장애 요소가 되었습니다.

이 문제를 해결하기 위해, 우리는 검색 시스템의 모듈화 및 현대화를 고려하기 시작했습니다.

초기 검토 과정에서 다음과 같은 기술과 아키텍처 방향을 논의했습니다:

OpenSearch 채택

• Amazon이 주도하는 오픈소스 기반의 검색 엔진
• AWS와의 높은 친화성 및 운영 편의성
• 보안, 모니터링, 스케일링에 대한 기능 강화

MSA 구조로의 분리

• DB와 검색 기능이 혼재되어 있는 기존 시스템에서, 검색 역할만 분리해 마이크로서비스화
• 전체 검색 흐름을 코드 단에서 역추적하며 기존 사용부를 분리 및 문서화

기존 Elasticsearch 사용부는 문서화가 거의 되어 있지 않아, 실제로는 전 코드 베이스를 수작업으로 살펴보며 검색 의존 모듈을 정리해야 했습니다. 이 과정에서 ‘검색 서비스’란 무엇인가에 대한 내부 정의와 기준도 정립해나갔습니다.

최종 선택

기술적/운영적 요소를 고려한 끝에, 우리는 다음과 같은 흐름으로 search_box라는 신규 서버를 만들기로 결정내렸습니다:

1. Legacy ElasticSearch 모든 사용 부분 식별

(1) Server 별로 흩어진 검색관련 api를 모두 식별하고, 분석함

(가)app_api server, client_api server, admin_api server, cron server

(2) 서버별, 인덱스별, 목적별 등으로 나눠서 총 89개의 대표적 사용부를 분석함

2. 최신 OpenSearch 기반 MSA search_box 개발

3. ElasticSearch에 저장된 data Bulk Migration + 한국어 Nori 형태소 분석 기능 적용 Nori 형태소 분석: AWS OpenSearch에서 사용되는 Nori는 한국어 텍스트를 형태소 단위로 분석하여 검색의 정확도를 높여주는 플러그인, 문장을 의미를 가진 가장 작은 단위인 단어로 쪼개어 그 본질을 파악하는 것

• 양이 적은 data는 한번에 migration 진행함
• 수백만개 수준의 data는 병렬로 AWS step functions를 활용하여 migration 진행함
• 직렬로 처리했을 경우, migration 완료까지 약 70시간이 예상되어 병렬로 진행함
• 서버 점검없이 migration을 빠르게 적용하기 위해, 인덱싱된 id별로 잘라서 20개로 병렬 처리함: id는 일부 구간 겹치게 처리하여, 신규 인입되는 데이터들도 대응가능케 함

4. Create(index), Update, Delete, Bulk app_api server

• ElasticSearch 기반의 기존 서비스가 동작하고 있기에, CUD 먼저 구현 및 적용 후, 병행으로 데이터를 적재하고 테스트함

5. Search 기능 케이스별 적용

• Create, Update, Delete 기능 안정화에 들었기에 Read(검색) 부분도 전면 교체함

6. MSA에서 Search 기능 고도화

• 산발적으로 흩어진 검색 기능을 하나의 MSA 기반 서버로 옮겼기에, 수정 및 모니터링이 용이해짐

이 과정은 단순한 검색 엔진 교체가 아닌, 검색의 정의, 설계, 운영 방식 전체를 다시 설계하는 작업이었습니다. 이미 서비스중인 앱의 기능을 MSA화하며, 신규 엔진으로 변경하는 작업이기에, 마이그레이션, 테스트, 코드 리팩토링을 반복하며 점진적으로 안정화시켰습니다.

산발적으로 흩어졌던, 검색 관련 기능을 분석하여, search_box라는 micro service로 몰아 뒀기에, 검색 관련 기능의 as-is 파악이 다음과 같이 보다 명확해졌습니다.

1. swagger를 통해 모든 search_box api 문서화

2. DataDog을 통해 검색 기능만의 모니터링이 용이해짐

3. Kibana 사용이 편리해져서, Dev Tool을 활용한, Opensearch 데이터 확인 및 테스트가 용이해짐

일차적으로, 서비스의 문서화, 모니터링, 테스트등의 관리가 명확해졌고, 이를 통해, 1) 검색 관련 인사이트를 보다 쉽게 얻을 수 있고, 2) 새로운 기술과 기획적 방향성을 효율적으로 제시할 수 있게 되었습니다.

향후 진행

독립된 서비스로 분리됐기에,

1. 검색 관련 인사이트를 보다 쉽게 얻을 수 있고,
2. 앱, 웹, 글로벌 등 멀티플랫폼에서의 개발 일관성 유지 및 개발비용 절감 가능해졌고,
3. 새로운 기술과 기획적 방향성을 효율적으로 제시할 수 있게되었기에,

향후에는 검색 기능 1) 안정화, 2) 고도화에 보다 집중하고자 합니다.

특히, 고도화 측면에서는 Ai 기능을 활용한 검색 기능을 제공하고자 합니다.

Search Box MSA 전환 여정: 서비스 분리와 확장 전략 was originally published in Babitalk on Medium, where people are continuing the conversation by highlighting and responding to this story.