[ICT 인턴십] 회고록 4 - 두 번째 프로젝트

첫 번째 프로젝트를 마치고 두 번째 프로젝트에 참여하게 되었다. 두 번째 외부 기업이 요청한 앱을 만드는 외부 프로젝트였다.

 

1. 프로젝트 시작하기 전 나의 마음가짐

첫 번째 프로젝트를 진행하며 은근 flutter가 재밌어서 두 번째 프로젝트를 맡게 되었을 때 은근 기대가 되었다.

특히, 첫 번째 프로젝트를 진행하며 실행되는 것에 급급하여 코드를 비효율적이고 유지보수가 쉽지 않게 작성했었는데, 이번 프로젝트는 사수와 함께 진행하는 거여서 도움을 더 많이 받을 수 있을 것 같다는 생각을 하게 되었다.

 

2. 프로젝트를 진행하며 배운 지식적 내용

1) GetX의 사용법

상태관리

UI에서 실시간으로 변하는 여러 데이터들의 상태를 효율적으로 관리하기 위한 개념

GetX

flutter에서 상태관리를 도와주는 라이브러리

GetX에서 사용한 기능

• 변수, 비즈니스 로직, 화면 구현 코드를 따로 관리해서 코드 작성 및 유지보수에 편리
• obs를 이용해서 실시간으로 변수 변경 확인
• 각 페이지별 루트를 따로 모아놓고, GetPage를 이용해서 페이지 이동을 간편화함
• snackbar나 dialog를 사용, context 넘김 없이 사용 가능하다는 편리함이 있었음

2) 다양한 flutter 응용 패키지 사용

• image_picker: 사진 파일 선택
• painter: 그림 그리기
• file_picker: 파일 선택
• url_launcher: 외부 URL연결

3) gitMessage 사용법

깃 메세지란

협업을 할 때 효과적이고 효율적인 소통을 위해 규칙에 따른 커밋 메시지를 작성하도록 해 주는 방법

 

방법

• 프로젝트 있는 폴더 안에다가 메모장 .gitmessage.txt 작성해주기
• git config --global commit.template .gitmessage.txt 입력하기

################
# <타입> : <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
# 예) feat : 로그인 기능 추가

# 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)

################
# 본문(구체적인 내용)을 아랫줄에 작성
# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내)

################
# 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등)
# 예) Close #7

################
# feat : 새로운 기능 추가
# fix : 버그 수정
# docs : 문서 수정
# test : 테스트 코드 추가
# refact : 코드 리팩토링
# style : 코드 의미에 영향을 주지 않는 변경사항
# chore : 빌드 부분 혹은 패키지 매니저 수정사항
################

4) 브랜치 머치 방법

• 특수 브랜치를 로컬에서 생성 후 그 브랜치에서 작업을 한다
• 작업하던 걸 push하면 원격에도 해당 특수 브랜치가 생긴다
• 특수 브랜치 작업이 완료되었으면 로컬 메인브랜치로 이동하고 로컬 메인에서 로컬 특수 브랜치를 merge한다
• merge한 후 원격 브랜치에 push하면 원격 메인 브랜치에 merge된 내용이 반영된다.

5) 역할 구분에 따른 로그인 

백엔드는 구분해 놓은 역할에 따라 jwt 토큰을 내려줘야 한다. 거기에는 역할에 따른 메뉴리스트, 로그인한 회원 정보등이 포함된다.

 

3. 프로젝트를 하면서 배운 지식 외적 내용

1) 요청 기업과의 소통

전체 일정표 및 일정에 맞는 개발자들의 계획표를 서로 공유

개발자 본인은 본인의 계획을 잡을 수 있고, 요청 기업은 계획을 볼 수 있어서 좋은 듯

 

매주 한 번씩 회의를 진행하여 진행상황 보고

처음에 내가 맡은 부분만 알고 들어갔더니 내가 모르는 부분에 대해서 무슨 이야기인지 따라가기 어려웠음. 본인이 맡은 부분 뿐만 아니라 프로젝트를 전반적으로 이해해야 회의에 참여했을 때 이해도가 높아짐. 내가 이해하지 못한 부분에서 내가 해야 할 일이 언급될 수도 있는데, 내가 이해를 못 하면 그걸 캐치 못 하고 넘어가서 추후에 요청받은 일을 다 하지 못하는 불상사가 발생할 수도 있음. 또한, 전체적으로 이해를 해야 다른 사람이 놓친 부분을 내가 캐치할 수 있어서 프로젝트 진행에 도움을 더 줄 수 있음.

중요한 내용은 메모하는 습관이 필요. 회의에서 정해진 내용을 곧바로 수정 혹은 수행해야 하기 때문에. 머릿속에만 넣어져 있으면 나중에 까먹을 수도 있고, 왜곡해서 받아들일 확률이 높음.

 

실시간 질문 사항은 공유문서를 만들어 텍스트로 질문과 답변 진행 혹은 카카오톡 이용

공유문서를 사용한 방안이 좋았음. 모르는 걸 정리해서 물어보고 정리된 답변을 받을 수 있었음. 또한, 이런 답변을 받았다는 것이 증거로 남아서 요청사항과 관련되어 대립되는 입장이 있을 때 유용하게 사용됨. 

카톡은 대화로 이루어지다보니 한 눈에 질문과 답변을 볼 수 없어서 아쉬웠음.

 

2) 전반적인 프로세스

- 기획 - 요청업체와 미팅 계속 진행 - UI 보고 화면과 api 구현 - 프론트와 백 소통하며 수정 - 사내 서버에 백엔드 배포 - 도메인 구매 및 aws나 카페 24 같은 곳에 올림

 

4. 프로젝트를 마친 후 소감

앱 개발을 배울 기회가 없었는데 앱 개발을 배울 수 있어서 좋았다. 앱 쪽도 웹 프론트와 비슷할 것이라는 생각을 가지고 있어서 나와 안 맞을 거라는 생각을 가졌는데, 생각보다 괜찮아서 추후에 풀스택으로 가고 싶을 경우 이 쪽을 배워도 좋을 것이라는 생각을 가질 수 있게 되었다.

특히, 좋았던 부분은 프론트엔드로서 백엔드와 소통하는 경험을 해 볼 수 있었다는 것이다. 전에 백엔드로서 프론트엔드와 협업해본 적이 있었는데 그 때는 스프링 사용을 익히느라 프론트의 입장에 대해 생각해 볼 여유가 없었다. 하지만, 이번 프로젝트에서 프론트엔드로서 데이터를 받아오고, 프로젝트 완성을 위해 추가적인 데이터를 백엔드에게 요청하면서 프론트엔드의 프로세스를 이해할 수 있었다. 또한, 백엔드로서 프론트엔드와 협업할 때 필요한 자세들을 배울 수 있었다.

프론트엔드는 화면 구현을 빼고는 백엔드의 api가 완성되어야 기능 구현이 완벽히 가능해서 백엔드의 기능 개발이 우선되어야 한다. 또한, 프론트엔드가 진행하다 추가적인 데이터가 필요한 경우가 있기에 백엔드는 이에 발빠르게 대처할 준비가 되어 있어야 한다. 특히, 데이터 요청사항의 변화에 따라 데이터베이스 구성이 달라질 수도 있기에 데이터베이스는 변화에 유연하게 설계되는 것이 좋다. 이런 변동사항을 줄이기 위해서 백엔드는 api를 만들 때 프론트엔드 개발자와 충분히 상의해서 사전에 어떤 형식으로, 어떤 데이터들을 내려줄지 정하는 것이 좋을 것 같다.