토스 메이커스 컨퍼런스 25

Heechan Kang·2025년 7월 28일

20년 레거시를 넘어 미래를 준비하는 시스템 만들기

하태호 | 토스페이먼츠 Head of Technology

결제 산업 혁신을 목표로 출범한 토스페이먼츠는, 20년 넘게 운영된 레거시 시스템을 인수한 뒤 복잡한 구조를 개선하며 안정성과 확장성을 동시에 확보해왔습니다.
이번 세션에서는 국내 결제 시장의 패러다임을 바꾸기 위한 기술적 진화 과정과, 고객·가맹점 경험을 높이기 위한 새로운 결제 제품 개발 사례를 공유합니다.

처음에 git도 없었다고 함.
최신 코드 찾아서 git 등록하는 과정은 굉장히 힘들다. (근데 이건 대부분의 현대 개발자들에게 상관 없을듯)
온프레미스에서 AWS로 마이그레이션
- 물리 장비의 상태에 의존하는 시스템에서 탈피하자.
- MSA 전환 및 Docker/K8S 도입으로 고가용성 확보
Java도 최신 LTS 항상 따라가고 있음.
모든 로컬, 빌드머신 및 배포 환경 맞추기
- 모두 동일한 환경을 갖추는 것의 중요성
골든 이미지 작성 및 활용 하는듯
- 골든 이미지란? 표준화되고 최적화된 상태의 시스템 이미지.
- 우리 회사도 적용했으면 좋겠다.
전사 내에 추상화된 DevOps 파이프라인 구축: 모든 부서가 동일하게, 커밋 해시를 통해 배포 할수 있음
- 팀 이동, 다른 업무시에도 적응 시간 최소화: 효율적인 업무 환경 조성
표준화와 자동화의 중요성
1% 단위로 네트워크 흐름을 조정 할 수 있음
- 카나리 배포 등 안정적이고 신뢰할 수 있는 배포 가능

현장 결제 서비스의 분산 트랜잭션 관리학 개론

김학현 | 토스 현장결제 서비스

토스 현장결제 서비스에서 어떻게 분산 트랜잭션을 관리하는지 소개헤요.
결제 도메인에 국한되지 않고, 다양한 상황에서도 적용 가능한 보편적이고 직관적인 접근 방식을 중심으로 실전 사례를 공유합니다.

"개론"에 포인트
가맹점 -> 결제서버 -> 송금, 포인트, 프로모션 서버로 트랜잭션
API 호출 결과를 단정 할 수 없는 경우가 있음
- Unknown 상태(알 수 없는 경우) 예시
  - Read Timout
  - 네트워크 유실
  - 정의되지 않은 에러
- 즉, 실행 결과에는 당연히 '모름'도 포함되어야 함.
  - 그래야 MECE(Mutually Exclusive, Collectively Exhaustive) 하게 모든 경우를 표현 할 수 있음.
  - 이 Unknown 상태는 또다시 성공, 실패로 나뉘어짐.
Task1이 각각 또다른 2차 서브태스크를 가진 SubTask1, SubTask2로 나뉜 경우.
- 이 때, SubTask1과 SubTask2는 독립적으로 실행되며, 결과를 반환함.
예시) 토스결제 등..
문제 해결
- 복잡한 상황에 대한 표현 모델
  - 트리 구조를 통해 복잡한 상황도 표현 가능, 유연한 확장도 가능
    - 리프 노드에 상태를 표현 할 수 있음!
    - 이를 각각 상위로 집계하며 표현해 나갈 수 있음.
      - 자식이 하나라면 그대로 승계
      - 둘 이상이라면 자식들의 상태에 따라 상태 결정
    - 이를 통해 전체 상태에 대한 관심사를 오직 자식 노드로 한정 할 수 있음.
      - 하위 상태가 Unknown -> Success 로 전이 시 상태를 상위로 리졸브 할 수 있음.
        
        다만 이것만으로는 문제를 해결할수 없음
      - 방법 1. 실패한 상태를 재시도하여 성공으로 맞춘다
      - 방법 2. 성공한 상태를 롤백하여 실패시킨다.
  - 실제 구현 예시
```
// 트리 노드 구조
Task(결제)
├── Transaction(송금서버): Success
├── Transaction(포인트서버): Unknown → Success/Failure
└── Transaction(프로모션서버): Failure

// 상태 집계 로직
- 모든 자식이 Success → 부모도 Success
- 하나라도 Failure → 부모는 Unknown (보정 대기)
- Unknown 포함 시 → 부모도 Unknown
```
- 일관성을 누가!
  - 이처럼 방법을 선택할 책임을 누가? 각 노드가?
    - 각 노드는 단순 보상이 아닌, 재시도와 보상이라는 두 가지 전략을 가짐 - 기존 Saga Orchestrator와 다름.
- 언제까지 보장할지
  - ASAP 하지만 결국은 '최종적 일관성'
  - Unknown 상태 처리 방식
    - 타임아웃 정책: 각 서비스별로 다른 타임아웃 설정
    - 재시도 정책: exponential backoff로 부하 분산
    - 최종 전이: Unknown → Success/Failure 확정 후 상위 노드에 전파
실제 구현
- 노드의 레벨별로 테이블을 나눈다??
- 분단위 배치를 통해 정합성 보정?
  - 하지만 부족해서 API 내에서 자체 보정도 시행
정책
- 정책 수립 시 고려
  - 결제수단별 심리적 가치차이(현금, 카드, 등)
  - 보상 트랜잭션의 난이도 (입금 < 출금)
  - 결제수단별 처리 난이도(내부 < 외부)
- 결제수단 승인/환불순서
- 각 결제수단의 필수 성공여부
- Unknown 상태의 전파 바운더리 설정
  - 정책의 위임
- 금원이동 서비스와 결제서비스의 분리
- API 트랜잭션 내에서의 최소한의 보상 트랜잭션 시행
트랜잭션은 사실 원자적 요소가 아님
- 결국 각각은 내부적으로 묶이는 또다른 트랜잭션이 있음. 사실상 이미 트리구조를 형성하고 있음.

수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기

나재은 | 토스페이먼츠 Server Platform Team Leader

서버 설정도 소프트웨어일까요? 개발자의 인프라 접근성을 높이면서도 설정 실수를 줄여야 하는 미션은 얼핏 모순처럼 느껴질 수 있어요.
단순한 복사·붙여넣기에서 시작해, 수천 대의 서버를 한 번의 클릭으로 바꾸기까지.
이번 세션에서는 플랫폼 엔지니어링의 핵심인 설정 체계의 진화 과정을 소개하고자 해요.

일종의 setting.json 같은걸까? => 맞음.
수백, 수천개의 배치 중 잘못된(버그) 정산 배치를 찾아야 함.
- 일을 하다보면, 실수와 오타는 필연적
- 대부분 비슷한 설정이지만 '조금씩만' 다르다면?: 버그의 온상
- 코드는 버그를 만들지만, 인프라 설정 실수는 장애로 이어짐
중복 없이, 테스트 가능한 설정 체계가 필요함.
API 설정에 가해지는 외부 압력
- 개발자의 요구사항
- 모든 서버에 공통 변수 넣기
- 특정 서버 그룹에만 힙 메모리 늘리기
- 특정 빌드에서만 특정 테스트 실행하기
- 해결을 위한 두가지 축
  - 오버레이 아키텍처
    - 조합 가능한 계층형 레이어 설정 구조
      - Global, CLuster, Phase, App-type, APp-group, App...
    - 설정 파일을 여러 파일의 디렉토리 구조로 구성함
    - 하지만 특정 환경변수의 중복이 생기는 경우가 있음
      - kv yaml의 한계. 리스트형 표현에 한계가 있음.
      - 예시: DB_URL이 여러 레이어에서 정의되어 충돌
  - 템플릿 패턴
    - {{ }} 와 같은, 동적으로 삽입 가능한 템플릿으로 활용
      - 그러면 이걸 누가넣어주지? 실제 사용 직전에 후처리를 위한 프로세서가 관리되어야 할텐데
    - 실제 템플릿 예시:
```
server:
  port: {{ SERVER_PORT | default(8080) }}
  heap: {{ if eq .ENV "prod" }}4g{{ else }}2g{{ end }}
database:
  url: jdbc:mysql://{{ DB_HOST }}:{{ DB_PORT }}/{{ DB_NAME }}
```
  - 오버레이를 빌드한 뒤, 마지막 완성된 설정의 템플릿을 채우기?
  - 설정에 코드를 넣기?
    - 이건 제어 못하면 안티패턴이 될듯
  - 조건부 설정 기입
    - 이것도 좀.. 나중에 복잡도가 폭주할 것 같은데..
- 결국은 계속 변화, 진화 해야함
  - 복붙 => 오버레이 아키텍처 => 템플릿 패턴 => ???
    - 중복제거, 실수 방지 / 필요한 값 동적 기입
배치 설정
- 토스페이먼츠, 한달에 수 조원 정산
- 일, 월단위 대사 작업
- KISS: 단순하게 가자.
- Jenkins 사용: 단순하고 강력함. 그동안 증명된 신뢰성
- 해결해야 하는 문제
  - 수백개의 젠킨스 java 경로 업데이트
  - 수백개 잡의 환경변수 일괄 수정..
- JOB DSL 플러그인 어댑터?
  - 플러그인을 페이먼츠에서 자체 구현?
    - 개발자에게 정말 필요한 부분만 노출토록 래핑
    - 빌더 패턴으로 Job Building을 할 수 있음
```
job('payment-batch') {
    schedule('0 2 * * *')
    memory(4096)
    environment {
        add('SPRING_PROFILES_ACTIVE', 'production')
        add('BATCH_TYPE', 'daily-settlement')
    }
    steps {
        shell('java -jar payment-batch.jar')
    }
}
```
      - 근데, 그러면 어디까지 열어줄건지?
        
        '이런 기능 없나요?'
      - 그만큼 Jenkins와 JobDSL이 성숙해서 대부분의 기능이 지원 가능한걸까?
- Dynamic Provisioning 인프라
  - 배치의 메모리 부족문제 해결
  - 노드 하나에 프로세스 몇개가 적절할까.
    - 전용 노드 활용
- 진화과정
  - 복붙 => Job DSL => Dynamic Provisioning => ???

100번 실패하고 살려 낸 문서 시스템

⚠️ 다듬어진 글은 이 링크를 참고해 주세요!

박서진, 한주연 | 토스 Head of Frontend / Technical Writer

믿을 만한 문서 하나 없어서 옆 사람에게 모르는 것을 물어보던 토스 프론트엔드.
1년 사이 3천개 넘는 고품질 문서가 생기고, 하루 천 번 넘게 문서를 읽고 있어요.
하지만, 문서만 쓰는 것은 답이 아니었어요. 왜 문서를 쓰기만 해서는 안 되는지, 대규모 문서 시스템을 운영하는 데 중요한 것은 무엇인지, 토스가 99번 실패하고 고민하며 얻어온 노하우를 공유해요.

Notion, Logseq, Confluence...
- 이런 여러 도구를 사용했으나.. 잘 되지 않았음.
  - 계속되는 질문
    - 이 문서 있나요
    - 이거 최신 맞나요
    - 이거 더 잘 아시는분
현재는 '박씨' 봇
- 문서를 기반으로 답변
- 참조된 문서 링크
- 외부 데이터를 학습도 바로 시킬 수 있음
문서화 길드? 라는게 있다는 듯: 개발자들이 능동적으로 참여하는 문서화 그룹(?)
프론트, 온보딩 각 파트별 문서 플랫폼 관리중 - 약 2,000개 이상
테크니컬 라이팅 가이드 존재
오래되거나 잘못된 문서는 바로 알림을 보낼 수 있는 기능이 통합되어있음.
- 메트릭, 피드백 평가 등을 함께 노출: 직관적인 피드백
문서.. 좋은건 알겠는데, 왜 그렇게까지?
- 신규입사자 온보딩
  - 이걸 누구한테 물어봐야?
  - 이건 어떻게 동작하지?
  - 이거 왜 이렇게 짰지? 등등
- 누군가는 분명 알지만, 이게 암시적으로만 있음. => 이걸 명시적으로 끄집어 내자.
  - 힘들여서 아는사람부터 찾고, 이것도 단발성으로 동작
  - 휴가, 퇴사 시 정보의 부재
- 게다가 규모가 커지면서 이게 길을 잃게됨
- 슬랙은 공지가 되고, 서로 아는사람도 잘 없고, 질문하기도 좀 눈치보임.
좋은 문서 시스템의 두가지 조건
- 신뢰할 수 있는 정보
  - 낡지 않은, 최신의
  - 틀리지 않고 정확한
  - 스스로 완결되어있는
  - 필요한 것은 대부분 있는: 그래도 원하는것의 85% 정도는 있어야 나머지를 내가 채우지
- 누구나 접근 가능해야한다.
  - 검색하기 쉽다.
  - 익숙하고 맥락을 이어갈수 있어야한다.
    - 어려운 툴이나, 다른 매체로 변경(context switching 최소화)
- 즉, 신뢰성과 접근성
  - '박씨' 에서 느낀점: 접근성이 생각보다 중요하다.
- 문서의 라이프사이클: 중요하다.
  - 문서 작성
  - 읽기 => 중점. 읽어야 뭐라도 한다.
  - 피드백
  - 더많은 문서
- 당연히 검색이 되어야 한다.
  - 수많은 주제, 수많은 형태의 문서들이 있는데, 이게 보통 개별로 검색된다
  - '통합 검색'의 중요성!
  - 알골리아? SaaS
    - 통합 인덱스 활용
- 워크플로우에 통합되어야 한다.
  - 이게 바로 슬랙 봇 박씨?
근데 검색만으로도 부족, 접근성에 대한 갈증
- 옆사람에 질문이 더 편함
- 메신저로 물어보는게 더편함
- IDE 밖으로 나가고싶지 않음
- 이게 결국은 '물어보기'의 흐름을 유지해야 함.
그리고 박씨라는 봇이 생기니, 사람이 아니므로 질문의 허들이 매우 낮아짐.
게다가 박씨가 몰라도 다른 사용자가 대답해줌.

통합된 문서에 대한 MCP를 활용하여 문서 참조

MCP(Model Context Protocol) 활용 방식:

// MCP를 통한 문서 시스템 연동
- IDE에서 직접 문서 검색/참조 가능
- 코드 작성 중 관련 문서 자동 추천
- 문서 업데이트 시 실시간 반영

다시 신뢰성 이야기
- 시스템 만들기: Docflow
- 문서의 종류부터 파악
  - 레퍼런스 문서: 특정 소스코드에 대한 설명 문서. 사전과 같은 속성 Docflow, JSDoc을 사용한 문서 자동화
    - 코드를 바탕으로 문서 자동화
```
/**
 * @description 결제 요청을 처리하는 함수
 * @param {PaymentRequest} request - 결제 요청 정보
 * @returns {PaymentResponse} 결제 처리 결과
 * @example
 * const result = await processPayment({
 *   amount: 10000,
 *   method: 'CARD'
 * });
 */
function processPayment(request) { ... }
```
    - CI에 통합하여, 문서가 없으면 통합이 안되게!
    - 신선하지 않은 문서에 대해서는 관리자에게 알림
  - 가이드 문서: 튜토리얼, 줄글 및 설명
- 문서가 '정확한' 정보를 담게 하기 위한 시스템 구축
  - 문서 생성
  - 개발자 리뷰(수석 개발자)
    - 기술 리뷰
  - Technical Writer 리뷰
    - 읽기 좋은 문서
    - 이해하기 좋은 문서
왜 이렇게까지 하나?
- 고품질 문서 비율을 80% 이상으로 유지해야 한다.
필요하고, 쓸모있고 유용한 문서가 많아지게 하는 방법?
- 문서를 만들기 위한 리더들의 마중물
  - 분위기 만들기: 우선 열심히 초안 들이붓기
    - 일종의 가이드라인
- 정복단? 스터디를 통해 획득한 산출물 문서화
- 문서화 세션: 글 쓰는 방법에 대한 세션
박씨 학습시키기
- 근데 그래서 이건 누가 만들어..? 일단 박씨가 있어야...
중간정리
- 좋은 문서 시스템
  - 신뢰 할 수 있는 문서
    - Docflow
    - 문서 리뷰 시스템
    - 정복자, 문서화 세션
  - 누구나 접근 할 수 있는 문서
    - 통합검색
    - 익숙한 플랫폼
    - 맥락전환 최소화(MCP등)
수평확장
Technical Writer must die??
- 2000개 이상의 문서 관리.. 자동화
문서는 조직의 인프라다.
좋은, 양질의 정보를 누구나 쉽게 접근 할 수 있게 해야한다.
이게 팀이 성장하는 동력

당신은 이미 팀을 최적화하고있다

이재연, 유희열 | Server Developer / L&D Coach

코드를 분석해 문제를 발견하고 가장 효과적인 수정 방법을 통해 최적화하는 것처럼 팀과 팀원이 일하는 방식에서도 효과적인 해결 방법을 어떻게 만들 수 있는지 공유해요.
개발을 직접 하지 않더라도 팀의 성장을 이끄는 방법. 그 감을 익힐 수 있도록 실전 사례들을 소개드려요.

위임, 분배, 책임감
- 위임, 기대와 현실의 거리, 책임감 과잉
  - 위임
    - 내가 하고말지.. 하는거 있지.
    - 주변인의 도움이 필요할테니 위임을 해라
      - 자신이 하던 일을 그냥 쪼개서 주는게 위임이 아님.
      - 주고 잊을 수 있어야 진짜 위임. 근데 그게 어려움.
믿음을 쌓아가는 방법
- 팀원의 프로젝트 싱크를 맞출 수 있어야 함
  - 계획을 구체적으로 세우되... ?????
- 전체 볼륨을 먼저 합의하자
  - 이걸 합의 안하면 대체로 결국 충돌이 날 수 밖에 없음.
  - 당일, 혹은 하루, 혹은 중간중간 서로 확인하는 것도 필요: 부담되지 않게 요청하기?
    - 이것도 그냥 수시로 물어보는것도 스트레스 요인임.
      - 이런 작은것도 퍼미션을 하나씩 쌓아가자.
- 의견이 다른 부분에 대해 맞춰가는 과정
- 신뢰의 3요소(배반의 3요소...)
  - 역량 신뢰: 이사람이 이 일을 잘 해낼거라는 믿음
    - 개발자의 흔한 실수: 남들도 나만큼 할 수 있을거라는 착각
  - 소통 신뢰: 이 사람이 어떤 상황에서도 진심으로, 솔직하게, 맥락있게 소통할거라는 믿음
  - 계약 신뢰: 약속할 것을 지킬 사람이라는 믿음
- 개발능력 외에도 위의 요소를 갖춰야 할 듯.
- 자율성을 존중하면서 퍼미션 얻기??
  - 팀원의 자율성이 존중되고 있는지
  - 팀원이 스스로 뭔가를 결정할수 있는지
  - 일정도 지켜야하는데?
  - '퍼미션'이 뭐지?
    - 무턱대는 조언 말고, '의견을 말해줘서 좋고, 그러면 내가 의견을 말해도 될까' 라는 허락을 통해 청자의 듣기 효율을 매우 높일 수 있다.
Managing Up
- 변화, 한 사람, 버드뷰, 알아주기
- 리더십 코칭 경험
  - 잘 변하는, 혹은 변하지 않는 조직
  - 코칭 대상자의 작은 변화를 읽어 줄 수 있는 매니저가 있어야 함.
    - 회사의 방향과의 정렬이 잘 되어있는지 확인해 줄 사람이 필요함 - 유형석 CTO?
      - 결국은 상하동욕자승이라고 했지.
  - '나를 알아봐주는 리더'를 만나는 것도 복이지
사람을 '대체 불가능한 인력', '대체 가능한 인력' 으로 나누는 습관.
- 대체 불가능한 사람들의 풀을 늘리자
하위 팀 멤버의 성과를 끌어내고, 보일 수 있게 하는 방법
- 이력서를 실제로 같이 써보는 경험도 좋다?
  - 회사 사람, 더군다가 상급자와 이력서를 같이 써보는 경험이라..

확장성과 회복 탄력성을 갖춘 결제 시스템 만들기

박순현, 양권성 | 토스페이먼츠 Server Developer

토스페이먼츠의 20년 된 레거시 시스템, 어떻게 개선했을까? 코드 뿐 아니라 DB까지 노후화된 레거시 시스템은 강결합된 구조로 인해 유지보수는 물론, 비즈니스 측면에서도 수많은 제약을 만들어냈어요.
이번 세션에서는 이런 레거시 시스템을 어떻게 신규 DB로 이관하고, 점진적으로 구조를 개선해 나갔는지 그 과정에서 마주한 이슈들과 해결 경험을 공유하고자 해요.

원장
- 기업의 모든 거래내역을 기록하는 공식 장부
결제 원장
- 고객이 결제하거나 취소한 내역 저장
레거시 원장 시스템의 문제점
- 일관성 없는 구조
  - 카드 취소/부분취소는 분리된 테이블
  - Refund라는 이름 테이블 이름이지만, 계좌이체 부분취소
- 다양한 도메인 사이의 강한 의존
  - 동일한 용어도 팀별로 사용 용어가 다름. 혹은 중복
- 비즈니스 확장을 막는 구조
  - 1:1 구조로, 분할 결제 등을 구현 할 수 없음.
Oracle => MySQL 로 전환
- 시스템 안정성: 결제팀 전용의 DB 인프라
- 유지보수
  - 오라클 자체 함수, 디버깅 힘든 환경 등
- 유연함과 확장성, 실험환경 구성
  - 오픈소스 기반, 다양한 도구와 쉽게 연동 가능
해결
- 일관된 구조 잡기
  - 승인과 취소를 각각의 테이블로 쌓음. 기존 row 조작이 아니라 무조건 insert. 이러면 락도 필요없어짐
- 도메인 과 결합도 낮추기
  - 카프카를 활용한 결합도 분리
  - 근데 이건 좀 다른 이야기같은데? 용어 문제라며???
- 확장성
  - 결제와 승인의 개념적 분리
  - 더치페이, 복합결제 등 요소를 구현 할 수 있음.
신규 원장으로 전환시 동기/비동기 동시 처리: 섀도우?
비동기 처리를 위한 스레드풀 설정
- 일부 데이터 버려도 되도록
Graceful shutdown
레거시, 신규 결제원장 사이의 검증배치.
- 매시 정각이 아닌 5분 텀
신규원장 전환시 점진적 트래픽 투입
- 트래픽 관리, 버그 확인도 있지만 스펙도 확인해야 함.
마이그레이션 작업을 라이브에서 하면 문제가 생길 수 있음.
- 마이그레이션용 서버를 분리해서 작업
초기에는 하나씩 기존 로직으로 insert를 하려했으나... 느리고 트래픽 터짐
결국 배치 인서트
로컬 캐시 사용?? 어디다가?? 왜??
마이그레이션 시 네트워크 대역폭 문제가 있음
- 다른 서비스가 눌려버릴 수 있음..
그래서 회복력과 탄력성은?
- 결제서버 장애 문제
  - 결제 DB에 부하가 배포 이후 확 침
  - 특정 Select 쿼리가 문제
    - 전날 배포된 신규 로직. 롤백하여 우선 장애 해소
    - 단순한 셀렉트인데 왜?
      - 적재량이 많아짐에 따라, 옵티마이저가 인덱스를 활용을 안했다?? 왜??
        
        쿼리 힌트 추가하여 해결
  - DB 적재 실패하여 신, 구 원장 불일치
    - 아직 메인이 구 원장이므로 배치로 동기화
  - 원천사 원장 불일치
    - 타임아웃으로 실패 판단한 거래에 대해서는 원천사에 결제취소를 자동으로 요청
  - 원장 가맹점 불일치
    - 각 홉 간에 타임아웃이 따라야 할 규칙을 세우고, 이를 조사한 뒤 새로 적용해야 함.
  - 이벤트 발행도 누락됨
    - 아웃박스 패턴
    - 아웃박스에도 저장이 안된 이벤트??
    - 이벤트 재발생시 중복 가능성
      - 헤더에 멱등키 활용

레거시 정산 개편기: 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지

20년간 운영되어 온 토스페이먼츠의 레거시 정산 시스템에 ‘대대적인 리모델링’을 감행한 여정을 소개해요. 고고학 발굴처럼 복잡한 쿼리 속에서 핵심 로직을 명쾌한 코드로 재구성하고, 수억 건의 데이터를 빠르게 처리하기 위한 최적화 과정을 수차례의 검증을 반복했어요. 1,700개가 넘는 배치를 운영하며 얻은 실전 경험까지 빠짐없이 공유합니다.

정산이란?
- 결국 돈이 흐르게 하는것
왜 개편하는가?
- 세 가지 한계점
  - 1. 비즈니스 로직이 쿼리에 종속적임
    - 수수료 계산 쿼리, 조인, 서브쿼리, 유니언.... 읽기 힘듦.
    - 작은 수정시에도 쿼리를 하나 하나 모두 열어봐야 함.
    - 이 한방쿼리를 작고 명확한 단위가 될때까지 분해
    - 이를 통해, 전체 일괄 변경이 아니라, 분해된 작은 기능단위로 새로운 기능 도입 가능
    - 이런 작업의 비즈니스 로직을 하나하나 객체로 분리하여 코드 재사용성 높임
  - 1. 데이터 모델링 한계
    - 각 거래의 결과를 개별적으로 저장하는게 아니라 집계 후 저장하고있었음.
      - 원인 추적도 힘들고, 가시성 떨어짐
    - 이미 특정 단위로 집계되어, 다른 요구사항을 위한 데이터 제공도 어려움.
    - 데이터를 집계가 아닌, 독립적인 단위로 저장
      - 원인 추적이 용이
      - 최소 단위의 데이터에 대한 재사용성 확보
      - 계산 당시 파라미터를 모두 스냅샷 저장
      - 실패건에 대한 지엽적인 조치 가능
      - 데이터가 고해상도가 되면서, 사이즈가 매우 커짐
    - 날짜 기반 레인지 파티셔닝, 인덱스
    - 조회 전용 테이블 설계
      - 개별 데이터 조회시, 기존 인터페이스를 맞추려면 매번 집계해야 함.
      - 따라서 조회용 집계 테이블을 별도로 설계
  - 1. 배치 시스템 성능이슈
    - 거래량 증가할수록 처리 실행시간이 매우 길어짐.. 배치간격보다 길어질지도
    - 스프링 배치를 사용해도, 여전히 IO 많음
    - 싱글 스레드 기반이라 처리량 한계있음
    - IO 처리횟수를 매번 DB 조회 => 인메모리 캐시 활용
    - itemProcessor가 하나씩만 입력받음(IO 많음) => Wrapper 클래스 사용하여 묶음으로 입력
    - insert도 하나씩 하던것 => 배치 인서트로
    - 다수 API 호출 필요시 순차처리 => 병렬처리
    - 배치처리시 스레드 안전 지키도록
    - 배치 병렬처리 시 ID 모듈러 연산 사용
그래서 개발 이후 마이그레이션은?
어떻게 새 시스템이 기존 시스템과 동일한 처리를 한다고 확신 할 수 있지?
테스트 자동화 플랫폼 활용
- 테스트 방식을 표준화하여 제공
- 수만 개 이상의 테이스케이스 관리 용이
신규 시스템 투입 방법
- 시스템 변화를 원자적으로 적용?
- 최소 단위를 구분하여 카나리 배포
- 트래픽을 조정할 수 있다는 것의 장점 / 필요성
정산 배치 관리
- 젠킨스 잡만 1781개가 있음..
과거 정산배치 구조
- 매우 많은 배치가 다수의 IDC에 분산되어 있음
- 즉, 관리되지 않고 있었음.
일단 하드웨어 장애에 취약한 환경에서 벗어나자.
- AWS k8s로 이전
  - RTT 늘어남
배치는 결국 젠킨스
- 안정적이어야함.
- 정산 도메인은 매우 stateful함
- 파이프라인 선언을 통해 워크플로우 정의 가능
- 플러그인 생태계가 풍부함
젠킨스 잡 실행 장비를 고정해두면 비용 낭비 혹은 성능이슈가 생김.
dynamic provisioning 으로 필요할때만 사용
Job DSL
배치 모니터링 도구 강화

조직의 생산성을 높이는 Process Mining

김병묵 | 토스플레이스 Node.js Developer

반복되는 운영 업무를 자동화했는데도 조직이 성장하지 않는다면, 과연 문제는 어디에 있을까요? Process Mining을 활용해 데이터 기반으로 핵심 병목을 찾아내고, 업무 프로세스를 재설계한 사례를 소개하고자 해요. 개발자가 단순한 자동화를 넘어, 조직의 생산성 향상에 직접 기여할 수 있는 전략과 접근 방식을 함께 나눕니다.

Process Mining?
- 우리가 어떻게 일하는지
- 업무 자동화와 생산성
성장을 위해 필요한 OOO: 모두 필요함
- 제품
- 일하는 방식
- 손님이 많아지는 가게가 마냥 좋은것은 아님.
  - 준비가 되어있어야 하는데, 그렇지 못하다면 컴플레인이나 실수가 많아지는 문제가 있음.
  - 고객이 많아지기 위해서는 그걸 받아줄 인프라가 뒷받침되어야 함.
  - 개발자 생활중에도 이런 점을 느낌
단순 반복 업무나 백오피스에 대한 자동화
이런 경험이 쌓일수록, 우선 '우리가 어떻게 일하고 있는지' 를 데이터 기반으로 명확하게 알아야 함.
- 에러 감지 => 담당자 할당 => 개발 => 코드리뷰 => 배포
- 이 싸이클이 대략 몇시간, 얼마나 걸리는지, 그리고 각 비율이 얼마나 되는지.
- 보통 수집하는 데이터도 없고,비율도 명확한 수치로 알 수 없다.
- 반복 업무에 건당 약간이라도 자동화를 통해 시간을 세이브 할 수 있다면, 그 효과는 커질 수 있다.
일반적인 팀의 업무 프로세스에서...
- 이 업무들이 한달아 몇 건 정도 있는지, 얼마나 걸리는지, 각 단계를 어떻게 개선할 수 있는지
  - 동기부여도 된다.
  - 팀에 기여한 성과도 알 수 있다.
  - 새로운 아이디어를 주도할 수 있다.
자 다시 Process Mining: 우리가 어떻게 일하고 있는지 이해하기 위한 도구
- 1. 데이터를 수집
- 1. 분석을 위한 가공
- 1. 이용을 위한 실제 업무 흐름일 도식화한 '프로세스 모델' 작성
  - 단계별 소요시간 등..
어떤 업무를, 누가 어느정도 빈도로 하고 얼마나 시간을 쓰는지

데이터 수집
- 모든 일은 시스템 위에서 일어난다
  - 팀마다 다양한 툴을 사용할수는 있다.
  - 그러나 결국 기록은 하나의 시스템, 플랫폼 안에서 기록된다.
  - 즉, 모든 흔적을 데이터로 쌓을 수 있다. => 외부 툴이어도 가능, 센트리, 깃, 슬랙, 마케팅 툴 등 대부분.
  - 데이터를 수입할 기반부터 만들자.
    - 어떠한 데이터를 어떠한 포멧으로 남길까? => "이벤트 로그"
  - PM4PY
    - CaseID Activity Timestamp
- 그럼 어디까지 데이터를 수집해야 하는가?: Scoping
- 서로 다른 시스템을 어떻게 연결할것인가?: Entity Resolution
  - 결국 독립된 플랫폼이랑 GUID 가 필요한거 아닌가??
  - {{ 이거 JIRA 같은데에 배치로 뽑을 수 있는거 없나? 있을것같은데 }}
수집된 데이터로 일의 흐름과 병목을 분석하고 개선한다
- 수집된 데이터를 바탕으로, 실제 흐름의 경향을 볼 수 있음
- 이 과정에서 노이즈가 생기면 그냥 안듣게됨..

Heechan Kang

안녕하세요!

이전 포스트

토스의 기가막힌 문서 시스템: 실패에서 배운 교훈들

다음 포스트