토스 러너스하이 서버 1기 백엔드 과정 후기

토스 러너스 하이란?

토스 러너스 하이는 개발 실무 경력이 있는 서버 개발자를 위한 프로그램입니다. 2024년 12월 16일부터 2025년 1월 16일까지 약 한 달간 진행된 교육에 참여할 수 있었습니다. 아 참고로 이번이 처음으로 시행하는 서버 1기였습니다 ㅎㅎ 2025년부터는 추가 기수를 모집할 예정이라고 하니, 1기 모집과정이 궁금하신 분들은 모집요강 을 확인해 보시면 좋을 것 같습니다.

 

 

러너스하이해또 모집!!

저는 글또 커뮤니티에서 활동하고 있는데, 우연찮게도~? 글또의 백엔드 개발자분들 중에서도 토스 러너스 하이에 참여하시는 분들이 계셨습니다. 글또에서는 총 23분이 참여하신걸 확인했습니다. 저는 바로 노션 팀 페이지를 만들고 함께 달릴분들을 모집했고 결과적으로는 9분과 함께 서로의 작업물을 공유하며 한 달간 열심히 달렸습니다.(개인정보 부분은 모자이크 처리..)

 

한 달간의 여정 시작!

토스 러너스하이에 참여하며 처음 고민했던 것은 팀과 회사에 어떤 이득을 가져다줄 것인가? 였습니다. 우리에게 남겨진 기술 부채나 고질적인 문제는 무엇일까? 부터 고민해볼 수 있었습니다.

 

러너스하이 교육은 자율적으로 진행되었기 때문에, 각자 회사에서 자율적으로 어떤 결과물을 만들지 정한 뒤 열심히 달려야 했습니다!! 하지만 아무래도 연말이다 보니 본업무들이 바빠서 아쉽게 목표했던 결과물을 수행하지 못하시는 분들도 있어 안타까웠습니다...

 

필자는 아래와 같은 방식으로 계획했던 목표를 달성할 수 있었습니다.

 

 

 

해결한 과제들

결과적으로 저는 무중단 배포, DLQ 적용, 그리고 SAGA 패턴 도입을 진행했습니다. 이를 통해 서비스 안정성과 장애 대응 능력을 강화하는 데 기여할 수 있었습니다.

 

다만 ELK 로깅 고도화와 카테고리 코어 이슈 분석은 시간이 부족해 깊게 다루지 못한 점이 아쉬웠습니다. 또한, 사내에서 외부 솔루션 및 조직도 연동과 같은 중요한 작업이 있었기에 일정 조율이 쉽지 않기도 했습니다.

 

추가적으로 엘라스틱서치 검색 엔진 최적화 및 동의어 처리 작업도 수행했지만 메인 담당자는 따로 있었기에 개인적으로 만족스러울 만큼 기여하지는 못했다고 느꼈습니다.

 

하지만 앞선 과정을 통해 정해진 기간내에 목표를 지속적으로 상기시키며 다양한 도전과 결과물을 만들 수 있었습니다.

 

과정 종료

드디어 1월 16일이라는 공식적인 종료일이 왔습니다!! 하지만 여기서 끝이 아니라 1월 31일까지 토스 러너스하이 경험을 기반으로 경력 기술서를 제출하면 다음과 같은 혜택이 주어졌습니다.

• 혜택 1: 토스 Server Developer로의 채용 기회 부여 (직무 인터뷰)
• 혜택 2: 멘토와의 캐주얼챗 제안
• 혜택 3: 토스커뮤니티 채용 포지션 추천

다만 경력 기술서를 제출하지 않아도 불이익은 없습니다.

 

배운 점 "왜"와 "어떻게"가 중요한 이유

토스 러너스하이를 통해 개발자란 호기심이 많아야 하며 개발에서 "왜"와 "어떻게"가 얼마나 중요한지를 다시 한번 느꼈습니다.

• 왜 해당 기술을 적용해야 하는가?
• 왜 이 방법을 선택했는가?
• 왜 문제가 발생했는가?
• 어떻게 해결할 것인가?
• 어떻게 성장할 것인가?

앞선 질문을 끊임없이 던지며 고민하는 것이 잘하는 개발자로 성장하는 길이라고 느꼈습니다.

 

개발자는 "결과"를 만들어내는 사람

백엔드 개발자 3년 차에 접어들면서 개발자는 과정보다 "결과"를 만들어내는 것이 중요하다고 느끼고 있습니다.

토스러너스하이에서 배운 것 처럼 깊이 고민하는 것도 중요하지만, 일단 부딪히고 행동하는 것이 더 큰 의미를 가질 때도 있다는 걸 이번 경험을 통해 배웠습니다.

 

토스 러너스하이를 통해 한 달 동안 의미 있는 시간을 보낼 수 있었습니다. 팀이나 회사에서 내가 기여할 수 있는 게 무엇이 있을까?? 와 같이 좀 더 주도적으로 업무를 깊게 생각하며 진행하다 보니 팀원들을 넘어서 결국에는 팀 전체의 생산성에 도움을 줄 수 있는 업무를 수행할 수 있었던 것 같습니다.

추후 동일한 과정이 진행된다면, 더욱 발전한 모습으로 다시 참여하고 싶다는 생각을 했습니다. 앞으로도 주어진 환경에서 최대한으로 성장하면서 팀에게 조직에게 도움이 되는 방향은 어떤 것일까?라는 고민을 해볼 수 있을 것 같았습니다

 

 

러너스하이 기간 동안 수행한 업무를 정리했습니다. 깊게 다루지 못한 내용이나 기여를 많이 못했다고 느꼈던 부분은 아쉽지만 과감히 제외시켰습니다.

DLQ 적용 및 이벤트 신뢰성 강화

문제 상황

• 이벤트 실패 시 자동으로 복구 프로세스 부재로 데이터 정합성 문제 발생
• 수동 이벤트 재처리(isPublish 컬럼 활용)로 인한 운영 부담 증가

주요 개선 사항

• DLQ 기반 자동 복구 시스템 구축
  • 이벤트 실패 시 자동으로 DLQ로 이동 및 복구 프로세스 작동
  • 일시적 장애에 대한 즉시 재시도 로직 구현
• 실시간 모니터링 체계 구축
  • Grafana와 Slack 연동으로 장애 실시간 감지
  • 운영팀 즉시 대응 가능한 알림 시스템 구현

선택 이유

• DLQ 기반 복구 기능을 도입하여 서비스 신뢰도를 높이고 운영 부담을 줄이기 위해서
• 즉시 재시도 로직을 통해 일시적인 장애로 인한 이벤트 실패 최소화
• 실시간 알림 시스템을 통해 장애를 빠르게 감지하고 대응

성과 및 결과

• 수동 재처리를 제거하여 운영 부담 감소 및 이벤트 신뢰성 강화
• 실시간 장애 알림 연동을 통해 빠른 대처로 인한 고객 신뢰도 향상

향후 개선 방향

• DLQ 모니터링 강화를 통해 실시간 모니터링 및 장애 조기 감지를 목표로 할 예정입니다.
• 지수 백오프를 적용하여 재시도 로직을 최적화할 예정입니다.

---

쿠버네티스 무중단 배포 체계 구축

문제 상황

• RollingUpdate 배포 방식을 적용하고 있었으나 서버의 크기가 커지면서 파드 재구동 시간이 길어져 서버 다운타임이 발생했고 서비스가 불안정해졌습니다.
• 배포 시간을 공지하는 방법을 사용했으나 이로 인해 운영에 대한 부담이 증가하고 있었습니다.

주요 개선 사항

• HealthCheck 도입
  • livenessProbe, readinessProbe 설정으로 무중단 배포 구현
  • 배포 중 트래픽 안정적 처리
• 모니터링 시스템 구축
  • Prometheus를 통한 리소스 모니터링 (CPU, 메모리, 트래픽)
  • Grafana와 Slack 연동으로 실시간 알림 체계 구축

선택 이유

• 무중단 배포를 실현하면서 기존 배포 전략을 유지하기 위해 HealthCheck 방식을 선택
• Grafana & Slack 연동을 통해 장애 발생 시 즉각적인 대응이 가능하도록 구성

성과 및 결과

• 무중단 배포 구축 완료
• 자동화된 장애 감지 및 대응 체계 구축을 통한 신속한 장애 대응

향후 개선 방향

• 헬스체크 로그 필터링을 통해 가독성을 개선할 예정입니다.
• 서비스별 맞춤형 모니터링 대시보드를 추가적으로 구축하여 운영 효율성을 높일 계획입니다.

---

SAGA 패턴을 통한 분산 트랜잭션 관리

문제 상황

• 결제/재고 차감 등 이벤트 실패 시 데이터 정합성 문제 발생.
• 분산된 도메인으로 인한 장애 원인 파악 지연

주요 개선 사항

• Choreography 패턴 적용
  • 각 도메인별 독립적 트랜잭션 처리
  • 보상 트랜잭션으로 실패 시 자동 롤백
• 보상 트랜잭션 적용
  • 결제 실패, 재고 차감 오류 등의 실패한 트랜잭션에 대해 롤백을 수행할 수 있도록 했습니다.
• 데이터 일관성 보장
  • Kafka 멱등성 설정으로 중복 처리 방지
  • 이벤트 기반 트랜잭션 처리 자동화

선택 이유

• 도메인별로 event consumer가 존재하는 현 상황에서 각 서비스가 독립적으로 동작하면서도 트랜잭션을 관리할 수 있는 방법은 Choreography 패턴이라고 생각했습니다.
• 보상 트랜잭션과 멱등성 적용을 통해 데이터 정합성을 유지하고, 장애 발생 시에도 안정적인 시스템 운영이 가능하도록 했습니다.

성과 및 결과

• 트랜잭션 일관성 유지 및 장애 복구 가능으로 시스템의 안정성을 크게 향상시켰습니다.
• 서비스 간 느슨한 결합을 통해 유연한 트랜잭션 관리가 가능해졌습니다.
• 장애 대응력 강화로 시스템의 복원력을 높였습니다.

향후 개선 방향

• 도메인별 최적화된 보상 트랜잭션과 에러 핸들링 전략을 구축할 예정입니다.
• 멱등성 키를 활용하여 중복 메시지 처리를 더욱 정교하게 관리할 계획입니다.