[2025.07.25] Toss Makers Conference 25

 

행사 홈페이지: https://toss.im/tmc-25/

 

  마지막으로 참여한 컨퍼런스인 인프콘22 이후로 3년 만에 오프라인 컨퍼런스에 오게 되었다. 토스 컨퍼런스에 응모했는데 당첨되어서 참석하게 되었다. 3일 중 엔지니어링 데이인 마지막 3일 차인 25일 금요일. 세미나 참석으로 하루 회사를 빠질 수 있었지만, 오후에 회의도 있고 해서 회사 -> 코엑스 -> 회사 이동을 하게 되었다.

  짧은 호흡으로 많은 세션이 있었다. 호흡이 짧다보니 지루해질 만하면 끝나서 집중하기에 좋았다. 다만 더 깊이 있는 이야기를 하지 못하는 그늘도 있었긴 하다.

  외부에서 토스의 일하는 문화 때문에 무성한 소문들이 많긴 하지만, 정말로 일을 좋아하고 더 나은 세상, 서비스를 만들기 위해 노력하는 사람들이라는 모습을 볼 수 있었다. 금융과 관련하여 불편한 많은 부분들을 (아마도) 10년 넘게 계속 혁신해 오고 있음은 누구도 부정하지 못하는 사실이리라.

  우리 회사도 테크핀 회사인데 이런 컨퍼런스도 열고 조금 더 개방적인 모습을 보여주면 어떨까 싶다. 실패한 것을 두려워하지 않고 오히려 당당히 공유하고 발표하면서 다른 이들에게 조금이나마 도움이 될 수 있다면...

---

 

오프닝 세션 - 이형석 CTO (10:10 ~ 10:25)

- slash 기술 컨퍼런스 온라인으로 -> 작년 처음 오프라인 컨퍼런스로 확장 -> 모든 메이커가 함께하는 컨퍼런스로 이어짐

- 실패가 일상, 그러나 실패하지 않는 조직음 없음. 실패를 어떻게 다루느냐가 중요. 드러내고 공유하고 다음선택의 근거로 사용. 실패를 통해 배우는 것이 일하는 문화의 핵심

- 자신만의 방식으로 질문 던져보길: 나였다면 어떻게 기준으로 접근, 어떻게 해결할까, 나도 발표자리에 서고 싶다 ...

 

 

20년 레거시를 넘어 미래를 준비하는 시스템 만들기 - Payments head of tech 하태호 (10:30 ~ 11:00)

- PG (payment gateway)

- 연가 거래액 40조+

- pay tech

  - sdk & api: 손쉬운 결제 연동

  - mcp 서버: ai

  - 브랜드페이: 나만의 간편결제 구축

  - 링크페이: 나만의 쇼핑몰

  - 결제위젯: 노코드. 원하는 형태로 주문서 구성 가능

  - 퀵계좌이체: 높은 카드 수수료 낮춤

- 가맹점의 성장에 기여하는 제품을 만든다

- 2020.8 타사 pg 시스템 인수 및 법인 설립

  - 이관 받은 시스템의 상태가 좋지 않다...

  - 소스코드 관리 상태: 개선 필요 (2020.08 시스템 인수 시점)

    - 노후화 서버, unix 서버, 10년 넘은 Os 버전, 노후화 장비 다수

  - 인프라 기반 시설 투자 부족: 개선 필요

    - 사내 DNS 시스템 없음

    - 인프라 자동화 도구 미존재

    - 시스템 observability 부족

  - 네트워크 라우팅 구성: 개선 필요

    - 각 서버가 라우팅테이블 존재. 서버마다 설정이 달라질 수 있음

- 새로 합류하는 팀원이 (레거시 시스템에 영향을 받지 않고) 비즈니스 임팩트를 낼 수 있어야 한다

  - 인프라: AWS

  - DevOps, 플랫폼 엔지니어링 

  - 단계적 시스템 개선

## 개선

1. Github Enterprise 도입

  - 어떤 소스코드가 최신인지 모르는 상태...

2. 빌드 표준화

  - 모든 개발자의 pc -> 어디서든 빌드 가능

3. MSA 아키텍처로의 전환 및 쿠버네티스 도입

  - 150+ Service

4. 고가용성 인프라 구성

  - 클러스터 4, IDC 2 & AWS 2

5. 자동화된 코드 업데이트 체계 확보

  - 표준화

  - 로깅, 모니터링 -> Common Libarary. 런타임에 자동으로 주입

6. 서비스 안정성 및 성능 고도화

  - 카나리 배포 가능

  - 성능: HTTP/3, TLS 1.3, Multi-Layer Cache, Multiplexing

7. 대규모 데이터 조회 기술 확보

  - 수십초 이내 과거 5년 데이터 OLAP 쿼리

  - 1분 걸리던 쿼리 -> 1초 이내

  - 3개월 조회 제약 -> 5년

  - 조회 빠르고 길게 되서 감사하다는 사례 있음!!

8. 보안 강화

  - 결계, 내부망, 업뭄망, 런타임, 컨테이너 보안. + AI를 활용한 보안 이벤트 분석

  - TLS 1.3 민감한 API E2E 암호화 + 어플리케이션 레이어에서 추가적인 암호화

9. 어플리케이션 개편

  - Struts 1.2 (2004) -> boot3, kotlin, react

  - 쿼리 중심 어플맄에ㅣ션 -> 로직 중심 어플리케이션

  - On-Prem, Monolithic -> Cloud Native

  - 개선된 시스템 -> 고객사의 다양한 요구사항을 빠르게 수용하는 데 도움

- 현재 모습?

  - Private Cloud + Public Cloud

  - provider agnostic envrionment

  - 보안 + Zero Trust

  - Devops + Platform Engineering

  - 수 억~수십 억건 테이블*n 개 join

  - FDS

  - 불법 상품 판매 상점 심사 w/ AI

 

 

현장결제 서비스의 분산 트랜잭션 관리학 개론 - core 김학현 (11:05 ~ 11:35)

 

- 전혀 새로운 방식으로 접근 예정

- 실제 서비스에서 검증 된 방식 중 하나

## 2개의 api를 atomic 하게 처리하기

- case1. 호출 결과를 단정할 수 없는 경우

  - 서버 에러 등의 경우까지 고려 해야함

- 문제해결을 위해 필요한 것

  - ...

  - 일관성 보장 주체

  - 일관성 보장 시점

- 표현모델

  - tree의 node 별로 success, fail, unknown 상태를 가짐

  - 부모는 자식의 상태를 보고 상태가 결정

- 언제(까지) 일관성이 유지 되야할까?

- 정리

  - 표현모델:  트리구조

  - 일관성 누가 어떻게 보장: 각 노드가

  - 일관성 언제까지 보장: ASAP 하지만 최종적 일관성 추구

- 다양한 정책 

  - 정책 수립 시 고려해야할점

  - 결제수단 승인/환불 순서

  - 각 결제수단의 필수 성공 여부

  - UNKNOWN 상태의 전파 boundary 설정

  - 금원이동 서버와 결제 서비스의 분리

  - api 트랜잭션 내에서의 최소한의 보상 트랜잭션 실행

 

수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기 - payments 나재은 (11:40 ~ 12:10)

## API 서버

- 코드 중복이 설정 중복 -> 인프라 장애 가능

- 하나의 설정 체계 -> 실시간 API 서버, 배치 서버

- 문제 정의

  - 모든 서버에 공통 환경 변수

  - 특정 서버 그룹만 heap memory 설정

- 실시간 API 서버 설정의 두 가지 축

1. 오버레이 아키텍처

- 조합 가능한 계층형 레이어 설정 구조: global, cluster, phase, app-type, app-group, app

- 만능은 아님

  - 중복 가능

- 템플릿 패턴

  - 예시: -Xms{{XMS}}

- 설정에 코드를 넣기

핵심: 계속 진화할 수 있는 구조

## 배치 서버

- 페이먼츠의 배치: 한 달에 수조워

- 적정기술! Simple is the best!

  - airflow, k8s cronjob,, => Jenkins!

- 개발자가 선언만 하면, 나머지는 데브옵스가 알아서 처리하는 구조를 만들자!

  - 개발자: 원하는 상태를 선언, 편안함

- 배치 설정에서 해결해야 하는 문제

- JOB-DSL 플러그인 어댑터

  - 플러그인을 한 번 감싸서, 사용하기 쉽게 페이먼츠 자체 구현

  - java application 실행을 위한 선언형 설정 (groovy)

  - 패턴에 맞게 전부 제공: batch 빌드, 배포, java 빌드, shell 커맨드 등등...

- JOB-DSL 플러그인 어댑터가 가져온 변화

  - 테스트 가능, JVM 옵션 자동 설정, 공통 기능 자동 적용, 선언만 하면 끝

- 한 노드에 몇 개의 process를 실행하지?

  - 동적으로 장비 받아와서 1 job = 1 node 할당

- 핵심: 개발자와 데브옵스간의 단일 업무 인터페이스 구축

- 머나먼 여정의 결과

  - jdk 25 9월 출시

  - 새로운 apm의 추가

  - 설정 릴리즈 노트: 오늘부터 이 기능 사용 가능합니다

 

 

가맹점은 변함없이, 결제창 시스템 전면 재작성하기 - payments 황성우 (12:15 ~ 12:45)

- 결제창은 무엇인가?

  - 고객: 쇼핑몰, 토스페이먼츠, 카드회사/간편결제사

  - 국내 전체 카드사, 해외 대표적인 브랜드사, 주요 간편결제사 지원

- 결제창 레거시로 인한 문제

  - 2500 라인의 index 메소드

  - 20년 pg만큼이나 오래된 프레임워크: Weblogic, JSP, Struts 1

  - JSP 내에서 DB까지 읽고 있음

## 레거시 개편 전략

- 20년 된 레거시 파라미터 연동 방식

  - 사실상 전역변수처럼 사용됨

- 외부 인터페이스 <-> 결제창의 Core 로직이 강결합

- 레거시 파라미터

  - 값이 그대로 사용되는 파라미터

  - 결제 세부기능을 제어하는 파라미터 (복잡하게 얽힘)

- 변환 Adapter가 비대해짐

- 단일 JSP: FE와 BE의 강결합

  - entry: 화면에 그리기 위한 데이터 받기

  - prepare: api 호출을 위한 단계

  - confirm: 결제 컨펌 단계

  - 웹브라우저 상에서 암호화된 Data Relay 필요

    - redirect/form 방식을 서버가 결정하도록 결정

- 검증

  - use case 수집

  - 수기 테스트

  - 검증 rule의 세분화 & 자동화

- 결제 서비스의 핵심? 서비스 연속성

  - canary 배포

- 전환과 검증

- 개편 결과 - 성능

  - entry 단계에서는 simple request -> RTT = 1 (preflight 제거)

- 개편 결과 - 비즈니스적 변경의 우수성

  - 10년치 기존 코드 분석

  - 기존 기능 + 유관 부서 니즈를 반영한 신규 기능

  - 운영담당 부서를 고려한 사용성 있는 얻믠 개발

  - be2, fe1 1달

- 개편 결과 - Peak 트래픽? 오히려 좋아!

  - Multi-layer Cache 설계가 촘촘하게 잘 되어 이써, Peak 트래픽이 오더라도 p95 기준 반응속도 개선

- 개편 결과 - 정리

  - 단순한 프레임워크 포팅 X

  - 비즈니스의 본질을 이해한 전면 재작성

  - 유연하게 대응가능한 시스템

  - "결제창" 하나만의 개편이 아닌,

  - 결제제품 전체를 지탱하는 기반의 개편

  - 결제제품 혁신을 가속하기 위한 준비

 

모던 FEP 이후의 구조 개선과 통합 여정 - bank 강우진 (12:50 ~ 13:20)

## 모던 FEP 소개

- 전문통신?

  - TCP, fixed length 방식

  - ex) 홍길동 123456790 00010000

- 모던 FEP

  - 전문 변화

## 모던 FEP 문제점 개선 과정

1. 대외기관: 세션 연결수 제한. 그래서 1.0, 2.0 서버 2대가 동시에 연결이 안됨

  - 순단 가능

  - 해결: 전문 송수신 서버와 전문변환 서버 분리

2. k8s active - active 환경으로 인한 순단 문제

- tcp 서버 노드 분리

## 운영 효율화 사례

- 운영 리소스 줄이기 - 서버 통합

  - 모던 FEP: 전문변환 서버, 전문송수신 서버

  - 전문변환 서버를 라이브러리 형태로 제공!

- 트러블슈팅 문의 자주 들어옴. 로그 확인 어려움

  - TCP 환경에서 trace 끊김 문제

    - 비동기로 돌기 때문에 발생

    - trace 전파 해결 - 요청시간, 전문요청번호를 key로 저장

## 레거시 FEP와의 통합 여정

- 마이그레이션 지원 요청

  - 바빠서, 너무 레거시라 대응해주기 어려움...

- 해결: 기능은 동일하게 유지하고, 통신만 모던 FEP를 호출하게 변경

- 사용자 입장에서 최소한의 변화 <!-- 역질의, idpToken 변화 -->

- 안정성

  - 노드 분리

- 운영효율화

  - trace id 연결을 통한 로그 쉽게 확인

  - 레거시 FEP -> 모던 FEP 통합 중

- 기존시스템도 움직이는데, 왜 바꾸나요?

 

 

확장성과 회복 탄력성을 갖춘 결제 시스템 만들기 - payments 박순현, 양권성 (13:30 ~ 14:00)

멋지다 순현쿤

## 양권성

- 토스페이먼츠의 결제 시나리오

  - 고객 - 쇼핑몰 - 결제수단 (토스페이먼츠)

  - 결제 원장: 고객이 결제하거나 취소한 거래내역을 보관하는 DB (테이블)

- 문제1. 일관성 없는 구조

  - 카드 취소/부분취소, 계좌이체 취소/부분취소 등등

- 문제2. 다양한 도메인 사이의 강한 의존성

  - 동일한 이름의 컬럼이 다른 의미로 테이블마다 사용

- 문제3. 비즈니스 확장을 가로막는 구조

  - pg_mastger - paytype (1:1)

  - 더치페이, 카드/페이 일부 등 불가

- 왜 MySQL로 전환?

  1. 시스템 안정성

    - 다른팀도 oracle을 쓰기에 영향을 주지 않기 위해

  2. 유지보수

    - 기존 oracle/mybatis -> mysql/jpa

  3. 유연한 확장과 실험

- 해결1: 일관성 있는 구조

  - 계좌이체 결제 승인, 카드 결제 승인

  - 결제 승인, 결제 취소

- 해결2: 도메인 간 결합도 낮추기

  - kafka 이벤트 기반. 결제 발생하면 이벤트 발행 -> 정산, 거래 대사, 기타 서버들 consume

- 해결3: 확장성 있는 구조

- 신규원장 전환: 비동기/예외 처리

- 신규원장 전환: 비동기 쓰레드풀 설정

  - 비동기 쓰레드풀 설정

- 신규원장 전환: 데이터 정합성 보장

  - 검증배치

- 신규원장 전환: 점진적인 트래픽 투입

- 신규원장 마이그레이션: 서버 분리

  - 마이그레이션용 서버 별도 구성

  - 병목 제거, 성능 테스트

- 신규원장 마이그레이션: bulk insert

  - jdbcTemplate

- 신규원장 마이그레이션: 캐시

  - in-memory cache (local)

- 신규원장 마이그레이션: 네트워크 대역폭

  - IDC, AWS 로 나뉘어져 있음.

 

## 박순현

- 장애인지

  - db cpu 100% 알람

  - 빠르게 이전 이미지로 rollback

- 장애원인

  - index 제대로 못타는 select 쿼리

  - 옵티마이저가 index가 아닌 full scan 탐

  - query hint 추가 -> 원하는 index 사용

- 장애 후속 대응

  - DB 부하로 적재 실패 -> 구&신규 원창 불일치

  - 원천사 & 원장 불일치

  - 원장 & 가맹점 불일치

  - 이벤트 발행 누락

- 1. DB 부하로 적재 실패 -> 구&신규 원창 불일치

  - socket timeout

  - connection close

  - 추가 커넥션 연결 실패

- 2. 원천사 & 원장 불일치

  - 보상 트랜잭션 방어 로직 있었음

- 3. 원장 & 가맹점 불일치

  - connection * 3 + read timeout

  - 전수 조사 후 timeout 조정

- 4. 이벤트 발행 누락

  - 아웃박스 패턴

  - es 에 로그. es 장애 대비를 위해 로컬 서버에 저장 후 es에 쌓음

- 초기 설계만큼이나 이후 운영 대응 역시 중요합니다.

  - 안정적인 시스템은

    - 스스로 회복할 수 있는가?

    - 잘못 처리된 데이터를 바로잡을 수 있는가?

 

4개 스티커 모으면 럭키 드로우 응모권이 가능하다. 비타500 당첨 되었다!