[팀 프로젝트] UMC 3기 앱 개발 프로젝트: 안드로이드 개발자 후기

들어가며

이번 포스팅의 목적은 겨울 방학동안 진행했던 UMC 3기 앱 개발 프로젝트가 마무리가 되고,
팀 "당신의 발자취"에서 안드로이드 개발자이자 Sub Project Manger로 활동했던 소중한 경험을 잊지 않고 기록하기 위한 포스팅이다.

사담 [Sub Project Manager로 활동하게 된 계기]

본 글에 들어가기 앞서, 이번 프로젝트에 대한 사소한 나의 이야기를 하고 본 글에 들어가고자 한다.

처음에 이번 프로젝트를 참여할 때는 안드로이드 개발자로 지원하여 프로젝트에 합류하였다. 하지만 프로젝트가 마무리되고
팀 내의 나의 역할을 돌이켜보면, Sub Project Manger이자 안드로이드 개발자로써 활동을 했다.

 

앞에서 말했듯이 처음에 프로젝트에 참여할 때 "안드로이드 개발자"로써 지원을 했다. 사실 이번 프로젝트는 Project Manger가 아닌,

팀의 구성원 안드로이드 개발자로써 활동을 하면서, 능력있는 PM분과 능력있는 팀원분들을 만나뵙고 프로젝트를 더 안정적으로 이끄는 방법들을 배우고자 프로젝트를 참여했었다. 하지만, 첫번째 팀 전체 회의를 가지고나서 그 생각들이 사라지고, "큰일났다"  라는 생각밖에 들지 않았다.

 

# 첫번째 팀 전체 회의를 가지면서..
첫번째 팀 전체 회의에서는 PM분과 안드로이드 파트 팀원들과 함께 기획 회의 그리고 프로젝트 진행관련 회의를 진행했다.
첫 회의를 하고 나서, 나는 알게되었다.
PM분은 프로젝트 경험이 전혀없고, PM 경험또한 이번이 처음이라는 사실과 안드로이드 파트 팀원분들도,
협업 프로젝트 경험이 하나도 없고, 심지어, Github를 이용하는 방법도 모른다는 사실을 깨닫게 되었다.
정말, 첫번째 회의를 하고 나선 내가 생각했던 것과 정반대의 상황인 내가 배우는 입장이 아닌, 내가 프로젝트를 이끌고, 가르쳐 주어야된다는 입장이 되었다는 걸 깨닫고 "어떡하지,,, 큰일났다"라는 생각밖에 나지 않았다.
대학교 1학년 2학기 때, Project Manager [PM]으로써 4개의 활동에서 참여를 했었지만, 이번 프로젝트처럼 큰 규모의 프로젝트가 아닌,
규모가 작은 프로젝트에서 PM으로써 활동했기에,
처음으로 큰 규모의 프로젝트에서 흡사 PM으로써 프로젝트를 이끌어가며 활동해야된다는 생각에 사로잡혀
"내가 과연할 수 있을까?" 라는  말이 머릿속에 한동안 맴돌았다..

 

# 정리 [글을 들어가며.. ]

결과적으로 보면, 큰 규모의 프로젝트에서 Sub Project Manager로써 경험이 적은 PM분을 보조하면서 사실상 Project Manager이자 안드로이드 개발자로써 앱 개발을 성공적으로 완수해냈다.

첫 회의를 하고나서, "과연 내가 할 수 있을까?" 라는 생각에 사로잡혔지만,
"유쾌한 창조자"의 "자신이 생각하는 대로 이루어진다" 라는 구절을 생각하며
이번 경험을 성공적으로 해낸다면, 큰 규모의 프로젝트를 스스로 이끌 수 있는 사람이 될 수 있다는 소망을 가진 채
첫 회의 후 가졌던 부정적인 생각들을 없애고, 포기따윈 생각하지 않은 채 새로운 경험으로 향해 나의 발걸음을 옮겼다.

 

이번 프로젝트는 활동하는 모든 기간 내내 편안한 기억들보단, 힘들었던 기억들이 더 많이 남았던 것 같다.

정말, 정말 힘들었고, 말로 설명할 수 없을 만큼, 감정적으로든, 정신적으로든, 육체적으로든 힘이 많이 들었다.

그렇다고, 이번 프로젝트가 좋지 않았다고 말하는 건 아니다.

오히려 힘든 기억들이 많이 있었기에, 더 기억이 많이 남고, 나에 대해 더 많은 걸 알려주고,

새로운 시야를 발견하게 해준 좋은 프로젝트 경험이라고 생각한다.

그래서, 이번 포스팅에선, 프로젝트하면서 힘들었던 기억들 & 어려웠던 기억들 & 좋았던 기억들을 곱씹어보며 생각하면서

새롭게 나에게 대해 발견한 점과 새롭게 배운점들을 정리해보도록 하겠다.

 

이제 본격적으로, UMC "당신의 발자취" 앱 서비스 개발 프로젝트에서
안드로이드 개발자이자 SubProject Manager로써 활동한 경험들을 프로젝트를 진행한 순서대로 정리하려고 합니다.
본 글은 프로젝트를 하면서 느꼈던 감정 그리고 저의 주관적인 생각들을 토대로 작성한 것임을 참고하시길 바랍니다.
본 글은 무언가에 대한 답을 제시하는 것이 아닌, 저만의 경험을 토대로 저만의 답을 적어둔 것입니다.
인생에는 정답이 없듯이, 다른 누군가에게 제 생각과 가치관을 강조 & 주장하려고 글을 쓰기보단, 저만의 생각을 정리하기 위해 쓴
포스팅이기에, 제 글을 읽으실 때는 제 생각에 대해 참고한다는 느낌으로 글을 읽어주시길 바랍니다.
제 생각이 다른 누군가의 답안을 찾는데 도움이 되면 말할 수 없이 좋겠지만, 이 글을 읽는 독자 여러분께선 스스로의 생각과 가치관에 따라서 제 글을 읽으면서 글을 지금 읽고있는 당신만의 답안을 찾기를 응원하겠습니다.

[그럼, 본격적으로 약 1달 반동안 앱 개발 프로젝트에서 안드로이드 개발자이자, Sub PM으로써 활동한 경험들을 회고해보록 하겠습니다.]

 

---

기획 회의

프로젝트의 안드로이드 개발자로 참여한 후, 첫번째 회의로 기획회의를 진행했었다.

기획 회의는 PM분을 비롯해, 안드로이드 파트의 팀원분들과 "인하대학교"에서 진행했다.

 

# 불안정했던 첫회의.. 기획회의

당시에는 PM분께서 프로젝트 경험 그리고 PM 경험이 없으셨던 분이기에,
회의에 대한 안건사항과 목적성이 뚜렷하지 않은 채 회의를 진행해서, 다소 불안정하게 회의를 진행했다.

회의에 대해서 분명한 목적성을 세워두지 않고 회의를 진행하니깐, 팀의 방향성이 일치되지 않고

회의의 흐름이 일정하지 못하고 산으로 가는 회의만을 진행하고 있었다..

 

# 팀 내의 공통된 목적성 그리고 회의의 목적성을 찾기

PM분께서 프로젝트 경험 & PM 경험이 없었기에,
회의를 진행하면서 알 수 없고, 예측할 수 없었다. 그래서, 나는 팀원으로써 "의견"을 제시하여

이번 회의에 대한 목적성을 찾고, 회의의 흐름을 팀원 모두가 찾아서 회의를 진행할 수 있도록

회의에 대한 방향성을 잡아주었다.

불안정한 회의에서 방향성을 잡기 위해 다음과 같이
행동하여 팀 전체의 기획회의의 목적을 분명하게 세웠다.

 

- PM분께 앱 서비스 기획한 사항 설명 듣기

첫번째 회의에선, 분명한 목적성 없이 회의가 진행되었던 터라 PM분께서 기획하신 사항에 대해서
제대로 된 설명을 듣지도 않고, PM분께서 기획하신 바에 대한 피드백을 진행하고 있었다.

이 부분에서 PM께서 기획하신 바를 먼저 설명 들은 뒤
PM께서 기획하신 WoW포인트를 토대로 기획 구체화를 진행하는 의견을 내었다.

[이 부분에 대해선, 지난 프로젝트 경험을 토대로 기획 구체화를 다같이 하게되면,
기획된 사항이 "하울의 움직이는 성"이 될 수 있기에, 공통의 기획 포인트를 잡고,
기획 구체화를 진행해야 "하울의 움직이는 성"이 되지 않을 수 있기 때문이다.]

 

- 기획 WoW 포인트 기반으로 기획 구체화

[PM께서 생각하는] 기획의 와우 포인트를 PM을 비롯한 모든 안드 팀원들과 함께 공통으로 공유한 후,
기획에 대한 구체화를 진행했다. [PM의 기획의 와우 포인트는 "일상의 사진을 체계적으로 가치있게 기록하고 정리하는 앱 서비스" 였다.]

기획 구체화는 기획된 사항에서 수정하거나 추가하는 의견을 제시하는 식으로 진행되었다.

그리고 나서, 제시된 의견들 중 기획의 와우 포인트에 부합되는 의견들을 기획에 추가 시켜
기획을 수정하는 방식으로 기획에 대한 구체화를 진행했다.

이때의 상황이 상황인지라 (PM분께서 프로젝트 경험이 없었었다.) 모든 팀원들과 함께 기획 구체화를 진행했었다.

[사실, 이 부분은 모든 팀원들과 함께 진행하긴 보단, 모든 의견들을 받아서, 기획을 진행한 PM이나 소수의 사람끼리 WoW 포인트 기반
기획을 확정시키는 것이 합리적이라고 생각한다.]

 

- 앱 개발 프로젝트 방향성 정하기

기획 WoW 포인트를 기반으로 확정시킨 기획 구체화를 토대로 약 1달간 진행될 앱 개발 프로젝트 방향성을 정했다.

확정된 기획 사항을 앱의 핵심 기능별로 나누어 보고, 핵심 기능 중 WoW 포인트 기반으로 구현 우선순위를 정하여 개발 프로젝트의 방향성을 팀원들과 함께 다음과 같이 확정시켰다.

기획의 와우 포인트가 사진을 체계적으로 기록하고 정리하는 앱 서비스이기에,
메인 홈, 갤러리, 마이페이지에 대한 사항을 우선 구현순위로 두고,
로그인, 회원가입, 피드와 같은 사항을 후 순위 구현사항으로 프로젝트 방향성을 정해두었다.

 

# 기획 회의 끝

첫번째 회의인 기획회의에서는 팀원 모두가 프로젝트에 공통의 방향성을 지닐 수 있도록
앱 프로젝트 기획 사항의 WoW 포인트를 찾고, 기획 구체화를 진행했다.
그리고, 이에 따른 앱 개발 프로젝트의 방향성을 정했다.

팀원 모두가 프로젝트에 대한 공통의 방향성을 공유하고, 기획 구체화 및 방향성을 정하니
"하울의 움직이는 성"처럼 난잡한 형태가 아닌 안정화된 프로젝트 기획을 갖출 수 있었다.

 

 

# 정리 [사담]

이번 프로젝트의 첫번째 회의는 프로젝트 기획회의로 "인하대학교"에서 진행했다.
기획회의는 약 5시간 정도 진행했던 것 같다 ㅋㅋ.. 정말로 긴 시간가량의 회의였다.

# 회의 목적성의 중요성 [회의 안건사항]
이렇게 긴 시간동안 기획회의를 진행했던 이유는 무엇일까?
이번 프로젝트의 PM분은 프로젝트 경험이 없었고, 따라서 프로젝트 회의를 진행하는 방법또한 모르고 있었다.
기획회의를 할 당시에는 회의 안건사항이 뚜렷하지 않았고, 진행력 또한 회의의 목적이 불분명하게 진행되고 있었다.
따라서, 회의에 대한 목적이 뚜렷하지 않아서 회의하는 내내 회의의 흐름이 산으로 가는 경우가 많아비효율적으로 회의를 하게되었던 것 같다.

정리해서, 회의를 하고자 할때는 회의에 대한 목적성을 정한 후, 회의를 함께 진행하는 팀원들에게 이에 대한 사항을공유하여 공통의 회의의 목적성을 가지고 회의를 진행한다면 효율적인 회의를 진행할 수 있다.
사실, 이 부분에 대해선 대학교 1-2 PM으로써 활동을 하며 깨달은 바였지만, 이번 경험으로 더욱 더 구체화가 된 듯 하다.

---

기능 명세서 구성

완료된 기획 사항을 토대로 앱의 핵심기능을 구분 지은 후
핵심 기능별로 앱의 기능 명세서를 작성을 하여
팀원들에게 공통적으로 공유했다. (안드로이드 개발자 & 백엔드 개발자 & 디자이너 & PM)

 

# 기능 명세서 구성 목적

기능 명세서는 팀 내의 앱 개발 프로젝트의 공통된 목적성을 지니기 위함으로써 구성되어졌고,
큰 규모의 프로젝트에서 모든 팀원들에게 프로젝트에 대한 기획 사항을 공통적으로 공유하고자 구성되어졌다.

다시말해, 프로젝트에 소속한 팀원 모두가 프로젝트의 확정된 기획을 공유하고,
개발을 시작할 수 있는 레퍼런스로써 작용하도록 기능명세서를 구성하였다.

"한 눈에 볼 수 있는 개발 프로젝트의 기획서 - 기능명세서"

"팀원들에게 보여주는 프로젝트 기획서"

"개발 프로젝트의 시발점"

 

 

# 기능 명세서 구성 과정

1. 핵심기능 정리

기능 명세서를 구성할 땐 우선 노션 텍스트를 이용해서
확정된 기획사항을 토대로 핵심기능을 우선적으로 텍스트로 정리했다.

이번 프로젝트 "당신의 발자취" 앱 서비스의 기획에선
핵심기능을 다음과 같이 나누었다.

- 지도 형태로 발자취 조회
- 갤러리 뷰로 발자취 조회
- 발자취 사진 업로드
- 마이페이지 조회
- 부가기능 (피드 조회)

 

2. 핵심기능 별로 서브기능 분류

핵심 기능 별로 소속하는 서브기능들을 노션 텍스트를 이용해서
확정된 기획사항을 토대로 텍스트로 정리했다.

이번 프로젝트에서 서브기능들은 다음과 같이 나누었다.

- 지도 형태로 발자취 조회
   - 기간대 별 발자취 조회
   - 장소 검색
   - 장소 카테고리 별 발자취 조회
    - 모든 발자취 조회

- 갤러리 뷰로 발자취 조회
    - 날짜순 조회
    - 캘린더 지정 조회

- 발자취 사진 업로드

- 마이페이지 조회
    - 마이페이지 기본정보 조회
    - 로그아웃
 
- 부가기능 (피드 조회)
    - 타 유저 피드 조회

 

3. 핵심기능 별로 상세기능 정리

서브기능 별로 소속하는 상세기능들을 노션 텍스트를 이용해서
앱의 UI를 살펴보면서 상세히 텍스트로 정리한다.

이때는 프로젝트의 기능명세서를 마무리하는 과정으로 파트 별로 나눈 기능에 따른
상세기능들을 기입한다.

그렇게, 기능명세서 구성과정을 모두 거치면 다음과 같은 기능 명세서가 텍스트로 정리되어진다.

"당신의 발자취"의 기능명세서 텍스트

이렇게 기능 명세서 작성과정을 순차대로 거치게 된다면, 큰 규모의 프로젝트에서도 (기능들이 셀 수 없이 많은 프로젝트)
한눈에 보기쉽게 "텍스트"로써 간단하게 정리하였다.
따라서, 완료된 기획사항을 기능 명세서로 정리하여 소속한 팀원들에게 공유하여 쉽게 프로젝트 기획 사항을 알 수 있도록 도와주었다.

4. 기능명세서 "표"로 정리

마지막으로 텍스트로 정리된 기능명세서를 더욱 더 한눈에 알아보기 쉽게 노션의 "표"를 이용해서
"텍스트" 자료를 정리했다.

다음과 같이 "표"를 이용해 기능명세서를 정리하였다.

 

노션에 "기능 명세서"를 표 형태로 업로드 해둔 후
팀원들에게 공유하여 앱 개발 프로젝트의 전반적인 확정된 기획사항과 프로젝트의 방향성을 이해할 수 있도록 하였다.

 

 

# 정리 [처음으로 큰 규모의 프로젝트 상의 기능명세서를 작성하다..]

# 기능명세서 효율
노션에 기록해둔 기능명세서는 이번 우리 팀 프로젝트의 시발점이 되었고,
나를 비롯한 팀원들은 기능 명세서를 토대로 파트 별로 개발 버전을 계획하고
개발 파트를 나눠서 개발을 시작했다.. ^.^

따라서, 이번에 구성한 기능명세서를 토대로 우리 팀은 프로젝트에 대한 공통된 방향성을 잡았고,
그에 따라 프로젝트를 파트별로 나눠서 작업하는 환경을 제공해주었다.

# 이번 경험으로... 나의 역량을 점검하다..
이번 기능 명세서 작성해보는 경험은 시간이 지나고,
PM으로써 리드하면서 프로젝트를 이끌어볼 때 뜻깊은 경험이 될 수 있다고 생각한다.

이번 프로젝트는 프론트엔드 & 백엔드 & 디자이너 들과 함께 참여하는 "큰 규모의 프로젝트"이기도 하고,
실제 앱의 규모로 보았을 때도, "큰 규모의 앱 서비스" 이다.
이번에 "큰 규모의 프로젝트"에서 기획된 사항의 기능명세서를 완성시켰고, 모든 팀원들이
한 눈에 알아보기 쉽게 정리하는 경험을 하였다.
따라서, 나 또한 큰 규모의 프로젝트 그리고 큰 규모의 서비스에서도 기획된 사항을 한 눈에 알아보기 쉽게 정리하고,
모든 팀원들이 알아보기 쉽게 정리할 수 있다는 역량을 지녔다는 걸 증명했다는 사실을 깨달았기에
앞으로의 PM을 꿈꾸는 나로썬 뜻깊은 경험이 되었다.

---

개발 템플릿 구성 [ 프로젝트의 개발 규칙을 지정..]

기능명세서 작성이 완료되어지고, 이번 프로젝트에서 속한 안드로이드 파트에서
본격적인 안드로이드 개발을 위한 Pre-셋팅을 진행했다. 개발 템플릿은 UMC 10주차 강의에서 제공되어진
MVP 패턴기반으로 설계된 "코틀린 안드로이드 개발 템플릿"을 토대로
우리 팀의 안드로이드 개발 템플릿으로 재구성하였다.

 

# 개발 템플릿 구성은 생각보다, 복잡하지 않다.
개발 템플릿에 대한 Pre-셋팅은 나와 이번 프로젝트의 PM과 함께 템플릿을 구성하였다.
개발 템플릿에서는 핵심 기능별로 패키지 폴더를 나눠서 MVP 기반으로 코틀린 클래스 파일들을 구성해뒀다.

다음과 같이 패키지 폴더를 나눠서 개발 템플릿을 구성했다.

 

사실, 개발 템플릿 구성은 실제로 개발을 하기 전만해도, 정말 어려웠던 과정같이 느껴져서,
어떤게 "정답"인지 몰라서 불안하고, 계속해서 더 나은 걸 찾으려고 노력했던 것 같다.

하지만, 막상 개발을 다하고 나서 돌이켜 생각해보면, 개발 템플릿은 복잡한 과정이 아니였다는 걸 깨달았다.
"기능명세서"의 핵심 기능별로 패키지 폴더를 나눠두었던 것을 토대로 앱 개발 구현을 완료해낼 수 있었다.

그리고, 템플릿의 패키지 폴더는 개발 공간으로써 자유자재로 바뀔 수 있다는 가능성이 충분히 존재했다는 것이다.
(개발 템플릿에서 구현된 패키지 폴더의 위치를 옮겨도, 개발 상 오류가 발생하지 않는다는 점)

따라서, 개발 템플릿 구성은 복잡하지 않고, 핵심기능 별로 패키지 폴더를 나누고,
서브 기능별로 세부 패키지 폴더를 나누면 된다는 점을 이번 경험을 토대로 깨닫게 되었다.

 

 

# 개발 템플릿 자체는 복잡할 수 있다.

이번 안드로이드 개발 템플릿은 UMC에서 제공되어진 안드 템플릿을 재구성하여
만들었다.
UMC에서 제공된 템플릿은 기본적인 안드로이드 프로젝트 개발을 위한
개발 템플릿 구조를 갖추고 있었다.
API 요청을 위한 Retrofit 설정, API 요청 헤더 자동 설정, API 서버 주소 설정과 같은
추후에 API 연결을 하여 개발을 하고자 할때 필요한 초기 셋팅을 미리 Config 폴더에 지정해두어 이번 프로젝트에선
쉽게 API 연동하여 개발을 진행할 수 있었다.
하지만, 개발 템플릿을 스스로 구성해야되는 상황이면, 이에 대해서 스스로 파일 규칙을 정해서 설정해야된다는 점을 이루어보면,
개발 템플릿 구성은 복잡한 과정이 될 수도 있다.

"그래도, 개발 템플릿 구성하는 작업 자체는 "답"이 정해진 것이 아니기에,
자신만의 파일 규칙을 정해서 설정하게 된다면 올바른 개발 템플릿이 될 것이다. 그리고, 규정한 템플릿 규칙들을
팀원들에게 올바르게 공유만 한다면, 빠르고 쉽게 개발 프로젝트를 진행할 수 있게 된다."

 

 

# 개발 템플릿은 여러 레퍼런스로 다듬어진다.

이번 안드로이드 개발템플릿에서 Pre-셋팅 파일의 집합체인
config 폴더 구성을 살펴보면,
API 연결을 용이하게 해주는 설정 파일,
안드로이드 개발 시 Console & 로그를 편하게 찍게 해주는 설정 파일,

XML 파일 ViewBinding 설정해주는 파일 등등이 있다.

개발 템플릿은 실제 여러 개발자들이 작업을 하면서 주로사용하는 작업 & 설정들을
하나의 파일에 설정해두어 실제 개발 환경에서는 "config" 폴더에서와 같은 설정 파일에서 "메소드"를 호출하여
그 작업들을 편하게 수행할 수 있도록 도움을 준다.

정리하면, 개발 템플릿은 개발을 하면서 좀 더 "편하게"하기 위해서 구성되어진 "레퍼런스"라고 보아도 될 것 같다.
여러 레퍼런스들을 참조해서 개발하는 환경에 맞춘 템플릿 환경을 셋팅하는 것이
프로젝트 개발하면서 더 "편하게" 개발을 할 수 있다.

 

 이 점에서 느낀 바이다.
개발 템플릿은 정말 "답"이 존재하지 않고, 개발하면서 필요할 것 같은 부가적인 설정같은 것들을 생각한 후
설정 파일로 추가해서 만들어지는 프로젝트 폴더라고 생각한다.

# 개발 템플릿의 본질
프로젝트의 단체 별로 개성 넘치는 "개발 템플릿"을 구성해서 프로젝트 개발을 시작하는 것이
개발 템플릿의 본질이 아닐까? 라는 생각을 해본다.

---

개발 비전  계획 & 파트 분업

개발 템플릿을 구성을 완료한 후
내가 소속한 안드로이드 파트의 개발 비전 & 파트를 (기능명세서) & (개발템플릿)을 기반으로 계획했다.

# 개발 비전 계획

개발 비전은 다음과 같이 세웠다.

당발의 안드로이드 개발 비전

 

# 개발 파트 분업
개발 파트는 다음과 같이 분업하였다.

당발의 안드로이드 개발 파트

 

# 개발 비전의 초기 버전은 기간도 크게, 핵심요소를 우선적으로 구현하자

이번 경험을 토대로 개발 비전을 계획하고, 파트를 나누는 방법을 터득한 듯하다 ㅎㅎ...
(팀원으로써 참여하려고 했지만...!)

 

프로젝트 진행에 있어서 초기 버전을 세울 때는
기간을 다른 버전과 달리 3~4일정도 더 많이 세우는 것과 초기 버전에선 핵심요소를 우선적으로 파트를 지정하여 구현을 하는 것이 합리적인 사실을 깨달았다.

초기 개발에는 프로젝트 구성원 모두가 흔히 말해 "적응기"라는 시간을 가지는 것 같다고 생각한다. 그래서,
다른 개발 버전보단, 구현 기간을 더 많이 주어, 모두가 더 많이 프로젝트에 적응할 수 있도록 하고,
핵심요소를 구현함으로써 프로젝트의 이해도를 증가시킨다.
따라서, 후속 개발 기간동안에는 "적응기"를 거친 채 부속기능을 구현함으로써 프로젝트의 이해도를 증가한 채
세부 기능들을 구현하여 팀원 모두가 더 쉽게 프로젝트를 이끌어 나갈 수 있도록 해주는 것이다.

---

백엔드와 협업

이번 프로젝트에선 백엔드 개발진과 함께 주도적을 소통하면서
전체 프로젝트를 조율하는 역할로써 참여했다..
그래서, 이번 프로젝트를 토대로 다른 부서와 함께 협업하는 방법을 주도적으로 경험할 수 있었다.
큰 규모의 프로젝트에서 안드로이드 파트에 속하여 백엔드 파트와 어떤 협업과정을 거쳤는지 상세히 녹여내도록 하겠다.

# 백엔드 개발 비전 제공

앞에선, 기능 명세서 기반으로 내가 소속한 안드로이드 파트의 개발비전을 계획했다.
이번 프로젝트는 프론트 & 백엔드와 함께 프로젝트를 진행하여 백엔드에서 작업한 서버 API 받아서
프론트에서 API 연결을 수행하여 앱 서비스를 구현해야 되었다.
그래서, 프론트 상에선 화면구현이 완료되는 우선순위에 대해 "안드로이드 파트 개발비전"을
기능 명세서를 기반으로 백엔드 단에게 서버 API 개발 우선순위를 지정해주었다.

정리하면, 서버단에게 안드로이드 파트 개발 비전 기반으로 서버단의 개발 비전을 제공해주었고,
서버단은 이에따라 개발 일정을 조율하고 API 개발을 진행할 수 있도록 해주었다. 

 

# API 명세서 Swagger 사용요구

안드로이드 파트단에서 API 연결을 쉽게 할 수 있도록,
스웨거를 사용해서 API 명세서를 작성해주도록 요청했다.
그에 따라 안드 파트는 스웨거를 공유받아서 API 연결을 수월하게 할 수 있었다.

 

---

프로젝트 안드로이드 개발

# API 명세서 기반으로 화면 설계 및 더미데이터 구성

안드로이드 개발에 시작하기 앞서, API 명세서와 화면 설계서 (와이어프레임 디자인)를 토대로

실제 화면 구현에 필요현 API의 응답데이터와 요청데이터를 정리해두었다.

그리고, 정리된 것을 백엔드 개발진분들에게 제공하여,

API 개발을 보다 쉽게 할 수 있도록 도왔다.

(커뮤니케이션 비용을 절감하고자, API 명세서 기반 화면 설계에 따른 요청 & 응답데이터 정리를 진행했고,

이에 따라 복잡한 데이터는 프론트 단에서 정리하여 제공해주면, 개발이 수월해진다는 걸 깨달았다.)

 

또한, 프론트 단에서 미리 요청 & 응답 데이터를 정리하게 된다면, 프론트단에서도 효율적인 개발을 진행할 수 있다.

프론트 로직에 따라 (데이터가 뿌려지는 형식) 요청 & 응답 데이터를 맞추어 API 개발을 하게되면, 프론트에선 보다 쉽게 코드 구현이 가능하다.

 

# 개발 시작

- 구현 설계 기반으로 안드로이드 개발 [개발 가치관]

- Top Down 설계 개발방식

프론트 엔드 개발자로, 안드로이드 개발자로서 처음 진행했던 개발 프로젝트이기에

지난 백엔드 개발자로 참여한 프로젝트와 달리 새로운 개발 가치관들을 깨닫고 내게 정의하기 시작되었다.

정리하면, 다양한 개발 환경들을 직접 접해보고, 프로젝트를 진행해봤기에 나만의 개발 방식을 찾아내기 시작했다.

(개발을 효율적으로 하게 되며, 개발의 속도를 높히는 방법과 쉽게하는 방법들을 이번 프로젝트의 안드로이드 개발을 하면서 많이 깨달았다.)

 

이번 프로젝트 경험을 하면서, 찾아진 나만의 개발 방식은 아래의 블로그에

상세히 기록되어져 있으니 참고하길 바란다.

[Android | Kotlin] 갤러리 뷰 Fragment 구현 완료 - 개발 회고록

 

# 서버 API 연결

서버 API 연결은 앱 개발 템플릿의 API 호출 URL 주소만 업데이트를 해주면 된다.

개발 템플릿을 초기에, 안드로이드 개발 프로젝트 형식으로 셋팅해두었으면,

(개발 템플릿 설정 파일을 잘 이해 했다는 과정하에) 생각보다 단순하다.

 

# 확장 구현의 가능성

이 부분은 정말, 이번 프로젝트의 개발하면서 많이 깨달음을 준 부분이기도 하다..

나는 한번도 구현해보지 않았던, 안드로이드 개발이기에, 개발 가능성을 잘 몰랐기에

현재 "당신의 발자취"의 피드 기능인 "타 사용자 발자취 둘러보기" 기능을 구현할 가능성이 처음에는

못할 거 같다고 생각했다.

개발을 모두 끝 마치고 회고록을 쓰는 지금 순간에 돌이켜 생각해보면, 피드 구현은 모두 완료했다.

 

기획된 사항을 안정적으로 정리되고, 개발 셋팅을 알맞게 (여러명 혹은 큰 규모의 개발 프로젝트에 따른) 셋팅을 해둔다면,

확장 구현은 어려운 사항이 아니라는 점이다.

결국, 개발 템플릿과 개발의 규칙들을 잘 지켜나가며, 개발에 임한다면 프로젝트 확장 기획에 대한 여러 기능들은

새로운 과제만큼 어려운 느낌이 아닌, 이미 완성되어져 있는 곳에 몇 줄의 작업 (코드 작성)인 셈을

이번 프로젝트의 안드로이드 개발자로서 "확장 구현"이라는 것을 처음 수행해보고 깨달은 바이다.

"확장 구현에 대해서 어렵게 생각하지 말자." 라는 것이 이번 개발 프로젝트를 임하면서 내게 준 지혜이다.

---

Github 관리자로 안드로이드 코드 관리 & 병합

Github 관리자로써 코드 관리 & 병합한 사항은 아래의 포스팅에서 정리해두었으니,
참고하길 바란다.

[Github] Github 프로젝트 관리자로 활동하면서.. - 1차 병합완료

# Github 브랜치 전략 [Github Flow 전략 이용]

Github 브랜치 전략은 Github Flow 전략을 채택하여 이번 프로젝트에서 이용했다.

이전 프로젝트에서, Git-Flow 전략을 채택하여 사용했던 경험에선, "소규모 프로젝트"
즉, 배포가 수시로 이뤄지지 않는 프로젝트에서는 다소 불필요한 브랜치들이 많이 사용되어져, PR을 관리할 때,

불편했었다.

그래서, 이번 프로젝트도 "소규모 프로젝트"라는 점에 Github Flow 전략이라는 Git-Flow 전략에 비해

브랜치의 전략이 간편하게 개선된 것으로 불필요한 브랜치를 없애고, Github Flow 전략으로
"당신의 발자취" 안드로이드 파트는 PR을 관리했다.

결국, 이번 프로젝트를 토대로 프로젝트 상황에 따른 적합한 Github 브랜치 전략을 채택하고 진행하는 것이 합리적이라는 사실을 깨닫게 되었다.

 

# main 브랜치 & feature 브랜치 설정

Github Flow 전략을 "당신의 발자취" 안드로이드 파트에서
사용될 때는 다음과 같이 사용되었다.

 

(메인 디벨롭 업데이트 브랜치)

main 브랜치

(main 브랜치로부터 파생된 feature 브랜치)

feature/map

feature/gallery

feature/post

feature/mypage

 

# Pull Request 관리 & 병합

PR은 개별 브랜치에서 코드 업데이트를 버전 별로 수행한 후,

PR 보내기를 하기로 안드로이드 팀원들과 이야기를 했다.

그리고, 1차 개발이 모두 완료되고, 모든 PR이 모여진 상황에선

main에 Merge하는 역할은 내가 맡아서 진행했다.

 

[Merge 진행방법]

Merge는 브랜치 하나씩 차례대로 진행했다.

예를 들면, feature/map 브랜치를 main에 merge 시키는 PR을 받아서

충돌이 발생되는 부분을 해결한 후 (Github에서 해결 하지만, 충돌이 많을 경우 로컬에서 수행 해야함)

merge를 진행한다.

그리고, 로컬 환경에서 업데이트된 main 코드를 가져와서 실행시켜본다.

merge된 사항이 에러 없이 제대로 구현되는지 테스팅을 진행했다.

(에러가 없이, 정상적으로 작동된 것을 확인하면, 다음 브랜치 merge 작업을 수행한다.)

 

정리하면, 모든 PR을 위와 같은 방식으로 merge를 진행하고, 테스팅을 완료하게 되면

안드로이드 팀원들에게 커밋하는 형식으로 진행되었다.

모든 팀원들이 Github를 통한 프로젝트 관리를 해본 경험이 없었기에, 불가피하게

내가 주도해서 Github 관리를 맡아서 진행했었다.

개발 비전이 다소 기간이 넓은 편이라, PR을 merge하는 작업은 순조롭게 진행되었지만,

merge 작업이 여러 번 발생되는 순간에선, 개별 PR은 개별 merge를 진행되는 프로세스를 이용해야 되겠다는 생각을 하게 되었다.

그러한 개별 프로세스를 통해 Github 레포를 관리하는 방법을 터득하는 것이 앞으로 내가 배울 점이기도 하겠다.

---

안드로이드 프로젝트 회의 관리

다음 포스팅은 이번 프로젝트에서 회의를 관리하면서
느낀점들을 기록한 포스팅으로
회의하면서 구성원으로써 의견을 제시할 때에 대한 나만의 생각을 기록해둔 포스팅이다.

아래의 포스팅을 요약하자면,
주관없이 의견을 감추기 보다는, 주관있으면서 적극적으로 의견을 내세우는 것이
더 행복하고, 회의를 더 잘 이끌어갈 수 있다는 점이다.

 

"고집같다는 생각으로 나의 주관적인 의견과 생각들을 감추는 것보다,
고집이 될 것 같더라도, 나의 주관적인 의견과 생각들을 표현하자.
그리고, 많은 경험을 토대로 나의 주관적인 의견들을 다른 사람들에게 표현할 때 고집이 아닌,
선한 영향력으로 끼칠 수 있도록 하는 방법들을 터득하자. "

자기 주관있는 삶이란

 

# 안드로이드 회의록

 

# 회의하면서 힘들었던 점 & 어려웠던 점

 

# 회의하면서 배운점
  - 주관있는 의견을 선한 영향력을 끼치며 표현하는 방법

  -  그 의견들의 표현력을 증대시키는 방법

---

마치며..