좋은 프로젝트란 무엇인가? - 기획편

취준을 하면서, 이번에는 욕심을 내서 여러 프로젝트에 참여하게 되었다.

 

특히 프로젝트 2개는 초기 단계 멤버로 시작하여 기획이나 UI/UX 쪽도 건드려볼 기회가 생겼는데,

평소에 내가 하던 업무와 달라서 기대가 되기도 하고, 알아야 할 것도 많을 것 같아서 이참에 정리를 해보려고 한다.

또한 앞으로 계속 AI 프로덕트 개발에 참여하려면 기획적인 측면도 잘 고려해야 훌륭한 개발자로 성장할 수 있을 것이라 생각한다.

 

이쪽은 전문적으로 공부한 분야는 아니기에, 웹 서치 + 프로젝트 진행할 때 PM 분들과 협업하며 배운 것들을 위주로 서술해보려고 한다.

---

 

좋은 프로젝트가 나오기 위해서

맨 처음 프로젝트를 시작할 때에는 우선 기획을 잡고, 프로젝트 전체의 진행 계획을 수립하는 것이 중요할 것이다.

일반적인 개발 프로젝트가 어떤 방식으로 이뤄지는지 알아보기 위해서, 기본적인 개념부터 짚고 넘어가겠다.

 

 

소프트웨어 개발 주기 (SDLC)

SDLC는 Software Development Life Cycle의 약자로, 소프트웨어가 계획에서부터 배포 및 유지보수에 이르기까지의 전 과정을 체계적으로 정의한 모델이다.

과정의 세부사항은 팀에서 어떻게 정의하느냐에 따라 다르겠지만, 보통 다음과 같이 구성된다.

• 계획
  • 고객의 문제를 정의하고 요구사항을 문서화
  • 필요한 작업과 리소스를 정리
  • 작업의 우선순위를 명시
• 설계 (디자인)
  • 요구사항을 충족할 수 있는 제품을 설계
• 구현
  • 설계한 내용에 따라 제품 구현
• 테스트
  • 배포 이전 버그, 오류를 찾아 수정
• 배포
• 유지 관리

 

그리고 이걸 구현하는 방식에는 다양한 모델이 있는데, 그 중 대표적인 워터폴과 애자일 위주로 알아보겠다.

 

Waterfall VS Agile

워터폴 방법론은 순차적인 진행이 중요시되는 방식이다.

출처 : 코드스테이츠 (https://www.codestates.com/)

 

우리가 흔하게 생각하는 순차적 접근 방식을 체계화해놓은 느낌이다.

각 단계가 끝나고 다음 단계로 넘어가다보니 현재 상황에 대한 추적이 쉽지만, 변경이 어렵고 결과물을 확인하기까지의 속도가 느리다는 단점이 존재한다.

 

다음으로 애자일 방법론이다.

출처 : 코드스테이츠 (https://www.codestates.com/)

 

짧은 사이클(1-4주 단위)로 빠르게 제품 개발 & 피드백 & 테스트를 진행하는데,

앞에서 설명했던 설계, 개발, 테스트를 스프린트 단위로 끊고 빠르게 진행하는 방식이다.

 

고객의 피드백에 따라 대처가 유연한 만큼 B2C 테크기업 (네이버, 카카오 등..) 은 대부분 이 방식을 사용하고 있다.

요즘은 애자일이 대세라고는 하지만, 이것도 상황에 따라 달라서 변동성이 적은 프로젝트의 경우는 오히려 워터폴 방식이 더 편한 경우도 있다고 한다.

 

이외에도 V-모델, 스파이럴 모델 등이 있다고 하는데 자주 쓰이는지는 모르겠다.

 

 

 

실제 개발은 어떨까?

그럼 실제 스타트업들은 개발 계획을 어떻게 세울까? 그리고 어떤 점이 중요할까?

내부 자료이다보니 명확하게 프로세스를 확인할 수는 없었지만 (아마 컨퍼런스 등에서 맛보기로 보여줄것이다) 참고할만한 가이드 자료^{[각주:1] [각주:2]}를 몇 개 찾았다.

 

글 내용을 요약해서 정리하면 다음과 같다.

 

• 개인별로 제품 형상 / 용어에 대한 이해도가 상이하기 때문에, 팀이 지향하는 목표를 일치시켜야 함
  • 그 프로젝트의 목표가 매출 증대인가? 혹은 기존 사업에 대한 비용 절감인가?
• 추상적인 단어 (파이프라인, 데모, 콘텐츠 등) 에 대한 통일된 네이밍 필요
  • 버저닝도 여기에 속한다. 버저닝에 대한 글은 여기^[각주:3] 참고
• output과 마일스톤 결정하기
  • v1을 3월에 출시한다면, 그 전까지 어떤 작업들이 수립되어야 하는지 등
• 동종 업계 사례 조사
  • 너무 유사한 사례가 없는지, 혹은 경쟁력 있는 다른 제품에서 벤치마킹할 요소가 있는지
• 업무별 세부 사항 결정 / 인원 명확화
  • 팀마다 어떤 업무를 담당하고, 인원 배정은 어떻게 할지

 

 

개발 업무 분담

프로젝트 초기에 가장 어려웠던 부분은 업무 세부사항이나 파트가 명확히 나오지 않아서 파트를 분담하기가 어려웠던 것이다.

편의상 크게 분류하여 BE, FE, DE, AI 이런 식으로 나누긴 하지만,

사실 조직마다 맡는 역할의 범위가 다르기도 하고 실제로 겹치는 부분이 상당히 많은 포지션도 있다.

 

이걸 명확하게 하기 위해서 작성하는 것이 태스크 정의서, 내지는 단위업무 정의서이다.

 

블로그^[각주:4]에 좋은 예시가 있어서 가져왔는데, 

다음과 같이 단위업무 ID와 단위업무명을 할당하고, 요구사항 ID와 담당자를 기록하면 업무가 헷갈리는 일 없이 명확해질 것이다.

 

실제 내가 진행하고 있는 프로젝트에서도 PM분이 다음과 같은 단위업무 정의서를 만들어주셨다.

 

단위업무 정의서

현재 내가 진행하고 있는 프로젝트의 단위업무 정의서를 GPT와 함께 작성해보았다.

 

우리 프로젝트의 파트 구성은 다음과 같다.

 

• 백엔드 개발팀: 서비스의 핵심 로직과 아키텍처 설계, 채팅방 관리 및 보안 시스템 담당.
• 프론트엔드 개발팀: 사용자 인터페이스(UI)와 사용자 경험(UX) 관련 기능 개발.
• 데이터 엔지니어팀: 데이터 수집, 전처리 및 파이프라인 설계.
• AI 엔지니어팀: 면접 질문 생성 및 관련 로직 개발.
• 프로젝트 매니저(PM): 일정 관리, 팀 간 커뮤니케이션 및 프로젝트 문서화.

 

 

이에 맞추어서 테이블 형태로 업무 정의서를 작성해보았다.

 

여기에 추가한다면 태스크, 요구사항 ID, 연관 태스크, 태스크 시작 및 종료일 등이 들어갈 수 있겠다.

요구사항 ID 또한 체계를 갖춰서 정하는 것이 좋기 때문에 팀원들과 논의 후 추가적으로 작성할 예정이다.

 

태스크 ID 이외에도 추가적으로 네이밍 룰을 적어야 할 몇 가지를 나열해보자면..

• Git 관련
  • Convention : 커밋 메시지 구조, 커밋 타입 등
  • Template : 이슈, PR, README 등 
    
    • 참고^[각주:5]
  • 깃허브 사용 관련 강의 추천^[각주:6]
• 버저닝 : 이게 무슨 버전인지 숫자를 체계에 따라 정하는 것
  • e.g. v.1.2, v.1.4.7 ... 
  • 참고^{[각주:7] [각주:8]}
• 태스크ID, 화면 ID, 요구사항ID
  • 특히 요구사항ID는 요구사항 정의서 작성할 때 쓰이고, 혼란을 방지해주므로 (e.g. 로그인 기능이라고 하면 이게 소셜 로그인인지, 자체 로그인 기능인지 등등) 꼭 필요하다
  • 참고^[각주:9]

 

 

 

 

 

---

결론

 

이로써 AI 프로덕트의 PM 역할을 살짝 찍먹해보았다.

 

사실 이전까지만 해도 대부분 단발성 개발에 그치거나, 대회 출전 방식으로 진행을 했기 때문에 프로젝트 체계화에 대한 공부가 많이 미흡했던 것 같다.

 

누군가는 "개발자가 개발만 잘하면 되지, 이런 것까지 세부적으로 알아야 하나" 라고 생각할 수 있다.

실제로 과거의 내가 그랬고..

 

하지만 프로젝트는 여러 사람이 모여서 하는 일인만큼, 각자 무슨 일을 하고 있는지 명확히 파악하는 것이 중요하다.

효율적인 측면에서도 그렇고, 커뮤니케이션 측면에서도 서로가 하고 있는 일을 모르면 제대로 된 소통이 일어날 수 없다.

 

더불어 개발자가 개발 전체의 흐름과 방향성을 숙지하는 것은 매우 중요하다.

그 자체가 프로덕트 개발에 대한 동기부여가 되기도 하며, 애초에 무엇을 위해 쓰이는지도 모른 채 개발된 기능이 유저 입장에서 만족스러울리 없다.

 

 

요즘은 GPT도 코딩 잘한다. 

이런 세상에서야말로 커뮤니케이션을 즐기고, 가치 있는 개발을 지향하는 개발자가 되도록 노력해야 할 것이다.

 

 

---

References

1. https://app.dalpha.so/blog/ai-implementation-guide2/ [본문으로]
2. https://www.upstage.ai/blog/ko/product-development-process [본문으로]
3. https://velog.io/@server30sopt/%EB%B2%84%EC%A0%80%EB%8B%9D-%EC%A0%84%EB%9E%B5-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%B4%EC%95%BC-%ED%95%98%EB%82%98 [본문으로]
4. https://hanbyeol93.tistory.com/149 [본문으로]
5. https://yejinlife.tistory.com/entry/GitHub-Issue-%ED%85%9C%ED%94%8C%EB%A6%BF-PR-%ED%85%9C%ED%94%8C%EB%A6%BF-%EB%A7%8C%EB%93%A4%EA%B8%B0 [본문으로]
6. https://www.boostcourse.org/cs103 [본문으로]
7. https://velog.io/@server30sopt/%EB%B2%84%EC%A0%80%EB%8B%9D-%EC%A0%84%EB%9E%B5-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%B4%EC%95%BC-%ED%95%98%EB%82%98 [본문으로]
8. https://devdesigner.tistory.com/21 [본문으로]
9. https://velog.io/@juyeon/%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EC%A0%95%EC%9D%98%EC%84%9C-%EC%9E%91%EC%84%B1%ED%95%98%EB%8A%94-%EB%B2%95 [본문으로]