TPM · 프로세스 최적화

파이프라인 생성 공수 80% 절감 — 데이터 기반 개선 제안부터 구현까지

2025 카카오뱅크

프로젝트 개요

개발 기간
3개월
2025.01 — 2025.03
팀 구성
2명
BE 2
담당 역할
기획, 백엔드/프론트엔드 개발
Spring Boot Java

들어가며

기능 개발 요청은 항상 기획팀이나 현업에서 먼저 오는 것이 당연하게 여겨집니다. 그런데 이 프로젝트는 달랐습니다. 개발자인 제가 먼저 데이터를 분석하고, 문제를 정의하고, 해결책을 제안하여 결국 구현까지 이어졌습니다. 이 글은 운영팀의 반복 작업을 데이터로 증명하고, 금융 규제 안에서 실현 가능한 자동화를 설계한 과정을 SBI(Situation → Behavior → Impact) 구조로 기록합니다.

Situation — 매번 처음부터 다시 그려야 하는 파이프라인

금융 도메인의 구조적 제약

카카오뱅크의 마케팅 메시지 발송은 금융 당국의 규정과 내부 컴플라이언스 정책에 따라 엄격한 결재 프로세스를 거쳐야 합니다. 모든 발송 내역은 감사 추적(Audit Trail)이 가능해야 하고, 이를 위해 각 발송마다 독립적인 1회성 파이프라인을 생성하는 방식으로 운영되고 있었습니다.

이 구조 자체는 규정 준수 측면에서 합리적입니다. 문제는 그 결과로 생겨난 운영 부담이었습니다.

반복이 만들어낸 비효율

마케팅 캠페인은 일반적으로 오전 발송과 오후 발송으로 분리되거나, 채널(앱푸시·SMS·카카오 알림톡)별로 나뉘어 실행됩니다. 매번 새 파이프라인을 생성해야 하는데, 그 설정 내용은 대부분 동일합니다.

파이프라인 생성 평균 소요 시간
7.5분
동일 패턴 반복 비중
~50%
수동 입력 항목 수
20+개

파이프라인 하나를 만들려면 발송 시간, 대상 세그먼트, 메시지 템플릿, 채널 설정, 발송 속도 제한, 결재자 지정 등 20개가 넘는 항목을 일일이 입력해야 했습니다. 그리고 이 입력 과정은 사람이 직접 수행하는 만큼 실수(휴먼 에러)의 여지가 항상 존재했습니다.

"내일 오전 캠페인이랑 오후 캠페인이 설정이 거의 똑같은데, 또 처음부터 다 입력해야 하나요?"

Behavior — 데이터로 설득하고, 정책으로 설계하다

1단계: 1년치 로그로 문제를 정량화

직관적으로는 명백한 문제처럼 보이더라도, 조직 내에서 새 기능의 우선순위를 확보하려면 데이터가 필요했습니다. 1년간의 파이프라인 생성 이력을 분석하여, 동일 또는 유사한 설정으로 반복 생성된 파이프라인의 비중을 정량화했습니다.

분석 결과 연간 생성 파이프라인의 약 50%가 채널 구성, 발송 속도, 메시지 템플릿 등 핵심 설정이 이전 파이프라인과 동일했습니다. 주요 반복 패턴은 다음과 같았습니다.

  • 오전/오후 분할 발송: 동일 캠페인을 오전·오후로 나눠 실행하는 패턴 (가장 빈번)
  • 채널별 분할 발송: 동일 내용을 앱푸시·SMS·알림톡으로 각각 생성하는 패턴
  • 주간 정기 캠페인: 매주 동일 세그먼트에 발송되는 정기 캠페인 재생성

이 데이터를 바탕으로 ROI를 산출했습니다. 파이프라인 1개 생성에 평균 7.5분, 연간 반복 파이프라인 수를 대입하면 절감 가능한 공수가 명확하게 나왔습니다. 기획서와 함께 유관 부서에 제안한 결과, 파이프라인 복사 기능 개발이 공식 일정에 채택되었습니다.

2단계: 금융 규제 안에서의 UX 설계 — 필드 분류

복사 기능을 만드는 것은 단순합니다. 어려운 부분은 무엇을 복사하고, 무엇은 반드시 새로 입력받아야 하는가를 결정하는 것이었습니다.

금융 컴플라이언스 관점에서 복사 기능은 잠재적 리스크가 있습니다. 이전 파이프라인의 설정을 그대로 복사하다가, 실제로는 다른 대상에게 다른 조건으로 발송해야 하는 상황을 놓칠 수 있기 때문입니다. 마케팅 운영팀, 컴플라이언스 팀과의 인터뷰를 통해 필드를 두 가지로 분류했습니다.

분류 예시 필드 이유
반드시 새로 입력 (복사 불가) 발송 예정 시간, 대상 세그먼트, 결재자, 발송 명칭 캠페인마다 달라지는 핵심 속성. 이전 값이 그대로 사용되면 잘못된 대상에게 잘못된 시간에 발송될 위험
자동 복사 허용 메시지 템플릿, 채널 설정, 발송 속도 제한, 필터 조건 동일 캠페인 시리즈에서 재사용되는 기술적 설정. 매번 재입력은 오히려 실수 가능성을 높임

복사 불가 필드는 폼에서 빈 값으로 표시되어 담당자가 반드시 직접 입력하도록 강제했습니다. 복사 가능 필드는 이전 값이 자동으로 채워지되, 수정이 자유롭도록 설계했습니다.

3단계: 결재 정합성을 유지하는 복사 로직 구현

복사된 파이프라인은 신규 생성 상태로 시작해야 합니다. 이전 파이프라인의 결재 이력이나 발송 상태가 함께 복사되어서는 안 됩니다. 결재 흐름(대기 → 승인 → 발송)의 최초 단계에서 새롭게 시작하도록 상태를 초기화했습니다.

// 복사 시 초기화 대상 필드
PipelineCreateRequest copy = PipelineCreateRequest.builder()
    // 복사 가능 필드 (이전 파이프라인에서 가져옴)
    .messageTemplateId(source.getMessageTemplateId())
    .channelConfig(source.getChannelConfig())
    .sendRateLimit(source.getSendRateLimit())
    .filterCondition(source.getFilterCondition())
    // 반드시 초기화 (새로 입력 필요)
    .scheduledAt(null)          // 발송 시간: 빈 값
    .targetSegmentId(null)      // 대상 세그먼트: 빈 값
    .approverId(null)           // 결재자: 빈 값
    .name(source.getName() + " (복사)")  // 구분을 위한 접미사
    // 상태 초기화
    .status(PipelineStatus.DRAFT)
    .approvalHistory(Collections.emptyList())
    .build();

Impact — 7.5분에서 1.5분으로, 운영팀의 하루가 달라지다

파이프라인 생성 소요 시간 (개선 전)
7.5분
파이프라인 생성 소요 시간 (개선 후)
1.5분
공수 절감율
80%

복사 기능 도입 이후 마케팅 운영팀의 파이프라인 생성 소요 시간이 평균 7.5분에서 1.5분으로 단축되었습니다. 숫자 자체보다 더 중요한 변화는 맥락의 전환이었습니다. 대규모 캠페인을 준비할 때 파이프라인을 여러 개 나눠야 하는 경우, 이전에는 각각 처음부터 입력해야 해서 준비 시간이 캠페인 전략 설계보다 더 많이 드는 역전 현상이 있었습니다. 복사 기능 이후 운영팀은 캠페인 내용에 집중할 수 있게 되었습니다.

핵심 교훈

  • 데이터 없이 제안하면 우선순위에서 밀립니다. 1년치 로그 분석으로 50% 반복이라는 수치를 제시하자 개발 우선순위가 즉시 확보되었습니다. 같은 문제도 정량화 여부에 따라 설득력이 달라집니다.
  • 자동화는 책임 소재를 명확히 해야 안전합니다. 복사 가능 필드와 불가 필드를 정책으로 명문화했기 때문에, 컴플라이언스 팀도 우려 없이 기능을 수용할 수 있었습니다.
  • 개발자도 제안자가 될 수 있습니다. 이 기능은 현업 요청이 아니라 개발자의 데이터 분석에서 시작했습니다. 운영 현장을 이해하고 데이터를 볼 수 있다면, 개발자는 기능 구현자를 넘어 비즈니스 개선 제안자가 될 수 있습니다.

정리하며

이 프로젝트에서 가장 오래 걸린 부분은 코딩이 아니었습니다. 데이터로 문제를 증명하고, 규제 안에서 실현 가능한 설계를 만들고, 여러 이해관계자의 동의를 구하는 과정이 더 많은 시간을 차지했습니다. 코드는 그 합의의 마지막 표현이었습니다. 좋은 기능은 좋은 코드만으로 만들어지지 않는다는 것을 다시 한번 체감한 경험이었습니다.