엘리스 SW 엔지니어 트랙 8-9주차

Gomao·2023년 4월 30일

목록 보기

11/12

0. 리뷰를 시작하기 전에

8-9주차는 1차 프로젝트 기간이었다. 거의 매일 새벽 4~6시 사이에 자면서 작업을 하다 보니, 도저히 포스팅에 신경 쓸 시간이 없었다.

이번 프로젝트는 이전에 사용해오던 깃허브가 아니라, 깃랩을 사용하여 진행하게 되었다.

깃랩에 커밋 한 흔적들이 남아있다.

쇼핑몰을 만드는 것이었고, 우리 팀은 6명이 한 조로 구성되었다.
말 많고, 기획/계획을 좋아하고, 앞에 나서는 것을 좋아하는 성격에 이번에도 팀장을 맡게 되었다. 하지만 프로젝트 경험이 없었기 때문에, 정확히 뭘 해줘야 하는지 전혀 감을 잡을 수가 없었다.

정리하는 느낌으로, 우리가 진행한 개발 프로세스를 적어보면서,
어떤 부분에서 어떤 개선을 하면 좋았을 지도 같이 생각해보기로 하였다.

1. 파트 분배

먼저 파트를 분배해야 한다. 우리 팀원들의 희망 포지션은 프론트엔드 4 백엔드 1 상관없음 1 이었다. 각 파트에 3명씩 배분하고, 만약 한 파트가 많이 일찍 끝나면
다른 파트를 지원해주면 되지 않을까 생각하였고, 조율 끝에 프론트3 백3으로 결정.
나는 백엔드 파트를 맡게 되었다.
일단 나는 현재 프론트엔드 개발자 지망생이다.
장기적으로는 풀스택 엔지니어가 되어야 한다고 생각하고, 
프론트 개발자라고 백엔드 지식이 없어도 되는 건 아니라고 생각한다.

내가 1차 프로젝트에서 백엔드 파트를 선택한 이유는,
개발 프로세스가 어떻게 진행되는 건지 전체적으로 알고 싶었다.
부트캠프에서 백엔드 관련 지식을 1달 동안 배우긴 했지만, 
전체적인 구조가 어떤지 전혀 이해를 못 하고 있는 상태였다.

내가 할 일이 자체가 너무 많으면 전체적인 흐름을 배우기 어려울 것이고,
아무래도 1차 프로젝트는 비교적 간단한 프로젝트이기 때문에
조금 더 시간을 써서 전체적인 개발 프로세스를 익혀보기로 하였다.
실무에서는 내 담당분야가 어느정도 정해져 있을 것이기 때문에,
이번 프로젝트에서는 흐름을 익히는 것을 최우선으로 생각했다.

2. 개발 전 기획 회의

무엇을 누구에게 팔지 결정하고, 각자 맡을 역할을 분배하고,
그 외 협업을 위한 기타 협의사항들을 결정해야 한다.
경험이 너무 부족해서 이 부분에서 많이 어려움을 겪었다.
기획 회의는 정말 중요하다. 각자 아이디어를 정리할 시간을 가지고,
즉각적인 소통을 위해 가급적이면 모여서 진행하는 것이 좋을 것 같다.
우리는 와인을 팔기로 하였다. 진짜로 사업을 한다고 생각하고, 진짜 내 돈이 여기에 투자되었다고 생각하고, 누구에게 팔아야 장사가 가장 잘 될 것인지 고민해 보았다.

아무래도 이미 존재하는 와인 전문 쇼핑몰이 많을 것이기 때문에, 너무 전문적으로 들어가면 불리할 것이라 생각했다. 따라서, 최대한 친숙함/편리함을 무기로 하여, 대중적으로 와인에 대해 잘 모르는 사람도 부담없이 이용 할 수 있는 서비스를 제공하는 것이 경쟁력이 있을 것이라 판단했다.

따라서 와인에 대해 잘 모르지만, 기념일에 마실 와인을 사기 위해 이곳저곳 둘러보는 20대후반~30대초반 직장인을 타겟으로 하였다.

최종적으로는 우리 쇼핑몰을 이용한 고객이 서비스에 편안함을 느끼고,
다음에도 방문하도록 유도하는 것을 목적으로 했다.

3. 세부 역할 분배

먼저 팀적으로 역할을 분배해야 한다.
발표자 / PPT 제작자 / 회의록 작성자 / Git 관리자 등을 정했는데, 나는 원래 발표에 큰 부담감이 없기 때문에, 발표를 꼭 하고싶은 사람이 없으면 내가 하겠다고 했고,
그대로 발표자를 맡게 되었다.

다음으로 파트별로 실제 업무분야를 분배해야 한다.
백엔드 파트는 3계층 구조로 설계하는 것이 평가 기준이었는데, 다음과 같이 구성된다.

서버와 직접 통신하여 데이터를 주고받는 model

서버에서 받아온 데이터를 클라이언트와 주고받기 위해 데이터를 가공하는 service

클라이언트에서 백엔드 서버로 보내는 API 요청들에 대해 정의하는 router

이 계층구조를 기준으로 나눌 지, 아니면 기능을 기준으로,
유저관련 기능 / 상품관련 기능 / 주문관련 기능 으로 나눌 지, 간단히 협의한 결과 기능별로 업무를 나누기로 하였다.

사다리타기 결과 나는 주문관련 기능을 담당하게 되었다.
업무분야 분배 관련해서는, 이 선택이 맞았던 것 같다.
프로세스를 조금 더 개선하자면 아무래도 기능 사이에 어느정도 관계가 있기 때문에, 
이런 부분에 있어서 초반에 조금 더 협의를 했어야 했다.

또, 와이어 프레임의 중요성을 처음에는 잘 못느꼈는데, 끝나고 보니 제일 중요한 게 
와이어 프레임이었다. 데이터 형식은 어떻게 할 건지, 키워드는 뭘로 할 지,
이런 부분에 대해 최대한 많이 고민하고 확실하게 협의해야 한다.

이 과정에서 프론트 분야와 주고받을 데이터 형식에 대해서 조금 더 자세하고, 확실하게
정하고 가는 것이 좋다. 클라이언트와 서버 간의 API 요청을 정리하는 과정에서 생각한 
데이터 형식이 다르면, 특히 type자체가 다를 경우 이걸 맞추는 데 생각보다 많은 시간이 
추가로 들어갈 수 있다는 점에 유의해야 한다.
프로젝트 경험과 내가 맡은 파트에 대해 자신감이 부족했다 보니,
당장 코드를 짜야한다는 강박에 큰 흐름을 보지 못한 듯 하다.

(쉬어가는 파트 - 스크럼 진행)

매일 스크럼을 진행하며 각 파트에서 업무가 어디까지 진행되었고, 오늘은 어디까지 진행할 건지, 또 파트 간에 협의해야 할 사항이 발생하면 언제든 적극적으로 소통 / 협의하기로 하였다.

이제부터는 클라이언트-서버 API 연결작업 전까지 거의 파트별로 작업을 했기 때문에, 내가 맡은 백엔드 파트 위주로 회고를 작성하고자 한다.

4. 백엔드 - 폴더 구조 생성 및 서버 연결 작업

조금 더 효율적인 작업을 위해 가장 먼저 폴더 구조를 설계하고,
각 파트에서 사용할 데이터 형식을 정의하는 Schema를 짰다.
이 부분에서, 폴더 구조는 한명이 설계하는 것이 좋다.
model, service, router, middleware, 필요하다면 controller 까지
어떤 폴더에서 어느 작업까지 처리할 지, 협의하고 가는 게 좋다.

내 파트가 아닌 파트의 코드를 참고하거나 유지보수를 해야 할 수도 있다.
따라서, 어떤 부분에서 뭐가 문제인지 최대한 빠르고 효율적으로 알기 위해
협의하고 넘어가야만 한다.
또, 서버가 잘 실행되는 지 확인하고, 코드가 잘 작동하는 지 확인을 실시간으로 하기 위해 최상위 폴더부터 시작해서 모든 하위 폴더에 import/export를 사용해서 연결 작업을 진행했다.

최상위 폴더의 index.js를 npm start로 실행했을 때, ./src/DB 폴더 내의 Schema와 index.js에 정의된 서버 연결 코드가 정상적으로 실행되어야 한다.
이 부분에서 시행착오를 줄이기 위해서는, 백엔드 폴더 간 관계도를
정확하게 정해서 작성하고 가는 것이 좋다.

어느 파일에서 어느 파일로 뭘 주고 뭘 받을 건지 확실히 정해야만,
지금 어느 파일에서 연결이 잘 안 되고 있는지 체크가 가능하다.

이 부분에 대한 지식이 부족했다 보니, 나는 모든 파일에 추적을 위해
console.log("체크포인트 N") 을 추가/삭제하면서 연결을 진행했다.

모든 인원이 모여서 작업하더라도, 이 연결작업을 같이 진행하고
같은 구조를 공유하는 상태에서 작업을 진행하는 것이 효율적일 것이다.
root 폴더의 index.js / src 폴더의 app.js / db 폴더의 index.js를 작성하였고, 각 계층을 형성하는 폴더를 연결하였다.

약 3시간의 대장정 끝에 최하위 폴더의 console.log가 실행되었다.

(쉬어가는 파트 - Git 관리)

프로젝트 형상 관리를 위해 Git 을 사용해야 한다.
master branch는 모든 버그를 해결하고 서비스에 활용 가능한 코드.
dev branch는 배포 전에 branch는 모든 파트에서 작업한 내용을 모아서 최종적으로 기능 테스트를 진행하는 중인 코드.
feature branch는 파트별로 현재 작업을 진행중인 코드를 올렸다.
feature에 하위 branch로 각자 파트를 눠 작업하고, 역순으로 merge를 하며 최종적으로 master branch까지 올리도록 관리하였다.

깃 사용법이 익숙하지 않아, 1주차에는 코드 작성시간보다 git관련 이슈를 해결하는 데 더 많은 시간이 걸렸다. 프로젝트 전에 최대한 익숙해지는 것이 좋지만, 또 프로젝트를 해야 익숙해지기도 하니.. 쉽지 않은 문제다.

하지만 대부분의 문제는 git fetch, git pull을 생활화하면 생기지 않을 문제들이고, 각 명령어들이 정확히 어떤 역할을 수행하는 지 정리해 두는 것이 좋다.

가장 많이 실수하는 부분은 지금 내가 원격 저장소의 파일을 보고 있는건지, 로컬에 있는 파일을 보고 있는건지 헷갈려서 원격 저장소에 있는 파일을 직접 수정하다가 로컬에 있는 branch로 이동하는 일이다.

git branch -a 명령어를 통해 내가 지금 어디 있는 건지 자주 확인하는 것이 좋다. 또, 인터넷에서 찾은 명령어를 구분 없이 막 실행하면 안된다. 특히 --force 명령어를 해결방법 이라고 올려둔 곳이 많은데, 그러다가 팀원이 다같이 타임머신을 타게 될 수도 있다.
복구할 자신 없으면 --force 절대 쓰지 마라.

git을 사용하는 취지와 안 맞긴 하지만, 불안하면 제발 자기 코드들을 별도 폴더에 압축하여 백업해두는 걸 추천한다. 타임머신 타는 것 보다는 낫다.

5. 백엔드 - Schema, Model 파일 작성

가장 먼저 서버와 직접 통신하여 데이터를 주고받는 기능을 구현해야 한다. Schema에서 주고받을 데이터 형식을 정의하고, Model에서 find/create/delete/update등의 메소드를 사용하여 서버에서 데이터를 읽어오거나, 저장하거나, 삭제하거나, 수정한다.

이때, 프로젝트 설계 단계에서 "어떤 데이터를 뭘로 검색해서 가져올 것인지" 결정했다면, 그에 맞게 함수를 사용하면 된다.
이 부분에서 가장 문제가 되었던 부분은, DB에서 가져오는 데이터 형식이
기본적으로 JSON 형태로 이루어진 Object 형태로 생겼는데,
이게 그냥 우리가 생각하는 객체랑은 살짝 다르다는 것이다.

DB에서 find 함수를 사용해서 데이터를 가져와서 출력하면 분명 내가 아는
객체 형태가 잘 출력되는데, key-value 값에 접근하려 하면 잘 안된다.

_id, __v 이런 정체를 알 수 없는 key값이 같이 딸려오고,
_doc 라는 의문의 key값에 value로 내 눈에 보이는 객체가 담겨있었다.

또, DB와 주고받는 데이터는 모두 Promise 객체 형태로,
async/await을 사용하여 반드시 비동기 처리를 해줘야 한다.

만약 이 부분을 생각하지 않고 작업한다면..
무수한 undefined와 함께하게 될 것이다!
나는 주문 파트를 담당했기 때문에, 다음 기능들을 구현하였다.

새 주문내역 생성

(관리자) 모든 주문내역 검색

아이디로 주문내역 검색

주문번호로 주문내역 검색 <-- 초기 단계에서 빼먹었음ㅠ

주문내역 수정 <-- 어디까지 수정 가능하게 할 지 협의해야 함

주문 취소

(관리자) 주문 삭제

(관리자) 배송 상태 변경

(관리자) 운송장번호 변경 <-- 나중에 추가로 요청받음

유저가 클라이언트에서 사용하기 편하려면 뭘로 검색을 하게 해야 할 지 고민하며 결정했는데, 이 부분은 기획 회의단계에서 반드시 협의를 해야 하고, 기획 단계에서는 잘 몰랐더라도 작성 과정에서 반드시!! 반드시!! 협의를 하고 확정을 지어놔야 한다!!!

물론 사용자의 요청이나 필요에 따라 추가/수정/삭제될 여지가 없는 것은 아니지만, 불필요한 업무 소요를 줄이기 위해서는 반드시 확정짓고 가는 것이 좋다.

나같은 경우, 처음에는 모든 것을 userId로 검색하게 구현했는데 한 사람이 여러 주문을 하면 어떡하지? 하나하나 수정하려면 주문 마다 고유한 index가 필요한 것 아닌가? 내가 상품을 살 때 주문 번호가 부여되지 않던가? 중복 불가능하고, 조금 더 직관적인 값이 있으면 좋지 않을까..? 하는 고민 끝에

YYYYMMDD + 6자리 난수를 주문번호로 생성하도록 구현했다.
정석은 DB에 자동으로 저장되는 _id (ObjectId)를 활용하는 것이다.
그런데 주문번호 라는 개념의 특성상, 내가 구현한 방식도 충분히 설득력이
있다고 생각된다. 협의 단계에서 그렇게 사용하겠다고 말하기도 했고..

지금 생각해보면 어차피 클라이언트에서는 전부 _id로 요청하게 
서비스를 구현할 테니, _id를 이용해서 모든 작업을 처리하게 하고,
별도로 주문번호도 생성하게 하여 그 번호를 제공하면 될 수도 있긴 하다.

그런데 그럼 식별자로 이용되는 값이 2개나 되는 거니까..
효율적이지 않다고 생각했다. 실무에서는 어떻게 처리하는 지 궁금하다.
기타 기능들이 정상적으로 작동되는 지 확인하기 위해, 더미데이터를 직접 선언하여 DB에 저장되고 읽어지고 수정되는 것을 확인하였다. Model 기능이 전부 작동하는 것을 확인하고, 다음 단계로 넘어가기로 하였다,

6. 백엔드 - Service 파일 작성

서비스 단계에서는 Model에서 정의한 함수를 사용하여 읽어온 데이터를 가공하여 클라이언트에서 요청하는 데이터를 보내줄 수 있도록 수정하는 기능을 한다.

사람마다 스타일 차이가 있는 것 같다.
Model에서는 서버에서 데이터 읽기/쓰기/저장하기/삭제하기만 정의하고, Service에서 모든 데이터 가공을 하는 경우도 있고, Model에서 거의 모든 기능을 구현해둔 이후에, Service에서는 추가로 발생하는 소요에 대해서 작업을 처리하는 경우도 있었다.

나는 Model에서 최대한 많은 기능을 구현했다 보니,
Service에서는 받은 데이터를 Router로 넘겨주도록 설정했다.

그래서 이 부분에서는 쓸 말이 별로 없다.

(쉬어가는 파트 - 오피스아워 진행)

주 3회, 1시간씩 오피스아워 시간이 제공되었다. 개발 분야 현업자로 있는 코치님들이 배정되어 개발 중에 발생하는 문제들에 대해 조언을 구할 수 있는 시간이었고, 프로젝트 외적으로도 다양한 조언을 들을 수 있는 시간 이었다. 오피스아워를 효율적으로 활용하는 것도 좋은 전략이 될 수 있다.

단, 정확한 해결책을 얻기보다는 해결 방법이나 접근 방법을 물어보는 것을 추천한다. 직접 해결한 문제가 기억에 오래 남는다.

7. 백엔드 - Router 파일 작성

라우터에서는 클라이언트에서 API 요청(request)을 받으면, 원하는 데이터를 포장하여 응답(response)을 돌려주는 기능을 한다.

이 과정에서 Model, Service에서 정의한 함수를 사용하여 서버에서 필요한 값을 가져오고, 수정하고, 저장하거나, 삭제한다.

이때, 잘못된 요청이 들어오거나 권한이 없는 요청이 들어올 경우 서버 측에서 에러를 발생시켜야 하는데, 이를 위해 Middleware를 이용하는 것이 좋다. 각 Router마다 모두 예외처리를 할 수도 있지만, 코드의 가독성과 재사용성 그리고 유지보수의 편의성을 위해 모듈화 작업을 하는 것이다.

나는 잘못 전달된 데이터를 서버에 요청하지 않고 즉시 에러를 발생시키기 위해, JOI 라이브러리를 사용하여 Validation(유효성 검사)을 실시하도록 구현하였다.

물론 Schema가 정의되어 있기 때문에, 잘못된 데이터로 서버에 요청이 들어가면 오류를 발생시키도록 설정해 두었지만, 이미 서버와 통신을 했다는 것 자체가 다 돈이다. 돈 벌자고 하는 일인데, 돈을 낭비할 수는 없는 것이다. 따라서, 입력값을 받는 즉시 유효성 검사를 하여 불필요한 서버 통신을 줄이는 것을 목적으로 한다.
시간이 좀 더 충분했다면, user 파트에서 구현한 loginRequired, adminRequired 
미들웨어를 사용해서 권한이 없는 요청을 조금 더 체계적으로 관리했을 것이다.
이 부분은 개인적으로 하든, 팀원들과 함께 하든 계속해서 기능을 보완해 나가고자 한다. 
시간이 없어서 못 넣은 기능들도 다 추가하고..

8. VM 서버 구축

백엔드 파트는 작업 3~4일차에 대부분의 서버 구축이 완료되었다.
물론 이후에 계속 보수작업이 있긴 했지만, 포스트맨을 이용하여 CRUD 기능이 잘 동작하는 것을 확인할 수 있었다.

API명세서를 작성하여 프론트엔드 파트에 전달하였고, VM 서버에 백엔드 서버를 업로드하여 프론트엔드 파트에서 이용할 수 있게 하기 위해서 조금 일찍 배포작업을 시작하였다.

배포 메뉴얼에 따라 가상머신 서버에 우리 폴더를 clone 하였고, 배포된 서버에 약간의 이슈가 있었지만 해결 후에 백엔드 서버를 정상적으로 배포할 수 있었다.

VM서버에 있는 파일이 꼬이는 것을 방지하기 위해, VM서버 파일 최신화는 담당자를 확실히 정해서 하는 것이 좋다.

아무래도 가장 먼저 서버 배포를 위해 터미널과 씨름을 했다 보니, 내가 하기로 했다. 덕분에 리눅스 명령에 많이 익숙해졌다.

9. 클라이언트 - 서버 연결작업

사실 여기까지 왔다면, 백엔드 파트에서 본격적으로 할 일이 많지는 않다. 그리고 이 작업을 하면서 수많은 오류를 보게 되는데, 대체 어느 파트에서 문제가 생기는 건지 구분이 안 가는 경우가 많다.

따라서 백엔드 파트에서는 이런 문제를 확실하게 구분하기 위해 에러핸들링에 신경을 써주는 것이 좋다. router, service, model, middleware의 각 부분에 console.log를 이용하여 어느 단계에서 코드 진행이 막히는 건지 파악하기 쉽게 작업하였다.

가령, 클라이언트에서 주문정보 받기 API요청을 보냈다면,
배포작업을 해둔 VM 서버의 터미널에 다음과 같이 로그가 찍힌다.
[router] get 요청으로 모든 주문정보 조회를 시도합니다.
[service] 서버에 주문정보 조회 요청을 보냅니다.
[model] 서버와 통신 중입니다...
[model] 서버에서 주문정보를 받아오는 데 성공하였습니다.
[router] 주문정보 출력 완료!!
가령 어느 부분에서 오류가 발생했다면, 정상적으로 동작했다면 찍혔어야 할 로그가 끊긴 부분을 추적하면 되는 것이다.
정상적으로 동작하는 것이 확인된 후에는 중간단계의 로그는 쓸데없는 동작을 줄이기 위해 삭제해주면 된다.

또, 에러핸들러 미들웨어를 만들어 각 상황에 맞는 에러 코드를 리턴하도록 설정하였다. 우리가 사용한 에러코드는 다음과 같다.
1. [500] Internal Server Error - 서버 내부 오류
2. [403] Forbidden - 권한 오류
3. [400] Bad Request - 입력 오류
적절한 에러 코드를 사용하여 처리하지 않으면, "저 이거 안되는데 확인해주실 수 있나요?" 라는 질문을 수도 없이 받게 될 것이다. 더 규모가 큰 프로젝트를 진행하게 되면, 더 다양하고 정확하게 에러코드를 사용하여 어느 부분에서 오류가 발생하는지 정확하게 알게 해주는 것이 좋다.

잘 작성해 두었다면 이렇게 대답할 수 있다.
"코드 번호 뭐에요? 아 그거 입력 잘못하신듯요. 확인해보세요"

아무리 잘 작성해 두었더라도, 피드백을 하다 보면 이런 기능이 더 있으면 좋을 것 같다, 이런 기능은 도저히 구현을 못 하겠다, 기존에 쓰던 것 보다 더 편한 데이터 형식으로 변경하고 싶다.. 이런 요청들이 들어올 수 있다.

기획 단계에서 잘 협의해둔다면 이런 소요가 적긴 하겠지만, 언제든 이런 일이 발생할 수 있으니 팀원 간에 최대 연락 확인 시간을 설정해두는 것이 좋다. 적어도 1시간 내에는 연락을 한 번씩 확인 하자는 것이다.

그렇지 않으면 한쪽 파트에서 아무것도 못 하고 업무 올 스톱 상태가 와서 하염없이 기다리는 사태가 벌어질 수 있다. 상당히 진 빠지는 상황이니, 서로를 위해 연락을 자주 확인하자. 물론 만나서 같이 작업하면 이런 부분에서는 확실히 메리트가 있을 것이다.

10. 서비스 최종 점검 및 피드백

이제 우리가 만든 클라이언트와 서버를 각각 구동하고, 인터넷 환경에서 정상적으로 작동하는지 확인한다. 우리가 직접 사용자가 되었다는 생각으로, 우리 사이트를 직접 이용해 보면서 개선점을 찾아보는 것이다.

아무래도 사용자 입장에서 테스트하다 보니, 대부분 프론트엔드쪽 개선사항이 발생하게 된다. 이 과정도 기획 회의 단계에서 자세하게 짤수록 문제 발생 가능성 자체가 적고, 경미한 문제가 발생할 것이다.

이래서 기획 회의가 정말 중요하다. 그렇지 않으면, 다 만들어놓고 띄워놓고 보니 이것도 아쉽고.. 저것도 아쉽고.. 고치자니 시간이 없고.. 이런 문제가 발생할 수 있는 것이다.

11. 발표

이제 나의 시간이 왔다. 발표라는 것은 단순하게 우리가 만든 기능을 구구절절 설명하는 것이 아니라고 생각한다.

발표는 곧 마케팅이다. 우리가 아무리 밤을 새워가며 대단한 서비스를 만들었다 해도, 발표를 통해 우리 서비스의 매력을 충분히 표출하지 못한다면 사용자들은 우리 서비스를 이용하지 않을 수도 있다.

또, 발표라는 것은 내가 할 말을 하는 것도 중요하지만, 사용자가 원하는 정보를 전달하여 발표 후에 궁금증이 남지 않도록 해야 한다고 생각한다.

이 점을 중심으로 하여 발표를 진행하였다.

가장 먼저 프로젝트명, 팀원, 우리 서비스의 이름을 소개한다.

다음으로 우리가 팔 물건, 우리의 주요 타겟, 사용자를 붙잡기 위한 전략, 우리가 사용한 기술 스택이나 협의사항들을 소개한다.

우리 서비스에서 사용 가능한 기능들을 소개한다. 이때, 왜 이런 기능을 이렇게 구현 하였는지 설명하였다. 사용자의 편의를 위해 서일 수도 있고, DB 관리를 위해서일 수도 있고, 보안성을 위해서 일 수도 있다.

간단한 기능 시연을 하였다. 사람들이 가장 많이 궁금해 하는 기능과, 우리가 가장 심혈을 기울여 만든 기능 위주로 진행했다.

발표는 성공적이었다. 반응도 나쁘지 않았다.

이 글을 볼 지 모르겠지만, 첫 프로젝트고 언제 뭘 해야 되는지도 정확히 모르는 팀장 이었는데, 각자 위치에서 맡은 역할에 최선을 다해주고, 마지막날 어떻게든 준비한 기능들을 다 보여줄 수 있게 밤을 꼬박 새가며 작업을 해준, 그 와중에 발표자료도 깔끔하게 만들어준, 모든 팀원들에게 다시한번 감사를 표한다.

또, 뒤에서 끊임없이 지원해준 많은 매니저님들, 프로젝트관련 조언 뿐만 아니라 현업 이야기도 들려주며 많은 도움을 주신 코치님들에게도 감사드린다.

무슨 상받은 것도 아니고 다 끝난 것도 아닌데 왜 이리 장황하냐고?
그게 바로 ENTJ다 난 항상 하고싶은 말이 많다.

12. 마치며

이렇게 나의 첫 번째 프로젝트가 끝났다.

팀 프로젝트는 내가 부트캠프를 가야겠다고 결심한 가장 큰 이유 중 하나였고, 기대했던 것보다 더 많은 것을 배울 수 있었다.

백엔드 파트에서 서버를 구축할 때 뭘 고려해야 하는지, 또 프론트엔드 파트는 백엔드 파트에 언제 어떤 것을 요청해야 하는지, 기획 회의에서는 뭘 어디까지 정해야 하는지, PM은 프로젝트를 어떻게 관리하고 조율해야 하는지, 개발자는 각자의 자리에서 어떻게 일을 해야 하고 어떻게 소통 하는 것이 효율적인지, 그리고 우리가 그동안 이용해오던 서비스들은 어떻게 구성되어 있는 건지, 이런 기능은 불편하기만 한데 왜 넣은 건지 모르겠던 기능들의 존재 이유, 모르고 사용했지만 편의성이나 보안을 위해 수많은 기능들이 존재한다는 사실도.

이번 프로젝트로 내가 배운 게 수도 없이 많다.
그리고 개인적인 기량 상승도 많이 있었던 것 같다.

1차 스터디 주제를 코딩테스트 연습으로 설정한 것도 도움이 되었다.
어떤 정보를 받아서 어떻게 정리해서 어떻게 보내줄 것인가에 대해 많이 고민해봤기 때문에, 각각의 기능 구현 자체는 크게 어렵지 않았다.

그리고 이걸로 프로젝트가 완전히 끝난 건 결코 아니다.
프론트엔드 파트에서 작업한 코드도 전부 읽어보고 이해해봐야 하고,
백엔드 파트에서도 쓸데없는 서버 통신을 최소화하고, 데이터를 더 효율적으로 읽고/쓰고/수정할 수 있는 방법을 계속해서 고민해야 한다.

모든 작업을 깃랩에서 했기 때문에, 이후의 유지보수 작업과 관리를 편하게 하기 위해 내 깃허브로 자료를 가지고 왔다. //------깃허브 - 프로젝트 폴더 링크------//

아직은 고칠 것도 많고, 당장 기능 구현에 급급하여 비효율적인 코드가 많을 것이다. 개선을 위해서는 데이터베이스, 네트워크 등 컴퓨터공학적 지식이 필요할 수도 있다. 그리고 부족한 지식은 보충하면 된다.

벌써 교육의 절반 이상이 지나갔다.
1달 간 이론 교육 후에 바로 2차 프로젝트를 해야 한다. 2차 프로젝트에 필요한 지식들을 미리 공부하여 2차 프로젝트는 더 좋은 결과물을 만들고 싶다. 2차때는 어느 파트를 맡을지도 지금부터 조금 더 고민해봐야 겠다.

후기와 자체 피드백과 일기가 합쳐진 내 첫 프로젝트 후기는

여기까지.

Gomao

코딩꿈나무 고마오

이전 포스트

엘리스 SW 엔지니어 트랙 7주차

다음 포스트