배포 링크: Gijol
배경
GIST 청원 프로젝트를 진행하면서 크게 제품의 코드 작성법과 테스트, Operation, Git flow 등을 배울 수 있었다. 이를 청원팀의 팀원으로서 배웠던 점이 많은데 과연 이 배운 것들을 내가 스스로 해나갈 수 있을지에 대해서 의문이 들었다. 이에 대한 중요성과 필요성이 너무나도 중요하게 느껴졌기에 프로젝트에서 사용하면 좋은 부가적인 것들이 아니라, 필수적인 것들로 느껴졌다. 그렇기에 새로운 프로젝트를 진행하면서 배운 방법론적인 부분을 적용해보고 싶었다.
Gijol 프로젝트는 기존에 진행하던 프로젝트를 완성하지 못해 아쉬움이 남아 진행한 프로젝트이다. 학교 졸업요건을 특별히 확인할 수 있는 서비스가 아직 없기 때문에 이를 학사편람과 직접 비교와 대조하면서 졸업요건을 확인해야 했고, 이 부분에서 졸업요건 확인을 심지어 놓쳐 한 과목 때문에 졸업을 못하는 사례도 발생했다. 이 부분에서 Pain Point는 확실하다고 느꼈고 본격 프로젝트를 진행하게 되었다.
성장
뿐만 아니라 내가 생각하는 좋은 팀이라는 기준에 맞아서 진심으로 몰입해보고 싶다는 생각이 들었다. 팀 상태는 한 명은 운영은 아니지만, 기본적인 FE 개발 경험이 있었고. 한 팀원는 개발을 처음 진행해봤지만, 몰입의 중요성을 너무나도 잘 알고 현 상황에서 팀에 도움이 되는 본인이 할 수 있는 최선을 다했었다. 그에 따라 개발적인 성장도 놓치지 않으면서 최대한 도움을 받을 수 있는 부분을 활용하면서 성장을 해나갔다. 그 결과 React + Typescript를 2달 가량만에 코드적인 부분에 기여를 할 수 있었다.
이 팀원의 성장은 크게 모르는 것과 대해 투명하게 공유한다는 점에서 기인했다고 생각한다. 처음 개발을 해보는 팀원이 본인이 겪는 어려움에 대해 우연히 말을 하다가 겪었던 어려움을 들었다. 이에 대한 어려움을 호소할 때 혼자 고민했던 부분, 병목이 되었던 부분, 그로 인한 본인이 느끼는 감정을 공유함으로 충분히 공감이 되었다. 이를 통해 우리 프로젝트를 진행하는데 학습에 대한 시간이 더 필요하다고 판단해 일정 조율을 하는 현실적인 대안을 세울 수 있었다. 그 결과 팀원이 성공적으로 코드를 기여하고 자신감을 되찾을 수 있었다. 뿐만 아니라 팀의 전체적인 생산성도 높였다. 이를 통해 같은 팀원과 투명한 의사소통을 통해 발생할 수 있는 위험을 줄일 수 있었다. 이후 현업에서 나도 같은 상황에 놓일 수 있는데, 일정에 영향이 갈 정도의 정말 어려운 부분에 대해 부끄럽다고 느껴 위축되고 문제를 만들기보다 투명한 공유가 필요할 수 있겠다는 생각이 들었다.
개인적으로 반성하게 되는 점이 나는 무언가를 잘못한다는 생각이 들때 마다 너무나도 부끄러워 위축되는 경향이 있다. 항상 거기서 현실적인 대안으로 한 걸음 더 발전해나가려 생각해보지는 못하는 것 같다. 이에 대한 의식적인 개선이 필요하고 적용해나가야 한다.
What I did
내가 진행하고 고민한 부분들을 요약하면 다음과 같다.
전반적인 Project Management 및 조직 관리
- Backlog 작성을 진행한 후 Sprint를 진행
- Linear 도입을 통해 스크럼 보드 도입
- 팀 작업 규칙(Working Agreement) 도입
- 1차 릴리즈 후 Sailboat 회고 진행
- 새로운 기술 도입에 대한 의사결정 조율 → 이 기술이 우리에게 정말 필요한가?에 대한 고민
프로젝트 Automation of Operation
- Github Action을 통해 FE, BE 배포 자동화 → 구축을 통해 배포 자동화를 통한 생산성 향상을 팀에 알릴 수 있었다.
- Git Flow → dev, prod를 통해 브런치를 관리하고, merge 규칙에 대한 논의를 진행했다. 또한, 브랜치 네이밍 컨벤션에 대해서도 논했다. 이를 통해 스타일에 대한 통일을 진행했다.
- Github와 Linear의 통합, Linear과 Slack 알림 통합
벡엔드 API 개발
- 졸업요건 확인 객체에 대한 도메인 설계 및 구현
- POI를 활용한 Excel 파싱
What I Learned
기본적인 프로젝트 운영 방식
함께 일하는 것은 효율을 극대화하기 위해 진행하다는 것을 배울 수 있었다. 기존에 토이프로젝트는 여러번 리딩을 진행해봤지만, 실제로 런칭할 프로젝트를 리딩해본 경험은 처음이었다. 프로젝트를 진행해보면서 어느 정도 서로가 일적인 가치가 맞는 팀원이었기에 방법론 도입에 대한 공감대 형성이 잘 되었던 것 같다.
SW 마에스트로를 진행하면서 에자일, 스크럼, 협업에 관한 특강을 관심을 갖고 열심히 들었다. 이를 Gijol 프로젝트에서 바로바로 사용할 수 있었던 점이 굉장히 체화하기 좋았었다. 이 경험을 바탕으로 SW마에스트로 과정도 비슷하게 운영해나갈 계획이다.
도메인 설계와 테스트
졸업요건은 전공, 교양, 기초과학, 기타과목과 같은 각각 분야에 대한 조건을 맞춰야 충족할 수 있다. 이를 하나의 객체에 모두 책임을 지게하는 것은 데이터 주도적인 설계로 느껴 각각 분야를 하나의 객체로 둬서 책임을 분할했다. 예를 들어, 전공은 Major라는 객체로, 기초과학은 BasicScience 라는 객체로 분리했다. 이는 각각의 책임이 명확해질 뿐더러 각 기능에 대한 테스트도 용이했다.
특별히 데이터베이스를 사용하지 않기 때문에 비즈니스로직이라고 할 것들이 크게 없었다. 다만, 졸업요건을 확인하는 알고리즘을 짜는데 시간이 걸렸다. 처음에는 단순 알고리즘이기에 테스트를 미뤘다. 이는 굉장히 오만했음을 느낄 수 있었다. 테스트를 안짜고 변경에 취약한 부분들이 테스트를 통해 오류가 너무나도 많이 발견되었다. 이는 결국 운영서버에 배포까지 오류가 생겼고, 결국 각각 전공에 대한 유닛테스트를 모두 작성하게 되었고 기본적이고 중요한 기능에 대한 기능은 유닛테스트를 반드시 해야된다는 것을 느꼈다.
TMI로 jar 빌드에서 classResource를 getFile() 하게 되면 빌드가 깨진다. 이는 jar에서는 File://와 같은 프로토콜을 제공하지 않아서라고 한다. 이는 getInputStream() 을 사용해야된다는 것을 느끼게 해줬다.
To-do
회고를 진행했을 때, 코드적인 부분의 투명한 공유가 부족했다는 점이 우리팀의 합의안 중 하나였다. 그렇기에 코드리뷰 문화를 일의 진행에 차질이 생기지 않는 선에서 강제하기로 Working Agreement를 추가했다. 나는 Java Spring 기반의 코드를 주로 작성하기에 FE 부분에 코드리뷰에 관여를 하기 어려웠다. 다만, 팀원들 스스로 객체 지향 설계의 필요성과 코드 개선에 대한 필요성을 너무 느끼고 있는 상황에서 내가 할 수 있는 것을 생각해보게 되었다.
Spring은 SOLID를 어느정도 Framework에서 강제한다. 그렇기 때문에 객체지향 설계에 대해 꾸준히 고민하게 된다. 뿐만 아니라, 우아한테크코스 프리코스 과정을 통해 객체지향 설계에 대한 고민을 진행해봤고, 최근에 객체지향 프로그래밍 수업에서 프로젝트(프로젝트는 객체지향과 사실과 오해라는 책에 소개한 객체 지향을 입각해 진행했다)를 진행하면서 객체 지향 설계에 대한 설명을 가장 잘할 수 있을 때가 아닌가라는 생각을 하게되었다. 뿐만 아니라 기존에 나는 데이터 주도 설계를 진행해보고 이는 객체 지향적이지 못하다는 것을 느꼈고 이 경험을 공유해주면 팀적으로 너무나도 좋을 것 같다는 생각이 들었다.
이러한 생각을 바탕으로 React를 코드리뷰가 가능한 선에서 공부해보기로 결심했다. 이는 장기적인 팀적 성장으로 봤을 때 팀적 생산성이 복리로 돌아올 수 있을거라 느껴 공부를 시작한 것이다. 또한, 새로운 것에 대한 학습으로 받아들일 수도 있겠다 내가 생각하는 학습이 맞는지에 대한 검증을 할 수도 있겠다. 이를 바탕으로 최대한 빠른 시간으로 React라는 것에대해 공부를 해보고 코드를 어느 정도 작성해보면서 Gijol 팀의 리뷰 문화를 개선하는 것을 목표로 두고있다.
벡엔드 개발자로서 역량도 향상에 힘쓸 생각이다. Gijol MVP는 DB 사용이 필수는 아니라는 것이 결론이었기 때문에, 아직 DB를 사용하지 않는다. 다만, 졸업요건 확인의 상태 유지를 할 계획이라는 점과 강의평가 기능을 추가한다는 점으로 사용자의 uniqueness를 검증해야 한다. 그렇기 때문에 다음 스프린트부터는 DB 도입을 진행할 계획이다. 그렇기에 DB와 설계에 대한 고민과 JPA 도입을 염두하고 있다.
마지막으로
아직 부족하게 많은 프로젝트였지만, Gijol 첫 MVP는 개발자로서 내가 중요하게 여기는 가치, 개발자를 너머 삶의 가치까지 생각해보게 되는 뜻깊은 시간이었다. 생각했던 것이 실현되는 것만큼 기쁘고 자아실현에 도움을 주는 것은 없는 것 같다. 물론 이 기대가 너무 커지면 불행으로 다가오는 것을 항상 인지해야 한다. 기대가 너무 크면 실망도 그에 상응한다.
공동 목표를 지닌 팀원들과 함께 정말 진심어린 몰입을 통해 기대 이상의 가치를 느끼는 것은 어떤 가치와도 맞바꾸기 어려운 것같다.
프로젝트는 본 링크에서 확인하실 수 있습니다.