개발과 리서치, 기술과 고객의 문제
연구는 그렇게 하는게 아니야... 소비자는 당신 생각과 달라...
내가 이끄는 조직은 14명의 연구원들이 일한다. 올 초부터 6개월 이상 노력을 기울인 끝에 나름 구색을 잘 갖춘 인공지능 연구소가 꾸려졌다. 물론 경영층의 전폭적인 지원과 영입된 시니어 테크 리더들의 지원도 한몫 했다. 아쉽지만, 기초 연구를 할만큼 자금력 있는 회사는 아니라서 응용 또는 상용화 기술에 대한 연구개발을 주요 과제로 삼아야 했다.
꼭 필요로 하는 최소의 인원을 갖춘 덕분에 뭔가 새로운 시도를 하기 좋은 구조가 되었고, 올 하반기 부터는 나름 글로벌 기술 경쟁력을 갖춰 나가기 위해 도전적인 목표를 수립했고, 차근차근 기술개발에 속도를 내는 듯 했다. 몇 가지 의미심장한 발언들이 쏟아지기 전까지는, 그럭저럭 잘 굴러 가는 듯 싶었다.
"앞단에서 스펙이나 피쳐가 명확하게 정의 되야 다음 블록 설계가 가능해요."
챗봇을 설계하고 개발중인 개발자의 말이었다. 별다르게 나무랄 데 없다고 생각하는 사람들이 대부분이었다. 그저 나 혼자만 심각하게 고민하고 있었다. '이 친구는 연구원이었어야 하는데 개발자였구나... '
나는 그 연구원에게 지금까지 설계했던 챗봇 엔진의 다이얼로그 매니저를 문서화 하라고 지시했고, 그 친구는 어떻게 문서화 해야 하는지 물어왔다. 그 친구도 나름 진지하고 신중하게 문서를 작성 중이었지만, 갈피를 잘 못잡고 있었다.
"혹시, 리서치와 개발 업무의 차이점이 무엇인지 헤깔리나요?"
예상대로였다. 내가 데리고 일하는 사람들은 연구원들이 아니고 개발자들이었다. 연구원 대부분이 마인드 부터 행동까지 모두 개발자였다.
나는 바로 개발하던 내용을 모두 중단 시키고 챗봇을 개발하는 전체 인력과 함께 챗봇의 엔진 아키텍처를 다시 재설계하는 워크샵을 진행하기로 결심했다. 제일 먼저 필요한 것은 고객의 문제를 기술로 해결하기 위해 고객의 문제를 정의하는 것이었다. 흔히들 작성하는 PRD(Product Requirements Document)를 먼저 시작했다.
"이제, 모든 고객의 요구사항을 수집 정리해 봅시다."
연구원들은 수십개의 요구사항 항목을 수집해서 하나의 파일로 모두 옮겨 놓았다. 그 문서를 보는 순간 다시 한번 고민에 빠졌다. 요구사항의 많은 부분들이 기술적인 내용들이었다.
"왜 개발자의 언어로 요구사항이 적혀 있는거죠?"
열심히 요구사항 목록을 작성한 연구원들은 내가 괜한 트집을 잡고 있다는 듯 눈치를 슬슬 보기 시작했다.
"왜 고객의 요구사항인데, 문장이나 단어에 기술용어나 개발자 요구사항이 들어있는지 궁금합니다."
그들은 연구 업무가 어떤 것인지, 고객의 요구사항이 어떻게 작성되야 하는건지 전혀 알지 못했다. 그들은 개발만 해 오던 사람들이었고, 고객과 직접적인 만남이 거의 없던 사람들이었다. 잘 모르는 사람들에게 계속해서 잔소리 해봐야 그건 괴롭힘 밖에 더 하겠는가...
그래서 다음과 같은 내용으로 연구원에 대한 정의, 고객의 요구사항에 대한 정의를 설명해 나갔다. 별다르게 고민해 본 적이 없는 개발자들에게 내 얘기는 지루한 소설같은 이야기처럼 들렸겠지만 멈추지 않았다.
"연구원은 기존에 없는 방식이나 기술로 새로운 것을 만드는 비중이 높습니다. 구조화 되어 있지 않은 업무들이죠. 우리가 만드는 챗봇 엔진은 동작 방식이나 처리 순서, 제공되는 기능들이 기존 방식과 많이 다릅니다.
그래서 여러분들이 그토록 원했던 아키텍처 구성도, 레퍼런스, 시퀀스 다이어그램 같은게 제게는 없습니다.
제 업무 지시가 모호하다고 말하는 분도 계시고, 시스템 구조도를 연구소장이 줘야 하는거 아니냐면서 설계 리스크에 대한 책임을 아랫사람들에게 전가시키는거냐고 의심하시는 분도 계시죠.
새로운 것을 만드는 일인데, 여러분들이 요청하는 설계도가 만약에라도 저에게 있었다면, 제가 만들려는 그것은 새로운 것이 아니었을 겁니다.
그럼 제가 혼자 시스템 구조도를 그려야 할까요? 아니면 같이 그려 나가야 할까요? 물론 같이 그려 나가야 하죠. 어렵죠? 어려운 문제를 풀기 위해서 여기 모였으니까 당연히 어렵겠죠. 그러니 계속 어렵다는 말을 한다는건 우리가 제대로 된 일을 맡았다는걸 말해줍니다.
그리고, 저에게 자꾸만 뭔가 자료를 달라고 한다면 제가 드릴 수 있는건 없습니다. 우리는 리서치를 하기 때문입니다. 우리가 만들려는 챗봇엔진 구조도나 설계도는 해외 논문이나 기술서 어디에도 없는 내용이니까요.
여러분은 지금 자꾸만 개발 업무를 하려 하고 있어요. 정의된 스펙과 기능, 주어진 서비스 환경에서 구축해야 하는 개발 업무를 말이죠. 그것도 매우 숭고하고 중요한 일이긴 하지만, 우리 연구소가 일하는 방식과는 좀 많이 다릅니다.
새롭기 때문에 정해진 게 없고, 정해진게 없어서 수도 없이 설계도를 그리고 지우고 수정하고 고쳐보고 실험하면서 설계도를 완성시켜 나가야 하고, 필요하면 다시 새롭게 설계도를 그려봐야 하는게 리서치 업무 입니다. 자꾸만 동작 방식이 바껴서 코드를 수정해야 한다고 스트레스 받는 분들이 계신데요. 그게 맞습니다. 우리에겐 레퍼런스 삼을만 한 오픈소스도 없고, 참고할만한 데이터도 없어요. 새로운 방식이니까요.
여러분이 이렇게 아우성 치고 혼란스러워 하는 걸 보니 제가 세운 목표가 제대로 세워진게 맞네요. 하지만 일하는 방식을 리서치 업무에 맞게 바꾸셔야 합니다.
소비자 요구사항을 한번 봅시다. 요구사항에 개발자의 언어들이 잔뜩 들어가 있어요. 그건 개발자가 생각하는 요구사항이지 소비자가 원하는건 아니잖아요.
소비자가 그런걸 원할 것이라고 상상하고 요구사항을 적은 분들도 계시는데, 그건 상상이지 실체는 아니잖아요. 그런 부분들은 제외 시키는게 맞습니다. 소비자는 관찰하고 대화를 나눠 보면, 그들의 요구사항을 알 수 있는거지, 자신의 생각을 소비자의 대표 의견처럼 적어 놓으면 위험합니다."
"소장님, 저희도 나름 소비자인데, 저희 말도 맞지 않나요? 왜 위험하다는거죠?
"그건, 연구원님은 개발자 경험도 길고 개발자 성향이 강해서 한쪽에 치우치기 때문이에요. 본인 스스로 편향되어 있다는걸 인지하지 못하니까 위험하다는 것이죠. 편향되면 소비자가 원하지 않는 다른 방향으로 갈 가능성이 높습니다. 노키아가 스마트폰을 무시했다가 망했던 것처럼, 전문가 집단이 편향된 시각을 가지면 시류를 읽지 못하거나 소비자가 원하지 않는 제품을 내놓게 되는거죠."
"우리는 제품을 만드는게 아니잖아요. 그저 기술일 뿐인데 그게 그렇게 리스크가 큰가요?"
"우리는 연구소이고, 부품을 만드는 겁니다. 성능 좋은 훌륭한 부품을 개발팀에 넘기면, 개발팀은 그걸로 제품을 만드는거에요. 제품 기능은 결국 부품으로 부터 나오니까 부품을 만드는 철학이 중요한거죠. 소비자가 원하는 요구사항을 부품에서부터 만족시키지 못하면, 아무리 실력 좋은 개발자라도 엉터리 부품으로는 좋은 제품을 만들지 못해요. 우리는 부품을 책임질 의무가 있잖아요."
IT영역은 리서치와 개발 업무가 뒤죽박죽 섞여 있는 도메인 중 하나이다. 기술 트랜드가 너무 빠르게 흘러가고, 변화의 범위가 워낙 넓다 보니 논문으로 발표된 기술들이 바로 서비스나 제품에 적용 되기도 한다. 특히나 SW기술은 HW기술 만큼의 긴 상용화 과정을 건너 뛰고 바로 보급 되기도 한다.
그래서, 내가 뽑은 개발자들은 리서치와 개발의 차이를 이해하지 못했고, 앞으로도 이해하는데 시간이 많이 걸릴거 같다. 앞으로는 사람들을 뽑을 때 다음과 같은 질문과 검증이 필요할거 같다.
"당신은 구조화 되지 않은 업무,스스로 구조화 해야 하는 업무에 익숙한가요?"
"당신은 소비자를 잘 관찰하고 자신의 의견을 섞지 않을 자신이 있나요?"
