6주, 절반을 넘기며
TL;DR 💡 이직 준비하려고 시작한 부트캠프가 절반을 넘겼다. 6주 동안 기술보다 설계가, 코드보다 구조가 중요하다는 걸 배웠다. 근데 정작 이력서에 뭘 쓸지는 아직 모르겠다.
시작은 이직이었다
솔직히 말하면, 이 부트캠프를 시작한 이유는 이직 준비다.
작년 12월쯤부터 슬슬 이직을 생각하고 있었고, 지인 추천으로 이 부트캠프를 알게 돼서 신청했다. 어차피 옮겨야 한다면, 준비된 상태에서 옮기고 싶었다.
그런데 부트캠프를 진행하던 중에, 지금 맡고 있는 서비스를 내린다는 얘기를 들었다. 서비스 종료가 확정된 상태에서 매일 출근하는 기분이 어떤 건지는, 겪어본 사람만 안다. 지금은 비용을 줄이기 위해 AWS에서 IDC로 인프라를 이관하는 작업을 하고 있다.
AWS 의존성이라는 현실
IDC 이관 작업을 하면서 매일 느끼는 게 있다. AWS에 의존된 코드가 너무 많다.
S3, OpenSearch, Aurora, SQS, EC2 위의 RabbitMQ, Parameter Store — 인프라 서비스에 직접 의존하는 코드가 비즈니스 로직 곳곳에 박혀 있다. “이거 IDC에서 뭘로 대체하지?”를 고민하기 전에, 어디까지가 비즈니스 로직이고 어디부터가 인프라 의존인지 구분하는 것부터가 일이다.
만약 처음부터 인터페이스로 추상화가 되어 있었다면? 메시지를 보내는 건 MessageSender고, 그게 SQS든 RabbitMQ든 구현체만 바꾸면 된다. 파일을 저장하는 건 FileStorage고, S3든 NFS든 갈아끼우면 끝이다.
근데 현실은 amazonSQSClient.sendMessage()가 서비스 클래스 안에 있다.
부트캠프에서 배운 게 이론이 아니었다
부트캠프 초반부터 멘토님들이 반복해서 강조한 게 DIP(의존성 역전 원칙)였다. 처음엔 “인터페이스를 만들어라”라는 뜻인 줄 알았다. 3주차 멘토링에서 혼나고 나서야 깨달았다. 고수준 모듈이 저수준 모듈에 의존하면 안 된다는 건, 비즈니스 로직이 인프라에 끌려다니면 안 된다는 거다.
3주차 글에서 정리한 내용인데, 그때는 과제 코드 안에서의 이야기였다. 지금은 회사에서 매일 그 반대 사례를 보고 있다. 과제에서 배운 원칙이 이론이 아니라, 지금 내가 고통받는 이유 그 자체였다.
고수준 기술을 깊게 파는 게 의미 있나
2주차 글에서 멘토님한테 질문한 적이 있다. “AI가 코드를 다 짜주는 시대에, 직접 삽질해서 깊게 파는 경험이 필요한가?”
답은 “필요하지 않다”였다.
6주가 지난 지금, 이 답이 더 선명해졌다. Redis 직렬화 삽질, Resilience4j 설정 — 이런 건 AI한테 물어보면 대부분 해결된다. 실제로 서킷브레이커 설정할 때 Claude한테 물어봤고, 대부분 맞았다. (HALF_OPEN 조기 차단은 틀렸지만.)
근데 “PG 호출을 트랜잭션 안에 두면 왜 위험한가”, “결제 실패와 결제 결과를 모르는 상태는 왜 다른가” — 이런 질문은 AI가 대신 해주지 않는다. 질문 자체를 할 수 있으려면 설계 감각이 있어야 한다.
고수준 기술스택은 언제든 대체된다. SQS가 RabbitMQ로, RestTemplate이 WebClient로. 근데 추상화 수준을 어디에 둘 것인가, 트랜잭션 경계를 어디에 그을 것인가 — 이건 기술이 바뀌어도 남는다.
시니어가 AI를 쓰는 방식
부트캠프 멘토님들은 빅테크 시니어들이다.
멘토링 때 AI 활용 이야기는 여러 번 들었다. 학습 방식, 업무 활용 사례, 추천 도구 같은 것들. 듣는 것만으로도 도움이 됐는데, 한 번은 Zep으로 화면을 공유하면서 실제로 AI를 쓰는 과정을 직접 보여주신 적이 있다. 듣는 거랑 보는 건 다르다. AI를 업무에 녹여서 쓰는 밀도가 생각보다 높았다.
왜 그런가 생각해봤다. 결국 경험이 많으니까 AI한테 던지는 질문이 다르고, 나온 답에서 뭘 취하고 뭘 버릴지 기준이 있는 거다. 2주차에 멘토님이 했던 말 — “같은 목적지를 다양한 길로 표현하는 걸 보는 게 더 효과적이다” — 이게 그런 뜻이었다. AI가 보여주는 여러 경로 중에서 맞는 길을 고르려면, 목적지가 어딘지는 알고 있어야 한다.
도구를 잘 쓰려면 도구가 아니라 문제를 알아야 한다.
절반을 넘겼는데
6주가 지났다. 기술적으로는 분명히 달라졌다.
좋아요 버튼 하나 설계하는 데 하루가 걸리던 2주차에서, 결제 시스템에 서킷브레이커를 붙이고 트랜잭션을 세 토막 내는 6주차까지 왔다. Redis SETNX로 만든 따닥 방지가 @RateLimit 어노테이션이 되어 결제에도 쓰이고 있다. 뭔가 쌓이고 있다는 감각은 있다.
근데 이력서를 열면 막막하다.
이걸 어떻게 어필해야 하는지 모르겠다. 1년 전 마지막으로 이직 준비했을 때랑 지금은 AI 관련해서 업무 환경이 많이 달라졌다. JD가 어떻게 바뀌었는지도 아직 제대로 안 봤다. “뭘 준비해야 하는지”를 모르는 상태에서 “준비하고 있다”고 말하기가 어렵다.
솔직한 불안이 하나 더 있다. 10주가 끝나면 해방감 때문에 한동안 아무것도 안 할 것 같다. 지금 이 글을 쓰는 것도, 이 블로그 자체가 이직할 때 어필할 수단이기도 하다. 그 사실을 인식하고 있으면서도, 정작 이력서 방향은 못 잡고 있다.
남은 4주
남은 4주 동안 뭘 해야 하는지, 사실 아직 답이 없다.
다만 6주 동안 하나는 배웠다. 고수준 기술을 깊게 파는 것보다, 그 기술이 왜 거기에 있는지를 이해하는 게 오래 간다는 것. 환경이 바뀌면 특정 기술에 대한 숙련도는 금방 낡지만, 구조를 보는 눈은 남는다.
준비가 됐냐고 물으면 아직이다. 근데 6주 전의 나는 뭐가 부족한지도 몰랐다. 지금은 안다. 1주차에 쓴 글에서 “앎은 작은 모름에서 큰 모름으로 나아가는 과정”이라고 했는데, 딱 그거다.