어떻게하면 주니어 개발자를 효과적으로 매니징하면서 프로젝트의 품질과 팀의 생산성을 높일 수 있을까?를 고민하며
작성한 글로 다른 분들께도 도움이 되었으면 합니다.
1. 관리직이 직면한 현실적 고민
저는 Vision과 Motor 구조 설계에 4~5년 경험이 있는 개발자였습니다. 그런데 올해 사업을 준비하면서 제 주요 업무는 투자 유치와 관련된 비개발 업무로 이동했습니다.
이 과정에서 개발의 주요 부분을 2년차 주니어 개발자에게 위임해야 하는 상황에 놓였고, 곧 몇 가지 현실적인 문제에 직면하게 되었습니다.
주요 문제:
- 주니어 개발자가 구상된 기능을 제대로 구현하기 어려운 경우가 발생함.
- 필요한 기능만 구두로 전달하고 "알아서 해봐"라는 방식의 위임은 시간을 벌 수 있지만
오히려 혼란과 비효율을 초래할 수 있음. - 기술 부채와 코드 품질 문제로 시간이 지날수록 프로젝트의 방향성이 흐려짐
2. 무분별한 위임의 부작용
처음에는 내가 지금 너무 바빠서 개발에 신경을 쓸수 없기 때문에 일단 위임이 좋을거라고 생각할 수 있습니다.
그런데 지금까지의 경험상 주니어 개발자에게 업무를 맡기게되었을 때 초기엔 책임감과 사명감에 수행하면서 성실히 보고서도 작성합니다.
그러나 시간이 지날수록 아래와같은 문제들이 드러날 수 밖에 없었습니다.
- 기술 부채가 쌓인다: 유지보수와 확장이 어려운 코드가 늘어납니다.
- 프로젝트의 방향성 흐려짐: 시스템 설계의 일관성이 무너지면서 프로젝트의 전반적인 품질 저하.
- 저품질 코드 증가: 단순히 기능 구현에만 초점을 맞춘 코드가 프로젝트에 누적됩니다.
그러면 결국 내가 모든걸 개발하고 몇가지 남은 부스러기 코드들만 주니어 개발자에게 맡겨야하는건가? 라는 생각이 들었지만 이 모든 문제는 다른 사업의 위임처럼 개발 프로세스를 체계적으로 만들어놓으면 해결할 수 있지않을까? 라는 생각으로 전환할 수 있었습니다.
예를들어 저는 에어비앤비와 단기임대를 각각 하나씩 운영하고 있는데 제가 하루에 1분도 투자하지 않음에도 잘 운영되고 있습니다.
그렇게 만든 과정을 살펴보면 제가 해야하는 일들을 모두 위임했기 때문인데, 그 과정은 아래와 같습니다.
그럼 직접 해보고 그걸 바로 매니저를 뽑아서 바로 넘기는건가? 라고 하면 그건 아니었습니다.
위와같은 과정을 거친 이후에 매니저님을 뽑아서 위임을 진행했습니다.
문서 하나만 보면 바로 업무에 투입될 수 있도록 한 것이죠.
그런데 이런 생각이 들 수 있습니다.
이건 지식 노동이 아니고 몸쓰는 일이니까 매뉴얼화가 가능하지... 그런데 개발자들은 지식노동자들이고
자기가 생각하는대로 움직이고 업무를 할텐데 그걸 어떻게 매뉴얼화해서 위임 할 수 있겠어??
어떻게 매뉴얼화해서 할 수 있을지 예시를 들며 한번 생각해보겠습니다.
Example)
현장 노동자분들은 처음 업무에 투입되었을 때 어떻게 일을 할까요?
제가 만약 숙소청소 업무에 투입되었다면 일단 아래와 같은 생각을 처음에 하게 될 것 같습니다.
( 업무에 관심이 있다는 가정입니다. 업무에 관심이 없다면 " 그냥 가서 청소하면 되지~ "라고 생각할테니까요 )
- 내가 이 숙소에서 어떤 청소를 하면되지? 모든 청소를 세세하게 다하는건가? 아니면 일부분만 하면되나?
- 내가 숙소에 들어가서 어떤 순서로 일을 해야하지?
- 내가 숙소에 들어가서 가장 먼저 해야 할일은 뭐지?
- 내가 어떤걸 준비해서 가야하지? 만약 도구들이 있다면 어떤 도구를 사용해서 해야하지?
- 청소를 하다보니까 이런 문제가 이런상황에서는 어떻게 해야하지?
- 청소가 다 끝났을 때는 그냥 가면 되는건가?
그럼 이러한 내용들을 저를 고용한 사람한테 물어보게 되겠죠.
"이런 궁금한 사항들이 있는데 이것들에 대해서 좀 알려주세요"
그럼 그 고용주는 저에게 위 질문에 대해서 생각하고 알려주느라 시간과 집중력이 흐려질겁니다.
그런데 이럴 때 고용주가 아래와같은 메뉴얼을 주면 제 질문에 대답하느라고 시간과 집중력을 소모하지는 않겠죠.
그럼 이 방식을 지식노동자분들께 그대로 적용해보겠습니다.
제가 로봇을 제어하는 회사에 개발자로써 서류를 내고 면접을 봐서 합격했습니다. 그런데 제가 첫번째 개발자라고 하네요.^^; 그럼 이제 회사에 출근하기 전까지 이런 생각들을 할겁니다.
- 내가 이 숙소에서 어떤 청소를 하면되지? 모든 청소를 세세하게 다하는건가? 아니면 일부분만 하면되나?
▶ 내가 이 회사에 들어가서 어떤 업무를 하는거지? 개발자가 나밖에 없으니 모든 프로그램을 다 만들어야하는건가?
아니면 이미 만들어진 프로그램에서 기능만 추가하는건가?
- 내가 숙소에 들어가서 가장 먼저 해야 할일은 뭐지?
▶ 내가 이 회사에 들어가서 가장 먼저 해야 할 일은 뭐지? 프로그램을 처음부터 만들어아하는건가?
아니면 Vision이나 Motion제어만 하는건가?...
- 내가 어떤걸 준비해서 가야하지? 만약 도구들이 있다면 어떤 도구를 사용해서 해야하지?
▶ 내가 이 회사에 들어가기 전에 알아야 할건 뭐지? 이 회사에서 어떤 프레임웍과 툴을 사용하고 있을까?
협업툴도 사용하고있나? Github를 사용하고 있나?
- 청소를 하다보니까 이런 문제가 이런상황에서는 어떻게 해야하지?
▶ 내가 이 회사에 들어가서 발생하는 일들을 누구와 함께 처리하게 되는거지?
이렇게 현장노동자분들의 생각과 비슷한 고민을 하게 됩니다.
그럼 이때 회사 입사 전 아래와 같이 그 회사가 만들어놓은 문서들을 공유해준다면
무엇을 준비해야할지, 그리고 누구에게 연락해야할지 등등 회사에 직접 연락할일은 없겠죠?
그리고 회사에 입사한 뒤에는 아래 작성한 방식들을 따르면 충분히 혼자 일을 할수 있는 능력까지 갖출 수 있을겁니다.
3. 주니어 개발자와의 효율적인 협업 전략
프로세스 만들기
그러면 입사한 주니어 개발자에게 내가 최대한 개발에 관여하지 않고 업무를 맡기려면 어떻게 해야할까요?
멘토링을 받으면서 들었던 한 가지 조언이 뇌리에 남습니다.
“미국 상위 10%는 어떻게 나머지 90%를 이끌어가는가? 답은 체계적인 프로세스에 있다.”
즉, 나보다 업무를 모르는 다른 사람들을 위해서 체계적인 프로세스를 만들어서 전달해줘야합니다.
이것의 핵심 관점은 "내가 일을 잘할 수 있는 방법"을 생각하는게 아니고 " 팀원이 일을 더 잘할 수 있는 환경을 만드는 방법"을 생각하는 관점입니다.
그럼 이 프로세스를 만들기 위해서는 어떤 방법을 사용하고 어떤 생각을 해야할까요
- 명확하고 구체적인 지침: 명확한 지시와 구체적인 작업 목표를 요구합니다.
- 시스템 일관성: 프로세스는 알고리즘처럼 반복 가능하고 일관되게 설계되어야 합니다.
의사결정 미리하기
명확하고 구체적인 지침과 일관성 있는 시스템을 만들기 위해 우리는 의사결정을 미리하는 문사화를 사용해야합니다.
개발 과정에서 가장 시간이 많이 소요되는 것은 코딩이 아니라 의사결정입니다.
주니어 개발자는 특히 불확실성에서 오는 고민으로 많은 시간을 낭비합니다.
이를 해결하기 위해 문서화 과정에서 핵심적인 의사결정을 선제적으로 기록해야 합니다.
구체적인 문서 작성 예시:
- 모호한 문서:
- Vision 검사 기능 구현- 데이터 수집 최적화- Motion 제어 오류 처리 추가
- 명확한 문서:
- Vision 검사 기능 구현> OpenCV를 사용하여 흑백 이미지를 기반으로 물체 경계선을 검출.
> 경계선 검출 정확도 95% 이상을 목표로 조명 보정 알고리즘 추가.
> 검사 주기: 2초 내 완료.- 데이터 수집 최적화
> FASTECH 모터 라이브러리를 사용하여 모터 속도와 위치 데이터를 10ms 간격으로 수집.
> 수집된 데이터는 CSV 형식으로 로컬 저장소에 저장하며, 1시간마다 서버로 전송.
> 데이터 누락 방지를 위해 100개의 데이터 버퍼링 처리 후 일괄 저장.- Motion 제어 오류 처리 추가> 통신 장애 발생 시 최대 3회 재시도, 재시도 간격 1초.
> 지정 위치 오차가 ±0.05mm를 초과하면 보정 루틴 실행.
> 모터 과부하 시 알림 로그를 생성하고 동작 중지 후 재가동.
업무지시 명확하게 하기
"사장학개론"을 집필한 김승호 회장님의 말을 빌려오자면 업무 지시는 위에 말한 것과 같이 명확성과 데드라인을 반드시 포함해야 합니다.
다음은 잘못된 예시와 올바른 예시를 통해 살펴보겠습니다.
- 잘못된 예: "아까 그 문서 처리해줘요."
- 올바른 예: "오전에 받은 API 명세서를 검토해서, 오후 3시까지 피드백 주세요."
명확한 목표와 기한이 주어지면 팀원의 생산성은 극대화됩니다.
이러한 말 하나하나가 직원과 상사 (대표) 와의 신뢰성, 업무효율성을 극대화 시켜줍니다.
4. 체계적인 문서 기반 개발 프로세스 구축
그럼 실제 어떤 문서를 작성해야 개발을 위임할 수 있을지 살펴보겠습니다.
- SRS (Software Requirements Specification): 시스템 요구사항 정의서. 프로그램의 핵심 기능과 제약사항 명시.
- SDD (Software Design Document): 시스템 설계 문서. 주요 컴포넌트 간 상호작용 정의.
- Tech Spec (Technical Specification): 세부 기술 구현 명세서. 기술 스택과 구현 방식 구체화.
물론 주니어 개발자가 개발용어에 대해 익숙하지 않고, 지금까지 항상 복사/붙여넣기만 하는 업무만해왔다면
위 문서를 보는 방법을 모를 것이기 때문에 이 부분은 직접 알려주며 진행하는게 좋지않을까 싶습니다.
위에서 예시를 들었던 청소업무를 하는 현장 노동자가 최신 청소기 사용법을 몰라서 일을 못하고 있으면
가서 알려주면 되듯이요.
그런데 만약 복사/붙여넣기만 하는 업무라고 했어도 기존에 만들어 놓은 프로그램이 탄탄하고 체계적으로 만들어져있다 라고 한다면 기능만 추가되는 것이기 때문에 문제될만한건 없을 것 같습니다.
5. 주간 업무 프로세스 설계
SRS, SDD를 보고어떠한 기능들을 자신이 추가해야하고 어떻게 만들어야하는지 모두 숙지했다면
이미 개발이 진행되고 있다고 하더라도 SRS만 보고 어떤 기능들이 필요할지에 대해서 하루동안 구체적으로 설계해보라는
지시를 통해 프로젝트에 대해 깊이 생각해보는 훈련을 시켜봅니다.
"너가 이 프로젝트를 맡은 팀장이라고 한다면 그리고 고객이 (대표가) 이런 설비, 로봇, 프로그램을 만들고싶다고 이야기 했을 때 너는 이 프로젝트가 얼마나 걸릴 것 같고, 이 프로젝트를 진행하기 위해서는 어떤 기능들이 필요하다고 생각하는지 작성해봐"
* 여기서 중요한점은 전체적인 기능설계시에는 디자인패턴이나 언어의 특성을 세세하게 고려하지 말고 이 프로젝트가 현실화 되기 위해서는 어떤 기능들이 필요할지 브레인스토밍 하는 형식으로 나열하고 필요없는 기능들은 제거해나가며 프로젝트의 방향성을 확립시키는게 중요할 것 입니다. *
이후에는 실제로 작성한 문서를 기반으로해서 왜 이렇게 생각했는지를 시간을내어 들어주고 어떤 부분이 부족한지
일주일정도는 투자해서 코칭해줍니다.
시간이 없고 월급이 그냥 나가는 것처럼 마음이 아프더라도 이러한 과정을 거쳐야 생각하는 훈련을 할 수 있고
실제 이 프로젝트를 진행하면서 잘못된 방향으로 나가는 것을 막을 수 있습니다.
그리고 마지막으로 직접 설계한 기능들을 직접 구현하기 전에 절대 코드를 먼저 작성하지 않고
Tech Spec을 작성하게 하여 업무를 진행시킵니다.
요일주요 업무
| 월요일 | Tech Spec 작성 |
| 화요일 | Tech Spec 리뷰 및 수정 |
| 수요일 | 핵심 코드 작성 |
| 목-금요일 | 세부 기능 구현 및 테스트 |
1개월간 반복된 결과:
- 주니어 개발자의 설계 능력 및 Tech Spec 작성 역량 향상.
- 체계적인 사고방식을 자연스럽게 훈련.
6. 마무리 성공적인 협업을 위한 전제 조건
아래 조건들이 뒷받침되지 않으면, 어떤 프로세스도 효과를 발휘할 수 없습니다:
- 충실한 기본 문서: SRS와 SDD는 상세히 작성되어야 하며, 지속적으로 업데이트되어야 합니다.
- 시간 투자: 리뷰 및 피드백에 충분한 시간을 할애해야 합니다.
- 일관된 프로세스 유지: 프로세스는 예외 없이 지켜져야 하며, 필요 시 개선이 이루어져야 합니다.
'Program > 생각' 카테고리의 다른 글
| 테크스펙의 새로운 중요성과 AI 시대의 변화 ( Chat GPT ) (1) | 2024.12.04 |
|---|---|
| 테크스펙의 새로운 중요성과 AI 시대의 변화 (1) | 2024.12.04 |