안녕하세요, 데이트팝 백엔드 개발자 이찬영입니다.
주니어 개발자로서 처음 전사 프로젝트 킥오프 회의에 참여하게 되었습니다. '킥오프'라는 단어만 들어봤지, 실제로 어떻게 진행되는지, 왜 필요한지 막연했는데요. 이번 첫인상 프로젝트 킥오프를 경험하며 프로젝트가 시작되는 과정을 이해하게 되었습니다.

첫인상 프로젝트란?

데이트팝 앱을 실행하면 처음 보이는 지도 화면을 유저 친화적으로 개선하는 프로젝트입니다. 앱의 첫인상을 결정하는 화면이다 보니, 개발팀 전체가 참여하는 중요한 프로젝트였습니다.

현재 데이트팝 초기 화면
현재 데이트팝 초기 화면

2차에 걸친 킥오프, 왜 그럴까?

데이트팝의 킥오프는 1차와 2차로 나뉘어 진행됩니다. 처음엔 "왜 두 번이나 모이지?"라는 생각이 들었는데, 참여해보니 각각의 목적이 명확했습니다.

1차 킥오프: 큰 그림 그리기
CEO, COO, 개발팀장, 그리고 iOS/Android/백엔드 개발자까지 전 직군이 모입니다. 이 시점에 디자인은 80% 정도 완성된 상태입니다.

1차 킥오프에서는 기술적 실현 가능성을 중심으로 논의합니다. 이번 프로젝트에서는 이런 질문들이 나왔습니다:

  • 애니메이션을 어떤 포맷으로 구현할 것인가?
  • 용량과 품질의 균형을 어떻게 맞출 것인가?
  • iOS, Android 양쪽에서 문제없이 동작하는가?

약 40분간 논의하고, 각 직군이 조사할 내용을 가져갑니다. 저는 백엔드 개발자로서 이미지/애니메이션 포맷 비교를 맡았습니다.

2차 킥오프: 조사 결과 공유 및 기술 결정
1차 이후 각자 조사해온 내용을 공유하고, 구체적인 기술 스택을 결정합니다.

GIF vs Lottie: 수치로 보는 기술 선택

저는 GIF와 Lottie를 비교 조사했습니다. 같은 애니메이션을 구현할 때 차이가 명확했습니다:

GIF 방식

  • 용량: 2~3MB (5초 기준 애니메이션)
  • 장점: 별도 라이브러리 없이 즉시 재생 가능
  • 단점: 프레임 제한으로 부드러운 애니메이션 구현 어려움

Lottie 방식

  • 용량: 30~50KB (JSON 기반 벡터 애니메이션)
  • 장점: GIF 대비 60~100배 가볍고 부드러운 애니메이션 표현 가능
  • 단점: 전용 라이브러리 필요, 플랫폼별 호환성 검토 필요

하지만 백엔드 개발자인 제가 용량만 보고 판단할 수는 없었습니다. iOS와 Android 개발자분들이 라이브러리 호환성과 각 플랫폼에서의 렌더링 일관성을 확인해주셨고, 디자인팀에서 원하는 애니메이션 표현이 Lottie로 구현 가능한지 검토했습니다.

결론적으로 Lottie를 선택했습니다. 각 직군의 검토를 거쳐 내린 결정이었습니다.

킥오프 이후 프로세스

킥오프가 끝나면 이런 흐름으로 진행됩니다:

Kick-off → Preview 회의 → 일정 수립 → Sprint 1~n → QA → 배포

주니어 개발자도 자료 조사와 기술 검토에 참여합니다. Preview 회의에서는 킥오프에서 정한 방향을 바탕으로 더 구체적인 설계를 논의합니다.

주니어 개발자로서 배운 것

킥오프를 경험하며 몇 가지를 배웠습니다.

첫째, 기술 선택은 단일 관점으로 할 수 없습니다.
백엔드 개발자인 저는 처음에 용량과 전송 효율만 생각했습니다. 하지만 iOS 개발자는 라이브러리 호환성을, Android 개발자는 렌더링 일관성을, 디자이너는 표현력을 고려했습니다. 각 직군의 관점이 모여야 제대로 된 기술 선택이 가능했습니다.

둘째, 킥오프를 2차로 나누는 이유를 이해했습니다.
1차에서 모든 걸 결정하려 하면 근거 없는 추측에 기반한 결정을 내릴 수밖에 없습니다. 1차에서 질문을 정리하고, 조사 후 2차에서 결정하는 방식이 훨씬 합리적이었습니다.

셋째, 프로젝트는 킥오프에서 시작됩니다.
단순히 "이런 기능 만들자"가 아니라, 왜 만드는지, 어떻게 만들 것인지, 각자의 역할은 무엇인지 명확히 하는 과정. 그게 킥오프였습니다.

다음 글에서는 Preview 회의 내용을 공유하겠습니다.