2025년 회고, 백엔드 개발로 재취업하기까지

 

 다사다난했던 한 해의 끝자락에서 첫 회고를 시작합니다. 퇴사 후 "설계와 테스트 역량을 키우자"는 목표를 세우고 달성하기 위해 보낸 1년이었습니다. 부족했던 기초를 다지고 성장하기 위해 다양한 교육 플랫폼을 활용하며 지식을 재정비했습니다. 무엇보다 큰 변화는 스스로의 틀을 깨고 나온 것입니다. 내향형(I)임에도 정적인 학습에만 머물지 않고 외부 스터디, 커뮤니티, 세미나에 참여하며 식견을 넓히기 위해 노력했습니다.

 

2025년의 구체적인 활동 기록은 아래와 같습니다.

 

[주요 학습 및 활동 기록]

• 스터디 및 심화 학습
  • 토비의 리팩터링 스터디 (1~4월)
  • 부산 IT 모각코 알고리즘 스터디 (6~8월)
  • 도메인 주도 설계의 사실과 오해 11기 참여 (10월)
• 오픈소스 및 대외 활동
  • 전자정부 프레임워크 컨트리뷰터 참여
  • 한빛미디어 '나는 리뷰어다' 연간 활동 종료
• 기술 세미나 참관
  • Apache Airflow
  • C# .NET v10
  • DevFest GDG Busan 2025

 

12주 간의 리팩터링 스터디 : 홀로서기와 함께하기의 균형

훌륭한 개발자는 책이나 영상 속에만 존재하고 현실에는 만날 기회가 없을 줄 알았습니다. 올해 1월에 시작했던 "토비의 리팩터링 읽기 모임"은 그런 저의 편견을 깨고, 개발자로서 살아갈 동력을 얻게 해준 소중한 전환점이 되었습니다.

 

• 자기주도적 학습의 정수: "저는 일절 개입하지 않겠습니다"는 선언과 스터디 가이드 아래 12주간의 하드한 여정이 이어졌습니다. 단위 테스트를 우선 작성하고 AI를 보조 도구로 활용하며 리팩터링 사이클을 반복했습니다. 낯선 방식이었지만, 테스트 코드가 주는 빠른 피드백과 안정성을 몸소 체험하며 막연했던 '캡슐화의 본질'과 '상속보다 합성'의 의미를 코드로써 명확히 설명할 수 있게 되었습니다.
• 기술을 넘어선 회복의 경험: 2024년은 퇴사와 치료를 병행하며 홀로 AI와 대화하며 자기계발했던 힘든 시기였습니다. 1년 만에 처음 세상 밖으로 나와 참여한 이 활동에서, 끝까지 남은 약 14명의 스터디원과 나눈 완주의 성취감은 잊을 수 없는 기억으로 남았습니다.
• 성장의 이정표: 부족한 저를 편견 없이 평범하게 대해주신 모두 덕분에 큰 위안을 얻었습니다. 이 과정을 통해 기술적 테크닉뿐만 아니라, 스스로를 단련하는 법과 제가 받은 선의를 다른 이에게도 전달하는 개발자가 되고 싶다는 새로운 이정표를 찾았습니다.

 

https://github.com/ljw1126/refactoring2

GitHub - ljw1126/refactoring2: 리팩터링 2판 스터디 (12주)

 

https://dev-ljw1126.tistory.com/483

[개발 도서] 리팩터링 2판 - 스터디 회고 (Java, JUnit5)

 

 

도메인 주도 설계의 사실과 오해 11기 : 처음으로 만난 진짜 시니어

 현재 다니고 있는 회사의 2차 구현 과제를 앞두고, 지금이 아니면 강의를 들을 기회가 없을 것 같다고 생각해 무리해서 서울행을 결정했습니다. 당일 새벽 5시에 차가운 공기를 가르며 출발할 때 느꼈던 떨림은 아마도 새로운 목표를 만날 것 같다는 설렘이었던 것 같습니다.

 

• 본질을 꿰뚫는 8시간의 몰입: 오전 10시부터 시작된 강의에서 조영호님은 소프트웨어의 본질적인 문제인 '복잡성'을 해결하기 위해 DDD가 어떻게 탄생했는지를 풀어내셨습니다. 8시간 동안 800페이지에 달하는 방대한 자료를 거의 보지 않고 설명하는 모습에 감탄이 절로 나왔고, 물흐르는 듯한 설명을 들으며 강의에 몰입할 수 있었습니다. 특히 20년 넘은 에릭 에반스의 원서를 매년 다시 보며 새로운 것을 깨닫는다는 말씀에서, IT 업계에서 유명한 시니어도 멈추지 않고 학습한다는 사실에 깊은 자극을 받았습니다.
• 기술보다 빛난 겸손의 태도: 쉬는 시간, 쏟아지는 질문들에 "모든 경험을 다 해본 것은 아니기에 모르는 부분은 답변드리기 어려운 점 양해 부탁드립니다"며 고개를 숙이시는 모습에서 처음으로 '진짜 개발자'의 모습을 보았습니다. 실력자임에도 자신의 부족함을 인정하는 겸손함은 기술적인 지식보다 더 큰 가르침으로 다가왔습니다.
• 잊을 수 없는 친절함: 강의가 끝난 후 마지막으로 남아 이어진 짧은 스몰토크에서 부산에서 올라온 저를 친절히 배려해 주시는 모습에 깊은 감동을 받았습니다. 그날 강의장을 나오니 비가 쏟아져 옷은 흠뻑 젖었지만, 마음만은 포근했던거 같습니다. 긴 하루의 피로조차 잊게 할 만큼 값진, 제 다음 목표를 확신하게 된 시간이었습니다.

 

 

두 번의 구현 과제와 재취업 : 낯선 기술 스택 속에서도 길을 잃지 않았던 이유 (*긴 글 주의)

 6년 차 Java/Spring 개발자로서 마주한 국내 취업 시장은 결코 녹록지 않았습니다. 실무를 하면서 자기계발을 지속하는 것이 현실적이라 판단하여 익숙한 기술 스택을 고집하기보단 '어떤 환경에서도 빠르게 적응하고 성과를 내는 개발자'가 되기 위해 정면 돌파를 선택했습니다. 그 결과 도메인의 특수성과 낯선 기술 스택을 동시에 경험할 수 있는 현재의 자체 서비스 회사에 취업했습니다.

 

 정직원 전환 과정에서 총 두 번의 구현 과제와 PPT 발표를 거쳤습니다. 생소한 프레임워크와 언어로 과제를 수행해야 하는 불안함도 있었지만, 2년간 갈고닦은 '기본기'를 믿고 도전정신으로 임했습니다.

• 1차 구현 과제 : Node.js, TypeScript 기반 로그 파일 검사 기능 구현 (1주 소요) 
  • + Jest 활용 
  • 📚 단위 테스트의 기술 
• 2차 구현 과제 : C# .NET Core 기반 REST API 설계 (with TDD, 2주 소요)
  • + xUnit, Moq, SQLite, Testcontainers 활용
  • 📚 Unit Testing (단위 테스트), 🏠 "기억보단 기록을" 기술 블로그 참고

과제 요구사항에는 없었으나, 문제 도메인에 대한 이해도를 높이고 설계와 리팩터링을 반복하기 위해 자발적으로 테스트 프레임워크를 도입했습니다. 테스트 코드가 주는 안정감과 빠른 피드백 덕분에 생소한 기술 스택 속에서도 요구사항을 올바르게 구현하고 코드 구조를 개선할 수 있었습니다.

 

출처 교보문고, 알라딘

 

 

[예상치 못한 변화, 다시 찾은 기술서]

 한 가지 해프닝으로 1차 과제를 마칠 무렵 예상치 못한 변수가 생겼습니다. 퇴사했던 시니어 개발자의 복귀로 팀 배치가 변경되면서, 당초 준비하던 Node.js가 아닌 전혀 경험이 없던 C# .NET 솔루션 팀으로 가게 된 것입니다. 이에 따라 2차 과제를 하게 되었고, 생소한 C# .NET 환경에서 TDD(테스트 주도 개발)로 과제 구현할 것을 요구했습니다.

 

 살아남기 위해 기억을 더듬었고 예전에 C# 기반이라 읽기를 포기했던 『단위 테스트(Unit Testing)』 도서가 생각이 났습니다. 퇴근 후 즉시 책을 구매했고, 추석 연휴를 반납한 채 완독과 예제 학습에 몰입했습니다. 이때 책에서 다룬 'SQLite 기반의 통합 테스트' 예제는 JPA와 대비되는 EF Core의 메커니즘을 학습 테스트로 빠르게 이해하는 데 결정적인 도움이 되었습니다.

https://github.com/ljw1126/unit-testing

GitHub - ljw1126/unit-testing: 단위 테스트(블라디미르 코리코프) 도서 예제 학습

 

https://mammoth-anteater-cf1.notion.site/TDD-with-Java-18-a95440b8e21e4350aee5e58bb3185c70?source=copy_link

TDD, 클린 코드 with Java 18기 | Notion

 

 

 

[Spring vs .NET Core: 학습 테스트로 발견한 기술적 통찰]

 낯선 .NET 환경에서 과제를 수행하며, 익숙한 Spring 프레임워크와 대조해보는 과정은 매우 흥미로웠습니다. 두 프레임워크의 철학적 차이를 실전 코드를 통해 체감하며 정리한 내용은 다음과 같습니다.

 

1. 선언적 방식과 명시적 구현: 트랜잭션 관리

 Spring에서는 @Transactional이라는 강력한 선언적 방식을 사용하지만, .NET Core에서는 비즈니스 로직에 트랜잭션을 명시적으로 구현해 처리하는 경우가 많았습니다. 이로 인해 서비스 레이어를 구현할 때 핵심 로직과 부가 관심사가 섞여 테스트를 작성하기 어려운 문제가 생겼습니다. 비즈니스 로직의 순수성을 지키기 위해 데코레이터 패턴(Decorator Pattern)을 활용하여 트랜잭션이라는 '부가 관심사'를 깔끔하게 분리했고, 결과적으로 단위 테스트와 통합 테스트를 작성할 수 있었습니다.

 

2. ORM의 유연성: JPA vs EF Core

 JPA가 어노테이션 기반의 설정을 제공한다면, EF Core는 네이밍 컨벤션, 어트리뷰트, Fluent API라는 세 가지 선택지를 제공했습니다.

• 처음에는 JPA와 비슷한 EF Core의 Attribute 방식으로 Entity 연관 관계 설정 시도했으나 런타임 에러가 발생했습니다.
• 공식 문서를 찾아본 결과, Attribute 방식으로 연관 관계 설정할 때 기본적으로 PK를 찾게 되어 있어 PK가 아닌 속성을 FK로 설정할 수 없다는 걸 알게 되었습니다.
• 그래서 Fluent API 설정 방식을 선택했고, 이를 통해 엔티티 간의 세밀한 연관 관계 설정을 제어하며 문제를 해결했습니다.

 

3. DI 컨테이너와 서비스 등록의 철학

 Spring이 IoC, DI를 제공한다면, .NET Core는 '명시적인 제어'를 통해 설계의 투명성과 유연성을 제공합니다

• Spring (Bean): 자기 주장이 강한(Opinionated) 프레임워크 
  • @ComponentScan을 통해 빈을 자동으로 탐색하고 스프링 컨테이너에 등록 후 런타임에 DI 해줍니다.
  • "내가 다 찾아 관리해 놓을 테니 너는 비즈니스에만 집중해"
• .NET Core (Service): 명시적이고 자율적인(Explicit & Flexible) 프레임워크
  
  • 서비스 등록(Service Registration)과 스코프(Scope) 설정을 개발자가 직접 명시해야 합니다.
  • 개발자가 의존성 관계를 한눈에 파악하고 통제할 수 있도록 '설계의 주도권'을 넘겨주는 방식입니다.
  • "네가 쓸 것들만 정확히 나한테 알려줘. 나머진 알아서 해줄게"

 

4. 명시적인 제어가 주는 즐거움: xUnit vs JUnit5 

 처음 .NET 환경에서 서비스를 일일이 명시적으로 등록할 때는 모든 것이 자동으로 처리되던 Spring의 방식이 몹시 그리웠습니다. 하지만 시간이 지날수록 이는 불편함이 아닌, .NET 진영이 가진 독특한 설계 철학과 장점으로 다가왔습니다.

 

4-1. 추상화된 애너테이션 이면의 원리를 마주하다.

 xUnit을 사용해 테스트를 작성하며 가장 흥미로웠던 점은 생성자나 인터페이스 후킹(Hooking)을 통해 호출 순서를 직접 제어해야 한다는 것이었습니다. JUnit5에서 @BeforeEach, @AfterEach라는 애너테이션 하나로 해결되던 라이프사이클을 직접 관리하는 과정은 때로 피로하기도 했지만, 동시에 깊은 깨달음을 주었습니다. 편리함이라는 장막 뒤에서 프레임워크가 대신 수행해주던 핵심 동작들을 수면 위로 끌어올려 직접 만져보는 기분이었고, 이는 곧 프레임워크의 동작 원리를 본질적으로 이해하는 계기가 되었습니다.

 

4-2. 효율적인 통합 테스트: 필요한 것만 담는 유연함

@SpringBootTest를 사용할 때 전체 컨텍스트가 load 되다 보니, 테스트하고 싶지 않은 Bean까지 등록되어 설정 오류를 막기 위해 @MockBean을 처리해야 하는 경험도 했었습니다. 반면 .NET의 환경에서는 테스트하고자 하는 서비스와 그 의존성만을 정밀하게 관리할 수 있었습니다. 불필요한 리소스 낭비 없이 딱 필요한 만큼의 컨텍스트만 구성하여 테스트를 진행할 수 있다는 점은 효율성 측면에서 강점으로 느껴졌습니다.

 

 결국 .NET은 개발자에게 더 많은 고민을 요구하지만, 그만큼 시스템의 동작을 투명하게 이해하고 통제할 수 있는 '설계의 주도권'을 돌려주는 프레임워크였습니다.

 

 

 아래는 두번째 과제 저장소입니다. 더미 데이터, 로컬 테스트 환경 위주에 테이블부터 비즈니스 로직 구조도 모두 다르기 때문에 링크 첨부합니다. 과제 끝난 후 Testcontainers로 SQL Server 올려 서비스 통합 테스트를 작성했고, 테스트 간 격리성 보장 문제를 해결하기 위해 Reswpan 패키지 활용하여 데이터 초기화했습니다. (그외 Test Data Builder, Object Mother Pattern 등)

 

https://github.com/ljw1126/ShipParticularsApi/tree/master/ShipParticularsApi.Tests/Tests

ShipParticularsApi/ShipParticularsApi.Tests/Tests at master · ljw1126/ShipParticularsApi

 

 

2026년 목표

2025년 잔디 심기

 

 치열했던 기간을 모두 마친 11월과 12월은 잠시 숨을 고르는 시간이었습니다. 그간 묵묵히 버텨온 스스로에게 작은 보상을 건네기도 하고, 다시 월급을 받아 부모님께 용돈을 드리는 소소하지만 소중한 행복을 누렸습니다. 끝이 보이지 않던 공백기를 지나 다시 일상의 궤도에 진입했다는 안도감이 비로소 실감 났던 시기였습니다.

 

 돌이켜보면 늘 스스로가 부족하다는 생각에 쉼 없이 채찍질만 해왔던 것 같습니다. 하지만 올 한 해 다양한 스터디와 세미나, 그리고 AI와 함께하는 자기계발을 통해 이제는 어떻게 성장해야 하는지, 어디로 나아가야 하는지에 대한 방향을 명확히 잡았습니다. 조급함보다는 확신을 가지고, 실무와 성장의 균형을 맞추며 2026년에도 꾸준히 저만의 속도로 걸어가 보려 합니다.

 

 그 새로운 시작으로 다시 한번 NextStep 교육을 신청했습니다. 적지 않은 비용과 시간을 투자하는 만큼, 그 시간이 헛되지 않도록 열심히 임할 생각입니다. 2025년에 쌓은 단단한 기초 위에, 2026년에는 실무에서의 깊이를 더해 더욱 신뢰받는 개발자로 거듭나기를 스스로에게 약속해 봅니다

 

+"도메인 주도 설계의 사실과 오해 - 2부" 강의가 최근에 하고 계시다는 소식을 접했는데, 2026년에도 강의를 들으러 갈 수 있도록 꾸준히 노력해야겠다. 

코팅해서 이쁘게 간직하고 있습니다