Kernel360 E2E Project에 대한 회고
끝과 끝을 자르면 또 다른 끝과 끝
요약 - kernel360 프로젝트 중 하나인 E2E Project를 마치고 그에 대한 회고와 공부한 기술스택, 기여도에 대한 글
-
일시 : 2023-10-24 ~ 2024-11-24
-
결과 :
- 기획의도 : [Boogle] IT 도서에 관심있는 독서가들을 위한 검색창
- 깃헙링크 : Boogle Github Repository
"회고: 잘 맞는 동료들과 함께 첫 사이클을 돌아보다."
E2E 프로젝트는 Front-End부터 Back-End까지의 구현 기술을 협업으로 경험해보는 프로젝트로 기획, 설계, 개발, 배포까지 경험할 수 있다. 팀 빌딩은 해커톤과 비슷하게 아이디어를 내고 다수의 채택을 받은 사람이 팀장으로 선정되고 그 팀장을 중심으로 자유롭게 팀이 구성된다. 나는 여러번 팀을 해보고 같은 셀에 있는 사람들이 있는 팀으로 이끌리듯 소속되었다.
기획 의도는 IT서적을 찾는 사람들에 유용한 서비스를 만들자는 생각이었다. 팀장과 또다른 팀원은 책을 통해 기술을 주로 접하는 사람들이었다. 사용자들에게는 IT 서적 검색, 독후감 작성, 독후감에 대한 댓글, 마이페이지 기능을 제공하고, 관리자에게는 도서와 독후감을 관리할 수 있는 기능 그리고 월간 사용자 유입, 댓글 수 등에 대한 통계 자료를 제공한다.
기획 작업은 Boot-Up 또는 해커톤 때와 크게 다르지 않았다. 기능 명세를 작성하고 Figma로 와이어프레임을 만들고, ERD 클라우드로 테이블 구조를 그렸다.
협업 전략으로는 기능 단위로 fork된 repository에 branch를 새로 만들어 pull request를 보내는 github flow 전략을 채택했다.
배포가 완료된 5주차부터 각 조는 배포된 URL을 슬랙에 공유하고, 각자의 서비스를 돌아가며 테스트하고 버그 리포트를 하는 시간을 가졌다. 다른 조에서했던 작업을 돌아가며 버그를 일일이 찾아보는 일을 했는데, 나는 크게 많은 기여를 한 것 같지 않다. 그 이유는 개발자들이 의도한 대로만 제품을 썼기 때문이다. (이심전심인가?)
프로젝트 발표에서 나는 Tech Story라는 부분을 맡아서 내용을 구성하고 발표를 했다. 일종의 Boogle팀 단위로 다른 팀에게 나눌만한 기술적 회고를 생각하고 작성했다. 나의 발표에서 방점을 찍었던 부분은 아래와 같다. 쓰고보니 전부 나에게 하는 다짐이 되어버린 것 같다.
-
패키징: 테이블과 패키지가 적절히 매핑된 구조를 만들자, 도메인을 전부 가지고 있는 패키지는 어플리케이션에서 공통으로 사용하는 패키지와 동일선상에 두고 그것들이 섞이도록 하지 말자!
-
테스트코드: 저조한 실적을 가지고 있지만, 보다 강건한 코드 작성을 위해 최대한 기능을 나누고 그에 맞는 테스트코드를 먼저 만들자!
-
기능 추가: 테이블 설계부터 스마트하게 다가가자!
-
Final때는 조금 더 클린코드를 짜고, 효율적인 알고리즘을 짜고, 여러 프레임워크의 세부 모듈에 기술적 깊이를 지닌 개발자가 되자!
Kernel360 1기에서는 한 프로젝트가 마무리되면 우승팀을 뽑아 상품을 준다. 개인적으로 우승에는 그렇게 관심을 두지 않고, 주어진 일을 열심히해서 많이 배우자는 생각을 했던 것 같다. 그리고 6팀 모두 기술에 큰 차이가 있기보다는 디테일과 깊이에서 수준 차이가 약간 있었고, 협업이라는 가치가 기술적으로 드러난 부분으로 코딩 컨벤션 등이 있을 것 같다는 생각이 들었다. 여러가지 기준에 Boogle팀이 아주 큰 두각을 드러내지는 않을 것이라 생각했지만, 우리팀이 우승을 했다. (!!) 개인적인 생각으로 Boggle팀은 정말 즐겁게 일할 수 있는 팀이었다. 회사에 들어가서도 꼭 그런 팀에 속하고 싶을 정도로 말이다.
마지막으로 ‘6개 팀이 했던 작업들을 한데 모으면 스타트업에서 내어놓는 상품이 될 수 있다.’ 고 하셨던 박조은 디렉터님의 말씀이 인상 깊었다.
"기술스택: Kernel360은 스프링부트 생태계에 나를 빠트렸고"
"어느새 나는 인공지능 외에 갖가지 튜브를 끼고 있었다."
해커톤을 막 마치고 E2E 프로젝트에 투입되었던 상태를 돌이켜보면, 아주 막연하게나마 API의 개념을 이해하고 DB와 통신하기 위해 어떤 작업들이 필요한지 겨우 파악한 상태였다. 그때와 지금을 비교해보면 기능하나를 도맡아서 할 수 있는 자신감을 얻은 상태이다. 홈페이지 하나를 만들기 위해 사용해야하는 그 수많은 기술 스택과 생소한 문법들은 언젠가는 한번 시도해볼만한 도전 과제가 되었다.
많은 일을 할 수 있었던 이유는 …
- 같이 배울 수 있는 동료가 함께하기 때문
- 필요한 때에 도움을 받을 수 있는 디렉터진과 멘토들이 있기 때문
- LLM 모델의 답변이 계속 정교해지고 있기 때문
기술스택
E2E 프로젝트는 생각외로 기술적인 요구사항이 많았다. 백엔드 부트캠프 과정임에도 프론트엔드를 소홀히 하지 말 것을 주문받았기 때문에 프론트엔드를 포함한 개발과 배포까지의 과정에 필요한 많은 기술을 접할 수 있었다. 새로운 기술을 접한다면 우리는 습관적으로 러닝커브에 대하여 고민하게 되었고, 꼭 거쳐가야하는 기술이 있다면 ChatGPT나 Bard의 도움을 받았다.
CI/CD 흐름
배포는 대체로 Boogle 팀의 팀장이 도맡아서 수행했으나, 팀 단위로 진행되었던 기술 회고에서 대략적으로 몇가지 AWS 서비스를 조합하여 어떤식으로 자동 배포를 구현하였는지 공유를 받을 수 있었다. Kernel360은 개발 이후에 운영이라는 측면을 강조하는 부트캠프로 파이널 프로젝트에서는 이 부분에 대한 조금 더 심도있는 경험을 할 수 있을 것으로 기대된다. 지금은 “아주 편리하게 우리가 만든 서비스가 올라갈 수 있었다”라는 추억을 지닌 것으로 감사하게 여긴다.
"기여도: 개발자는 일을 끝내는 사람들, 그리고 끝은 또다른 시작."
개발자라는 직업은 매력적이다. 다른 이를 도우면 나에게도 도움이 된다는 사실을 시스템적으로 깨닫는 사람들로 보인다. 컴퓨터를 사용하여 “뭔가 멋있는 일”을 한다는 것도 마찬가지이다. 하지만 내가 가장 중요하게 생각하는 이유는 일을 마무리 지을때 가장 주요한 역할을 하는 사람들이 개발자라는 것이다.
E2E 프로젝트에서 Boogle팀의 팀원으로 활동하면서 아래 스프링 부트 세부 모듈을 활용하여 기능들을 구현했다. 이로써 기획으로 우리가 뿌린 씨앗을 제대로 거둘 수 있었다.
Spring Data JPA
Kernel360에서 표준처럼 사용하는 ORM(Object Relational Mapper)이다. 나는 스프링 부트를 시작하면서 웹 어플리케이션도 같이 시작했다고 볼 수 있다. SQL쿼리문을 실행시키고 나온 테이블 결과를 일일이 객체에 저장해 줄 필요없이, 어플리케이션을 만들 수 있다는게 편리했다. (다른 의미로 조금 불안하기도 했다…)
개인적으로 데이터를 잘 다루는 것에 관심이 있으므로 자연스럽게 영속성에 대하여 깊게 공부하기 시작했다. 그런 과정으로 기술세미나와 오픈세미나 주제로 삼고 이해를 심도있게 하기 위해 준비 중이다.
Spring Security
Spring Security는 사용자 인증과 인가에 필수적으로 사용되는 세부 모듈로서 나는 주로 인가에 사용되는 JWT구현을 맡았다. 아직 이 모듈에 대한 이해는 매우 부족해보인다.
Spring Batch
Batch 작업은 서버에서 실시간으로 돌아가는 서비스와는 별도로 대용량 데이터를 한꺼번에 처리를 하거나, 루틴한 작업을 수행할 때 사용된다. Batch 작업을 도입하는 기능으로 통계 자료 산출과 메일링 서비스를 생각했지만, 두가지 기능 모두 스케줄러로 돌아가도록 로직을 수행하면 가능한 일이었다.
결과적으로 통계 부분은 로직으로 구현하였고, 메일링 서비스는 단일 작업 실행 단위 (Tasklet)으로 구현하였다. 앞으로 Batch 작업이 대량으로 필요할 법한 서비스를 올려두고 심도있는 고민을 수행할 기회가 있었으면 좋겠다.
"끝으로."
E2E는 끝났다. 말 그대로 끝에서 끝으로 진행된 프로젝트였다. 프론트엔드와 백엔드를 아우르는 프로젝트로서 두 종단을 잇는 작업을 처음부터 끝까지 맛을 본 과정이었다. 나는 이 과정을 나의 기술지도에 X축을 그렸다고 생각한다. 기술적 깊이를 갖추고 조금 더 입체적인 기술적 역량을 키워나가는 길이 열렸다고 본다. 그건 4개월 뒤 파이널 프로젝트 회고에서 쓸 수 있을 것이다.