데이블럭 회고 - 하루 24개의 블럭을 가치있게 쌓아나가는 방법

프로덕트 디자이너에서 iOS 개발자로서의 걸음마를 뗄 수 있었던 첫 번째 개인 프로젝트 회고입니다.

• 참여 인원 : 개인 프로젝트
• 역할 : 기획 / 디자인 / 개발
• 기여도 : 100%
• 프로젝트 기간 : 2023.03.01 - 2024.01.11(약 10개월)
• 기술 스택 : UIKit / CoreData
• Github : DayBlock - Github
• AppStore : DayBlock - AppStore

---

앱 소개

하루 24개의 블럭을 가치있게 쌓아나가는 방법, DayBlock 데이블럭과 함께해요!

"내가 얼마나 생산성 있는 시간들을 보냈을까?"

우리 모두는 하루를 다양한 시간으로 채워가고 있어요.
그중 기록하고 싶은 시간들을 블럭으로 만들고 쌓아가다 보면
노력과 열정의 흔적을 데이블럭에서 확인할 수 있을 거에요.

생산성 트래킹

• 30분 단위로 시간을 측정해 생산성 블럭을 쌓아나가요
• APP이 종료되어도 데이블럭이 똑똑하게 트래킹을 진행해요

나만의 블럭 및 그룹

• 작업명, 색상, 아이콘을 활용한 나만의 개성 있는 블럭을 만들어요
• 그룹을 이용해 연관성 있는 블럭끼리 묶어서 관리해요

캘린더

• 캘린더를 이용해 해당 날짜에 어떤 블럭을 얼마나 생산했는지 확인해요
• 다양한 블럭을 생산할수록 캘린더 블럭의 모양이 변해요

---

KPT 회고하기

1️⃣ Keep

1. 디자인 시스템과 연계한 컴포넌트 관리
Figma Component 기능을 활용해 디자인 시스템을 구축 후 코드에 적용시켰습니다. 디자인상 변경사항이 있어도 큰 비용 없이 변화가 가능한 형태를 지향했습니다. 이를 통해 일관성 있는 UI 디자인을 최종 프로덕트에 적용할 수 있었습니다. 기획, 디자인, 개발, 배포 전 과정을 개인으로 진행했기 때문에 조금은 수월했던 것 같기도 합니다.

 

2. 꼼꼼한 주석 정리
최근 들어, “혼자 개발하는 것도 협업이 될 수 있다”라는 말에 더욱 공감이 갑니다. 한 달 전의 나와, 지금의 나는 같은 맥락 상에 놓여있지 않기 때문입니다. 더군다나 공부량이 많은 요즘, 한번 습득한 지식 및 정보를 어떻게 온전히 내 것으로 만들 수 있을지 깊이 고민하게 됩니다.

 

주석을 통해 미래의 나와 협업할 수 있도록 노력했고, 의도치 않았지만 일정이 늘어질수록 큰 힘을 발휘할 수 있었습니다. 추가로 Documentation을 위한 주석(/// 주석, Parameter 정리 등) 활용법을 깊이 배웠습니다.

 

3. 경험에 근거한 코드 컨벤션 스타일 확립
개인 프로젝트를 진행하며 내가 작성한 코드에 대해 고민할 수 있는 시간이 많았습니다. 자연스레 특정 작성법들에 대한 필요성 혹은 불편함을 느끼게 되었고, 이는 개인 코드 컨벤션 확립에 많은 도움이 되었습니다. 또한 추후 팀 컨벤션 결정에 꼭 필요한 근거들에 대해서도 정리할 수 있었습니다.

 

4. 이벤트 처리에 대한 이해도 상승
프로젝트의 목표 중 하나는 “기본에 충실하기”였습니다. 그에 대한 실천법으로 외부 프레임워크 및 라이브러리의 개수는 최소화하고, Swift + UIKit이 제공하는 기본 기능은 최대한 활용했습니다.

 

CallBack, Delegation, Notification 등 이벤트 처리 방법을 중점적으로 공부했습니다. 그중에서도, Apple이 제공하는 많은 Framework에 적용된 Delegation의 경우 직접 구현을 통해 깊은 이해와 함께 적용할 수 있었습니다.

 

5. 프로젝트 일지 작성
프로젝트 성장 과정을 남기려 Github을 활용해 일지를 작성했습니다. 하루를 마치고 무슨 기능을 개발했는지, 어떤 문제가 있었는지, 어떻게 해결했는지 등을 기록했습니다. 생각을 정리하고 진척도를 확인할 수 있었습니다.

---

2️⃣ Problem

1. 끝없이 밀려나는 일정
가장 회고하고 싶었던 부분이기도 합니다. 본격적인 프로젝트 시작 전 간트 차트를 활용해 3개월간의 계획을 세웠지만, 결국 하나도 지켜지지 못했습니다. 근본적인 원인은 크게 2가지가 있었습니다.

 

첫 번째는 개인 일정을 보수적으로 고려하지 못했다는 점입니다. 회사 업무 이후 프로젝트를 진행했기에 절대적인 시간이 부족했고, 아카데미 지원 등의 외부 변수가 생겨났습니다. 일의 우선순위 및 변수를 고려해 현실적인 프로젝트 기간을 산정했으면 어땠을까 하는 아쉬움이 남습니다.

 

두 번째는 처음으로 진행해 본 프로젝트였다는 점이었습니다. 초기에 생각했던 비즈니스 로직, UI 기능 구현 등 예상했던 기간 내에 끝내는 데 스스로 부족한 점이 많았습니다. 자연스레 시간은 훨씬 오래 걸리게 되었고, 이후 일정 계산에도 어려움이 생겼습니다.

 

결과적으로 3개월로 예상했던 프로젝트는 훨씬 지난 10개월짜리 프로젝트로 마무리되었습니다.

 

2. 정돈되지 않은 기획
DayBlock 프로젝트는 개인적인 동기로 시작하게 되었습니다. 나를 위한, 내가 사용할 프로덕트였기에 기획에 대한 의사결정이 어렵지 않았습니다. 머릿속으로 큰 그림을 그려나갔고 빠르게 기능 리스트를 작성해나갔습니다.

 

그렇게 초기 디자인과 개발까지 빠르게 치고 나가는 듯했으나, 중반부터는 정돈되지 않은 기획으로 속도가 급격히 느려지게 되었습니다. 특히 DayBlock의 핵심 비즈니스 로직인 시간 관리에 허점이 많아 디자인을 수정하고 구현했던 내용을 뒤집어야 하는 상황이 발생했습니다.

 

3. 비즈니스 로직 테스트의 어려움
주요 엔티티 관리 및 핵심 비즈니스 로직 작성을 위해 GroupDataStore, BlockDataStore, TrackingDataStore 등의 객체를 구현했습니다. 이는 모두 앱 내 전역적으로 공유하는 객체였기에, 싱글톤 패턴을 사용했습니다. 또한 서로를 호출해야 하는 상황도 빈번했기에 서로를 참조했습니다.

 

처음은 사용 면에서도, 개발 속도 면에서도 효율적이었습니다. 싱글톤 객체는 어디서든 사용이 가능했고, 객체 내에서도 서로를 참조하기 쉬웠기 때문입니다. 하지만 프로젝트가 진행됨에 따라 여러 가지 문제가 발생했습니다.

 

첫 번째는 개발 비용의 증가입니다. 객체 간 의존성이 전혀 고려되지 않았기에 서로 강하게 결합되어 있었고, 코드 한 부분을 건드리니 여러 객체에서 에러가 쏟아졌습니다. 자연스레 작은 로직 수정도 큰 비용으로 다가왔습니다.

 

두 번째는 비즈니스 로직 테스트의 어려움입니다. DayBlock은 시간 관리에 세심한 비즈니스 로직 적용이 필요했습니다. 이를 위해 다양한 테스트 케이스가 필요했지만 강하게 결합되어 있는 객체 사이에 테스트 케이스 작성 난이도는 불필요하게 높았습니다. 또한 CoreData 프레임워크에 의존하고 실제 시간에서만 동작 가능한 로직은 이를 더욱 어렵게 만들었습니다.

---

3️⃣ Try

1. 구현 만큼 설계에도 집중하기
첫 번째 개발 프로젝트에서 가장 간과한 것은 설계보다 구현에 집중한 점입니다. 빠르게 기능 개발에 착수하고 싶은 마음에 얕은 설계로 프로젝트를 진행했고, 그 결과 일정 관리의 어려움과 비효율적인 개발을 만들었습니다. 이후 프로젝트에서 설계 단계에 더 집중해 보고자 합니다.

• 기능 명세서 여러 가지 케이스를 고려해 꼼꼼히 작성하기
• 핵심 비즈니스 로직 시각화하기
• 실제 구현 가능 여부 확인을 위한 타당성 조사 진행하기

 

2. 객체 간 의존성 관리
무분별한 싱글톤 패턴 사용, 서로를 강하게 참조하고 있는 객체 등은 개발 비용 증가와 비즈니스 로직 테스트의 어려움을 만들었습니다. 이론적으로만 배웠던 다양한 문제점들을 실제 경험하고 나니 평소 실감하지 못했던 의존성 관리의 중요성을 절실히 깨닫게 되었습니다.

• 객체 간 의존성 그래프 시각화하기
• 의존성 역전(DIP) 활용해 보기
• 프로젝트 규모, 특성에 맞는 아키텍처 리서치 및 적용하기

 

3. 키워드 중심 딥다이브
프로젝트에서의 목표는 ‘일정 내 기획 및 배포까지의 프로세스를 경험’하는데 초점이 맞춰져있었습니다. 늘어나는 일정에 쫓기다 보니 자연스레 구현 그 자체에 집중하게 되었고, 학습적으로 돌아봤을 때 아쉬움이 남습니다. 사용 기술에 대한 깊은 이해를 하고자 합니다.

• CoreData 딥다이브하기
• 내가 작성한 코드 중 설명이 불가능하거나 모호한 부분 찾아 공부하기

 

4. 회고는 내용만큼이나 시기가 중요하다!
프로젝트가 끝나고 8개월이 지난 지금 회고를 다시 한번 작성하고 있습니다. 당시 작성할 때와 지금의 느낀 점이 달라 회고가 조금은 미화되는 것 같기도 합니다. 산출물에 대한 아카이빙은 미뤄서 하는 것이 아닌, 바로 진행해야 한다는 말이 생각납니다.

• 프로젝트 스프린트 기간 종료 시, 일주일 내에 회고 작성하기.
• 블로그, 링크드인 등을 활용해 회고 내용 공유하기.

---

전체 회고

프로젝트가 끝난 후 대략 8개월 정도 지났습니다. 회사 업무를 마치고 집으로 돌아와 머리를 부여잡고 개발했던 기억이 가장 많이 납니다. 모든 게 낯설고 어려웠으며, 어처구니없는 실수도 많이 했습니다. 배포까지의 과정은 예상보다 훨씬 힘들었습니다.

 

그렇게 고군분투 후 앱스토어에서 DayBlock의 이름을 본 순간은 아직까지도 새롭게 느껴집니다. 어릴 때부터 지닌 ‘내 생각을 구체화시켜 서비스로 출시해 보자’라는 꿈이 실현된 순간이었죠.

 

디자이너에서 개발자로 직무 전환을 결심하게 된 결정적 요인이기도 했습니다. 처음엔 UX/UI 디자인을 사랑하는 사람으로서 개발이 정말 나와 맞을까에 대해 수차례 고민했습니다. 둘은 너무나 동떨어져 있다고 생각했습니다.

 

하지만 프로젝트 경험 후, 생각은 완전히 달라졌습니다. 둘은 함께 갈 수 있을 만큼 닮아있었습니다. 가치를 만들어내는 방법이 다를 뿐 근본적인 지향점은 같았습니다. 개발자의 길을 걷는 것이 디자이너의 길을 포기하는 것이 아니라는 확신이 들었습니다.

 

확신이 있었기에 재미도 있었습니다. 내가 만든 디자인을 실제 동작 가능한 기능으로 구현시키는 것, 끈기 있게 설계한 로직이 원활하게 작동하는 것, 누군가에게 필요할 수 있는 프로덕트를 만들어내는 것 모두 재미있었습니다. 디자이너로서 가치를 만들어내는 것 만 큼이었습니다.

 

DayBlock 프로젝트는 앞으로의 방향성을 결정할 수 있게 도왔습니다. 새로운 시작점이자, 밑거름으로서 많은 성장을 할 수 있었습니다. 지금 배우고 느낀 점들을 소중히 간직해 좋은 개발자가 되고 싶습니다.