[2026 WINTER DEV] 뜨개 도안을 제작하고 판매하는 애플리케이션 ‘뜨개도아’, HOMIS팀”

프로젝트 소개

“뜨개도아”는 뜨개 도안의 제작과 판매 기능을 하나의 애플리케이션 안에서 통합적으로 제공하는 플랫폼입니다.

팀원 소개

HOMIS팀은 APP 준희님, PM 지우님, BE 선주님, DE 아현님으로 구성되어 있습니다!

인터뷰

Q. 프로젝트를 소개해주세요!

(준희) 뜨개도아는 뜨개 도안의 제작과 판매 기능을 하나의 애플리케이션 안에서 통합적으로 제공하는 플랫폼입니다.

현재 뜨개 도안 시장은 도안을 만드는 제작 툴과 거래하는 마켓플레이스가 엄격히 분리되어 운영되고 있습니다. 이로 인해 도안 제작자는 도안을 완성한 뒤 별도의 플랫폼에 업로드해야 하는 번거로운 과정을 거쳐야 하며, 이러한 구조는 사용자에게 지속적인 불편함을 초래합니다.

저희는 이러한 구조적 문제를 개선하고자, 도안 제작 완성과 동시에 판매 등록까지 한 번에 이어지는 일원화된 시스템을 기획하고 구현하였습니다. 사용자가 도안을 완성한 이후 판매를 위해 다른 플랫폼으로 이동해야 하는 불필요한 과정을 제거함으로써, 제작부터 판매까지의 흐름을 하나의 서비스 안에서 자연스럽게 이어지도록 설계하였습니다. 또한, 제작된 도안을 PDF나 PNG 등의 범용 파일 형식으로 자유롭게 내보낼 수 있도록 지원하여, 사용자가 자신의 도안을 개인적으로 소장하거나 외부에 공유할 수 있도록 하였습니다.

비록 실제 결제 기능은 구현되지 않았지만, 도안 제작부터 판매 관리까지 이어지는 일련의 흐름을 하나의 애플리케이션 안에서 경험할 수 있도록 기능을 구성하였습니다. 최종적으로 뜨개도아는 창작자가 별도의 번거로움 없이 자신의 작업물을 관리할 수 있는 환경을 지향하며, 누구나 자신만의 창작물을 공유하며 뜨개의 즐거움을 마음껏 누릴 수 있는 공간을 제공합니다.

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

(지우) 프로젝트 초반에는 1인 가구를 위한 커뮤니티 기반 앱을 기획하며, 행정 정보처럼 흩어져 있는 내용을 한곳에 모아 사용자에게 도움을 주는 것을 목표로 했습니다.

하지만 여러 차례 회의를 거치면서 팀원마다 생각하는 서비스 방향이 달라 기획이 반복적으로 수정되었고, 그 과정에서 앱의 정체성이 흐려지며 기획 단계에 머무르는 시간이 길어졌습니다. 또한 정보 제공을 위해 사진 자료를 활용하려는 과정에서 저작권 문제가 발생할 수 있어, 핵심 기능을 그대로 유지하기 어려운 상황도 겪었습니다.

이 경험을 통해 프로젝트를 진행하는 동안 서비스의 정체성과 핵심 방향을 지속적으로 점검하는 것이 중요하며, 현실적인 제약을 고려해 여러 가능성을 열어두고 기획해야 한다는 점을 깨달았습니다. 이러한 점을 바탕으로 최종 프로젝트인 뜨개질 프로젝트에서는 초기 단계부터 방향성을 명확히 설정하고, 이를 기준으로 기획을 조율하며 보다 안정적으로 프로젝트를 진행할 수 있었습니다.

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

(선주) 개발을 바라보는 관점이 가장 크게 달라진 것 같습니다! 이전에는 기능을 빠르게 구현하는 것에만 집중했고, 그렇다 보니 라이브러리 선정과 구조 설계 등에 대해 깊이 고민하기보다 기존 레퍼런스를 참고해 그대로 따라 구현하는 경우가 많았습니다.

하지만 이번 프로젝트를 진행할 때에는 단순히 동작하는 코드를 짜는 대신, 왜 이 구조인지, 현재 서비스의 특성과 팀 환경에 적합한 방법은 어떤 것일지를 고민하며 설계에 더 많은 시간을 투자하였습니다. 그 과정에서 처음으로 제가 스스로 생각하고 판단해 백엔드 구조를 만들어가고 있다는 느낌을 받았고, 그만큼 제 코드에 대한 이해도 또한 더 높아졌습니다. 이를 통해 그간 글로만 접했던 개념인, 개발자는 단순히 코드를 작성하는 사람이 아니라 복합적인 요소를 고려해 상황에 맞는 최선의 선택을 해야 하는 사람이라는 걸 경험으로 체감할 수 있었습니다.

처음 해본 백엔드 개발이었는데, 이번 기회를 통해 그 방향성에 대해 이렇게 어느 정도 감을 잡을 수 있게 된 것 같습니다…! 이 경험을 교훈 삼아 앞으로도 제가 선택한 방법의 이유를 논리적으로 설명할 수 있는 개발자가 될 수 있도록 노력할 생각입니다.

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

(아현) 첫 프로젝트를 하면서 느꼈던 세 가지가 있는데요. 1. 할 수 있는 일은 미리미리 하자!!! - 당연한 말인 만큼 중요합니다! 일이 없어도, 데브가 다가오면 일이 쏟아져나오는데요, 그런 상황에서 프로젝트마저 급하게 움직여야한다면 정말 멘탈이 많이 흔들릴듯 합니다!

1. 할까..말까.. 할땐 합시다!!! - 저희 팀같은 경우, 데브 전날에 추가할 수 있었던 기능이 있었는데, 할까 말까 하다가 안하게 됐던 일이 있었습니다. 나중에 팀끼리 만나서 이야기를 했을 때 ‘그 기능 넣을껄..’ 하고 후회가 남았던 경험이 있었습니다.

2. 부스를 운영할거라면 철저하게 준비하자 - 첫 프로젝트, 첫 부스운영이었는데요. 발표와 부스 둘 다 해야하는 상황에서 발표를 중심적으로 데브를 준비했던 거 같아요. 부스는 데브 이틀 전 부터 준비 했는데, 부스 운영 방침, 부스 설명 등, 부스를 방문하는 사람들에게 우리의 프로젝트를 어떻게 이야기 할지를 크게 고려하지 못했던 거 같아요. 부스 운영하다가보면, 예상치못한 질문이나, 예상치못한 서버의 문제가 80퍼센트 확률로 생길텐데요, 그런 상황에서 부스 운영 방침이 없다면 첫 부스에서 많이 헤매지 않을까 싶습니다!

Q. 기획자로서 프로젝트 초기에 어떤 역할을 수행하였고, 프로젝트 진행 중에 어떤 어려움을 겪었나요?

(지우) 기획자로서 프로젝트에 참여한 것은 이번이 처음이었기 때문에, 초반에는 협업과 소통 능력을 키우는 것을 개인적인 목표로 삼고 프로젝트에 임했습니다. 다만 기획자가 어떤 역할을 수행해야 하는지에 대한 이해가 부족해, 초기에는 기획자의 역할을 단순히 아이디어를 제안하는 것으로 생각하고 있었습니다.

프로젝트 초반에는 주로 아이디어를 제시하는 데에 집중했으나, 이를 구체적인 기획 산출물로 정리하고 프로젝트 전반을 관리하는 역할에는 어려움을 느꼈습니다. 이후 멘토님과 팀원들의 도움을 받으며 기획 과정에서 활용할 수 있는 다양한 도구를 배우게 되었고, 그중에서도 기능 명세서는 팀원 간 소통과 협업에 있어 중요한 역할을 한다는 점을 깨닫게 되었습니다.

기능 명세서를 작성하며 서비스의 기능과 흐름을 명확히 정리하는 과정에서 협업이 한층 수월해졌고, 이를 통해 기획자는 아이디어를 제안하는 역할을 넘어 프로젝트의 방향을 정리하고 일정과 작업 흐름을 관리하며, 다양한 문서를 통해 팀 전체가 원활하게 움직일 수 있도록 돕는 역할이라는 점을 이해하게 되었습니다.

다만 프로젝트 전반을 관리하고 조율하는 과정에서는 여전히 부족함을 느꼈으며, 이러한 경험을 바탕으로 다음 프로젝트에서는 기획자로서 프로젝트 관리 역량과 조율 능력을 더욱 강화하고 싶다는 목표를 갖게 되었습니다.

Q. Winter Dev 프로젝트에서 개발자로 참여한 경험을 설명해 주세요. 어떤 역할을 맡았고, 주요 기술 스택은 어떻게 구성되었나요?

Homis 팀의 주요 기술 스택은 다음과 같습니다.
- FE
  - React
  - PWA
  - JavaScript
  - CSS

- BE
  - Spring Boot (Java)
  - MySQL (Azure RDS) + JPA(Hibernate) + JDBC
  - Azure Blob Storage
  - GitHub Actions + Azure App Service

(선주) 저는 이번 프로젝트에서 백엔드 개발자로 참여하여 프로젝트 초기 구성부터 RESTful API 설계 및 구현, 그리고 배포 환경 구성까지 전반적인 백엔드 개발을 담당하였습니다. 그중에서 특히 기억에 남았던 파일 처리 관련 구현 경험에 대해 설명해보려 합니다.

위에 기술한 대로 파일을 업로드하고 관리할 때 Azure Blob Storage를 통하도록 구조를 짰는데요, 그 처리 방식을 파일 출처와 사용 목적에 따라 분리했습니다. 사용자가 업로드하려는 파일의 경우(외부 출처), 그 용량이나 개수를 사전에 예측하기 어렵기 때문에 이를 byte 배열로 처리하면 JVM 메모리에 그대로 올라가 메모리 부담이 커질 수 있다고 판단했습니다. 따라서 이 경우에는 stream 기반으로 처리해 서버 메모리 사용을 최소화하는 방식을 선택했습니다. 반면 내부에서 생성되는 파일은 서버에서 생성 시점과 개수를 제어할 수 있었고, 실제 사용되는 용량 또한 매우 작다는 점을 확인했습니다. 이런 경우에는 byte 배열로 바로 처리하는 것이 구조적으로 더 단순하고 명확하다고 판단해 해당 방식으로 진행했습니다. 이런 과정으로 도안 판매 등록과 도안 제작이라는 유스케이스 단위로 파일 처리 방식이 분리되었고, 각 유스케이스에 맞게 파일 처리 관련 메소드와 에러 처리를 별도로 구성할 수 있었습니다. 그 결과 기능별 책임이 명확해졌으며, 가독성과 유지보수성 또한 챙길 수 있게 되어서 특히 기억에 남습니다.

또한 내부 파일 처리 중 하나로, 사용자가 제작한 도안 정보를 담은 PDF 파일을 생성하는 로직을 구현한 것도 기억에 남습니다. Apache PDFBox를 이용해 구현했는데, 줄바꿈 처리나 문장 폭 제어, 페이지 오버플로우 관리 등 기본적인 요소까지 직접 구현해 제어해야 했어서 어려운 점이 많았지만 파일 생성 로직의 내부 동작을 구현 관점에서 깊게 이해해볼 수 있어 좋았습니다. 특히 평소 Notion과 같은 서비스에서 제공하는 PDF 내보내기 기능이 내부적으로 어떻게 동작하는지 궁금했었는데, 유사한 기능을 직접 구현해보며 그 구조를 이해할 수 있었다는 점에서 굉장히 의미 있는 경험이었습니다!

Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

(준희) 프로젝트 초반에는 제공된 시안을 기반으로 각 페이지의 구현을 우선적인 목표로 삼아 개발을 진행했습니다. 하지만, 개별 페이지 단위의 작업에만 몰입하다 보니, 페이지 간의 유기적인 관계나 서비스 전체의 데이터 흐름을 충분히 고려하지 못한 채 개발이 진행되었습니다.

그 결과, 컴포넌트 간의 책임이 명확하지 않은 채로 로직이 점차 비대해졌고, 여러 페이지에서 공통으로 사용되는 상태를 필요에 따라 반복적으로 상위 컴포넌트로 끌어올려야 하는 상황이 빈번하게 발생했습니다. 새로운 페이지를 추가할 때마다 기존에 정의된 상태를 어떻게 가져와야 할지 고민해야 했고, 대부분의 경우 상태를 상위 컴포넌트로 끌어올려 하위 컴포넌트에 공유하는 방식으로 구조를 수정하게 되었습니다. 이러한 반복적인 구조 수정은 단순히 기능을 구현하는 것보다 상태의 위치를 조정하고 의존 관계를 정리하는 데에 더 많은 고민을 필요로 하였으며, 이는 개발 생산성을 저해함은 물론, 구조를 수정하는 데에 상당한 시간적 비용을 요구하였습니다.

이 문제를 해결하기 위해 하나의 페이지 구현에만 집중하기보다, 해당 페이지가 어떤 페이지들과 연관되는지, 어떤 상태를 공유하게 될지를 사전에 고민한 후 전체 구조를 대략적으로 설계한 이후에 개발을 진행하는 방식으로 접근을 바꾸었습니다. 그 결과, 여전히 상태를 상위로 올려야 하는 상황은 존재했지만, 아무런 계획 없이 개발을 진행했을 때에 비해 구조 수정이 발생하는 빈도를 줄일 수 있었습니다.

이 경험을 통해 초기 설계 단계에서의 명확한 구조 정의가 프로젝트 생산성을 좌우한다는 점을 깨달았습니다. 과거에는 UML 다이어그램을 단순한 이론이나 형식적인 절차로만 여겨 그 실효성에 의문을 가졌으나, 직접 구조적 문제에 부딪히며 다이어그램 설계에 대한 관점을 단순한 문서화가 아닌 ‘효율적인 구현을 위한 필수 단계’로 재정립할 수 있었습니다. 더 나아가, 프로젝트 규모가 커지고 복잡해질수록, 설계에 투자하는 시간이 향후 발생할 구조적 결함을 수정하는 재작업 비용을 획기적으로 낮춰주는 가장 비용 효율적인 방향임을 이해하게 되었습니다. 이후 프로젝트에서는 개발에 앞서 시스템의 구성 요소와 데이터 흐름을 먼저 정리한 뒤, 해당 설계를 기준으로 구현을 진행하는 습관을 가지도록 노력할 계획입니다.

Q. 디자이너로서 팀에 참여한 경험을 설명해 주세요.

(아현) 이번 데브가 저의 첫 협업 프로젝트였는데, 처음이라 많이 떨리고 어떻게 해야 할지 걱정도 많았는데, 에코노 멘토분들과 팀원분들이 많이 도와주신 덕분에 무사히 잘 마칠 수 있었던 것 같습니다.

기억에 남는 작업은 ppt표지로 쓰였던 에프터 이펙트 작업인데요. 전부터 해보고싶던 애니메이션 작업이었는데 뜨개도아에서 하면 좋을 거 같아 시도해보았습니다! 유튜브에서 강좌를 보면서 차근차근 만들었는데, 다 만들고나서 되게 뿌듯하더라고요 ㅎㅅㅎ! 완성물도 나쁘지 않아 앞으로 더 갈고닦고 싶습니다.

지금까지 도안 제작부터 판매, 구매까지, 우리가 좋아하는 뜨개질을 돕는 “뜨개도아”를 제작한 HOMIS팀이었습니다! 앞으로도 사용자에게 실질적인 도움을 주는 서비스를 만들어 나가길 기대하겠습니다!