LG U+ 유레카 백엔드 1기를 수료하며

LG U+ 유레카 백엔드 비대면 1기 수료!
교육 기간: 2024.6 ~ 2024.12 (7개월)

2024년 하반기를 불태웠다 해도 과언이 아닐정도로 매일 9 to 6 로 달렸던 유레카 교육과정을 저번주 화요일을 끝으로 수료하게 되었다. 끝나고보니 지난 상반기의 나보다 훨씬 성장되어 있는 내 자신을 보며 수고했다고 말하고 싶다.

🔥유레카 지원부터 합격까지의 스토리

유레카에 지원하게 된 가장 큰 이유는 “실무 중심의 다량의 프로젝트” 를 진행한다는 점이었다.

🐚 나는 껍데기만 개발자였다.

6월 시점까지 나의 이력은 아래와 같았다.

• 자바 이해도 중
• 프로젝트 경험 2번
• 수상 경력 2번

운좋게 따라준 수상과 경험들에 비해 실력은 얕았다. 특히 가장 부족했던 점은 개발자 간의 협업 능력이었다. 캡스톤을 진행할 때 백엔드 개발자는 나 혼자였기에 무엇을 깊게 고민해야 하는지 몰랐다.

물론 해커톤을 통해 여러 개발자를 만나고 소통해 볼 수 있었지만, 짧은 시간 내에 협업을 배우기에는 부족한 시간이었다. 그래서 이런 나에게 유레카 교육 과정은 다른 부트캠프보다 가장 적합한 부트캠프라 생각됐다.

그리고 이건 유레카의 가장 큰 강점인데..
바로 유플러스 지원 시 혜택이 제공된다는 점이다!

이 부분은 어느 부트캠프와도 비교할 수 없는 가장 큰 강점이자 차별점이다.
그래서 어떤 부트캠프보다 준비를 가장 많이 했던 것 같다.

운이 따라준 면접

서류와 코딩테스트를 무사히 통과하고 대망의 면접을 보게 되었다.

운이 좋았던게 6월 달에 회사 면접도 연달아 보게 되면서 나름 면접 공포증이 없던 때였다. 그래서 '준비한 대로만 보여주고 오자' 하는 마음가짐으로 면접장에 들어갔다. 다행히 예상 질문과 크게 벗어나지 않아서 오히려 하고 싶은 말이 많은 데 시간이 부족했다는 점이 아쉬울 정도였다.
(이때 왜이리 자신감이 넘쳤는지 지금은 상상도 모대)

기분 좋은 말 "합격을 축하합니다 🎉"

아무튼 이런 모습을 좋게 봐주셨는지 당당하게 합격 목걸이를 받을 수 있었다.

이제 남은 건 하반기까지 나의 협업 능력! 그리고 기술력 성장! 을 기대하는 것이다.
과연 내가 이 두 키워드에 어울리는 사람이 되었을까?

✓ 프로젝트별 회고

💡 유레카 백엔드 비대면 커리큘럼 보러가기

위에서도 말했듯이 유레카는 프로젝트가 무려 4개나 진행된다. 프로젝트 과정을 빠짐없이 기록하고자 GitHub 과 노션을 이용해 기록해왔다. 그래서 프로젝트별로 회고해 보고자 한다.

Swing 으로 처음 구현해 본 미니프로젝트1

🔗 미니프로젝트1: 영화 평가 플랫폼 코드보기
개발 기간: 2024.07.16 ~ 2024.07.18 (3일)

가장 첫 번째 프로젝트는 JDBC 와 Swing 을 이용한 자유 주제로 진행된 프로젝트였다. 교육 중간마다 간단한 실습을 했었는데, 그때마다 나는 영화 주제로 진행했기 때문에 자연스럽게 영화 평가 플랫폼으로 주제를 선정하게 되었다.

이 프로젝트는 서버 구현보다 UI를 구현하는 데 어려움을 많이 겪었다. Swing을 처음 접했기 때문에 강사님이 알려주신 내용만으로는 이해하고 구현하기가 쉽지 않았다. 그래서 간단한 프로젝트임에도 불구하고 화면 구상과 UI 구성에 많은 시간을 할애했다.

비록 결과물이 완벽하지는 않았지만, 이번 과정에서 순수 JDBC로 직접 쿼리를 작성하며 데이터베이스와 상호작용하는 기본 원리를 이해할 수 있었다. 특히, 트랜잭션 관리의 중요성을 체감하며 JPA와 같은 ORM의 필요성을 뼈저리게 느낄 수 있었다...ㅎㅎ

테스트커버리지 100% 채워봤던 미니프로젝트2

🔗 미니프로젝트2: 오이 마켓 코드보기
개발 기간: 2024.09.10 ~ 2024.09.24 (약 2주)

드디어 스프링을 사용할 수 있게 되었다!!
아마 나 뿐만 아니라 모두가 좋아하지 않았을까 싶다.

기간이 2주였지만 추석이 겹치면서 실제 개발 기간은 일주일이 채 되지 않는 기간이었다. 그래서 프로젝트를 시작할 때 기술적 기교보다 모든 비즈니스 로직의 테스트를 작성해 커버리지 100%를 채우는 것을 목표로 진행하게 되었다.

📍 설득으로 이뤄낸 기술 도입의 성공

이전 프로젝트 와사비 나 캡스톤 에서 테스트 코드를 작성할 때는 Autoparams 라는 라이브러리를 사용해 테스트 데이터를 자동으로 생성했었다. 하지만 이번에는 오직 순수 JUnit과 Mock 라이브러리만 사용해 테스트를 작성해야 했기 때문에, 반복되는 코드가 많아지면서 비즈니스 로직을 테스트하는 데 불필요한 작업들이 방해가 됐다.

이를 해결하기 위해, 나는 Fixture를 사용해 보자는 제안을 하게 되었다. 하지만 Fixture 를 사용해본 한 명의 팀원을 제외한 나머지는 생소한 상황이었기에,

“Fixture 를 사용하면 어떤 이점이 있는지 알려주세요”
라는 요청이 있었다.

이에 미리 Fixutre 를 적용시킨 코드와 적용하지 않은 코드를 비교하며 불필요한 코드 중복을 줄이고 코드 가독성을 높일 수 있음을 강조했다. 두 방식의 차이나는 코드를 통해 팀원들의 이해를 도왔고, 그 결과 동의 하에 Fixture 를 도입할 수 있었다.

이 과정에서 기술 도입에 대한 설득력 있는 의견이 되기 위해선 단순히 이점만을 설명하는 것이 아닌

1. 현재 발생하는 문제점을 명확히 제시하고
2. 구체적인 예시를 통해 타당한 근거를 마련하는 것이 중요함을 알 수 있었다.

🏆 페어 프로그래밍의 묘미를 알게 해 준 종합 프로젝트

🔗 종합 프로젝트: 아이북조아 코드보기
개발 기간: 2024.10.15 ~ 2024.11.03 (3주)

종합 프로젝트는 DB 부터 SpringBoot 까지 모든 백엔드 스택을 이수한 이후 본격적으로 시작하는 찐 프로젝트이다.

👍 결론부터 말하면 처음과 끝이 모두 완벽했던 프로젝트였다.

백엔드만 진행하는 프로젝트였기에 페어 프로그래밍으로 진행하기로 결정했다. 팀원 모두가 서로의 의견을 존중하고 경청함으로써 분위기 역시 항상 최고였다. 이 부분을 자부할 수 있는건, 매일 강사님이 모든 팀을 돌아가면서 진행 상황을 확인하시는데 ‘팀 분위기가 다른 팀에 비해 밝다’ ‘문제 없이 원활히 돌아가는 유일한 팀인 것 같다’ 라는 얘기를 자주 해주셨기 때문이다.

기능별로 페어를 나누어 진행했는데, 그 중 도서 추천 배치를 신지님과 함께 맡았다. 배치 처리가 처음이었기에 가중치 요소부터 구현 흐름까지 다양한 의견을 주고받으며 깊이 고민했다.

처음에는 이 방식이 낯설어서 흐름을 즉각적으로 떠올리기 어려웠지만, 차츰 적응하면서 알게 된 것은 혼자 생각한 내용에 또 다른 의문이 덧붙여지고, 그것이 해결되는 과정에서 아이디어가 더욱 견고해진다는 점이었다.

이런 과정을 통해 배치 처리에서 성능 최적화를 이루었고, 팀원들과의 소통이 단순한 업무 분담을 넘어 문제 해결과 아이디어 발전의 원동력으로 작용했다는 점에서 기술적인 성장뿐 아니라 협업의 중요성을 체감할 수 있었던 값진 경험이었다.

그 덕분일까? 우리는 종합 프로젝트에서 🏆 최우수상 🏆 을 받게 되었다 !

문서화를 통한 협업을 알게 된 융합 프로젝트

🔗 융합 프로젝트: POV 코드보기
개발 기간: 2024.10.15 ~ 2024.11.03 (6주)

융합 프로젝트는 프론트반과 합반하여 진행되는 마지막 프로젝트로, 프론트와의 협업이 가장 중요한 요소였다.

📍 개발 생산성을 향상시킨 Swagger & Jira 도입

1. 프로젝트 초기 단계에서 원활한 현업을 위해 Swagger 를 활용해 API 문서를 자동화했다. 덕분에 비즈니스 로직이 아직 구현되지 않았음에도 각 API 목적과 요청/응답 형식, 예외 상황까지 확인할 수 있어 개발 생산성을 높일 수 있었다. 또한 API 명세 변경 시 빠르게 반영할 수 있어 노션으로 관리하는 것보다 훨씬 효율적으로 작업할 수 있었다.

2. 제한된 기간 내에 프로젝트 완성도를 높이기 위해 각 스토리마다 스토리포인트를 산정했다. 이 과정에서 팀원들은 자신이 맡은 스토리의 난이도와 소요 시간을 직접 포인트로 작성했고, 포인트 내에 구현하지 못했을 경우 반드시 도움을 요청하는 규칙을 설정했다. 이 규칙은 팀원 간의 적극적인 소통을 유도했을 뿐만 아니라, 문제를 조기에 해결할 수 있도록 도왔다.

📍 효율적인 협업을 위한 컨벤션 설정

코드의 일관성을 위해 아래 항목별로 컨벤션을 설정했다.

• GitHub PR
• Method
• DTO 네이밍
• Exception
• TestCode
• 프로젝트 패키지 구조
• S3 패키지 구조
• HTTP 상태 코드

특히 프로젝트 패키지 구조 에 고민을 가장 많이 했다.

기존에 도메인별로 서비스를 관리하던 중 여러 도메인이 겹치는 서비스가 발생하면서 패키지를 재구조화하는 일이 필요했다. ex) 클럽의 리뷰를 가져올 때

처음엔 서비스 간의 책임을 명확히 분리하고 복잡도를 줄일 수 있는 퍼사드 패턴을 도입하려고 했다. 하지만 모든 서비스에 퍼사드 패턴을 도입하기엔 시간이 부족하다는 점을 고려해, 아래와 같은 회의를 거쳐 최종적으로 도메인이 겹칠 경우 행위의 목적이 되는 도메인 패키지 하위에 기능을 만들도록 결론지었다.

• 회의1: 퍼사드 패턴을 도입할까?
• 회의2: 행위자를 기준으로 서비스를 나누자!

✓ 목표를 이루었는가?

Yes !

스스로 느끼는 성장과 주변 동료분들의 얘기를 종합해보면, 전보다 많이 성장했음을 알 수 있었다.
그 성장은 다음과 같다:

Tech

• 기술 도입에 대한 근거있는 이유 제시
• 스프링 배치 이해와 적용할 수 역량
• 테스트 도구(JMeter) 를 활용한 부하 테스트 설계 및 실행
• DB 정합성을 위한 락 개념 이해와 적용할 수 역량

Collaboration

• Jira 사용법을 익혀 효율적으로 작업 관리 가능
• 학습한 내용을 정리 및 공유하여 팀의 생산성에 기여
• 코드 리뷰를 통한 적극적인 피드백 수용 및 의견 제안

✓ 감사한 분들

긴 교육 과정인 만큼 가끔 지칠 때도 있었지만, 열심히 하는 동료들의 모습을 보며 포기하지 않고 더 열심히 해야겠다는 동기부여를 받을 수 있었다. 모두에게서 배울점이 많아 감사한 분들이 많지만, 그 중 특히 감사한 분들을 뽑자면

• 코드 품질 향상을 위해 개발자로서 어떤 고민을 해야 하는지 알려주셨던 영철님
• 소통의 신… 항상 먼저 고민을 공유하고 좋은 자료는 아낌없이 나눠주신, ‘신지최고’ 신지님
• 먼저 편하게 다가와줘서 너무 고마웠던 시은(정)
• 막힘없는 의견 제시로 배울 게 많았던 지민 & 시은(박)
• 수료 마지막날을 정말정말 행복한 하루로 마무리해 준 회헌님

아쉬운 건 많은 사람들과 소통해보지 못했던 점이 가장 크다.

비대면으로 진행되다 보니 한정적인 인원과 소통 할 수 밖에 없다. 물론 매 챕터마다 팀이 변경되어 새로운 사람들을 만날 수 있었지만, 전에 함께했던 사람들이 조금씩 겹치다 보니 아예 얘기조차 나눠보지 못한 동료가 생기게 되었다. 그럼에도 다양한 사람들과 적극적으로 소통한 동료들을 보면 나의 아쉬운 점은 핑계에 불과했다는 생각이 든다. 따라서 그러지 못한 점이 가장 큰 아쉬움으로 남았다 😞

---

어쩌다보니 2024년 하반기의 긴 일기가 된 것 같다. 이렇게 회고를 작성하며 돌아보니 의미 있는 시간들로 가득했지만, 아쉬움이 남는 순간들도 있었다. 그러나 아쉬움을 후회로 남기기보다는 성장의 발판으로 삼기 위해 앞으로 더 나아갈 방향을 고민하게 되었다. 프로젝트를 진행하면서 정리하지 못한 부분들이 남아있는데, 추후에 정리해서 공유할 예정이다. (많관부)

🍀 2025년도 열심히 살아보자 ~!! 🍀