[나만무] 10기 4조 팀장의 후기

** 개인의 의견이 다수 포함되어 있음 **

** 프로젝트에 대한 포스팅은 나중에 진행 **

 

핀토스가 어떻게 끝났는지 복기할 여유도 없이 바로 나만무 프로젝트가 시작되었다.

 

 

나만무를 진행하며 몇가지 키워드에 대해 기록해둔다.

 

팀원

나만무가 시작되기 전부터 팀장에 지원할 생각이었어서, 핀토스 3주차(VM)부터 계속해서 팀원을 찾아다녔다.

0주차 미니프로젝트부터 마음이 잘 맞는 친구 하나와 무조건 같이 하기로 했어서, 3명의 팀원을 구하기 위해 

영업을 뛰었다.

(팀 선정 방식은 운에 맡길 수밖에 없는 구조이지만, 그 확률을 최대한 높이기 위해서였다)

 

팀원을 최대한 운에 맡기지 않기 위해 노력했는데 그 이유는 다음과 같다.

 

1. 좋은 결과물(당당하게 1등이라 말할 수 있는)을 내기 위해서

2. 오롯이 개발에 집중할 수 있는 환경을 만들기 위해, 정확히는 감정을 배제한 토론이 가능해야 해서

3. 이 때가 아니면 정말 팀플해보고 싶은 사람과 프로젝트를 진행할 기회가 없을 것 같아서

 

 

개인적인 목표는 1번이었지만, 나만무를 겪으며 가장 크게 와닿았던 것은 2번이다.

 

어차피 친한 사람들과 팀플을 해도 갈등이 생길 수 밖에 없다.

다만 그 갈등을, 완성될 서비스를 위해 의견을 하나로 모으는 과정이라 생각하는 사람들과 함께하기를 바랬다.

 

아마 나중에 더 자세히 포스팅을 하겠지만, 우리 도메인에 대해 제대로 아는 사람이 아무도 없었고,

따라서 싱크를 맞추기 위해 많은 시간을 투자해야 했다.

 

그 과정에서 정말 많은 토론이 있었고 의견 갈등이 자주 발생했지만 감정 싸움으로 번지는 일이 없었다.

팀원들에게 정말 고마운 부분이다. 다들 고집은 정말 강했지만 서비스를 위한 의견 제시 이상으로 감정을 표출하는 일은 없었다.

 

코드 구현과 발표 준비를 하면서도 물론 의견은 달랐지만 오히려 서비스 기획할 때보다 의견 모으기는 수월했다.

 

기획

다시는 모르는 도메인에 함부로 뛰어들지 않으리

 

아마 코치님도 힘드셨을거다. (실제로 10기가 역대급으로 힘들었다 하심)

우리는 정말 거의 2주동안 진행된 게 많이 없었다.

딱 웹 에디터 형식(워크플로우)에 노드를 MVP 수준으로 구현해서(그것도 유연한 설계가 아닌 강한 결합도로) 발표만 겨우 끝마친 정도?

 

유저층을 정할 때도 비개발자를 타겟으로 할지 개발자를 타겟으로 할지

최종적으로 제공하는 서비스가 무엇이 되어야 할지

이게 정말 타겟 유저들이 쓸만한 기능인지

기존 서비스와의 차별점이 무엇인지

구현이 가능할지

 

너무나 많은 고민거리에 결정을 내리지 못하고 심지어 멘토님께도 "그래서 여러분들이 만들고 싶은게 뭐에요?"

라는 피드백을 가장 많이 들었다.

 

다행히 팀원들이 "난 모르겠다~" 하고 도망가지 않았다. 다들 끝까지 의견을 제시해주고 치열하게 고민을 해주었다.

 

"개발자라면 이렇게 쉽게 에이전트를 만들 수 있다면 좋아할 것이고, 이러한 기능이 있으면 진짜 좋을 듯"

 

그러다 보니 언젠가 코치님의 피드백이 와닿았고, 그 뒤부터는 정말 시간과의 싸움이었다.

진짜 시간이 1주만 더 있었으면 RAG에 DB 연동이든 도커 이미지 배포든 멀티모달 지원이든 더 할 수 있었다....

그게 너무 아쉽다 ㅠㅠ

 

 

일정관리

이 부분도 정말... 쉽지 않았다.

우선은 아까 말한 도메인 지식 부족으로 인해, 어느 기능을 어느 기간동안 개발할지에 대한 감이 도저히 잡히지 않았다.

따라서 구현 시 밤샘은 기본이고, 이로 인해 일정 관리는 꼬여만 갔다.

 

내가 할 수 있는 일은 최대한 코드 구조를 파악한 뒤, 각 팀원의 구현 역량을 어림짐작하여 충돌하지 않는 디렉토리에서 구현하도록

업무를 주는 것밖에 없었다.

 

5명이 교육장에 같이 있는 시간이 그리 길지 않아 가장 중요한 안건에 대한 회의만 우선 진행하고,

나머지 시간에는 팀원들의 진행상황을 파악한 뒤 시간이 비는 팀원에게 UI 개선이나 발표 시나리오, QA 등을 맡겼다.

필요한 작업이 끝날 때까지 어느 정도 시간을 벌었다(?)고 생각해야 하나... 

 

각자 최대한 병렬적으로 작업할 수 있게 하려고 정말 오만가지 수단을 사용했던 것 같다.

모든 일을 그렇게 진행할 수는 없었지만 나름 발버둥친 노력으로 프로젝트 진행속도를 올릴 수 있었다.

 

'팀장이 모든 일정을 관리해야 한다' 라는 생각이 어찌보면 당연할 수도, 어찌보면 틀에 박힌 생각일 수도 있었다.

이상적인 것은 정말 진행상황 공유가 잘 되어있고 다른 조건도 잘 맞춰져서, 내가 없어도 다른 팀원끼리 진행하고 

후에 공유해주는 것인데, 사실 이는 풀스택+인프라 구조까지 다 아는 5명이 아니기 때문에 불가능했다.

 

결국 백엔드+인프라를 담당한 나는 프론트엔드와의 API 명세, 피드백을 반영한 기능 추가 및 수정, 인프라 확장(트래픽 증가 대비)에

일정관리와 발표 준비로 한 달 내내 수면 부족에 시달렸다... 물론 다른 팀원도 힘들었겠지..

 

어찌보면 나만무 진행 중에 가장 힘들면서, 스스로가 부족하다 느꼈던 역량이었다.

도메인 지식은 기본이고, 프론트엔드도 잘 알고 있어야 조금 더 효율적인 작업 분배가 가능하지 않았을까 싶다 ㅎㅎ

(PM의 길은 멀고도 험하구나...)

 

구현

당연히 AI를 사용했다. 코드를 많이 짜지 않았다. "돌아가는 완성품"을 만드는 것이 우선이었고, 확장 가능한 구조로 설계하는 것 이외에는 

기능에 수정이 필요하더라도 그리 시간이 오래 걸리지 않았다. 이건 그냥 개인의 역량에 따라 달라지는 것 같다. 

 

다만 AI에게 무조건 맡기는 것이 아닌 구체적인 전략이 필요했다. 우리 팀의 경우는 codex, claude code의 superclaude와 use seq MCP를 사용하여 아래의 절차에 따라 구현을 맡겼다.

 

명확한 요구사항(직접 작성 + AI) -> 이를 구현하기 위한 구현 계획서 제작(plan mode) -> codex로 검증 및 예상되는 문제에 대한 의문 제시 -> 피드백을 바탕으로 구현 계획서 수정 -> codex로 검증 완료 -> Phase별 상세 구현 명세서(API 명세등) -> 구현 시작

 

AI 활용에 대한 자세한 내용은 다른 포스팅에서 다루겠다.

우리 팀은 스택을 공부하는 실력 다지기 기간에, React에 대한 기초와 AI 활용에 대한 내용을 많이 공부했고, 도움이 많이 되었다.

 

 

갈등과 해소 (시나리오 및 발표 직전)

결국 기능은 잘 나왔는데, 한 두명의 팀원은 조금 더 욕심을 내고 싶은 모양이었다.

노코드 워크플로우와 배포기능을 잘 만들었는데 데모가 너무 임팩트가 없다라는 의견이 있었다.

 

이때가 아마 발표 4,5일전이었을 것이고, 포스터 세션 제작, 발표 대본 작성 및 연습, 최종 점검 등 해야할 것이 너무나 많았다. 

Restful 배포 방식의 시나리오를 바꿔야 한다는 주장이 있었고, 나도 어느정도 동의하고 있었다.

 

다만 보통 발표주간에는 기능 개발보다는 마지막 테스트 정도만 하고 코드를 건드리지 않기 때문에 반대하는 팀원도 있었다.

게다가 구현을 할 노드가 꽤 복잡했다. Http 요청 및 템플릿 변환 노드를 구현해야 했는데 포스터를 준비해야하는 마당에

한 명이 맡아서 구현하기란 쉽지는 않아보였다.

 

사실 이때 가장 서로가 날카로웠고, 팀의 화합이 어그러질 수도 있었던 것 같다.

 

둘 다 일리가 있는 말이라 결정을 내리기 어려웠지만 작업 분배를 잘하면 해볼만하다라는 생각에,

각자가 할 수 있는 일을 주고, 추가 기능 구현을 하려는 팀원에게 딱 하루의 시간을 주었다.

 

동시에 나는 구현이 되지 않을 경우를 대비해, 현재 조건에서 가장 와닿을 만한 시나리오를 만들고 대본을 작성하기로 했다.

일종의 보험을 들어놨다라고 할 수 있을 것 같다.

 

내 의견을 두 팀원 모두 수용해주었고, 결과적으로 만족할 만한 기능을 완성하여 최종 발표에 반영할 수 있었다.

팀원의 구현 역량을 믿고 있었고, 그 동안 확장이 가능하도록 설계를 나름 잘해둔 덕도 있었던 것 같다.

 

마지막으로 무한 발표 연습을 통해 7분이라는 엄격한 시간 제한안에 우리가 담고 싶었던 내용을 다 담을 수 있었고, 무사히 발표를 마쳤다.

 

 

회고

정말 끝까지 힘들었던 프로젝트. 최선을 다했기에 높은 벽을 느낄 수 밖에 없던 경험이었다. 

다만 실제 팀장 경력이 아닌 같은 동기로서 팀장을 맡았다는 쉴드를 받으면, 그래도 제법 잘하지 않았나 생각이 들었다.

(뒷풀이에서 서로가 서로를 많이 믿어준 것에 대한 고마움을 나눴다)

 

PL의 역량은 정말, 협업에서 너무 중요하다...

 

 

 

 

 

팀장이 아닌 팀의 의사결정 과정은 다음에 포스팅할 예정!