1인 스쿼드 이야기
1인 스쿼드의 장단점과 나만의 문제해결들
브런치 첫 글은 1인 스쿼드에 대한 이야기로 풀어보고자 한다.
작가 승인받고 현생이 바빠 글을 한 번도 못 썼는데,올해가 가기 전에 하나라도 올려보자는 마음으로 퇴근 후 노트북을 켰다.
목차
1. 뭔데요 그게
2. 1인 스쿼드의 장점
3. 어려운 점과 나만의 해결 방식
4. 어떤 역량이 필요할까 - AI에게 좋은 질문을 던지는 것은 다른 문제
5. 업무강도
1. 뭔데요 그게
1인 스쿼드란 대충 이런 것이다.
스쿼드 조직 모델의 특징인 자율성과 목적성을 1인 기업 운영에 접목하거나, AI 기술 등을 활용하여 소규모 인원으로 효율성을 극대화하는 모델을 의미할 수 있습니다.
문제 해결을 위한 기획 → 개발 → 실행 → 회고 전 과정을 1인이 하는 것이다.
솔깃하다!
요즘처럼 AI가 발달해서 직무의 경계가 흐려진 요즘엔1인 스쿼드에 대한 니즈가 점점 커지고 있는 듯하다.
출처: 경경수의 개발만화2. 1인 스쿼드의 장점
1) 기획도 내가 하고 개발도 실행도 내가 한다 (재밌다 !!)
개발은 특히나 내가 만들고 싶은 거 직접 기획해서 할 때 가장 재미있는 법인데, 모두 직접 주도해서 하기에 즐기며 일할 수 있다.
재미있어서 하다 보면 매일 야근해도 그렇게 힘들지 않다. (지금도 야근하다 왔다)
2) 빠르다
프로젝트 진행 중 생기는 문제를 정말 빠르게 해결할 수 있다.
상황을 공유하느라 미팅을 잡을 필요도 없다. 내가 만든 UI이고 내가 짠 Code니까 어디를 수정해야 하는지도 빠르게 찾는다.
우리 팀 팀원들이 내가 일하는 시간에 항상 온라인인 격이다.
3. 어려운 점과 나만의 해결 방식
(어려운 점을 쓰고 있긴 하지만, 사실 이 과정들 또한 재미있어서 이 일을 한다는 점..)
1) 어려운 점 - 해당 업무에 관련된 사람이 많아질 때, 이해관계 조정이 쉽지만은 않다
예컨대 해결해야 하는 문제가 3개의 팀과 연관되어 있다고 가정해 보자.
A팀의 니즈를 반영하면 B팀의 리소스가 투입되고, vice versa라고 할 때,
그 사이에서 이해관계 조정하는 과정이 쉽지 않다.
이미지 출처: https://brunch.co.kr/@kiril/7내 프로젝트에 연관된 팀은 크게 프로덕트 디자인 조직과 엔지니어링 조직이었고, 목적조직*이었기 때문에 각 PD와 ENG의 업무방식은 팀마다 달랐다.
8개 정도 되는 팀이 공통으로 해야 하는 작업에 대해 각 팀의 이해관계를 PD와 ENG 입장을 고려하며 조정해야 했으니, 쉽지 않은 작업이었다.
* 목적조직: 우측 이미지 참조
나만의 해결방식) 실무진 미팅 후 리더십 미팅
이해관계 조정 과정에서 나는 1) 실무진 미팅을 통해 실무 관점에서의 의견을 수집하고, 2) 리더십 미팅을 통해 의사 결정에 도움을 받았다. 무턱대고 리더십을 먼저 찾아가서 우리 이렇게 결정해요! 하면 설득력도 떨어지고, 결정이 된다고 한들, 실무진 분들께서 문제 제기를 할 가능성이 높다. 또 실무진 미팅만 하고 결정하기엔, 각 팀의 업무방식이 상이해서 리더십의 의사 결정이 필요했다.
2) 어려운 점 - 막혔을 때 조언을 구하기 어렵다
팀 구성원으로 일하게 되면 업무 도중 막혔을 때 누군가에게 질문을 할 수 있다(ex. 이건 어디서 찾나요, 저건 어떻게 하나요). 같은 팀이니까 도움 요청하는 것이 비교적 쉽다. 왜냐면 내가 하는 일이 뭔지 같은 팀 사람은 대충 알기 때문이다.
하지만 1인 스쿼드로 일하게 되면 조언 구할 사람이 애매하다. 맥락을 공유할 수 있으면 더 좋은 조언을 얻을 수 있을 터인데, 일단 내 프로젝트를 설명하는 것부터가 쉽지 않다.
나만의 해결방식 1) 상황을 추상화하기
나의 경우, 그럴 때마다 상황을 추상화해서 비슷한 일을 하는 사람들에게 질문했다. 특히 이해관계 조정에서 막혔을 때 친한 PO분과 TLM(Tech lead manager)분께 많은 도움을 받았다.
나만의 해결방식 2) 발로 직접 뛰기 (삽질하는 것 두렵지 않아!)
또, 업무 히스토리 추적 과정에선 직접 발로 뛰었다. 기존에 관련 업무 했던 사람들과 미팅을 잡고, 비슷한 프로젝트를 했던 사람을 찾아가서 조언을 구했다. 산발된 히스토리를 한데 모으는 작업에 시간이 꽤 걸렸지만, 이 과정이 지나고 나니 방향성 설정에 큰 도움이 됐다.
프로젝트 초기에 TLM분께서 내게 말씀해 주신 것이 있다. "저는 롤백하는 거 전혀 두렵지 않아요"
그 마음으로 임했다. 삽질하는 것 두렵지 않아! 하는 마음으로.
4. 어떤 역량이 필요할까 - AI에게 좋은 질문을 던지는 것은 다른 문제
AI가 성능이 아무리 좋아도, AI에게 좋은 질문을 던질 수 있는지의 여부는 다른 문제이다.
개발자가 나보다 커서에게 좋은 질문을 한다.
오류가 났을 때 기존의 경험을 바탕으로 이거 확인해 봐! 하면 더 빨리 문제가 해결된다.
PM이 나보다 기획이나 프로젝트 매니징을 잘한다.
이 프로젝트가 어떻게 흘러가면 되는지에 대한 질문도 더 잘할 것이다.
PD가 나보다 UI 기획을 잘한다.
이런 기능이라면 이런 컴포넌트가 있으면 좋겠군! 하고 디자인시킨다.
그래서 개인적으로 1인 스쿼드를 하는 데에 필요한 것은 1) 다양한 실무 경험이 있거나, 2) AI를 통해 빠르게 학습하는 역량이라고 생각한다. 아 그리고 이해관계 조정을 위한 3) People Skill에 대해서는 두말할 것 없다
5. 업무강도
야근을 안 할 수 있나..? 솔직하게 말하면 매일 하는 것 같다. 빠르게 배우려면 삽질하는 시간도 그만큼 필요하고, 미팅으로 빠지는 시간도 많으니, 어쩔 수 없는 듯하다.
아무튼 이 일이 난 좋다.
끝.
Lucy - AI Workflow Operator
AI, 개발, 자동화를 활용해
프로덕트 품질 상의 오랜 레거시 문제를 해결하기 위한 노력을 하고 있습니다.