내가 20대 초, 한 기업에서 채용 인터뷰를 했을 때 일이다. 그 회사의 CEO가 내게 얼마나 받고 싶으냐고 물었다. 나는 속으로 민망하다는 생각이 들 만큼 큰 액수를 조심스럽게 불렀다. 그러자 그 CEO는 그 자리에서 계약서를 쓰면서 내가 말한 액수에 10%를 더 얹어줬다. 사람들은 "소프트웨어 엔지니어"가 가진 기술을 높게 평가했다. 한 회사에서 일할 때는 직원 하나가 힙챗(HipChat, 슬랙과 비슷한 메신저)을 사용해 사내 소프트웨어 엔지니어에게 질문을 했다가 "엔지니어에게 직접 질문하지 말라"는 문책을 받는 것도 봤다. 프로그래머의 소중한 시간을 뺏지 말라는 거였다.

메타의 직원들 (이미지 출처: Business Insider)

이자율이 0%에 가까웠고, 테크 업계가 폭발적으로 성장하던 시절이었다. 이때 우리가 알고 있는 업계의 관행이 생겨났다. 구글 같은 기업들을 시작으로 코딩하는 사람들에게 커피와 식사를 무료로 제공했고, 세계 최고 수준의 의료 서비스, 출산 휴가, 각종 장비가 갖춰진 운동시설, 캐주얼 드레스코드가 당연시되었다. 거기에 더해 근무 시간의 20%를 일과 무관하게 자기가 원하는 일에 쓸 수 있게 해주는 제도도 생겨났다. 그뿐 아니라 그들이 가진 기술은 중요하고 쉽게 다칠 수 있는 거라고 생각한 나머지, 이를 둘러싼 일종의 미신 같은 비슷한 게 있었다. 가령 특정 작업을 완성하는 데 드는 시간을 예상하는 건 어리석은 태도라는 생각이 그렇다. 프로그래밍을 하다 보면 예상치 못했던 문제가 튀어나오기도 하고, 온갖 버그가 발견되기도 하니 데드라인을 정하면 안 된다는 것. 코딩을 하던 직원이 할당된 작업을 마치는 데 너무 큰 압력을 받는다고 느끼면 "번아웃(burnout, 탈진)"이라는 말만 해도 몇 달의 시간을 벌 수 있었다.

이런 추세가 등장하자마자 나는 뭔가 잘못되었다는 생각이 들었다. 우리가 하는 일이 그토록 소중한 건가? 이런 활황이 얼마나 지속될까? 나는 십 대 시절에 웹디자인으로 돈을 벌었다. 그 당시만 해도 웹디자이너를 구하기 쉽지 않았고, 웹디자이너를 대단하게 생각했다. 주말에 열심히 일하면 몇천 달러를 벌던 시절이다. 그러다가 스퀘어스페이스(Squarespace) 같은 서비스가 등장해서 피자집 사장이나 프리랜서 아티스트도 클릭 몇 번으로 웹사이트를 만들 수 있게 되었다. 전문적으로 코딩을 하던 사람들의 경우 별로 힘들이지 않고 큰돈을 벌 수 있는 종류의 일감은 자취를 감췄다.

이런 상황 변화에 대해 프로그래머 커뮤니티에서는 "스킬(기술)을 계속 업그레이드하라"고 조언했다. 어렵고 흔하지 않은 기술을 배우라는 것. 문제는 소프트웨어 엔지니어라는 족속이 기본적으로 자동화를 좋아한다는 사실이다. 그러니 가장 뛰어난 소프트웨어 엔지니어가 다른 엔지니어의 직업을 없애는 도구를 만들어 내는 결과가 불가피하게 일어난다. 사실 프로그래머들이 좋은 대접을 받았던 이유가 이거다. 소프트웨어 하나가 수백만 명의 일에 영향을 줄 수 있기 때문이다. 프로그래머가 스스로를 대체하는 프로그램을 만들어 내는 건, 그래서 자연스러운 일이다. 이런 변화의 물결이 밀물처럼 다가와 우리 발이 젖을 수 있으니 스킬을 업그레이드하면 마른 땅에 서 있을 수 있다는 건 훌륭한 조언이지만, 쓰나미가 온다면 얘기가 다르다.  

(이미지 생성: Stable Diffusion XL)

내가 일하는 회사에서 프로그래밍의 보조 역할로 AI 챗봇을 사용해도 된다고 허용했을 때도 나는 사용하지 않고 버텼다. 나는 내 동료들도 나처럼 AI 챗봇 사용을 거부했으면 했지만, 시간이 지나면서 사무실 모니터에서 챗봇 창이 열려있는 건 점점 더 자주 보게 되었다. AI 챗봇을 사용하면 생산성이 올라간다는 말을 자주 들었고, 경우에 따라서는 열 배나 빨리 문제를 해결할 수 있다는 얘기도 있었다.

하지만 내가 그런 생산성을 원하는지 확신할 수 없었다. 나는 프로그래밍 작업 자체를 즐기고, 내가 쓸모 있다고 느끼고 싶다. 코드를 살펴보거나 보기 좋게 정리할 때 사용하는 텍스트 에디터처럼 내게 익숙한 도구들은 이 두 가지 욕구를 모두 충족시켜 준다. 프로그래밍을 더 잘하게 해주고, 작업 시간을 단축시켜 주지만, 이 작업은 내가 한 작업이라는 만족감을 준다. 반면 AI는, 적어도 사람들이 말하는 게 맞는다면, 다른 것 같았다. 프로그래머에게 도움을 아주 많이 줬다. 나는 AI를 프로그래밍 보조로 사용할 경우, 퍼즐을 푸는 재미를 내게서 뺏을 뿐 아니라, 내가 풀었다는 만족감도 뺏어갈 것으로 생각했다. 그걸 사용해서 나의 생산성이 무한하게 늘어날 수도 있겠지만, 내가 내놓을 수 있는 건 그저 결과물뿐일 것이다.

대부분의 프로그래머가 하는 작업은 그렇게 신나는 일이 아니다. 솔직히 말하면 거의 우스울 정도로 단조로운 작업인 경우가 많다. 몇 달 전 나는 회사에서 돌아와 아내에게 "오늘은 회사에서 유난히 재미있는 문제와 씨름하게 되어 무척 즐거웠다"라고 했다. 나는 그때 표(table)를 생성하는 프로그램을 만들고 있었는데, 누군가 표의 세로단(column) 하나보다 더 긴 헤더(header)를 추가하도록 해달라고 주문했다. 우리 회사에서 만든 프로그램으로는 그렇게 할 수 없게 되어 있었다. 게다가 긴급하게 처리해야 할 사안이었다. 중요한 문서에 사용될 표였고, 중요한 사람들의 요청이었다. 그래서 나는 그날 오후의 대부분을 비워두고 빈 회의실에 들어가서 문제 해결에 매달렸다.

그 요청을 해결하기 위해서는 먼저 많고 재미있는 하위 문제들을 먼저 해결해야 했다. 우리 레이아웃 엔진의 사용자가 세로단을 가로지르는 헤더를 만들고 싶다는 것을 어떻게 요청하게 할까? 그들이 사용할 코드를 어떻게 만들게 할까? 게다가 무시했다가는 버그를 일으킬 복잡다단한 요소들이 있었다. 예를 들어 헤더가 들어가야 할 세로단이 데이터가 없다는 이유로 빠져버릴 수도 있다. 나는 펜과 노트패드를 꺼내 들고 이런 다양한 시나리오를 그리면서 내가 세운 로직을 확인, 재확인했다.

나는 이런 작업을 무척 좋아한다.  

하지만 그날 내가 한 일을 멀리 떨어져서 바라보면? 표에 새로운 종류의 헤더가 하나 생긴 거다. 세상에 이보다 단조로운 일도 찾기 힘들 거다. 하지만 내게는 그 결과물이 아니라 프로세스 자체가 즐거움이었다. 그런데 챗GPT와 3분 정도 대화를 주고받아서 이 문제를 해결한다면 어떨까?  

물론 프로그래머가 하는 일은 단순히 코드를 작성하는 것 외에도 많다. 새로 들어온 주니어 엔지니어들을 코칭하고, 높은 단계의 시스템을 설계하는 일 같은 게 그렇다. 하지만 그런 모든 일의 뿌리에는 코딩이 있다. 나는 프로그래머로 일해오는 동안 바로 그렇게 작은 프로그래밍 문제를 해결하기 위해 채용되곤 했다. 그런데 어느 날 갑자기 그런 능력이 덜 중요해지게 된 거다.

(이미지 출처: The Keyword)

벤은 내게 GPT-4를 이용하는 게 얼마나 편리한지 열심히 설명했다. 그런데 알고 보니 AI는 그렇게 작은 문제들만 잘 풀어내는 게 아니라, 시니어 엔지니어의 역할도 수행할 수 있었다. 풍부한 지식의 창고를 기반으로 문제를 푸는 방법을 제시하는 것이다. 예를 들어 이런 일이 있었다. 벤은 영국에서 온 친구에게 줄 선물을 만들고 있었다. 영국 찰스 3세 국왕의 초상이 들어간 액자에 LED 전구와 스피커를 부착한 건데, 이를 위해 웹사이트를 하나 만들고, 이 웹사이트에 들어가 메시지를 작성하면 그 내용이 모스 부호로 전환되어 액자에서 빛과 소리로 나오는 거다.

그런데 벤은 그 장치가 새로운 메시지를 가져오게 하는 프로그램을 만들 재주가 없었다. 그가 주로 사용하는 마이크로컨트롤러만이 아니라, 메시지를 저장하는 백엔드 서버의 파이어베이스(Firebase)에 대한 전문 지식이 필요해 보였다. 벤은 내게 조언을 구했고, 나는 가능한 방법을 몇 개 이야기했지만, 솔직히 말하면 그가 원하는 게 가능해 보이지 않았다. 그러다가 벤이 GPT-4에 그 질문을 했고, AI는 벤에게 파이어베이스가 벤의 프로젝트를 훨씬 더 간단하게 해결해 줄 수 있다며 마이크로컨트롤러와 호환되는 코드를 만들어 주었다.

나는 GPT-4를 사용해 보고 싶었지만, 여전히 직접 사용하기가 꺼려져서—그리고 그걸 사용하는 데 한 달에 20달러를 내는 게 좋게 보이지도 않았다—벤을 통해서 GPT-4의 기능을 확인해 보기로 했다. 벤과 함께 십자말풀이 프로그램을 만들면서 내가 "프롬프트(명령어)를 이렇게 바꿔 보면 어때?"라고 말하면 벤은 "그러지 말고 네가 직접 써 보라니까?"라고 키보드를 내밀었고, 나는 "아니, 운전은 그냥 네가 해"라고 대답하곤 했다.

그렇게 함께 일하면서 AI가 할 수 있는 일이 무엇인지에 대한 감이 오기 시작했다. 나보다 GPT-4를 더 많이 사용했던 벤은 한 번에 정확한 프롬프트를 입력하는 것 같았다. 내가 그 얘기를 했더니 벤은 자신의 신경망이 GPT-4와 일치(align)하기 시작한 것 같다고 했다. 앞서 말한 '기계와의 공감(mechanical sympathy)'에 도달한 것으로 보였다. 내가 특히 감탄했던 건 벤이 AI를 이용해 뱀 게임(snake game)을 만들었을 때다.

옛날 노키아 폰에 기본으로 들어가 있던 그 게임 말이다.

뱀 게임을 만든 벤은 GPT-4와 대화를 나누더니 게임에 질 경우 플레이어가 가장 효과적인 이동 경로에서 얼마나 벗어나 있었는지 보여주는 기능을 넣었다. AI가 이 기능을 만드는 데 걸린 시간은 약 10초였다. 솔직히 고백하면 나는 그 기능을 만들 자신이 없다.

AI가 이미 수십 년 전에 평정한 체스의 경우, 플레이어가 승리하려면 봇(AI)와 한 팀을 이뤄야 한다. 이렇게 인간과 AI가 결합한 팀을 체스에서는 '켄타우로스(centaur, 상반신은 사람, 하반신은 말인 상상 속 종족)'라 부르는데, 이렇게 결합한 팀은 가장 뛰어난 인간 플레이어와 가장 뛰어난 AI 플레이어를 모두 이길 수 있다. 프로그래밍은 아직 체스가 걸어간 길을 가지 않았다. 하지만 켄타우로스는 이미 우리에게 찾아왔다. GPT-4 혼자만으로는 나보다 프로그래밍 실력이 떨어진다. 벤의 프로그래밍은 그보다 더 떨어진다.

하지만 벤과 GPT-4가 만나면? 무서운 존재가 된다.

로마 하드리아누스 황제의 빌라 벽화 속 켄타우로스의 모습 (이미지 출처: following hadrian)

오래지 않아 나는 결국 굴복했다. 나는 회사에서 작은 검색 도구를 만들다가 검색 결과에서 사용자가 검색한 것과 일치되는 부분이 하이라이트 되는 기능을 넣고 싶었다. 하지만 나는 검색어를 단어별로 분리하고 있었고, 이게 문제를 복잡하게 만들었다. 인내심이 바닥난 내게 GPT-4를 사용할까, 하는 생각이 들었다. 오후 내내 이걸로 씨름하는 대신 프롬프트를 몇 번 다듬으면, 즉 AI와 대화를 좀 나누면 해결될 문제처럼 보였다.

컴퓨터 공학자 에츠허르 다익스트라(Edsger W. Dijkstra)는 1978년에 쓴 "'자연언어 프로그래밍'의 어리석음에 대하여(On the Foolishness of 'Natural Language Programming')"이라는 글에서 만약 컴퓨터에게 C++나 파이썬(Python) 같은 전문화된 프로그래밍 언어를 사용하지 않고 인간의 말(자연언어)로 지시를 내릴 경우 컴퓨터를 유용하게 만드는 정확성을 희생하게 될 것이라고 주장했다. 그는 프로그래밍 언어가 "놀랍도록 효과적인 도구이기 때문에 우리가 자연언어를 사용할 때 불가피하게 들어가는 각종 헛소리(넌센스)를 모두 없앴을 수 있다"라고 했다. 다익스트라의 주장은 프로그래머들 사이에서 불변의 진리로 받아들여졌다. 그 글이 2014년, 레딧에 다시 등장했을 때 가장 많은 '좋아요'를 받은 댓글은 이거였다. "나는 그의 생각이 사소하게 느껴질 정도로 당연하다는 것과 많은 사람들이 여전히 그걸 모른다는 사실 중에서 어떤 게 더 무서운 건지 모르겠다."

나는 GPT-4를 처음 사용하면서 다익스트라가 하려고 했던 말이 뭔지 이해할 수 있었다. 우리가 AI에 "내 문제를 풀어줘"라고 말한다고 문제가 풀리는 게 아니다. 그런 날이 올 수도 있겠지만, 적어도 지금의 AI는 어떻게 연주법을 익혀야 하는 악기에 가깝다. 우리가 원하는 게 뭔지를 조심스럽게, 초심자에게 이야기하듯 정확하게 말해줘야 한다. 나는 검색 결과를 하이라이트 하는 기능을 얻기 위해 처음에는 GPT-4에 너무 많은 것을 한 번에 요청했고, 원하는 결과를 내놓지 못하는 것을 보고 프롬프트를 수정하기를 반복해야 했다. 그렇게 수정할 때마다 나는 많은 결과를 얻으려는 욕심을 계속 덜어냈다. 그런 대화를 반복하다 보니 결국 나는 GPT-4에게 검색이나 하이라이트를 얘기하고 있지 않았다. 나는 문제를 구체적이면서도 추상적이고, 모호하지 않은 하위 문제들로 쪼개어 물었고, 그렇게 얻은 답을 모두 조합해 내가 원하는 것을 얻을 수 있었다.

AI의 수준을 파악하고 나니 나의 업무 생활이 즉각적으로 바뀌었음을 느낄 수 있었다. 이제는 어떤 문제를 봐도 GPT-4가 이해할 수 있는 크기로 쪼개질 수 있는 게 보였다. 그제야 비로소 사무실 동료의 모니터에 왜 그렇게 챗GPT 대화창이 많이 보이는지, 왜 벤의 생산성이 그렇게 높아졌는지 이해할 수 있었다.

나는 더 자주 AI를 사용해 보기로 생각을 바꿨다.

(이미지 생성: Stable Diffusion XL)

그렇게 해서 다시 십자말풀이 만들기 프로젝트로 돌아왔다. 우리가 만든 생성기는 퍼즐을 아래처럼 보기 흉한 텍스트 포맷으로 만들어 냈다. 내가 원한 건 웹사이트에서 보는 것처럼 장기판 모양의 그리드 안에 단어가 등장하는 거였고, 점수도 한눈에 볼 수 있기를 바랐다.

"s""c""a""r""*""k""u""n""i""s""*" "a""r""e""a"

하지만 그렇게 하는 게 쉬운 작업이 아님을 알고 있었다. 각 글자는 그게 속한 단어로 태깅(tagging)되어 있어야 했고, 어떤 글자는 세로 단어와 가로 단어에 모두 태깅되어야 한다. 이건 아주 세밀한 문제라서 저녁 내내 매달려야 해결할 수 있는 그런 일이다. 하지만 이제 곧 아이가 태어날 거라 저녁 시간이 그다지 자유롭지 못했던 나는 GPT-4와 대화를 나눠 보기로 했다.

물론 한 번에 되는 건 아니었고, 몇 차례를 주고받다 보니 어느 순간에는 GPT-4가 뭘 하고 있는지 파악하기 위해 내가 코드를 몇 줄 읽어봐야 했다. 나는 내가 코딩에 중요하다고 생각했던 그런 사고를 GPT-4가 쓴 코드를 이해하는 데 적용하지 적용하지 않고 있었다. 숫자와 패턴, 루프(loop)에 주의를 기울이지 않았고, 컴퓨터가 작동하는 방식대로 생각을 해보지 않았다. 프로그래머인 제프리 리트(Geoffrey Litt)가 말한 것처럼 "나는 프로그래머의 두뇌를 사용하지 않았다." 그럼 나는 뭘 했던 걸까?


이세돌은 바둑이라는 게임이 가치를 잃었다는 생각에 은퇴하지 않았을까? 내가 처음 입문했을 때 프로그래밍은 일종의 마술처럼 느껴졌다. 컴퓨터라는 기계는 나에게 엄청난 능력을 부여하지만, 그걸 사용하려면 고대의 비밀을 배워야 한다. 그 비밀의 주문이 프로그래밍 언어였다. 그런데 이걸 익히려면 독특한 사고방식을 갖고 있어야 했고, 나는 그런 의미에서 선택된 소수라고 생각했다. 나는 지루한 작업, 조심스러운 사고에 나의 모든 것을 쏟아부었고, 잘 알려지지 않은 지식을 쌓아나갔다. 그런데 어느 날 갑자기 (AI의 등장과 함께) 그런 사고법이나 지식이 없이도 똑같은 결과물을 만들어 내게 된 거다. 그러니 어떻게 보면 프로그래머가 노력해 온 많은 나날이 시간 낭비로 보이는 게 사실이다.

하지만 나는 이세돌을 생각할 때마다 체스를 떠올린다. 컴퓨터가 체스에서 사람을 이긴 건 약 30년 전이다. 그때만 해도 사람들은 더 이상 체스를 할 필요를 느끼지 않을 거라고 생각했다. 하지만 지금은 어떤가? 체스는 그 어느 때보다 인기를 끌고 있다. AI의 등장은 체스를 다시 한번 인기 게임으로 만들었다. 최근 체스에 재미를 들인 친구 하나는 AI 체스 코치를 사용한다. AI 코치는 내 친구의 실력을 조금 벗어난 정도의 난이도를 갖고 게임에 임한다. 그렇게 해서 사용자가 패하면 어느 지점에서 실수를 했는지 알려준다. 그런가 하면, 체스의 최고수(그랜드마스터)들은 마치 신을 상대로 하는 것 같은 게임을 하며 학습한다. 체스를 배우기는 그 어느 때보다 쉬워졌고, 체스의 가장 심오한 비밀은 그 어느 때보다 흥미진진하게 다가온다.

역사상 최연소 체스 그랜드마스터 아비마뉴 미슈라 (이미지 출처: ESPN)

AI는 아직 프로그래밍을 정복하지 못했다. GPT-4의 실력은 뛰어나지만, 일반인은 프로그래머만큼 AI를 사용해 프로그래밍을 할 수 없다. 그런 의미에서 나는 아직 직업을 잃을 걱정을 하지 않는다. 아니, 나의 직업 안정성은 과거보다 더 커진 것 같다. 소프트웨어가 만들기 쉬워지면서 세상에는 더 많은 소프트웨어가 나타날 것이고, 그걸 설계하고, 구성하고, 보수하기 위해 프로그래머들이 필요하게 될 거다.

그리고 비록 내가 프로그래밍에서 까다롭고 성가신 작업이 가장 중요한 작업이라고 생각하고, 그걸 할 때 내 마음이 안정되는 게 사실이지만, 그렇다고 해서 내가 그런 작업을 특별히 잘하는 건 아니다. 나는 빅테크 기업들에서 채용 인터뷰 때 프로그래머들에게 내주는 고전적인 코딩 문제를 풀지 못한 적도 많다. 내가 상대적으로 잘하는 건 어떤 소프트웨어가 만들 만한 가치가 있는지, 사용자들이 좋아하는 게 뭔지 아는 것이고, 기술 언어와 인간의 언어를 모두 사용한 의사소통이다. 한 친구는 AI의 현 단계를 "그저 그런 프로그래머의 복수(the revenge of the so-so programmer)"라고 부른다. 코딩 자체의 중요성은 감소하고, 소프트한 기술이 빛을 발하게 될지 모른다.  

하지만 태어날 내 아이에게 뭘 가르쳐야 하는지에 대한 의문은 남는다. 어쩌면 내 아이가 성인이 될 때쯤이면 우리는 "프로그래머(the programmer)"를 과거에 우리가 "컴퓨터(the computer)"라고 불렀던 사람들—손으로 직접 계산하던 계산원들—처럼 생각하게 될지 모른다. 그때가 되면 C++이나 파이썬을 사용해 직접 프로그래밍하는 지금을 돌아보며 우리가 지금 종이 카드에 구멍을 뚫어 이진법 코드를 넣던 시절을 생각하듯 생각하게 될 수 있다. 다익스트라가 들으면 기겁하겠지만, 컴퓨터가 원하는 기능을 수행하게 하려면 그저 내가 원하는 게 뭔지를 예의 갖춰 부탁하기만 하면 되는 세상이 올 거다.

여성 계산원(computer)들의 모습 (이미지 출처: The New Atlantis)

그러니 아이에게 가르쳐야 하는 것은 코딩이라는 기술이 아니라, 정신(spirit)일 거다. 나는 나 같은 사람이 다른 시대에 태어났다면 무슨 일을 하며 살았을까, 하는 생각을 가끔 한다. 프로그래머들은 농경시대에 태어났다면 물레바퀴나 품종을 개선하고 있었을 거고, 뉴턴 시대에 태어났다면 유리와 염료, 시간 기록에 집착했을 거다. 나는 얼마 전에 신경망 컴퓨터를 개발한 사람들의 증언을 기록한 책을 읽다가 흥미로운 사실을 발견했다. 1930년대 언저리에 태어난 이들은 하나같이 어린 시절에 라디오를 가지고 놀았다는 거다. 어쩌면 다음 세대의 프로그래머들은 엄마 아빠 세대가 블랙박스라고 부르던 AI의 속을 들여다보며 밤을 새울지 모른다.

그러니 나는 코딩의 시대가 저문다고 걱정하지 않는다. 해킹은 영원하니까. 🦦