starbooks 토이 프로젝트 회고록

LimHeeSang/starbooks_project: ✔⭐ 로그인, 리뷰, 좋아요, 도서 조회 기능이 있는 도서 홈페이지 (github.com)

 

 이번 팀 프로젝트를 하면서 정말 많은 것을 느꼈고 배웠다. 그리고 앞으로의 공부 방향성도 정할 수 있을 거 같아서 글로 정리하려고 한다. 

 

 

 일단 이번 프로젝트의 목표는 특별한 기술로 특별한 서비스를 만드는 것 보다는 프론트와 백엔드를 분리하여 간단한 토이 프로젝트로 협업하는 과정을 경험을 하는 것이었다. 나는 기술 스택으로 자바 + spring 프레임워크를 선택했다. 이번 프로젝트는 기술적인 목적을 둔 프로젝트가 아니였기에 기술스택 관련보다는 협업과정에서 느낀점과 부족한점에 대해서 말하고자 한다. 일단 팀원 모두가 협업하는 과정이 처음이었고, 모두가 같은 속도로 같은 시간에 개발을 하는것이 아니였기 때문에 서로간 나눴던 대화들, 회의 내용, 개인별 진행사항(공부, 개발, 삽질 등), api 스팩, 공부자료등과 같은 내용들을 어딘가에 기록하고 서로 공유할 수 있는 곳이 필요했다. 따라서 우리는 노션을 선택했다. 노션을 사용함으로 우리는 불필요한 의사소통을 줄이고, 개발과 공부에만 더 집중할 수 있었다. 

 

 또 프로젝트를 진행하면서 느낀건 모두가 다르다는 것이다. 이건 어찌보면 당연한거다. 사람은 누구나 다르다. 프로젝트를 하면서 느꼈던것은 개발에 투자하는 시간, 개발을 주로 하는 시간, 개발을 하는 속도, 개발을 하는 방법, 공부하는 방법, 새로운 기술을 받아들이는데 걸리는 시간등 모든것이 다르다. 나와 다르다고 해서 뭐라고 할 수 없는 노릇이다. 사람은 다 다르기 때문이다. 다른사람이 나와 다르다고 내가 느낄 수 있지만, 오히려 그 사람 입장에서는 내가 달라보일 것이다.

 나는 새로운 기술을 이해하는 능력과 습득력이 빠르지만, 잘 잊어버리기 때문에 충분한 복습이 필요하다. 다른사람은 나보다 새로운 기술을 이해하는 능력과 습들력이 낮아도, 나보다 기억력이 좋을 수도 있다. 또 나는 개발에 몰두할때는 3시간이상 길게 몰두하고 오래 쉬지만, 다른 사람은 50분씩 몰두하고 10분씩 쉬는 사람도 있을 것이다. 이 방법이 그사람의 개발 능률을 향상시키는 방법이라면 나와 다르다고 해서 틀리다고 말할 수 없을 것이다. 이렇듯 같은팀이지만 팀원들은 서로가 다르다. 이 다른점을 서로 이해하고, 타협하고, 존중해줘야 팀 프로젝트의 완성도가 올라가고 성공적으로 프로젝트를 마칠 수 있을 것이다.

 

 팀 프로젝트를 할 때 나는 열정이 넘처있어서 하루에 상당 시간을 개발에 쏟아부었던적이 있다. 하지만 나혼자 개발을 하고 공부를 한다고 해서 프로젝트가 완성되는게 아니였기 때문에 팀원들이 개발과 공부에 좀 더 시간과 열정을 투자해줬으면 좋겠다는 생각을 했었다. 위에서 말했듯이 모두가 다르고, 내가 강요할수도 없기 때문에 나는 팀원들의 열정을 끌어올릴 수 있는 방법을 생각했다. 그것은 더 열심히 하는 모습을 보여주는 것이었다. 당시 도전을 시작했던 1일 1커밋 운동을 소개했고,  2주에 3번정도 프론트와 백엔드 분야 모두 개발하는데 필요한 지식인 Http, Api 관련 지식들의 자료를 정리해서 팀원들에게 발표하는 시간을 가졌다(관련 내용은 블로그에 정리되어있다). 이 발표를 시작한 이유는 단지 내가 공부한 지식을 공유하는 것이 아니라 서로가 개발 공부를 하면서 유익한 지식들을 자발적으로 팀원들에게 발표하여 팀원들과 본인에게 도움이 되고, 팀 프로젝트에 자발적으로 기여도를 높이게끔 하기 위해 내가 먼져 발표를 시작했다. 이러한 나의 노력을 봐주었는지 팀원들의 능률이 많이 올라가서 팀 프로젝트를 성공적으로 마칠 수 있었다.

 

 

 이제 나혼자 자바 + spring으로 개발 공부를 하고 프로젝트를 진행하면서 느낀점에 대해서 써보려고 한다. 일단 나는 지금 자바와 spring으로 개발을 할 수 있다. 프로젝트를 진행하면서 springsecurity도 공부하여 프로젝트에 적용했다(spring security관련 깃허브에 정리되어있음). 이렇듯 나는 새로운 기술을 이해하고 받아들이는데 빠르다고 생각한다. 하지만 프로젝트를 진행하면서 많은 것들을 느꼈고, 앞으로의 공부 방향성도 정할 수 있게 되었다.

 첫번째로 java라는 언어의 깊이있는 이해가 필요했다. spring 프레임워크는 자바로 이루어져 있고, 나는 지금 자바로 코딩을 하고 있다. 물론 지금 이상태로도 코딩을 하는데는 문제가 없다. 하지만 이 상태로 spring 프레임워크에 대해서 더 깊이있는 학습이나 관련된 기술을 습득하고 심도있는 프로그래밍을 하는데 문제가 있다고 판단했다. 어느 프로그래밍 언어에나 있는 변수, 연산자, 메소드, 클래스, 컬렉션, 반복문, 조건문과같은 기본적인 문법개념을 자바언어로 활용할 수 있지만, spring 프레임워크를 뜯어볼 수록 제네릭의 깊은이해, 다른사람의 좋은 코드를 공부하는데 부족한 람다와 스트림 그리고 리플렉션, 쓰레드, 입출력 문법등에 대한 공부가 필요하다고 생각했다. 따라서 프로젝트가 끝나고 또 다른 프로젝트를 시작하여 이미 경험해 보았던 api기능을 만드는 과정 대신에 자바 언어에 대한 깊은 공부가 프로그래머로 성장하는데 더 좋은 길이라고 판단했다.

 

 두번째로 내 코드가 맞는 코드인지, 버그 없는 코드인지, 기획자의 의도대로 제대로 작성된 코드인지 어떻게 검증하지?라는 의문이 들었다. 개발했던 과정을 돌이켜보면 api기능을 완성하고 테스트 해보는 과정은 postman을 통해서 요청을 보내고 로그를 찍어서 확인하고 db의 결과를 확인해보는 통합 테스트 과정 뿐이였다. 물론 나중에는 이러한 통합 테스트도 진행을 해야한다. 하지만 프로그래밍 과정에서 이러한 식으로만 테스트를 진행하면 매 테스트마다 시간이 오래걸리고, 하나의 테스트가 다른 테스트에 의존하게 된다. 예를들어 하나의 기능이 버그가 있지만, 통합 테스트에서 잡지 못해서 계속 개발을 진행하고 이 기능을 다른 테스트 기능에서 의존하게 되는 경우에 버그가 발생했다면, 나중가서는 어디에서 버그가 발생했는지 잡기 힘들고, 버그 잡기에 시간이 엄청 걸리게 된다. 토이 프로젝트나 예제 수준에서야 금방 잡을 수 있겠지만 프로젝트가 좀만 커져도 이러한 문제점이 들어나게 된다. 또한 이러한 통합 테스트만을 의존하면 그 시점에는 통과했지만 내가 생각하지 못한 예외상황이 나중가서는 큰 버그로도 이어질 수 있기 때문에 자바의 테스트코드 와 관련된 라이브러리인 Junit, assertj와 TDD와 같은 테스트 주도 개발과 관련된 공부가 필요하다고 생각했다. 따라서 자바의 깊이있는 공부와 TDD를 공부한 후 다음 프로젝트를 진행하는 것이 좋은 프로그래머로 성장하는데 더 좋은 길이라고 생각했다.

 

 마지막으로 클린코드와 객체지향의 개념이다. 프로젝트를 진행할 때 클래스를 설계하고 코드를 작성하는 것은 누구나 할 수 있고 하는 과정이다. 하지만 객체지향의 관점을 잘 살려서 변화에 대응할 수 있고, 확장성이 있는 클래스를 설계하는것과 깔끔한 코드 즉, 유지보수성이 있고, 누군가 보고 이해하기 좋은 코드를 작성하는 것은 쉽지 않은 일이다. 하지만 급변화하는 사회에서 소프트웨어도 시시각각 변화를 요구받기 마련이기 때문에 변화에 질질 끌려가기에 앞서려면 클린코드와 객체지향적 설계는 필수 역량이다. 이러한 공부를 하지않고 프로젝트가 끝났다고 해서 다른 프로젝트에 바로 들어가거나 spring의 공부를 더 진행한다면 앞으로도 이러한 개념들을 공부하지 않거나 전혀 모르는 개발자가 될 확률이 높다고 생각한다. 위에서 말했듯이 service메소드에 모든 비지니스 로직을 담고, 테스트라곤 매번 브라우저단에서 직접 기능을 테스트하고 db를 확인하는 테스트하는것밖에 모르는 개발자가 될 확률이 높다. 따라서 클린코드와 객체지향프로그래밍과 같은 개념들을 공부하고 다음 프로젝트에 적용을 해보는게 좋은 프로그래머로 성장하는데 저 좋은 길이라고 생각한다.

 지금까지의 나혼자 자바 + spring으로 개발 공부를 하고 프로젝트를 진행하면서 느낀점을 정리해보자면 자바언어에 대한 깊은 공부를 하고 테스트코드/OOP/클린코드를 공부하여 다음 프로젝트에 적용하고 협업하는 과정을 경험하는게 목표이다.

 

 

 나름 시간이 흐르고 나름대로 공부(tdd, 객체지향, 클린 코드)를 한 후에 해당 프로젝트의 코드를 살펴보았다. 코드를 살펴보니 깃허브에 공개하기조차 부끄러운 코드들의 나열이였다. 테스트코드가 없는건 당연했고, 수많은 중복된 코드들의 존재, 많은 객체의 핵심 로직이 엔티티가 아닌 서비스 계층의 클래스의 밀집되어있었다. 한마디로 말하면 객체지향적이지 못했다. 또한 하나의 메소드의 코드가 너무 길며 여러가지 일을 하고 있고, 하나의 클래스는 여러 책임을 가지고 있었다. 그냥 기능만 구현되어있는 쓰레기코드에 불가했다. 그래도 지금 이러한 것들이 눈에 보이는 것 자체가 내가 많이 성장했다라는 것을 느껴서 오히려 뿌듯하다.