항해 플러스 백엔드 - 마무리 회고

길고도 짧았던 10주 간의 항플 백엔드 7기를 마무리 했다. 시원 섭섭함이 공존했던 과정 회고를 짧게나마 정리하려고 한다.

 

 

GitHub - pbg0205/concert

 

🍿 prequel

#1 항해를 신청한 이유

 바이오 공학을 전공한 후 사회인 신분으로 개발을 처음 접하게 되었다. 영상 회의 서비스 백엔드 개발을 담당했고 다시 백엔드 개발자로 일하기 위해 항해 플러스 7기를 신청했다. 현재 내가 부족한 부분을 키워드로 고민해보았을 때 설득력과 방향성이었다. 내가 알고 있는 것을 잘 전달할 수 있을지, 어떻게 해야 지속적으로 성장이 가능할 수 있는지에 관한 고민이 있었다.

 

#2 개발 상태 health check

개발 유튜브에서 한 개발자 분의 몰입의 중요성에 관한 이야기를 듣고 인상을 받았다. 100개의 Level 1 캐릭터는 하나의 Level 100 캐릭터와 같을 수 없다. 깊이 있는 몰입이 얼마나 중요한지에 관한 이야기였다. 여러 시도하면서 ‘다양한 경험을 쌓고 있다’고 생각했지만, 깊이가 얕은 경험을 쌓아 올리고 있다는 느낌이 들었다. 내가 지금까지 고민해온 것들이 정말 깊이 있는 고민이었는지 되돌아보며 이번 과정을 통해 깊이 있는 고민과 몰입을 하고 싶었다.

 

🚢 설득력있는 개발자가 되기 위한 노력

#1 모니터링 시스템 구축

 서버 상태를 모니터링하기 위해 서비스 메트릭 기반의 모니터링 시스템을 구축했다. 컨테이너 환경에서 각 컴포넌트에 알맞는 Exporter를 지원한다. 이를 구성해 메트릭을 수집하고, Prometheus 에서 관리했다. 메트릭을 시각화하기 위한 툴로는 Grafana를 사용했다.

 

server monitoring architecture

mysql exporter

 

 

 모니터링 시스템 구축은 여러 장점이 있었다.

 

1. 명확한 원인 파악이 가능하다. 

 

 일반적인 서비스는 DB, MQ 와 같이 다양한 컴포넌트와 협력하며 동작한다. 비즈니스 로직적인 문제는 테스트 코드를 통해서 보완할 수 있지만 부하, 네트워크 오류와 같은 문제로 인해 다른 컴포넌트가 비정상적으로 동작해 인해 장애가 발생할 수 있다. 이를 모니터링 시스템을 통해 점검하고 원인에 관해 명확하게 정의하여 안정적인 서비스의 유지보수에 기여할 수 있을 것이라는 생각이 들었다.

 

 

2. 객관적 수치를 기반해서 개선할 수 있다.

 

 문제 해결과 성능 개선을 위해서는 객관적인 수치가 필요하다. 명확한 측정이 비롯되어야 문제 해결을 할 수 있기 때문이다.

모니터링 시스템의 통해 객관적인 수치로 개선했던 내용이 캐시 보고서와 인덱스 개선 보고서 였다. 이번 보고서에 수치를 기반한 데이터를 첨부하여 개선 여부에 관한 명확한 근거를 제시할 수 있는 장점이 있었고, 이를 통해 동료들과 논의할 때도 유용한 자료로 쓰일 수 있어 소통이 더욱 원할했다.

• 캐시 보고서
• 인덱스 개선 보고서

캐시 보고서 예시

 

#2 문서 작성

 항해를 시작하기 전까지 문서, 보고서 작성 능력이 많이 부족했다. 글을 썼다 지웠다는 반복하기 일수였고, 그러다보니 작성이 진척이 없었다. 하지만 항플에는 문서 도사인 동료들이 정말 많았다. 동료들의 문서를 분석하면서 좋은 문서가 갖춰야 할 요소를 파악했고, 반복과 수정을 반복하며 핵심을 간결하게 전달하는 데 집중하며 문서 작성 능력을 기를 수 있었다.

 

 그리고 항플을 하다보면 정말 많은 문서를 작성했다. 주차별로 설계, 개선, 기술 검토 보고서들을 작성하면서 해당 보고서에 필요한 요소들을 파악하고 작성해볼 수 있었다. 부족한 작성 능력을 보완하기 위해 수정을 반복하며 동료분들에게 돌리면서 피드백을 받으며 노력했다. 그래도 몇몇 분들이 보고서 잘 보았다는 말씀해주시면서 항플에서 개선해보고 싶었던 부분에 긍정적인 피드백을 받아 뿌듯했다.

• 동시성 제어 보고서
• HikariCP Pool 개선 보고서
• 시나리오 테스트 보고서
• 장애 대응 보고서

HikariCP 보고서

 

🍿 항해 후기

#1 몰입한 만큼 얻어간다. 

 이미 알고 있었지만 직접 겪어보니 더욱 난이도가 과정이었다. 학습할 기술들, 코드를 작성한 이유에 관해 명확한 근거를 제시하기 위해 몰입할 시간이 충분히 필요했다. 하루 최소 4-5시간은 레퍼런스를 찾아보거나 코드 작성하는데 자리에 앉아 있었다. 특히 4주차 발제에서는 밤을 새는 주간도 있었다. 

[발제 주제들] 클린 아키텍처 +동시성 제어 + 레디스 + 인덱스 + 카프카 + 기타 등등

 

10주는 비록 힘들었지만 포기하지 않고 ALL PASS 를 받을 수 있어 개인적으로는 의미있는 10주였다.

ALL PASS

 

#2 완주까지 이끌어 주신 귀인들

항해를 시작하면서 코치님, 학습 메이트님, 팀원 덕분에 쉽지 않은 10주를 완주할 수 있었다.

밤낮 가리지 않고 노력해주신 귀인들을 뵙게 되어 정말 영광이었다. 🙇‍♂️

항플 백엔드 8팀 귀인들(貴人)

 

👏 마무리하며

 과제가 나올 때마다 처음에는 막막했다. 해결 방법이 바로 떠오르지 않는 경우도 많았고, 때로는 몇 시간 동안 고민해도 답을 찾지 못하는 경우도 있었다. 하지만 문제를 쪼개고, 공식 문서를 참고하고, 동료들과 의견을 나누면서 조금씩 해결해 나갈 수 있었다. ‘완벽보다는 끝까지 해보자’는 마인드가 완주의 원동력이 되었다. 문제를 바라보는 방식도 달라졌고, 같은 개념을 더 깊이 이해하는 노력을 할 수 있었다. 끈기가 실력을 만든다는 마음으로 끝까지 해내면 결국 성장한다는 마음으로 쉽게 포기하지 않고 나아가는 개발자가 되고 싶다.

 

저와 비슷한 고민으로 항해 플러스 과정을 고민하고 있다면 아래 링크로 말씀주시면 답변드리겠습니다.

• 오픈채팅 링크 : https://open.kakao.com/o/sL5FSmjh
• 할인 코드 : yk1bVN

 

 

🪜 PR - 기록용

• [step5] 프로젝트 설계
• [step6] ERD & Mock API 작성
• [step7 & step8] 서버 구축
• [step9] HTTP Message 로깅 필터 적용
• [step10] 동시성 통합 테스트 작성
• [step11 & step12] 동시성 제어 보고서
• [step13] 캐싱 검토 보고서
• [step14] Redis 기반 대기열
• [step15 & step16] 인덱스 검토 보고서 작성
• [step17 & step18] 카프카 적용 (DLT 적용)
• [step19&step20] 시나리오 테스트 진단 보고서 및 장애 대응 보고서 작성