[항해 플러스 백엔드] 마지막 회고

 

11월 30일, 가을의 마지막 토요일에 10주간의 여정이 끝을 맺었다.

토요일마다 발제 강의를 듣고 평일에는 발제 내용을 학습하는 게 일상이 되었는 데, 이제는 제출할 과제가 없어 어색하다.

매주 피곤하고 힘들어서 빨리 자유가 오길 바랐지만, 막상 끝나고 나니 허탈하기만 하다.

 

 

 

목표를 이루었는가?

처음 생각한 목표의 50%를 달성했다.

 

항해 플러스를 시작할 때, 10주 동안 이루어야 할 3가지 목표를 세웠다.

1. 모든 과제 제출하기
2. 매주 진행되는 발제 주제 정리하기
3. 코치분들의 개발 노하우 배우기

 

모든 과제 제출하기

매주 발제와 함께 과제가 제공되고, 과제 통과율에 따라 배지를 받는다는 안내를 받았을 때부터 블랙배지를 목표로 삼았다.

해당 주차의 교육내용을 완전히 이해해야 통과할 수 있다고 생각했기 때문에, 블랙배지는 10주 과정의 이해도를 보여주는 상징이라고 여겼다. 내심 모든 과제를 패스하고 블랙배지를 받길 희망했지만 아쉽게도 과제 1개를 통과하지 못해서 올패스에는 실패했다. 하지만 진행되었던 과제에 대한 이해도와 투자한 시간을 고려하면 좋은 결과를 얻었다고 생각하기 때문에 나 자신을 칭찬한다.

 

매주 진행되는 발제 주제 정리하기

안타깝게도 정리는 하지 못했다. 항플 시작 때 이 목표를 세웠다는 것조차 잊고 있었다. 이전에 국비지원 개발학습 프로그램에서 새로운 개념을 학습할 때마다 따로 정리했고, 그 작업이 큰 도움이 되어서 이 목표를 세웠었다. 하지만 항플을 진행하면서 발제내용을 따로 정리하는 게 생각보다 어려웠고, 새로운 개념을 이해하고 과제를 진행하기 위해 여러 블로그를 읽고 간추린 내용만 노션에 간단히 메모하는 정도로 끝났다. 매주 발제 주제를 개인 블로그에 포스팅하는 다른 동기들을 보면 아쉬움이 남는다.

 

코치분들의 개발 노하우 배우기

기대했던 만큼 멘토링 청강을 하지 못했다. 앞서 언급했듯이 항플에서는 매주 발제를 통해 특정 주제를 학습하고 이와 관련 과제를 제출해야 한다. 과제를 해결하기 위해 학습하고 고민하는 과정에서 생기는 궁금증은 멘토링 시스템과 DM을 통해 해결할 수 있다. 토요일 정규 세션이 끝나면 시니어 코치진 중 한 명과 평일에 1시간 동안 멘토링을 받을 수 있는데, 가장 큰 장점은 다른 조들의 멘토링도 청강할 수 있다는 점이다. 하지만 과제 진행에 급급해 주어진 멘토링 시간만 참여하고 다른 팀의 멘토링을 청강하지 못한 것이 아쉽다. 특히 항플의 초반부와 마지막 2 ~ 3주에는 다른 팀들의 멘토링을 많이 청강했기에 더욱 아쉬움이 남는다.

 

 

 

무엇을 얻었을까?

항플을 등록할 때의 기대보다 더 많은 것을 얻었다. 현재 직장에서 물경력만 쌓이는 것 같아 불안했지만, 항플에서는 코스내용보다 이력서 컨설팅에 더 큰 기대를 걸었었다. '대규모 트래픽' 외에는 평범한 내용을 다룰 것이란 예상과 달리, 모든 주차에서 백엔드 개발자가 갖춰야 할 핵심 기술들을 다뤘다.

 

 

TDD

TDD 방법론을 살펴보고 테스트 코드의 필요성을 학습할 수 있었다.

특히 요구사항 기반의 시나리오에 따라 단계적으로 테스트 코드를 작성하는 과정이 큰 도움이 되었다.

 

Architecture

프로그램의 아키텍처를 이해하는 기회가 되었다. 새로운 프로젝트 돌입 시 패키지를 어떻게 나누는 것이 좋을지만 생각했었다. 모놀리식 아키텍처의 프로젝트를 주로 프로그래밍 했지만 각 레이어간 어떻게 의존하고 의존의 방향성을 어떻게 잡아야할 지 고민해본 경험이 없었기 때문에 색다른 경험이 되었다.

 

문서작업 - 시나리오 분석 및 설계

프로젝트를 설계할 때 어떤 문서들이 필요한지 배울 수 있었다. 현재 다니는 회사에서는 문서작업 없이 개발을 진행하기 때문에 설계시 사용하는 문서를 생각하면 단순히 ERD를 떠올렸었다. 시나리오 분석 및 설계를 위한 문서 작업을 하면서 시퀀스 다이어그램 등을 작성하였고 문서 작업의 필요성을 확인하게 되었다.

 

프로그래밍도 건축처럼 하나의 구조물을 만드는 작업이다. 건축 작업을 시작할 때 설계도를 활용해서 건물의 구조와 건축과정을 미리 계획한다. 이 설계도 덕분에 공사에 참여하는 건설사와 작업팀은 계획한 의도대로 작업할 수 있다. 프로그래밍도 이와 같다. 설계문서는 함께 작업하는 다른 개발자의 프로젝트 이해도를 높히며 미래에 유지보수가 필요할 때 설계문서를 참고하면 좀 더 빠르게 작업할 수 있다. 설계문서는 해당 프로젝트의 구조와 핵심을 보여주며 개발 작업의 '이정표'가 된다.

 

DB Lock

DB 트랜잭션의 주요 특징인 ACID에서 격리성(Isolation)을 학습할 때, Lock에 대해서는 신경을 쓰지않았었다. 격리수준에 따라 발생가능한 문제를 확인하고 이를 방지하기위해 어떤 방법들을 사용할 수 있는지 DB Lock과 관련하여 학습하면서 큰 도움이 되었다.

 

Redis

말로만 들었던 레디스를 활용해서 분산락과 대기열을 구현해보았다. 제공되는 API가 잘 정리되어 있고 관련 사용법을 구글링 및 AI로 쉽게 찾아 볼 수 있어서 구현 자체는 문제가 안되었지만, Redis의 근본적 기능 및 동작 원리에 대해서는 이해가 부족함을 느꼈다.

 

성능 개선 - 캐싱과 DB Index

실제 업무에서 캐싱을 사용하지 않기 때문에 캐싱과 DB Index의 연관성을 생각해본적이 없다. 물론 지금도 이 둘은 연관성이 없다고 생각한다. 하지만 Application의 '성능개선' 측면에서 이 둘을 함께 떠올릴 수 있다. 

 

캐싱이 임시방편이라면 DB Index는 근본적인 해결책이다. 운영중인 서비스에서 코드 오류와 같은 프로그래밍적 예외를 제외하고 발생가능한 문제가 무엇일까? 여러 문제들이 존재하지만 '슬로우 쿼리'가 가장 대표적인 문제라 할 수 있다. 이 문제를 해결하기 위해 쿼리 최적화를 통해 성능을 개선하여 근본적인 원인을 해결할 수 있지만 변동이 적은 데이터라면 캐싱을 통해 임시방편으로 해결할 수 도 있다. 물론 이 예시는 굉장히 단순화한 케이스를 나타내지만 둘을 연관지어 생각해보는 기회를 제공한다.

 

MSA(서비스 확장과 Application Event), Kafka and Outbox Pattern, 장애 대응과 대비(K6 and Grafana)

기업의 채용공고에서 확인만 했던 기술스택들이다. 처음 접하는게 대부분이었기 때문에 기초적 개념과 사용법을 학습하는데 급급했다. 10주간 진행된 발제내용 모두 추가학습이 필요하지만 특히 이쪽 파트들은 다시한번 정리가 필요하다.

 

 

 

무엇이 가장 중요할까?

기술도 중요하지만 무엇보다 '글쓰기' 능력이 핵심이라는 점을 배웠다. 한 코치분은 중간에 포기하지 않고 꾸준히 학습하고 노력한다면 나중에 시니어들 간의 개발 실력 차이는 크지 않다고 말했다. 이때 개발자가 자신을 차별화할 수 있는 포인트가 바로 '문서 작성 능력'이다.

 

매주 발제를 시작할 때 '명예의 전당'을 공개했다. 명예의 전당은 지난주 제출된 과제들 중 모범이 되어 다른 수강생들과 공유할 만한 우수 과제를 선정하여 소개하는 것이다. 발제 내용에 연관된 보고서 작성이 과제일 때 명예의 전당에 공개된 수강생들의 보고서를 읽어보면 왜 명예의 전당에 올랐는지 그 이유가 납득이 되었다. 대부분 구조화가 잘되어서 읽기 편했으며 논리적으로 구성되어 사고의 흐름을 확인할 수 있었다. 이런 보고서들과 코치분들의 이야기를 들으며 글쓰기의 중요성을 크게 느낄 수 있었다. 

 

 

 

마치며

2024년 한 해의 끝이 다가온다. 올해 했던 많은 선택들 중 '항해 플러스'를 등록한 행동은 최고의 선택이라 생각한다.

아쉬운 일은 털어버리고 부족했던 점을 보완하여 다음에는 더 나은 모습을 보여주도록 하자.

 

아래는 항해 플러스 6기 백엔드를 수료하며 받은 블랙배지다. 부족한 부분도 있지만 이를 극복하고 블랙배지를 넘어서 꾸준히 성장하는 실력 있는 개발자가 되어보자.

 

---

 

 

 

---

 

 

항해 플러스를 등록한 이유와 현재의 마음가짐을 잊지말고 새로운 시작을 해보자.