본문 바로가기
📦 아카이브

탑다운 방식의 백엔드 학습과 앞으로의 방향에 대해

by Gukin 2025. 9. 18.

이번 주 토요일(9월 20일)을 기점으로 지난 10주간 진행했던 부트캠프를 마무리하고, 앞으로 스스로 학습해 나아가야 한다. 이 글에서는 각 주차별로 무엇을 했고, 앞으로 계획을 대해 고민해보려고 한다.
 

시작하기 전

보통의 교육 마케팅은 "공포 마케팅"이 주를 이룬다.

"이거 안들으면 큰일나요"
"몇년 차에 이걸 모르면 안됩니다"
"이 내용 모르면 시험에서 광탈합니다"

성인 교육은 어떻게 마케팅 해야할까? | 향로 (2025)

 
하루하루 LLM의 발전으로 AI의 코드 작성, 분석, 아키텍처 설계 능력이 압도적인 속도로 진화하고 있다. 실제로 회사에서는 업무에 클로드 코드를 도입하려는 시도를 하고 있고, 개인적으로는 Gemini-cli, GPT를 통해 테스트 코드 작성과 설계 그리고 학습을 하고 있다. 앞으로 의사결정의 주체가 AI에게 넘어가기 전 까지는 사람의 역할이 분명해보인다. 그래서 요즘은 의도하지 않게 코드작성 능력보다는 사고력과 설계능력에 초점을 맞춰서 학습을 하고 있다.
 
이 부트캠프를 시작하기 전 마음가짐을 돌이켜 보았다. "내가 사용하는 방식, 생각하는 방식이 이게 맞아?" 적어도 3곳의 기업에서 일한 멘토들을 통해서 이 질문 답해보고 싶었다. 상업적인 마케팅이 심해서 결제하기 까지 상당히 오래걸렸다.
 
대상 독자는 유사한 프로그램에 대해 결제를 고민하고 위 질문이 궁금한 사람들은 읽어보면 좋을것 같다. 객관적으로 적어두었고 해당 프로그램에서 레퍼럴코드라고 할인 코드를 주었는데 그런걸 공유할 생각은 딱히 없다. 필요한 사람들은 다른 사람의 글을 찾아서 사용하시길!
 
 

주차별 생각의 변화와 추가 학습 키워드

1주차 : Test Driven Development

유닛, 통합, e2e 테스트에 대해 고민해볼 수 있었다. "개발 과정에서 테스트는 필수고 TDD는 선택이다. 하지만 모든 테스트를 작성하려고 하지 말자"는 확고한 관념이 생겼다.
 
실무에서도 테스트를 자주 작성하는데 TDD가 도움되는 상황이 있고, 비효율적인 상황이 있음을 경험할 수 있었다. 인사 도메인 처럼 법적 기준이 명확한 경우, 알고리즘의 결과가 명확한 경우 테스트 코드를 미리 작성하는 방법은 분명 도움된다. 반면에, 스타트업 처럼 빠르게 변화에 대응하고 요구사항을 수용해야하는 경우 오히려 발목을 잡는 경우도 있다.
 
테스트 작성 기준도 분명해졌다. 이미 보장된 라이브러리, 프레임워크는 테스트 하지 않는다. JPA, Resilience4J와 같은 프레임워크나 라이브러리, 모듈에 대해 작성할 필요 아니 우선순위가 낮다. 테스트 커버리지를 채우기 위해 컨트롤러까지 모두 테스트코드를 작성할 필요도 없다. 유스케이스를 기반으로 해피 케이스 1개, 엣지 케이스 위주로 작성하는게 좋았다.
 
특히나 이슈가 발생해서 발견하게 되는 케이스들을 테스트 코드 작성하고 해당 케이스를 분명하게 DisplayName 어노테이션에 명세를 해주면 큰 도움이 되었다. 이렇게 잘 작성된 케이스는 회귀테스트에서 빛을 발휘했다. 실무에서 특히나 사이드이펙트로 고생을 하고 있는데 어느정도 해결책이된 상태이다.
 
테스트는 사실 범위가 넓은 키워드다. 테스트코드에서 벗어나서 다음과 같은 범위로 확장해보면 좋을것 같다 :
 

  • 시스템 아키텍처 레벨 테스트 : 카오스, 스모크, 회귀
  • 비기능적 테스트 : 퍼포먼스, 스케일, 리질리언스, 시큐리티
  • 운영/릴리즈 테스트 : 카나리, A/B, 모니터링, 백업

이중에서 비기능적 테스트 부터 시작해보려고 한다.
 
 

2주차 : Software Design

"앞으로 가장 중요한 주제를 갖는 주차가 무엇일까?" 질문에 답하자면 1주차, 2주차라고 생각한다. 설계를 하고 테스트 환경을 갖춰두면 그 안에서 요구사항에 맞는 구현을 AI가 사람보다 빠르게 해낼 수 있으니까.
 
여기서 배운 설계방법, 툴은 유용해서 회사에서 적극적으로 사용중이다. 특히 Mermaid를 이용하여 마크다운에 작성하는것이다. 이게 좋은 이유는 AI 이식성이 훌륭해서다. LLM으로 부터 Mermaid로 다이어그램을 뽑아내거나 인풋으로 줘서 아키텍처를 전달해줄 수 있다.
 
관련해서 책도 읽어보려고 개론서 느낌으로 아래 책을 구매해서 조금씩 읽고 있다. 로버트 마틴이 전달하고자 하는 메시지는 뚜렷했다. "보지도 않을 다이어그램은 시간 들여서 그리지 말자. 다이어그램은 수명이 짧고 그 순간 팀원들과의 생각을 맞추기 위한 일시적인 도구"로 요약할 수 있다.

나는 아직 대학교 교직원 계정이 있어서 학산도서관에 1년마다 30권정도? 주문할 수 있다. 주로 전자책을 주문하는데 안타깝게도 인사이트 출판사의 모든 책들은 입수불가다. 아마도 저작권 관점에서 관리하기 어렵다는게 GPT의 추론? 이 책을 제값주고 산게 살짝 아깝다는 생각이 들고 교보전자책 어플의 메모리 일부로 낭비되고 있다. 모든책을 다 읽기에는 인생이 너무 짧다. 파이썬을 하자!
 
앞으로 목표는 시각화 자체는 커뮤니케이션을 효율적으로 하기 위한 도구이기 때문에 어떻게 하면 효율적으로 커뮤니케이션을 할 수 있을지 고민하고 UML에 익숙해지는 시간을 갖는게 좋을것 같다. 블로그 글을 작성할때 추후에 나에게 던질 메시지를 생각한다면 잘 그려두는게 빠른 이해를 하는데 도움되지 않을까?
 
 

3주차 : Domain Modeling & Development

3주차를 돌이켜보니 주차별로 큼지막한 주제들로 구성되었고 각각 겉핧기만 했다는 생각도 든다. 도메인 모델링도 상당히 큰 분야인데, 트랜잭션 스크립트 방식을 실무에서 사용하는 입장에서 객체 지향적 사고를 갖기는 너무 어렵다. 디자인패턴의 유용함은 이해할 수 있는데 팀을 운영하는 입장이라면 제대로된 구루가 없이 도메인 주도 개발을 구현하고 유지보수하기는 상당히 어렵지 않을까 생각된다.
 
메시지를 주고 받는 책임을 나누고 역할을 관리한다는 것은 쉽지 않다. 이 부트캠프 하기 전에 책 한권을 구매해서 마음잡고 공부하기로 했는데 무슨 책이냐면
 

 
 
이 책의 프리퀄 느낌의 책도 읽은적이 있었는데 쉽지 않다. 지은이의 의도는 알겠지만 같은 메시지를 656 페이지에 걸쳐서 반복해서 말한다. 살짝 추상적이면서도 천천히 고민하면서 읽어야 하는 개념서 느낌인데 북스터디를 하지 않으면 완독하기 어려울것 같다. 이 주차에서 배운 내용은 다른 주차에 비해 실용성이 낮아서(지극히 개인적인 판단) 나중에 학습을 해보는 것으로.
 
마지막으로 3주차에는 VO관련된 글을 썼는데 식별자에 VO를 적용했을때 처음에는 유효성검증의 유용함에 빠져들었지만 곧 단점에 허우적 거려서 모두 걷어내버렸다. 이걸 직접 PoC에서 경험하고 실무에 적용하지 않아서 다행이다. 식별자 자체는 너무 단순해서 Wrap, Unwrap하는 리소스 관점에서의 낭비와 개발자의 구현관점에서의 낭비가 어마어마했다. VO가 유용한 케이스는 좀 따로 있는것 같다. 계산을 하기 위한 어떤 값이라던가. 추상적으로 감싸서 내부 타입은 언제나 교체할 수 있도록 하는 방식으로 말이다.
 
 

4주차 : Transactional Operation

4주차 키워드는 "낙관적 락 vs. 비관적 락" 이었고 개념적으로는 낙관적 락이 속도가 빠르지만 실제로 그럴까? 하는 의문을 갖는게 중요했다. 물론 상황에 따라서 너무 다르다. 동일한 핫키에 여러 요청이 들어왔을때 오히려 비관적 락이 속도가 더 빠를것이다. 고려할 두 가지 키워드가 있는데 일관성과 공정성이었다. 두 락 모두 일관성은 지켜진다. 하지만 공정성 관점에서 비관적 락은 내부 큐가 존재해서 어느정도 지켜질 수 있지만 낙관적 락은 그 순서가 보장되지 않을 수 있다는 점?
 
사실 실무에서는 동시성 고려가 전혀 이뤄지지 않고 있다. 동시성 자체가 고려할 필요 없는 도메인이기 때문이다. 휴가 신청을 본인 아니면 누가 신청할까? 따닥 이슈가 있을 수 있다. 하지만 극히 가능성은 낮아서 적용을 한다면 낙관적 락 혹은 멱등성있는 방식의 CUD로 바꾸려고 한다. 
 
중요한 주차였는데 이후에는 어떻게 다듬을지 고민이다. 좀더 생각해보기로.
 
 

5주차 : Practical Read Optimization

4주차 만큼 5주차도 중요했다. 대부분의 서비스는 읽기 성능이 중요한데 이를 어떻게 실무에서 풀어낼 수 있을지 직접적으로 연관지을 수 있었던 주제였기 때문이다. 쿼리, 인덱스, 캐싱 등을 다뤘지만 캐싱 자체가 워낙 딥한 주제라서 제대로 배웠다는 생각이 들지 않았다. 캐시 전략에 무엇이 있는지 학습도 했고 멘토님이 레디스를 어떻게 생각해야할지 알려줬는데 "레디스는 서버의 전역변수 저장소"라고 생각하면 도움된다고 했다. 맞는 말이었다. 레디스에 저장하는게 캐싱이 아니다.
 
5주차 과제를 진행하면서 프로메테우스와 K6를 이용해서 부하테스트도 진행했다. 회사에서 하는일보다 흥미로웠는데 왜 그럴까 하는 질문을 해보니 돌아온 답변은 "너는 비기능적 측면에 더 관심이 많아보인다"였다. 기능적 요구사항은 우리가 도메인 관점에서 구현해야하는 요소들이다. 예를 들어, "직원의 휴가는 연차별로 다르게 제공해주세요" 가 기능적 요구사항이고, 비기능적 요구사항은 "연차 요청시 p99 50ms 이하로 나오게 해주세요"가 비기능적 요구사항이다. 요것도 생각해보니 2주차에서 다뤘던 내용이다.
 
앞으로 해야할일은 모니터링, 로깅은 당연히 가져가면서 비기능적 요구사항에 대해 고민하면 백엔드의 보편적인 지식과 기술들을 챙겨서 도메인이라는 정책을 추가하기만 하면 경쟁력있는 백엔드 개발자가 될 수 있는게 아닐까? 회사에서 많은 실험과 적용을 해보자.
 
 

6주차 : Failure-Ready Systems

백엔드 개발자의 최종 목적은 단순한 기능 구현은 아니다. 실패에도 무너지지 않는 안정적인 시스템을 구축하는 것.
 
Resilience4J도 북스터디를 진행하면서 들었던 키워드다. 그때 읽었던 책은 "대규모 시스템 아키텍처로 배우는 면접 사례" 이런 비슷한 제목의 책이었는데 꼭 읽어보길 바란다. 백엔드 개발자 필독서! 지은이는 카네기 멜론 대학교 컴퓨터과학과에서 석사과정을 했는데, 카네기 멜론 대학교에도 기계공학 박사로 지원한적이 있었다. 아무래도 미국에서 CS학과중 탑이라서 지웠했었는데 기계공학쪽에서도 그러한 특색을 가져가려는 느낌이었다. 인도계열의 교수님과 인터뷰를 했었는데, 내가 상용소프트웨어를 사용한다는것에 반감을 가졌던 것으로 기억한다.
 
아무튼 Resilience4J를 이용해서 Resilience를 학습해볼 수 있는 아주 귀중한 시간이었다. 어떤 개념을 제대로 학습하기 위해서는 단순히 듣고 보기만 하지말고 실제로 구현하고 실험해서 결과를 얻어내는게 중요한것 같다. 여기서 timeout, retry, fallback, circuitbreaker 등의 개념들을 학습했는데 너무 케이스바이케이스로 적용할 수 있는 개념들이라 좀 어려웠다. Resilience4J를 적용한 메서드들을 테스트 코드로 작성했는데 Resilience4J라는 라이브러리를 테스트하는 느낌이었다. 이번 주차는 라이팅 과제를 작성하지 못했고 6주차 부터 살짝 힘이 빠졌던것 같다.
 
4, 5주차 처럼 6주차도 매우 중요한 개념이라 대규모 트래픽을 받아내야하는 시스템을 안정적이게 운영하려면 꼭 고려해야할 점인것 같다. 멘토님이 더 이상 확장하지말고 다듬으라고 했는데 무슨 느낌인지 알겠다. 우리가 배운 키워드들은 이미 충분한것 같다.
 
 
 

7주차 : Decoupling with Event

7 주차에서는 핵심 기능과 부가 기능을 구분하는 연습을 했다. 실무에서 직접적으로 적용이 가능했는데 어떤 요청에 대해 이것을 빠르게 응답을 주고 부차적인 기능은 비동기로 실행할지 그 경계에 대해서 고민을 했다. 예를 들어, 출근 요청을 해서 출근을 시키고 퇴근 알림을 생성하는 것은 비동기로 실행해도 되는 영역이었다.
 
여기서는 3가지 케이스에 대해서 실험도 같이 했었는데 동기적으로 요청하는 케이스, JVM기반의 이벤트로 비동기 호출, 비동기로 Redis에 저장하고 스케줄러 동작하는 방식. 3가지 모두 각각의 독특한 결과가 나왔고 결국 마지막 단계에서 직렬화가 이뤄져서 병목점이 사라지지 않는다는 점이다. 마치 해결하기 어려운 심시티4 러시아워의 교통체증이구만.
 

심시티4 러시아워

 
게임에서나 백엔드에서나 트래픽, 동시성 문제가 불거졌다. 실험결과가 흥미로웠는데 나중에 다시 읽어보면서 복기를 해봐야겠다. 7주차에서는 경계를 나누는 방법에 대해 고민하는 시간이었고, 설계를 할때는 항상 고민하고 있다. 최근에는 배치 프로세싱이 필요한 작업이 동기적으로 연결되어 timeout되는 문제가 발생했는데 6주차의 Resilience와도 살짝 연관이 되면서도 7주차의 고민이 필요했던 순간이었다. 설계는 완료되어서 구현만 하면 되는데 올해 연말에는 다른 우선순위가 많아서 일단 N+1문제만 코드레벨에서 해결해둔 상태이다. 아무래도 사업의 성공이 더 중요한 시기니까. 피쳐에 신경을 더 써야한다.
 
 

8주차 : Hello, Kafka!

7주차와 8주차를 통해 이벤트를 Reliable하게 구현하는 방법을 고민하게 되었다. 이벤트와 커맨드를 비교해보라고 멘토님이 알려줬지만 카프카를 소개하는 영상을 천천히 봐보니 커맨드 보다는 상태를 비교하면 좀더 의미가 있을것 같다.
 
RDB는 상태를 저장하는 방식이다. 예를 들어, 현재 삼성전자의 주가는 78,000원이라고 가정해본다. 그러면 그 가격이 그대로 레코드에 들어간다. 이벤트는 오르고 내리는 하나의 델타로 보면된다. 5원씩 오르는 이벤트가 10초 동안 5번 이뤄지면 결국 삼성전자 주가는 78,025원이 된다. 이벤트가 모여서 상태를 만들어낸다. 그렇다면 커맨드는 무엇인가? 커맨드는 대상이 정해져있고 목적도 정해져있다. 디자인 패턴 중에 커맨드 패턴이 있는데 직접적인 연관성은 없지만 어떤 일을 시키려고 할때 이를 객체화하고 직렬화해서 저장소에 저장하고 추후에 다시 불러서 역직렬화를 통해 시켜려고 했던 일을 불러올 수 있다. 
 
카프카는 실제로 업무에서 사용중이지만 초기 설정을 구현하는데 상당히 골치 아팠다. 누구는 회사에서 이걸 돈받고 배웠는데 나는 돈주고 배웠네? 보내는쪽, 보관하는쪽, 받는쪽 각각 설정이 모두 고려할게 많아서 아직은 확실히 정해진 나만의 템플릿은 없다. 추후에는 구축하는 방법을 좀 고민하고 레디스와 함께 패키징이나 모듈화를 어떻게할지 나만의 방식을 정해둬야겠다. 그리고 운용하는 방식과 모니터링을 학습하는 방식으로 확장해보기. 아니 이렇게 복잡한 데이터 시스템을 다른 실무자들은 어떻게 학습하는걸까?
 
 

9주차 : What is Popularity?

9주차 부터 사실 흥미가 많이 떨어졌다. e-HR 도메인에서는 랭킹을 고려할 필요가 거의 없기 때문이다. 하지만 요즘 집계 처리 및 대시보드 관련 요구사항들이 업무에 주어지는것 같아서 적용해볼 기회가 있을까? 하는 기대감은 살짝 있다.
 
아무튼 과제 구현보다는 현업에서 어떻게 적용해볼 수 있을지 고민하고 설계하는 시간을 가졌다. 나중에 이커머스가면 다시 읽어보면 좋은 키워드들이 많이 들어있다.
 
 

10주차 : Collect, Stack, Zip

마지막 주차는 현업에 적용해보기 좋은 주제인것 같아 탄탄하게 공부를 하여 우리 회사 팀원들에게 공유기반 학습을 해볼까 생각중이다. 하지만 시기상으로 개인적으로 도전해보고 싶은 신입공채가 있어, 코드 구현 과제는 설계만 해서 리뷰를 받을까 생각중이고 WIL 작성은 이 글로 대체하거나 생략하려고 한다.
 
과거에 다른 팀에서 배치서버를 설계/구현하려는 시도가 있었는데, 무산된적이있었다. 아무튼 그 당시에는 스프링 배치는 스케줄러와 여러 복잡한 기능들을 탑재한 프레임워크나 라이브러리라고 생각했다. 이번에 공식 문서를 살펴보면서 알게된 점은 좀 놀라웠다. 배치 프로세싱 자체는 굉장히 오래된 방식이고 이를 구현하면서 많은 시행착오들이 존재했는데 이를 프레임워크 차원에서 제공하는게 목적이었다.
 
실무에서의 고민은 어떻게 하면 실패하지 않고 안정적으로 배치 프로세싱을 운영하는것이다. 지난 주에는 스케줄러를 이용한 단순한 방식의 근무 집계처리가 실행되지 않았는데 그 원인을 도통 알 수 없었고 retry는 존재하지 않고 logging 방식은 디버깅을 어렵게 해두었다. 일단 logging처리는 보강해둔 상태이고 멱등성을 지키면서 실행되기 때문에 반복실행 자체는 문제가 안되기 때문에 APP과 DB의 리소스를 고려한 retry 방식을 고민해봐야겠다.
 
앞으로의 목표는 공식문서를 읽으면서 탑다운 방식으로 학습하면서 실무에서 적용해보기를 노력하는것이다. 지식을 다듬자.
 

수료한 후 생각정리

나의 삶은 어디쯤일까? 가끔 유튜브 알고리즘에 올라오는 "사람의 인생을 주로 나타내면 몇개인가?"를 보면 우울해진다. 매주 스터디를 하면서 수업도 듣고, 돈도 벌고 부트캠프도 참여하고 쉽지 않은 인생인것 같다. 방송대는 내년에 끝나니까 좀만 참아볼까? 그래도 수업은 재밌는게 많긴 하지만 1시간 가만히 듣고 있는건 어렵다. short form에 익숙해진 현대인들은 long form이 너무 힘들다.
 
이게 참 웃긴게 한국은 너무 작은 사회라서 나와 비슷한 결의 사람들을 보면 비슷한 스택을 갖고 있다. 넥스트 스텝의 TDD강의를 한 번씩 들어봤으며, Flab이나 실무자 부트캠프를 고민하고 비전공자라면 방통대 학위도 따고. 다음은 AWS SAA자격증인가? 너무 상업적인 자격증이라 따기 싫긴 하지만 고민해봐야겠다. 무엇을 배우고 무엇을 잃을지. 결국 더 이상 배울게 없으면 도달할것 같기는 하지만.

나의 리빙 스택을 레이어 아키텍처로 그려봤다

 
나는 배우는게 너무 좋다. 사람들과 어울리면서 생각과 경험을 주고 받는 활동이 좋다. 이렇게 많은 일들을 벌여놓아서 그런걸까? 빠르게 흡수되는 느낌은 딱히 없는듯. 이 과정을 마무리하면서 내린 결론은 다음과 같다 :
 

  • 돈을 주지 않아도 물어볼 수 있는 네트워크를 만들기
  • 배운것들이 헛되지 않도록 도전적인 환경으로 이동하기 (써먹지 못하면 증발한다)
  • 결이 비슷한 사람들과 같이 일해보기
  • (가장 중요) 내가 열정을 가지고 빠질 수 있는 도메인을 찾아보기

 
시작하기 전에는 이 공부했다가, 저 공부했다가 하는 비효율적인 방법을 사용했었는데 적당한 기간을 두고 하나의 토픽에 대해 깊게 고민하는 시간을 갖는 방식으로 해야겠다. 회사에서 사용하는 기술들을 더 깊게 파는게 중요할것 같고 멘토님들의 공통적인 의견은 사이드 프로젝트보다는 회사 업무에서의 경험이 더 중요하다는 것.
 
아래 책을 읽어보려고 고민했다가 구매를 했다. 예전에 원서를 좀 읽었었는데, 다시 번역본으로 읽어보니 아는만큼 보인다고 그때 읽었을때랑 지금 읽을때랑 생각이 많이 달라졌다.

 
블로그를 작성하는 습관을 들이는것도 굉장히 중요했는데 사람은 하나의 긴 시간선 아래에 살고 있기 때문에 특정 시점에 어떤 생각을 갖고 있었는지 기록하는게 나중을 위해 필요하다. 우리 블로그 글들이 쓰레기통에 들어가야할 수준일지도 모르겠지만 에세이나 일기라고 생각하고 작성하면서 가끔 도움되는 글들도 작성하면 좋지 않을까?
 
생각을 정리하는 습관, 나만의 글로 표현하는 연습. 글로 정리/고민을 해본 주제들이 많아질수록 말도 잘하게 된다.

 

관련글

티스토리툴바