신입 개발자를 위한 온보딩 업무 팁
어떻게 하면 신입 개발자가 조직에 온보딩을 잘 할 수 있을까? 저의 경험을 바탕으로 한 조언을 3개를 정리 했습니다. 이 사람은 이랬었구나 하며 읽어 주시면 좋을 듯 합니다.
프로젝트를 진행하면 늘 제한된 자원과 상황에 놓이며 최종 기한에 쫓기며 살게 됩니다만, 적당한 스트레스는 업무 효율을 높이는 데 긍정적인 영향을 미칠 수 있습니다. 다양한 연구 결과와 사례도 많이 있습니다.
프로젝트에서 충분한 일정과 자원이 주어지면, 업무를 끊임없이 조정하고 다듬으며 "완벽한" 해결책을 찾기 위한 완벽주의의 함정에 빠지기 쉽습니다.
이를 잘 설명한 것이 파킨슨의 법칙(Parkinson’s Law)입니다. 영국의 시릴 노스코트 파킨슨(Cyril Northcote Parkinson)이 1955년에 제안한 개념으로, 업무를 마치는 데 걸리는 시간은 할당된 마감 시간만큼 늘어난다는 법칙입니다.
예를 들어, 프로젝트 단위 기능 개발이 2주 안에 완료되어야 하면, 그 작업은 2주 동안 계속 늘어질 수 있습니다.
무엇이 중요한가?
제가 3년 차일 때, 대기업의 Java, Oracle 기반 회계 프로그램을 .NET 2.0, SqlServer로 전환하는 프로젝트에 투입되었습니다. Typed DataSet이라는 ORM 초기 개념의 기술을 활용하여 Winform을 개발하는 프로젝트였는데, 10명 정도가 1년 동안 진행한 제법 큰 프로젝트였습니다.
문제는 제가 Java, Oracle 기술은 어디서 들어본 수준밖에 되지 않았고, 차변 및 대변의 의미를 모를 정도로 회계 업무에 대한 이해가 전혀 없었다는 점이었습니다. 업무와 기술이 부족하면 현실적으로 야근과 철야를 반복할 수밖에 없었습니다. 가진 것은 책임감과 체력이었으니까요. 물론 지금은 배포/운영 장애 상황이 아니면 야근하지 않습니다.
스트레스를 하나도 받지 않고 살 수는 없습니다. 그래서 스트레스를 어떻게 관리하느냐가 중요한데, 저의 경우 해본 적이 없는 새로운 업무에 대해 제 전공과 경력을 활용할 수 있는 상황이라면 다음과 같이 긍정적으로 생각합니다.
- 레퍼런스가 있는가? 아주 좋아요! 검증된 가이드라인이 있다는 것은 업무에 대한 보고와 설득의 시간을 줄여주며, 완료 시기를 가늠하며 기승전결을 구상할 수 있습니다.
- 레퍼런스가 없는가? 아주 좋아요! 누구도 해보지 못했던 경험을 나보다 잘 아는 사람이 많아지도록 업무에 대한 보고와 설득할 수 있는 권한이 생겼습니다.
부당하게 받아들일 수 있는 업무를 통해 새로운 기술이나 학습과 성장 기회를 습득할 수 있는 기회가 있는지 확인합니다. 내가 업무를 주도할 수 있는 기회는 흔하지 않습니다. 이는 본인에게 장기적으로 도움이 될 수 있습니다.
내 능력으로 할 수 없는 일은?
최종 기한은 일에 대한 우선순위와 실용적인 결정을 내리는 것에 대해 나를 위한 것인지, 조직을 위한 것인지, 고객을 위한 것인지 선택하도록 강제하는 효과가 있기 때문에 어렵고 힘이 듭니다. 하지만 반대로 일의 진행을 위한 주변의 반론을 줄이며 마일스톤을 찍을 수 있는 명분을 만들어주는 강력한 힘이 있습니다.
결자해지(結者解之) "맺은 자가 그것을 풀고, 일을 시작한 자가 마땅히 끝까지 책임져야 한다"는 의미를 마음에 품는 편인데, 10명 중 9명은 그것을 해내기 어렵고, 이것이 나의 강점으로 생각하기 때문입니다. 예전엔 이런 마음이 좀 먹혔던 것 같은데, 지금은 좀 달라진 것 같네요.
그래서 고객의 요청을 정리해서 팀원들에게 보고/설득/전달할 때와 직접 요청을 받아 기능의 추가/개선을 하기 위해 개발 일을 하기 전에 한 번 더 고민해봅니다.
- 누구에게 꼭 필요한 기능인가?
- 개발/납기 일정을 스스로 가늠할 수 있는가?
- 협업 또는 위임이 나을 수 있는가?
- 더 나은 다른 방안이나 솔루션은 없는가?
- 결과로 인한 향후 추가 업무의 가능성은?
여건이 되지 않아 일을 마무리 짓기 어렵다면 위의 내용과 함께 보고/공유에 내가 아니더라도 이 작업을 완료하기 위해 필요한 내용을 추가해야 합니다. 예를 들면 다음과 같습니다.
- 마무리에 필요한 지원 또는 조건 항목을 정리
- 가능한 해결책을 명확하게 정리
부끄럽게도 제가 신입 개발자 때에는 업무를 뭉개거나, 모르는 체하거나, 파고들 생각을 못한다는 예기를 자주 들었습니다.
최종 기한은 3개로 나누는 게 좋습니다.
IT 프로젝트에서 흔하게 언급되는 단어로 마감일, 마지노선, 데드라인이 있는데, 각 단어의 유래를 찾아보면 사람이 하는 일들은 어디든 비슷비슷하다는 것을 알게 됩니다.
세 가지 용어 모두 어떤 작업이나 과제를 완료해야 하는 마지막 시점을 의미합니다. "최종 기한"이라고 표현할 수 있습니다. 일정에 대한 얘기는 생각보다 입장이나 역할에 따라 오해의 여지가 많아서 3개 정도로 구분해서 소통하는 게 좋습니다.
프로젝트를 하다 보면 흔히 하는 말들 중에 오해를 부르는 말이 있습니다.
- XXX 이거 언제까지 완료할 수 있나요?
- XXX 이건 언제까지 가능합니다.
두리뭉실한 이해당사자들 간의 프로젝트 일정에 대한 명확한 커뮤니케이션을 위해 다음과 같이 나누어 할 수 있습니다. 이렇게 구체적인 업무와 일정을 명시하면 오해를 줄이고, 각 업무 단계별로 필요한 업무 단위를 공유할 수 있습니다.
- 개발 작업은 [날짜]까지 완료될 예정입니다.
- 품질 검증 및 문서화 작업은 [날짜]까지 완료될 예정입니다.
- 운영 적용은 [날짜]까지 완료될 예정입니다.
대부분의 경우 역할이 다른 이해당사자들은 서로의 업무가 어떻게 진행되는 지 잘 모르고, 입장이 다르기 때문에 개발을 하기 전과 하고 난 후에 일어날 일의 양에 대한 예측을 하고 공유하는 것이 좋습니다.
현재 HandStack 프로젝트를 기반으로 레퍼런스를 만들어 가는 중입니다. 이에 대한 개발 경험을 공유하기 위해 자료를 수집하고 정리 중입니다. 그래서 개발자들에게 효율적으로 지식을 공유하기 위해 동영상 강의와 문서화를 연계하는 방안을 고려하고 있습니다. 이를 위해 Marp와 OBS Studio의 사용법을 학습 중인데, 조만간 HandStack을 처음 사용하는 개발자들을 대상으로 자료를 공유하겠습니다.