Introduction

수많은 관리 방법이 존재하지만, 본문에서는 앤더슨이라는 사람은 이렇게 관리/운영을 한다고 생각해주시면 좋을 것 같습니다.
저 또한 회사마다의 아이덴티티 또는 문화가 존재한다고 생각하며, 문제와 방향에 맞는 방법을 사용하는 것이 좋다고 생각합니다.
즉 모든 회사와 문제에 적용가능한 솔루션은 없다고 생각하며,
기술 집약적 팀을 운영하는데 적합한 앤더슨만의 노하우라고 생각해주시면 좋을 것 같습니다.

이 바닥에 10년 넘게 있으면서 많은 성과를 냈습니다.
구글 플레이 1위, 카카오 게임 1위, 업계 매출 3위를 1위로 올림, 다들 실패한 프로젝트 맡아서 성공시킨 일화..
대규모 프로젝트를 성공적으로 마친 경험 등등.. 몇백억단위의 매출 기록..
실질적 성과/비즈니스 임팩트를 내는데 많은 노력을 기울여 왔습니다.
(물론 많은 실패또한 겪었지만 실패담은 다음 기회에 쓰겠습니다.)

제가 잘하는 분야는.. 기술과 비즈니스를 잘 엮는데 있다고 생각합니다.
목표는 데이터를 읽고, 방향과 전략을 짜고, 주어진 연구/리소스로 최대한의 성과를 내는데 있습니다.
이런 관점에서 글을 읽어 주시면 감사하겠습니다 :)

1. High Performance Team Management

1.1 기술집약적 챌린지의 문제

문제해결에는 명확한 것이 있으며 비명확한 것으로 구분 될 수 있습니다.
예를 들어 안드로이드 앱/UI 개발하는 것은 이미 풀린 문제이며 대부분 정확한 개발 시간/리소스를 투입해서 문제를 해결할 수 있습니다.

문제는 불확실성이 높거나, 아직 풀리지 않은 문제에 대한 답을 찾는 것 입니다.
대표적인 예로 자율주행, 주가예측 모델링, 또는 중력과 전자기력을 합치는 이론을 찾는 것.. 등등이 있을수 있습니다.
모두 어느정도 풀렸지만, 완벽한 답을 찾은 것은 아닙니다.
또한 문제가 풀렸다 하더라도 정보의 부족이나 문제 자체의 복잡성 때문에 프로젝트를 마칠수나 있을지 의심이 드는 경우가 많습니다.

팀장/조직장은 이런 문제에 대해서 리소스 투입 / 플랜B / 효율화에 대해서 고민을 해 봐야 합니다.
여기에 대한 답은 아래에 계속 글을 쓰면서 이야기 하겠습니다.

1.2 좋은 팀장의 길

1.2.1 최대치의 권한 위임 그러나 작동하지 않는 문제

많은 기업들이 권한 위임을 하려고 노력합니다.
꽤 힙해 보일수도 있는데.. 실제 해보니 성과가 잘 나오지 않는 케이스도 있습니다

문제는 다음과 같습니다.

  1. 권한 위임을 할 수 있는 문화가 되어 있는가?
  2. 권한 위임 가능한 업무와 불가능한 업무를 구분해 놓았는가?
  3. 목표 설정과 방향성은 제대로 조율이 되어 있는가?

1번은 저는 “100% 공유 문화”로 문제를 해결하고 있으며, 아래에서 다시 이야기 하겠습니다.
3번은 OKR로 해결하고 있습니다. 이것도 아래에서 다시 이야기 하겠습니다.

2번의 경우가 중요한데.. 바로 “시급성” 그리고 “중요도” 를 따져서 관리자가 끌고 나갈지, 위임을 할지 결정해야 합니다.
(보통 4분면을 그려서 따지는데.. 그냥 시급한게 중요한거고 중요한게 시급한것이다라고 생각해도 무방합니다.)

  • 시급성으로 따진다면 지금 몇주안에 당장 결과가 나와야 하는 프로젝트 또는 매출에 상당히 크게 임팩트를 주는 업무들.
  • 중요도로 따진다면 업무 프로세스 효율화, 먹거리 찾기, 연구 성과 등등.

포인트는 “이유가 없다면 대부분의 업무는 위임하되 시급하고 중요한 업무의 경우는 리더가 책임지고 끌고 나가야 합니다.”
경험상으로 위임이 잘 안되는 경우는 문맥없이 위임을 하기 때문입니다.
그리고 관리자로서 당신의 업무는 문제를 시스템화 해서 효율적으로 문제를 푼다는 것을 잊으면 안됩니다.

쉽게 생각해서 카페를 운영하는데 직원들한테 모두 맡긴다고 돌아갈까요?
맡겨야 될 것들이 있고, 직접 챙겨서 할 것들이 있습니다.

1.2.2 질문과 명령을 몇대몇으로 하고 있는가?

저희 딸내미한테 장난감 청소하라고 시키면 잘 안합니다.
아마 하려고 했던 마음이 있었을지도 모르는데.. 이렇게 시켜버리면 기분이 나쁜수도 있어서 그런지 더 안하게 됩니다.
아니.. 자는척하고 더 안합니다. ㅋ
왜냐하면 명령을 함으로서 “자기 결정권”을 없애버렸기 때문입니다.

많은 리더들이 효율적으로 움직이기 위해서 경험상 가장 최적화된 솔루션을 하라고 시키는 케이스가 꽤 많습니다.
앞서 제가 비율을 말씀드렸는데.. 이렇게 명령으로 시키는 케이스가 지나치게 많다면..
결국 그 사람은 자기주도적으로 일하는 사람이 아니라.. 그냥 위에서 오더가 내려오면 일하는 사람이 되고 말아 버립니다.

이렇게 한번 해보세요.
문제의 해법을 찾는데.. (분명 리더가 정답을 알고 있다고 하더라도..)
팀원들에게 모두 포스트잇을 나눠주고 문제를 해결할 솔루션을 브레인 스토밍 해보는것도 좋습니다.

여러 팀원이 정말 색다르고 창의적인 솔루션을 제안할 겁니다.
여기서 매출에 바로 영향을 줄 수 있는 생각지도 못한 답안들이 나올 수 있습니다.

자~ 포인트는 “알고 있더라도 질문을 함으로서 팀원이 스스로 문제를 해결할 수 있도록 도와주세요”
스스로 문제를 찾았다고 생각한 팀원은 시켰을때 보다 2~3배는 더 큰 성과를 기대할 수 있을 겁니다.

1.2.3 Personal Management Interview (개인면담)

PMI의 목표는 몇가지가 있습니다.

  1. 회사와 개인의 방향 설정
  2. 어려움이 있는지, 요즘 좋아하는 것은 무엇인지 -> 요것도 방향 설정
  3. 지속적인 관심을 통한 성장 (A급 보다는 B급 C급과 더 많은 대화 필요)

1번 2번은 어떤 팀장이든지 누구나 잘하고 있을거라 생각됩니다.
3번이 매우 중요하다고 생각하며, 구체적인 PMI는 다음과 같이 합니다.

  1. 최소 1달에 한번은 반드시 PMI를 갖는다 -> 1달이 지나면 효과가 떨어짐
  2. 의제는 팀원이 선택하는 것이며, 팀원이 주도한다 (즉 팀장이 하고 싶은 말을 쏟아내는 자리가 아니다)
  3. A급 인원하고는 어차피 이래저래 말할일 많으니까, B급 C급 인원들이 절대 소외받지 않고 존중받는 생각이 들도록 더 많은 시간을 할애한다
  4. 밑바닥까지 팀원에 대해서 알기 위해서 끝났다고 생각됐을때 질문을 더 하라
  5. 듣고 흘리지 말고 적어두었다가 액션으로 나와야 한다

1.3 좋은 문화 만들기

1.3.1 심리적 안정감

심리적 안정감과 편안함은 구분되야 합니다.
편안함이란 동료들끼리 마냥 사이좋고, 친절하고, 하하호호 웃는 분위기를 말하는 것이 아닙니다.
제가 정의하는 심리적 안정감이란 “위험을 감수할수 있는 환경” 을 의미합니다.

심리적 안정감을 갖은 팀은 다음과 같습니다.

  1. 문제가 있는 발언 또는 껄끄러운 주제를 이야기 해도 무시받지 않고 치열하게 토론할수 있는 분위기
  2. 새로운 도전에 대해서 부정적이거나, 무식하거나, 무능력하게 보이지 않는 것
  3. 실수를 하면 100% 공유 가능하며, 개인의 문제가 아닌 시스템적으로 문제를 해결하려는 노력

사실.. 2번이 중요하다고 보는데, OKR의 높은 목표를 이루기 위해서는 당연히 높은 리스크 테이킹이 필요합니다.
실수 때문에 돈을 날렸고.. 그렇다고 인사조치가 된다면 -> 아무도 높은 목표를 이루려고 하지 않을 것입니다.

1.3.2 100% 공유 문화 / 문서화의 중요성

공유는 최대한 문서를 통해서 남겨두며, 공유의 이유는 다음과 같습니다.

  1. 각 포지션별 최대치의 권한과 책임을 갖기 위해서
  2. 회사의 방향과 목표를 맞추기 위해서
  3. 메인터넌스 (새로운 사람이 들어와도 빠르게 팔로업할수 있다)

1번의 경우는 이전 특정 윗사람이 주도해서 업무/지시가 내려오고 일이 진행되는 과정으로 이해를 해보겠습니다.
이 경우 모든 핵심적인 정보는 주도하는 그 윗사람이고, 전반적인 컨텍스트는 잘 공유가 되지 않으며,
각 팀마다 요구사항을 맞추기 위해서.. 참.. 이상한 방법으로 문제를 해결하게 됩니다. (그런데 돌아가! 그게 더 신기!)

완전히 반대로 되서, 각자 맡은 포지션에서 의사결정을 주도적으로 하고 책임을 지려면..
누군가 1명이 모든 정보를 다 갖고 있는게 아니라 다른 팀과 다른 동료는 어떻게 일하고 있고,
어떻게 협업이 될 수 있는지 공유를 받는게 매우 중요합니다.

1.4 효율적인 문서화 방법

1.4.1 위키 문서

위키의 경우 다음의 순서로 문서를 작성합니다.

  1. table of contents 가 가장위에 오게 합니다.
  2. 어떤 내용의 문서인지 작성합니다. 이유는 문서 상단에 어떤 문서인지 알아야 다름 팀원이 읽을지 말지 빠르게 결정내릴수 있습니다.
  3. 결론/결과을 작성해주세요. 팀원또는 다른 부서의 사람이 과정까지 알 필요는 없는 경우가 많습니다. 그냥 결과만 보면 됩니다.
  4. 경험을 공유 (특히 연구/개발의 경우 중요)
  5. 자세한 과정을 공유

포인트는 중구난방식의 서로 다른 유형의 문서형식이 아니라, 일관되고 빠르게 읽을수 있는 문서 형식입니다.
다시한번 강조하면 무슨 내용의 문서인지.. 그래서 결론이 뭔데.. 바로 나와줘야 합니다.

또 다른 핵심은 4번 입니다.
회사의 핵심 자산은 결과론적으로 다 만들어진 소프트웨어가 아닙니다.
Tensorflow로 만들어진 모델도 아니고, Spring으로 만들어진 서버도 아닙니다.
핵심 자산은 개발자의 만들면서 겪었던 그 경험입니다.
이걸 잘 공유하는 사람은 상장이라도 줘야 합니다.

하나의 예를 들자면 GAN 모델을 학습시키는데.. 계속 학습시키니까.. 이상하게 속이기 쉬운 데이터만 잔뜩 만들더라!
(네 GAN의 mode collapse 이야기 하는 겁니다.)
이런 경험을 사진 첨부해서 공유하면.. 오~ 왜 저런 현상이 일어날까.. 또 다시 다른 엔지니어에게 영감을 불어넣을수 있을 것입니다.

1.4.2 회의 문서

회의의 경우 다음의 내용이 반드시 있어야 합니다.

  1. Objective (목표) 가 명확하게 있어야 합니다.
  2. Key Results - 목표를 이룬다면 구체적으로 어떤 결과물들이 나와야 하는지 명시합니다.

포인트는 쓸때없는 회의 하지 말고, 회의 하게 되면 목표와 방향이 명확하게 설정되야 합니다.

1.5 프로세스 효율화

1.5.1 병목점 찾고 개선

팀장으로서 잊지 말아야 할 것은 시스템화 입니다.
먼저 프로세스 과정중에서 가장 시간이 많이 걸리는 부분을 리스트업 해놓고 문제를 해결해야 합니다.

저의 예를 들어보겠습니다.
모델에 들어가는 features를 만드는데 80%이상의 시간을 사용하고 있다면 이걸 해결하면 되는데..
Database에 따로 모델에 사용되는 features를 모델러가 사용하기 쉽도록 테이블로 정리해놓고, 일배치로 feature store가 만들어지도록 만들었습니다.

기존 복잡한 SQL query를 만들고, pandas에서 데이터 정제하고 원하는 matrix로 만들어주기 위해서 데이터 랭글링을 했다면,
feature store이후에는 쉽게 가져다 쓰는 구조로 변경이 되었습니다.
이후 모델링에 필요한 시간을 더 할애할 수 있었으며 연구분야에도 더 많은 시간을 갖을 수 있었습니다.

1.5.2 포스트 모템

특히 실서비스에서 문제가 발생했을때 잘못된 문제 해결은 실수한 사람에 대한 비난입니다.
(물론 그 사람이 빈번하게 문제를 일으킨다면.. 이야기는 다름.. 항상 이해해주는것이 덕목은 아닙니다.)
포스트모템 또한 문서로 전사에 공유를 합니다.

발생시간, 최초 알게 된 사람, 누가 대응을 어떻게 했는지, 등등 -> 핵심은 근원적 문제를 파악하는 것입니다.

어떤 병원에서는 약을 잘못 처방하는 사고가 간혹 일어났는데..
이로 인해서 수백억단위의 의료 분쟁이 일어났습니다.
포스트모템을 통해 문제가 일어나는 경위를 자세하게 살펴보니 약을 만드는 도중..
누군가 말을 걸거나.. 전화를 받는등의 업무로 인해 잘못된 약을 처방하는 일이 생긴다는 것을 알았습니다.
해결책은 약을 처방하는 약사는 노란색 조끼를 입히고, 절대 말걸거나 다른 업무를 시키지 않는 것이었습니다.
이후 사고는 급격하게 줄어들었습니다.

누군가를 비난하기전에 핵심문제를 파악하고 시스템적으로 문제를 푸는 것이 중요합니다.

1.5.3 Request For Comment

그냥 RFC라고 하며, 우버에서 사용중인 방법론입니다.
저는 우버 다닌 경험은 없고, 한국의 모 회사에서 FRD (functional requirements document) 프로세스를 경험한 적이 있습니다.
사람이 많거나, 프로젝트의 규모가 커질수록 효과를 발휘합니다.

RFC에 대해서 설명드리면..

  1. 일종의 문서
  2. RFC를 하는 이유는 실제 개발전 방향/요구사항/효율성등을 미리 검토하고 만들기 위함
  3. 아래의 내용이 들어 갈수 있습니다. (✓ 는 반드시 들어가야 함)
    • 무슨 프로젝트인지 ✓
    • 승인자 목록 ✓
    • 아키텍쳐 ✓
    • 요구사항 ✓
    • 제약사항 ✓
    • 서비스 SLA ✓
    • 서비스 의존성
    • 보안 고려 사항
    • TDD 리스트
    • 측정항목 및 모니터링
  4. 중요포인트는 이 문서를 관련된 모든 엔지니어에게 알리고 리뷰를 받음 (원래 회사의 모든 엔지니어게 알리는건데.. 지나치다고 판단됨)
  5. 중요 인원들에게는 반드시 리뷰 검토를 받아야 함 (팀장급, 시니어 개발자, 프로덕트 오너, PM 등등)

1.6 OKR (Objectives and Key Results)

미안하다.. 이거 말할려고 여태까지 썼다. ㅋ
간단하게 OKR에 대해서 소개하면 다음과 같습니다.

  1. OKR 핵심
    • OKR은 단순히 툴일 뿐입니다.
    • 높은 목표 -> 더 대담하고 큰 생각을 하기 위함
    • 목표설정 진행상황 모두 100% 공유 -> 탑다운으로 일하는 방식이 아니라 버튼업 방식
    • 포지션별로 책임과 권한 위임
    • 권한이 많은 만큼 -> 회사의 방향과 지속적으로 맞춤
  2. Objective
    • 목표는 누가봐도 “아~ 힘들거 같은데” 이런 목표로 잡습니다. (stretch goals 이라고 합니다.)
    • 도전적이고 정량적 평가가능한 수치를 제시해야 합니다. (예를 들어 “마케팅을 한다” X, “신규유저 20만 달성한다” O)
    • 높게잡는 이유는 훨신 더 높은 목표를 이루기 위해 더 대담하고 더 큰 생각과 커뮤니케이션을 하기 위함입니다. -> 생각 자체를 크게!
    • confidence level 사용 -> 0~10점 사용 하며, 7점은 프로젝트 완료가능, 10점은 목표까지 가능. (시작은 7점)
    • 데드라인이 설정되어 있어야 합니다. (이것도 원래 OKR에는 없는 내용이지만 뭐 항상 3개월 내내일을 하는 것도 아니고 하다보니 필요했습니다)
  3. Key Results
    • 목표에 대한 핵심 결과 지표 3개정도를 수립합니다.
    • 목표와 마찬가지로 매우 구제적이어야 합니다. (신규유저 달성을 위해 -> “트와이스를 섭외한다” O)
  4. Evaluation
    • 0~1점 사이의 점수를 사용하며, 0.7이면 업무를 잘 해냈다라고 생각하면 됩니다. 1점은 당연히 불가능한 목표수치를 해냈다! 입니다.
    • 만약 누군가 지속적으로 0.7 이상의 점수를 계속 받는다면.. 그 사람은 더 큰 목표와 생각을 갖도록 수정할 필요가 있습니다.
    • OKR은 직원 평가 지표가 아닙니다라고 구글에서는 말하지만.. 저는 0.7을 기준으로 직원평가까지 사용합니다.
      핵심은 도전적인 정신을 잃지 않도록 만드는 것입니다.
  5. OKR 운영 방법
    • 3개월 미만으로 운영이 되야 합니다. (스타트업의 경우 더 짧게 추천)
    • 지속적으로 변경/추가 등을 합니다.
    • 월요일에 1:1 미팅을 통해서 팀장은 팀원이 제대로 방향을 잡아서 가는지 확인
    • 금요일에 OKR 브리핑 미팅을 통해서 현재 진행되고 있는 상황을 공유
    • 금요일에 confidence level의 변화율에 대해서 이야기 하는 것 좋음 (7점 이하면 팀장 케어 필요)
  6. OKR 파티 (클로징 미팅)
    • 2~3개월 사이클이 한번 다 돌았을때 진행
    • 서로 성과를 발표하고 축하해주는 분위기 중요 (이야! 다돌았다!! 다들 수고했어!)
    • 3개월동안 얻은 지식이 무엇이고, 다음 3개월 무엇을할지 발표 (즉 클로징 미팅전에 미리 다음 분기 OKR 수립해놔야함)
    • 피자나 치킨이나 맥주한잔 하면 더 좋고 :) 다들 고생했으니까~

1.7 앤더슨의 빠른게 치고 나가는 개발 노하우

뭐.. 팀장급이면 딱히 새로운 내용 없을수도 ㅎㅎ
매우 주관적인 내용이 있다. 가려서 들으면 됩니다.

  1. 데드라인 설정
    • 각 테스크 마다의 데드라인은 개발자/연구원이 직접 정하게 한다
      • 쥬니어급: 일단 믿지 않는다. 3일 걸린다고 했으면 일단 마음속으로는 6일 이상 걸릴수 있다고 보면 됨. 열정이 많지만 경험이 부족해서 생기는 현상
      • 시니어급: 믿고가면 됨 (이 사람들은 알아서 버퍼 잡고 말해줌 -> 보통 더 단축해서 결과 나옴)
    • 사실 핵심은 내가 정하는게 아니라 정하게 만드는 것인데.. -> 책임감이 생김 (유이사님한테 배움 ㅋ)
    • 시간 일정 측정하는건 물론 애자일 프로세스처럼 모두 모여서 태스크 얼마나 걸릴지 논의하는것도 좋은데.. <– 굳이..
  2. 오래걸리는 작업 (이주일 이상 걸리는 작업) feat.머신러닝 엔지니어
    • 업무를 쪼개서 리스크 관리를 해야 한다. (한방에 큰게 빵! 들어가는 것 보다 작게 쪼개서 일정 밀리지 않도록 노력)
    • Feature store를 확보한다. -> 개발자가 feature 모두 만들게 하지 말고.. 만들어져 있는거 끌어다 쓰게 만든다.
    • 최악의 경우는 꼼수를 쓴다 (제대로 만들면 어려우나 언제나 쉽게 가는 우회로는 있다. 다만 코드가 지저분 해질뿐.. 어쩔수없다)
    • 사실.. 모델링에서 꼼수가 많은데.. 너무 공개하면 아시죠? 제 시크릿 레시피 입니다. 저도 먹고 살아야.. ㅎㅎ
  3. 지원 플랫폼
    • 누구나 쉽게 적용 가능한 사내 A/B 테스트 플랫폼 구축 -> 돈이 여기서 나옴
    • 빠르게 배포 가능한 파이프 라인 구축 -> 개발/연구에만 집중 (이건 뭐 다들 잘하고 있는 내용)
  4. 프로젝트 관리
    • 요구사항: 개발전에 다 확인 맡는다. (RFC참조) 매우 중요한데.. 안하면 나중에 다 만들어지고 어? 이거 아닌데.. 소리 들을수 있다.
    • 프로젝트 디펜던시 끊기 -> A가 만들어지고 B가 만들어지는게 아니라.. 그냥 동시에 작업할수 있게 dependency를 애초에 끊어버린다
  5. 기술
    • 애초에 쓰기 복잡한 덕후나 좋아하는 기술은 쳐다보지 않는다.
    • 제 기준에서는 Tensorflow 1.0은 사실상 deprecation이나 마찬가지 -> Pytorch, Keras 사용 추구 -> 왜? 쓰기 편하니까. 디버깅 쉬움
    • 아키텍쳐는 필요한 만큼 매우 작게 시작하지만 scalable 할수 있도록 만든다. (특히 DB쪽 TPS몰아치면 확장할수 있도록)
    • 항상 over engineering 을 조심한다 -> 개발자/연구원 태생이 그렇다. 작게 시작하도록 권유한다. -> 다만 미래시점에는 해야한다는 것도 인지 필요
    • 특히 대기업에서 온 사람들 조심: 회사에 맞지 않는 지나치게 큰 솔루션을 제안하는 케이스가 많다.
      (RDBMS로 할수 있는걸 굳이 하둡생태계 만들고 있으면 맞아야함. 아니면 그냥 BigQuery 쓰던가)
    • Code maintenance는 매우 중요하다. 시간이 걸리더라도 code를 제대로 짜놓고 가는게 오히려 나중에 커질수록 일관되게 개발을 할 수 있다.
    • 시작은 모방에서 시작한다. 안타깝지만 처음 시작은 이게 가장 빠르다. 다만 기술력을 계속 쌓아야 한다.
  6. 트와이스
    • 팬이다
    • 개발과 관계있다.
    • 었쟀든 관계있다.

1.8 반박자 빠르게. 그리고 지표의 중요성

이건 회사의 방향과 사실 밀접하게 연관되어 있습니다.
연구에 들어가는 투자대비 이익률이 포인트입니다.

개인적으로 딥러닝 연구/머신러닝 연구 등등.. 다양한 연구를 지지하고 좋아합니다.
다만 약간의 우려가 있습니다.

저는 소수의 인맥을 통해서 실제 딥마인드의 매출 사정이나 본사와의 갈등에 대해서 들었습니다.
(링크는 외부로 나온 내용이기도 하고, 저는 조금더 자세하게 내부 사정에 대해서 들어보기는 했습니다.)
AI를 통해 구글의 데이터센터 쿨링 비용을 40% 줄인것 에 대해서 매우 강조를 하고 있습니다.
(내부 이야기는 안하고 외부에 보이는 것만 말하면…) 쿨링 비용을 40%줄였으나 뉴스에서 말하지 않는것은 여기에 들어간 비용입니다.
실제 2018년 딥마인드의 손실은 5억 7000달러로 급증했고, 700명의 직원에게 2018년기준 약 4억 8300달러를 쏟아부었습니다.
그외에도 인프라 비용, 운영 비용, 스폰서쉽 비용 등등.. 많습니다.
주주 입장에서 생각해보면 이게 줄인거 맞나요?

그 유명한 보스턴 다이나믹스는 어떻게 됐을까요?
아시다시피 구글은 보스턴 다이나믹스를 소프트뱅크에 팔았습니다.
혁신적이었으나 결국 비즈니스와의 연계와 관련된 문제가 풀리지 않았습니다.

다른 예로 우버에서 3000명에 달하는 연구조직 인원 해고에 관해서도 주목할 필요가 있습니다.
물론 여러가지 이유가 있을 것입니다. 특히 코로나 바이러스로 인해서 매출급감으로 이어진것도 있겠죠.
그런데.. 미래 먹거리인 연구조직을 자른다? 음…. 생각해볼 문제인듯 합니다.

오해하지 않았으면 좋겠습니다.
이런 연구하시는 분들 매우 존경하고 있으며, 저 또한 실무에서 연구를 안한다는 뜻이 아닙니다. (연구는 중요합니다!)
다만 방식이 좀 다를 뿐입니다.
제 생각을 간단하게 정리 하면 다음과 같습니다.

  1. ROI: FANG + 카카오 + 네이버는 알아서 잘할거고.. 중소기업의 경우 투자 대비 이익에 대해서 고려가 필요합니다.
  2. 비즈니스 모델: 결국 비즈니스 모델과 연계가 중요.
    새로운 모델이 나와서 세상을 이롭게 하는건 알겠으나 실질적 성과로 이어지려면 비즈니스 모델과 연결이 되어야 함
  3. 대부분의 케이스: 대부분은 엄청난 AI모델이 없어도 비용대비 최적화 할수 있는 방법은 많이 있다 (심지어 구글 같은 곳도..)
  4. 반박자: 점진적 연구를 의미합니다. 처음부터 대단한 혁신이 아니라, 경쟁사 대비 아주 조금 더 혁신을 만들고 유지하는 것입니다. -> (가볍게! 당신은 엘론 머스크가 아닙니다)
  5. 제발 오해 금지: 연구하지 말라는게 아니라 혁신적인 연구이후의 방향성 그리고 점진적 방법이 중요하다는 뜻입니다.

저는 AI연구가 -> 실질적인 매출증대로 이어져서 -> AI가 더 활성화되고 연구 또한 더 활발해 졌으면 좋겠습니다.
그런데 간혹 보면 몇몇 회사들에서 그정도 규모가 아닌거 같은데.. 고비용의 모델에 투자하는 케이스들을 봤습니다.
그 특정 회사는 나름 AI를 한다고 주가를 꽤 올렸지만, 작년기준 실제 매출은 마이너스로 돌아섰습니다.
순수한 학문을 회사에서 진행하는 것도 좋지만, 그런 방향으로 진행을 함으로서 매출로 이어지지 않았을 경우..
또는 의도했던 예상 KPI에 도달하지 못했을 경우의 거기서 함께 일하고 있는 팀원들도 생각해 봐야 합니다.
(제가 결과만 보고 말씀드리는게 아니라.. 방향이 잘못 되었기에 여기에 씁니다.
자세하게 쓰면.. 어떤 회사인지 알기 때문에 더이상 적지 않겠습니다.
그렇다고 그 회사가 엄청난 기술 투자로 자율주행처럼 성장성 높은 문제를 푼것도 아닙니다)

제가 문제를 풀어내는 방법은 크게 다음과 같습니다.

  1. 반박자 빠르게: 목표는 경쟁사 대비 딱 반발자국 빠르게 입니다. <- 이것도 매우 어려워요
    구체적으로는 점진적 기술향상을 합니다. (ROI 중요)
  2. 지표: 정말 당연한거 같은데.. 넵… 지속적인 연구/성장을 위해서 조직장선에서 꼭 보셔야 합니다.

결론만 말하면.. 몸은 가법게 그리고 비즈니스와 연계된 한두가지의 목표/지표에 집중해서 달려야 합니다.

좀 공격적으로 썼는데.. 오해 없으셨으면 좋겠습니다.
연구를 하면 안된다가 아니라 마일스톤에 맞춰서 그리고 비즈니스 ROI를 고려해야 한다는 뜻입니다. -> 비즈니스 임팩트!
저도 연구를 해야 할때는 과감하게 가야 한다고 생각합니다. 그만큼 비즈니스에 중요한 것이겠죠.
물론 동의 안하시는 분도 계실거에요.
저와 좀 다를 뿐입니다.
논문 내고 인정 받는것보다, 실질적으로 성과 내고 제가 이끌고 있는 사람들 인센티브 받고 연봉 올려주는게 더 좋습니다.

마침

결국.. 위에 써놓은 것들은 이론일수 있고 그냥 이 친구는 이렇게 사는구나 이쯤 이해해주시면 될거 같습니다.

가장 중요한건 사람입니다.

Tensorflow 모델이나 Flask 같은 서버가 일을 하는게 아니라.. 사람이 하는 것입니다.

사람의 마음을 움직일수 있다면 사실.. 저런 개발 방법론이 무슨 필요가 있을까요? ㅎ

저도 아직 많이 부족하고, 많이 배워야 한다고 느낌니다.

읽어주셔서 감사합니다.~ :)

끝.