LOCKA 프로젝트를 마치며...

마지막 일기는 : https://oflofty.tistory.com/9

LOCKA 프로젝트 마지막 개발일기

상당히 오랜만에 개발을 했고, 바로 출시해도 될 정도의 서비스를 만든 적은 처음이라 느낀 점이 꽤 많았다.

여기서는 감상하고 앞으로 이렇게 개발해야겠다고 느낀 점들을 한번 써보려고 한다.

 

그거하고 별개로 다른 참가자들 작품을 보면서 정말 많이 배웠던 거 같다. 

크게 느꼈던 점들을 간략하게 정리하자면

 

• 깔끔한 디자인의 중요성
• 프로젝트 관리를 조금 더 체계적으로 하기
• commit message 쓰는 방법

 

첫번째로 깔끔한 디자인이 중요하다는 점은 이번 해커톤 우승팀의 작품인 '국방프렌즈'를 보면서 느꼈다.

우승작품 '국방프렌즈'

https://github.com/osamhack2020/WEB_KookbangFriends_Woowahan

osamhack2020/WEB_KookbangFriends_Woowahan

이대회에서 우승한 팀의 repo인데 이팀을 보면서 느낀 점은 참 디자인이 깔끔하게 잘 했다... 라는 것이다. 시중에 다른 디자인하고 견주어봐도 전혀 손색이 없는데 솔직히 말하자면 기술적으로 대단하다던가 참신함이 있는 프로젝트는 아니다. 소개 그대로  "온라인 비대면 상담 서비스를 제공하고 자유롭게 소통을 할 수 있는 커뮤니티" 를 만든 것인데 솔직히 이런 플랫폼은 많다. 기술적으로 어려운 것도 아니다. 하지만 복무중인 군인 수준에서 할 수 있는 디자인을 뛰어넘는 수준의 디자인에서 이미 어나더레벨이라서 작품을 까보기도 전에 감탄이 절로 나왔다.

 

그리고 내가 그때 느낀 감정은 심사위원들도 똑같이 느꼈는지 그대로 우승을 했다.

알고보니 둘다 SW 개발병으로 복무중이라 아마 사지방이라는 열약한 환경이 아닌 전문적으로 개발환경이 갖춰졌을 것이지만, 그래도 잘한 거는 잘한거지... SW 개발병이 괜히 된 게 아니라는 생각도 확실하게 들었다.

 

너무 디자인만 칭찬해서 디자인만 잘하는 팀이냐 하면 그것도 아니다.  채점하는 입장이 되었을 때 채점기준에 되게 충실하게 잘 짰다는 느낌이 많이 들었다. 내가 심사위원이고, 심사하는데 있어 필요한 요소들을 너무 잘 소개해주는 README는 정말 배울만하다고 생각한다. 그리고 작품 외적인 부분에서도 신경을 많이 썼다는 게 티가 많이 나는데 대표적으로 프로젝트의 얼굴이라고 할 수 있는 소개영상에서 정말 깔끔하게 핵심기능을 소개하면서도 잘 만들었다고 생각한다. 어떻게 해야 군인 2명이 짬짬히 1달간 짜서 저런 퀄리티의 작품이 나올 수 있는지도 궁금하지만 다음에 내가 해커톤 나가면 꼭 디자이너하고 같이 나가야겠다 싶은 생각이 들게끔 하는 팀이다. 그리고 프론트엔드 개발자가 처음으로 대단하다고 느낀 것 같다. 물론 백엔드 개발자도 이런저런 고생을 했을것이지만 아무래도 작품방향이 프론트가 좀 더 고생한 게 눈에 보이는 작품이었다. 실제로 사용하면서 완성도를 보니 생각보다 엄청나지는 않지만 자신들의 성과에 대해서 "어필을 이렇게 해야한다." 라는 가이드라인을 조금 잡아주는 계기가 되지 않았나 싶다.

 

그리고 개발과정이 진짜 깔끔하다 느끼는 팀이 하나 있었다. 

https://kookmoban.gitbook.io/osam/

국방 모바일 반납

준우승팀이던가 그랬던 거 같은데 잘 기억은 안난다. 이 팀은 우리하고 똑같은 주제인 비대면 반납을 할 수 있는 서비스를 제공하는 팀인데 gitbook을 이용해서 자신들이 얼마나 노력했는지를 너무 잘 보여줬다고 생각한다. 물론 완성도는 당연히 높았고, 주제가 같다보니 개발과정을 유심히 봤는데 최종 산출물에서는 내가 만든 앱도 완성도는 비벼볼 수준인데 우리팀하고는 비교가 안될 정도로 체계적인 과정하에서 짰고, 그거를 잘 보여줬다는 게 차이가 크다고 생각한다. 가장 "Team"이라는 말이 잘 맞지 않았나 싶다.

 

특히 workflow문서에서 이슈관리를 어떻게 했는지에 대해서 보면서 솔직히 많이 감탄했다. '와 진짜 프로젝트 관리/유지하기 정말 좋겠고 앞으로 이렇게 이슈관리하고 커밋메시지를 작성해야겠다.' 를 많이 생각하게끔 했다.

 

그 문서를 한번 보자면..

---

이슈

 

이슈 만들기

우선 분야별로 필요한 기능들 정리 (다음에 개발해야 할 것들도!)

백엔드 예시

• 용사 정보를 저장하는 Soldier Domain 모델 정의
• 저장된 용사 정보와 라즈베리파이가 요청한 정보와 검증 기능
• QR 코드 생성 후 안드로이드 앱 전송 기능
• 등등.....

이슈 열기

위에서 정리한 목록으로 이슈를 만든다 (기능당 하나씩)

• 제목은 간결하고 핵심 내용만 ( [이슈 목적] 이슈 제목 )
• 본문은 자세하고 기술적인 요구 사항을 명시
• Assignees는 책임자를 지정
• Labels는 이슈의 목적을 지정

만약 Issue에서 다른 사람의 의견을 물어보고 싶으면 @github_id로 태그 할 수 있다.

만들어진 이슈는 아래처럼 #숫자와 같이 이슈 번호를 부여받는다.

이슈 관리 예시

아래처럼 여러 가지의 라벨을 붙여 관리할 수 있다.

브랜치

 

브랜치 만들기

위에 이슈를 기반으로 아래의 컨벤션에 따라 브랜치를 만든다.

브랜치 이름 예시

• 기능(ENH) : feature/issue-n
• 리팩터링(CLN) : cleanup/issue-n
• 오류수정(BUG) : bug/issue-n
• 테스트(TEST) : test/issue-n

기능 구현 관련 1번 이슈라면 브랜치 이름은 feature/issue-1 이라고 명명하면 된다.

커밋

 

커밋 메시지 작성

 

ENH: (Enhancement) 개선하거나 신기능 추가

BUG: 버그 수정

DOC: (Documentation) 문서화 관련된 작업

TST: (Test) 새로운 유닛테스트를 추가하거나 기존 테스트를 수정

BLD: (Build) 빌드 프로세스 관련 코드 혹은 스크립트를 수정

PERF: (Performance) 계산 속도의 개선과 관련된 작업

CLN: (Cleanup) 코드를 정리하거나 리팩토링한 작업

 

커밋 메시지 작성 예시

제일 아래에 Resolves #10을 적은 이유는 #10번의 이슈를 해결했다는 의미고 이렇게 작성할 경우 아래 커밋을 푸시 후 머지하면 자동으로 이슈가 닫힌다.

 

ENH : 라즈베리 파이에서 웹서버로 용사 정보를 전송하는 기능 구현

* 전송시 데이터는 post 형식에 용사 정보가 담긴 json을 담아 전송

* 용사 정보는 군번, 이름, 휴대폰 기종, 고유번호로 이루어짐

 

Resolves #10

CLN : 웹서버에서 앱으로 QR코드를 전송하는 메서드 중복 수정

* 같은 기능을 하는 메서드가 여러개 있어 하나로 통합

Resolves #10

---

커밋메시지를 쓸 때 저렇게 표시한다는 생각을 못했는데 너무 유용하게 잘 쓸 수 있을 거 같다. 덕분에 정말 많은 것을 느낀 거 같다. 특히나 협업할 때 영서형 커밋 메시지 읽고 그 의도를 몰라서 시간을 좀 쓰긴 했는데 (물론 나라고 커밋메시지를 깔끔하게 쓰지는 않았다.) 그런 시간을 좀 줄일 수 있을 거 같다.

 

그 외에도 내가 개발하면서 느낀 점들도 상당히 많다. 그런데 말로 하기에는 이게 표현이 잘 안된다. 여튼 처음 해보는 프론트엔드 개발에 앱개발이라 그런지 상당히 해맨 부분도 많고 어려운 사항도 많았는데 그만큼 공부 열심히 해서 채워넣어야겠다는 생각이 들었다.