Week 0. 미니프로젝트 회고
아니 분명 입소식에 앉아 있었는데, 정신 차려보니 어느새 미니프로젝트 끝... 정말 바쁘고 정신없는 기간이었다. 기록된 시간을 보니, 식사시간 제외 일평균 15~16시간을 책상 앞에 앉아있었던 것 같다. [입소일 오후 팀빌딩 -> 당일 기획 회의 -> 다음날 아침 기획 발표 -> 구현 -> 다다음날 점심 최종 발표] 라는 매우 타이트한 타임라인이라 2박3일 내내 철야를 했다.
잠깐 딴 얘기지만, 입소식 때 장병규 의장님이 강연을 해주셨는데 정글에서만큼은 옆에 있는 동료들과 비교하지 말고, 어제의 나와 비교하라는 말씀을 해주셨다. 또 김현수 코치님은 이곳을 안전한 실험장(?)으로 쓰라고 조언해주셨다. 이곳에서는 마음껏 실패해보라는 뜻. 사회에서의 실패는 타격으로 이어지기 때문에, 안전한 이 공간에서 많은 시행착오를 겪고 사회로 나가라는 말씀이셨다.
'동료로부터 배우고 자극받고, 다만 비교는 어제의 나와 한다.'
배경도 학습속도도 각자 다른 수십 명의 사람들과 함께 지내다보면 의외로 쉽지 않다. 이 마음가짐을 잘 지켜가며 정글 생활을 이어가야겠다.
입소 당시의 내 상황
앞선 게시물에 적었듯, 개발자로의 전향을 결심한지 반년이 넘었지만 줄곧 겉핥기식 경험만 해왔다. 정상적인(?) 팀 프로젝트 경험도 전무하였다. 때문에 프로그램 코드를 짜는 법, 개발에서의 협업 방식 모두 매우 부족한 상태였다. 부족을 넘어 무지한 상태에 가깝다.
그래서 처음으로 경험하게 될 협업에 대한 걱정과 설렘이 공존하고 있었다.
미니 프로젝트 총평
점수를 매기지 않는 정글이지만 개인적으로는 프로젝트 결과는 만족스럽지 않다. 다른 팀들을 보며 자극을 많이 받았고, 한편으로는 민망하기도 했다.
우리 팀원들도 마찬가지였던 것 같다. 발표가 끝나고 모두 조금씩은 아쉬움을 공유했다. 준비 과정에서 좌충우돌을 너무 많이 겪었고, 마주하는 문제를 돌파하는 과정도 주먹구구식이었다.
하지만 불과 3~4일 전에 비해 많은 것을 느끼고 배우게 되었기에 유의미한 시간이었다고 생각한다. 팀원들과 특별한 불화도 없었고, 나름 내 현재 단계에 맞는 배움을 얻은 것 같다.
다른 팀들의 결과물은 생각보다 퀄리티가 높아서 놀랐다. 들어오기 전에는 미니 프로젝트 결과물은 대부분 입학시험 때 배운 개념을 활용한 게시판형일 거라 짐작했는데, 새로운 기술을 시도하거나, 같은 걸 배웠지만 경험치를 토대로 완성도있게 구현해낸 팀도 있었다.
반면, 우리 팀 포함 모든 팀이 발표에서 아쉬운 부분이 있었다. 이 부분은 우리 기수 모두가 많이 고민해야 할 주제라고 생각한다.
아쉬웠던 점과 배운 점
기술적 측면
우선 이번 프로젝트의 아키텍처는 다음과 같았고, 나는 백엔드에서 API 명세서 작성 및 문서화/ Jinja2를 활용한 SSR/ 게시물 CRUD 구현/ EC2 배포를 맡았다.
- 백엔드는 API 별로 소스코드 파일을 분리한 다음 blueprint로 합치는 방식을 택했는데, 기능별로 코드를 분화하면 서로 유지보수하기 편할 거라는 생각이었다. 다른 팀은 각자가 app.py에 대부분 기능들을 구현한뒤 하나에 merge 하는 방식을 택한 팀들이 많았던 것 같다. 잘 다듬어진(?) 보다 큰 규모의 프로젝트에서는 우리팀 방식이 맞을지 모르지만, 이번 프로젝트에 한해서는 다른 팀 방식이 더 효율적이었다고 판단된다. 소스파일을 나눴을 때의 장점을 살릴만한 지식이 부족한 상황에서 급하게 마무리해야 하는 프로젝트이기 때문이다.
- 비효율적이었던 대표적인 예시로는 config를 제대로 활용하지 못해 각 api 파일에서 DB를 불러오는 코드를 중복해서 넣게 되었다는 점이다.
- 또한 api 명세를 작성했음에도 불구하고 프론트와 백 간에 명칭이 일치되지 않는 경우가 종종 있었다. 프론트도 일부 그랬고, 백에서 응답을 줄 때도 일부 그랬다.
- JWT 토큰과 SSR 구현이 주요 미션이었는데, 위에서 말한 문제들을 부랴부랴 수습하느라 기술에 대해 깊게 알아보고 고민할 시간이 없었다. 어찌어찌 구현만 해놓은 상태로 프로젝트를 마치게 되었다. 코치님들도 발표회가 끝나고나서 이 기술들에 대한 고민이 부족했다는 피드백을 주셨는데, 다시 공부해보는 시간을 갖는게 좋을 것 같다.
기술 외적 측면
1. 협업
- 우리 팀은 3명이었고, 한 분은 전공자였지만 나 포함 2명은 제대로 된 프로젝트 경험이 없다시피 했다. 전공하셨던 분도 협업 경험이 풍부하진 않아서 팀 전체적으로 많이 헤맸던 것이 아쉽다.
1-1. 문서화
- 문서화 (API 명세, 데이터베이스 구조도), 규약 정리 (코드 컨벤션 ..)에 있어 많이 미숙했다. 때문에 불필요한 리소스 낭비가 많이 발생한 것 같다.
- 덕분에 문서화가 얼마나 중요한지를 깨달았고, 이번 기회에 직접 작성해보는 기회도 갖게 되어 좋았다. 확실히 명세서를 가운데 두고 토론을 하니 훨씬 커뮤니케이션이 원활해지고, 오해도 줄어듦을 느꼈다.
1-2. Git을 통한 협업
- Git을 통한 협업에 있어서도 많이 미숙했다. 이 역시 불필요한 리소스 낭비의 주요 요인이다.
- 그래도 이번 기회에 원격 레포지토리에 브랜치를 파서 협업하는 경험을 해볼 수 있었다. 그러나 아직도 헷갈리는 점은 fork와 PR을 활용해서 협업하는 법. 이들을 익히는데 더 이상의 시간을 쓸 수 없어, Github를 반쪽짜리로만 활용했던 것 같다.
1-3. 패키지 관리
- 패키지 관리: 팀원 각자가 가상환경에 설치한 패키지들을 어떻게 공유하는지가 궁금했었는데, 이런 것들을 편하게 담아서 보낼 수 있는 기능이 있더라. flask의 경우에는 freeze 명령어를 통해 내 venv 파일에 있는 패키지들을 requirements.txt 형태로 담을 수 있고, 이걸 팀원이 공유받은 다음 그대로 다운로드 받을 수 있다.
pip freeze 명령어로 내 패키지 목록을 담는다.
pip freeze > requirements.txt
팀원은 공유받은 requirements.txt 를 작업 폴더에 넣고 다음 명령어로 설치한다.
pip install -r requirements.txt
설치된 패키지를 확인하려면 다음 명령어를 실행하면 된다.
pip list
2. 기획/발표적 측면
- 첫날에 기획 회의를 진행했는데, 다룰 수 있는 기술이 한정되어 있고 아이디어보다는 평범한 아이디어이지만 구현적인 면에서 승부를 보자는 의견이 나와 다소 평범한 게시판형 기획으로 정해졌다. 기획 발표 때 이 부분에 대해서 코치님들도 아쉽다고 피드백을 주셨다.
- 조금 더 과감한 아이디어를 내고, 이를 구현해보려는 도전을 해봤으면 어땠을까.. 하는 아쉬움이 남는다. 스케줄링, 실시간 렌더링 등의 시도까지 나아갔으면 더 좋았을 것 같다.
- 발표할 때 갑자기 서버가 끊기는 일이 발생했다... 아마 발표장이 강의실과 달랐는데, 이동하는 과정에서 ip가 바뀌면서 발생한 일인 것 같다. 당황한 나머지 터미널을 꺼버려서 원인 분석을 하지 못했ㄸ ㅏㅠ
- 거의 모든 팀이 발표 피드백을 받았다. 5분을 초과했거나, 핵심 기능/컨셉 시연이 아닌 기획의도, 역할분담 등으로 많은 시간을 썼기 때문이다. 다들 발표에 신경쓸 겨를이 없기도 했지만, 이 부분에 있어서는 개선해야겠다.
3. chatGPT에 과도하게 의존
- 부끄럽지만, 이번 프로젝트 기간 중 GPT에 너무 의존했다는 것을 인정안할 수가 없다. 내 생각에는 이게 아쉬운 결과로 이어진 정말 큰 요인이었던 것 같다. 처음에는 괜찮을 거라 생각했다. 앞으로 생성형 AI를 활용한 작업환경이 디폴트가 될 테니까.. 근데 배우는 입장에서는 GPT가 자료를 다 찾아주고, 코드도 짜주는 것이 마냥 좋은 건 아니라고 느끼게 되었다.
- GPT 도움 덕에 초벌 작업(?)은 빠르게 끝났지만 당연히 우리 기획에 딱 맞는 코드가 아니었고, 정작 이를 손봐야 할 우리는 초반 코드를 GPT에 맡겼기에 이해도가 부족해서 빠르게 수정하지 못했다. 처음부터 침착하게 관련 지식을 '직접' 알아보고, 구조를 짜고 진행했으면 어땠을까 싶다. 최소한 GPT에게 코드를 짜달라고 시키는 건 가능하면 자제해야겠다.
- 어제 김현수 코치님이 하신 말씀이 떠오른다. 우리가 필드에서 마주칠 대부분의 문제는 답이 없고, 개발자는 원래 답이 없는 문제를 풀어내는 사람이라는 것. 그리고 풀어내지 못하면 모가지가 날아갈 수도 있다는 것😨. 맞는 말씀이다. 답을 모르는 문제를 두려워하지 말자.