달고나 49. 미래를 위한 준비
Asking & Prototyping
50번째 글이다. 옛날 개발자답게 0부터 시작해서 50번째가 맞다. 아이러니지만 50번째는 데이터나 알고리즘에 관한 글이 아니다. 모두를 위한 글이지만 또 그 누구를 위한 글도 아니다. 귀 있는 자는 들을 것이고 그렇지 않으면 그냥 괘변으로 무시해도 좋다.
많은 책을 읽고 매일 새로운 정보를 습득하지만 머릿속에 오랫동안 계속 여운으로 남는 것은 별로 많지 않다. 집중하지 않고 의무감으로 글을 읽어나갔기 때문이라 자책도 하지만 나를 감동시키지 못한 저자들의 잘못도 없지 않다. 그렇게 위로한다. 지난 긴 시간 동안 나의 관심 주제는 과거와 현재 그리고 미래를 연결하는 흐름 (트렌드)였다. 역사와 전기, 트렌딩 기술과 서비스, 그리고 미래의 먹거리를 다룬 책이라면 어김없이 구매해서 읽는 편이다. 관심의 폭이 넓은 편은 아니다. 과학과 기술이 중심이고, 그 외에 경제와 사회를 거시적으로 통찰한 저작물에 늘 끌리는 편이다. 사람은 누구나 결코 이뤄지지 않더라도 미래에 관한 것엔 늘 호기심이 발동한다. 오늘날에도 점집이나 도사들이 여전히 성행하는 데는 다 이유가 있다. 풍수가 중요하고 공간이 의식을 지배한다고 하지 않았는가?(먼산)
지식의 깊이나 경험의 폭이 그리 대단치는 않지만 오랫동안 그리고 최근에 더더욱 관심을 사로잡는 주제는 ‘질문하기 Asking Questions’와 ‘빠른 실행/구현 Fast Prototyping’이다. 다소 이질적이지만 이 둘을 연결하는 것은 ‘미래 Futures’다. 다양한 관점으로 질문을 던져서 그럴듯한 미래의 모습/시나리오를 찾고 그걸 빠르게 구현해서 합당성을 검증하며 전진하는 것이 미래를 준비하는 가장 바람직한 자세가 아닌가 생각한다. Allen Kay가 말한 ‘미래를 예측하는 가장 좋은 방법은 미래를 창조하는 것이다. The best way to predict the future is to invent it.’라는 문구는 앞으로도 여전히 유효하다.
아래에 도식화한 것처럼 크게 (최소) 3 가지로 질문을 유형화할 수 있다. 회고형 질문, 문제해결형 질문, 그리고 문제정의형 질문이다. 회고형 질문은 말 그대로 과거의 일, 즉 이미 기록된 것들이 왜 일어났고 어떤 경로로 진행해서 어떻게 결론 났는지를 복기하는 거다. 역사에서 가정(if)은 무의미하다고들 하지만, 다양한 가정 하에 조건을 바꿔가며 과거를 시뮬레이션하는 거다. 마치 부족한 데이터를 augmentation 해서 샘플수를 늘리듯이 하나의 사건을 다양한 관점에서 해석하고 다양한 가정들로 새로운 과거를 만들어서 직접 경험할 수 없었던 경험을 하게 하는 거다. 역사가 완전히 똑같이 반복되지는 않지만 비슷한 상황이 발생했을 때 적절히 사용할 수 있다. 지난 글이 ‘그때는 맞고 지금은 틀리다’였는데…(^^)
문제해결형 질문은 현재 맞닥뜨린 문제를 해결하기 위해서 다양한 관점에서 문제의 본질을 파고 들어가서 적당한 답 또는 실행안을 찾아가는 거다. 때론 문제 자체가 합당한가?부터 의문시해야 한다. 여러 글에서 밝혔듯이 나는 기계적으로 어떤 알고리즘이나 솔루션을 적용하는 것에 매우 부정적이다. 비록 그게 가장 좋은 방법일지라도 자기 발전, 성장을 위한 경험치를 쌓을 수 없다. 아래의 ‘빠른 실행’과 다소 배치되는 것 같지만 여러 가능성들을 검토하며 하나하나 실행해보는 것과 그냥 무턱대고 ‘묻고 더블로 가’는 완전히 다르다. 여러 관점에서 문제의 본질은 무엇이고 어떻게 해결할 것인가에 관한 질문하는 습관은 분명 데이터 과학자로의 성장에 큰 도움이 될 거다.
마지막으로 — 사실 이걸 위한 긴 서론이었다 — 문제정의형 질문은 ‘과연 미래는 어떤 모습일까?’를 묻는 거다. 단순히 ‘어떤 모습일까?’를 묻는 것이 아니라 Allan Kay의 말마따나 미래를 정의하는 질문이다. 미래에 관한 옳은 질문 후에 합당한 답을 찾았다면 그게 바로 미래다. 예측보다 확실한 창조인 셈이다. ‘축적의 시간’으로 알려진 서울대 이정동 교수의 신간 ‘최초의 질문 Original Question’도 미래를 정의할 물음에 관한 것이고, ‘눈 떠보니 선진국’에서 주장하는 바도 결국 아직 아무도 가보지 않은 미지(의 미래)를 해쳐나가기 위해서 우리는 미래를 어떻게 정의하고 나갈 것인가?를 묻는 거다. 개인 페이스북 페이지 (https://www.facebook.com/unexperienced)의 제목이 Unexperienced인 이유는 ‘Unexperienced Pasts’에서 Pasts를 제거한 거다. 현재까지 전혀 경험해보지 못한 과거, 즉 로그 스케일로 변하는 시대를 살고 있다. (to make a long story short) 1,000년, 100년, 10년, 1년 전의 일반 대중의 삶이 어떻게 달라졌는지 생각해보면 된다. 1천년 전의 우리 조상들은 몇 백 년 후의 후손의 모습을 쉽게 상상할 수 있었겠지만, 요즘은 1년 뒤의 모습도 상상하기 어렵다.
우리가 미래를 창조하기 위해서 먼저 미래를 정의할 질문을 던져야 한다. 미래에도 여전히 비교우위, 아니 절대우위를 갖는 유일한 원천 기술을 얻는 방법은 문제를 정의하는 질문에서 나온다. 안타깝게도 나도 어떤 질문을 해야 하는지 모른다. 그래서 조금이라도 공감이 된다면 같이 찾아봤으면 좋겠다. 질문도 어렵지만 답도 만만치는 않을 거다.
사람들에게 각자가 상상하는 미래의 모습을 말해보라 한다면 대부분은 현재와 다른 점을 나열할 거다. 그러니 당연히 ‘미래는 어떻게 바뀔 것인가?’가 좋은 질문일까? 오랫동안 나도 그렇게 생각했던 것 같다. 아마존 창업자 Jeff Bezos는 나와 다른 사람임을 깨닫는다. (그가 물리학과로 진학했지만 천재 동기를 보고 진로를 변경했다는 일화는 유명한데, 천재가 생각한 천재의 모습이 쉽게 상상 가지 않는다.) 아마도 TED 강연에서 사람들이 베조스에게 ‘5년/10년 뒤의 세상은 무엇이/어떻게 변할까요?’라는 질문을 자주 하는데, 그는 ‘5년/10년 뒤에 무엇이 변하지 않는가?’에 고민, 집중한다고 말했다. 예를 들어, 사람 간의 커뮤니케이션은 "방문 — 서신 교류 — 전신 — 전화 — 메신저" 순으로 변화(발전?)해왔다. 그런데 이런 변화 속에서 우리가 쉽게 놓친 점은 수단은 계속 바뀌었지만 여전히 커뮤니케이션의 필요는 그대로라는 점이다. 미래에는 뇌파를 읽어서 텔레파시를 보내는 기계로 대화할지도 모르지만, 여기서 중요한 점은 미래에서 여전히 대화를 한다는 거다. 미래에도 여전히 바뀌지 않는 것이 무엇인지를 찾았다면 그것의 변형된 형태를 찾는 건 다소 쉬울 수 있다. 그래서 사람들에게 농반진반으로 인간의 ‘생과 사’와 관련된 일을 찾아보라고 권한다. 미래에도 여전히 수많은 사람들이 태어나고 죽을 테니 그와 관련된 일은 없어지지 않을 거다. 미래에는 데이터 과학자도, 딥러닝 알고리즘도 필요 없어질지도 모른다. 학위를 받을 즈음에는 SVM이 대세였는데 지금은 딥러닝의 시대다. 10년 후에도 여전히 딥러닝의 시대라면 재미없을 것 같다. 대학에 들어갔을 때 C언어를 배웠다. 몇 년 후엔 유수의 대학에서 C 대신 Java를 가르친다는 얘길 들었는데, 요즘은 파이썬이다. Java 기반의 서비스들이 여전히 많지만 20년 전의 Java가 아니다. 모델, 언어, 라이브러리와 프레임워크는 계속 바뀌지만 여전히 지금도 모니터 앞에서 코딩을 하고 있다. 코딩하는 것도 언젠가는 역사가 되겠지만... 끊임없이 변하는 미래에도 여전히 살아남기 위해서 미래에도 여전히 변하지 않는 것이 무엇인지 알아야 하고 준비해야 한다. 변화에 민감해야 하지만 옳은 방향에는 둔감해야 한다.
옳은 질문엔 수많은 가능한 답들이 따른다. 전혀 아닌 것들도 있겠지만, 어떤 가능성이 가장 좋은지 아무도 모른다. 그렇다고 느긋하게 기다릴 수도 없다. 그렇기에 가능성들에 우선순위를 두고 하나씩 시도해보고 맞는지 틀렸는지를 빠르게 검증해야 한다. 가능한 빠르게 프로토타이핑을 해보고 더 확장할지, 아니면 방향을 수정할지, 그것도 아니면 중단하고 새로운 가능성을 도전해볼지… 빠르게 구현하고 빠르게 실패해야 한다. 궁극의 방향을 모른다면 빠른 실패가 가장 빠른 성공의 길이다. 한 시간, 하루, 일주일, 보름, 한 달, 두 달, 6개월 등… 문제와 솔루션의 경중에 따라 주어진 시간은 모두 다르겠지만 가능한 빠르게 확인해봐야 한다. 아닌 것에 너무 많은 리소스를 들이는 것만큼의 낭비는 없다. 그런데 이런 fast prototyping이 가능하려면 우리는 우선 기술적으로 완벽히 준비돼있어야 한다. ‘Hello, World’도 찍어보지 않은 개발자(?)가 프로토타이핑을 할 수는 없다. 파이썬, 아니 엑셀도 모르는 이에게 빨리 데이터를 확인해서 인사이트를 가져오라고 닭달하는 건 미친 짓이다. 아이디어가 떠오르면 최대한 빨리 가능성을 확인하고 그 후에 더 크게 키우면 된다. 완벽한 준비와 적절한 타이밍 중에 고르라고 한다면 나는 후자를 선택하겠다.
지금 조직에서 문제 정의하기와 패스트프로토 프랙티스를 어떻게 구현할 수 있을까?
