멋쟁이사자처럼 여기톤 대비 토이 프로젝트 후기

6월 13일을 끝으로 약 3주간 걸친 여기톤 대비 토이 프로젝트가 끝이 났다. 원래는 끝나자마자 적으려고 했는데, 생각보다 많은 일을 맡게 된 관계로... 회복하는 데에 시간이 조금 많이 걸렸다. (사실 프젝 하나 할 때마다 며칠은 골골댄다)

 

그동안 나름 많은 팀 프로젝트를 해왔었다. 안드로이드 애플리케이션 두 개를 프론트로 개발하고 유니티로 게임 개발도 해보았는데, 언제나 나를 가장 힘들게 했던 부분이 소통이었다. 특히 백과 프론트가 별도로 존재하면 어디까지 프론트가 개발하고 어디까지 백이 개발할 것인지, 명세서를 언제 넘겨줄 것인지 등을 회의하고 전체 개발 일정을 조율하는 등 정말 많은 이야기를 해야했다.

 

이전 팀프로젝트 때 전체 팀장을 맡았는데, 백 한 명이 자신이 맡은 부분을 하지도 않고 잠수를 타버려서 사실상 백 한 명과 프론트 한 명(나)만 작업하고 있다는 사실을 뒤늦게 알게 되었다. 백2, 프론트1, 디자인1로 이루어진 소규모 팀이기도 했고, 당시 내가 백을 전혀 알지 못하는 상태라 백에 관여를 하지 않은 탓이었다. 결국 마감일 며칠 전에 그 사실을 깨닫고 핵심 기능이 아닌 부분들은 빼면서 겨우겨우 프로젝트를 제출했다. 기적적으로 장려상을 수상하기는 했지만 많은 아쉬움을 남긴 프로젝트였다.

 

이번 토이프로젝트는 그러한 경험을 기반으로 '소통'을 굉장히 중요하게 여겼다. 물론 PM이 따로 있기는 했지만, 개발이 어떻게 진행되고 있는지를 모르는 디자이너가 개발팀에 깊게 관여하기는 쉽지 않을 것이라고 판단했다. 게다가 Django는 백과 프론트가 함께 개발해야하는 프레임워크라, 누군가는 파일 디렉토리를 구상하고 깃에 공유를 해야 작업이 원활하게 흘러갈 것 같았다. 즉 누군가는 개발팀의 구심점이 되어야했다. 나를 제외한 팀원들은 전부 재학생이었고, 처음으로 프로젝트를 진행하신 분들도 꽤 많았다. 깃허브가 익숙하지 않은 분도 꽤 있으셔서 아무래도 그 역할은 내가 하는 게 효율적이라고 생각했다.

 

그렇게 나는 자칭 개발팀 팀장이 되었다.

 

---

 

먼저 Django 프로젝트 디렉토리를 하나 생성하고, 기능별로 앱을 생성해 내 깃허브 레포에 푸시했다. 개발자들이 클론 받아서 바로 작업에 들어갈 수 있도록 초기 세팅을 제대로 하는 것이 중요하다고 생각했다. 처음 한 번만 하면 될 줄 알았는데, 계속 무언가가 하나씩 추가가 되어 기초 세팅 부분만 푸시를 세 번은 한 것 같았다.

 

두 번째는 깃허브를 어떻게 관리할 것인지였다. fork해서 사용할 것인지, 아니면 한 레포 내에 여러 브랜치로 사용할 것인지를 결정했다. 많은 고민이 있었다. 여기톤 레포들을 보니 대부분이 fork 방식을 사용하고 있었으나, 지금 상황에서는 브랜치 기반 협업 방식이 훨씬 효율적인 것 같았기 때문이었다. 결국 우리 팀은 브랜치를 사용하여 작업했다. 내가 fork 방식을 채택하지 않은 이유는 아래와 같았다.

일단 내가 진행 상황을 파악하기가 곤란하다. fork 방식은 내가 팀원에 레포에 다시 들어가 확인하거나, 팀원이 풀리퀘를 해야지만 진행 상황을 파악할 수가 있다. 매번 팀원의 레포에 들어가서 작업 현황을 확인하는 것은 번거로운 일이었고, 심지어 풀리퀘가 올라오지 않으면 그조차 확인이 불가능해서 상황을 개인적으로 물어봐야할 수도 있었다. 게다가 우리 팀에는 깃허브를 처음 접한 팀원도 꽤 존재해서, 내가 항상 깃허브를 보며 관리를 해야했기 때문에 fork 방식은 적절하지 않다고 판단했다.

두 번째는 큼직큼직한 풀리퀘가 될 가능성이 높았다. 깃허브는 한 번에 너무 많은 코드를 변경하게 되면 가끔 같은 프로젝트를 완전히 별개의 프로젝트로 인식하게 되고, 그러면 최종 머지가 되지 않는다. 그 상태에서 강제로 병합할 경우 거대한 충돌이 발생해, 이 충돌을 해결하는 데에 또 많은 시간을 할애하게 된다. 본격적인 마감일이 2주밖에 되지 않은 상태에서 큼직한 풀리퀘를 마주하게 되면 곤혹스러울 것이라고 판단했다.

마지막은 원본 레포를 가진 사람에게 승인 권한이 주어져, 그 사람은 항상 풀리퀘를 최종 승인해야만 머지가 가능하다는 점이다. 그렇게 되면 팀장인 내가 연락이 되지 않을 때 개발이 멈춰버릴 수가 있었다. 한 사람에게만 승인 권한이 부여되는 것은 그 사람에게도 부담이지만, 머지한 최종 코드를 풀 받아서 작업해야하는 다른 개발자에게도 좋은 일은 아니었다.

그래서 우리 팀은 나의 강력한 주장 아래, 현업에서도 많이 사용하는 방식인 이슈-브랜치-풀리퀘 방식으로 깃허브를 관리했다. 컨벤션 사용과 풀리퀘 시 풀리퀘했다고 반드시 이야기해달라고도 공지했다.

 

세 번째는 MTV 방식에 대해서였다. 나는 그동안 프론트와 백이 완전히 분리되어 있는 개발을 진행해왔는데, Django는 그게 되지 않았다. 유일한 방식이 API 방식, 그러니까 DRF를 사용하는 방식인데 운영진 분들께 질문드리니 사용이 불가능하다는 답변을 받아서 html 자체를 렌더링해야했다. 다만 이 점을 프론트에게 어떻게 설명해야할 지를 알 수가 없었다.

프론트는 Django 사용 경험이 아예 없었다. 백은 스터디라도 진행하였지만, 프론트는 그조차 진행하지 않아서 당최 어떻게 설명해야할 지 곤혹스러웠다. 템플릿 기반 방식이라 API 명세서가 없다는 점, fetch로 지연 로딩을 사용할 수 없고 include를 사용해야한다는 점, 어떤 프로젝트 파일에서 작업해야하는지 등등을 아무것도 모르는 프론트에게 전달하는 게 여간 어려운 일이 아니었다.

나름 공부를 해온 나도 MTV 방식이 뭔지 이해가 안 갔는데, 공부하지 않은 프론트가 이해하는 건 당연히 힘든 일이다. (심지어 나는 구입한 강좌에는 Django를 사용한다는 건 MTV 방식을 사용한다는 것이라고 하여, DRF를 쓰는 것도 MTV 방식이 아닌가라는 의구심도 들었었다. 결국 여기톤 레포지토리 코드를 뜯어보고 JSONResponse나 APIView가 사용되지 않는 점을 보고 MTV 방식이 템플릿 기반 방식이구나라고 스스로 정의내렸다.) 그래서 초기 회의, 중간 회의에 템플릿 기반 방식이며 API가 없다고 공지했다. 그럼에도 어려운 개념이다보니 개인적으로 찾아가서 이야기를 나누기도 했었다.

---

 

1주차 (5/22 ~ 5/28)

• 아이디어 회의
• 디자인 확인하고 구현 가능 여부 판단

---

2주차 (5/29 ~ 6/4)

<팀장>

• 쟝고 프로젝트 디렉토리 구상 및 프로젝트 생성
• 생성한 기초 프로젝트를 깃허브 init 브랜치에 푸시
• init 브랜치를 디폴트로 설정
• 초기 회의 준비
  • 일정 조율
  • 회의 안건 올리기
  • 기능별 역할 분담 데이터베이스 생성하기
  • MTV 개발 방식 안내하기 (api 방식 X, 기본적으로 html 자체를 렌더링함을 공지)
  • 깃허브 이슈 및 브랜치 문서 작성
  • 컨벤션 작성
• 깃허브에서 발생한 문제 revert 후 팀원 깃 경로 체크 및 올바른 경로로 바꾸기

<개발>

• 카카오 소셜 회원가입/로그인 구현Django로 카카오 소셜 로그인/회원가입 구현하기
• → 상세 기록은 개인 블로그

---

3주차 (6/5 ~ 6/13)

<개발>

• 카카오 비즈 앱 등록카카오 개인 개발자 비즈 앱 전환 (사업자 등록 없이 비즈 앱)
• → 상세 기록은 개인 블로그
• allauth의 User 테이블과 Member 테이블 연결Django allauth User 테이블과 Member 테이블 연결하기
• → 상세 기록은 개인 블로그
• 프로필 화면에 카카오에서 받아온 정보 출력
• 프로필 사진 변경 기능 구현
• 로그아웃 구현
• 등록한 일정 불러오기 구현
• 바텀 네비게이션 뷰 아이템과 페이지 연결
• 프로필 기본 이미지 추가
• 스플래시 화면 페이지 전환
• .gitignore 관리
• 일정 삭제 구현
• 일정 수정 시 불러오는 데이터 수정
• 프로필 화면에서 일정 추가 눌렀을 때 home으로 리다이랙트 후 바텀 시트 자동 생성 코드 작성

<팀장>

• 잘못된 푸시된 코드 확인 후 revert 및 수정
• 작업 현황 체크 후 역할 재분배
• 중간 점검 회의 준비
  • 템플릿 방식에 따라 fetch → include로 변경되었음을 공지
  • 연동된 부분 영상으로 첨부
  • 일정 조율
• UI나 기능 쪽에서 수정이 필요한 부분 노션 데이터베이스 제작
• 쟝고 및 파이참 초기 설치 과정 도와주기
• README.md 작성
• DB 필드 누락 관련 전달
• 팀원 개발자 페이지 SITE와 Application 설정 봐줌
• 최종 점검

 

---

 

 

그동안 내가 팀장으로서, 개발자로서 해온 것들은 위와 같다. 게다가 풀리퀘 최종 머지 승인을 내가 하게 되어서 풀리퀘할 때마다 머지하고 자잘한 충돌을 해결해오기도 했다. 너무 자잘한 것들은 위에 적어두지 않았다.

 

사실 사건 사고가 매우 많았다. 그럼에도 이를 무사히 넘길 수 있었던 건 문제가 생길 때마다 나에게 연락해준 팀원들과 어떻게든 끌어가려고 했던 나의 합작품이었다. 팀원들이 혼자 끙끙 앓고 있었으면 프로젝트가 공중에서 날아갈 뻔했다.

 

나는 항상 팀 프로젝트를 할 때 초반에 일을 빠르게 끝내두는 편이다. 에러 하나에 5일을 잡아먹기도 해서 미루다가 시작하면 항상 예상치 못한 상황에 직면하기 때문이다. 그래서 초반에 내가 맡은 부분을 최대한 빠르게 끝내놓고 다른 사람들을 도와주는 게 내가 그동안 프로젝트를 진행해온 방식이었다. 이번에도 그랬다. 이러한 나의 습관은 내 일을 많이 늘려놓기도 하지만, 팀 전체에게는 좋은 일을 만들어준다.

 

원래 나는 카카오 소셜 로그인, 회원가입, 로그아웃, 프로필 정보 불러오기, 프로필 사진 수정하기의 기능을 맡았다. 언제나 그랬듯 미리 전부 끝내놓고 작업 상황만 주시하고 있었는데, 이슈를 보니 유난히 작업이 더딘 기능이 있어 담당 팀원에게 연락했다. 그리고 나는 이미 내 파트를 전부 구현해놓았으니 기간 내에 못하겠으면 이야기하라고 말했다. 그리고 원래 내가 맡은 부분이 아니었던 날짜 별 일정 불러오기와 일정 삭제를 구현했다.

또한 그 팀원의 코드를 확인해보니 JSONResponse를 사용하고 있어서 그건 API 방식이라고 알려주고, 그 팀원과 나의 일정을 조율했다. 아무리 프로젝트라지만 대회를 준비하기 위한 하나의 경험이니, 내가 많은 부분을 손대는 것보다는 그 팀원이 최대한 자신의 일을 하도록 기다려주는 게 맞을 것 같았다. 그래서 데드라인을 정해놓고 이때까지 할 수 있는 대로 다 하고 이후로는 나한테 맡기라고 했다.

 

또 다른 문제는 깃의 위치였다. 아무 생각 없이 머지 승인을 했는데, 풀을 받고 보니 프로젝트 안에 프로젝트가 들어있어서 다급히 revert 하고 풀리퀘한 팀원과 화상 회의를 진행했다. 깃의 위치가 잘못되어있는 것을 확인하고, 팀원이 VSC에서 깃을 사용할 때 경로를 확인하지 않는다는 점을 깨달았다. 그래서 1시간 가량 왜 이런 일이 일어났는지 설명해주고, 다시 클론을 받은 뒤에 기존에 작업했던 코드를 덮어씌우는 것을 지켜봤다. 마지막으로 푸시가 제대로 되었는지 확인하기 위해 머지 승인하고 내 컴퓨터에 풀 받아 문제가 없음을 확인했다.

 

그리고 프론트가 Django를 설치하는 법을 도와달라고 이야기해서 여러 설치 과정을 알려주었다. 우리는 mysql를 사용하여 mysql도 설치가 되어 있어야하는 상황이었고, Django 자체가 설치하는 게 복잡하며, 관리자 페이지에 등록해야하는 애플리케이션 설정도 있어서 처음부터 끝까지 디코로 소통하며 설치를 지켜봐왔다. 최종적으로 화면이 제대로 뜨는 것까지 확인하며 약 2시간 가량의 설치가 마무리 되었다.

 

기존에 잘 작동하던 내 코드가 에러가 터진 적도 있었다. 분명 이건 디렉토리 문제인데 어떻게 된 거지하고 상황을 파악했더니, 팀원 중 하나가 파일 디렉토리 구조를 통째로 바꿔놓고 내 코드를 만져서 일어난 해프닝이었다. 결국 해당 부분 revert 하고 팀원에게 연락했다. 자초지종을 들어보니 자신의 코드가 경로 문제로 작동이 안 되어서 디렉토리를 바꾸었다고 했다. 확인해보니 팀원 코드의 경로 자체가 잘못 입력되어 있어서 팀원의 코드를 내가 수정했다. 이후 반드시 남의 코드를 수정할 때는 풀리퀘든 어디든 이야기를 해야한다고 신신당부했다.

---

 

최대한 소통하기 위해 개발팀 개개인과도 이야기를 하고, 개발팀 전체를 소집하기도 했었다. 이 모든 일을 해왔기에 내게는 조금 많이 벅찬 2주였다. 사실 그 과정이 완전하지 않았기에 내가 많은 것을 끌어안아야 했었던 것 같다.

 

fetch가 아니라 include를 사용하면서 지연 로딩이 불가능해, DOM 요소가 js를 불러오기 전에 로드되지 않아서 null값을 뱉어내었다. 그리고 시작과 종료 시각을 가져올 때 잘못 잘라서 가져오는 바람에 화면에 보여주는 데이터가 이상했고, 마이페이지에서 일정 등록 시도 시 DOM 요소가 없어 에러를 뱉어내었다. 엄밀히 말하면 이건 프론트의 문제였지만 백인 내가 해결했다.

아마 include를 사용해야한다는 사실을 프론트가 인지하지 못했을 가능성이 높았고, 데이터는 잘라오기만 하면 되었으며, 마이페이지에서 일정 등록 시도 시 홈으로 넘기고 일정 추가 바텀 시트를 올리면 되었다. 시간이 얼마 걸리지는 않는 작업이었고, 거의 프로젝트 마무리 단계여서 여러 명이 작업하는 것보다 내가 간단하게 만지는 게 나을 것 같았다.

나름 html이나 js 코드는 많이 봐왔어서 어렵지 않게 끝낼 수는 있었지만, 심적으로 조금 부담이 가는 건 사실이었다. 최대한 프론트의 코드를 손대지 않으면서 핵심 부분만 만지는 게 은근 힘들었다. 처음부터 내가 짜는 것보다 남이 짠 코드를 조금 수정하는 게 더 정신적 피로도가 높았다.

 

어쩌다보니 개발보다 PM일을 더 많이 한 것 같지만, 개발도 충실히 했다. 소셜 기능은 어렵지 않았는데 오히려 프로필 수정 기능이 은근히 애를 먹었다. 데이터가 덮어씌워지는 문제도 있어서 아예 테이블을 새로 만들기도 했으며, 카카오 기본 프로필 url을 알아내고 그 url이면 우리 서비스 디폴트 사진을 테이블에 넣어두기도 했다. 원래 내가 맡은 부분에서 가장 어려웠던 부분은 이것이었다. 새로고침하면 풀려서 고쳤더니 로그아웃하면 풀려서, 데이터가 덮어씌워지는지도 확인하고 작업해야했기 때문이었다. 그래도 나름 스스로 최선을 다해 해결했다.

 

---

 

이전 프로젝트와 비교했을 때는 팀장의 역할은 다한 것 같아서 스스로가 뿌듯하다. 내가 다시 팀장이 될 지는 모르겠지만, 여기톤에서도 최선을 다해 개발하고 싶다. 특히 그때는 MTV 방식에 대해 제대로 이야기를 하고, 풀리퀘하기 전에 풀 받기, 타인의 코드를 수정할 시 연락하기 등의 규칙도 추가하는 것이 좋을 것 같다. 지금 이 경험이 여기톤과 해커톤에 많은 도움이 되었으면 좋겠다.