실리콘밸리에서 느낀 AI시대의 인재상

 

AI 시대의 인재상 - 실리콘 밸리와서 보고 깨달은것들

How to do? 에서 What to do?로.

조대협 (http://bcho.tistory.com)

 

이 글은 본인의 개인의 경험을 기반으로 한 개인적인 의견임을 미리 밝혀둡니다. 

 

ChatGPT, Gemini와 같은 AI 모델이 개발되면서, IT 엔지니어의 업무의 방식과 요구 되는 역량이 변화하기 시작하였다. 코딩이나 IT Operation은 AI를 통해서 생산성이 극대화 되었고, 이로 인해서 단순 반복 코딩 작업을 하는 신입 엔지니어의 수요가 점점 줄어들게 되었으며, 이러한 단순 반복 작업은 저소득 국가로 옮겨지고 있는 추세이다.

 

이런 변화에서, IT 엔지니어로써 갖추어야하는 역량은 무엇일까에 대한 고민을 실리콘밸리 IT 엔지니어들의 대화와 경험에서 정리해보고자 한다.

I. AI 시대의 인재상

비즈니스 지향적

먼저 코딩이나, 시스템 운영, 디자인 등 모든 IT 업무에 관련되는 일은 비즈니스를 하기 위한 과정이다. 그러면 비즈니스란 무엇인가? “돈을 버는 행위” 즉 “수익을 남기기 위한 행위”이다. 예전에는 시키는 일만 하면 잘 됐지만 요즘은 “어떤일을 할것인가?”를 찾아야 하며, “그일이 비즈니스적으로 어떤 성과를 만들어 냈느냐를 증명 해야 한다” 예를 들어, “OO 기능을 개발 하여, 제품의 수익을  OO$ 증가 시켰다”. “OO 프로세스를 개선하여, 운영 코스트를 OO$ 절약하였다” 와 같은 구체적인 비즈니스 성과를 만들어 내야 한다.

 

돈을 주는 고용주 입장에서 생각해보자, 200K를 받는 엔지니어와 500K를 받는 엔지니어가 있을때 당연히 고용주 입장에서는 돈을 많이 받는 엔지니어가 더 많은 비즈니스 가치를 만들어내기를 원하고, 이를 측정하기를 원한다. 여러가지 방법을 사용하겠지만, 결국 그 가치를 증명해야 하는 것은 그 돈을 받는 엔지니어가 된다. (기업에서, 업무 평가시 실리콘 밸리에서는 엔지니어들이 자신의 업적과 성과를 증명하는 것이 일반적이다. )

 

이런 트렌드에서 보면, 미국의 VC들이 인당 수익률이 높은 작은 회사에 투자를 선호하는 방향으로 선회하고 있는 것이 좋은 증거가 된다. 대표적인 예가 이미지 생성 모델 서비스 기업인 미드저니 (Mid Journey)인데, 직원수 약 100명이, 연 매출 5억달러($500M) USD를 내고 있다. 즉 인당 5M USD (한화로 70억원)의 매출을 내고 있다는 이야기이다. 

 

즉, 이제는 시키는 일만 하는 것이 아니라, 비즈니스 가치를 극대화 할 수 있는 일을 내가 찾아서 해야 하고, 그 결과를 숫자로 증명할 수 있는 능력을 필요로 하고 있다. 

문제 정의 및 풀이 능력

그러면, 비즈니스 가치를 극대화하기 위해서는 어떻게 일을 해야 할까? 시작점은 문제 정의 능력이다. 고객의 Pain point가 무엇인지를 이해하고, 잠재적 시장 가치를 research하여 예상 수입을 예측한후에, 그 문제를 풀기 위한 최적의 경로를 찾아야 한다. 

 

실제 내가 인터뷰했던 우버의 엔지니어의 개발 경험담을 들어보면, 개발팀의 시니어는 어떤일을 하도록 관리자로 부터 지시를 받지 않는다고 한다. 어떤일을 하면 좋을지를 스스로 찾아내고 판단하고 그 프로젝트를 시작해야 하는 명분을 만들어서 관리자를 설득하는 과정을 수행한다고 한다. 

 

프로젝트를 진행함에 있어서는 개발 능력과 AI 로만으로는 그 문제를 풀 수 없다. 몬가 일을 하기 위해서는 예산과 인원 그리고 기간을 받기 위해서기획안을 다른 사람에게 설득해야 하고, 개발을 시작하더라도 기존 시스템과 통합등을 위해서 다른 부서와 협업을 해야 하며, 제품이 개발된 후에는 고객으로 부터 피드백을 받아서 제품을 개선하고, 잘 팔기 위해 영업을 교육하고 독려해야 한다. 문제 해결이란 단순하게 문제를 해결하기 위한 기능을 만드는 것뿐만 아니라 결과를 내기 위한 일련의 과정을 모두 포함해야 한다. 

커뮤니케이션과 트리아지 (Triage)

이런 관점에서 여러 사람과, 다른 조직, 고객 그리고 리더쉽과 협업하기 위해서 가장 중요한 능력중의 하나가 커뮤니케이션과 Triage 이다. 커뮤니케이션은 다른 사람에게 문제를 설명하고, 다른 사람으로 부터 의견을 듣고 설득하는 단편적인 능력이라면, Triage는 복잡한 문제를 해결 하기 위해서 여러 사람 또는 여러 부서와 복잡한 문제의 해결을 위해서 협업하는 과정을 이야기 한다. 

 

예를 들어, “나의 고객이 대용량 AI 모델 학습을 위해서 대규모의 GPU가 필요하다고 가정하자. 그런데 문제는 우리가 가지고 있는 GPU의 여유 용량이 충분하지 않은 상황일때 어떻게 해결해야 할까?”

 GPU 용량을 가지고 있는 부서를 설득해서 GPU용량을 획득하거나, 아니면 다른 리전에 가용 용량을 보거나, 아니면 고객에게 일정 변경을 요청하거나 또는 더 높은 가격으로 협상을 유도하는 등, 답을 찾기 위해서 여러가지 방안에 대해서 여러 부서를 통해서 정보를 수집하고, 협상하고 설득하는 과정이 필요하다. 하나의 문제가 아니라 동시에 여러 연관된 문제들이 있을 것이기 때문에 이를 구조화하고 타임 라인에 맞게 추적하는 능력이 필요한데, 이를 Triage라고 한다.

특히 시니어 엔지니어 갈 수 록 이러한 능력이 훨씬 더 많이 요구 되고 있으며, 이는 사람을 설득하고 커뮤니케이션 하는 능력이 필요한 만큼 AI로 대체될 수 없는 분야기이다. 

문서화 

문제를 정의하고, 이 문제를 다른 사람과 풀어나가기 위해서 커뮤니케이션을 할때, 매번 모든 사람에게 모든 내용을 설명할 수 없다. 여러 사람들이 같은 목표와 같은 컨텍스트 내에 있게 하려면 가장 좋은 것이 문서화이다. 

문서는

• 문제를 명확히 정의해야 하며,
• 왜 이 문제를 해결해야 하는지, 그리고 이 문제를 해결했을때 얻을 수 있는 비지니스 효과가 명확해야 한다. 

“아무도 긴 문서를 꼼꼼하게 다 읽지 않는다.” 특히나 자신이 꼭 해야 할일이 아니라 도움을 주거나 선택할 수 있는 일이라면 더 그렇다. 그래서 문서는 읽는 사람이 읽어야 하는 이유를 만들어줘야 하는데, “이 문서를 읽었을때 나에게 이득이 있을 수 있는 이유”로 설명을 시작하는 것이 좋다. 

그 이후에, 

• 어떻게 이 일을 진행할 것인지
• 누가 어떤일을 하는지 (R&R)
• 타임 라인은 어떻게 되는지

가 명확하게 정의되어야 한다. 이러한 문서를 보통 One Pager라고 한다. 

이 문서는 항상 업데이트 되어 있어야 하기 때문에, MS-WORD같은 오프라인 문서보다는 실시간 업데이트가 가능한 Google Docs나 Notion과 같은 문서 공유 시스템으로 작성하는 것이 좋다. 특히 Comment를 통해서, 리뷰 의견을 실시간으로 달 수 있고, 특정 Task를 특정인에게 Assign할 수 있기 때문이다. 

 

마지막으로, 문서화에서 가장 중요한것은 “읽기 쉽고, 간결해야 한다.” 문서라는 매체의 특성은 “기록”에도 있지만 가장 큰 목적은 “정보의 전달”에 있다. 단순하고 명확하게 이 문서를 통해서 전달하려는 내용이 명확해야 한다. 

실험 및 데이터 분석 능력

가치 있는 문제를 찾아내고, 이를 해결함으로써 얻을 수 있는 비즈니스 가치($$)를 예측하고, 제품이 출시된 후에, 제품으로 부터 얻어지는 비즈니스 가치($$)를 측정하기 위해서는 “숫자”가 필요하다. 이 “숫자”는 “데이터”이다.

제품의 기획 단계에서, 시장에 대한 분석과, 고객에 대한 분석, 그리고, 실제로 제품이 매출을 발생시킬때 이를 측정할 수 있는 데이터 분석 시스템이 있어야 하고, 또한 이 데이터를 추출하고 해석할 수 있는 능력이 있어야 한다. 

제품이 기능이 어떤 임팩트를 만들어내는지를 보려면, 적어도 A/B 두 집군 이상의 그룹으로 나누어서, 제품의 가치가 실제 수익을 만들어내는지 아닌지를 비교 분석할 수 있는 A/B 테스팅 같은 기본적인 데이터 분석 기술을 가지고 있어야 한다. 

 

이 데이터는 특히 리더쉽을 설득하는게 객관적인 증빙 자료로 효과적으로 사용될 수 있기 때문에, 신뢰있는 데이터 수집 및 분석은 대단히 중요한 능력이며, 특히 이러한 데이터를 직관적으로 이해할 수 있도록 도와주는 시각화(도표,그래프) 능력은 문서화와 커뮤니케이션 능력과 함께 중요한 능력이다. 

리더쉽

앞에서 언급한 능력들을 이용해서, 프로젝트를 기획하고 이끌어 나가기 위해서는, 목표를 설정하고, 팀원을 모집하며, 팀원들에게 영향력을 행사하여 동기를 부여해야 한다. 

즉 팀을 이루어서 목표를 달성하는 능력이 필요한데, 이것이 리더십이다. 

특히 예전처럼 시키는 일을 하는 문화가 아니라, 스스로 일을 찾아서 하는 문화에서는 강제적으로 일을 시킬 수 도 없을뿐더러,오히려 팀원이 되어 달라고 부탁해야 한다. 

팀을 이루면, 각 구성원의 성과를 최대화하기 위해서는 동기를 부여하고, 부족한 부분을 발전시킬 수 있도록 돕는 리더쉽이 필요하다. 

 

내가 한국 스타트업이나 대기업에서 일했던것과 가장 다른 부분중의 하나인데, 한국 대기업에서는 직급을 이용해서 내가 맏은 업무를 지정된 팀원들에게 시킬 수 있었지만, 미국에서는 내가 일을 만들고 이를 같이해줄 주니어 엔지니어들을 설득해야 하며, 그들이 일을 해서 성과를 낼 수 있도록 계속해서 도와주어야 한다. 결과는 나의 실적이기도 하지만 그들도 실적이 필요하기 때문에, 일에 결과를 실적으로 만들 수 있도록 가이드하고 도와주어야 한다. 

 

팀을 이끄는데, 그들을 설득하고 영향을 주기 위해서는 결국에는 커뮤니케이션인데, 이 커뮤니케이션은 상대방에 대한 존중과, 내가 이룬 성과가 중요하다. 내가 이룬 성과는 “내가 이 사람과 일을 하면 얻을 것이 있겠구나.” 라는 기대를 심어줄 수 있어야 하고, 존중은 “나의 의견을 이 사람이 들어주는구나” 라는 마음을 들게 할 수 있어야 한다. 

결론

요즘 실리콘 밸리에서는 “General Software Engineer”라는 단어를 쓰기 시작한다. 예전에 Front End-Backend-Devops 까지 모든 기술 스택을 다룰 수 있는 “Full stack engineer”가 선호되었다면,이제는 기술의 범위를 넘어서 “주어진 문제를 기술로써 해결함으로써 비즈니스 성과를 낼 수 있는 엔지니어” 가 필요한 시대로 변화하고 있다. 

 

기존에 필요 역량이 How to do? 였다면, 이제는 What to do ? 로 옮겨가고 있다. 

 

단순히 주어진 문제를 기술로 구현하는 것만이 아니라, 비즈니스 가치를 낼 수 있는 문제를 스스로 찾아내고, 이를 해결하기 위해서 스스로 팀을 조직해서 협업하고 구현하며, 지속적인 개선을 통해서 가치를 증명해 나갈 수 있는 엔지니어이다. 이 과정에서 필요한 기술은 배우거나 또는 협업을 통해서 해결하거나, 만들어 내면 된다. 기술은 이제 엔지니어에게 문제해결을 위한 수단일뿐 예전과 같이 목적이 되지 않는다.