토스증권 Server Developer (Product) 공고 분석: 제품 개발자에게 원장 수준의 정합성을 요구하는 이유

게시 2026/05/03

By August

조회 34 분 읽는 시간

이 글을 쓰는 시점 기준으로 토스증권의 Server Developer (Product) 채용공고와 그 주변 자료를 읽었다. 공고 본문만으로는 역할의 윤곽이 잘 잡히지 않아서, 토스 커리어의 현직자 인터뷰, 서버 챕터 Q&A, SLASH 22·23 발표, Toss Tech 글, AWS 기술 사례까지 함께 봤다. 이 글은 그 자료들을 한 방향으로 읽어 낸 기록이다.

먼저 결론을 적어 두면 이렇다. 공고명은 제품 서버 개발자지만, 실제로 요구하는 것은 고객이 직접 쓰는 투자 제품을 빠르게 만들면서 동시에 실제 자산을 다루는 시스템의 정합성·실시간성·장애 복원력을 끝까지 책임지는 역할이다. 제품 개발과 원장 수준의 안정성을 따로 떼어 준비하면 어느 한쪽이 비게 된다.

공고가 말하는 것과 말하지 않는 것

공고의 배치 범위는 일반적인 제품 사일로보다 넓다.

배치 가능 영역	주요 업무
제품 사일로	계좌·수익률·검색·주문·시세·커뮤니티·알림 등 고객 접점 제품
원장 플랫폼	주식 매수·매도, 결제, 권리, 환전 등 금융 원천 데이터
백오피스	비대면 업무 처리, 망분리 환경의 내부 운영 제품
신규 영역	AI 투자 서비스, 레버리지·담보대출, 글로벌 제품

소속은 입사 전에 회사 우선순위와 지원자의 강점을 종합해 정한다고 한다. 즉 특정 제품 하나를 겨냥해 준비하는 것보다 “제품 개발 + 금융 정합성 + 대규모 운영”을 한 묶음으로 준비해야 한다.

기술 스택은 Java, Kotlin, Spring, JPA/Hibernate, MySQL, Oracle, MongoDB, Redis, Kafka, Elasticsearch, Kubernetes, ELK, Grafana가 중심이고, 일부 영역에서 Go, Netty, NATS를, 실시간·네트워크 영역에서 WebSocket, FIX, UDP multicast를 쓴다. 공고가 따로 강조하는 역량은 대규모 트래픽과 동시성, JVM부터 OS·네트워크까지 내려가는 트러블슈팅, 실시간 데이터 처리, 기존 시스템 개선, 그리고 담당 영역의 기술적 최종 의사결정이다. 공식 채용공고

공고가 직접 말하지 않는 것은, 이 스택 목록이 어떤 문제를 풀기 위해 조합돼 있는가다. 그건 공개된 아키텍처 자료를 읽어야 보인다.

제품 영역에서 실제로 풀리는 문제

Product 서버 개발자가 닿을 수 있는 영역은 계좌 정보와 실시간 수익률, 국내·해외주식 주문과 체결 상태, 종목 검색과 가격 변동, 실시간 시세와 호가, 커뮤니티와 투자 콘텐츠, 관심 종목·체결·가격 알림, AI 기반 투자 정보, 미수 거래와 주식담보대출 같은 레버리지 제품이다.

이 목록에서 “API를 만들었다”는 문장은 힘이 없다. 대신 이런 질문에 답이 있어야 한다.

여러 시스템의 데이터를 어떻게 한 화면에 일관되게 조합했는가
주문이나 잔고가 중복 처리되지 않도록 무엇으로 보장했는가
외부 시스템이 느리거나 응답을 잃었을 때 고객에게 무엇을 보여줬는가
장애 중에 최신 데이터와 정확한 데이터 중 무엇을 우선했는가
운영자가 새벽에 수동 조치하지 않도록 무엇을 자동화했는가

원장 쪽은 더 분명하다. 원장은 고객 주문, 잔고, 체결, 배당·액면분할 같은 권리, 환전 내역을 기록하는 핵심 시스템이다. 2026년 현직자 인터뷰에는 해외주식 권리 도메인의 구조 설계와 테스트 환경 구축, 국내주식 권리 원장의 안정화와 제도 개편 대응, MSA 환경의 트랜잭션 관리, 법률·제도 변경 히스토리를 AI 에이전트로 탐색하는 일, AI 서비스 결과를 서빙하는 서버와 데이터 파이프라인 같은 업무가 나온다. 권리 도메인은 숫자 하나가 틀려도 고객 자산에 영향을 주므로 “유연한 변경 구조”와 “강한 검증”을 동시에 요구한다. 2026년 서버 개발자 인터뷰

공개 자료로 복원한 시스템의 모양

여섯 개의 자료를 순서대로 읽으면 하나의 원칙이 반복된다. 데이터 종류마다 유실 허용 여부, 순서 보장, 최신성 우선순위, 복구 방식을 다르게 정한다는 것이다. “항상 Kafka”, “항상 무손실”이 아니다.

빠른 성장이 남긴 통합 문제

초기에는 제품마다 독립 서버와 DB를 빠르게 만들었고, 서비스가 커지면서 유사한 서버와 DB가 도메인마다 분산되고, 한 화면을 위해 수많은 API 호출이 필요해지고, 서비스별 aggregation 코드가 늘고, 같은 데이터를 제품마다 제각각 해석하고, upstream 변경이 여러 화면과 서버로 전파되는 문제가 생겼다고 설명한다. 그래서 여러 데이터 소스를 추상화하는 통합·집계 레이어를 중요한 과제로 본다. 다만 통합 레이어는 그 자체가 병목이자 단일 장애점이 될 수 있으므로 비즈니스 로직의 위치, 캐시, timeout, circuit breaker, tracing, 팀 간 소유권을 함께 설계해야 한다.

면접에서 BFF나 GraphQL 같은 정답을 요구한다기보다, 분산된 도메인을 어디까지 통합하고 어디까지 분리할지의 트레이드오프를 말할 수 있어야 한다는 뜻으로 읽힌다. 서버 챕터 Q&A

CQRS와 Vitess로 읽기를 분리하되, 검증기로 위험을 통제한다

서버 챕터 Q&A에 따르면 원본 데이터는 Oracle에서 관리하고, 조회 트래픽은 별도의 읽기 전용 모델로 분리하며, MySQL 계열 수평 확장에 Vitess를 쓴다. 공개 당시 API p95는 약 40ms, 실시간 일관성이 필요한 데이터는 대부분 10ms 이내에 갱신됐다. 여기서 눈여겨볼 것은 성능 수치가 아니라 그 다음 문장이다. 원본과 read view 사이에 실시간 검증기를 운영하고, 실시간 검증이 놓친 잔차는 일 배치로 다시 대사한다.

CQRS를 성능 패턴으로만 쓰는 것이 아니라, eventual consistency가 만드는 위험을 온라인 검증과 배치 대사 두 겹으로 잡는다는 이야기다. 이 구조를 놓고 나올 만한 질문은 다음과 같다.

read model 지연을 사용자에게 어떻게 표현할 것인가
CDC 이벤트가 중복·역전·유실되면 어떻게 복구할 것인가
원장과 조회 DB의 차이를 어떻게 탐지할 것인가
온라인 검증과 배치 대사의 책임을 어떻게 나눌 것인가
resharding 중 쓰기·읽기 일관성을 어떻게 관리할 것인가

실시간 시세: WebSocket과 polling fallback

초기 토스증권은 polling도 썼지만 더 빠른 시세를 위해 WebSocket을 도입했고, WebSocket 장애나 지연에 대비해 polling API를 fallback으로 유지했다. 공개 자료가 설명하는 흐름은 이렇다.

flowchart TD
    A["거래소 시세"] --> B["수신부<br/>UDP multicast"]
    B --> C["처리부<br/>가공·정합성·저장"]
    C --> D["Redis / 메시지 전달"]
    D --> E["WebSocket 서버"]
    E --> F["토스증권 앱"]
    G["REST 조회부"] --> F
    E -. "지연·장애" .-> G

초기 WebSocket 구조에서는 전자금융 망분리 요건과 네트워크 홉을 고려해 DMZ에 WebSocket 서버를 두고, 별도 라우팅 서버와 Redis로 클라이언트 연결 위치를 관리했다. SLASH 22 세션, 발표 영상

시세 처리부: 저지연을 위해 유실을 받아들인다

SLASH 23 발표는 시세 플랫폼을 수신부·처리부·조회부로 나눈다. 수신부가 거래소 UDP multicast를 받고 수신 시각을 헤더에 넣어 end-to-end latency를 잰다. 처리부가 비즈니스 로직 뒤 Redis에 저장하거나 서비스로 전달하고, 조회부가 REST API를 제공한다. 처리부와 저장소를 복제해 장애 시 오염되지 않은 경로로 전환한다.

선택이 드러나는 지점은 메시징이다. Kafka보다 낮은 latency가 필요한 구간에는 Redis Pub/Sub을 썼다. Redis Pub/Sub은 영속 큐가 아니므로 유실 가능성을 받아들이는 대신 저지연을 얻는다. 종목별 순서는 이벤트 루프 단위로 채널을 분리해 보장하고, Redis 저장은 ReactiveRedisTemplate 같은 non-blocking 방식으로, 과거 값 조회는 local cache로, RDB 적재나 배치는 별도 EventLoopGroup으로 격리했다. SLASH 23 세션, 발표 영상

해외주식 주문: 분산락 다음에 무엇이 있는가

해외주식은 국내 시스템에서 해외 브로커를 거쳐 현지 거래소로 주문한다. 공개된 설계의 선택은 다음과 같다.

MSA 간 계좌 단위 동시성 제어에 Redis 분산락
분산락 timeout 전에 트랜잭션이 끝나지 않는 예외 상황은 JPA optimistic locking/CAS로 방어
주요 테이블의 변경 이력 관리
브로커 호출을 주문 트랜잭션에서 분리해 비동기 처리
응답 유실·TCP timeout 시 임의로 성공이나 실패로 처리하지 않음
멱등 API와 제한된 재시도, exponential backoff
끝까지 해결되지 않은 건은 사후 대사와 운영으로 복구
브로커별 어댑터·요청 서버로 외부 의존성을 매매 서버에서 격리
Kafka 장애 시 polling으로 전환하는 failover 경로

SLASH 22 세션, 발표 영상

이 포지션 면접에서 가장 깊게 파일 주제로 보인다. 분산락을 썼다는 설명으로는 부족하고, lease 만료 뒤에도 이전 작업이 계속 실행되는 문제, fencing token 또는 version 기반 갱신, 외부 주문 요청의 idempotency key, 요청은 성공했는데 응답을 잃은 상태의 reconciliation, at-least-once 소비에서의 중복 방지, 트랜잭션 DB와 Kafka 사이의 atomicity, outbox·CDC·saga의 적용 범위와 한계까지 이어져야 한다.

폭증 트래픽과 브로커 장애: 탐지에서 전환까지 자동화

해외주식 서비스 안정화 사례에는 트래픽 특성이 구체적으로 나온다. 미국 정규장 시작 시 평시 대비 TPS가 20배 이상 뛰고, 서비스 초기 대비 주문 요청은 약 30배 늘었으며, 정규장 시작 직후 100만 건 이상의 예약 주문이 전송된다. 브로커가 수용 가능한 TPS를 넘지 않도록 resilience4j RateLimiter를 두고, Grafana·Kibana 규칙으로 이상 징후를 감지하면 그 결과를 Kafka 이벤트로 발행하고, 이를 구독한 시스템이 메인 브로커에서 서브 브로커로 스스로 전환한다.

여기서 “운영”은 알람을 받고 사람이 고치는 것을 뜻하지 않는다. 탐지 → 판단 → 격리 → 전환의 상당 부분이 자동화되어 있다. 해외주식 서비스 안정화 사례

미국 옵션: 초당 수백만 건 앞에서 데이터마다 다른 정책

2025년 AWS와 공동 공개한 사례가 현재 규모를 가늠하기에 가장 유용하다. 미국 옵션 종목은 약 160만 개, 장 초반 초당 200만~300만 건이 발생한다. Virginia 리전에 EKS와 Amazon MSK 기반 처리 시스템을 두고, Sliding Window Counter로 rate limit을 걸고, 3개 AZ에 걸친 2개 Kubernetes 클러스터와 이중화된 국내 데이터센터 채널로 전송한다. 데이터 결측을 감지하면 Slack 알림과 함께 보조 vendor를 자동 활성화하고, Virginia–Seoul latency를 지속 측정해 임계치 초과를 잡는다.

정책의 차이가 분명하다. NBBO는 최신 상태가 중요하므로 유실 시 과거 데이터를 버리고 최신 값을 우선한다. 체결 데이터는 순서와 차트 복원이 중요하므로 별도의 영속 경로를 둔다. 실시간 경로는 Kafka acks=0, 복구용 원천은 acks=all로 이중 전송한다. AWS 기술 사례

모니터링과 트러블슈팅에서 보는 것

서버 챕터 자료에 따르면 API 실패율과 응답 지연, 스레드 고갈, Kafka lag과 로그 증가, CPU·메모리 이상, 에러 수와 특정 서버·사용자군의 공통 특성, 서비스 간 호출 실패를 서비스 특성에 맞춰 감시한다. 운영 흐름은 대체로 다음 순서다.

최근 배포·설정 변경 확인
Grafana·Kibana·Flink 기반 이상 탐지
알림에 서버·사용자 등 원인 분석용 context 포함
Jaeger·Pinpoint로 분산 호출 경로 추적
TCP dump·thread dump·heap/profile 분석
CPU, 메모리, 스레드 고갈, deadlock 등 병목 확인
재발 방지와 공통 도구화

알림 전달 시간을 5분에서 1분으로 줄인 사례도 공개돼 있다. 지원자 입장에서는 “장애를 해결했다”보다 MTTR을 어떻게 줄였고 같은 장애가 재발하지 않도록 무엇을 표준화했는지를 설명하는 편이 이 흐름과 맞는다. 서버 챕터 Q&A

조직 구조와 기대하는 행동

제품은 PO, Product Designer, Frontend, Server, Data Analyst 등 6~8명 규모의 사일로가 자율적으로 만든다. 서버 개발자는 동시에 서버 챕터에 속해 상시 코드 리뷰, 서버 챕터 위클리, 엔지니어링 데이, 기술 스터디와 설계 토론, 공통 라이브러리·모니터링·개발 방식 공유에 참여한다. 사일로에서 비즈니스 임팩트를 만들고 챕터에서 기술 품질과 표준을 올리는 이중 구조다.

공식 Q&A가 제시하는 인재상은 꽤 구체적이다.

아무도 맡고 싶어 하지 않는 문제라도 팀에 중요하면 맡는다
피드백을 적극적으로 구한다
태스크 수보다 임팩트가 큰 일을 고른다
“왜 배치여야 하는가”처럼 기존 전제를 의심한다
문서·히스토리·이전 담당자를 찾아 근본 원인을 학습한다
작게 구현해 가설을 빠르게 검증한다
완벽한 계획보다 실행과 학습을 우선한다
운영 고통을 제거하고 고객 경험의 변화를 확인한다

문화적합성 인터뷰에서 “주도적입니다” 같은 형용사보다, 주인 없는 문제를 발견하고 동료를 설득해 운영 방식까지 바꾼 사례 하나가 필요하다는 뜻이다. 근무 시간은 고정된 9-to-6보다 생활 패턴에 맞춰 조율하는 유연성을 강조하지만, 결과와 책임은 강하게 요구한다. 2026년 인터뷰

전형에서 무엇을 보는가

채용 절차는 서류 → 라이브 코딩 인터뷰 → 직무 인터뷰 → 문화적합성 인터뷰 → 레퍼런스 체크 → 처우 협의 순이다.

서류

공고와 2026년 합격자 인터뷰를 종합하면 이력서의 각 항목은 다음 순서로 서술하는 것이 맞다.

문제 → 규모·제약 → 검토한 선택지 → 선택 이유 → 직접 한 일 → 수치 결과 → 장애·한계 → 후속 개선

예를 들면 이런 문단이다.

주문 급증 시간대에 DB lock 경합으로 p99가 3.2초까지 증가했다. Redis 분산락, DB 비관적 락, optimistic locking을 비교했고, 충돌 빈도와 장애 시 안전성을 고려해 계정 단위 직렬화와 version 검증을 함께 적용했다. p99를 480ms로 줄이고 중복 갱신을 제거했다. 이후 lock lease 만료 상황을 fault injection으로 재현하는 테스트를 CI에 추가했다.

준비해야 할 경험은 여섯 종류로 정리된다.

데이터 정합성 또는 트랜잭션 문제를 해결한 경험
트래픽·응답 시간·비용을 수치로 개선한 경험
실제 장애를 JVM·DB·네트워크 수준까지 추적한 경험
외부 시스템의 지연·실패를 격리한 경험
반복 운영을 자동화하거나 팀 공통 도구로 만든 경험
고객 문제를 기술 과제로 변환하고 직접 의사결정한 경험

프로젝트 수를 늘리기보다 가장 깊게 설명할 수 있는 3~4개를 고르는 편이 낫다. 합격자들도 경력 나열보다 임팩트가 큰 프로젝트, 수치화된 결과, “왜 그 해결책이었는가”를 중심으로 준비했다. 2026년 합격자 인터뷰

라이브 코딩

합격자들의 공통 행동은 문제를 읽은 뒤 이해한 요구사항을 다시 말하고, 모호한 조건을 질문하고, 풀이 전에 자료구조와 복잡도를 설명하고, 코딩 중 사고 과정을 계속 공유하고, 인터뷰어의 피드백을 방어적으로 받지 않고, 우선 동작하는 해법을 만든 뒤 개선하고, edge case와 테스트를 직접 제시하는 것이었다. 언어 숙련도 시험이라기보다 문제 정의·사고력·협업 가능성을 보는 페어 프로그래밍에 가깝다고 현직자들은 설명한다.

직무 인터뷰

CS 퀴즈보다 본인의 프로젝트를 깊게 파는 방식이다. 다음 꼬리 질문은 미리 답을 써 두는 것이 좋다.

왜 이 기술을 선택했는가
대안은 무엇이었고 왜 제외했는가
장애가 나면 어떤 순서로 확인하는가
데이터 중복과 유실을 어떻게 검증했는가
이 구조의 가장 큰 단점은 무엇인가
트래픽이 10배가 되면 어디가 먼저 깨지는가
지금 다시 만든다면 어떻게 바꾸겠는가
본인이 아닌 팀 전체에 남긴 변화는 무엇인가

실제 인터뷰에서는 Kotlin Coroutine 질문에 정확히 답하지 못한 지원자가 Java 비동기 처리 경험으로 사고를 이어갔고, “지금 다시 만든다면 어떻게 설계하겠는가”라는 질문이 나왔다. 키워드를 외우는 것보다 모르는 지점에서 아는 원리로 추론하는 태도가 평가된다.

준비 우선순위

공개 자료에서 반복되는 빈도와 이 포지션의 책임 범위를 기준으로 순서를 매기면 다음과 같다.

순위	영역	구체 항목
1	정합성과 동시성	isolation level, MVCC, optimistic/pessimistic locking, Redis 분산락과 lease 만료, idempotency key, transactional outbox, CDC, saga와 보상 트랜잭션, 순서 보장·중복 소비·reconciliation, 금융 원장과 감사 이력
2	Kafka와 이벤트 처리	partition key와 종목·계좌 단위 순서, consumer group과 rebalance, retry topic과 DLQ, producer `acks`와 idempotent producer, lag 모니터링, exactly-once의 실제 범위, Kafka 장애 시 polling fallback, IDC·리전 이중화
3	JVM·Spring 운영	Coroutine과 Reactor의 차이, Tomcat thread pool과 connection pool, blocking/non-blocking I/O, GC와 heap dump, thread dump와 deadlock, Spring transaction proxy, JPA dirty checking·N+1·batch, graceful shutdown
4	실시간 네트워크	WebSocket 연결·heartbeat·reconnect, TCP flow control과 receive buffer, UDP multicast 특성, event loop와 종목별 순서, FIX 기본 구조, connection timeout과 unknown outcome, backpressure와 load shedding
5	분산 시스템 운영	CQRS와 read model, Vitess·샤딩·resharding, circuit breaker와 rate limiter, p95/p99, Grafana·Kibana·분산 tracing, Kubernetes rollout과 장애 격리, chaos·fault injection 테스트

1순위가 정합성인 이유는 분명하다. 위에서 본 여섯 개 자료 모두가 결국 “무엇을 잃어도 되고 무엇은 잃으면 안 되는가”를 정하는 이야기였다.

지원 전에 인지할 현실

기술적으로 매력적인 만큼 책임 범위가 크다. 국내 장은 오전, 미국 장은 한국 기준 야간에 열린다. 브로커·거래소·인증기관처럼 통제할 수 없는 외부 시스템이 많다. 주문·잔고·배당은 단순 재시도로 처리하면 자산이 중복 변경될 수 있다. MSA에서는 로컬 트랜잭션만으로 전체 정합성을 보장할 수 없다. 금융 제도와 법률 개정에 따라 기존 시스템을 계속 바꿔야 한다. 빠른 출시와 금융 안정성이 동시에 요구되고, 자율성이 큰 만큼 “담당자가 아니어서 하지 않았다”는 태도와는 맞지 않는다.

반대로 증권 경력이 필수는 아니다. 최근 합류자 인터뷰에서도 배달 주문 시스템, 검색 플랫폼, 데이터 엔지니어링 경험이 토스증권 업무로 이어졌다. 중요한 것은 기존 경험을 주문·정합성·실시간 데이터·외부 의존성 문제로 번역할 수 있는지다.

내 경험을 어떻게 번역할 것인가

지금까지의 경력을 다음 네 축으로 다시 분류하는 것이 가장 효율적이라고 판단했다.

평가 축	제시해야 할 증거
제품 임팩트	고객 지표, 전환율, latency, 운영 시간 같은 수치
금융 수준의 안정성	중복·유실·순서·감사·복구를 다룬 경험
기술적 깊이	JVM·DB·네트워크까지 원인을 추적한 과정
Ownership	주인 없는 문제를 정의하고 조직에 전파한 경험

자기소개의 방향도 여기서 정해진다. “Java/Spring을 쓰는 개발자”가 아니라 실제 고객 트래픽에서 정합성과 성능 문제가 났을 때 여러 계층을 추적하고, 기술 선택의 트레이드오프를 설명하며, 재발 방지까지 제품과 운영에 반영해 온 개발자로 위치를 잡는다.

한 가지 단서를 남겨 둔다. SLASH 22·23 자료는 당시 아키텍처의 스냅샷이므로 세부 구현이 지금도 같다고 단정할 수 없다. 다만 2025~2026년 자료에서도 MSA, 실시간 대용량 처리, 정합성, Kafka·Redis, 장애 대응 자동화라는 방향은 일관되게 확인된다.

참고 자료

Recruit, Information