[ASM·SWM] SW마에스트로 17기 합격 후기! (1년의 준비 과정, 16기 탈락 그 이후)
[ASM·SWM] SW마에스트로 17기 합격 후기! (1년의 준비 과정, 16기 탈락 그 이후)
👋 소개안녕하세요! 대학생 개발자 주이어입니다.오늘은 제가 SW마에스트로 17기에 합격하게 되어 후기를 남겨보려고 합니다!조금 길 수 있지만... 재밌게 읽어주시길 바랍니다!❌ 16기 탈락의
blog.juyear.dev
이전 글 읽으러 가기!
👋 소개
안녕하세요! 대학생 개발자 주이어입니다.
오늘은 SW마에스트로 활동 내용을 정리하게 되었습니다.
지금 보니 합격 글 이후로 별 다른 글을 안적었더라구요...
여러 이유가 있지만, 사실 2~3달 동안
아이디어 회의 -> 고도화 -> 시장 검증 -> 폐기이 루틴을 계속 밟고 있었습니다.
그러다보니 블로그에 적을만한 성과나 경험이 없었습니다.
사실 처음에 정해진 아이디어가 있었지만, 기획 발표 이후에 시장 검증과 비즈니스 모델이 빈약하다고 판단했고 피보팅을 결정하였습니다. 그 이후에 아이디어에 대한 기준이 높아지다 보니 계속해서 정해지지 않았던 것 같습니다.
그러다가 기획 멘토님을 만나게 됐고, 운 좋게 "사업 제안서" 작성 및 대표님 미팅 자리를 얻게 되어 아이디어를 확정하게 되었습니다. 이 부분에 대해서도 다음에 글을 적어볼 생각입니다. (분량이 짧을 것 같아서 일단은 미뤄뒀습니다.)
그래서 오늘 정리할 내용은 테크리더로서 프로젝트 시작 전에 어떤 설계를 했는지, 어떤 과정을 거쳤는지, 개발 중에 어떤 문제가 있었고 어떻게 해결했는지 등을 정리해보려고 합니다.
기술적인 내용 보다는 활동한 것과 느낀 점 위주로 남겨보려고 합니다.
👋 SDD 도입 과정
SDD 도입을 생각하게 된 이유
우선 저는 아이디어가 확정되기 전 부터 SDD를 도입해야 겠다고 생각을 하고 있었습니다.
이렇게 생각한 이유는 3가지 정도가 있었습니다.
- 현재 우리 팀의 속도
- AI 시대에 맞는 개발 방법 적용
- 멘토님의 역량 활용
각각에 대해서 좀 더 자세히 설명해보면, 우선 저희 팀은 속도가 빠른 편이 아니었습니다. 굳이 따지자면 이미 개발을 끝낸 팀도 있던 와중에 저희는 아이디어 회의를 하고 있을 정도였습니다. 물론 완전히 느린 편도 아니었지만, 지금 이 상황에서 저희 팀의 목표와 계획에 맞는 개발 속도를 확보하기 위해서는 체계적으로 AI를 활용하는 개발 방법이 필요하다고 생각했습니다.
두 번째로, 전 아직까지도 GPT, Gemini를 사용한 단순한 질의 응답 형식으로만 AI를 활용해 개발을 하고 있었습니다.
Claude, Orca, Skill, Hook 등을 사용해 개발을 하고 있는 개발자들에 비해서는 현저히 AI와 거리가 멀었습니다. 그래서 저는 이번 SW마에스트로 과정에서 이러한 AI를 활용한 개발 경험을 제대로 한 번 쌓고 싶었습니다.
마지막으로 저희 멘토님의 역량이었습니다. 저희 멘토님은 100% SDD 개발 방법론을 적용한 회사에서 일을 하고 계셨고, 저희 팀이 SDD로 개발을 진행한다면, 멘토님의 도움을 받아 쉽게 적용하고 빠르게 개발할 수 있을 것이라고 생각했습니다.
이러한 3가지의 이유로 SDD 도입을 생각하고 있었고, 이전부터 팀원들에게 SDD에 대해서 어필을 하고 있었습니다.
생각보다 쉽지 않았던 SDD
이전부터 제가 어필을 하고 있었던 탓인지 SDD 도입에 대해서는 팀원들의 갈등없이 모두의 동의로 결정하게 되었습니다.
그 이후 SDD에 대해서 잘 알고 있던 멘토님과 미팅을 잡아 뭐부터 시작해야 하는지, 어떻게 개발해야 하는지 등을 물어보며 SDD에 대한 이해를 키워나갔습니다.
하지만 들으면 들을수록 SDD 개발이 쉽고 빠르기만 한 것은 아니라는 것을 직감적으로 느끼고 있었습니다.
우선 PRD 작성부터 막막했습니다. AI에게 저희 프로젝트에 대한 맥락을 공유하기 위해서는 이 PRD라는 "프로젝트 요구 사항"문서를 작성해야 했는데, 어느 범위까지 얼마나 자세하게 적어야할지 감이 안왔습니다.
제가 느낌적으로 생각했을 때는 PRD에는 프로젝트 전체에 대해 필요한 정보만을 넣고 이후 자세한 사항은 기능명세서에 넣는게 맞는 것 같은데.. 그렇다고 RPD를 자세히 작성하지 않으면 기능명세서가 잘 나오지 않았습니다.
이에 대해서 멘토님과 미팅을 진행했고, SDD는 절대 한 번에 완성되는 것이 아니라는 것을 알려주셨습니다.
PRD를 통해 기능명세서를 생성하고, 제대로 정의되지 않은 것을 수정하여 다시 생성하고 이러한 작업을 무한 반복 하는 것이 가장 정확하게 AI와 맥락을 공유할 수 있는 방법이었습니다.
그래서 일단 저희는 PRD에 들어가야할 목차와 내용을 찾아서 작성했고, 하루 날 잡고 모여 하루종일 PRD를 수정하면서 저희 팀원끼리 맥락을 공유하였습니다.
이후 저희가 먼저 테스트로 만들어볼 기능 3가지를 정했고, 그 기능은 auth(로그인), onboarding(유저 프로필 입력), library(유저 저장 콘텐츠 확인)로 사용자 경험 흐름을 고려하여 정하였습니다.
이 3가지 기능에 대해서 AI에게 기능명세서를 각각 생성해달라고 했고, 역시나 저희가 생각하는 것과 다르게 정의한 것들이 많이 보였습니다.
이에 대해서 팀원들과 수정 사항에 대해서 논의하고, 이를 반영하여 다시 기능명세서를 생성하고, 또 논의하고 또 수정하고...를 하루정도 투자하여 명세 작성에만 거의 이틀을 투자하였습니다.
이렇게 맥락 공유가 완료된 기능명세서를 가지고 개발에 필요한 API명세서와 UIUX명세서를 뽑아달라고 했습니다.
여기서부터는 거의 AI를 믿고 진행했던 것 같습니다.
저희는 프론트엔드 개발자하고 백엔드 개발자가 모여서 대충 이 API가 필요한게 맞는지 정도만 검증하였습니다.
추가로 도메인 모델을 설계하고 성능적 관점, 효율적 관점, 프로젝트적 관점 등을 통해 팀원들과 내용을 공유하고 초기 도메인 모델을 확정지었습니다.
개발에 필요한 문서들이 모두 준비되었기 때문에 테스트 개발을 시작하였습니다.
👋 프로젝트 설계 고민
브랜치 전략 - 혼자 할 때 와는 전혀 다르다.
우선 제가 처음에 제안한 브랜치 전략은 다음과 같았습니다.
저희 팀은 백엔드 1명, 프론트 1명, AI 1명으로 사실상 같은 부분을 수정할 경우는 없었고, 위와 같이 브랜치만 be와 fe로 나누면 문제 없이 진행될 것이라고 생각했습니다. 그리고 dev에 병합하기 전에 integraton 브랜치를 두어 여기서 백엔드와 프론트엔드를 합쳐 실제로 오류 없이 작동이 되는지 테스트 및 검증하도록 설계하였습니다.
이렇게 설계하면, Dev에는 항상 백엔드와 프론트엔드 통합 테스트가 진행된 안정된 상태의 코드만 올라가도록 할 수 있었습니다.
하지만 역시 실제 개발을 진행해보니 문제점이 발생하였습니다.
[기능별 개발 속도 차이를 어떻게 관리할 것인가]
저희가 만난 문제점은 백엔드와 프론트엔드 개발 속도 차이를 어떻게 관리할 것인지 였습니다.
이것이 문제가 된 지점은 아래와 같습니다.
프론트엔드 개발자는 백엔드 기능 개발이 완료될 때 까지 기다려야 하는가?
이 부분은 아무리 생각해도 정답이 없는 문제처럼 보였습니다.
제가 생각했던 전략은 3가지 정도가 있었습니다.
- 완료된 프론트엔드 개발을 Integration에 병합하고, 새로운 기능 제작은 Dev에서 새로운 브랜치를 생성한다.
- 완료된 프론트엔드 개발을 Integration에 병합하고, 새로운 기능 제작은 Integration에서 바로 생성한다.
- 독립적으로 제작 가능한 기능에 대해서만 병렬로 개발을 진행하고, 이외에는 무조건 테스트가 완료될 때 까지 기다린다.
우선 1번에 대한 문제점은 명확했습니다.
이전에 개발된 기능을 지금 만들 기능에 반영할 수 없다는 것입니다.
예를 들어 onboarding 페이지는 무조건 login페이지에서 user 정보를 받아와야 제작이 가능한 페이지입니다.
물론 mock 데이터로 어느정도 테스트가 가능하지만, SDD로 이미 정해진 명세대로 제작이 가능한 상황에서 굳이 mock 데이터로 제작하고 이후에 또 수정 작업을 거치는건 비효율적이라고 생각했습니다.
그래서 생각한 방법이 2번입니다.
Integration에서 바로 다음 기능을 위한 Integration을 생성하는 것입니다.
예를 들면 Integration/auth에서 바로 Integration/onboarding 브랜치를 생성하는 것입니다.
이 방법은 1번 방법에 대한 문제점을 해결할 수 있었습니다.
이전에 개발한 기능에 이어서 다음 기능을 개발할 수 있었습니다.
하지만 연쇄 충돌이라는 새로운 문제점이 생기게 됩니다. Integration/auth - Integration/onboarding - Integration/library 이런식으로 브랜치를 설계하면, 이후에 Integration/auth 테스트 과정에서 수정 사항이 생기면, 이후에 생성된 모든 브랜치에 연쇄적으로 충돌이 발생할 수 있습니다.
결국 팀에서 정한건 3번이었습니다.
기능별로 연결되는 페이지와 독립적으로 존재하는 페이지를 구분하는 작업을 진행하였습니다.
이후 기능이 연결되어야 하는 작업은 테스트 이후에 다음 기능 제작으로 규칙을 정했고, 기다리는 동안에는 독립적으로 제작 가능한 페이지를 제작하는 것으로 결정했습니다.
이로써 문제를 완벽하게 해결하진 못 했지만, 프론트엔드 개발자가 기다리는 동안 다른 페이지를 안정적으로 개발할 수 있는 규칙을 추가함으로써 이전보다 더 나은 팀 개발 환경을 만들 수 있었습니다.
💡 느낀 점
처음에 브랜치 전략은 단순하게 우리가 어떻게 작업 할 건지 흐름을 결정하고 보여주는 흐름도 정도라고만 생각했었습니다.
하지만 실제로 개발을 진행해보니 단순히 흐름도 결정만으로는 해결하지 못 하는 부분이 많다는 것을 깨달았습니다.
프론트엔드가 기다려야 하는지, 백엔드가 기다려야 하는지, 언제 테스트를 진행해야 하는지 등 단순한 흐름도가 아니라 우리 팀과 프로젝트의 규칙 집합소라는 것을 깨달았습니다.
이는 테크리더로서 팀에 적절한 브랜치 전략을 설계하고 이에 대해서 팀원들과 공유해보는 중요한 경험 이었습니다.
공용 문서 수정에 대한 규칙
저희 팀에서 정한 규칙 중 하나는 "공용 문서를 어떻게 수정하고 관리할 것인가" 였습니다.
처음에는 공용 문서에서 충돌이 발생할 일은 없을 것이라고 생각했습니다. 이미 충분히 기능명세서와 API명세서를 검토한 뒤 개발을 시작했기 때문입니다.
하지만 실제 개발을 진행해 보니 여러 번 검토를 거쳤던 것과는 별개로 예상하지 못했던 부분에서 지속적으로 문서 수정이 필요했습니다.
명세와 실제 구현에서 충돌이 발생하는 경우도 있었고, 문서끼리 내용 최신화가 공유되지 않아 서로 다르게 설명하는 부분들도 있었습니다.
예를 들어 auth 기능명세서에는 "nickname은 입력받지 않는다." 라고 작성되어 있지만, API명세서에는 "nickname을 입력받아야 한다." 라고 작성되어 있는 것입니다.
이런 부분에 대해서 공용 문서 수정이 필요하지만, 수정에 대한 규칙을 정하지 않으면, 분명 Integration으로 합치는 과정에서 충돌이 생길 확률이 증가할 것이라고 생각했습니다.
이에 대해서 어떤 방법이 적절할지 고민하던 중 프론트엔드 개발자 팀원이 좋은 의견을 내주셨습니다.
문서에 직접 반영하는 것이 아니라 업데이트 해야할 내역을 기록하는 파일을 따로 만들자는 의견이었습니다.
듣자마자 너무 좋은 방법이라는 생각이 들었습니다. 공용 문서를 직접 수정하지 않으니 충돌할 확률도 급격히 줄어들고, 업데이트해야할 내용은 작업할 때 바로 기록하니 코드 수정과 문서 업데이트가 같은 버전을 유지할 수 있었습니다.
저는 해당 방법을 바로 도입하자고 했고, 위 사진은 공용 문서 수정 이유를 작성한 문서입니다.
이와 같이 백엔드와 프론트엔드가 동시에 공유해야 하는 domain 문서를 각자가 직접 수정하는 것이 아닌 위와 같이 업데이트가 필요하다는 내용을 적은 문서를 발행하는 형식으로 진행하여, 실제 공용 문서 수정은 Integration에서 백엔드와 프론트엔드가 합쳐졌을 때 진행하는 방식을 선택했습니다.
이를 적용하기 위해 위와 같이 폴더 구조를 설계했습니다.
docs/changes/archive는 공용 문서 수정이 완료된 건을 저장하고,
docs/changes/pending은 아직 공용 문서에 반영되지 않은 건을 저장하여 어떤 문서를 반영해야 하는지 직관적으로 알 수 있는 구조를 선택하였습니다.
💡 느낀 점
이번 경험을 통해 SDD에서 문서는 단순한 설계 결과물이 아니라, 팀원과 AI가 함께 참고하는 하나의 공통되는 소스라는 것을 깨달았습니다. AI를 단순히 AI라고 생각하는 것이 아닌 한 명의 문서 관리 직원이라고 생각하고, 어떻게 이 문서 관리 직원이 우리와의 이해 관계를 따라오게 할 수 있을지 설계하는 것이 중요하다는 것을 깨달았습니다.
AI 기반 기능 수정 사항 Ticket 자동화
제가 도입한 구조 중 하나는 기능 수정 사항을 AI가 ticket 문서 형태로 자동으로 발행 해주는 구조였습니다.
Integration에서 통합 테스트를 진행하다 보면, 백엔드와 프론트엔드에서 수정해야될 기능이나 구조가 자주 발생합니다.
이러한 수정에는 API 명세가 변경되기도 하고, 도메인 구조가 수정되기도 하고, 백엔드와 프론트엔드가 같이 수정되어야 하는 기능도 생깁니다.
일반적으로 이러한 내용을 공유하기 위해서 slack이나 jira를 사용하는 것으로 알고 있습니다.
하지만 이러한 방법은 두 가지 불편한 점이 있다고 생각했습니다.
첫 번째는 개발자가 변경 사항을 직접 Ticket으로 정리해야 한다는 점이고,
두 번째는 수정을 담당하는 개발자가 다시 AI에게 변경 배경과 맥락을 설명해야 한다는 점입니다.
그래서 제가 떠올린 방법은 이러한 수정 사항과 맥락을 AI가 직접 Ticket 문서로 생성해주는 것이었습니다. 예를 들어 docs/tickets/frontend/pending과 같은 경로에 뭐가 문제인지, 왜 수정해야 하는지, 어떤 것을 수정해야 하는지, 어디까지 영향이 가는지 등을 적은 짧은 문서를 발행하는 것 입니다.
이렇게 하면 이를 수정하는 개발자는 문서를 읽으며 간단하게 검증만 하면 되고, 이후 개발을 진행할 때는 이 문서 자체를 AI에게 넘겨 SDD의 장점을 살릴 수 있었습니다.
이를 적용하기 위해 위와 같은 폴더 구조를 설계했습니다.
생성된 Ticket은 pending에서 관리하고, 작업이 완료되면 archive로 이동하도록 하여 변경 사항의 진행 상태도 함께 관리할 수 있도록 했습니다.
이러한 구조의 도입은 효율적이고 훨씬 더 체계적인 개발을 할 수 있도록 도와주었습니다.
위 사진은 제가 Slack에서 이러한 기능에 대해 도입 제안을 하는 글입니다.
💡 느낀 점
이번 구조를 설계하면서 가장 크게 느낀 점은 AI 시대의 Ticket은 사람만을 위한 문서가 아니라는 것이었습니다.
기존에는 수정 사항을 팀원에게 전달하기 위해 Ticket을 작성했다면, 이제는 AI에게도 동일한 맥락을 전달해야 합니다.
결국 하나의 수정 사항을 사람에게 설명하고, 다시 AI에게 설명하는 프로세스는 중간에 맥락이 손실될 가능성이 있고, 개발자끼리 같은 맥락을 공유하지 못 한다는 문제점도 있습니다.
그래서 변경 내용을 AI가 직접 문서화하고, 그 문서를 다시 AI의 입력으로 사용하는 구조를 고민하게 되었습니다.
물론 이러한 구조가 실제 프로젝트에서 충분히 검증된 방법은 아니지만, AI가 개발의 중심이 되는 시대에는 코드보다 이러한 맥락을 얼마나 잘 관리하고 전달할 수 있는가가 생산성을 결정하는 중요한 요소지 않을까 생각했습니다.
이번 구조는 그런 AI시대에 맞는 실험적인 구조 도입이었습니다.
😊 마무리
이번 프로젝트를 진행하면서 AI 시대에는 개발자의 역할도 달라지고 있다는 것을 느꼈습니다.
물론 이전에도 느끼고 있었지만, 실제로 AI를 활용한 개발을 진행해보니 더 확실히 느껴졌습니다.
예전에는 어떻게 코드를 작성할지 고민했다면, 이제는 AI가 올바른 코드를 생성할 수 있도록 어떤 맥락을 어떤 형태로 제공할지를 고민하는 시간이 더 많아졌습니다.
PRD, 기능명세서, API명세서, UIUX명세서, 공용 문서 수정 규칙, Ticket 발행 구조 도입까지 모두 결국 AI에게 정확한 맥락을 전달하기 위한 설계였습니다.
앞으로는 코드를 설계하는 능력만큼 맥락을 설계하는 능력도 중요한 개발 역량이 될 것이라고 생각했습니다.
테크리더로서 느낀 점도 분명히 있었습니다.
기존에 제가 중요하다고 생각했던 능력은 프로젝트 요구사항에 맞게 프로젝트를 설계하는 것이었습니다.
예를 들어 "이 프로젝트는 AI 서버가 독립적으로 처리해야할 게 많고, 백엔드가 이 처리를 기다려야 하니 서버를 분리해서 메시지 큐를 적용한 비동기 형식으로 통신을 구현해야 겠다." 같은 것이었습니다.
이러한 부분은 정답이 없는 영역이라고 생각했고, 그렇기에 더 어려운 부분이라고 생각했습니다.
하지만 이번 경험을 통해 알게된 점은 단순히 프로젝트 요구사항만이 중요한 것은 아니라는 것을 깨달았습니다.
물론 프로젝트 요구사항도 중요하지만, 우리 팀의 개발 속도, 인원 구성, 팀원의 역량, 협엽 방식 등도 프로젝트를 설계하는 데 있어 굉장히 중요한 부분이었습니다.
즉, 테크리더는 단순히 프로젝트 요구사항에 맞춰 프로젝트를 설계하는 것이 아니라, 팀 전체를 보고 프로젝트를 설계할 수 있어야 한다는 것을 깨달았습니다. 또한 요즘 시대에는 AI를 어떻게 팀에 잘 적용할 것인지 설계하는 것도 테크리더의 중요한 역할이지 않을까 생각했습니다.
결론적으로, 이번 테크리더의 경험은 정말 많은 것을 배우고 느끼고 생각하게 만드는 경험이었습니다.
기존에 혼자 개발하면서는 얻기 어려운 것들을 정말 많이 얻어갈 수 있었습니다.
앞으로도 테크리더로서 다양한 문제들을 만나고 해결하는 과정이 진행될 것 같고, 이 중에 공유할 만한 내용이 생기면 또 글을 적어보도록 하겠습니다.
그럼 지금까지
읽어주셔서 감사드리며, 다음에 더 좋은 글로 돌아오도록 하겠습니다.
by. 대학생 개발자 주이어
KYT CODING COMMUNITY Discord 서버에 가입하세요!
Discord에서 KYT CODING COMMUNITY 커뮤니티를 확인하세요. 28명과 어울리며 무료 음성 및 텍스트 채팅을 즐기세요.
discord.com
KYT CODING COMMUNITY 가입하기!
'[Activity] > [ASM·SWM]' 카테고리의 다른 글
| [ASM·SWM] SW마에스트로 17기 합격 후기! (1년의 준비 과정, 16기 탈락 그 이후) (3) | 2026.04.27 |
|---|
