[2025 WINTER DEV] 요리 시간 관리 서비스 ‘쿡타임’, 기믹팀

프로젝트 소개

기믹팀의 ‘쿡타임’ 프로젝트는 요리 타이머 관련 불편함을 해결하는 것에 초점을 맞추었습니다. 기존의 타이머들은 단일 시간 설정만 가능하고, 여러 단계가 필요한 요리 과정에서 매번 새로 설정해야 하는 번거로움이 있었습니다. 또한, 여러 타이머를 관리할 수는 있지만 이를 체계적으로 분류하고 효율적으로 찾는 방법이 부족했습니다. 이런 문제를 해결하기 위해 ‘쿡타임’은 사용자가 요리에만 집중할 수 있도록, 자동화된 타이머 전환 기능과 직관적인 타이머 관리 시스템을 제공합니다.

‘쿡타임’은 특히 밀키트나 복잡한 요리 과정을 다루는 사람들에게 큰 도움을 줄 수 있습니다. 예를 들어, 요리 중간에 불 세기를 바꿔야 하는 경우, 기존의 타이머에서는 매번 다시 설정해야 했지만, ‘쿡타임’은 이러한 과정을 자동으로 처리해줍니다. 이를 통해 사용자는 요리의 타이밍을 놓치지 않고, 요리의 핵심에만 집중할 수 있습니다.

또한, ‘쿡타임’은 다양한 로그인 방식을 제공하여 사용자가 더욱 쉽게 서비스를 이용할 수 있도록 했습니다. 구글 로그인과 게스트 로그인 기능을 통해 회원가입 없이도 빠르고 편리하게 서비스를 이용할 수 있으며, 처음 사용하더라도 부담 없이 접근할 수 있습니다.

팀원 소개

인터뷰

Q. 프로젝트를 하면서 어떤 문제를 겪었나요?

A. 쿡타임 프로젝트를 진행하면서 기획 단계에서 상당한 시간이 소요되었습니다. 처음에는 단순한 타이머 기능만을 구현하려 했으나, 팀원들 간의 프로젝트 방향성에 대한 의견 차이로 인해 기획 회의가 길어지는 경우가 많았습니다. 일부 팀원은 사용자 경험을 높이기 위해 레시피 추천, 커뮤니티 기능 등 다양한 부가 기능을 추가하자는 의견을 제시했고, 다른 팀원은 타이머라는 핵심 기능에 충실하여 심플하게 가져가자는 의견을 냈습니다.

이러한 의견 차이를 해결하기 위해 저희는 각 기능의 우선순위를 로드맵으로 그려나갔습니다. 그 결과 핵심 기능인 타이머는 완성도 있게 구현하되, 최소한의 필요한 부가 기능들 위주로 단계적으로 개발하기로 합의되는 중간지점을 찾을 수 있게 되었습니다.

Q. 프로젝트를 하기 전 후 달라진 점이 있다면?

A. 프로젝트를 하며 가장 달라지게 된 점은 리액트 네이티브에 대한 이해도인 것 같습니다. 리액트 네이티브라는 프레임 워크의 특성에 대해 이해하고 개발을 하는 과정에서 웹 개발에만 한정되어있던 지식을 더욱 넓힐 수 있었던 것 같아요.

또한, 리액트에 비해서 에러 해결에 대한 정보가 한정되어 있고, 버전에 따른 에러가 많이 발생해서 이를 해결하는 과정에서 공식 문서 참고를 더욱 많이 참고하는 습관을 기를 수 있었습니다.

Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

A. 큰 규모의 프로젝트를 계획하다 보면 다 마무리 하지 못한 채 프로젝트가 끝나는 경우가 많습니다. 작은 규모의 프로젝트를 계획하고 차별화 포인트를 한 두가지 정도 넣는 방법으로 계획했던 프로젝트의 기능들을 모두 구현해보는 것을 권장드립니다!

Q. 이번에는 기획 관련 질문 드리겠습니다! 사용자 경험(UX) 및 사용자 인터페이스(UI) 디자인에 대한 고려사항이 어떠했나요? 사용자들의 피드백을 어떻게 수용하였나요?

A. 유저가 최대한 스크롤을 하지 않도록 한 화면에 많은 정보를 담으려고 하였고, 타이머 재생에 따른 진행도를 한 눈에 파악하기 쉽게 애니메이션을 도입하였습니다. 데브 기간동안 개발된 어플리케이션을 사용자에게 공개하였는데, 버튼 클릭이 잘 안된다는 의견을 받았습니다. 글자에만 버튼 영역이 지정되어 있기 때문인데 버튼 클릭 영역을 더 키우는 방식으로 사용자 피드백을 수용하였고 추가적으로 기능을 개발한 후에 다른 피드백도 받아보고 반영 할 계획입니다.

Q. 다음은 개발자님께 질문 드리겠습니다. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

A. 스와이프 기능을 개발하는 게 가장 까다로웠던 것 같아요. 처음에는 라이브러리를 통해서 구현하고자 했는데 리스트 형태의 블럭을 좌우로 스와이프 할 수 있게 도와주는 라이브러리는 있지만 제가 원하는 형태의 스와이프는 제공하지 않아서 제스처 핸들러와 reanimated를 활용해서 직접 개발했습니다.

아래로 스와이프 하는 기능을 만드니 위로 스와이프가 되지 않고, 하나를 해결했더니 또 다른 문제가 발생하더라고요. 알고보니 제가 reanimated 특성을 제대로 이해하지 못하고 활용하다보니, event와 value를 혼동해서 사용해 발생하는 문제였습니다. 단순 구현에만 초점을 맞추지 않고 제가 사용하는 라이브러리나 기능에 대해서 꼼꼼히 공부하고 활용할 수 있는 능력을 길러야 한다는 교훈을 얻게 됐던 것 같아요.

Q. 팀 내 협업에서 문제가 없었는지는 궁금합니다!

A. 저희 쿡타임 프로젝트는 4명의 개발자가 함께 참여하여 진행되었습니다. 초기 개발 단계에서는 순조롭게 진행되었으나, 개발 막바지에 테스트를 진행하면서 여러 오류가 발견되었습니다. 당시 시간적 압박감이 있었기에, 오류 해결에 대한 체계적인 계획이나 팀원 간 상호 조율 없이 각자 발견되는 오류를 개별적으로 수정하는 방식으로 작업을 진행했습니다.

이러한 방식은 여러 문제를 야기했습니다. 동시다발적인 코드 수정으로 인한 충돌이 빈번히 발생했고, 때로는 다른 팀원이 수정한 부분을 인지하지 못한 채 작업을 진행하여 코드가 누락되거나 의도치 않게 변경되는 상황이 발생했습니다. 이러한 경험을 통해 기능 개발 순서 조율의 중요성을 깊이 깨닫게 되었습니다.

이후 이러한 문제를 해결하기 위해 매주 스크럼 미팅을 진행하여 작업 우선순위를 명확히 설정하고, 충돌 가능성이 있는 작업을 사전에 조정하는 등의 협업 방식을 도입하여 이전보다 더욱 안정적인 어플리케이션을 구축할 수 있었습니다.

Q.본인 팀만의 특별한 협업 방식이 있나요? 있다면 소개해 주세요!

A. 기믹팀은 본격적인 개발에 들어가기 전에 Git과 관련된 여러 규칙을 상세히 정하고 조율했습니다. 우선, 커밋 메시지 작성 시 일관성을 유지하기 위해 메시지 컨벤션을 정의하고, 브랜치의 구조와 이름 규칙을 명확히 했습니다. 또한, 브랜치를 생성하기 전에는 반드시 GitHub에서 이슈를 먼저 등록하도록 하고, 이슈 템플릿과 Pull Request 템플릿을 정의하여 Git에 업로드함으로써 일정한 형식으로 이슈와 PR을 작성하도록 유도했습니다.

업스트림 브랜치로 PR를 보낼 때의 주의사항과 일련의 과정을 팀원들 간에 공유하여 협업의 효율성을 높였습니다. 예를 들어, 개발 중 upstream에 새 커밋이 추가된 경우, 자신의 변경 사항을 바로 PR을 보내지 않도록 주의해야 한다는 점을 상기시켰고, PR을 보내기 전에는 stash - checkout - pull - rebase - stash pop - push 순서로 작업하여 커밋 트리가 꼬이지 않도록 할 수 있습니다. 이외에도, merge 전에는 반드시 팀에서 결정한 연락 수단을 통해 머지 의사를 전달하고, PR을 보내기 전에 코드 리뷰를 요청하는 등의 세부적인 규칙을 적용하여 협업의 품질을 높였습니다. 이러한 협업 방식을 적용한 덕분에, 기믹팀은 코드의 일관성을 유지할 수 있었습니다.

지금까지 요리 시간 관리 서비스 ‘쿡타임’을 개발한 기믹팀의 인터뷰였습니다! 기획부터 개발까지 치열한 고민과 협업 과정을 엿볼 수 있었습니다. 읽어주셔서 감사합니다~🙌