토스증권 서버 개발자가 많이 듣는 질문 4가지

https://toss.im/career/article/secu_server-chapter-2

토스증권 서버 개발자가 많이 듣는 질문 4가지 : 무엇이든 답해드려요

우연히 위 글을 읽게 되었는데 토스증권 개발자들의 기술적인 고민을 엿볼 수 있는 좋은 아티클이어서 정리해보려 한다!

 

크게 각 문답별 내용 및 그에 따른 학습 포인트를 정리해보고,

각 문답별 학습 포인트에 대한 내용들은 학습 후에 별도 포스팅으로 올릴 예정이다🙏

---

Q1. 현재 기술적으로 해결하려는 문제

• 서비스가 빠르게 커짐에 따라 기능간 통합 필요
• 소규모로 각각 운영하던 서버들이 증가라면서 유사한 성격의 서버와 데이터베이스가 흩어지며 구조적 한계가 드러남
• 한 화면에 보여지는 데이터가 각각 흩어져있어서 호출해야하는 api가 많아짐
• 이에 따라 aggregation 코드의 복잡성이 증가하하고 유지보수가 어려워짐
• 중간에 통합레이어를 두는 아키텍처 도입/고려 중
  • 장점 : 각기 다른 데이터 소스를 하나의 통일된 인터페이스로 추상화하여 서비스 단에서는 보다 단순하게 데이터를 사용할 수 있다
  • 단점 : 통합 레이어 자체가 성능 저하 또는 새로운 장애의 포인트가 될 수 있음
• 만약 통합레이어에 비즈니스 로직이 포함되어 있다면 upstream 서버의 변경이 통합 레이어에도 영향을 줄 수 있어 로직간 의존성과 팀 간의 커뮤니케이션이 중요해짐
• 따라서 앞으로는 이 통합 레이어를 얼마나 효과적으로 설계하고, 잘 관리해 나가는지가 기술적 관점에서 매우 중요한 미션이 될 예정
• 빠르게 변화하고 복잡해지는 서비스 환경에서, 이 통합 계층을 기술적 확장성과 안정성 모두를 만족시킬 수 있는 방향으로 고도화시키는 것이 필요

 

✏️ 학습 포인트

• 통합 레이어 아키텍처 ⇒ 여러 API 또는 DB를 하나의 일관된 방식으로 추상화하여 복잡도와 중복을 줄이고 유지보수성을 높이기 위한 아키텍처적 접근

키워드	설명
Backend for Frontend (BFF)	각 클라이언트(Web, App 등)의 특성에 맞는 API 인터페이스를 제공하기 위한 중간 계층. 통합 레이어와 유사한 목적.
API Gateway	다양한 마이크로서비스 API를 하나의 진입점으로 통합. 인증, 라우팅, 집계 등의 역할 수행.
GraphQL	클라이언트가 필요한 데이터만 요청하고, 여러 소스를 통합해 응답할 수 있는 API 쿼리 언어. 통합 레이어 대안으로 각광.
Aggregation Layer / Orchestration Layer	여러 마이크로서비스나 데이터 소스를 집계하거나 흐름을 제어하는 중간 계층.
Federated Architecture	서로 다른 도메인 서비스들이 하나의 통합 인터페이스(API, GraphQL 등)를 제공하기 위한 분산 설계 방식.
Service Composition	복수의 서비스 호출 결과를 조합하여 하나의 응답으로 만드는 기술.
Service Mesh	서비스 간 통신, 관찰, 제어를 위한 인프라 계층. 통합은 아니지만, 복잡성 관리 측면에서 유사한 문제 해결.
Clean Architecture / Hexagonal Architecture	비즈니스 로직과 외부 시스템(API, DB 등) 간의 의존성을 줄이고 추상화하는 계층화된 아키텍처. 통합 레이어 구현에 적합.

• API 호출 통합 + 화면 구성 복잡성 해결
  • Backend for Frontend
  • API Composition
  • GraphQL (vs REST)
  • API Gateway + Aggregation
• 다른 DB/API 구조 통합 및 추상화
  • Data Abstraction Layer
  • Service Aggregation Layer
  • Anti-Corruption Layer (도메인 주도 설계의 용어, 외부 시스템과 내부 도메인을 분리)
• 성능 문제 및 장애 포인트 관리
  • Resilience4j, Hystrix, Circuit Breaker
  • Caching in API Gateways
  • Distributed Tracing (예: OpenTelemetry)
• 협업 및 의존성 관리
  • Domain-Oriented Microservices
  • Team Topologies
  • Conway's Law

• 학습 방향
  • BFF & API Aggregation 아키텍처부터 시작
  • GraphQL vs REST의 통합 가능성을 비교
  • 도메인 기반 아키텍처(Domain-Oriented Architecture)로 확장

 

---

Q2. 대규모 트래픽 처리 방식

• CQRS 아키텍처 도입
  • 데이터의 읽기/쓰기 분리를 통해 성능을 높임
  • 원본 데이터는 Oracle에서 관리되며, 읽기 전용 뷰는 별도의 DB로 분리하여 트래픽 분산
• 서비스가 성장함에 따라 데이터가 급증하여 단일 인스턴스 기반 구조로는 한계가 명확해짐 → Vitess 도입
  • Vitess: MySQL 기반의 샤딩 게이트웨이
  • 실시간으로도 안정적인 reshard가 가능하고, OLTP 성격의 대용량 데이터 처리에 매우 적합한 구조
• 현재 토스증권은 Vitess를 기반으로 CQRS 구조를 확장했고, API 응답 속도는 p95 기준 40ms 수준을 유지하며, 실시간 일관성이 필요한 데이터는 대부분 10ms 이내로 업데이트 됨
• read view database를 사용하면 데이터 일관성에 대한 굉장한 관리가 필요 → 원본 database와 실시간 검증기를 거치고, 매일 잔차(소량) batch를 통해 데이터의 오염 확인
  • 주기적인 검증 및 추가 잔여 배치를 통해 일관성 유지

 

✏️ 학습 포인트

주제	탐색 키워드
Vitess 내부 동작 원리	Vitess architecture, Vitess resharding, Vitess VReplication
CQRS 실무 적용 시 고려사항	CQRS trade-offs, CQRS with eventual consistency
실시간 데이터 정합성 검증기 구현	data consistency checker, CDC vs checksum validation
잔차 batch 설계 방식	residual data validation batch, data reconciliation job
p95 latency 기준	SLA vs p95 vs p99, latency percentile monitoring
읽기/쓰기 분리 아키텍처 사례	read replica architecture, read/write split

• 아키텍처 확장성 확보는 구조적 전환(CQRS, 수평 확장)과 운영적 세부 관리(정합성 체크)의 균형이 중요
• 실시간성과 일관성을 동시에 잡기 위한 검증 체계(실시간 + batch)는 고도화된 시스템 운영의 핵심 요소
• 단일 성능 지표(p95, 10ms 등)를 명확히 정하고, 그것을 위한 기술 선택을 실무에 반영하는 방식은 현실적인 성능 목표 설정 및 달성 방법의 좋은 사례

 

---

Q3. 안정성을 위한 모니터링 및 트러블 슈팅 방식

• Grafana, Kibana, Flink 등 다양한 오픈소스 활용
• 이를 통해 에러 개수, Thread 고갈, Api 실패율, Kafka Log 증가 등 서비스의 특성에 따른 다양한 이상치 모니터링
• 이상치가 감지되면 Alert 시스템을 통해 서비스 담당자에게 전파
  • 최근에 Alert 시스템 개선을 통해 전파 시간을 5분 → 1분으로 단축
• 발생한 에러의 특정 서버, 유저와 같은 동일한 특성을 가지고 있는지도 함께 전송하여 빠른 원인 파악에 도움
• 트러블 슈팅 시 최근 변경 이력 파악 및 영향 가능성을 우선으로 확인
• 이와 동시에 Jaeger, Pinpoint와 같은 트레이싱 도구를 통해 서비스 간 호출 흐름을 분석하여 에러가 최초로 발생한 서비스 식별
• 이후 해당 서비스에 대해 Tcp dump, Thread dump와 같은 프로파일링 도구를 이용해 상세 분석 진행
• 이를 통해 CPU, 메모리와 같은 리소스에 과다 사용, 스레드 고갈, 데드락 등 시스템의 병목 발생 가능 지점을 찾아냄
• 다양한 공통화 도구도 제공 → 공통 메트릭 포맷, 프로파일링 도구, 로그, 트레이싱 등..

 

✏️ 학습 포인트

항목	설명
1. 실시간 모니터링 도구 활용	Grafana (대시보드), Kibana (로그 분석), Flink (실시간 스트리밍 처리) 등을 활용해 이상치를 탐지함
2. 모니터링 지표 다양화	단순 에러 개수뿐 아니라 - API 실패율 - Thread 고갈 - Kafka lag 등 서비스 특화 지표도 모니터링
3. Alert 전파 시스템 고도화	Alert 전파 시간을 5분 → 1분으로 단축+ 관련 context (서버, 유저 등) 포함하여 빠른 원인 분석 가능하게 함
4. 트러블슈팅 흐름 정형화	① 최근 배포/작업 여부 확인② Jaeger, Pinpoint로 호출 추적③ Thread dump, TCP dump로 시스템 병목 분석
5. 성능 병목 탐지 포인트	CPU 과다, 메모리 누수, 스레드 고갈, 데드락 등 주요 장애 원인을 탐지
6. 도구 접근성 및 공통화	프로파일링, 트레이싱, 메트릭 수집 도구를 사내 어드민 툴로 누구나 쉽게 접근 가능하게 제공
7. 메트릭 포맷 표준화	서비스 간 공통 메트릭 포맷 정의하여 일관된 모니터링 구조 구성

 

기술 스택 별 학습 포인트

도구	사용 목적
Grafana	실시간 대시보드로 지표 시각화
Kibana	로그 기반 분석 및 검색
Apache Flink	스트리밍 데이터를 실시간 처리하여 이상 탐지
Jaeger / Pinpoint	분산 트레이싱 도구로 서비스 간 호출 흐름 분석
Tcpdump / Thread dump	시스템 레벨의 네트워크, 스레드 상태 정밀 분석
Custom Admin Tool	내부 공통화된 프로파일링/트레이싱 도구 접근 허브

 

 

실무 적용 관점

주제	인사이트
관측 가능한 시스템 설계 (Observability)	서비스 지표 + 로그 + 트레이싱 + 시스템 dump를 연계한 종합적 관찰 구조
문제 탐지부터 해결까지의 속도 최적화	탐지 → 알림 → 분석 → 해결 루프의 속도와 정확도 모두 중요
공통화와 자동화의 중요성	도구와 포맷을 통합·표준화함으로써 개인 역량에 의존하지 않는 운영 구조 달성
컨텍스트 포함된 Alert	Alert 전파 시 에러 발생 지점의 특징(서버, 유저 등)을 포함해야 빠른 대응 가능

 

 

---

Q4. 서버 개발자의 인재상

👨‍💻 새벽마다 모니터링과 트러블슈팅으로 인해 모두가 기피하는 도메인에서 오늘도 묵묵히 팀에 필요한 일을 하는 김토증님. (mission over individual)

☕ 오늘도 커피챗과 함께 동료들에게 피드백을 구합니다. (ask for feedback)

🤷‍♂️ 김토스님의 피드백을 통해 본인이 요즘 너무 많은 태스크에 치이며 산다는 걸 상기합니다. 나에게 가장 임팩트가 큰 일은 뭘까? (focus on impact)

🤔 매일 새벽에 도는 문제의 배치. 어제도 트러블슈팅하고 모니터링 하느라 새벽잠을 설쳤습니다. 어떻게 하면 재발 방지를 할 수 있지? 근데 이거 꼭 새벽에 돌아야 하나? 어쩌면 굳이 배치일 필요는 있나? (question every assumption)

💡 도메인 문서도 살펴보고, 히스토리도 보고, 예전 담당자도 찾아봅니다. 근본부터 다시 이해하고 구조를 재설계해 봅니다. 지금은 개선할 수 있을 것 같습니다. 동료들과 논의한 결과, 지금은 컨슈머 구조로 바꾸는 게 오히려 더 좋다는 결론에 도달했습니다. (learn proactively)

🙆‍♂️ 일부 우려를 표하는 동료도 있지만, 할 수 있는 부분부터 해보면 좋을 것 같습니다. 간단하게 만들어서 테스트 환경에서 검증해 봅니다. (execution over perfection) 가설이 잘 동작했고, 동료들의 우려도 해소됐습니다.

🏃‍♂️ 최대한 빠르게 작업에 몰입합니다. (move with urgency) 동료들은 김토증님이 임팩트에 집중할 수 있도록 다른 업무들을 지원해 줍니다.

🚀 빠르게 만들고 꼼꼼하게 테스트해서 라이브에 릴리즈 합니다. 새벽에 때로는 다섯 명까지도 고통받던 업무가 사라졌습니다. 고객들은 일 1회 바뀌던 것을 실시간으로 볼 수 있게 됐습니다. (aim higher)

😀 자기 전에 커뮤니티에 글이 하나 올라왔습니다. "버핏 님의 새 글이 등록되었습니다. 이거 실시간으로 바뀐 거 보심?" 고객님들의 인정에 오늘도 뿌듯함을 느끼며 하루를 마무리합니다.

이건 토스만의 개발을 향한 순수 광기✨ 가 느껴져서 가져와봤다..

이렇게만 하면 사실상 특정 회사가 아닌 개발자의 참인재상이 아닐까 싶다😅