1. 지원한 계기

멘토님께서 슬랙에 올린 모집 글을 보고 처음에는 지원할 자신이 없었다. html과 CSS를 잠시 다뤄보기만 했지 모집 글에 적힌 기술들은 전혀 다뤄보지 못했기 때문이다. 그럼에도 서버와 클라이언트 전반의 웹 개발 경험을 하고 싶었고, 더 나아가 내게 어느 분야가 더 잘 맞는지에 대해서도 알고 싶었다.

그리고 실제 기업 협력 프로젝트로 웹 개발을 진행해 본다면 기획자나 디자이너와의 협업도 기대할 수 있으리라 생각했고, 그 경험은 나중에 실무 경험에 큰 도움이 될 것이라 생각했다.

2. 프로젝트 과정

2.1. 다른사람의 코드를 이해해 보자

이 프로젝트는 멘토님께서 다양한 카뎃에게 기회를 제공해 주시기 위해 한 달마다 팀을 변경하며 개발을 진행하는 프로젝트이다. 즉, 우리가 개발을 진행하기 전 다른 기수의 카뎃분들의 코드 위에 다른 피쳐들을 추가해야 하는 상황이었다. 그렇기에 개발을 진행하기 전에 앞서 우리는 기존 코드 제대로 이해해야만 했다.

그러나 그 과정은 생각보다 더 힘든 일이었다. 파일의 수도 많고, 한 파일에 몇백 줄이 넘는 코드도 있었기 때문이다. 그래서 우리는 개발을 본격적으로 진행하기 전에 기존 코드를 이해하면서 다른 사람들이 봐도 더 알기 쉽도록 리팩토링을 우선 진행했다.


module.exports = {
  DRAFTS: 1,    // 초안
  COMPLETED: 2, // 작성완료
  RELEASED: 3,  // 출고
  CONFIRMED: 4, // 게재
};

파일과 함수를 기능별로 잘게 쪼개는 작업과 더불어, 기존에 그냥 숫자로 사용되던 상태 값을 위 코드처럼 객체로 만들어 관리해서, 상태 값을 바꾸더라도 전체 파일을 바꾸는 일이 없게끔 수정했다.

2.2. 프로젝트를 파악하자

비록 완벽하진 않지만, 리팩토링을 하는 과정에서 기존 코드를 더 잘 이해하게 되었고, 기존 코드도 조금 더 가독성 좋게 변경되었다.

그리고 또 어려웠던 부분은, 전체 기능을 한 눈에 파악할 수 있는 기획서가 없다는 점이었다. 그래서 우리는 자체적으로 개발에 이해가 될 만한 시각적 자료들을 추가해서 GitHub 위키에 등록해, 다른 사람들이 코드를 봐도 더 이해하기 쉽도록 구성했다.

데이터 간 상태값 파악
직원의 권한을 파악

그 외에도 시퀀스 다이어그램(Sequence Diagram)을 작성해서, 유저가 서버에 보내는 요청과, 서버가 데이터베이스에 보내는 요청을 시각화해서 정리했다. 링크에 들어가서 보면 유저가 특정 행동을 할 때마다 동작하는 서버와 db의 흐름을 정리해 두었다.

이런 정리의 필요성 또한 프로젝트를 넘겨받는 경험을 통해 깨닫게 되었고, 인수인계에 대해 고민하며 작업을 진행하게 되는 경험의 바탕이 되었다.

시퀀스 다이어그램 보러가기

2.3. 대략적인 서비스 구조

  • aws를 통한 실서버 구축

현재 aws에 구축된 환경은 다음과 같다.

EC2 인스턴스 내부에 node.js로 작성된 서버가 작동하고 있으며, MariaDB도 같은 인스턴스 내부에 존재한다.

유저가 도메인에 요청을 보내게 되면 nginx의 리버스 프록시를 사용해 node.js 프로젝트가 실행되고 있는 port로 요청을 전달한다.

이미지를 인스턴스 외부에 저장하기 위해 AWS S3를 사용하고 있다. S3 버킷 내부에 이미지가 저장된 위치만 DB에 저장하였다.

2.4. s3를 사용한 이유

  • 개발 초기, 빠른 기능 구현을 위해 초기개발할 때 이미지 업로드 시 서버 내부 로컬에 파일을 직접 저장하는 방식으로 진행되어 있었다. 그러다 보니 이미지 파일은 EC2상태에 의존적으로 되어 관리가 힘들 게 되었다.
    • 만약 새로운 EC2에 환경을 구성하려고 하면 모든 이미지를 한 쪽에 받아 놨다가 다시 업로드해야 한다
    • 만약 백업작업 없이 디렉토리를 삭제하거나 이미지들을 .gitignore한 상태에서 브랜치를 바꾸게 되면 이미지들이 다 날아가게 되는 것이다.
    • 프로젝트 디렉토리 내부에 개발을 위한 것이 아닌 DB에 들어가야 할 항목들이 저장된다.
  • 이처럼 비합리적인 부분들을 제거하기 위해 AWS S3를 사용하였다. S3는 AWS에서 제공하는 온라인 스토리지 웹서비스이다. 파일을 쉽게 업로드하고 사용할 수 있다.
  • 이미지 업로드 before/after 이미지를 frontend로부터 받는 부분은 multer-s3를 사용했다. multer는 multipart/form-data를 핸들링하기 편하게 만들어준다. multer-s3는 multer와 S3를 연계하여 S3에도 파일을 업로드하기 쉽게 만들어 주는 라이브러리이다.
before
after

3. AWS를 활용한 제작부터 배포까지

  1. 나도 한 번 서비스를 배포해 보자! (EC2 인스턴스 생성 과정)
  1. EC2 접속 및 서버 환경 준비하기
  1. S3 및 nginx 리버스 프록시 활용하기

4. 깃을 통한 협업

팀원 간 코드 공유 및 이슈 관리는 모두 GitHub에서 이루어졌다. 협업하면서 혼자는 전혀 사용하지 않았던 기능들을 사용하게 되면서 깃과 GitHub의 진가를 알게 되었다.

기본적으로 팀원들과 개발을 진행할 때는 git flow를 사용해서 피쳐별로 역할을 나누어서 진행했고, 개발이 끝나면 develop브랜치에 풀리퀘스트를 올려 함께 충돌을 해결해 나가는 방향으로 진행했다. 그에 더해 멘토님께서 알려주신 git graph를 통해 브랜치 별 상태관리를 진행했다.

프로젝트를 진행하면서 크게 실수한 경험도 있었는데, 올리면 안 되는 AWS 접속 pem키를 GitHub 풀리퀘스트 요청으로 올려 버린 일이었다. 다행히 멘토님께서 바로 발견하시고 실수를 바로 잡아 주셨는데, 그걸 통해 중요한 값들을 환경변수로 따로 저장해서 관리하는 이유에 대해 절실히 깨닫게 되었다.

4.1. 업체와의 소통

업체와도 주로 GitHub 이슈를 통해 소통했다. 실무에서 개발에 요구되는 기능과 버그를 찾아서 이슈에 올려주면, 각자 역할을 나눠 이슈에 작업을 커밋하여 각자 한 일을 관리했다.

그 외에도 주에 한 번씩 미팅을 하며 작업 사항과 기획을 공유했다. 그 과정에서 느낀 점은 개발과 기획이 완전히 분리되기는 힘들다는 점이다. 개발자 또한 UI/UX에 대해 생각하고, 기획이 덜 구현되어 있는 부분에 대해 적극적으로 질문하고, 생각해야 한다. 물론 기획이 완전하게 나와 있는 큰 회사라면 모르겠지만, 이번 프로젝트처럼 소규모로 진행되는 경우에는 개발자의 기획 역량도 중요하다고 생각된다.

아무 생각 없이 기획대로 진행하다가는 나중에 죄다 수정해야 하는 참사가 일어날 수도…

5. 느낀 점

yejeong

  • 실제 가동되는 웹 경험이 없었던 나에게 이번 프로젝트는 웹앱부터 node.js, 자바스크립트 문법, SQL, sequelize 등 매우 많은 것을 배울 기회였다. 라피신의 한 달 만큼이나 배우는 게 많은 시간이었다. 동료 팀원들에게도, 멘토님께도 많은 것을 배웠고, 하나하나의 경험과 실수로부터도 값진 배움을 얻었다.
  • 원래 디자이너의 입장에서 개발자와 협업을 해봤었는데, 개발자의 입장에서 기획자, 디자이너와 협업을 해보니 왜 기능의 디테일한 기획이 중요한지 몸으로 실감하는 경험이었다.
  • 깔끔하고 가독성이 좋은 코드의 중요성에 대해서도 다시금 깨닫게 되었다. 혼자 풀던 과제나 알고리즘과는 달리, 코드만 보고서도 어떤 기능인지, 어떤 변수인지 알 수 있게끔 코드를 작성하는 버릇을 들여야겠다.
  • 42서울을 진행하며, 과제를 빠르게 진행하는 것도 좋지만, 이렇게 멘토님들이 진행하는 프로젝트를 해보는 것을 다른 카뎃들에게도 매우 추천한다.

yurlee :

  • 이번 프로젝트를 진행하면서 GitHub를 단순히 코드 저장소로 사용하는 것이 아닌, 프로젝트에 필요한 작업 관리를 위해 Issue, Project, Actions 기능 등을 사용했었다. 많은 기능을 사용해 본 적은 없었지만 몇 가지의 기능을 사용하는 것만으로도 작업 관리의 효율성이 좋아지는 것을 느꼈다.
  • 백엔드에서 ejs 템플릿엔진을 통해 SSR(ServerSide Rendering)하는 과정을 겪어 보니, 어떤 게 CSR(ClientSide Rendering)과 다르고 왜 CSR이 최근 몇 년 사이에 많이 사용되는 지 몸으로 느끼게 됐다.
  • 멘토님과 회의를 하면서 개발에 관한 조언도 받았지만, 중간중간 멘토님이 최근 개발이슈나 과거 개발에 대한 문화(?)등을 설명해 주셨는데 이 부분도 개인적으로 좋은 경험이었다

ji-park :

  • 협업이 가장 중요하다. 내 의견을 말할 줄 알아야 하고 동료의 이야기를 들을 줄 알아야 한다.
  • GitHub은 많은 기능을 가지고 있고 이번 프로젝트를 통해서 Commits, Code Review, Issues, Pull Request를 사용해 보면서 왜 사용하는지, 어떻게 사용하는지 알게 되었다.
  • 기존 코드를 파악하기 위해 그리고 다음 기수를 위해 문서화는 필수다.
  • 멘토님과 많은 회의와 이야기를 나누며 개발자의 인생에 대해 배우고 어떻게 개발을 해야 할지 마음가짐을 세웠다.