[항해플러스] 1~7주차 회고

항해플러스 7주간의 첫 프로젝트가 끝났다.

프로젝트라는 말을 붙이기에는 다소 초라한 결과물이기는하지만, 그래도 TDD를 토대로 시나리오를 설계하고 코드를 구현했고, CI/CD를 파이프라인을 통해 main 브랜치의 품질 유지와 자동배포를, 그리고 통합 모니터링 시스템을 구축하고 소소한 트래픽 테스트까지 짧은 기간동안 몰아서 할 수 있었다.

매주 제한적인 시간을 쓸 수 밖에 없었던만큼 분명 완성도면에서 아쉬움이 크고, 또 부족한 완성도가 누적되어 마지막 장애대응 모의훈련에서 시도해볼 수 있는 테스트의 종류와 테스트 결과 분석도 한정적이었다. 그럼에도 불구하고 현업에서도 그렇고 앞으로도 프로젝트를 설계하면서 내가 볼 수 있는 시야가 확실히 더 넓어졌다는 생각이 든다.

프로젝트 회고

Ch1. TDD

말로만 듣던 TDD를 체득하고 이해한 방식을 토대로 TDD 사이클의 스탭단위로 마이크로 커밋을 진행했다. TDD란 블럭들을 쌓아서 올리는 것이라는, 한 코치님의 얘기에 많은 영향을 받아 바텀 투 탑으로 진행을하였는데, 이 때문에 통합 테스트와 e2e 테스트가 미비했고, 다른 팀원들은 비즈니스 로직까지만 완성하고 api 엔드포인트를 완성하지 못하게 되었다. 코치님 이야기와는 반대로 참고했던 많은 레퍼런스들에서는 e2e 테스트를 먼저 작성하고 이걸 채워나가는 과정으로 묘사했는데, 이처럼 엔드포인트 단위로 작업을 했다면 전체 작업의 완성도는 떨어져도 기능하는 서비스는 더 많았을 것 같다.

Ch2. CI/CD

자동배포 정도는 항해99 때부터, 그리고 지금 회사에서도 자주 만들지만 CI 파이프라인에 대해서는 깊게 고민을 해보지 않았었다. 일단 테스트 코드를 잘 작성하지 않았고, 회사에서도 최소한의 e2e 테스트만 작성하고 이정도만 CI에 포함시켜서 사용하곤 했다.

하지만 린트룰이나 테스트를 어떻게 팀차원에서 통일감있게 적용할지에 대해, 그리고 프리커밋 같은 기능들에 대해 배우고 적용해봤고, 정적 소스 검사 같은 기능이 있다는 것도 알게되어 적용해볼 수 있었다. 또, 그동안 컨테이너도 EC2를 통해서 실행시키다가 이번에 ECS에서 Fargate를 이용해 서버리스로 배포를 하고 ALB를 적용시켜볼 수 있었다. 한가지 아쉬운건 시간이 부족해서 무중단 배포까지는 하지 못했던 점인데, 후반 주차에서라도 완성했다면 어땠을까 싶다.

Ch3. 통합 모니터링 시스템

AWS 서비스들에서 CloudWatch로 로그를 수집하고 지표를 확인하는 정도까지는 해봤었지만, 서비스 로그도 CloudWatch에 기록을하고 알람을 연결해 슬랙이나 이메일 등 장애가 생겼을 때 자동으로 장애 전파가 가능한 시스템은 이번에 처음 구축을 했다.

팀원중에 ELK를 간단하게나마 쓸 줄 아는 사람도 있었고, 코치님 중에서도 ELK에 크게 의욕이 있으신 분이 계셔서 나도 욕심이 났었는데, 이때 다른 일로 바빠서 욕심을 낼 수 없었다. ELK든 EFK든 조만간 리서치를 다시 해보고, 회사 서비스에서는 적용해볼 수 있으면 좋을 것 같다.

그리고, PrismaClient에서 직접적으로 요청 컨텍스트에 접근할 수 없어서 Prisma 미들웨어를 만들 때 어떻게 로깅 컨텍스트를 가져올지에 대한 이슈가 있었는데, 그동안 실전에서 써보지 못했던 async_hook의 일부 기능인 AsyncLocalStorage를 이번 기회에 사용해볼 수 있었다.

Ch4. 장애대응 훈련

일단 처음에 너무 장애대응을 어렵게 생각했었다. 거대한 매뉴얼을 만들고, 매뉴얼에 따른 시나리오를 짜고, 실제 모의 훈련을 진행해야한다고 이해했었다. 아니 어쩌면 이게 애초의 커리큘럼 목적이 맞았을지도 모르겠다. 하지만, 서비스의 완성도가 낮아서 다양한 장애 설계가 불가능했고, 후반주차에 각자의 사정으로 팀 참여율이 많이 저조해서 해볼 수 있는게 많지 않았다.

다행히 항해99 실전프로젝트에서 로드 테스트는 지겹도록 했기 때문에 그때의 경험을 되살려 최소한의 로드 테스트를 설계하고, 이번에는 스케일아웃으로 대처하기보다 서킷브레이커 패턴을 프록시서버에 적용하여 최대 응답시간을 제어하는 방식으로 장애를 대처해봤다. 다만, 메인서버에 부하가 걸릴 정도면 프록시 서버도 부하가 걸리는 바람에 높은 트래픽에서는 half-open 로직이 정상적으로 작동하지 않았는데, 이걸 개선할 시간적 여력은 부족했다. 추후 여유가 될 때 프록시 서버를 단계적으로 구축해서, AG 서버와 엔드포인트별로 그룹으로 나눠 요청을 제어하는 서버를 구분하면 해결되지 않을까 생각한다.

이와 관련해 코치님께 BFF라는 최신 트랜드에 대해 들었는데, 마이크로서비스에서 GraphQL과 결합하여 대규모 서비스에서 쓰이는 패턴으로 보이며 추후 GraphQL부터 공부를 하고나서 한번 적용을 해보고 싶다.

장점

아직 3주나 남았지만, 그럼에도 정말 다 이루말할 수 없을 정도로 프로그램명 그대로 내게 플러스가 많았다.

1. 테스트 중요성과 TDD란 무엇인지 알게 되었다.

항해때부터 코치님들이나 외부 레퍼런스들에서 테스트의 중요성은 정말 귀에 못이 박히도록 들었다. 하지만 대부분의, 아니 어쩌면 모든 주니어 개발자들에게 테스트는 중요한 것도 알고 필요한 것도 알지만, 같은 코드를 두번 작성하는 반복작업인 것 같고 업무적으로 누가 강제하지 않으면 다른 업무에 밀려 뒷전이기 쉽다.

하지만, TDD라는 개발 패러다임이 테스트를 통해 어떻게 보다 체계적인 설계와 코드 안정성을 주는지, 추후 기능을 수정하거나 추가할 때도 어디부터 어떻게 수정할지 시작점을 찾아주고 결과적으로 디버깅 시간을 줄여주는지를 몸으로 체험할 수 있었다.

2. 어설퍼도 다양한 현업 경험들이 어우러진다.

항해99 때는 팀 프로젝트를 해도 사실 다들 백지 상태이기 때문에 모든것이 새롭고 모든것을 그때그때 학습해야한다. 누군가 먼저 학습을 해서 조금 더 많이 알 수는 있지만, 그 내용이 얼마나 실효성이 있는지에 대해서는 아무도 모른다.

하지만, 항해플러스는 짧게는 몇개월에서 길게는 2~3년 현업 경험들이 쌓인 사람들이 모이는만큼, 저마다 그동안 경험한 배경이 달랐고 어떤 주제에 대해 서로 갖고 있는 견해가 달랐다.

누군가는 시나리오를 설계하면서 각 데이터들간의 관계에 대해 더 많은 경험이 있었고, 누군가는 프레임워크나 소프트웨어 디자인에 더 많은 경험이 있었다. 또, 유효성 검사나 로깅처럼 누구나 어느 서비스든 다 공통으로 하는 작업이지만, 서로가 해온 방식이 달랐기 때문에 서로가 익숙한 방식을 비교해볼 수도 있었다.

이런 간접경험들을 통해 내 시야도 더 넓고 깊어지는 것을 두달간 분명하게 느낄 수 있었다.

3. SRE에 대해 얕게나마 인사이트를 얻었다.

주니어 개발자들에게 SRE는 쉽게 경험하기 힘든 영역이다. 설령 혼자서 개발을 한다고하더라도, 기능개발이나 다른 업무에 급급해 테스트처럼 상대적으로 소흘하기 쉬운 것이 SRE 업무들이기도 하다.

하지만 항해플러스에서 첫번쨰 프로젝트의 약 반에 해당하는 3주간 자동화된 통합 모니터링 시스템을 구축하여 시스템 각 요소에 대한 로깅과 적절한 커뮤니케이션 채널로의 알림까지 설정해볼 수 있었다. 또, 구체적인 장애대응 매뉴얼이나 시나리오를 만들어내지는 못했지만, 보다 규모가 있는 서비스와 팀에서 어떤식으로 장애 상황을 대비해 시스템이 짜여져있고 준비를하는지 알게 된 것도 당장에 적용해보지는 못했을지라도 현업에서 언제든 시도해볼 수 있는 키워드들이 생겼다.

4. 소프트웨어 디자인패턴에 대해서도 고민을 하게 됐다.

이전에는 다소 광범위하고 일반적인 의미의 클린코딩과 객체지향적인 코딩을 이해하고 적용하려고했다면, 매주 코치님들의 멘토링을 통해 조금 더 체계적인 디자인 패턴들에 대해 인사이트를 얻고 어떻게 적용할지 고민해볼 수 있는 시간이 되었다.

어설프게 알고 쓰고 있던 레이어 아키텍쳐에서 파사드, 팩토리 같은 패턴들이나, Nestjs에서 채용하고 있는 싱글톤과 DI에 대해서, 그리고 각 레이어, 도메인, 모듈 간 데이터를 주고 받기 위한 DTO와 맵퍼의 설계 방법에 대해서도 이러한 패턴들이 왜 쓰이고 어떻게 그동안 작성했던 코드들에서 쓰이고 있었는지 보다 구체적으로 이해할 수 있었다.

그리고 서킷브레이커처럼 요청을 핸들링하는 디자인 패턴을 구현해볼 수 있었고, 또 BFF라는 최근 대규모 마이크로서비스들에서 많이 사용하고 있다는 패턴에 대해서도 인사이트를 얻었으며 매우 흥미롭게 리서치를 했다.

5. 코치님들이 정말 열정적이고 다양한 경험들을 가지고 계셨다.

시니어 개발자와의 접점이 가장 아쉬웠던 나로서 항해 플러스에 가장 크게 기대했던 부분이기도 했고 동시에 가장 만족스러운 경험이기도 했다.

코치님들의 경험이나 경력도 빛나지만, 모든 분들이 교육, 오픈소스, 코딩테스트 등등 저마다의 방식으로 개발에 열정이 넘치셨고 또 본인들의 지식을 나누는데 엄청 적극적이셨다. 정해진 멘토링 시간을 넘어서서 많은 질문들을 받아주시고 또 많은 질문을 반대로 하시기도하는 등 코치님들이 너무 감사하게도 본인들의 값진 시간을 기꺼히 할애해주셨다.

덕분에 현업에서 고민중이던 문제들에 대해서도 여러 해결방법들을 얻기도 했다. 예를들어, 백엔드와 프론트엔드 사이의 api 인터페이스화를 어떻게 더 타입 안정적으로 할 수 있을지 조언을 구하면서, 손코딩하던 방식에서 sdk화해서 npm에 배포하고 최근에는 tRPC로 다시 넘어가고 있는 등 많은 회사 코드에 많은 변화가 있었다.

그리고 앞으로 개발자로서의 커리어를 어떤식으로 끌고 나갈지에 대해서도 여러 의미있는 조언을 많이 주셨다. 무엇을 공부해야하는지, 그리고 어떻게 공부해야하는지, 이직은 언제 준비해야하고 왜 해야하는지 등 항상 물음표가 끊이지 않는 질문들에 대해 코치님들마다 저마다의 관점을 제시해주셨고 항해플러스를 시작하기 전보다 조금은 더 명료해졌고, 또 잠깐 느슨해졌던 긴장도 다시 바짝 끌어올릴 수 있었다.

단점

항해99 때부터 고마운게 많고 그래서 더 좋은 애기들을 많이 남기고 싶지만, 그럼에도 아쉬운 점들이 없던 것은 아니다.

1. 커리큘럼 완급 조절이 아직 완성되지 않았다.

적절한 표현인지 모르겠지만, 간간히 주말 조깅 정도로 생각하고 나와서 하프 마라톤을 달린 기분이다.

프론트엔드 위주로 개발을 하던 사람도, 자바 스프링이나 파이썬으로 개발을 하던 사람도 모두 Nodejs를 해야만 했기에, 타입스크립트나 Nestjs를 처음 써보는 사람도 굉장히 많았다. 비록, 보다 간단하게 자바스크립트와 Express를 쓸 수 있는 옵션도 있었지만 누구든 욕심을 안내지 않을 수는 없었을 것 같다.

그러다보니 많은 팀들이 처음에 TDD는 고사하고 언어와 프레임워크를 학습하는데 많은 시간을 할애했다. 그나마 우리팀처럼 Nestjs 사용경험이 많은 사람이 있는 몇몇의 팀들은 사용 노하우들을 공유하면서 비교적 빠르게 프로젝트 모양새를 갖춰나가기는 했다. 그럼에도 TDD라는 익숙하지 않은 개발 방식을 체득하기에도 시간이 빠듯한데 처음 학습하는 사람들은 처음 학습하는대로, 그리고 처음이 아닌 사람들도 가만히 기다리고만 있을 수 없기 때문에 첫 3주동안 작업량이 정말 많았다.

단적으로, 실제 코딩을 많이 했던 2,3주차는 내가 코드를 직접 쓰는 시간보다 다른 사람들 코드를 리뷰하는 시간이 더 많았다.

그러다보니 첫 챕터, TDD와 서비스구현에서 모든 팀들이 제 시간내에 주어진 시나리오를 완성하지 못했고, 이후 주차를 수행하는데 있어서 작업이 누적되고 지연되어 각 챕터 주제들의 실제 난이도보다 체감 난이도가 훨씬 올라가는 상황이 펼쳐졌던 것 같다.

다만, 앞으로는 자바 스프링 옵션도 추가되는 등 수강생들이 조금이라도 더 본인이 편한 개발 환경을 선택할 수 있도록 조금씩 개선이 되고 있으니, 초반주차에서 발제 주제에 집중하지 못하던 문제는 차차 해결될거라고 생각한다.

2. 조별 과제는 조별 과제다.

항해99 때는 그래도 어느정도 출발선이 다들 비슷했었고, 또 모두가 풀타임으로 각 주차별 프로젝트에 매진했기 때문에 부족한 부분은 잠을 더 줄여가면서 채워나갈 수 있었다.

하지만 항해플러스는 다들 본업이 있는 상태에서 파트타임으로 진행하는 프로젝트였고, 또 경험치들이 다 달랐기 때문에 팀별로 그리고 팀 내부적으로도 개개인의 실력과 프로젝트에 할애할 수 있는 리소스의 편차가 많이 심했다. 그런 와중에 해야하는 일도 생각보다 많았기 때문에 결국 여력이 되는 혹은 의지가 있는 누군가가 더 열심히 하지 않으면 안되는 상황이었던 것 같다.

이런게 팀워크 연습이라면 연습이기도 하겠지만, 그래도 현업에서 컨트롤 가능한 범위를 훌쩍 넘어서는 변수들이 매주차 발생하는만큼 매주 과제 수행에 어려움이 적잖이 있었던 것 같다. 일단 나부터 중후반에는 회사업무와 다른 프로젝트로 항해플러스에는 초반주차만큼 시간을 많이 할애햐지 못했다.

3. 많은 것을 담았다는게 모든 것을 할 수 있다는 뜻은 아니다.

어쩌면 1, 2번과 이어지는 문제다.

비록 허접한 주니어 개발자지만 커리큘럼은 정말 훌륭하다고 생각한다. 내 개인적인 관심사랑 니즈와 많은 부분에서 커리큘럼이 일치했다. 하지만, 그 모든 것을 소화할 수 있는지 여부는 결국 내가 얼마나 열심히 하느냐에 따라 다르다.

평균적으로 주 10~15시간정도를 투자했었는데, 20시간 혹은 그 이상을 썼다면 분명 어거지로라도 프로젝트 완성도를 더 올리고 더 많은 도전과 경험을 해볼 수 있었을 것이다. 더 많이 해본만큼 관련해서 코치님들께 얻을 수 있는 인사이트도 더 많았을 것이다.

내 개인적으로는 그래도 본래 커리큘럼에서 내가 기대했던 것의 80% 이상은 얻었다고 생각하지만, 매 주차가 지날수록 전체적인 진행상황이 더딤에 따라서 커리큘럼 적으로 지향하는 목표치가 조금씩 낮아지는게 느껴졌다. 커리큘럼이 아직 덜 성숙한 것도 있겠지만, 분명 수강생들이 커리큘럼에서 원하는 결과를 따라가지 못한 것도 크다. 그리고 이는 부족한 결과만큼 각자가 얻어가는 결과도 적어진다는 의미이기도 하다.

때문에 어줍짢게 주말마다 다리 뻗고 편하게 누워서 뭔가를 얻어갈 생각을하기보다, 정말 회사 업무 외에 모든것을 다 항해플러스에 쏟을 각오 정도는 해야 현재의 항해플러스가 담고 있는 모든 내용을 하나라도 더 얻어갈 수 있을 것이다.

그리고 반대로 항해플러스에서도 너무 많은 것을 담으려고 애쓰기보다 어쩌면 항해플러스를 듣는 수강생들의 현실에 맞춰 조금은 선택과 집중을 해야하지 않을까 생각한다.

그래도...

재밌었다.

앞으로 남은 오픈소스 프로젝트도 3주간 얼마나 어떻게 할 수 있을지는 모르겠지만 어떤 새로운 배움들과 깨달음들이 있을지 기대가 된다.

그리고 적당히 6개월~1년 정도의 경험을 쌓은, 혹은 1년 이상에 이직을 준비 중인 개발자라면 정말 많은 도움이 될거라고 생각한다. 더 이르면 생각보다 내용이 어려울 수 있고, 더 늦으면 들이는 공수대비 얻어갈 수 있는게 많이 적어질 것 같다.