쇼핑몰 개인 프로젝트 회고

5월부터 진행해온 1인 개발로 3개월 가량 진행해온 쇼핑몰 프로젝트의 마무리가 되어감에 따라

프로젝트 동안 겪었던 내용과 감정들을 정리해놓고자 합니다.

 

프로젝트에 대한 세부 내용은 깃허브의 README로 대체합니다.

프로젝트 시작 이유 및 선택

2달의 기간 동안 동영상이나 책을 통해 이론으로만 공부하다 보니 머리 속의 지식들이 workflow 형태로 정리되는 것이 아닌 파편적으로 퍼져있다고 느껴졌다.

예를 들어 어떤 기능을 만든다고 생각하고 머리 속으로 쭉 흐름을 따라가다 보면 계속 군데 군데 내용이 '기억나지 않아서' 코드를 작성하지 못 하는 것이다.

기억이 나지 않는다는 것은 해당 내용을 이해한 것이 아니라 외운 것에 불과하다는 의미였으므로 이 문제를 해결할 방법이 필요했다.

백견이불여일타라는 프로그래밍 농담처럼 역시 프로젝트를 직접 진행하는 것이 최선이라 판단했다.

 

프로젝트를 진행하는데 있어 테마를 먼저 정해야 했는데 요구 조건은 다음과 같았다.

 

• 가능한 한 많은 기능을 구현해볼 수 있을 것
• 참신한 아이디어가 아닌 본인이 많이 써본 테마일 것
• 대량의 트래픽이 들어온다는 가정을 해볼 수 있을 것

커뮤니티와 이커머스 2가지 선택지가 나에게 가장 적합한 후보였고 이 중 레퍼런스가 많고 서버 사이드의 많은 기능을 직접 구현해볼 수 있는 이커머스를 테마로 결정하였고 쇼핑몰 프로젝트를 시작하게 되었다.

 

배우거나 얻은 점

고민할 거리가 많았던 것

전체 개발 기간 중 80%가 넘는 시간은 다음 요소 등에 의해 쓰여졌다.

 

• 애플리케이션의 동작 원리에 대한 이해
• 더 좋은 변수명과 코드의 가독성을 위해 고민
• 최대한 많은 시나리오를 커버할 수 있는 테스트 코드를 위한 고민
• 코드의 성능 개선 가능성에 대한 고민
• 코드 작성 이후의 리팩토링 가능성에 대한 고민

되돌아 생각해보면 코딩을 하는 시간은 전체의 일부분에 불과했고 대부분은 더 좋은 코드를 찾기 위해 구글링하고 개념을 익히는 것에 대부분의 시간을 할애한 것같다.

 

문제 하나를 해결하기 위해 검색하기 시작하면 모르는 지식들이 꼬리에 꼬리를 물고 나와 수 시간이 지난 후에 보면 십 수 개의 크롬 탭이 틀어져 있는 경우도 허다했다. 그럼에도 결국 원리를 이해하고 나서 하나 하나 탭을 꺼가며 공부했던 흐름을 리마인드할 때 가장 큰 성취감을 느낄 수 있었다.

 

전체적인 흐름을 이해할 수 있었던 것

프로젝트를 진행하며 가장 곤혹스러웠던 점은 서로 다른 요소들이 어떻게 소통하는지 감이 오지 않았던 점이다. 예컨대,

1. Java 레벨에서 클래스와 클래스간의 데이터를 주고 받는 방법
2. Spring과 같은 Framework 레벨에서 레이어간의 데이터 이동 방식
3. 백엔드에서의 프론트엔드로의 데이터 이동 vice versa
4. 서로 다른 애플리케이션간의 커뮤니케이션 방식
5. 네트워크를 통한 데이터 이동 방식

등과 같은 점들이 있었고 해당 문제들은 다음과 같이 해결될 수 있었다.

 

1, 2, 3 : 하나의 애플리케이션 내에서 발생하는 기능들이었으므로 프로젝트를 진행하며 자연스럽게 이해하고 체득할 수 있게 되었다.

4 :  대부분의 소스 코드가 작성될 즈음 시스템 디자인의 애플리케이션들을 동작하고 연결시키면서 경험해볼 수 있었다.

5 : 노트북으로 개발하고 데스크탑을 홈 서버로 웹 애플리케이션을 배포해보며 네트워크의 기본 요소를 경험해볼 수 있었다.

 

매 흐름에 대한 경험이 본인에게 더 큰 시야를 가질 수 있게 해주었고 아직도 이해가 부족하고 모르는 것이 많다는 것을 알기에 앞으로 얼마나 더 많은 '모른다는 것을 인지하지도 못 한 기술'들이 있을지가 기대된다.

 

문제였던 점이나 아쉬웠던 점

테스트, 주석, 문서화의 중요성을 너무 늦게 깨달은 것

프로젝트를 시작하기 전에 테스트, 주석, 문서화 (이하 기본기)가 중요하다는 글을 몇 번 본 적이 있었지만 크게 피부로 와닿지 않았다.

그리고 한 달의 기간 동안 이런 기본기를 작성하지 않은체 기능 구현 위주로 프로젝트를 진행했다. 

 

그러던 중 기능이 점점 복잡해지고 코드의 양이 쌓여가면서 왜 그렇게 다른 사람들이 기본기의 중요성에 대해 말하는지 알 수 있었는데 본인이 느낀 점들은 다음과 같다.

 

테스트 코드가 없다면 프로젝트 진행 속도가 현저히 느려진다.

테스트 코드를 작성하지 않을 때에는 end to end로 서비스 레이어에서 기능 하나 작성하고 UI를 직접 보면서 기능이 원하는대로 잘 구현되었는지, 문제는 없는지 확인을 했다. 

초반에는 서버를 재시작해가면서 기능의 동작 여부를 확인하다가 점점 느려지는 진행 속도에 문제점을 느끼고 spring의 dev tools 기능인 live reload를 활용하여 end to end의 기능 확인이 그나마 빨라질 수 있었다.

 

하지만 '내가 어떤 버튼을 누르면 어떤 기능을 한다.'라는 단순 CRUD를 넘어서서 지금 당장 화면으로 구현하기 힘든 기능들을 구현해야 하면서 테스트 코드의 중요성을 깨닫기 시작했다.

(e.g. 유저는 물건을 구매하고 배송 완료가 되면 리뷰를 작성할 수 있고 리뷰에 따른 포인트 지급은 유저의 리뷰 내용에 따라 달라진다.) 

 

이후에 JUnit과 Mockito를 공부해가며 서비스 레이어에 테스트 코드를 적용하기 시작했고 테스트의 중요성을 느끼고 나서 공부하니 빠르게 습득할 수 있었지만 한편으로는 상당히 고통스러웠다.

오래 전에 작성한 코드에 대한 기억을 다시 끄집어내서 테스트 코드를 몰아서 작성하는 점이 문제였다.

 

테스트 코드가 선택이 아닌 필수라고 생각한다면 TDD가 합리적이라 생각되었고 다음에는 꼭 TDD나 그에 준하는 테스트 코드를 작성하리라 생각하며 수십 개의 테스트 코드를 며칠 동안 작성하는 시간을 가졌다.

 

주석과 문서화가 없다면 그 코드가 어떻게 동작하는지는 신만이 아신다.

주석, 문서화에 대해서 혼자 프로젝트를 진행하는데 필요성에 대한 의문을 가졌었고 테스트 코드의 경우처럼 기능 위주의 구현으로 프로젝트를 진행하였다.

 

프로젝트를 시작하고 며칠, 몇주까지는 모든 기능들이 어떻게 동작하는지 기억에 남아있고 이땐 이걸 이렇게 사용해야지 했지만 테스트 코드의 경우처럼 기능들이 많아지고 복잡해지고 시간이 지나면서 문제가 발생했다.

분명 본인이 작성한 코드인데 왜 이 코드를 작성한건지, 이 코드가 왜 이렇게 동작하는건지 전혀 이해가 가지 않았다..

작성할 당시에는 나 자신과 신만이 코드가 어떻게 동작하는지 알고 있었지만 이제는 신만이 어떻게 동작하는지 알게 되는 상황이 온 것이다.

 

본인이 작성한 코드를 한참을 들여다보고 내부 코드를 이해하면서 시간을 쓰는 동안 남을 위해서가 아닌 나를 위해서라도 상세한 주석과 문서화가 필요함을 온 피부로 느낄 수 있었다.

 

하지만 그럼에도

하지만 그럼에도 만약 다시 되돌아가서 프로젝트를 멘땅에서 시작해야 하는 상황에 똑같이 처해진다면 테스트, 주석, 문서화에 대한 공부없이 프로젝트를 시작할 것같다.

일단 시작하기의 중요성을 깨달았기 때문이다. 처음부터 테스트 코드를 어떻게 작성하고 주석은 어디에 어떻게 달아야 하고 로그는 어떻게 작성하는지 모든 것을 공부하고 시작해야 했다면 필요한 것을 공부하는 즐거움에 대한 인지없이 프로젝트를 진행했을 것이다.

 

더욱이 미리 공부하고 테스트, 주석, 문서화, 로그를 작성하면서 기능을 구현했다면 그것들이 왜 중요한지 직접 깨닫는 계기가 없었을 것이라 생각하고 과거의 나를 반면교사로 삼을 수 있는 좋은 기회였다고 생각한다.

 

실제 트래픽을 받아볼 수 있는 서비스를 만들지 못한 것

처음 진행하는 프로젝트로 실제 트래픽을 받아보고 부하에 대한 걱정을 해보는 것은 실현 가능성이 낮다는 것을 알고 있기 때문에 크게 아쉬운 부분은 아니라고 생각한다.

하지만 성능을 개선하고 더 좋은 서비스를 만드려고 하는 노력에는 역시 그에 따르는 실제로 목을 조여오는 듯한 압박감(..)이 있어야 한다고 느꼈다.

 

프로젝트를 진행하며 계속 '이럴 것이라고 가정'을 하며 트래픽을 상상하고 기능을 구현하다 보니 약간 김이 빠지는 듯한 혼자서 레고 놀이하는 듯한 느낌을 지울 수가 없었기 때문이다.

 

이후에는 아무리 조그만 프로젝트를 하더라도 누군가의 불편함을 해소할 수 있는, 그러면서 돈까지 벌리면 더욱 좋은, 그런 프로젝트를 만들어보고 싶다. 

 

다른 사람과 협업을 해볼 기회가 없었던 점

다른 사람과 함께 깃플로우를 이용하여 깃 관리도 해보고 컨플릭션도 겪어보고 슬랙, 지라같은 협업툴도 써보고 싶었으나 해당 프로젝트를 진행하며 그럴 기회가 없었던 점이 아쉽게 남았다.

혼자서 상황을 가정해보고 시뮬레이션을 진행해보는 것은 아무래도 한계점이 크고 문제를 해결한다는 느낌이 들지 않아 진지하게 임하기가 힘들었다. 

 

또한 서로의 코드를 리뷰하고 서로간의 더 좋은 코드를 위해 아이디어를 개진해보지 못 한 것 등도 아쉽게 남았다. 

 

프로젝트 진행 중 겪은 문제를 전부 문서화시켜두지 않은 것

프로젝트에 겪었던 문제나 깨달았던 점을 한 톨도 빼지 않고 전부 기록해두지 않은 것이 많이 아쉽다.

중요하게 생각되는 부분들을 기록해두었지만 문제를 해결했을 때의 순간만 작성해두어 그 당시의 문제점이나 문제로 인해 겪은 고통, 문제 해결을 통한 깨달음과 같은 감정이 제대로 남아있지 않은 점이 아쉽다. 

시도해보고 싶은 점

실제 트래픽을 받을 수 있는 TDD로 진행하는 협업 프로젝트

다음 프로젝트는 다른 개발자들과 함께 트래픽을 받을 수 있는 테마로 정하여 진행해보고자 한다.

그리고 TDD로 진행해보고자 한다. 이왕 테스트 코드의 중요성을 깨달았으니 테스트가 주도하는 프로젝트를 해보는 것도 좋은 경험일 것이라고 생각된다. 그리고 정말 TDD가 효율이 좋은지, 좋지 않은지 코드의 품질이 올라가는지 등에 대해서도 직접 경험해보고 싶다!

 

전체적인 큰 그림을 먼저 그려보기

이번 프로젝트는 아무것도 없이 시작하여 처음부터 멘땅에 헤딩으로 하나씩 문제를 해결해나가는 바텀업 방식으로 구현되었으므로 다음 프로젝트는 전체적인 아키텍처와 ERD 등을 먼저 구상하고 그에 따라서 옆길로 새지 않고 해당 내용만 탑다운으로 진행해보고자 한다.

 

공부하는 개념으로 바텀업만큼 적절한 프로젝트 진행 방식이 없었지만 반대로 큰 그림이 그려지지 않고 시작하다 보니 이 기능도 구현해보고 싶고 저 기능도 구현해보고 싶고 다른 툴도 써보고 싶고 계속 다른 지식들이 눈에 밟히다보니 유야무야 프로젝트가 진행된 감이 없지않아 있었다.

 

프로젝트에는 언제나 데드라인이 존재하므로 그 데드라인을 맞추기 위해서 전체적인 큰 그림을 그리는 것을 필수일테니 먼저 틀을 잡는 능력을 수련해보고자 한다.

 

모든 문제점, 해결 방법 등에 대해서 문서화하기

이번 프로젝트를 진행하며 공부했던 내용을 깨닫고나서 대부분 머리 속에만 남기고 정말 중요하다고 느껴지는 것들만 기록하여 두었는데 이후에 이에 대해 아쉬움이 많이 남았다.

 

다음 프로젝트에는 어떤 것이 문제점인지, 그것을 왜 문제라고 생각하는지, 그 문제에 대한 해결책은 무엇이 있는지, 해결책 중 무엇을 선택하였는지, 개선점 수치화하기 등을 중점적으로 문서화해보자 한다.

 

그리고 아무리 사소한 문제점이라도 꼭 기록하자. 이 정도는 기록하지 않아도 괜찮겠지 하지 말고 모든 내용을 문서화하기!