[넥스트증권] Backend Engineer(국내 주식 주문·체결) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 국내 주식 주문·체결·잔고 도메인의 백엔드 시스템을 설계·개발·운영합니다.

  이렇게 볼 수 있어요

  주문이 접수되면 매수 가능 금액이나 매도 가능 수량이 먼저 묶이고, 체결 통보가 와야 잔고가 확정되는 구조라 세 도메인은 상태를 계속 주고받습니다. 주문 상태(접수·정정·취소·부분 체결·전량 체결)를 어떤 모델로 관리했고, 정정·취소와 체결이 뒤섞일 때 잔고를 어떻게 맞췄는지가 이 업무에서 가장 먼저 설명할 부분입니다.

• 한국거래소(KRX)와 연동하고 정규장·시간외·단일가 등 시장 세션에 따른 주문 파이프라인을 설계·구축합니다.

  이렇게 볼 수 있어요

  정규장은 주문이 들어오는 대로 체결되는 접속매매이지만, 장 시작·마감 동시호가는 일정 시간 주문을 모아 한 가격으로 체결합니다. 한국거래소는 2026년 9월 14일부터 오후 4~6시 시간외 단일가를 없애고 오후 4~8시 애프터마켓(시간외 접속매매)을 열었습니다. 같은 파이프라인이 세션마다 주문 접수 시간, 허용되는 주문 유형, 체결 방식을 다르게 처리해야 하므로, 세션이 바뀌는 시점의 경계 처리나 거래소 전문 연동을 다뤄 본 경험이 있다면 어떤 세션 규칙을 코드로 옮겼는지를 구체적으로 밝히면 됩니다.

• 대량 주문과 실시간 체결 이벤트 스트림을 안정적으로 처리하는 아키텍처를 설계하고 고도화합니다.

  이렇게 볼 수 있어요

  장 시작 직후와 마감 동시호가 체결 때 주문과 체결 통보가 한꺼번에 몰립니다. 기술 스택의 Kafka로 체결 이벤트를 흘린다면 같은 주문의 이벤트 순서를 어떻게 지켰고 중복 통보를 어떻게 걸렀는지가 아키텍처 경험을 보여 주는 지점입니다.

• 거래 무결성과 데이터 정합성을 보장하는 도메인 모델과 트랜잭션을 설계합니다.

  이렇게 볼 수 있어요

  주문 시스템의 정합성은 회사 원장과 거래소 체결 내역이 하루 끝에 맞는지로 확인됩니다. 같은 회사 국내 주식 결제 및 권리 업무 공고가 예탁결제원과의 약정대사를 운영 업무로 적었으므로, 이 파트의 체결 데이터가 틀리면 그 대사에서 차이로 나타납니다. 정합성을 트랜잭션 경계 안에서 지킨 부분과 사후 대사로 잡은 부분을 나눠 말할 수 있는 사례가 이 업무에 맞습니다.

• 서비스 오픈 이후 트래픽 증가에 대비해 시스템 처리 성능을 개선하고 확장 기준을 세웁니다.

  이렇게 볼 수 있어요

  서울경제 보도대로 오픈 API가 먼저 나오면 외부 프로그램이 계좌에 연결해 주문을 넣게 되어, 사람이 앱에서 누르는 주문보다 짧은 간격의 주문이 들어올 수 있습니다. 확장 기준을 세우는 일은 실제 트래픽이 아직 없는 상태에서 목표 처리량을 정하고 부하 테스트로 한계를 재는 일이므로, 출시 전에 용량 계획을 세워 본 경험이 그대로 쓰입니다.

• 안정적인 서비스 운영을 위해 무중단 배포, 실시간 모니터링, 장애 대응 체계를 계속 개선합니다.

  이렇게 볼 수 있어요

  국내 주식은 평일 장중에 배포하기 어렵고 2026년 9월부터 애프터마켓이 오후 8시까지 열려, 배포 시간이 밤 시간과 주말로 좁아집니다. 팀이 정해진 배포 프로세스에 따라 단계적으로 배포한다고 적은 것도 이 제약 안에서 위험을 나누는 방식입니다. 장중 장애를 대응해 본 경험이라면 영향을 받은 주문 건수와 복구 시간을 함께 적으면 됩니다.

2자격 요건

• 백엔드 개발 경력이 5년 이상이어야 합니다.

  이렇게 볼 수 있어요

  업무가 주문·체결·잔고 세 도메인을 설계부터 운영까지 묶고 있어, 5년 가운데 주문·결제·예약처럼 상태가 많은 거래형 서비스를 설계하고 운영까지 책임진 프로젝트를 자세히 적으면 이 공고의 범위와 이어집니다. 공고 하단은 금융 도메인 경험이 없더라도 배우며 함께 만들어 갈 사람을 찾는다고 적어, 커머스 주문 시스템 경력도 같은 흐름으로 꺼낼 수 있습니다.

• Kotlin 또는 Java와 Spring Boot로 백엔드 서비스를 설계·개발해 봤어야 합니다.

  이렇게 볼 수 있어요

  테스트 도구로 Kotest와 JUnit을 함께 쓰는 팀이라 Kotlin과 Java 코드가 같이 있는 환경입니다. 헥사고날 아키텍처로 도메인 로직이 특정 프레임워크에 종속되지 않게 한다고 적었으므로, Spring 기능을 쓴 경험보다 도메인 계층을 어떻게 나눴는지를 설명할 수 있게 준비하는 편이 이 팀의 구조와 맞습니다.

• RDBMS 기반의 데이터 모델링과 성능 최적화 경험이 필요합니다.

  이렇게 볼 수 있어요

  주문·체결 테이블은 하루 안에 행이 크게 늘고 장중에는 쓰기와 조회가 함께 몰립니다. 스택에 PostgreSQL과 Oracle이 함께 있으므로, 쓰기가 몰리는 테이블에서 인덱스·파티셔닝·잠금 경합을 어떻게 다뤘는지 DB 종류와 함께 밝히면 이 환경과의 연결이 분명합니다.

• 대량 트랜잭션 처리와 서비스 성능 개선 경험이 필요합니다.

  이렇게 볼 수 있어요

  국내 주식은 가격이 같으면 먼저 접수된 주문이 먼저 체결되는 가격·시간 우선 원칙으로 매매되므로, 회사 시스템 안에서 생긴 지연이 고객 주문의 체결 순서를 뒤로 미룰 수 있습니다. 그래서 주문 경로에서는 처리량만큼 지연이 중요합니다. 고객이 주문을 낸 뒤 거래소 접수까지 걸린 시간을 p99 같은 지표로 줄여 본 경험이 있다면 줄이기 전후의 숫자가 이 요건의 근거가 됩니다.

• 테스트 코드를 기반으로 안정적인 서비스를 개발해 봤어야 합니다.

  이렇게 볼 수 있어요

  주문 로직은 세션, 주문 유형, 정정·취소의 조합이 많아 경우의 수가 빠르게 늘어납니다. 팀이 높은 테스트 커버리지와 JaCoCo를 적었지만, 커버리지 숫자보다 세션 경계나 부분 체결처럼 재현하기 어려운 상황을 테스트로 어떻게 만들었는지가 이 요건에서 설명할 핵심입니다.

• 안정적인 운영을 위한 모니터링, 장애 원인 분석, 무중단 배포 경험이 필요합니다.

  이렇게 볼 수 있어요

  공고 본문의 이미지 문단은 실제 거래와 고객의 자산이 오가는 시스템인 만큼 작은 문제도 가볍게 넘기지 않는 태도가 중요하다고 강조합니다. 주문이 거래소에 접수됐는지 알 수 없는 상태를 겪어 봤다면 무엇으로 상태를 확인하고 어떻게 복구했는지를 장애 사례로 정리하는 게 좋습니다.

3우대 사항

• 거래·결제·원장처럼 데이터 정합성과 신뢰성이 중요한 시스템을 설계·운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  공고가 예로 든 셋은 모두 하루 끝에 외부 기록과 맞춰 보는 시스템입니다. 금융이 아니어도 PG 결제나 포인트 원장처럼 외부 정산 데이터와 대사를 해 본 시스템이면 같은 성격이고, 차이가 났을 때 어느 쪽 기록을 기준으로 바로잡았는지가 이 우대에서 묻는 부분입니다.

• 금융 도메인 또는 미션 크리티컬한 서비스를 개발한 경험을 우대합니다.

  이렇게 볼 수 있어요

  넥스트증권은 파생상품 위탁매매와 기업금융 같은 B2B 사업을 중심으로 성장했고 지금은 개인 고객용 B2C 사업을 준비하고 있습니다. 이 팀은 개인 투자자의 국내 주식 주문을 받는 시스템을 정식 오픈 전에 만들고 있습니다. 두 경험이 '또는'으로 묶여 있어 장애가 곧 금전 손실로 이어지는 비금융 서비스 경험도 이 우대와 관련이 있습니다. 증권 주문 시스템을 다뤄 봤다면 국내·해외·파생 가운데 어느 시장의 주문이었는지를 밝혀야 KRX 연동 업무와 얼마나 가까운지 보입니다.

• Kafka, Redis 등을 활용한 분산·이벤트 기반 아키텍처와 헥사고날·클린 아키텍처처럼 확장성과 유지보수성을 고려한 구조를 설계·운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  테크본부장 인터뷰는 회사가 Microservice, Event-driven, Clean Architecture를 도입하고 있다고 소개했습니다. 체결 이벤트를 잔고·알림·결제처럼 여러 소비자에게 보내는 구조에서 이벤트 유실 때 재처리와 멱등 처리를 설계했고, 헥사고날 구조에서 거래소 연동을 어댑터로 분리해 본 경험도 있다면 이 우대의 두 항목이 한 사례로 묶입니다.

• AWS 기반 클라우드 인프라 운영 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 DevOps Engineer 공고는 채널계·계정계·대외계별로 분리된 다중 EKS 클러스터를 운영한다고 적었습니다. 주문 시스템은 계정계와 거래소 연동을 맡는 대외계에 걸쳐 있으므로, 서로 다른 클러스터나 네트워크 경계를 넘는 호출을 운영해 봤다면 지연과 장애 격리를 어떻게 다뤘는지 말할 수 있습니다.

• CI/CD, 테스트 자동화, 운영 자동화 환경을 구축한 경험을 우대합니다.

  이렇게 볼 수 있어요

  팀은 일관된 브랜치 전략과 PR 리뷰 정책, 단계적 배포를 적었고 스택에 ArgoCD와 Terraform이 있습니다. 거래소 모의 환경이나 주문 시뮬레이터를 파이프라인에 붙여 주문 흐름을 자동으로 검증해 본 경험이 있으면 검증한 시나리오 수와 그 검증으로 막은 결함이 이 우대를 숫자로 보여 줍니다.

• 실시간 서비스의 모니터링과 장애 원인 분석·대응 경험을 우대합니다.

  이렇게 볼 수 있어요

  국내 증시는 오전 8시 30분부터 동시호가 주문을 받아 9시에 시가를 한꺼번에 체결하므로, 주문과 체결 통보가 가장 몰리는 시각이 매일 같습니다. 주문 장애는 장중에 바로 고객 손실로 이어질 수 있어, 이런 시각에 맞춰 미리 증설하거나 알림 기준을 시간대별로 다르게 잡아 본 경험이 있으면 탐지부터 복구까지 걸린 시간과 함께 이 우대의 사례가 됩니다.

4기타 사항

• 게시일 : 2026년 9월 15일
• 고용형태 : 정규직
• 근무지 : 서울특별시 영등포구 국제금융로 10 THREE IFC 12층/15층
• 경력 조건 : 경력 5년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• Kotlin
• Java
• Spring Boot
• AWS
• Kubernetes(EKS)
• Kafka
• Redis
• Docker
• ArgoCD
• Terraform
• Grafana
• PostgreSQL
• Oracle
• Kotest
• JUnit
• JaCoCo

전형과 지원

채용 사이트 How We Hire가 밝힌 기본 절차는 서류 접수, 1차 인터뷰, 2차 인터뷰, 처우 협의, 최종 합격의 다섯 단계입니다. 개발·디자인 공고 상당수는 1차 인터뷰 앞에 AI 스크리닝을 더하므로 공고마다 전형 문단을 확인해야 합니다.

지원 전 준비할 것

1. 1

   주문 상태 전이도 그리기

   접수·정정·취소·부분 체결·전량 체결이 섞일 때 주문과 잔고가 어떻게 바뀌는지 그려 보면 1차 인터뷰의 설계 질문에 바로 쓸 수 있습니다.

2. 2

   시간 경계 사례 고르기

   배치 마감, 영업일 전환, 운영 시간 경계처럼 시간대가 바뀌는 순간에 생긴 버그나 설계 사례를 하나 골라 원인과 해결을 정리합니다.

3. 3

   피크 트래픽 수치 꺼내기

   트래픽이 가장 몰렸던 순간의 초당 요청 수와 지연, 그때 병목이 생긴 지점을 숫자로 정리합니다.