최근에는 다들 정신없어하는 AI로 무엇을 할 수 있고 무엇을 하면 안 되는 지를 고민해 볼 기회가 있었다. 관련 아티클도 읽고 강의와 워크샵들도 참여하기도 했다. 이렇게 보내는 시간 동안, 여러 가지 생각과 여러 가지 감정이 날뛰었다.
아마도 당분간은, 지금같은 바이브 코딩 기반에서 무엇을 더 잘 하는가, 어떤 경우에는 어떤 식의 에이전트 구성을 해야 하는가, 프롬프트를 어떻게 써야 하는가 같은 이야기들을 계속 접하게 될 것이다. 쏟아지는 이런 콘텐츠 사이사이 모델의 성능이라든가 이런 것도 되더라 같은 기술 정보들 역시 빠르게 쏟아질 것이다. AI에 대한 동경, 불안의 사이에서 아슬아슬 줄타기를 하는 잡음들 사이를 이리저리 피해 다니는 과정은 한동안 반복되지 않을까 싶다. AI가 빠르게 발전하는 것은 맞지만(그만큼의 리소스를 태우기도 하고) 사람들은 그 속도까지는 아니더라도 발전하려는 노력보다는 불안해지는 데에 속도를 더하고 있는 것만 같다.
여기저기에서 우리 직업은 없어질 것이다 같은 이야기가 툭툭 튀어나온다. 사실 데이터 분석가/과학자 망했다는 이야기는 그 전부터 하도 들어서 이런 이야기에는 별 감흥이 없다. 마치 저주마냥 무언가가 나올 때마다 ‘데이터 분석가/과학자 필요없네’ 소리 오조오억번 들어왔고, AI 처음 나왔을 때도 바로 공격받았던 건 데이터 분야였다. (지금은 데이터 분야를 괜시리 건드리던 상당수의 분들이 본인들 일이 더 급한 지 잘 안 보이는 것 같지만.)
하지만 놀랍게도 이 직업에도 이 직업이 가지는 본질이 있다. 예전에 쓴 여러 책에서 늘 이야기하는 것처럼, 결국은 ‘문제를 해결하는 것‘이라는 것. 데이터는 사실 이를 위한 가장 중요한 재료이기 때문에 이에 대해서 더 자세히 알아야 하는 것이고. 그리고 그 문제와 데이터를 이해하기 위해서는 결국 도메인을 빠르게 이해하는 능력이 필요하고, 나를 비롯하여 데이터를 많이 다루는 사람들은 데이터와 문제를 통해서 도메인을 더 잘 이해할 수 있다. 결국 도메인과 데이터/문제는 상호보완적으로 서로를 이해하는 데에 도움을 주곤 했다. 그리고 이를 익히다보면 도메인이 어떤 프로세스로 진행되고, 어디에서 어떤 데이터들이 생겨나며, 어디에서 적절히 끊어야 하고 어떤 것을 살펴봐야 하는 지를 익히게 된다. 이런 것이 경험이고 일종의 ‘일을 하는 근육’이었다.
최근 이것저것 AI를 사용해서 구현해보고 AI 에이전트 프로세스를 구성해보면서 어렴풋이 알게된 것이 있다. 좋은 결과물, 쓸만한 에이전트를 만드는 건 무조건적으로 화려하게 작성한 프롬프트도 아니었고, AI에 대한 동경도 아니었으며, 무조건적인 최신 모델이 답인 것도 아니었다. 물론 각 AI 서비스별로 약간의 구조 차이라든가 강한 점들이 있고 이를 이해하여 프롬프트에 녹여내는 것도 꽤 쏠쏠한 팁이다. 하지만 이것은 결국 AI 서비스가 발전함에 따라 또 달라질, 한시적인 기술이다.
이것저것 케이스를 만들고 이를 실제 단계로 만들어 나가는 데에서 차별점을 만들어내는 것은 결국 적절한 데이터 활용과 문제 해결 프로세스였다. 문제의 추상화-실행 워크플로우를 어느 레벨로 나눠야 하는지, 단계별로 도메인 지식을 바탕으로 적절한 제약 조건을 설정하는 것, 어느 단계에서 어떤 데이터 검증이 필요한 지를 잘 설계하는 것, 결국 이런 게 결과물의 지속가능성과 품질을 결정한다. 여기서도결국 필요한 것은 ‘문제 해결 과정’ 을 잘 설계하는 것이었고 이를 위해 빠르고 깊은 ‘도메인 이해도’가 중요했다. 다행히도 그간 꾸준히 길러온 일하는 근육은 쓸모없는 것이 아니란 생각이 들고, 나 역시 완전히 놓지 못하던 동경, 불안 같은 감정들은 역시 손으로 조금이라도 만져보고 뜯어보면서 점점 낮아졌다. 다행스러운 일이지 않은가. 결국 동경은 이해로부터 가장 먼 감정이다.
(TMI: 사실 최근 전혀 다른 이유로 이 대사가 생각나서 써먹고 싶었다 « )
AI는 굉장히 똑똑하고, 많은 도움이 된다. 하지만 현재까지는-아마도 앞으로도 제대로 이를 활용하기 위해서는- 결국 내가 무엇을 필요로 하는 지를 확실하고 자세하게 명시해야 이를 지속하는 데에 도움을 줄 수 있다. 내가 하는 어떤 질문에 다각도로 답을 찾거나, 이를 실제로 구현하는 데에 도움을 주지만 결국 그 질문을 제대로 하고, 이를 단계적으로 꼼꼼하게 구성하는 것은 사람이 해야 할 일이다. 그리고 이에 필요한 것은 ‘문제 정의 및 해결 방안 수립’ 과 ‘도메인에 대한 이해’ 다.
AI에 대한 척수반사적 동경과 불안으로 인해 무언가라도 직접 만들어야겠다며 자랑스럽게 내놓는 상당수의 것들은 해당 당사자들의 감정에 대한 위안 정도밖에 되지 않는다. 이런 것들이 너무 많아 산만하기만 하고, 사실 그런 것들은 중장기적으로 어디에도 그다지 도움이 되지 않을 것이라는 생각만 든다.
오래 전 대학 어떤 산업공학과 수업 프로젝트를 하면서, 교수님께서 대략 이런 말씀을 하셨다(오래 전이라 정확하진 않으나 대충 이런 맥락이었다). ‘이게 현재 우리가 구현할 수 있는 지를 따지는 것도 굉장히 중요하지요. 하지만 이 프로젝트에서는 지금 당장 만들어서 내놓아야 하는 거를 구상하는 것이 아닙니다. 논리적으로 이걸 만들어서 사용하는 데 문제만 없다면 언젠가는, 혹은 좀 더 리소스가 있다면 만들 수 있는, 그런 것을 구상하는 프로젝트입니다. 이런 프로젝트는 현재 제약상황이 변하는 어떤 환경에서도 할 수 있지요’
그 당시에도 이 말씀에 대해서 장단점을 생각했고, 가끔 너무 이상론만 펼치는 사람들을 만날 때, 혹은 무조건 안된다는 이야기를 들을 때 가끔 이 이야기가 생각이 났다. 그 이후 세상은 많이 발전했고 AI로 이런저런 것을 시도해보면서 이 때를 다시금 생각한다. 현재의 기술을 꾸준히(물론 너무 깨알같이 모든 걸 다 할 필요는 없다고 생각하지만) 따라가면서, 문제의 바탕(도메인)을 잘 이해하고 프로세스를 잘 만들 줄 아는 것이 어떤 기술 배경에서든 이를 활용하는 것 시작점일 것이다.