Loop:Pak - 10주간의 회고

TL;DR

10주 동안의 루프팩은 단순히 기술 스택을 익히는 시간이 아니었다.
"어떻게 하면 더 나은 설계와 판단을 할 수 있을까?"를 계속 고민하며, 내 사고방식 자체가 바뀌어 갔던 여정이었다.

 

 

Loop:PAK - 새로운 코딩 교육의 시작, 루퍼스에서 곧 만나요!

10주간의 성장 회고: 기능 구현을 넘어 사고방식으로

Loopers에서 2025.07.12(토) ~ 2025.09.20(토) 동안 진행한 루프팩 백엔드 vol.1 멘토링이 완료되었다.

10주간 매주 정해진 주제에 맞춰 학습하고 실습을 진행하며, 단순한 기능 구현을 넘어 사고방식·문제해결·설계적 판단을 훈련하는 과정이었다.

내가 이 멘토링에 참여하게 된 이유

현업에서 기본적인 기능 구현에는 익숙해졌지만, "왜 이렇게 설계해야 하는가?"라는 질문에 답하기 어려운 순간이 많았다.

❓ 단순히 돌아가는 코드가 아니라 성능과 확장성을 고려한 코드
❓ 서비스가 커져도 유지보수가 가능한 구조적 설계
❓ 문제 상황에서 흔들리지 않는 트레이드오프 판단 능력

 

이 세 가지가 나에게 부족하다고 느꼈고, 그 공백을 메우고 싶어 멘토링에 참여하게 되었다.

내가 세운 목표

멘토링을 통해 달성하려던 목표는 명확했다.

 

1. 사고방식의 전환
   • "이 기능을 어떻게 만들까?"가 아니라 "이 기능이 어떤 문제를 해결하고, 어떤 제약 속에서 최적의 선택일까?"를 먼저 묻는 습관을 들이기.
2. 실전 감각 키우기
   • 트랜잭션, 락, 이벤트, 캐시, 배치 등 실제 서비스에서 자주 맞닥뜨리는 주제를 깊게 다루며 바로 현업에 적용할 수 있는 경험치 쌓기.
3. 테스트 코드의 가치 체득
   • 직접 기능을 테스트하면서만 문제를 확인하던 방식에서 벗어나, 테스트 코드를 통해 비효율성과 서비스 불안정성을 줄이기.
   • 동작을 보장하고 안정적인 리팩토링이 가능한 구조를 만들어 개발 효율성과 안정성을 동시에 확보하기.
4. 포트폴리오로 남기기
   • 단순히 결과물을 모으는 게 아니라, 내가 어떤 사고 과정을 거쳐 선택을 했는지를 정리해 앞으로의 성장을 점검할 수 있는 기준점으로 만들기.

전체 여정 요약

1~3주차: 단순 구현을 넘어

초반에는 그냥 기능을 만들고 돌아가면 됐다고 생각했다.
그런데 멘토링에서 강조한 건 "그게 왜 이렇게 설계됐는지 설명할 수 있어야 한다"는 거였다.
그래서 개발을 시작할 때 구현부터 시작하는 것이 아니라 TDD로 객체 설계부터 시작하고, 도메인 모델링과 계층 분리를 통해 구조적인 고민을 했다.
처음엔 답답했지만, DIP 같은 원칙을 스프링 구조에 녹여내면서 "아, 이렇게 해야 나중에 코드가 흔들리지 않겠구나"를 체감할 수 있었다.

 

4~6주차: 실무 문제랑 정면으로 부딪히기

이 시기엔 훨씬 더 현실적인 문제를 다뤘다. 
재고가 꼬인다거나, 동시성 충돌로 데이터가 뒤틀리는 상황 같은 것들. 그냥 @Transactional로는 해결이 안 됐다.
락을 걸고 트랜잭션을 세밀하게 다루면서 문제를 풀어갔다. 
또 느린 쿼리를 캐시와 인덱스로 최적화하고, 연관된 서비스가 죽더라도 전체가 멈추지 않게 서킷 브레이커도 붙였다.
이 과정에서 "내 코드가 안전하다고 끝이 아니다. 서비스 전체가 버틸 수 있어야 한다"는 걸 뼈저리게 느꼈다.

 

7~8주차: 구조를 느슨하게 푸는 법

점점 기능이 늘어나면서, 모든 걸 하나의 트랜잭션 안에 넣는 방식이 한계에 부딪혔다.
특히 후처리나 랭킹 계산 같은 건 묶어두면 답이 없었다.
그래서 도메인 이벤트를 중심으로 구조를 느슨하게 바꾸고, 일부 흐름을 비동기로 전환했다.

이 과정에서 "이벤트는 사실(Fact)을 알리는 것, 커맨드는 의도를 전달하는 것"이라는 차이를 체감할 수 있었다.
즉, 주문이 완료되었다는 이벤트는 여러 후처리로 흘려보내고, 특정 동작을 강제해야 할 때는 커맨드로 명확히 지시하는 식이다.
이 구분 덕분에 서비스 간 결합이 줄었고, 각 기능을 더 독립적으로 확장할 수 있었다.

 

9~10주차: 이제는 설명할 수 있다

마지막엔 단순 CRUD에서 벗어나, 내가 만든 시스템 전체를 설계하고 설명하는 단계까지 왔다.
랭킹 집계를 위해 배치를 만들고, 조회 성능을 위해 Materialized View를 도입했다. 
모듈을 분리하고 스케줄을 돌려보면서 "이제는 이걸 어떻게 운영할지까지 말할 수 있겠다"는 확신이 생겼다.

가장 큰 전환점

가장 큰 전환점은 단순히 “코드가 돌아가면 끝”이 아니라는 걸 깨달은 순간들이었다.

 

1주 차 테스트 경험

실무에서는 테스트 코드를 거의 작성하지 않았는데, 1주 차에 처음으로 내가 만든 코드에 대해 테스트 코드를 직접 작성했다.
그 과정에서 코드와 서비스의 안전성을 보장할 수 있었고, 안심하고 리팩토링이나 추가 개발을 이어갈 수 있었다.
자연스럽게 "구현"이 우선이 아니라, "설계와 테스트"가 먼저라는 개발 흐름으로 사고가 전환되었다.

 

4주차 트랜잭션/락 학습

단순히 @Transactional 하나로 끝나는 게 아니라, 동시성 문제와 락 전략, 그리고 성능 사이에서 균형을 잡아야 한다는 사실을 알게 되었다.
예를 들어, 재고 수량 정합성을 지키려면 단순 트랜잭션이 아니라 상황에 맞는 락이나 격리 수준을 고민해야 했고, 그 과정에서 데이터 안정성과 성능 사이의 트레이드오프를 구체적으로 체감할 수 있었다.

 

7주 차 이벤트 분리 경험

한 서비스 안에 모든 로직을 넣는 대신, 이벤트 기반으로 분리했을 때 확장성과 유연성이 생긴다는 걸 몸으로 느꼈다.
특히 중요한 깨달음은, 단순히 로직을 분리한다고 해서 트랜잭션까지 자동으로 분리되는 것은 아니라는 점이었다.
이벤트를 통해 도메인 결합도를 느슨하게 만드는 방법을 배우면서, 어떻게 하면 서비스 간 의존성을 줄이고 독립적으로 진화할 수 있는지 감을 잡을 수 있었다.

 

이 경험들 이후부터는 늘 "이 설계가 지금만 맞는가, 미래에도 확장 가능한가?"를 먼저 자문하게 되었다.

내가 이제 할 수 있는 것들

10주간의 과정을 통해, 이제는 단순히 “코드를 짜는 사람”이 아니라 구조와 의도를 설명할 수 있는 개발자가 되었다.

 

• 단순 CRUD 구현이 아니라, 설계 의도를 설명하며 구조적으로 개발할 수 있다.
• 테스트 코드를 기반으로 안정적인 리팩토링과 기능 확장을 할 수 있다.
• 트랜잭션과 락 전략을 상황에 맞게 선택하며, 데이터 정합성과 성능 사이에서 균형을 맞출 수 있다.
• 도메인 이벤트와 비동기 메시징을 통해 서비스 간 결합도를 낮추고 확장 가능한 아키텍처를 설계할 수 있다.
• 배치, 캐시, 장애 대응(Resilience4j)까지 고려하여 운영 가능한 시스템을 그려볼 수 있다.

즉, 이제는 “돌아가는 코드”가 아니라 설계·테스트·확장성까지 고려된 시스템을 만들 수 있게 되었다.

Next Step: 앞으로의 학습 방향

이번 멘토링을 통해 기초 체력은 쌓았지만, 아직 더 깊이 다루어야 할 부분이 많다. 앞으로는 아래와 같은 학습을 이어가고 싶다.

• 테스트 코드 심화
  • 단위 테스트뿐만 아니라 통합 테스트, 인수 테스트까지 포함해 서비스 전체를 검증할 수 있는 테스트 전략을 다듬고 싶다.
• 아키텍처 패턴 학습
  • CQRS, 이벤트 소싱, 헥사고날 아키텍처 등 다양한 패턴을 실제 예제 프로젝트에 적용하면서, **도메인 주도 설계(DDD)**와 접목해 보고 싶다.
• 운영 환경 경험 쌓기
  • 지금까지는 로컬/학습 환경에 가까웠다. 앞으로는 Kubernetes, 클라우드 인프라, 모니터링/로깅 시스템까지 포함해, 실제로 운영 가능한 환경을 직접 세팅하고 돌려보는 경험을 하고 싶다.
• 성능 최적화와 데이터 처리
  • 대규모 트래픽 상황에서 캐시, 배치, 스트리밍 처리를 어떻게 조합할지, 성능을 수치로 증명할 수 있는 역량을 기르고 싶다.

결국 내 목표는 단순히 기능을 구현하는 것이 아니라, 문제를 구조적으로 해결하고 팀과 함께 확장 가능한 시스템을 설계할 수 있는 개발자로 성장하는 것이다.

마무리

10주간의 멘토링은 단순히 기능 구현 능력을 키우는 시간이 아니었다.

그보다 더 큰 의미는 문제를 바라보는 시각을 바꾸고, Trade-off를 고민하는 습관, 그리고 확장성을 고려한 설계의 관점을 얻은 데 있었다.

 

이제는 단순히 "어떻게 구현할까?"에서 멈추지 않고, "왜 이렇게 설계해야 하는가?"까지 설명할 수 있는 개발자로 한 걸음 나아가게 되었다.

앞으로도 이 기준점을 바탕으로 새로운 문제를 만날 때마다 한층 더 단단한 해법을 찾아갈 것이다.

 

덧붙여, 이번 멘토링 프로그램은 여기서 끝이 아니다.

루프팩 백엔드 vol.2가 곧 모집될 예정이라고 한다.

이번 과정을 통해 성장할 수 있었던 것처럼, 다음 기수를 고민하는 분들에게도 분명 좋은 기회가 될 것 같다.

 

교육 과정 | Loop:Pak