2년전 나에게 - 첫 프로젝트 무서워 하지마.

박민기·2025년 7월 2일

2년전 나에게

목록 보기

1/6

A. 배경

이 글은 첫 팀 프로젝트를 시작하는 분들을 위해 준비했습니다. 저 역시 처음에는 어디서부터 손을 대야 할지 몰라 많이 헤맸던 기억이 있습니다. 그래서 저처럼 막막함을 느끼는 분들이 조금이나마 쉽게 다가갈 수 있도록 읽는 사람이 가장 이해하기 쉽게 쓰려고 합니다.

저는 앞으로 첫 프로젝트를 준비하는 분들에게 도움이 될 만한 내용을 시리즈로 작성할 예정입니다. 이번 글에서는 첫 프로젝트를 할 때 꼭 알려주고 싶은, 제가 많이 사용한 프로젝트 진행 프로세스를 소개하려고 합니다.

글을 쓰면서 저도 다시 한 번 프로젝트 과정을 정리해 보고, 여러분께 도움이 되는 경험을 나누고 싶어요. 혹시 읽으시다가 궁금한 점이나 본인만의 팁이 있다면, 댓글로 자유롭게 남겨 주시면 서로에게 큰 도움이 될 거예요.

B. 설계의 중요성

프로젝트를 처음 하는 분이 보통 생각하시는 게 기획과 설계를 후다닥 하고 개발 기간을 길게 잡자라는 분들을 많이 보았던 것 같습니다. 하지만 이렇게 하면 설계와 기획의 부재로 개발 기간이 더욱 길어져 마감 기한을 잘못 잡을 수 있습니다. 기획과 설계가 탄탄할수록 구현 기간이 짧아지고, 오히려 모두가 한 곳을 바라보게 되어 좀 더 양질의 프로젝트가 나오는 것 같다고 생각합니다.

위에 사진 처럼 구현,구축 단계는 많은 프로세스 중 일부에 해당합니다. 예전에 피드백을 해주신 CSO(최고전략책임자)분 께서는 기획과 설계를 통해서 모두가 한 곳을 바라 볼 수 있게 하는 게 중요하다고 하셨고, 저 또한 모두가 같은 생각을 할 때 프로젝트의 개발 및 수정상황에서도 빠르게 이해하고 이행할 수 있는 팀합이 나오게 되는 것 같았습니다.

🧭 설계는 항해를 할때 나침반의 역할을 해준다고 생각합니다.
나침반 없이 항해하는 배가 목적지에 잘 도착 할 수 있을까요?

C. 프로젝트 설계 (나만의 방법)

프로젝트를 진행할 때 저는 아래와 같은 순서로 설계를 진행합니다.

아이디어 선정
기능 명세 ( 프로젝트 구체화 )
디자인 ( 와이어프레임 )
피드백 ( 와이어프레임 기반 피드백 )
데이터베이스 설계, API 설계
피드백 ( 프론트-백엔드 협업 조율 )
구현

가장 중요하다고 생각하는 피드백 단계를 위해 위와 같은 프로세스로 프로젝트를 진행합니다.
아래에서 각 단계에서 어떤 일을 하고, 어떤 부분을 중요시하는지 소개해 드리겠습니다.

1. 아이디어 선정

저는 프로젝트 아이디어를 정할 때 흥미롭고 재미있어 보이는 주제를 선호합니다. 세미나, Meet-up과 같은 강연을 듣거나 최신 기술 트렌드에서 영감을 얻는 경우가 많아요.
하지만 대부분의 팀원들은 처음엔 ‘뭘 해야 할지 모르겠다’ 는 막막함을 느끼는 경우가 많습니다. 흔히들 “이게 정말 괜찮은 아이디어일까?”, “너무 평범하지 않을까?” 라는 고민을 하게 되죠.
그래서 중요한 것이 브레인스토밍 입니다. 보통은 각자 생각나는 아이디어를 자유롭게 공유한 뒤, 여러 의견을 합쳐보거나, 서로의 경험을 바탕으로 현실적인 주제를 선택하는 것이 모두가 만족하는 프로젝트의 주제가 될 수 있습니다.

💡 저 역시 처음엔 ‘특별한 아이디어’ 에 집착하다가 의견을 내지 못했지만, 일단 던져보고 브레인 스토밍을 하며 함께 이야기를 하니 더 좋은 아이디어가 되는 걸 경험했습니다.

2. MVP 선정

아이디어가 정해지면, 저는 기능을 리스트로 쭉 적어보고 우선순위를 정하는 방식으로 진행합니다. 핵심 기능(MVP)만 남기고, 부수적인 기능은 과감히 빼는 편이에요.
대부분 처음 팀 프로젝트를 하는 분들은 ‘이것도 넣고 싶고, 저것도 해보고 싶다’ 며 기능을 많이 넣으려는 경향이 있습니다. 하지만 이렇게 하면 실제 구현 단계에서 부담이 커지고, 일정에 쫓기게 됩니다.
그래서 많은 분들이 “처음엔 욕심을 많이 냈다가, 결국 핵심만 남기고 나머지는 포기했다” 는 경험을 공유하곤 합니다.

또한 이 과정에서 중요한 것은 "이 기능을 구현할 수 있을까?" 입니다. 저는 MVP를 선정하는 과정에서 사용할 것 같은 기술이나 기능들의 레퍼런스 를 찾아보면서 예상 시간과 현실 가능성을 찾아 보는 편입니다. 이것의 결과를 MVP선정과 프로젝트의 볼륨을 정하는 편입니다.

저 역시 첫 프로젝트 때는 많은 기능 욕심에 부리다가, 첫 프로젝트를 완성하지 못한 경험이 있습니다. 지금은 꼭 필요한 기능부터 차근차근 구현하는 게 가장 효율적이라는 걸 깨달았습니다.

3. 디자인 ( 와이어프레임 )

전공 첫 팀 프로젝트에서는 기획자라는 역할이 명확하지 않아 요구사항 명세가 부족해질 수밖에 없다고 생각합니다. 이런 상황에서 저는 와이어프레임 작업의 중요성을 강조합니다.

와이어프레임은 팀 프로젝트의 요구사항을 시각적으로 표현하는 첫 단계입니다. 프로젝트가 실제로 어떻게 동작할지, 어떤 흐름으로 진행되는지 모든 팀원이 한눈에 이해할 수 있도록 도와줍니다.

또한, 프로젝트는 결국 디자인된 UI 위에서 모든 기능이 구현되고 동작하기 때문에, 백엔드 개발자도 와이어프레임을 꼼꼼히 살펴봐야 한다고 생각합니다. 와이어프레임을 통해 프로젝트의 시나리오와 전체적인 흐름을 파악하면, 프론트엔드와의 소통도 훨씬 원활해지고, 실제 연동 과정에서 발생할 수 있는 이슈도 빠르게 발견하고 해결할 수 있습니다.

아직 현업 경험은 없지만, 지금까지의 경험상 프로젝트에 대한 이해도와 관심이 높을수록 디버깅도 훨씬 수월하게 느껴졌습니다. 그래서 저는 와이어프레임 작업이 단순히 디자인을 위한 단계가 아니라, 모든 팀원이 프로젝트를 깊이 이해하고 협업의 기반을 다지는 핵심 과정이라고 생각합니다.

4. 피드백

와이어프레임 기반 피드백

기능 명세가 어느 정도 정리된 후에는, 프로젝트의 기능적 구조만을 담은 와이어프레임을 작성합니다. 이 과정에서 모든 팀원이 각 기능이 어떻게 동작하는지 시각적으로 확인할 수 있습니다.

💡 와이어프레임을 통해 각자의 생각을 한 번 더 맞춰보고, 구체적인 요구사항을 명확히 할 수 있습니다.
특히 첫 프로젝트에서는 세세한 요구사항을 문서로만 정리하기 어렵기 때문에, 시각적인 자료가 큰 도움이 됩니다.

5. 데이터베이스 설계, API 명세서

데이터베이스 설계

먼저 ERD는 데이터베이스의 테이블 구조와 관계를 시각적으로 정의하는 도구입니다. 저는 프로젝트 요구사항이나 디자인을 참고해 필요한 데이터를 정리하고, 어떤 API에서 어떤 테이블이 사용될지 고민합니다.

이후 테이블을 정규화하여 데이터베이스를 설계합니다[4].
ERD 설계 과정에서는 데이터베이스에 대한 기본 지식이 필요하며, 설계 초기 단계에서 충분히 논의하고 검토하는 것이 중요합니다.
왜냐하면 잘못 설계된 데이터베이스는 성능 저하, 데이터 중복, 무결성 문제 등 다양한 문제를 초래할 수 있기 때문입니다.
이번 블로그에서는 프로젝트 순서 중 ERD 설계가 왜 필요한지, 어떤 역할을 하는지 인지하시면 좋겠습니다.

데이터베이스 설계 과정에서 API의 초안을 머릿속으로 생각하거나 적어 보면서, API 명세서를 작성할 때 참고하는 편입니다.

API 명세서 작성

프론트와 백엔드는 따로 작성한다고 생각하시겠지만, 결국 이 둘은 소통을 해야 하며, 이때의 약속과 협력 과정이 API 명세서 작성 단계라고 생각합니다. 저의 경우, 프론트가 디자인을 기반으로 퍼블리싱 작업을 시작하면, 제가 ERD, MVP, 디자인을 참고해 필요한 API 명세서를 작성한 뒤, 프론트와 피드백을 주고받으며 수정할 부분을 확인합니다.

API 명세서에는 프론트와 백엔드가 통신할 때 필요한 HTTP Method, URL, JSON 요청/응답 형식, 진행 상황, 담당자 등을 기록해 누가 어떤 부분을 수정하고 진행하는지 확인할 수 있습니다.

저는 처음 프로젝트에서 API 명세서를 작성해야 한다고 했을 때, 어떻게 작성해야 하는지 몰라 우왕좌왕했던 기억이 있습니다. 이 글을 보시고 노션 API 명세서 템플릿이 필요하시다면 댓글로 남겨 주세요.

저의 경우, 노션을 통해 API 명세서를 작성하는 것이 어느 한쪽에 치우치지 않고 중간에서 문서 관리가 잘 이루어지는 것 같아 이 방법을 선호합니다. 하지만 이 방법 이외에도 Swagger나 다른 툴을 사용해서 API 명세서를 작성할 수 있습니다.

6. 피드백

프론트-백엔드 협업 조율

데이터베이스와 API 설계가 끝난 뒤에는 프론트엔드 개발자와 함께 개발 방향을 다시 한 번 조율합니다. 서로의 이해관계를 확인하고, 실제 구현에서 발생할 수 있는 이슈를 미리 점검합니다.

💡 만약 프론트엔드에 프로젝트 경험이 적은 분이 있다면, 저는 백엔드에서 부담을 더 가져가고 프론트엔드가 더 편하게 개발할 수 있도록 역할을 조정합니다. 팀원의 역량과 상황에 따라 업무를 유연하게 분배하는 것이 프로젝트의 완성도를 높인다고 생각합니다.

이런 과정을 통해 프로젝트를 진행하면 팀원 모두가 같은 목표를 향해 나아갈 수 있고, 예상치 못한 문제도 미리 발견하여 효율적으로 대응할 수 있습니다.

D. 마무리

프로젝트를 처음 시작할 때 느끼는 막막함과 두려움은 누구나 겪는 자연스러운 과정입니다. 저 역시 첫 팀 프로젝트를 준비하며 많은 시행착오를 겪었고, 그 경험을 바탕으로 이번 글을 정리하게 되었습니다.

프로젝트 설계와 피드백, 그리고 팀원 간의 소통이 얼마나 중요한지 다시 한 번 느끼게 되었고, 이 과정을 통해 모두가 같은 목표를 향해 나아갈 때 훨씬 더 완성도 높은 결과물을 만들 수 있다는 것을 알게 되었습니다.

여러분도 이 글에서 소개한 단계들을 차근차근 따라가며, ‘나도 할 수 있다’ 는 자신감을 꼭 가져가셨으면 합니다. 완벽한 계획이나 특별한 아이디어가 아니어도 괜찮아요. 중요한 것은 팀원들과 함께 고민하고, 피드백을 주고받으며 조금씩 나아가는 과정 그 자체입니다.

혹시 프로젝트를 진행하면서 궁금한 점이나 공유하고 싶은 팁이 있다면, 댓글로 자유롭게 남겨주세요. 서로의 경험을 나누며 함께 성장하는 즐거움을 느끼셨으면 좋겠습니다.
여러분의 첫 팀 프로젝트가 좋은 추억과 값진 경험이 되길 진심으로 응원합니다!
읽는 분들이 '나도 할 수 있겠다'는 자신감을 얻어가셨으면 좋겠습니다!

"혼자가면 빨리갈 수 있지만, 함께 가면 더 멀리 갈 수있다." 라는 말 처럼 프로젝트라는 것도 함께 완성이라는 먼 과정을 가야하는 것이라고 생각합니다. 이 글을 있는 분들의 첫 프로젝트가 완성이라는 개발의 시작이라는 출발점에 도착하길 빌겠습니다.
다음 글은 ERD 설계의 기본개념 라는 글로 뵙겠습니다.