루퍼스 부트캠프를 마치며...

KwonMoYang·2026년 4월 26일

루퍼스 부트캠프 10주, 나는 무엇이 달라졌나 🌱

"이 시장에서 나는 경쟁력이 있는 사람일까?"
그 질문 하나로 시작된 10주의 기록.

들어가며

2025-12-31은 나에게 의미있는 날이였다.

25년도 한 해를 마무리하며 회고하고 있었는데 문득 이런 생각이 들었다.
어느새 3년이나 회사를 다녔는데, 나는 과연 이 시장에 경쟁력이 있는 사람일까? 같이 일하고 싶어하는 동료일까? 스스로를 되물어봐도 답이 나오지 않는 게 답답했다.

그래서 도전하고 싶었다. 더 많은 사람들을 만나보고 싶었다. 이런 견문을 넓히기 위해 노력하던 중 우연히 지인을 통해 루퍼스(Loopers)라는 부트캠프를 알게되었다.

변화한 나

루퍼스 부트캠프를 하며 나는 크게 3가지가 변했다.

기술에 대한 관점
학습에 대한 관점
소통에 대한 관점

🛠 기술에 대한 관점

이전에는 "좋은 기술이 좋은거다" 라는 마음가짐이 없지 않아 있었던 거 같다. 항상 트레이드오프를 고민한다고 자부해왔지만, 마음 속 어디선가는 기술을 뽐내고 활용하고 싶어하는 욕구가 너무 강했던 거 같다.

루퍼스에서 커머스 백엔드의 동시성 제어를 다루면서 이 생각이 결정적으로 바뀌었다.

처음엔 단순히 "동시성 문제는 락으로 해결하면 되지" 라고 생각했다. 그런데 실제로 재고 차감, 쿠폰 사용, 좋아요 카운트 세 가지 도메인을 마주하니, 같은 동시성 문제인데도 모두 다른 답을 요구한다는 걸 알게 됐다.

도메인	선택한 전략	이유
재고 차감	비관적 락 (`PESSIMISTIC_WRITE`)	초과 판매가 비즈니스에 치명적, 재시도가 무의미
쿠폰 사용	비관적 락 + `UniqueConstraint`	1회만 성공해야 하고, 중복 발급도 막아야 함
좋아요 카운트	원자적 업데이트 (`SET like_count = like_count + 1`)	순수 증감 연산, 모든 요청이 정당함

모든 기술에는 등장 배경이 있고,
비지니스와 도메인 특성 상 트레이드오프를 고민하여
현재 버릴 수 있는 것과 택해야 하는 것을 잘 구분할 줄 아는 능력이 중요하다.
세상에 나쁜 기술은 없다.

비관적 락이 무조건 무거운 게 아니고, 낙관적 락이 무조건 가벼운 게 아니다. 도메인의 경합 빈도, 실패의 비용, 재시도의 의미 — 이 세 가지를 저울에 올렸을 때 답이 도메인마다 갈렸다. 기술의 우열이 아니라, 문제와 해법의 궁합이라는 걸 손으로 부딪혀보고 나서야 알았다.

📚 학습에 대한 관점

수강 전의 나는 되게 지식을 깊게만 파고들려는 성향이 강한 사람이였다. 깊이우선탐색(?) 방식 공부법이라고 해야하나? 뭔가를 굉장히 딥하게 공부하려는 습관이 강한 사람이였다.

그런데 AI 시대를 격으며 계속 두려움이 생겼다. "내가 일주일을 들여 공부한 걸, AI는 5분이면 더 정확히 답하는데 의미가 있나?"

루퍼스에서 만난 증강 코딩(Augmented Coding) 워크플로우가 이 두려움에 답을 줬다. 핵심은 단 한 줄이었다.

방향성 및 주요 의사결정은 AI 가 제안만 할 수 있으며,
최종 승인된 사항을 기반으로 작업을 수행한다.

이전의 나는 AI를 "답을 알려주는 존재" 로 봤다. 그래서 AI가 잘하는 영역을 침범당한다고 느꼈다. 하지만 부트캠프에서는 AI를 "가설을 빠르게 제안해주는 동료" 로 다뤘다. 결정은 내가 하고, AI는 옵션을 펼쳐준다. 나의 가치는 "기억"이 아니라 "판단"에서 나온다는 걸 그제야 받아들였다.

이후 학습 방향이 완전히 바뀌었다.

모든 걸 외우려 하지 않는다 — 대신 "왜 이 선택지가 존재하는가" 를 이해한다.
깊이만 파지 않는다 — 의사결정에 필요한 만큼 넓게 본 다음, 필요할 때 깊이 들어간다.
AI에게 질문하기 전에 내 가설을 먼저 글로 적는다 — 비교할 기준이 있어야 AI 답변을 평가할 수 있으니까.

🤝 소통에 대한 관점

이전의 나는 "내 코드만 잘 짜면 된다" 는 생각이 강했다. 회사에서는 다른 사람의 코드를 깊이 들여다볼 일도, 내 결정의 이유를 글로 풀어낼 일도 생각보다 많지 않았다.

루퍼스는 달랐다. 모든 라운드 끝에 PR을 올리고, PR 본문에 의사결정 과정을 글로 적어야 했다. 처음엔 그게 시간 낭비처럼 느껴졌다. "코드 보면 다 보이는데 왜 또 적어?"

그런데 한번 적어보고 깨달았다. 글로 풀어낼 수 없는 결정은, 사실 내가 제대로 이해 못 한 결정이라는 것.

이걸 적는 순간, 내가 왜 그 결정을 내렸는지가 비로소 또렷해졌다. 기술 결정은 머릿속에서 정리하는 것과, 동료가 5분 안에 납득할 수 있게 풀어내는 게 완전히 다른 일이었다. 좋은 코드보다 어려운 건, 내 결정의 이유를 다른 사람이 납득할 수 있게 전달하는 일이라는 걸 여기서 처음 체감했다.

가장 인상 깊었던 프로젝트, 추천하고 싶은 이유

10주 동안 여러 라운드를 거쳤지만, 가장 기억에 남는 건 커머스 백엔드 — 동시성 제어 라운드다.

어떤 프로젝트였나

주제: 멀티 모듈 기반 커머스 백엔드 (commerce-api, commerce-batch, commerce-streamer)
사용 기술: Java 21 / Spring Boot 3.4.4 / MySQL 8 / Redis 7 (master-replica) / Kafka 3.5 (KRaft) / JPA + QueryDSL
아키텍처: 레이어드 아키텍처 + DIP (interfaces → application → domain ← infrastructure)
테스트 전략: Unit / Integration / E2E 3-tier + TestContainers

가장 좋았던 한 라운드 — "같은 동시성 문제, 다른 답 3개"

이 프로젝트의 백미는 재고·쿠폰·좋아요라는 세 개의 도메인을 다루며 각각 다른 동시성 전략을 선택해야 했던 라운드였다.

처음엔 모두 비관적 락으로 풀었다. 동작은 했다. 하지만 멘토님의 한마디가 있었다.

"세 도메인이 다 같은 비관적 락이면, 정말 그 세 도메인이 다 같은 성격이라는 뜻인가요?"

그 질문 하나로 다시 처음부터 분석을 시작했다. 결국 도달한 결론은 이거였다:

1️⃣ 재고 차감 → 비관적 락

재고는 Read 후 비즈니스 판단이 필요하다 (재고 부족 검증 → 금액 계산 → 주문 생성). Read와 Write 사이의 gap을 근본적으로 차단해야 했다. 추가로 productId 오름차순 정렬로 락 획득 순서를 통일해 데드락도 방지했다.

// productId 오름차순 정렬 → 데드락 방지
List<Long> sortedProductIds = orderItems.stream()
    .map(OrderItem::getProductId)
    .sorted()
    .toList();

2️⃣ 쿠폰 사용 → 비관적 락 + UniqueConstraint

쿠폰은 1회만 성공해야 하고, 재시도가 무의미하다. 게다가 발급 자체가 중복되면 안 되기 때문에 DB 레벨의 @UniqueConstraint(user_id, coupon_id)를 이중 방어로 걸었다.

3️⃣ 좋아요 카운트 → 원자적 업데이트 (전환 결정)

처음엔 좋아요도 낙관적 락(@Version)을 썼다. 그런데 동시성 테스트를 돌려보니 재시도 폭주가 발생했다. 원인을 추적하니, @Version은 엔티티 레벨이라 좋아요와 상품 수정이 같은 version을 경합하고 있었다. 서로 무관한 연산인데 False Conflict가 일어난 것이다.

그래서 원자적 업데이트로 갈아엎었다.

@Modifying
@Query("UPDATE ProductModel p SET p.likeCount = p.likeCount + 1 WHERE p.id = :id")
void incrementLikeCount(@Param("id") Long id);

JPA 변경 감지를 우회하니 @Version 자체가 트리거되지 않는다. 재시도 로직(retryOnOptimisticLock)도, 별도 트랜잭션 분리(LikeTransactionService)의 복잡한 경계도 전부 사라졌다. 복잡도가 한 단계 낮아진 것이다.

강의와 멘토링에서 좋았던 점

1. 답을 주지 않는 멘토링

루퍼스의 멘토링은 "이렇게 하세요" 가 아니라 "왜 그렇게 하셨어요?" 로 시작했다.

처음엔 답답했다. 빨리 정답을 알고 넘어가고 싶었으니까. 하지만 그 질문 하나가 나를 한참 더 깊게 생각하게 만들었고, 결국 내가 스스로 결론을 내릴 수 있게 됐다.

특히 인상 깊었던 멘토링 방식은 "여러 가지 설계 방식을 제안하며, 트레이드오프를 알려주고, 최종 결정은 개발자가 한다" 는 방식이 더 발전된 나를 만들 수 있게 되었다.

물고기를 주는 게 아니라 낚시법을 가르치는 멘토링,
정확히 그것이었다.

2. 깊이와 넓이의 균형

왜 이 기술이 등장했는가 (역사적 맥락)
어떤 문제를 해결하려 했는가 (설계 의도)
어떤 한계가 있는가 (트레이드오프)

이 세 가지를 항상 함께 짚어줬다. 그런 부분이 나에겐 기술에 대한 깊이와 이해감에 도움이 되었다.

3. AI 시대에 맞는 협업 가이드

루퍼스에서 가장 인상 깊었던 건 AI를 다루는 명시적인 원칙을 가르쳐줬다는 점이다.

- AI 가 임의 판단을 하지 않고, 방향성에 대한 제안 등을 진행할 수 있으나
  개발자의 승인을 받은 후 수행한다.
- AI 가 반복적인 동작을 하거나, 요청하지 않은 기능을 구현,
  테스트 삭제를 임의로 진행할 경우 개발자가 개입한다.

요즘 "AI에게 일을 시키는 법" 을 가르치는 곳은 많다. 하지만 "AI에게 휘둘리지 않는 법" 을 가르치는 곳은 드물다. 루퍼스는 후자에 무게를 뒀고, 그게 가장 시대에 맞는 가르침이었다.

4. 동료라는 가장 큰 자산

강의나 멘토님 못지않게 좋았던 건 함께한 동료들이었다.

서로 다른 배경에서 온 사람들이 같은 문제를 푸는 걸 옆에서 보는 경험. 내가 "이게 정답" 이라 믿었던 접근이 누군가에게는 완전히 다른 방식으로 보일 수 있다는 걸 매일 깨달았다. 그리고 함께 고민하고 공감해주는 문화를 통해 사람이 자산이라는 생각이 들곤 했다.

마치며

10주 전의 나는 "내가 시장에 통할까?" 라는 질문을 안고 있었다.

지금의 나는 그 질문에 나는 아직도 배우고 나아가야할 점들이 많기에 아주 명쾌한 답을 가지고 있다고는 말할 수 없다고 생각한다. 다만 답을 찾아가는 방법은 알게 됐다.

비유하자면 이전의 나는 좋은 칼을 모으는 데 집중하는 요리사였다. 칼이 좋으면 음식이 좋아질 거라 믿었다. 지금의 나는, 재료와 손님에 따라 어떤 칼을 들지 결정하는 요리사가 되고 싶다. 손님과 음식에 맞아야 좋은 도구가 된다.

기술을 바라보는 시선, 학습하는 방식, 동료와 소통하는 태도. 이 세 가지가 단단해진 것만으로도 나는 출발선이 달라졌다고 느낀다.

누군가 나처럼 "이대로 괜찮을까" 를 매일 자문하고 있다면,
그 답답함을 풀 수 있는 가장 좋은 방법은 익숙한 자리에서 한 발 나오는 것이라고 말해주고 싶다.

루퍼스에서의 10주는, 저에게 그 한 걸음이었습니다.
도움이 필요하시면 언제든지 댓글 남겨주세요!
루퍼스에 참여하시고 싶다면? 추천인 래퍼럴 코드입력을 통해 할인 받으실 수 있습니다! -> LJRY2

KwonMoYang

Dot Your moment.

이전 포스트

WIL (랭킹 시스템 설계: Redis ZSET부터 Spring Batch + MV까지)

다음 포스트