[데브코스 백엔드 1기] 회고

 

---

 

반 년간의 데브코스를 마쳤다

수료 키트에는 반팔 티, 텀블러가 있다

데브코스를 시작할 때, 나는 내가 경험해보지 못한 것이 나의 부족함이라고 정의했고, 그것을 채우는 것을 목표로 삼았다. 그러나 내가 이해했다고 여겼던 것들을 다시 되짚는 과정에서 오히려 더 깊은 통찰을 얻었다. 단순히 유행하는 기술을 익히는 데 그치지 않고, 스스로를 객관적으로 바라보며 부족한 점을 채워나가는 과정에서 진정한 성장이 이루어진다는 것을.

특히 가장 큰 변화는 단순히 구현하는 것에 머물지 않고, '왜 이렇게 해야 하는가'라는 질문을 끊임없이 던지게 되었다는 점이다. 이 관점은 코드 레벨에 그치지 않고, 비즈니스와 도메인 관련 기획까지 확장되었다. 기술적 결정이 비즈니스 요구사항과 도메인의 특성을 어떻게 반영해야 하는지 고민하게 되었다는 점에서, 단순히 개발을 넘어 더 넓은 시각을 가지게 되었다.

 

---

 

데브코스 과정

 

통합 역량 진단 리포트

 

프로젝트 흔적

백엔드 기초 역량을 다지며, 그와 관련된 프로젝트를 경험하는 순서로 진행됐다. 첫 번째로 커피 주문 서비스를 개발했고, 이어서 IT 뉴스레터 서비스를 주제로 한 2차 프로젝트를 진행했다. 이후 자바 스프링으로 진행된 2차 프로젝트를 코틀린 스프링으로 마이그레이션하며 기존 시스템을 개선하는 경험도 했다.

마지막으로 진행한 최종 프로젝트는 봉사 플랫폼 서비스다. 실제 서비스 배포를 목표로 현재까지도 기능 추가와 개선을 이어가고 있으며, 이전부터 함께 스터디하던 백엔드 동기들과 팀을 이루어 기획부터 설계까지 체계적으로 진행한 만큼 가장 기억에 남는다. 특히 이전 프로젝트에서 경험하지 못했던 프론트엔드 팀과의 협업은 시스템 전반을 깊이 고민하고 설계의 중요성을 배우는 계기가 되었다.

 

---

 

개발자의 역할이 단순히 코드를 작성하는 것에 그치지 않는다

 

모든 프로젝트에서 팀장을 맡아 일정 관리, 기획, 그리고 설계의 허점을 찾아내기 위해 고민하고 소통했다. 이 과정에서 아키텍처 설계 능력과 효율적인 시스템 운영 역량을 키울 수 있었으며, 팀원들의 코드 리뷰에도 적극적으로 참여하면서 원활한 커뮤니케이션 노하우를 체득했다.

 

이 모든 과정은 결국 '문제 해결 능력'이라는 큰 틀 안에 포함된다는 것을 깨달았다. 단순히 기능 구현에 그치지 않고, 시스템을 바라보는 넓은 시야를 가지게 되었다는 점에서 개발자로서 한 단계 성장할 수 있었다.

 

---

 

깃허브

 

PR의 소나큐브 코멘트

 

자주 사용하던 PR, 코드 리뷰부터 이슈 관리, 리베이스, 스쿼시 머지 등 이론으로만 접했던 기능들을 실제 프로젝트에서 적용해보기도 했다.

 

특히, 최종 프로젝트에서 소나큐브와 CI 연동을 통해 중복 코드나 보안상 문제가 되는 코드를 자동으로 분석하고, 테스트 커버리지를 위해 테스트를 반 강제적으로 작성하게 되면서 팀 전체의 코드 신뢰도가 크게 향상되었다. 이를 통해 안정적인 코드 품질을 유지할 수 있었으며, 협업 과정에서의 편리함을 배우기도 했다.

 

---

 

소프트 스킬

 

최종 프로젝트 피어 리뷰

 

협업에서 기술적인 하드 스킬만큼 소프트 스킬이 중요하다는 점을 다시금 강조하고 싶다. 의견을 솔직하고 분명하게 전달하면서도, 상대방을 존중하고 배려하는 태도는 기본이었다. 팀원들로부터 이에 대한 피드백을 받았을 때, 나의 접근 방식이 긍정적인 영향을 미쳤음을 느낄 수 있어 더욱 의미 있었다.

갈등 상황에서도 효과적인 해결 방안을 체득했다. 도메인, 서버 아키텍처, 클라우드 비용과 같은 이슈에서 의견이 충돌할 때가 많았지만, 당장에 말로만 논의하면 해결이 어려웠다. 그래서 합의를 다음 날로 미루고, 각자 의견을 문서로 정리해 발표한 후 투표로 결론을 도출했다. 이 과정에서 다양한 의견을 존중하면서도 최적의 해법을 합의할 수 있었고, 팀원들 모두가 충분히 고민하고 의견을 개진할 시간을 가질 수 있었다. 결과적으로 갈등이 완화되고 프로젝트의 기반도 더욱 탄탄해졌다.

 

---

 

하드 스킬

 

 

IT 뉴스레터 서비스(2차 프로젝트)에서는 스프링 Batch의 reader를 QueryDSL로 변환하는 작업을 진행했는데, 예상보다 훨씬 복잡해 여러 시행착오를 겪었다. 하지만 문제를 해결하며 QueryDSL의 장점을 활용할 뿐만 아니라 추가적인 최적화를 통해 눈에 띄는 성능 개선을 이뤄냈다.

 

Spring Batch ItemReader 성능 개선, 근데 이제 Querydsl을 곁들인...

 

---

 

또한, 뉴스레터 서비스를 위해 간단한 프론트엔드가 필요했기에 Vercel의 v0을 활용해 뼈대를 잡고, 프론트엔드 지인들의 도움을 받아 완성해 보았다. 처음에는 서툴렀지만, 새로운 기술 스택을 배우고 적용하는 과정은 매우 흥미로웠다. 이러한 경험은 기술적 자신감을 키우는 데도 큰 도움이 되었다.

 

v0 by Vercel

 

---

 

 

최종 프로젝트에서는 알림 기능을 위한 이벤트 아키텍처를 설계하며, 모든 이벤트들의 상위 클래스인 서버 이벤트를 구성했다. 특정 프레임워크나 외부 서비스에 의존하지 않으면서도, 구독자(리스너)의 요구에 따라 유연하게 대응할 수 있도록 설계하려고 노력했다. 특히, 확장성과 유지보수성을 염두에 두고 이벤트 기반 아키텍처의 장점을 최대한 살리려 했던 과정이 기억에 남는다.

 

추후 자료 첨부

---

 

 

프론트엔드와의 협업

 

 

액세스 토큰 전달 방식은 이번 프로젝트에서 기억에 남는 고민 중 하나였다. 기존에는 서버와 클라이언트가 쿠키를 통해 액세스 토큰을 공유했지만, 이 방식은 프론트엔드 팀의 로컬 테스트 환경에서 문제가 있었다. 프론트엔드 팀의 로컬 환경에서는 윈도우 OS의 도커 이슈로 인해 API 서버를 구동할 수 없었고, 배포된 API 서버를 기준으로 테스트할 수밖에 했다. 그러나 쿠키는 도메인에 종속적이기 때문에, 로컬 환경에서 배포 서버의 쿠키를 사용할 수 없었던 것이다.

 

이 문제를 해결하기 위해 서버가 액세스 토큰을 JSON 응답으로 전달하고, 클라이언트가 해당 토큰을 헤더에 담아 요청하는 방식으로 변경하기로 했다.

 

또한, 액세스 토큰 리프레시와 관련한 새로운 고민도 생겼다. 현재 서버가 리프레시 토큰을 관리하며, 만료된 액세스 토큰을 갱신해 쿠키에 자동으로 교체하는 방식을 사용하고 있다. 이는 기존 쿠키 기반 인증에서는 가능한 방식이었으나, 헤더 기반 인증으로 전환하면 이 과정이 불가능해진다. 헤더 기반 인증에서도 동일한 수준의 보안성과 편리성을 유지하려면 어떤 방식이 적합할지 추가적인 학습과 테스트가 필요하다.

 

프론트엔드와의 협업은 단순히 API 명세서를 구현하는 것에 그치지 않는다는 점을 깨달았다. 이번 사례를 예시로 보자면, 백엔드에서 보안을 강조하는 것도 중요하지만, 협업 과정에서는 개발 및 테스트 환경에서의 편의성 또한 반드시 고려해야 한다는 사실을 실감했다. 결국, 백엔드와 프론트엔드가 시나리오를 공유하고, 유연한 설계를 통해 상호 작업을 조율하는 것이 협업의 핵심임을 배우게 되었다.

 

돌아보면, 프론트엔드의 도커 이슈를 해결하는 것이 더 간단하고 적절한 해결책이었을 수도 있다는 생각이 든다...

 

---

 

 

향후 계획

깊이 있는 공부가 필요하다는 것을 절실히 느꼈다. 특히 자바를 다시 훑어보며, ‘공부할수록 모르는 게 더 많아진다’는 말을 실감했다. 앞으로는 JVM 동작 원리, GC, 그리고 스프링의 기반이 되는 리플렉션 같은 핵심 개념을 집중적으로 학습할 계획이다. 이를 바탕으로 직접 어노테이션을 구현하는 등 실질적인 응용력을 키우고자 한다.

 

또한, 기술의 동작 원리와 설계 의도를 명확히 이해하는 개발자가 되고 싶다. 자바, 스프링, DB(MySQL)와 같은 핵심 기술들이 어떻게 동작하고, 왜 그런 설계가 이루어졌는지 깊이 파악하며, 더 나아가 이벤트 기반 아키텍처에 대한 학습도 이어갈 계획이다. 현재 진행 중인 봉사 플랫폼 프로젝트에서 이벤트 기반으로 일부 기능을 구현했지만, 방향성이 올바른지 돌아보고 개선해야 할 부분이 많다고 느끼고 있다.

 

봉사 플랫폼 프로젝트에서는 일정상 미뤄둔 유저 도메인의 리팩토링이 가장 시급한 과제다. 현재는 유저에 속하는 ‘봉사자’와 ‘기관’이 같은 상위 클래스에 묶여 있지 않아 여러 불편이 발생하고 있다. 이를 해결하기 위해 인증/인가 로직을 유저 도메인에 집중시키고, 직접적인 관련이 없는 도메인들은 이벤트 기반으로 행동하도록 구조를 새롭게 설계할 계획이다.

 

 

우아한 기술 블로그에서 좋은 인사이트를 얻었다. 프로젝트에 적용하기 위해 몇 번 더 읽어봐야겠다.

회원시스템 이벤트기반 아키텍처 구축하기 | 우아한형제들 기술블로그

 

 

---

 

 

 

마무리

 

 

데브코스를 진행하며 정보가 넘치는 시대에서 중요한 것은 답을 얼마나 빠르게 찾느냐가 아니라, 어떻게 올바르게 적용하느냐라는 것이다. 즉, ‘무엇을 했는지’보다 '왜 그렇게 했으며, 그 과정을 어떻게 설계했는가, 그리고 다른 대안은 무엇이 있었는가'가 더 중요하다는 사실을 실감했다.

 

결국, 문제 해결 능력은 아이디어 자체가 아니라 이를 완성해 가는 과정에서 팀원들과 공유하고 설득하는 커뮤니케이션에서 나온다고 생각하게 됐다. 이를 위해서 더 높은 관점에서 문제를 바라보고, 타당한 예시와 논리를 통해 타인뿐만 아니라 나를 설득하는 과정을 정제해 나가려 한다. 

회고를 하며 스스로 발전하고 있다는 생각에 뿌듯하지만, 동시에 아직 배워야 할 것도 많고 더 고민해야 할 부분도 많다는 것을 느낀다. 앞으로도 내가 알고 있는 것과 모르는 것들을 꾸준히 점검하며, 한 걸음씩 앞으로 나아가고 싶다. 언제나 ‘왜’를 고민하고, 문제 해결 방식과 이유를 명확히 설명할 수 있는 근거 있는 개발을 할 것이다. 가가속을 향해서.

---