개발자 백그라운드 그로스 엔지니어 되기


Growth 2019. 10. 7. 20:25



 

그로스 엔지니어?! 그로스가 뭔가요?에 이어, 개발자 백그라운드를 가진 그로스 엔지니어가 정체성을 찾아가는 과정을 회고해보기로 한다. 

 

그로스 엔지니어?! 그로스가 뭔가요?

나는 8년차 개발자다. 문득 요새 고민하고, 생각하는 것들을 정리할 필요를 느꼈다. 다른 사람이 아닌 스스로의 생각을 정리해야 겠다 싶어 글을 작성한다. (도움이 되면 그것대로 좋고.) 처음으로 정리할 꼭지는..

mnworld.co.kr

지난 번에 간략하게 서술한 바와 같이, 나의 백그라운드는 개발자이다. 

대기업 연구소에서 인턴으로 안드로이드 앱 개발을 하고, SI 업체에서 팀장으로 주로 안드로이드 개발을, Ruby on Rails와 Frontend, 가끔은 iOS나 MAC프로그램을 개발해왔다. 

대부분의 개발을 1~2명이서 책임지고 했었고, 내부 팀원을 뽑고, 클라이언트와 직접 응대하고 미팅을 하고, 드라이브를 내가 먼저 걸어서, QA 이후 계약이 끝나면 잔금을 요청하던 역할까지 맡아 일을 했었다. 한번에 프로젝트가 몰렸을 때에는 6개가량의 프로젝트가 동시에 돌아간 적도 있었다. 이런 경험에서 내가 얻은것을 객관적으로 살펴보자. 

 

얻은 것: 

속도 - 속도는 원래 빠른편이였으나 빠르게 아웃풋을 내야 하는, 데드라인이 정해진 외주업체의 특성 상 정말 속도를 빨라질 수 밖에 없었다. 처음 일을 시작할 무렵에는 속도는 빨랐으나 버그가 많아, 속도를 유지하면서 버그를 최대한 개발하면서 예측하고 방어하는 능력을 키우는데 꽤 오랜 시간을 들였다. 

컨텍스트 스위치 - 대부분의 개발자가 오랜 시간 집중에 빠지는 시간을 들여 집중을 하며 Feature를 구현하고, 집중에서 빠져나오는 과정이 있다고 생각하는데, 거의 불가능한 상황이였다. 이 일에 집중하려고 하면 클라이언트에게 전화가 오고, 다시 집중하려고 하면 팀원의 질문이 날라오고, 다시 집중하려고 하면 급하게 운영상의 이슈가 터져 다른일을 해야 하고, 사실 그 때는 이런 일이 일상적이였기 때문에 나도 의식하지 못한 상황에서 컨텍스트 스위칭이 되었을 때 굉장히 빠르게 집중을 하고, 뭔가 일이 생기면 짧은 시간 내에 바로 처리할 수 있나? 아니면 잊지않도록 메모해놓고 최소한의 응대를 하자 라는 훈련이 된 듯 하다. 

일을 잘하는 방법 - 주로 신입을 뽑아 실무와 함께 다양한 방법으로 교육을 진행했고, 효율적인 업무를 위해 애자일 방식이나 다양한 협업툴을 활용했다. 더불어 2-3년 정도 협업과 관련한 프로덕을 밀도있게 개발한 경험을 통해 개발이 아닌 일의 시점에서 어떻게 진행하고 효과적인 커뮤니케이션과 일을 마무리하는 방식에 대해 고민을 많이 했다. 

비즈니스 시점에서 바라보기 (기획) - 대기업 선행연구소의 (매우 러프한 기획 상태에 매일같이 기획이 변경되는) 프로토타입의 외주를 자주 맡았고, 약 10가지의 내부서비스를 기획부터 개발, 마케팅 과정을 담당하고, 개인적으로 안드로이드 앱을 60개가량 서비스했다. 이후에는 거의 기획이 없는 상태에서 아이디어를 받아 기획을 녹여 개발하는 외주 형태를 진행했고, 반대로 기획이나 아이디어를 제안하여 프로덕에 녹이는 경험이 많았다. 때문에 클라이언트와 컨설팅을 하거나 기획에 대해 이야기할 때 개발자스럽게 코드를 생각하기보다 어떤 형태로 어떤 UX로 어떤 모습, 혹은 프로덕의 타겟이 니치한지, 해당 프로덕이 돌기 위해 유저 입장에서 중요한 플로우가 무엇인지 등의 고민을 하는 습관이 들었다.

 

이런 점들이 그로스 엔지니어에 어떻게 도움이 될까? 그로스 엔지니어라고 쓰고 그로스 개발자라고 읽었을 때 어떤 포지션에서 업무를 수행해야 하는지에 대략 6개월 가량 고민을 하고 다양한 실험과 롤을 통해 현재까지 정의된 바는 이렇다.

 

그로스팀은 문제를 정의하고, 풀어내고, 스케일업이 가능한 형태(프로덕의 Feature라던가, 그로스 프로덕이라던가)로 만들어 임팩트를 낸다. 

그로스 엔지니어는 각각의 단계에서, 이런 책임과 역할을 진행한다고 생각한다.
(회사와 서비스의 규모, 프로덕의 형태에 따라 그로스 엔지니어의 책임과 역할을 천차만별로 틀려질 수 있다. 철저하게 주관적이고 개인적인 관점에서의 책임과 역할이다)

* 문제정의 

 - (개발자가 아닌) 서비스, 유저의 시각에서 문제를 발견하고 정의할 수 있어야 한다. (정성적인 방법이 더 활용적일 때가 많음)

 - 찾아낸 문제에 대해 데이터를 기반으로 문제를 정의할 수 있어야 한다. (그래야 동일한 데이터를 가진 실험군을 타겟으로 문제를 풀고 스케일업 할 수 있으므로)


* 문제해결 

 - 정의 된 문제에 대한 해결이 가능한 가설을 세우고, 실험을 정의하고, 결과를 볼 metrix를 정확하게 선정할 수 있어야 한다. 

 - 해당 실험이 가능한 환경 구성 및 최소한의 요건을 충족하는 MVP(Minimal Viable Product)를 빠르게 만들 수 있어야 한다. 
 - 실험을 통해 들어온 데이터를 정확히 분석하고 의미있는 결론을 이끌어 낼 수 있다. 


* 스케일업

 - 검증이 완료(성공) 된 MVP를 프로덕으로 제작 혹은 해당하는 프로덕팀에 효율적으로 전달 할 수 있어야 한다. 

 

다양한 팀에서 그로스 엔지니어링 리소스를 요청 시 가설, 실험, 검증 과정에서 위의 역할과 책임을 수행할 수 있어야 한다.

실제 검증하고자 하는 바를 빠르게 이해하고, MVP를 개발해내야 하기 때문에 그로스 '개발자' 엔지니어로써 역할을 수행한다고 생각한다.

 

내가 얻은 강점을 살려,
백엔드와 프론트엔드, 모바일 어플리케이션까지 풀스택이 가능했기 때문에 다양한 MVP를 만들 수 있었고, '빠른 속도'와 '컨텍스트 스위치'를 통해 동시에 여러 일과 많은 카운트 파트를 상대할 수 있는 듯 하다. 개발을 진행하면서 기획을 녹여 아웃풋이 나오는 속도가 빠른 점 등이 그로스 엔지니어의 역할과 책임에 유리하게 작용되고 있다고 생각한다. 

 

상대적으로 경험이 부족한 '데이터를 오류없이 보는 방법 (통계적인 측면과 오류, Martech tool 숙달과 Raw data를 보기 위한 Jupyter nootbook 활용)'과 문제정의와 가설과 실험, 진행에 대해서 경험을 쌓아가는 중이다. 

 

 혹여나 개발자로써 그로스와 그로스 엔지니어에 관심이 있는 분이라면 해당 경험들이 도움이 되었으면 한다. 

 


WRITTEN BY
ShakeJ

트랙백  0 , 댓글  0개가 달렸습니다.
secret