[회고]202010_4주간의 첫 번째 프로젝트_S*FU

 

 

코딩에 관심을 가지게 된 것이 작년 5월 쯤이니까, 개발자라는 직무에 관심을 가지고는 약 1년 반, 그리고 본격적으로 개발자가 되기 위해서 올해 2월부터 부트캠프를 시작하여 공부를 한 지 8개월 가량이 흐른 것 같다.

진짜 아무것도 몰랐을 때, 두려움, 의심, 그리고 기대감을 가지고 시작했다. 

그리고 그 수많은 커리큘럼과 과제 그리고 페어프로그래밍을 끝내고 기대했던 첫 번째 프로젝트를 시작하게 되었다.

 

첫 번째 프로젝트 때는 서비스 구현도 중요하지만, 우리가 배운 것들을 실질적으로 활용하는 방법을 익히는 것도 중요했다. 

그래서 최대한 기술 스택들을 새로운 것을 배우기 보다는 기존에 배운 것을 제대로 이해하는 것에 초점을 맞추었다.

따라서 가장 어려웠던 부분, 혹은 깨달음을 크게 느낀 부분들을 위주로 간추려서 회고해보려한다.

 

첫 번째 프로젝트의 아이디어는 "부트캠프 후기 공유 커뮤니티 사이트" 였다.  

개발자로 커리어 전환 혹은 코딩공부가 하나의 트렌드로 자리 잡으며, 많은 부트캠프가 생겨나고 있는 요즘, 수강생들의 생생한 후기를 담을 수 있는 리뷰사이트를 만들어 보는 것이 어떻냐는 상현님의 제안에 모두 동의 하였으므로 빠르게 아이디어가 결정 되었다. 

나조차도 개발자라는 직무에 관심을 가지고 나서 코드스테이츠를 시작하기까지 시간이 꽤 걸렸고, 그 이유는 확실한 커뮤니티가 부재했기 때문이다. 각 부트캠프가 홍보하는 수강생들의 리뷰는 (내 기준에서는 당연하게도)신뢰가 가지 않았고, 나조차도 사실 코드 스테이츠에 대한 확실한 정보와 신뢰를 가진 지인의 소개로 좀 더 확신을 가지고 시작할 수 있었을 정도로 부트캠프에 대한 정보는 생각보다 다양하지 않았다.

지금은 부트캠프가 더 늘어나서 어느정도 후기를 다양하게 들을 수 있지만, 그래도 좀 더 솔직하고 적나라한 이야기를 듣고 싶은 사람들의 니즈가 있을거라는 생각에 해당 아이디어를 선택하게 되었다.

프로젝트 기획 및 백엔드 개발

프로젝트 기획(SR)

프로젝트의 SR들은 블로그에 별도로 정리해 두었으니 만약에 궁금하다면 이 링크 로 들어가서 확인해보면 된다. 
이번 글에서는 프로젝트에 대한 전반적인 정리와 회고를 해보고자 한다.

SR(Software Requirement)는 시스템이 목표 달성을 위해 갖춰야하는 기능, 또 그러한 기능을 정리한 문서를 뜻한다.

즉 지금까지는 주어진 과제에 대한 코드 작성에만 집중했다면, 이제는 정말 서비스와 기능 구현을 목적으로 기획 단계부터 고민을 해야 했다.

 

뭘 모르는 지를 알고, 어떻게 해결할 지를 고민하는 것도 어려워

제목으로 달아둔 말이 딱 당시의 내 심정이었다. 서비스를 기획하기 위해서 무엇을 고민해야 하는 것인지, 나는 무엇을 모르는 것인지를 파악하는 것조차 어려웠다. 코드를 작성하고 기능을 구현하는 것만큼? 아니 그거보다 더 어려웠다. 

 

사용자로써, 그리고 서비스 제공자로써 번갈아 가며 깊이 있게 고민하고 사람들이 너무 당연하게 생각해서 놓치기 쉬운 기능들까지 세세하게 잡아내는 작업을 위해 엄청나게 많은 고민을 했던 것 같다. 지금 생각해보면, 코드스테이츠의 프로젝트는 단순히 코드를 잘 짜는 개발자도 중요하지만, 자신이 구현하는 기능과 이 기능들이 이루는 서비스 자체에 대한 깊은 고민까지 가능한 개발자가 되게 하려는 것인가? 라는 생각이 들정도였다. DB 스키마를 짜는 것부터 API 문서를 작성하는 것까지, 심지어 Git으로 프로젝트 task card를 만들어서 일정 관리를 하는 방법에도 허둥지둥이었고, git work flow도 처음에 이해가 되지 않아서 팀원들과 몇 번이고 반복적으로 물으며 공부했었다.

 

 

정확한 소통, 질문은 자신감 있게

이렇게 허둥지둥했음에도 불구하고, 생각보다 빠르게 SR을 끝내고 코드 작업을 할 수 있었던 이유가 팀원들간의 정확한 소통과 머뭇거리지 않고 모르는 것은 언제든 물어보는 태도들이었다.  누군가가 열심히 제안한 아이디어에서 좀 더 보완했으면 좋겠는 부분에서는 확실하게 말하고 그 것을 빠르게 받아들였고, 제대로 이해가 가지 않는 부분에서는 부끄러워하지 않고 서로 질문을 함으로써 세세한 부분까지 채워가며 기획할 수 있었다.

 

Database _ Sequelize ORM

database를 세팅하고 이 후에 server에서 db로 요청하는 ORM 코드를 작성할 때 나는 sequelize 공식문서를 항상 켜두고 진행했었다.

영문이라서 불편하지 않았을까 라고 생각할 수도 있지만, db 세팅에서 생각보다 고생했을 때 여러 구글링을 해봤지만 공식 문서 만큼 정확한 설명은 없었기에 공식문서를 가까이 하라는 말이 엄청 와닿았다.

 

DB 초기 세팅하기.

database를 공부할 때 접했던 sequelize는 (말하기 부끄럽지만) 쉽고 간편하다고 생각했다. 하지만 실제로 DB schema를 짜고 그에 따라 DB세팅할 때 엄청 어려웠던 기억이 난다. 환경파일 설정부터 헤맸으니 말 다했지...🤦🏻‍♀️ 공부할 때는 그냥 지나쳤던 config 파일 설정들에 된통 혼나며, 어떠한 개념을 적용하고 코드를 작성할 때는 우선 확실하게 이해하고 정리하고 도입하자고 마음 먹게 되었다. 

 

어려웠던 외래키 적용_실패는 성공의 어머니

우선 db에 대한 이해가 부족했던 것에서 시작하여 외래키 세팅을 공부하니 database 초기 세팅부터 자꾸 어그러졌다. 서버와 DB 초기 세팅 모두 내가 담당한다고 했었기 때문에 빨리 완료되어야 다음 단계로 넘어가서 기능 구현을 시작할 수 있을텐데, 자꾸 db 초기 세팅에서부터 어그러지니 팀원분들께 너무 미안할 뿐이었다.

sequelize 공식문서를 다시 처음부터 정독하면서 외래키 설정부터 이를 실제로 server에서 어떻게 ORM 쿼리를 짜서 데이터를 가지고 올 수 있는지를 공부했었다. 

 

내가 db에 대해 잘 못 이해하고 있었던 부분

• db에 저장된 데이터들은 실제로 cnf 확장자(리눅스에서, 윈도우 환경은 다르다. 어쨌든 어떠한 확장자파일)내에 파일 형식으로 저장된다. 이 말은 정적인 파일이란 의미이다. 하지만 나는 하나의 동적인 기능으로 이해해 버렸다.
• 그래서 발생한 문제는 외래키를 연동해 두면, 하나의 테이블에 데이터를 입력하면 자동으로 외래키가 연결된 그 테이블에 데이터가 입력될 것이라 생각했던 것이다. 외래키는 일종의 그 데이터 칼럼의 특성을 설정해 준것이고, 실제로 db에 서비스를 처리할 때는 일일이 update/create 처리를 해주어야 했다.
• 데이터를 담고 있는 테이블이 다대다 테이블 역할도 할 수 있다. 이는 프로젝트 마무리 즈음에 발견한 것이다. 우리가 설정한 db 스키마를 유심히 보면, 없어도 되는 테이블이 발견된다.

-> users_bootcamp 테이블은 삭제해도 되는 테이블인 것이다. reviews 테이블이 실제로 users와 bootcamp_list 테이블의 다대다 역할을 해주고 있는 것이다. (이는 추후 리팩토링하면서 마이그레이션을 다시 진행하고 재배포할 예정이다.)

 

마이그레이션 정확하게 하기

처음 db를 세팅해주고 난 다음에, 각 테이블을 수정해줄 때, migration을  확실하게 이해하지 못해서 정확하게 활용하지 못했다. A라는 테이블을 만든 후에, 칼럼이 일부 수정되면, 수정된 부분에 대해서만 추가로 마이그레이션파일을 만들어서 세팅해주고 진행해주면 된다. 하지만 초반에 나는 db의 오류를 빨리 해결하고 수정하고 기능 구현을 해야한다는 것에 집착하였고, (지금은 말하기도 민망한 초보적인 실수) 계속 테이블을 새로 생성하고 생성할 때 컬럼을 변경해주는 식으로 마이그레이션을 진행했다. 결국 중간에 큰 에러가 나서 db를 뒤엎었던 기억이 난다. A테이블을 만들고 ->  A`테이블로 엎고 -> A``테이블로 엎고 하다보니, 나중에는 이미 있는 테이블을 만들려고 한다고 에러가 나고, 그래서 그 테이블을 삭제해주려니 삭제가 안된다는 에러가 뜨면서 완전히 꼬여버린 것이다...

 

이렇게 초보적인 실수들을 겪으며 db의 기본에 대해서도 익힐 수 있었을 뿐만 아니라, 코드 작성 및 기능 구현에 앞선 내가 활용하고자 하는 개념에 대한 정확한 이해가 선행되어야 한다는 사실을 크게 깨달았다. 

 

soft delete VS hard delete

API 기본적인 기능을 CRUD라고 한다. 실제로 D 즉 delete 기능은 잘 사용되지 않는다고 한다. 이는 db에서 진짜로 데이터가 삭제되어 버리기 때문이다. 그리고 이를 hard delete라고 한다. 

그렇다면 soft delete는 무엇일까? 실제로 db에서 완전히 삭제하지는 않지만 사용하지 않는 상태로 두는 것을 의미한다. 

실제로 회원탈퇴/ 리뷰 삭제 기능을 구현하면서 이에 대한 고민을 많이 했었고, 우리는 active 칼럼을 추가하여서, status 를 변경해주는 것으로 soft delete로 구현했다. 이에 대한 선택은 실제로 서비스의 database의 특성에 따라서 잘 고민하고 선택해서 쓰면된다. 

허나 개인 정보의 경우에는 결국 hard delete를 하기는 할 것이다.(개인정보 처리방침 으로 인해...)

 

프로젝트 기능 구현 / 통신 테스트

safu 서비스의 기능 리스트업을 살펴보면 basic 부분에서는 최소한 꼭 필요한 기능에 집중한 것을 알 수 있다. 실제로 팀원들끼리도 첫 번째 프로젝트때는 욕심부려 엄청난 기능들을 많이 넣기보다는 기존에 배운 것들을 잘 활용하여 기본적인 서비스 구현에 더 집중하자고 합의를 보았기 때문이다. 따라서 api 구현을 하며 node js 서버와 sequelize orm에 대해서 확실하게 공부하며 진행할 수 있었다.

무엇보다 db에 요청하고자 하는 다양한 orm 쿼리문들을 작성해보고, 이에 더해서 간단한 테이블이 아닌 외래키로 연결된 테이블 간에 데이터를 가지고 오는 방식에 대해서도 정리할 수 있었다.

 

의외의 복병, 지금은 엄청 도움이 되는 소셜로그인

sprint때는 심지어 선택사항으로 잠깐 넘어갔던 소셜로그인이었으며, 그 때는 생각보다 간단하여(코드가..) 그냥 지나쳐 버렸던 기억이 난다. 이를 감안하여 sprint로 익숙한 git 소셜로그인을 시도했지만, 실제로 이를 이해하고 완성하는데만 1주일 가까이 쓴 것같다.

우선 sprint 때의 소셜로그인은 하나의 예시였으며, 우리가 구현하고 싶었던 구조는 client에서는 최대한 API 요청 하나만 하도록 하고, 이후 실제 소셜서비스와 통신하고 토큰과 데이터를 받아오고 db에 저장하는 과정은 모두 server에서 처리하는 것이었다. 

소셜로그인 자체에 대한 개념 설명은 블로그에 별도로 정리해두었으니 참고하면 될 듯하다.

 

첫 번째 프로젝트를 할 때는 회사를 다니면서 프로젝트를 병행하고 있었는데, 소셜로그인을 하고 있는 동안에는 거의 잠을 못잤던 것 같다.

처음에는 편하게 구글링을 통해서 예시로 기재된 코드들을 활용했지만, 그것들은 일종의 예시일 뿐 정답이 아니었다.

결국은 우리의 서비스 구조를 이해하고 어떤 과정이 필요한지를 정확하게 파악한 후에, 내가 사용하고자 하는 기능에 대해서도 정확하게 이해하는 것이 필요했다. 그 다음에 각 단계별로 하나씩 적용해가며 가설을 검증하고 이 때에 좋은 예시의 코드가 필요하면 구글의 수많은 코드를 활용하면 되는 것이었다.

 

당시 너무 고마웠던 것은, 늦은 시간이었는데 현정님께 도움을 요청하니 바로 줌을 켜시고 도와주셨다. 진행하고 계시던 이슈가 있었는데도 불구하고, 내가 겪고있던 에러에서 내가 너무 버거워하는 게 느껴지셨던 건지 소셜로그인이 완료될 때까지는 같이 에러를 해결해주기 위해 고민해주셨다. 혼자서 할 때는 하나의 가설에 계속 집중하여 문제를 해결했다면, 팀원이 있으니 해결방법에 대한 시야가 넓어지고, 생각지도 못했던 버그를 발견하고 해결하면서 기능을 구현할 수 있었다. 

 

이 때의 1주일을 겪고난 이 후에, 에러에 크게 당황하지 않게 되었고, 모르는 개념이나 기능에 대해 파악하고 공부하는 방향이 잡혀서 훨씬 속도가 붙고 자신감이 생겼다. 

 

프로젝트 배포/ 다양한 경우에 따른 분기 구현

 

각 기능들에 대해 깊은 고민을 하며 유저의 입장에서 다양한 경우의 수를 고려해야 했다,

가령 소셜로그인 유저는 마이페이지에서 개인정보를 수정할 수 없도록 해야 한다.

/ 그리고 한 명의 유저가 하나의 부트캠프에 대한 중복 리뷰 작성을 방지해야 한다 -> 이에 파생하여 이미 A 부트캠프에 대해서 리뷰를 작성해 두었는데, B 부트캠프 리뷰를 수정할 때 A부트캠프로 수정하려 할 수 도 있을 것이다. 이러한 경우에 대비하여 client에서 수정 페이지에서는 부트캠프 부분은 변경 불가능하게 비활성화하거나, server에서 중복 방지코드를 작성해야 했다.

 

우리는 서버에서 코드 리팩토링을 감내하기로 하였고 내가 담당했었는데, 이 때 모든 경우의 수를 고려하여 데이터가 update/create 되도록 로직을 구성하는 과정에 시간을 많이 할애했다. Join이 많았기 때문에 어느 테이블이 선행되어야 하는 것부터, 최대한 많은 경우의 수를 고려하면서도 코드가 db와의 통신에 있어서 효율적이어야 했다. 

이 경우를 해결하면서, 단순한 서비스인듯 하지만 사실은 그렇지 않다는 것을 / 개발자의 입장이 아니라 유저의 입장에서 다양한 가능성을 고려하여 한 발 앞서서 대응해야 한다는 것을 생각했다.

 

배포를 하고 시작하자

이건 진짜 너무 중요했다. 단순히 AWS 서비스를 이용해보는 것이 아니라, 실제로 client와 서버 배포를 해보고, 통신 확인 후, RDS 배포 후에 통신 확인까지 하는 것. 그리고 https 프로토콜까지 실행한 후에, 매번 이슈가 하나씩 구현될 때마다 배포를 해가면서 발생할 수 있는 모든 에러상황을 미연에 방지하는 것이 중요함을 느꼈다. 왜냐면, 1차 프로젝트를 진행할 때, local 상황에서는 모든 것이 완벽하게 다 구현되었는데, 실제 배포 후 크롬상황과 local 상황이 달라서 다 만들어 두고 배포만 딱 못하고 있기 때문이다...
1차 프로젝트는 틈틈히 배포하며 문제를 해결할 예정이고, 2차는 문제없이 처음부터 배포하면서 진행해야 함을 느꼈다.

 

프로젝트 전반적으로 깨달은 점

SR의 중요성

어떤 구조로 서비스가 통신할 지, DB가 어떻게 구성될 지, 실제 UIUX 상 어떤 이슈가 발생할 수 있는지까지 섬세하게 고민하고 미리 가이드를 잡아놓아야함을 느꼈다. 실제로 기능 구현과 관련된 코드를 다 작성하였지만 통신 테스트를 해보고 여러 상황을 고려해보니 서버 코드가 많이 미흡했던 것을 발견했다. 

 

너무도 중요한 배포, 그리고 실제 웹 아키텍쳐를 이해하자

배포단계가 이렇게 어려운줄 몰랐다. 이 부분에 있어서는 정말 미흡한 점을 느꼈다. 실제 prod 단계에서는 나의 서버 ip에 외부 접속을 허용하는 것이기 때문에 보안까지 엮여있기 때문에 중요한 부분 이었던 것이다. 

이 부분에 대해서는 파이널 프로젝트가 끝나고 나서 다시 처음부터 진행했다. 클라우드 서버 개념부터 배포를 처음 공부한다 생각하고 배포의 전체적인 구조부터 AWS의 각 기능에 대해서 정리하고 재배포 하였다. 

그러면서 느낀 것이 실제 prod 단계에서 복잡하게 작동하는 웹의 구조에 대해서 그리고 이를 보완하는 다양한 서버와 database 개념에 대해서 공부해야겠다고 생각했다.

 

단순히 코드를 찍어내지 말자. 논리적인 고민 끝에 효율적인 best practice를 고민하자

실제로 백엔드 포지션으로 서버와 db 기능을 구현하면서 가장 많이 느낀 점이다. 서비스를 묘사하는 짤들을 보면, 빙하에 비유하는 것을 많이 보곤 했다. 작은 빙하처럼 보이지만 물 밑에는 엄청 큰 빙하가 존재하는 것이다. 그만큼 서버는 보이지 않지만 하나의 빙하가 물 위에 떠있고 그만의 기능을 하기 위해 엄청난 역할과 기능을 수행하고 있는 것이다. 이는 코드를 빠르게 잘 구현하는 부분이 아니라 더 효율적인 통신, 이를 위해 어떠한 개념을 활용한 것인가(캐싱서버, 메시징 서버 등등),를 고민하는 과정이라고 생각한다,

중복된 통신을 최소화하기 위해서도 고민해야 하고,(캐싱서버를 활용한다든지 해서) 서비스의 특성에 맞게 서버의 구조 자체도 고민해야 하는 것이다. 정답이 있는것처럼 보이지만 오히려 정답이 없고 상황에 맞는 방향을 잡아내야 하는 것이다. 

 

환경파일(env, config)파일 관리 /  gitignore 너무 중요하다.

엄청 초보적인 실수이지만, 이번 프로젝트에서 초반에 제대로 관리 하지 못해서 git commit에 이 부분이 남아버린 것이 가장 큰 실수이자 반성하고 있는 부분이다. 첫 번째 프로젝트가 끝나고 파이널 프로젝트 전에 잠깐 여유가 있는 지금 팀원들에게 config 파일과 env 파일의 관리, 그리고 git push 때 한 번 더 gitignore을 확인하는 습관에 대해서 또 강조하고 강조하고 있다.

 

commit message 중요성을 잊지말자 와 pr message의 중요성

이는 반성과 칭찬을 동시에 해보려 한다...

우선 초반에는 commit message 규칙을 지키려 노력했다. 그러나 후반부에 배포 버그를 해결하며 commit message 규칙을 뒤로 미루게 되어버렸고, 의미없는 commit message들이 너무 많아져 버렸다. 

지금이야 4명의 팀원이서 작은 project를 하는 것이지만, 실제로 git은 하나의 오픈된 회의록인 것이다. 즉 코드 작성 및 기능 구현에 있어서 오픈하여 회의록을 작성하고 공유하는 것이므로 그 메시지인 commit message는 너무 중요하다고 할 수 있다. 이에 대해서도 깊게 반성하여 파이널프로젝트 이후 부터 잊지않고 우선으로 반영하려한다.

 

이전에 내가 밟아왔던 이력이 도움이 될 수 있구나. 잘 활용하자

실제로는 개발자가 되기 전에는, 어찌보면 기획?구성?쪽에 가까운 일들을 해왔다보니, 현재 상황을 빠르게 파악해서 정리하고 이를 전달하는 것이 습관이 되어있었다. 이러한 내 성향이 실제로 프로젝트 진행 시에 도움이 됨을 느꼈다.

pr message의 경우는 초반에 내가 작성한 방식이 하나의 form으로 잡혀서 팀원들과 그 방식대로 공유하기로 했었을 정도로 잘 기재되었다.  pr message를 남길 때, 완료한 부분/논의가 필요한 부분 으로 정리했었다. 그러니 코드 리뷰가 훨씬 더 빠르고 정확하게 이루어질 수 있었다. 

또한 내가 담당한 이슈에만 집중하는 것에만 집중하는 것이 아니라 전체적인 흐름을 파악하려고 하는 부분에서도 나의 이전 업무에서 활용된 것들이 도움이 되었다.

 

커뮤니케이션의 중요성(코드리뷰)

내가 맡은 이슈는 끝냈으니 끝! 이 아니라 다른 팀원의 이슈에도 하나하나 꼼꼼히 이슈를 체크하고 통신상황을 보는 것이 중요하다고 느꼈다.
모든 API와 이슈는 연결되어있고, 결국 하나의 이슈가 흐트러지고 내가 만든 이슈와 연동이 잘 안되면 나중에 실제 서비스까지 제대로 작동이 안되기 때문인 것이다.

 

마치며

다시 돌이켜 생각하면 생각할수록 코드들에 대한 부족함이 보여서 많이 부끄럽다는 생각이 드는 프로젝트이다. 그럼에도 불구하고 리팩토링을 감내하면서까지 배포를 진행하고, 포트폴리오로도 활용하는 이유는 첫 번째 프로젝트로써 역할은 제대로 했다는 점에서이다. 아마 이런 과정을 겪지 않았다면 나는 내가 무엇이 부족한 지, 무엇을 잘하는 지 그리고 팀프로젝트에서 어떻게 커뮤니케이션을 해야하는 지 등등 많은 부분에 대해서 깨닫지 못했을 것이다. 

초반에 기획단계에서 무엇을 모르는지 아는 것도 어렵다고 했는데, 이제는 이걸 알고 해결책을 찾는데 자신감이 생긴 정도면 엄청난 성장이고, 이로써 첫 번째 프로젝트에 큰 의의가 있다는 생각이 든다.