프로젝트를 고민하며

프로젝트에서 무슨 경험을 해보고 싶냐면...

최근 프로젝트 이야기를 하다가 “백엔드 개발자로서 이번 프로젝트에서 어떤 부분을 경험해보고 싶냐”는 질문을 받았다. 바로 대답하기 어려웠다. Spring Boot를 사용해보고 싶다거나 Redis를 적용해보고 싶다거나... 기술 이름을 나열 할 순 있었겠지만 프로젝트에서 내가 정말 경험해 보고 싶은 부분이냐, 하면 그렇지 않은 것 같았다. 어떤 문제를 해결해보고 싶냐고? 새로운 문제요.

새로운 문제가 뭔데?

음

ㅎㅎ?

정말 모르겠습니다.

아직 백엔드 프로젝트 경험이 많지 않아서 그런 것 같다. 데이터베이스도 더 깊게 다뤄보고 싶고, 캐시나 비동기 처리도 궁금하다. 직접 서버를 배포하고 로그를 보면서 문제를 찾는 과정도 경험해보고 싶다. 해본 것이 많지 않다 보니 오히려 뭘 해봐도 재미있을 것 같았고, 그래서 하나를 고르기가 더 어려웠다.

이런 고민을 이야기하다가 두 가지 조언을 들었다. 아직 뭘 좋아하는지 모르겠다면 채용공고를 보면서 기업이 백엔드 개발자에게 어떤 기술과 경험을 원하는지 살펴보는 것도 좋다는 것이었다. 또 하나는 막상 프로젝트가 끝난 뒤 기술적으로 무엇을 경험했는지 떠올려보려면 생각보다 어렵다는 이야기였다. (조언 감사합니다)

그래서 살펴본 채용 공고

메가스터디교육 백엔드 개발 공고

• MySQL 스키마 설계, 쿼리 최적화 및 인덱스 관리
• AWS 클라우드 환경에서 서비스 운영

단순히 API를 구현한 경험만이 아니라 데이터 구조를 직접 설계하고, 느린 쿼리를 개선하고, 완성한 서비스를 실제 환경에서 운영한 경험을 요구하고 있었다.

이너버스 백엔드 개발자 공고

• Core Java & Framework
  ㆍJava 8+ 실무 경험 필수 (주 개발 언어)
  - 람다, 스트림, CompletableFuture 등 비동기 처리
  - 멀티스레딩, 동시성 제어 및 성능 최적화
  - JVM 튜닝 및 메모리 관리
  ㆍMaven/Gradle 빌드 도구 활용
• 대용량 데이터 처리
  ㆍElasticsearch 실무 경험 (인덱스 설계, 쿼리 최적화, 집계 쿼리)
  ㆍ대용량 로그 수집/저장/검색 시스템 개발 경험
  ㆍ실시간 데이터 파이프라인 구축 경험
  ㆍ배치 처리 및 스트림 처리 아키텍처 설계
  ㆍ효율적인 로그 파싱 및 정규화 로직 구현
• 분산 시스템 & 메시징
  ㆍApache Kafka 또는 유사 메시징 시스템 실무 경험
  ㆍ분산 환경에서의 데이터 일관성 및 트랜잭션 처리
  ㆍ마이크로서비스 아키텍처 설계 및 구현
  ㆍDocker/Kubernetes 기반 컨테이너 환경 경험
  ㆍ서비스 간 통신 패턴 (REST, gRPC, 메시지 큐 등)
• 데이터베이스
  ㆍRDBMS (PostgreSQL, MySQL 등) 설계 및 쿼리 최적화
  ㆍNoSQL (Redis, MongoDB 등) 캐싱 및 세션 관리
  ㆍ시계열 데이터베이스 경험 우대 (InfluxDB, TimescaleDB 등)
  ㆍ대용량 데이터 파티셔닝, 샤딩, 인덱싱 전략

다른 공고에 비해 필수 기술 역량이 자세히 적혀있어 전부 가져와 봤다.

다이렉트클라우드 채용공고

・PHP 또는 Golang을 이용한 백엔드 개발 경험
・웹 서비스의 구조를 이해하고 개발해본 경험
・대용량 트래픽 경험
・서버리스 및 마이크로 아키텍쳐에 대한 이해・PHP 또는 Golang을 이용한 백엔드 개발 경험

서버를 개발하는 것과 함께 배포된 서비스를 운영하고, 운영 중 발생하는 문제의 원인을 찾는 경험을 중요하게 보고 있었다.



이렇게 공고를 살펴봤는데, 모든 공고가 Kafka나 Elasticsearch 같은 기술을 공통으로 요구하는 것은 아니었다. 이너버스 공고는 대용량 로그를 다루는 서비스의 특성상 데이터 처리와 분산 시스템에 관한 요구가 특히 자세한 편이었다.

그럼에도 여러 공고에서 비슷하게 확인할 수 있었던 것은 다음과 같았다.

• 필요한 데이터를 고려해 DB 구조를 설계해본 경험
• 느린 쿼리와 인덱스를 분석해 성능을 개선해본 경험
• 많은 요청이나 데이터를 처리하면서 병목을 찾아본 경험
• 서버를 배포하는 것에서 끝내지 않고 실제로 운영해본 경험
• 오류나 장애가 발생했을 때 원인을 확인하고 해결해본 경험
• 캐시, 비동기 처리, 메시지 큐 등을 문제에 맞게 선택해본 경험

Kafka, Elasticsearch, Kubernetes처럼 특정 공고에서 요구하는 기술도 있었지만, 결국 공통적으로 보고 있는 것은 기술 이름보다 그 기술을 이용해 어떤 문제를 해결해봤는지에 가까워 보였다.

그리고 이너버스 공고를 보면서는 또 다른 궁금증이 생겼다.

저 많은 걸 백엔드 개발자 한 명이 다 할 줄 알아야 할까?

찾아보니 회사와 팀의 규모에 따라 달랐다. 작은 팀에서는 한 명의 백엔드 개발자가 API 개발부터 DB 설계, 배포와 운영까지 넓게 담당하기도 한다. 반대로 규모가 큰 회사에서는 데이터 엔지니어, 검색 엔지니어, 인프라 엔지니어, SRE처럼 역할이 나뉘기도 한다.

Kafka 클러스터는 인프라팀에서 운영하고 백엔드 개발자는 메시지를 보내고 처리하는 로직을 만들 수도 있다. Kubernetes 환경은 플랫폼팀에서 관리하지만, 백엔드 개발자가 자신의 서버에 필요한 설정과 상태 확인 방법을 정할 수도 있다.

그러니까 공고에 적힌 기술을 한 사람이 전부 같은 깊이로 다뤄야 한다기보다는, 자신의 영역은 깊게 이해하고 주변 영역의 개발자와 함께 문제를 해결할 수 있어야 한다는 뜻에 가까웠다. 물론 정말로 한 명이 다 하는 회사도 있을 것이다..

그래서 나는 무슨 경험을 해보고 싶은가

공고를 살펴보고 나니 처음 질문에도 조금은 구체적으로 답할 수 있을 것 같았다. 아직 “나는 반드시 대용량 로그 처리 전문가가 될 거야!” 같은 목표가 생긴 것은 아니다. 여전히 안 해본 것이 많고, 그래서 이것저것 해보고 싶다.

그래도 단순히 서버를 한 번 만들어보는 것에서 끝내고 싶지는 않다. 오늘 글의 결론은 크게 두 가지 이다.

1. 정상 동작보다 장애 상황을 한 번 만들어보고 싶다.

정해진 순서대로 요청을 보내고 예상한 응답을 받는 것만으로는 알 수 없는 문제가 많을 것 같다. 외부 API가 늦게 응답하거나, DB 연결이 끊기거나, 같은 데이터를 여러 사용자가 동시에 수정하는 상황을 직접 만들어보고 싶다.

• 외부 API 응답을 일부러 늦추거나 실패시키기
• DB 연결이 끊어진 상황 만들어보기
• 같은 데이터에 동시에 수정 요청 보내기
• 서버가 처리할 수 있는 양보다 많은 요청 보내기
• 작업을 처리하던 서버를 중간에 종료해보기

그다음 timeout이나 retry를 적용하고, 트랜잭션과 락을 사용하면서 결과가 어떻게 달라지는지 확인해보고 싶다. 장애가 한 번도 나지 않는 서버를 만들겠다는 것보다 장애가 났을 때 원인을 찾을 수 있는 서버를 만들어보고 싶다.

2. 성능 개선을 숫자로 확인해보고 싶다.

“Redis를 사용해서 빨라졌다”, “인덱스를 추가해서 성능을 개선했다”라고만 적으면 정말로 얼마나 좋아졌는지 알 수 없다. 개선 전후를 직접 측정하고 비교해보고 싶다.

• 데이터가 1만 건일 때와 100만 건일 때의 조회 시간
• 인덱스를 적용하기 전후의 응답 시간
• 캐시를 적용하기 전후의 DB 조회 횟수
• 동시에 여러 요청이 들어왔을 때의 처리량과 오류율
• N+1 문제를 해결하기 전후의 쿼리 실행 횟수

조회 API의 평균 응답 시간이 어떤 식으로 변했는지, 초당 처리 가능한 요청 수가 얼마나 늘었는지, 요청 한 번 당 실행되는 쿼리의 수를 줄일 수 있을지를 숫자로 체크하고 싶다.

결론

아직 백엔드 경험이 많지 않아서 어떤 분야가 가장 재미있는지는 잘 모르겠다. 오히려 지금은 안 해본 것이 많아서 무엇을 해도 재미있을 것 같다.

그래도 이번 프로젝트에서 해보고 싶은 경험은 이전보다 조금 구체적으로 정리할 수 있게 됐다.

• 정상 동작뿐 아니라 장애 상황도 직접 만들어보기
• 성능 개선 결과를 숫자로 확인하기

또 어떤 기술을 사용할지 먼저 선택하기보단 문제를 먼저 확인하고 필요한 기술을 선택하고 싶다. 먼저 기술을 정해놓고 프로젝트를 진행하면 사용한 기술은 많아질 수 있겠지만 왜 사용했는지를 설명할 수 없다. 프로젝트가 끝난 뒤 Spring Boot와 Redis를 사용했습니다라고만 말하고 싶지는 않다. 어떤 문제가 있었고, 왜 그런 방법을 선택했으며, 적용한 뒤 무엇이 달라졌는지를 설명할 수 있었으면 좋겠다.

프로젝트 기대된당!!