스타트업, 개발자 선배가 할 몫...
소프트웨어 개발은 팀워크이자 협업.
스타트업에서 개발자의 역할은 매우 중요합니다.
짧은 개발기간과 불확실한 비즈니스 모델, 처절할 정도로 부족한 개발 일정까지...
정말 힘들고 고된 상황입니다.
이 상황에서 스타트업에 들어온 경력 10년이 넘는 선배 개발자는 어떤 일을 해야 할까요?
생각보다 현재 소프트웨어 개발의 전체 과정은
실제 코딩을 하기 위한 설계, 디자인, 개발, 테스트, 배포의 일상적인 프로세스를 위한 주변의 과정과
개발부서 이외의 기획, 마케팅, 영업 부서와 소통하면서
복잡한 과정을 풀어가야 합니다.
보편적인 스타트업에서 개발자들이 매일 하는 업무일반적인 스타트업에서 개발자들이 평소에 하는 업무들을 시각화해봤습니다.
실제, 주황색으로 표시된 설계, 코딩, 단위 테스트의 과정은 하루에 할 수 있는 일에 비한다면, 생각보다 많지 않아 보입니다. 사실, 이 영역을 최대한 많이 늘려야 개발 성과가 많이 나올 텐데 말이죠.
그래서, 선배 개발자들이 노란색으로 표시된 비개발부서( 기획/마케팅/영업 ) 부서들과의 단계에서 정리정돈을 잘해주어야 합니다.
그리고, 이미 동작하고 있는 서비스의 DevOps, 프레임웍이나 인프라 운영, 개발 문서와 정합성을 맞추는 작업등의 비개발부서( 기획/마테팅/영업 ) 부서에서는 이 내용이 작업인지, 뭐하는지 모를 이 업무를 어떻게든 최소화하거나, 정리 정돈하는데 최선을 다해야 합니다.
몇 가지 행동지침을 나열해 보겠습니다.
첫째. 비개발부서( 기획/마케팅/영업 ) 부서의 요구사항이나 기획이 명확하게 될 수 있도록 조언한다.
가장 난감한 것은 부정확하거나 계속 변화되는 요구사항을 버틸 개발자는 없다는 것입니다. 요구사항을 최소화하는 것이 아니라, 명확하게 하고, 일의 우선순위나 환경, 현 단 게에서 할 수 있는 일과, 할 수 없는 일들을 구분해서 정리해주어야 합니다.
물론, 이 과정에서 가장 중요한 것은 '대화법'입니다.
너무 적극적이어도 곤란하고, 너무 소극적이어도 곤란합니다. 특히나, 경력자인 개발자의 경우 나이가 아무래도, 일반 기획부서보다 많기 때문에 상대방 부서에서 이를 힘들어 할 수 있습니다.
말투나, 뉘앙스도 맞추기 어렵고요.
좀 냉정하게 잘라서 이야기하는 개발자 특유의 버릇으로 이야기를 하게 되면, 비개발 부서에서는 해당 대화법을 너무 힘들어합니다. 최대한, 부드럽게 해야 합니다.
단, 능력이 없는 비개발부서의 담당자를 만나면 무지하게 괴롭지만, 그 부분은 상대방 부서의 관리조직을 믿고 기다리시기를...
둘째. 설계, 코딩, 테스트의 기본적인 단계 이외의 업무들을 어떻게 최적화할 것인지 고민하고 실천해야 합니다.
이런 개발의 주변 업무들에 대해서 개발자들은 그 중요성을 잘 알고 있지만, 해당 업무들은 그렇게 티가 나는 업무도 아니고, 개발자 생태계에서만 업무의 중요성과 이해도를 알 수 있습니다. 보통 이 업무들은 다른 개발업무나 서비스에 영향을 주고, 품질과 개발자들의 스트레스, 협업의 속도 등을 조절하는 업무들이죠.
해당 업무들을 최대한 단순화하면서, 절차를 지켜가면서 차근차근 서비스의 품질을 위해서 장기적인 작업이 가능한 형태로 나열을 해주어야 합니다.
셋째. 그렇다고, 기본 개발을 소홀하게 할 수 없습니다. 하지만, 단계별로 해야 합니다.
비즈니스는 계속 변화합니다. 한 번에 다 만들 수 없고, 만들어진 내용들이 몇 주면 새롭게 개선될 가능성도 농후합니다. 적절한 성능과 유지보수를 기반으로 한 개발 구조를 만들어 나가는 것은 신입이거나 1~2년 차 개발자들에게는 그 구조와 규모를 짐작하기 어렵습니다.
프로토타입 기법과 적당한 목업 서비스들로서 서비스를 지탱하면서, 서비스의 변화와 구조적인 안전성을 확보하는 단계에 이르렀을 때에 서비스의 버전업 관리를 하면서 구조를 잡아가야 합니다.
이 상황이 괴로운 상황입니다.
서비스가 일부 불안해지고, 신규 서비스는 증가하고 있으니까요.
하지만, 알아주는 사람은 CTO이거나 개발 총괄 정도밖에 알아주지 않을 겁니다.
뭐, 그 사람이 '선배 개발자'한 명뿐일 가능성도 있고요.
넷째. 능력이 부족한 개발자는 내보내야 합니다.
소프트웨어 개발자 구하기 어려운 시대입니다. 거의 '완전고용'의 시대에 가깝고요.
그래서, 귀하게 구한 개발자를 쉽게 내보낼 수 없습니다.
능력이 부족하지만, 어떻게 필요한 업무들을 나누어서 할 수 없냐는 대표의 이야기도 있고요.
하지만,
소프트웨어는 '품질'보다 중요한 것이 '협업'입니다.
선배 개발자가 보기에 적당한 아키텍처와 구조, 품질에 대해서는
손발을 맞추어 주는 동료가 최고의 동료입니다.
그런 동료가 되지 못할 사람이라면... ( 코드의 품질이나 기술적인 이슈는 해소가 가능하지만... )
빨리 내보내는 것이 현명합니다.
비개발자들과의 의사소통으로도 힘든데,
내부 개발자와의 의사소통까지 힘들면.. 정말, 난감합니다.
다섯째. 가장 많이 실수하는... '책임'에 대한 회피성은 아니지만, '내 잘못'아니다는 식의 답변입니다.
이 부분을 오해하시면 안 되는 것이, 선배 개발자들은 SI나 타기업에서 오랫동안 일을 하면서, 나름 습관화된 것들이 있습니다.
바로, '내가 문제'를 일으키지 않았다는 '발언'을 너무 쉽게 한다는 것입니다.
이런 '이야기'는 특히나 '비개발자'들에게 하지 않는 것이 좋습니다.
개발 조직이 크고, 방대한 상태가 아니고,
전문적인 DevOps조직이 없다면,
자체 QC/QA팀이 없다면...
이런 식의 답변은
비개발 조직에게서 '신뢰'를 잃어버리는 행동입니다.
팀이 작고, 전체 조직원이 100명 이하라면,
문제가 발생하고, 문제가 제기되면...
서로 같이 고민하고, 문제를 해결해보자는 식의
답변이 가장 최선입니다.
여섯째. 후배 개발자들이 사실은 코딩을 더 잘합니다.
저도 느끼는 것인데,
가장 최고의 개발 능력을 보유하고, 머리가 팽팽 돌아가면서 알고리즘을 구사하던 시절은 20대였던 것으로 기억합니다. 그리고, 30대에 적절한 경험과 개발 능력으로 나름 정점을 찍었죠.
분명한 것은 20대 개발자들이 순수 개발은 더 잘할 것입니다. ( 기본적으로... )
다만, 경험에 대한 부족과, 문제 해결에 대한 접근법이 조금 서툴러서
실수하는 것들에 대해서는 웃음으로 대해주시면 좋습니다.
후배 개발자들에게...
'그거 20분이면 되는데'
'그거 내가 예전에 해봤는데, 금방 되던데'
'그거 그럴 줄 알았어'
이런 식의 대화법은 매우 좋지 않은 대화법입니다.
물론, 반 농담 삼아 웃으면서 하는 것까지 이야기하는 것이 아닙니다.
정색하고,
문제를 해소해야 할 시기에...
후배 개발자들을 더 믿고
그들을 동료로서 인정해주세요.
그리고...
마지막으로...
선배 개발자들은...
후배 개발자들에게 조언과 충고보다는...
실천과...
저녁에 술 한잔 사거나,
점심 한 끼 사는...
지갑을 좀 더 여시는 것이 현명합니다.
모든..
선배 개발자들 파이팅~~
