항해 플러스 백엔드 5기 수료 회고 - 여름 방학 경험치 이벤트가 끝나면?

이 글에 대해서 - 요약

이 글은 항해 플러스 백엔드 5기 과정의 수료 회고 글입니다. 6 ~ 10주 차 과정 중심의 내용을 톺아보며, 항해 플러스가 제게 어떤 의미였는지를 다룹니다. 더불어서 지속가능한 개발자로 성장하기 위한 생각을 나눕니다.

 

5 ~ 6주차 과정 중간 회고 글은 아래 링크로 들어가면 볼 수 있어요! 👇🏻

 

https://upcurvewave.tistory.com/700

항해 플러스 백엔드 5기 1~5주차 현실 100% 회고 (1+1=N)

 

---

항해 플러스, 수료하다! ☘️

돌이켜본다

항해 플러스 백엔드 5기 10주 과정을 무사히 수료했다.

 

두괄식 원칙 준수를 위해 어떤 결과물과 어떤 성과를 냈는지 먼저 밝힌다.

 

결과:

• 대기열 기반 예약 애플리케이션 시스템 구현
• Java17, Spring MVC/Boot/Cloud, Mysql, Redis, Kafka, Docker, Promethus, Gatling, Cucumber, Github Action

한 일:

• 총 9개의 마이크로 서비스, 50개 API, 150개 테스트 코드 작성
• 과제 수행을 위해 7일 휴가, 5회 이상의 밤샘, 학습 시간 665시간 기록
• 수료식에서 '대기열 시스템 다양한 설계 방법 탐구'라는 주제로 발표
•  

while true {
잠 - 독서실 - 출근 - 퇴근 - 게더타운 접속 - 과제 - 멘토링 - 과제 - 리뷰 - 과제 - 잠 ...
}

 

성과:

• 상위 1% 실력 인증 Black badge 획득 ❤️‍🔥
• 20개 과제 All Pass 🚀
• 성실상 수상 ✨

 

 

목표를 이뤘나?

항해를 시작하기 전, 사전 네트워킹에 참석했던 기억이 생생하다. 내가 앉아있던 테이블에 석범 코치님이 오셔서 여러 얘기를 나누던 중, 코치님이 질문을 던지셨다.

 

"여러분은 항해를 왜 하게 됐어요? 항해에서 기대하는 게 무엇인가요?"

 

그 질문을 받았을 때, 순간 머릿속이 복잡해졌다. 이직? 성장? 여러 가지 생각이 스쳐갔지만, 결국 내 마음을 움직였던 한 문장이 떠올랐다.

 

어려운 문제를 풀고 싶어서요.

 

 

이 목표를 기준으로 지난 10주 여정을 돌아보았다. 다음과 같은 요구 사항에 대해서 아래와 같은 시스템을 구현했다.

💡 아래 명세를 잘 읽어보고, 서버를 구현합니다.

• 콘서트 예약 서비스를 구현해 봅니다.
• 대기열 시스템을 구축하고, 예약 서비스는 작업가능한 유저만 수행할 수 있도록 해야 합니다.
• 사용자는 좌석예약 시에 미리 충전한 잔액을 이용합니다.
• 좌석 예약 요청 시에, 결제가 이루어지지 않더라도 일정 시간 동안 다른 유저가 해당 좌석에 접근할 수 없도록 합니다.

 

→ 대기열 시스템: 다수의 사용자가 동시에 좌석 예약을 시도할 때, 동시성 이슈를 해결하고, 작업 가능한 유저에게만 예약 기회를 부여하는 시스템 구현.

 

→ 동시성 이슈와 이벤트 드리븐 아키텍처: 예약 과정에서 발생할 수 있는 동시성 문제를 해결하기 위해, 이벤트 드리븐 아키텍처를 도입하여 비동기적으로 좌석 예약을 처리. 

 

→ 대용량 트래픽 처리: 다수의 인스턴스에서 트래픽을 분산 처리하도록 시스템을 설계하여, 트래픽 폭증에도 안정적인 서비스를 유지할 수 있도록 구현.

 

처음에는 대기열이라는 주제 자체가 굉장히 도전적으로 느껴졌다. 하지만 집단 지성의 힘을 통해 그 문제는 점차 풀어갈 수 있었고, 결국에는 생각보다 큰 어려움 없이 해결할 수 있었다.

 

그래서 "엄청 어려운 문제를 풀었다!"라고 자신 있게 말하기는 어렵다. 하지만 작은 챌린지들을 자주, 그리고 많이 접할 수 있었다는 점은 분명히 성취감이 있다.

 

개인적으로 모든 과정의 최종 보스는 마지막 수료식의 발표였다. 효율적인 대기열 시스템 구현에 있어서 기술적으로 고민했던 내용을 발표했다. 

 

 

 

성장의 궁극적인 목표는 영향력이라고 생각한다. 커리어를 늦게 시작한 만큼 성장 그 자체가 내게는 너무 신기루와 같았고 꼭 삼키고 싶은 무엇이었다. 이제는 나눠줄 게 조금 생겼다. 

 

 

진짜 실무의 문제들을 다루나

💡기술 스택?

채용 공고의 Job description에서 기술 스택은 빠지지 않는다. 회사 입장에서 이 개발자가 무엇을 할 수 있는지를 가늠하는 가장 쉽고 빠른 척도는 당연히 기술 스택이다. 따라서 기술 스택은 시장에서 자신을 팔아야 하는 개발자에게 있어서 중요한 요소이다.

 

Wanted 백엔드 개발자 채용 공고 중 일부분

Wanted 백엔드 개발자 채용 공고 중 일부분

 

항해 플러스의 커리큘럼을 되짚어보면, 이 과정에서 다루는 기술 스택은 꽤나 '핫'하다.

 

Java17+, Spring, Docker, Kafka, Redis 등 자프링 개발자라면 필수 코스인 스택을 모두 섭렵할 수 있다. 이력서에 이 기술들을 빼곡히 채워 넣을 수 있다는 것만으로도 이미 매력 포인트 충분하다. 게다가 그냥 찍먹하는 게 아니라, 실제 프로젝트에서 '찐'으로 녹여내도록 도와주기 때문에 이건 진짜 큰 도움이 될 수밖에 없다.

 

그런데 이런 질문을 던져보고 싶다. 기술 스택이 그 자체로 은탄환일까?

 

개인적인 경험을 이야기하면, 운 좋게도 첫 직장에서 마이크로서비스에 Kafka와 Redis를 사용하는 환경에서 경력을 시작했다. 덕분에 도커, Redis, Kafka 같은 기술을 익힐 수 있었고, 이력서에 이 기술들을 모두 적어 넣었다. 주니어 0~1년 차였지만, 얼떨결에 3년 차 수준의 기술 스택을 갖췄었다. 그렇게 자격 요건과 일부 우대 요건까지 만족했으니, 서류는 당연히 프리패스였을까?!

 

6개월 차 가량부터 이력서를 쓰기 시작했는데, 초기에는 합격률이 0%에 가까웠다. 추후 이력서를 여러 번 수정하면서 결국 50% 이상의 합격률까지 올렸다. 여기서 흥미로운 점은, 그동안 내 기술 스택은 전혀 바뀌지 않았다는 것이다.

 

바뀐 건 딱 세 가지였다.

• 읽는 사람을 고려한 배치와 구성: 이력서의 컴포넌트를 어떻게 배치하고, 어떤 흐름으로 구성할 것인가.
• 문제와 해결 중심의 작성: 단순히 내가 무엇을 했는지를 나열하는 게 아니라, 문제와 해결 위주로 재작성.
• 강렬한 캐릭터 설정: '그래서 네가 뭘 할 수 있는데? 네가 우리한테 왜 필요한데?'에 대답할 수 있는 캐릭터 설정.

기술을 어떻게 활용했는지, 그 기술로 어떤 문제를 어떻게 해결할 수 있는지가 진짜 경쟁력이다. 기술 스택이야 말로 쉽게 대체될 수 있는 부품과 같은 것이다. 이것이 시장의 니즈라면, 자신을 팔아야 하는 개발자는 그 과정에서 자신을 얼마나 매력적으로 어필할 수 있는지 고려해야 한다.

 

이 점에서 항해 플러스는 기술 스택을 쌓도록 도와주는 것 외에 어떤 도움을 주었을까?

💡문제, 또 문제

문제는, 항해 플러스는 무엇이 다르냐는 점이었다. 사실, 좀 삐딱하지만 그런 의문을 갖고 처음부터 시작했고, 과정 내내 그런 의문을 계속 던졌다.

 

내게 가장 와닿았던 것은 문제 해결 능력을 기를 수 있는 환경을 제공한다는 점이었다. 환경이라 하면 커리큘럼, 매주 모일 수 있는 게더타운, 공부하는 분위기와 학습을 도와주는 여러 제도들, 성장과 몰입을 위해 도와주시는 분들, 등등...

 

최근 많은 기업들이 알고리즘 테스트 대신 실제 과제를 기반으로 입사 테스트를 진행하는 경향을 보인다고 한다. 이와 관련된 자료를 살펴보면, 구글의 채용 방식 변화가 대표적이다. 구글은 전통적으로 알고리즘 중심의 면접을 진행했지만, 최근에는 실무와 직결된 과제를 주어 문제 해결 능력을 평가하는 방식으로 변화를 꾀하고 있다. 이는 실제 현장에서 마주하는 문제를 얼마나 효과적으로 해결할 수 있는지를 중점적으로 보겠다는 것이다.

 

항해의 커리큘럼은 이러한 기업의 요구를 타겟팅하도록 설계했다. "항플 과제 올 패스하면 웬만한 기업 과제 통과 쌉 가능!" 외치는 코치님들 자신감...은 실화다... ㅋㅋㅋ! 그만큼 커리큘럼과 과제들은 충분히 도전적이다.

 

https://hanghae99.spartacodingclub.kr/plus/be

 

과제는 "구현"이 아니라 "문제 중심이다. 특히 6 ~ 10 주차의 내용은 대용량 트래픽 처리와 장애 대응에 초점을 맞추고 있어 실무에서 직면할 수 있는 복잡한 문제들을 다룬다. 즉, 실제 환경에서 적용 가능한 해결 능력을 기를 수 있도록 한다. 매 주차마다 과제가 주어지고 이에 대해서 충분한 자료 학습과 동료 개발자들과의 다양한 토론을 하면서 자신의 코드에 명확한 의도와 철학을 담아, 이를 통해 문제를 해결할 수 있어야 한다.

 

이러한 점에서 항해의 커리큘럼은 분명히 성장지향적이면서도 실용적이다. 

💡 내가 푼 문제들

1 ~ 5주 차는 주로 구현 위주로 커리큘럼을 진행한다. 이때도 주요 이슈들을 찍먹해볼 수 있다. 관련 내용은 1부 회고에서 다루었기에 여기에서 볼 수 있다.

 

6 ~ 10주 차에는 개발과 운영 전반에서 발생할 수 있는 문제들에 집중했다. 주요 주제로는 동시성 문제, 캐싱 전략, 트랜잭션 관리, 이벤트 드리븐 아키텍처, 성능 모니터링 및 개선, 그리고 장애 대응을 다루었다. 간략하게나마 하나씩 살펴보자.

 

자세한 내용은 아래 레포의 리드미에서 볼 수 있다.

 

GitHub - renechoi/hhplus-concert-reservation-system: 항해 플러스 서버 구축 콘서트 예약 시스템

 

 

1. 동시성 문제와 극복

동시성 문제는 여러 스레드나 프로세스가 동일한 자원에 동시에 접근할 때 발생하는 대표적인 문제이다. 동시성 이슈가 발생하면 데이터의 일관성과 무결성을 보장하기 어렵다. 이를 극복하기 위해서는 뮤텍스, 세마포어와 같은 동기화 기법을 사용하여 임계 영역을 보호하고, 상호 배제를 통해 레이스 컨디션을 방지해야 한다. 과정에서는 실전에서 사용할 수 있는 다양한 락을 살펴보며, 실제 프로젝트에서 발생 가능한 동시성을 탐구하고 해결한다.

2. 캐싱을 이용한 API 및 쿼리 개선

캐싱 전략을 통해 API의 성능을 극대화하는 데 집중했다. 조회 빈도가 높고 데이터 변경 빈도가 낮은 쿼리들에 대해 Look-aside 캐싱과 글로벌 캐시(예: Redis)를 활용해 응답 속도를 크게 향상시켰고, 이를 통해 대량의 트래픽에도 안정적인 성능을 유지할 수 있었다. 캐시 사용 전에는 23%의 요청이 실패하고 평균 응답 시간이 11.6초에 달했으며, 시스템 과부하로 다양한 오류가 발생했지만, 캐시 사용 후에는 실패율이 0%로 감소하고 평균 응답 시간이 3ms로 크게 개선하는 경험을 했다.

3. 대기열 시스템 리팩토링 RDB → Redis

기존 RDB 기반 대기열 시스템을 Redis로 리팩토링하여 성능을 크게 개선했다. Redis의 Key-Value 구조와 TTL(만료 시간) 기능을 활용해 대기열 관리가 더 간편하고 효율적이 되었으며, 이로 인해 대기열 처리 속도가 대폭 향상되었다. 리팩토링 후 초당 처리 가능한 요청 수는 RDB의 118건에서 543건으로 약 4.6배 증가했고, 평균 응답 시간은 514ms에서 84ms로, 95번째 백분위수 응답 시간은 2128ms에서 510ms로 크게 개선되었다. 요청 실패율도 24%에서 0%로 감소했으며, 최대 응답 시간은 3250ms에서 1144ms로 줄어드는 등 전체 성능이 크게 향상되었다.

4. 레디스 기반의 큐 메커니즘 최적 방안 탐구

기존 RDB 기반 대기열 시스템을 Redis로 전환하면서 다양한 방식들을 탐구했다. 주요 내용으로는 은행 창구 방식과 놀이 공원 방식을 포함한 대기열 처리 메커니즘의 비교, 대기 토큰 관리 방법, 그리고 활성 토큰을 관리하는 여러 방식들이 있다. 상태 기반, HashSet 기반, Counter 기반, Kafka 기반 방식 등을 실험하며 각 방식의 아키텍처, 처리 로직, 장단점을 상세히 분석하였다. 최종적으로 Kafka와 Redis를 결합한 방식이 성능과 확장성에서 가장 효율적임을 확인하고 이를 구현하여 대기 시간을 단축하고 시스템의 응답성을 크게 향상시킬 수 있었다.

관련글 바로가기

대기열 시스템 다양한 설계 방법 탐구 (feat. 레디스와 카프카를 이용한 O(1) 최적화)

 

5. API 쿼리 분석 및 개선

실제 프로젝트에서 성능을 최적화하기 위해 API 쿼리의 효율성을 분석하고 개선하는 작업을 진행했다. 주요 쿼리들의 빈도와 복잡도를 고려하여 인덱스를 적절히 설정하고, 불필요한 테이블 스캔을 줄여 응답 시간을 단축시켰다. 이 과정에서 PMM(Percona Monitoring and Management), Grafana, Prometheus, Gatling을 활용하여 쿼리 성능을 모니터링하고, 병목 현상을 식별하여 실시간으로 개선 사항을 적용했다. PMM은 데이터베이스 성능 지표를 추적하고 분석하는 데 유용했으며, Grafana의 대시보드를 통해 CPU 사용량, 메모리 소비, 디스크 I/O 등의 주요 성능 지표를 시각화하고, Prometheus를 통해 실시간으로 데이터를 수집하여 문제를 조기에 감지하고 대응할 수 있었다. 또한, Gatling을 사용해 성능 테스트를 자동화하여 API의 처리량과 응답 시간을 지속적으로 모니터링하고 개선할 수 있었다. 이를 통해 데이터베이스 성능을 크게 향상시키고, API의 전반적인 응답 속도를 개선할 수 있었다.

6. MSA 아키텍처에서 느슨한 결합 추구하기

MSA 아키텍처에서 느슨한 결합을 구현하기 위해 이벤트 드리븐 아키텍처(EDA)를 적용했다. EDA를 통해 서비스 간 비동기 통신을 가능하게 하여, 한 서비스의 변경이 다른 서비스에 영향을 미치지 않도록 했다. 이를 통해 시스템의 유연성과 확장성을 높였으며, 특히 트랜잭션이 분리된 환경에서 논리적 일관성을 유지할 수 있었다. 또한, 트랜잭셔널 아웃박스 패턴을 사용하여 이벤트 유실을 방지하고, 데이터 일관성을 보장하는 방법을 추가하여 시스템의 신뢰성을 높였다.

 

관련글 바로가기

대기열 기반 예약 시스템에서 MSA와 EDA를 이용해 느슨한 결합 추구하기

 

7. 장애 대응

장애 대응의 일환으로, API 부하 테스트를 수행하여 시스템의 성능을 평가했다. 먼저, 주요 API들을 선정하여 시나리오를 기반으로 부하 테스트를 계획하고 실행했다. 이를 통해 트래픽 급증 시 병목 구간을 식별하고, Redis 클러스터 확장, 인덱스 최적화, 외부 캐시 시스템 도입 등 성능 개선 방안을 제시했다. 이러한 테스트는 실무 환경에서 발생할 수 있는 장애 상황에 대한 대응 능력을 강화하는 데 중점을 두었다.

💡 문서화

개발자에게 있어 또 하나 중요한 역량을 꼽자면 문서화 역량이다.

 

실무에서 일하는 시간을 돌이켜보자. 문서를 읽고 글을 작성하는 시간이 코드를 치는 시간보다 훨-씬 많다. 아마 많은 개발자들이 공감할 거라 생각한다. 코드 량과 문서 량은 최소한 비례한다. 밑바닥부터 생자로 프로젝트를 시작하는 경우는 드문데, 그렇더라도 결국엔 문서를 작성하는 일이 코드 작성보다 많다.

 

또, 개발자 일상의 절반 이상은 남의 코드를 이해하는 데 쓰는 시간이다. 따라서 동료와 자신에게 친절하려면 작성된 코드의 의도와 맥락을 잘 설명해 주는 좋은 문서가 필수적이다.

 

항해는 이와 같은 개발자의 사정을 고려했을까? 다음과 같이 항해에서 문서화 과제를 접했던 경우를 모아봤다.

항해에서 경험한 문서화 과제들

• ... 스텝 10까지는 생략
• STEP 11: 동시성 이슈를 파악하고 가능한 제어 방식을 도입한 후, 각각의 장단점을 문서로 정리하고 제출하기. 
• STEP 12: DB Lock을 활용한 동시성 제어 방식의 구현 및 검증 과정을 문서화하기.
• STEP 13: 캐싱을 통한 성능 개선 방안을 분석하고, 합리적인 이유와 함께 문서로 정리하기. 
• STEP 14: 다양한 시나리오를 기반으로 Caching Strategy를 적용하거나 대기열을 개선하는 로직을 설계하고, 이를 문서화하기.
• STEP 15: 쿼리 성능 개선을 위해 필요한 인덱스 추가 전후의 성능을 비교하고, 결과를 문서화하기.
• STEP 16: 트랜잭션 범위 이해 및 MSA 형태로 서비스 분리 시 발생할 수 있는 문제와 해결 방안을 설계하고 문서화하기.
• STEP 17~20: 카프카 설치 및 연동, 성능 테스트, 장애 대응 문서 작성 등 다양한 실무적 과제 문서화하기. 

ㄹㅇ 문서화 작업 정말 뒤집어지게 했다....ㅋㅋㅋ 

 

10주 간 작성한 coument 폴더 하위의 문서와 자료들

 

내가 작성한 코드에 대해, 어떤 이유와 배경으로 그렇게 썼는지, 어떻게 작동하는지, 그래서 어떻다는 건지를 문서로 명확하게 표현하는 연습은 아무리 강조해도 지나치지 않다. 

 

나에게 항해플러스란?

경험치 이벤트

나에게 항해플러스란 ㅇㅇㅇ이다?

 

라고 질문을 스스로 던져보았고, 다음과 같은 답변을 했다.

 

나에게 항해란 경험치 이벤트다!

 

수료식때 발표한 자료의 한 페이지

 

어릴 적이면 누구나 한 번쯤 교회에서 하는 수련회나 학교에서 가는 수련회를 가봤을 것이다. 항해에서의 ‘경험치 이벤트’는 그런 수련회와 비슷하다고 할 수 있겠다.

 

주니어로서 하드한 대규모 트래픽을 처리하거나 딥한 장애를 직접 경험한다면 정말 특권을 누리는 것이다. 실무에서 접하기는 쉽지 않은 경험이라 생각한다. 실제로 장애가 발생하면 안 되니까, 위험을 감수하면서 실험하기도 어렵고, 대기열이나 대용량 트래픽 같은 상황을 늘 상정할 수도 없는 게 현실이다.

 

더군다나 업무 환경은 말할 것도 없다. 회사에서 어디 사용하고 싶다고 해서 기술 스택을 마음대로 정할 수가 있던가? 자바 버전을 생각해 보자. 자바 17? 정말 흔치 않다. 자바 11? 그것도 사치일 때가 많다. 자바 8을 쓴다면 "와, 그래도 최신이네!"라고 말할 정도다. 자바 7을 쓰는 경우도 당연히 있다. 스프링 프레임워크? 3.x를 쓴다고? 현실에선 2.x도 못 쓰고, 2.x에서 3.x 올리기 어려운 경우도 많다.

 

레디스나 카프카? MSA? 꿈같은 이야기일 수 있다. 최신 기술 이야기를 꺼내면 오히려 "그게 우리 시스템에 필요한 거야?"라는 반문이 돌아올 수 있다. 

 

이런 현실을 생각해 보면, 항해에서의 10주는 정말 잘 차려진 기술 밥상이다! 보통이라면 현업에서 몇 년 동안 배워야 할 것을 10주 동안 압축적으로 배울 수 있다. 시니어 개발자들 어깨너머로 곁눈질로 배울 법한 주제들을 직접 체험하고 내 손에 쥘 수 있다.

 

그런 점에서 항해에서의 경험치 이벤트를 정말 풍성히 누려야 한다. 게임을 하다가 경험치 이벤트 기간에는 빨리 이때 레벨업 하려고 특별히 밤도 새고 하는 것처럼, 항플을 하는 동안에는 모두가 그런 마음으로 임했던 것 같다.

 

 

지속가능한 개발

역설적이지만, 이제는 항해에서 배운 것을 조금씩 잊어야 할 때다.

 

항해 플러스에서는 정말 마음껏 해볼 수 있었다. 모든 기술, 모든 도전이 가능했다. 그런 의미에서 항해플러스는 놀이터이기도 했다. 이론도 충분히 익히고, 실패에 두려워할 필요도 없이 다양한 문제에 도전했다. 그러니까 실패해 봤자 Fail이니깐...(?!)

 

안타깝게도, 우리가 돌아가야 할 실무 환경은 그렇지가 않다. 😭 실무에서 풀어야 하는 문제는 수능 시험 같은 정답이 있는 문제가 아니다. 한 번의 딸깍으로도 몇 분만에 평생 일해도 벌지 못할 액수만큼의 사업 손실을 발생시킬 수 있다. (물론 내 인생에 그런 일은 없어야 함)

 

까놓고 말해보자. 개발자는 뭐 하는 사람인가? 정말 나이브하게 말해서 개발자는 직장인이다. 돈 받고 회사 이익 증진에 기여하는 사람이다. 그걸 부정할 거면 나와서 자기 사업하는 게 맞다.

 

그러면 회사에서의 개발자는 기술 자체, 트렌드, 혹은 옳고 그름, 정답만을 따질 처지가 아니다. 주어진 상황에서 최적화된 해답을 찾아내야 한다. 때로는 "끄르믄 끄으지..."와 같은 어려운 상황도 감내해야 할 수도 있다. 

 

 

방금 하산한 문하생처럼, 최고의 코드, 완벽한 아키텍처를 배워왔다고 치자. 나는 최신 지식으로 무장했고 이제 나만 믿어봐! 라고 외치고 싶지만, 정작 내일 내가 출근해서 풀어야 하는 문제는 코드 혹은 아키텍처와는 전혀 다른 문제일 수 있다. 물론 마음은 다 똑같다. 당장 저 꼴 보기 싫은 레거시 시스템 전부 갈아엎고 싶은 마음. '이렇게 하면 될 것을 왜 저렇게 하지?'와 같은 생각들. 

 

하지만 현실은 다르다. 예를 들어, 아무리 최신 기술을 사용해 완벽한 코드를 작성해도, 기존 시스템과의 호환성을 유지해야 하거나, 팀 내에서의 협업 문제로 인해 계획을 수정해야 할 수도 있다. 아니면 제한된 자원과 시간 속에서 최선의 결과를 내기 위해 타협이 필요할 수도 있다.

 

이런 상황에서 개발자가 할 일은 어쨌든 모든 상황과 자원을 고려해 가장 적합한 해답을 찾아내야 한다는 것이다. 이 과정이야말로 진정한 소프트웨어 개발에서 말하는 유연성이 아닐까? 

 

기술적 결정에 대해서도 생각해 보자.

 

우리는 항해에서 동시성 이슈를 다루며 낙관적 락과 비관적 락의 사용에 대해 배웠다. 충돌이 적게 발생하는 상황에서는 낙관적 락을 사용하는 것이 유리하다. 충돌이 자주 발생하거나 데이터 일관성이 매우 중요한 상황에서는 비관적 락이 더 적합하다. 정석은 이렇다고 말할 수 있겠다. 그리고 우리 API에서는 그게 맞았다. 이 원칙은 불변일까? 현실에서는 시스템의 복잡성, 요구 사항의 변화, 성능 최적화의 필요성 등 다양한 요소들이 기술적 결정을 뒤흔들 수 있다. 그때는 맞았고 지금은 틀리다. 예를 들어, 예상치 못한 트래픽 증가나 비즈니스의 변경으로 그때는 낙관 락이 더 적합했던 상황에서 지금은 비관 락을 사용해야 할 수도 있다. 

 

또, 트랜잭셔널 아웃박스 패턴에 대해서도 배웠다. 이 패턴은 데이터베이스의 트랜잭션과 메시지 브로커 사이의 일관성을 유지하기 위해 설계된 것이다. 구체적으로는, 데이터베이스에 변경 사항을 기록하는 동시에, 해당 변경을 메시지로 브로커에 안전하게 전달하는 방식이다. 이 방법을 사용하면 데이터 손실이나 일관성 문제가 발생하지 않도록 할 수 있다. 하지만, 이건 어디까지나 패턴이다. 패턴이란, 자주 발생하기 때문에 문양처럼 신뢰할만한 사용을 위해 만들어낸 개념이다. 따라서 언제든 그 패턴을 깨트리는 다른 패턴이 존재할 수 있다. 

 

말하자면, 수학 문제 풀이와 같이 항상 옳은 정답이란 게 개발 일에 있느냐는 것이다. 중요한 것은 상황에 맞게 최적의 결정을 내릴 수 있는 유연한 사고와 경험이다!

 

회사원으로서 개발자의 역량은 그 조직의 이익을 증대시키는 데 기여하는 데 있다. 실전에서 만나는 다양하고 복잡한 문제에 있어서 내가 익혔던 방식이 지속적으로 옳다는 생각을 버리고, 실제 상황에 맞는 최적의 해결책을 찾아내는 것이 개발자의 진정한 매력이라고 생각한다.

 

이런 점에서 항해 아고라에서의 경험이 매우 유의미했다고 생각한다. 아고라는 슬랙 채널로 다양한 주제에 대해 활발하게 논의할 수 있는 공간이다. 아고라에서는 개발자 대 개발자로서 솔직하게 의견을 교환하고, 서로의 접근 방식을 비교하면서 새로운 시각을 얻을 수 있었다.

 

 

개인적으로 내가 지인에게 항플을 추천한다면, 아고라에서의 경험 하나만큼은 꼭 챙겨가라고 제안하고 싶다.

 

 

ㅋㅋㅋㅋ GPT에 아고라 사진을 던져주며 현대 개발자들 컨셉으로 그려달라고 하여 받은 그림 중에 그나마 괜찮은 그림

 

 

모든 가정에 의문을 제기하고 꼬리 질문을 물고 타고 타고 가보자. 꼭 정답이 아니더라도 다양한 실험과 도전을 해보면 어떨까? 그러다 보면 과제에서는 Fail을 받을 수도 있다. 그런데 내가 도전을 경험했고 나만의 철학과 접근 방식을 가졌다면 그것이 더 값지다고 생각한다. 아쉽게도 나는 그렇게까지 사이드 트랙을 탈 만큼 용기는 없었다. 하지만 아고라를 많이 활용하면서 의견을 나누고 도전하기를 즐겼다. 덕분에 기술적인 울타리를 깨어나가는 경험을 했던 것 같고, 덕분에 성실하다는 공로(?!)를 인정받아 상도 수상할 수 있었다!

 

 

정말 마무리 

 

무엇보다도 정말 남는 건 함께 고생한 개발자 동료들이다. 

 

 

 

이 사람들로 말할 거 같으면 개발자 잘리면 같이 타코 트럭 차리자고 하는 사람들이다. 

 

 

 

 

앞에서 항해는 이제 잊어버릴 때라고 썼다. 

 

하지만 좋은 사람들은 남는다. 함께 만드는 좋은 습관이 있다면 더 좋다. 그래서 개발자 인연이 소중하다. 

 

출발하게 만드는 힘이 ‘동기’라면 계속 나아가게 만드는 힘은 ‘습관’이다. 

 

 

정말 밀도 높고 강렬한 시간 10주를 이제 접어두면서 그렇게 아쉽지 않다면, 이 사람들 때문이라고 생각한다.

 

앞으로가 더 기대되는 사람들과 재밌는 것들 할 것들이 더 많아서 좋다. 

 

여름 방학 경험치 이벤트가 끝나면? 

 

가을 퀘스트가 오고, 그러면 또 가을 이벤트가 온다. 

 

끝.

 

---

 

자주 물으시는 질문 

저만의 뇌피셜로 드리는 답변입니다!

 

1. 회사에 다니면서 항해 플러스 프로그램에 참여하는 것이 가능할까요?

가능합니다. 다만, 직장과 병행하려면 하루에 최소 3-4시간은 꾸준히 학습에 투자해야 할 만큼 프로그램의 학습량이 적지 않습니다. 프로그램에 참여하신 분들 중 직장인은 절반 정도 되었던 것 같아요. 직장 다니면서 할 때는 시간을 관리를 잘해야 합니다. 모든 과제에 충분한 시간과 투자를 하면 좋겠지만, 그렇지 못한 경우더라도 얻어갈 것은 충분히 많다고 생각합니다. 

2. 항해 플러스 커리큘럼이 이직 준비에 도움이 되나요?

네, 커리큘럼은 분명히 도움이 됩니다. 다만, 이 과정은 본인이 얼마만큼 노력하느냐에 따라 얻어가는 게 천차만별일 수 있는 과정이라고 생각합니다. 💪🏻 

 

3. 항해 플러스에 집중하는 것이 나을까요, 아니면 지금 당장 이직 기회를 잡는 것이 좋을까요?

항해 플러스 프로그램은 개발자로서의 역량을 강화하는 데 큰 도움이 되므로, 프로그램에 집중하는 것이 좋을 수 있습니다. 그러나 이직 공고가 있다면 병행하여 지원해 보는 것도 나쁘지 않은 선택입니다. 이직 기회는 계속해서 생길 수 있으니, 자신에게 더 중요한 목표에 따라 결정을 내리시면 됩니다. 저의 경우에는 항플 초반에 다른 기업에 지원하고 면접도 보면서 진행했습니다. 대신 휴가도 많이 써야 했어요. 😭

 

4. 인강을 보는 것보다 나을까요?

상황에 따라 다를 수 있습니다. 만약 직장을 다니고 있다면, 재직자 과정인 항해 플러스가 더 적합할 수 있습니다. 이는 제가 경험해서가 아니라, 실제로 몰입이 가장 효율적으로 작동하는 기전을 살펴보면, 짧은 시간에 목표를 설정하고 집중적으로 학습할 때 학습 효율이 가장 높기 때문입니다.

또한, 항해 플러스의 또 다른 장점은 이력서에 기재할 수 있다는 점입니다. 직장을 다니면서도 제대로 된 교육을 받고, 다양한 개발자들과의 인맥을 쌓을 수 있습니다. 이를 통해 소중한 인연들도 많이 만날 수 있습니다.

 

5. 언어 공부를 여러 개 하는 게 좋을까요? 

저는 한 가지 언어에 집중하는 것이 좋다고 생각합니다. 언어는 도구일 뿐이며, 기본적인 원리는 대부분 비슷하기 때문에 하나의 언어에 정통하게 되면, 다른 언어는 쉽게 배울 수 있습니다. 

 

그리고 회사에 가서 일을 하다가 다른 언어를 익혀야 하는 경우가 있습니다. 그때, 회사에서 스터디하면서 새로운 언어를 배울 수 있습니다. 

 

 

---

 

 

항해 플러스 백엔드 과정에 대해 궁금하시거나 고민하신다면 커피챗 환영합니다 😊

현실 이야기 가감 없이 전해드립니다...ㅋㅋㅋ 

 

https://open.kakao.com/o/sTp2KQDg

르네님의 오픈프로필

 

 

그리고 등록 시엔 아래 할인 코드를 사용하시면 20만 원 할인을 받으실 수 있습니다 👏🏻

→ HHPGS0270