[iOS] '오르비 알람' 프로젝트 진행과정 회고(기획, 협업, 개발)

 

안녕하세요

 

 

최근에 활동했던(지금은 운영진) IT동아리 활동을 마치게 되어 회고를 작성해 보려고 합니다.

 

 

전체적으로 프로젝트가 진행됬던 흐름되로 작성하며 회고를 해보겠습니다.

 

 

기획

해당 프로젝트는 IT동아리에서 진행하는 프로젝트라, 뚜렷한 기획을 가지고 시작하는 프로젝트는 아니였습니다.

 

 

물론 팀원중 PM직군이 있었지만, 기획 아이디어는 모든 팀원이 함께 선정해야했습니다.

 

 

프로젝트 기간이 촉박했기에 빠른 아이템 선정이 필요했습니다.

 

 

그렇다고 기획적으로 부실한 프로젝트를 시작할 경우 랜턴없이 동굴속으로 들어가는 것이겠죠.

 

 

 

소프트웨어 마이스트로 연수생시절에 기획때문에 어려움을 겪었던 경험이 있었습니다.

 

 

그 당시에 아이디어를 도출하고 검증하기 위해 사용했던 방법론들을 활용할 수 있겠다고 생각했습니다.

 

 

그중 '6Hat' 방식을 사용하자고 제안하였습니다.

(6가지 역할을 통해 아이디어를 평가하는 방법론)

 

 

해당 방식에 대해 간략하게 설명을 하자면, 팀원들에게 특수한 역할을 부여하여 아이디어를 검수하는 것입니다.

 

 

역할에는 비관적인 사람, 긍정적인 사람, 자료조사에 충실하는 사람등이 존재합니다.

 

 

이 방법이 효율적인 이유는 다른 사람의 아이디어를 마음껏 평가할 수 있는 명분을 줍니다.

 

 

기획이라는 것이 겪어보지 않는 이상 단언할 수 없는 것이기에

 

 

다른 사람의 아이디어를 비평하기는 상당히 조심스러운 부분이 많다고 생각합니다.

 

 

따라서 시스템적으로 팀원들에게 책임을 부여하여 빠르고 객관적인 아이템 선정이 가능했습니다.

 

 

아래 이미지는 당시 제가 냈던 "생성형AI를 활용한 대화형 일기작성" 아이디어에 대한 팀원들의 의견들중 일부입니다.

 

6Hat 방법론 예시

 

결과적으로 저희팀은 알람앱을 선택하게 되었습니다.

 

 

하지만, 단순히 알람을 울리것에 그치지 않고 기상미션 수행을 통해

 

 

의미있는 정보를 제공하는쪽에서 차이점을 확보하자는 판단을 하였습니다.

 

 

인터뷰를 통해 목표하는 연령층이 '하루 운세'에 관심이 많다는 사실을 알게되어

 

 

최종적으로 기상알람과 운세를 확인하는

 

 

'오르비 알람' 애플리케이션이 시작되게 되었습니다.

 

 

협업툴 JIRA

저희팀은 총 9명으로 구성되어 있었습니다.

(PM: 1명, 디자인: 2명, AOS: 2명, iOS: 2명, 서버: 2명)

 

 

지금까지 했던 프로젝트중 가장 많은 인원이였습니다.

 

 

프로젝트를 운영을 효율적으로 할 수 있는 방법에 대해 고민하였고

 

 

한번 사용해본 적이 있는 JIRA를 사용하는 것이 좋겠다고 판단했습니다.

 

 

하지만 저희 팀원중 과반이 JIRA툴을 사용해 본적이 없어 당황하였지만,

 

 

협업시스템을 구축하는 경험은 다음에도 좋은 경험이 될 것 같아 설득을 통해 JIRA를 사용하기로 결정했습니다.

 

 

우선 JIRA에 대한 러닝 커브를 최소화 하기위해 팀원들이 보기쉽게 문서화하는 과정을 가장 1순위로 수행했습니다.

 

 

노션 문서화

 

그후 깃허브와 지라를 연동하여 티켓 관리를 진행하도록 하여, 개발사항과 작업처리를 동기화시키도록 했습니다.

 

 

 

 

티켓을 총 130개 이상을 생성하여 프로젝트를 진행할 수 있었습니다.

 

 

프로젝트 초기에는 해당 방식이 잘 동작하였습니다.

 

 

하지만, 후반으로 갈수록 개발을 빠르게 처리하는 것에만 급급해져 동기화가 잘 이루어지지 않았습니다.

 

 

아무래도 기한내에 배포를 해야하는 것에만 급급하여 이러한 과정들에 다소 소홀하졌다고 생각합니다.

 

 

개발

 

iOS개발자는 2명이였습니다.

 

 

저희는 시작하기 앞서 정한 목표가 있었습니다.

 

 

프로젝트를 기능단위로 분할(모듈화)화여 예시앱을 배포하고 테스트하자!

 

 

해당 목표를 세운 이유는 다음과 같습니다.

 

 

1. 효율적인 작업 분배

 

 

개발할 기능을 모듈화되어 있기에 온전히 해당 기능을 개발하는 개발자에게 책임을 부과할 수 있습니다.

 

 

2. 퀄리티 유지

 

 

앱을 완성한 후 QA를 진행한 경우 너무 많은 수정사항이 한번에 도출되는 문제가 있을 수 있습니다.

 

 

이 경우 모든 것을 고려하여 앱을 개선하는 것은 매우 힘든 작업이 될 것이며 시간도 오래걸릴 것이라고 생각했습니다.

 

 

3. 지속적인 동기부여

 

 

웹의 경우 완성된 기능의 일부를 지속적으로 보여줄 수 있습니다.

 

 

하지만, 앱의 경우 그렇지 않기에 예시앱을 주기적으로 배포하여 팀원들에게 다음과 같이 말하고 싶었습니다.

 

 

"저 열심히하고 있어요! 조금만 힘내줘요"

 

 

다소 소홀해질 수 있는 사이드 프로젝트의 무언의 동기부여가 될 수 있다고 생각했습니다.

 

 

RIBs아키텍처

 

그래서 저희가 선택한 아키텍처는 RIBs입니다.

 

 

RIBs의 경우 프로젝트를 모듈화 하기에 정말 적합한 구조를 가지고 있다고 판단했습니다.

 

 

막상 RIBs의 장점을 알게되었긴 했지만, 한번도 사용해보지 못했던 라이브러리라 학습하는데 다소 시간이 걸렸습니다.

 

 

하지만 다행히도 능숙한 팀원덕분에 빠르게 적응할 수 있었습니다.

 

코드리뷰를 진행

 

RIBs아키텍처의 경우 모듈화를 효율적으로 진행할 수 있는 구조라고 생각합니다.

 

 

모듈의 외부로 노출되는 객체들을 추상화하기 때문에 모듈들을 각각 개발하고 이어 붙이기 유연하다는 것을 느낄 수 있었습니다.

 

 

하지만 새로운 기능을 추가할 때 마다 RIB의 구성요소를 모두 생성하여 관리해야한다는 점은 다소 귀찮은 작업이라고 생각했습니다.

 

 

RIBs는 대규모 프로젝트에 적합하다는 이유가 바로 이것이라고 생각되내요..

 

 

결과적으로 RIBs를 사용하여 프로젝트를 잘 모듈화할 수 있었고 기능별로 예시앱을 배포할 수 있었습니다.

 

 

아래 이미지는 프로젝트를 구성하는 모듈들의 일부입니다.

 

 

기능 모듈마다 앱 타겟(파란색 직육면체, Example suffix)이 존재하는 것을 확인하실 수 있습니다.

 

 

프로젝트 모듈 그래프

 

 

예시앱들을 배포하여 프로젝트 내내 QA를 지속적으로 진행할 수 있었습니다.

 

 

기한동안 총 90개의 수정사항을 도출할 수 있었고, 그중 70%를 해결할 수 있었습니다.

 

 

QA리스트 입니다.

 

QA시트

 

 

 

이전에 프로젝트를 진행할 때는 전체 개발이 완료된 시점에서 QA를 진행하곤 했습니다.

 

 

하지만, 해당 시점에는 디자이너분이 다소 동기부여가 많이 떨어져 보였습니다.

 

 

하지만, 기한 내내 검수과정을 함께하며 끝까지 열정을 가지고 작업에 참여하시는 것을 볼 수 있었습니다.

 

 

이것 때문이라도 의미가 참 컷던 작업이였습니다.☺️

 

 

알람기능 개발

 

iOS는 공식적으로 알람기능에 대한 API를 제공하지 않습니다.

 

 

하지만 시장에 알라미라는 애플리케이션이 있고 잘 동작한다는 것을 알 수 있습니다.

 

 

일단 시장에 비슷한 기능의 서비스가 있기에 기획을 결정할 시점에는 어떻게는 개발이 가능할 것이라고 판단하였습니다.

 

 

하지만, 공식적으로 지원하는 API가 없기에 여러 방면으로 논의가 필요했습니다.

 

 

앱을 백그라운드에 계속 살려두는법, 백그라운드에서 오디오, 진동을 재생하는 법, 정확한 시각에 작업을 실행하는 법.....

 

 

정글 속을 누비는 느낌이였지만, 서비스를 설계하고 구현하는 과정은 자체는 재밌고 흥미로웠습니다.

 

 

'오브젝트'도서를 감명깊게 읽었던 지라, 책임을 여러 객체로 분산시키기 위해 고민하는 경험을 할 수 있어 좋았습니다.

 

 

결과적으로 아래와 같은 협력 관계를 설계하고 개발하는데 성공하긴 했습니다.

 

'오르비 알람'의 알람 시스템

 

 

https://github.com/YAPP-Github/25th-App-Team-1-iOS/pull/34

 

 

개발 및 테스트를 마친후 배포를 하였고 잘 동작할 것이라 믿었습니다.

 

 

하지만, 운영단계에서 유저 지표를 통해 확인해본 결과 알람 시스템은 결함이 많았습니다.

 

 

앱을 백그라운드에 계속 살려둔다고 해도 배터리가 없거나 명확하게 알 수 없는 이유로 애플리케이션이 Suspended상태로 전환되어

 

 

내부 스케쥴러가 동작하지 않는 문제가 많은 유저에게서 발생했습니다.

 

 

해결방법에 대해 앞으로도 고민과 탐색을 겁듭할 예정입니다.

 

 

해당 경험을 통해 느낀 것은 다음과 같습니다.

 

 

• 시간에 쫒기는 작업이라도 기술적 고려가 프로젝트초기에 충분히 진행됬어야 했다.
• 다른 서비스가 성공했는데 어떻게든 되겠지 라고 생각하는 것은 다소 위험한 생각일 수도 있겠다고 느꼈다.
• 애플의 가이드라인을 벗어나는 기능에 대한 구현은 다소 명확한 해법을 찾기 어렵다.
• 의미있는 테스트에 대한 탐구가 필요하다고 느꼈다. 몇 %성공이 테스트의 목적인가? 이번 같은 경우 어떤 테스트가 필요했는가?

 

로깅 시스템 구축

 

앱을 배포한 이후 인스타그램 홍보등을 진행하여 100명의 유저를 모을 수 있었습니다.

 

 

시잔의 반응이 좋아 프로젝트를 계속 진행하게 되었고, 로깅을 통해 프로젝트를 개선하고 싶었습니다.

 

 

따라서 로깅시스템을 적극 제안하였고, 도입하였습니다.

 

 

PM분과 함께 작성한 이벤트 명과 프로퍼티들입니다.

로깅 이벤트 명세

 

해당 기능은 개발 및 배포를 완료하여 아래와 같이 지표를 확인하고 있는 단계입니다.

 

 

더 나아가 의미있는 개선 경험으로 연결 시키는 것을 목표로 하고 있습니다.

 

 

 

 

클라우드 로깅 툴로는 Amplitude를 사용했습니다.

 

 

앰플리튜드의 경우 Funnel을 무료로 구축할 수 있고 AOS, iOS SDK를 모두 지원한다는 점에서 선택하게 되었습니다.

 

 

로깅시스템을 구축하며 느낀점

• Funnel의 목적이 다소 불분명합니다. 전환율을 보겠다는 것을 알겠는데 몇 %전환을 목표로하는가에 대해선 아직까지 잘 판단이 서질 않습니다. 이부분에 대해서 공부가 필요할 듯 합니다.

 

성과

 

'오르비 알람' 서비스는 YAPP이라는 IT동아리에서 3~4개월간 진행한 프로젝트입니다.

 

 

팀원들과 다양한 시도를하고 열심히 개발에 정진한 때문인지 결과적으로 20개의 팀중 대상을 차지할 수 있었습니다.

 

 

서비스를 개발하고 수상을 하게되는 것이 처음이라 기분이 좋았습니다.

 

대상~!

 

프로젝트를 잘 마무리한 제 자신한테 대견하고, 함께 해준 팀원들에게 감사합니다.

 

 

기술적으로 아직 해결되지 못한 문제들이 있어 제 스스로 아쉬운 점이 있기도합니다.

 

 

하지만, 이또한 앞으로 성장의 믿거름이라고 생각하고 더 발전하도록 할 것입니다.

 

 

함께 고생해준 팀원분들께 진심으로 감사드립니다.

 

 

 

‎Orbit(오르비 알람): 기상알람, 운세