본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
지난 25일간 학습하면서 가장 기억에 남는 내용은 무엇이었나요?
여태까지 환급 챌린지를 진행하면서 가장 의미 있었던 것은 아무래도 습관을 가지는 것이 아닐까 싶다. 처음 시작할때에는 매일 학습한다는 것이 막연하게 느껴졌고 부담스러웠다. 첫 일주일은 앉아 있는 것 자체가 힘들었던 기억이 있다. 그런데 신기하게 어느 순간부터는 조금 덜 힘들어진 것 같다. 아직도 평일에는 힘든건 마찬가지지만, 주말에는 오히려 앉아서 강의를 하나만 보아두 작은 성공을 이뤘다는 느낌에 성취감이 느껴졌고, 계획한 시간보다 더 시간을 더 보내는 경우도 많았다. 비록 길지는 않지만 평일에도 매일 한 시간은 앉아잇는 루틴이 생긴것이다. 이전에는 "시간 날 때 공부해야지" 라고 생각만 하다가 미루는게 일상이었는데, 학습에 대한 생각이 일상 속으로 조금은 녹아든 것 같다.
배운 내용을 일상/업무에 적용해본 경험이 있나요? 없다면 앞으로 적용해보고 싶은 부분은 무엇인가요?
지금까지는 주로 Redis, webflux 위주로 배웠기 때문에 해당 기술들을 적용해보고 싶었다. 특히 레디스는 물론 캐시를 위해 사용하고 싶었던 부분도 있지만 특히 분산 락과 추가적으로 찾아본 Key Space Notifications 기능이 흥미로웠다. 분산 락의 경우 동시성 제어가 필요한 상황에서 유용하게 쓰일 것 같았고, Key Space Notifications는 만료 이벤트를 활용한 스케줄링 같은 기능을 구현할 수 있을 것 같아 관심이 갔다.
하지만 바로 적용하기에는 분산 락의 경우 현재 시스템에서는 애플리케이션 레벨의 낙관적 락과 데이터베이스 레벨의 유니크 제약과 혹은 네임드락을 주로 사용하고 있기 때문에 Redis 기반 분산락이 성능이나 관리 측면에서 더 나은 선택일 수 있다는 생각이 들었지만, 당장 Redis 클러스터를 구축하고 운영하는 데 필요한 인프라 비용과 리소스를 고려하면 현실적으로 어려움이 있었다. Key Space Notifications는 이벤트 유실 가능성이 있다는 점이 프로덕션 환경에서 사용하기에는 리스크가 있어 보였고, 아직까지는 보류 중이다.
대신 실제로 업무에 적용해볼 수 있었던 부분은 WebClient를 활용한 API 호출 최적화였다. 최근 업무에서 어쩔수 없이 MSA 서비스 API를 단일 루프로 여러 번 호출해야 하는 상황이 발생했다. 최대 호출 횟수의 제한이 있는 터라 크게 문제는 없지만 동기 방식의 순차 호출보다는, WebClient의 비동기 처리를 활용하면 성능을 개선할 수 있을 것 같았다. 물론 서버 스택이 Spring Web MVC 기반이라 요청 스레드 자체는 블로킹되는 한계가 있었다. 완전한 논블로킹 처리를 위해서는 전체 스택이 WebFlux이면 좋았겠지만, 그래도 WebClient의 비동기 처리 방식을 활용해 여러 API 호출의 지연 시간을 줄일 수 있었고, 응답 속도 측면에서는 충분히 의미 있는 개선 효과를 얻을 수 있었다.
학습 중 어려웠던 순간과 이를 극복한 방법은 무엇이었나요?
가장 힘들었던 점은 역시 매일 해야하는 것 아닐까 싶다. 주말은 그나마 시간 조절이 가능했지만, 평일은 정말 힘들고 애매했다. 회사 업무량이 많은 날에는 퇴근 후 녹초가 되어 강의를 듣기가 쉽지 않았고, 조급한 마음에 더 집중이 되지 않을때에도 있던 것 같다. 특히 평일에 피할 수 없는 일정이 생기는 경우가 가장 어려웠던 것 같다.
이런 어려움을 극복하기 위해 몇 가지 사소한 전략을 세웠다. 첫 번째는 '미리 준비하기'다. 다음 주 일정을 미리 확인해서 시간이 부족할 것 같은 날이 있으면, 주말이나 여유 있는 날에 미리 해당 챕터의 내용을 살펴보고 관련 자료를 준비해두었다. 완전히 다 파악하지는 못하더라도 개요와 해당 개념에 대해 미리 파악해두면 나중에 부담이 훨씬 줄어들었다.
두번째는 '처음부터 깊게 파고들지 않기'다. 처음에는 강의에 나온 내용과 추가적으로 살펴본 내용 100 퍼센트를 이해하고 넘어가려고 했는데, 그러다 보니 진도가 너무 느려지고 스트레스만 쌓인 적도 있다. 아직도 그런면이 있긴 하지만 요즘은 70-80% 정도 이해했다 싶으면 다음으로 넘어가고, 나중에 필요할 때 다시 찾아보는 것으로 방식을 바꾸려고 한다. 특히 그 뒤의 강의에서 다시 해당 개념이 나오거나 더 자세히 다루는 경우도 있던적도 있었기 때문에 좋았던 것 같다.
25일 동안 스스로 발견한 변화는 무엇인가요? (습관, 사고 방식, 태도 변화 등)
가장 큰 변화는 앞에서 말한 것처럼 평일 저녁에 앉아 있는 것이 꽤 익숙해진 것이다. 물론 힘들지 않은 것은 아니다. 여전히 어떤 날은 누워있고 싶고 뒹굴거리고 싶다. 하지만 조금은 나아진 것 같고 작은 성공으로 따라오는 성취감이 나쁘지 않은 것 같다. 지금은 오로지 환급을 받기 위한 강박감에 하는 학습이라기 보다는, 하나씩 몰랐던 부분을 알아가는 것에 대한 즐거움을 살짝 느끼고 있다고 느껴진다.
특히 강의 내용 외에도 여러 가지를 찾아보게 되었다. 예를 들어 현재 WebFlux를 학습 중인데, 최근에는 Server-Sent Events(SSE)에 관심이 생겨서 관련 자료들을 찾아보고 있다. 실시간 데이터 스트리밍이 필요한 상황에서 WebSocket 대신 SSE를 사용하면 어떤 장단점이 있을지, 어떤 상황에 더 적합할지 등 고민을 하는 시간들이 비중이 더 높아졌다.
업무에 대한 태도도 조금 달라졌다. 이전에는 주어진 작업을 해결하는 데 가장 많이 집중했다면, 이제는 "이 문제를 더 효율적으로 해결할 방법은 없을까?", "배운 기술을 여기 적용하면 어떨까?" 같은 생각을 자주 하곤 한다.
남은 25일 동안의 목표와 실행 계획은 무엇인가요?
우선 가장 최우선 목표는 챌린지를 끝까지 완주하는 것이다. 지금까지 만들어온 학습 습관을 끝까지 유지하면서, 남은 강의 내용도 학습해서 내 것으로 만들고 싶다. 특히 후반부로 갈수록 더 심화된 내용이 나올 것 같은데, 단순히 진도를 빼는 것이 아니라 제대로 이해하고 실습해보면서 진행하고 싶다.
두 번째 목표는 배운 내용을 실제 업무에 유의미하게 반영해보는 것이다. 시스템에 어떻게 활용할 수 있을지 구체적인 유스케이스를 찾아보고, 가능하다면 작은 PoC(Proof of Concept)라도 진행해보고 싶다.
세 번째로, 가장 해보고 싶은 것은 Event-Driven Architecture(EDA)를 적용해보는 것이다. 현재 레이어드 아키텍처로 설계된 프로젝트가 있는데, 일부 기능을 이벤트 기반으로 전환하면 시스템 간 결합도를 낮추고 확장성을 높일 수 있을 것 같다. 특히 헥사고날 아키텍처 기반으로 같이 진행하면 잘 맞을 것 같아 계획중이다. 물론 현실적으로 당장 적용하기는 어려울 수 있다. 작은 규모로 실험해볼 수 있는 부분을 찾아보거나, 개인 프로젝트로 먼저 경험을 쌓는 방법도 좋을 것 같다.
.
