이 시리즈를 시작할 때 지인이 물었던 걸 그대로 적어뒀습니다.
"내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?"
30년 넘게 코딩한 사람이 한 질문이었습니다. 그때 저는 제대로 답을 못 하고 얼버무리고 넘어갔습니다. 네 편을 쓰고 난 지금도 사실 그때에서 크게 나아가지 못했습니다.
저는 계속 "남는다"고 썼습니다
앞의 네 편을 다시 읽어보면 결론이 거의 같은 방향입니다.
AI가 못 보는 게 있다, 거기에 회사의 규칙이 있다, 책임은 사람에게 고정돼 있다, 그러니까 도구를 다룰 줄 아는 사람의 값이 올라간다. 다 제가 실제로 그렇게 보고 있는 것들입니다.
그런데 쓰는 내내 걸리는 게 있었습니다. 이게 관찰인가, 아니면 제가 그러길 바라는 건가.
저는 개발자입니다. 20년 넘게 이 일을 했고 지금도 이 일로 먹고삽니다. 그런 사람이 "개발자의 위치는 남는다"는 결론에 닿았을 때 그게 순수하게 본 것에서 나왔다고 자신하기가 어렵습니다. 저는 남길 바라니까요.
어떤 직군이 위험해질 때 그 직군 안에서 나오는 글은 거의 항상 "우리는 대체되지 않는다"로 끝나는 것 같습니다. 사진이 나왔을 때 회화 쪽 반응이 그랬고, 조판이나 타이핑처럼 기계가 먼저 들어간 일들에서도 비슷한 얘기가 나왔습니다. 그중 일부는 결국 맞았고 일부는 완전히 틀렸는데, 쓰던 당시에는 둘 다 똑같이 그럴듯하게 읽혔을 겁니다. 제 글도 그 목록에 들어갈 수 있습니다.
반대쪽도 사정은 비슷합니다. AI를 만드는 회사들은 이게 세상을 바꾼다고 말할 이유가 아주 큽니다. 투자를 받아야 하고 쓰게 만들어야 하니까요. "곧 대부분의 일을 대신하게 됩니다"라는 문장은 제품 설명이면서 자금 조달 문서이기도 합니다.
개발자는 남는다고 말할 이유가 있고, AI 회사는 다 바뀐다고 말할 이유가 있고, 컨설팅 쪽은 지금이 전환점이라고 말할 이유가 있습니다. 이 주제에서 아무 데도 안 걸려 있는 사람을 저는 잘 못 찾겠습니다.
그래서 요즘은 누가 무슨 말을 하면 그 사람이 뭘로 먹고사는지를 먼저 봅니다. 제 글도 그렇게 읽히면 됩니다. 이 글을 쓰는 사람은 개발자고, 개발자의 위치가 남기를 바랍니다.
생각해보면 지인의 질문도 완전히 중립은 아니었던 것 같습니다. "값이 있을까"라고 물었지만 듣고 싶었던 건 아마 "있다" 쪽이었을 거고, 저도 그걸 알아서 더 대답을 못 했던 것 같습니다. 있다고 하면 위로가 되고, 없다고 하면 근거를 대야 하는데 저한테는 둘 다 없었습니다.
그래서 반대쪽 그림을 한 번 진지하게 그려보려고 했습니다. 제가 틀렸다면 어떻게 되나.
아마 이럴 것 같습니다. 지금 남는다고 말한 것들이 하나씩 시스템으로 흡수됩니다. 회사의 규칙은 사내 문서 연결로 대체되고, 책임은 계약과 보험으로 정리되고, 설명은 자동으로 만들어진 사후 보고서가 대신합니다. 그 과정에서 개발자가 사라지는 게 아니라 필요한 사람 수가 줄어듭니다. 열 명이 하던 일을 두 명이 하고, 그 두 명은 지금보다 훨씬 위쪽에서 판단만 합니다. 나머지 여덟 명은 다른 일을 찾습니다.
별로 극적이지 않은데 그래서 더 그럴듯합니다. 대체가 직업이 사라지는 식으로 오지 않고 사람 수가 줄어드는 식으로 오는 거죠. 그리고 이 그림에서는 제 글의 문장이 전부 맞은 채로 결론만 달라집니다. 위치는 정말 남고, 판별력은 정말 값을 하고, 책임은 정말 사람에게 있습니다. 그 위치가 여덟 명에게는 없다는 것만 빼면요.
저는 계속 "어떤 위치가 남는가"를 물었는데, 사람들이 실제로 걱정하는 건 "내가 거기 있을 수 있는가"입니다. 두 질문의 답이 같지 않습니다. 제 논지에서 제일 아픈 데가 여기인 것 같습니다.
만약 제가 그 두 명에 들어간다고 치면, 저는 몇 년 뒤에 이 시리즈를 맞은 글로 기억할 겁니다. 그게 좀 무섭습니다. 맞았다는 판정이 남은 사람 쪽에서만 내려진다는 뜻이니까요. 여덟 명 쪽에서 이 글을 다시 읽으면 똑같은 문장이 전혀 다르게 읽힐 텐데, 그 사람들은 굳이 다시 읽지 않을 것 같습니다.
AGI라는 말부터 흐릿합니다
"AGI가 오면 어떻게 되나"라는 질문이 자주 나오는데, 이 질문이 성립하는지부터 좀 의심스럽습니다. AGI가 뭔지 합의된 적이 없으니까요.
오픈AI가 연내에 AGI를 만들겠다고 한 인터뷰를 놓고 한 번 써본 적이 있는데, 그때 제일 걸렸던 게 기준이 없다는 점이었습니다. 무엇을 통과하면 AGI인지 정해져 있지 않으니 "만들었다"는 말도 "아직이다"는 말도 틀렸다고 확인할 방법이 없습니다. 며칠 뒤에 실제로 제품이 나왔을 때도 얘기는 성능이 아니라 요건 쪽으로 갔습니다. 무엇이 빠졌느냐를 두고 의견이 나뉘었습니다.
예측 시점이 몇 년씩 당겨지는 일도 계속 있습니다. 당겨지는 것 자체는 이상하지 않은데, 무엇이 당겨졌는지를 물으면 대답이 매번 다릅니다.
그래서 "AGI 시대"라고 할 때 사람들이 가리키는 건 대개 시점이 아니라 감각인 것 같습니다. 지금 속도가 이어지면 언젠가 대부분의 머리 쓰는 일이 흡수되는 때가 온다는 감각. 그 감각은 저도 있습니다. 정의가 없어도 방향은 느껴집니다. 다만 정의가 없으면 예측이 틀렸을 때 뭐가 틀렸는지도 알 수가 없습니다. 낙관하는 쪽이든 비관하는 쪽이든 나중에 틀렸다는 소리를 들을 일이 없는 말을 하고 있는 셈입니다.
회사에서 "AGI 오면 어떻게 하실 거예요" 같은 질문을 받으면 저는 답을 못 합니다. 무엇이 오는지가 안 정해져 있으니까요. 그래서 되묻는 편입니다. 지금 하시는 일에서 어떤 작업이 없어지면 곤란하냐고요. 그건 답할 수 있는 질문이고, 답하고 나면 해볼 것도 구체적으로 나옵니다.
큰 단어로 하는 대비는 대개 아무것도 안 하는 것과 구별이 안 됩니다. 준비해야 한다고 말하는데 이번 분기에 실제로 바뀐 건 없는 상태요. 단어가 크면 그게 잘 안 보입니다.
이런 얘기를 들으면 저는 좀 단순한 쪽부터 묻게 됩니다. 이거 AGI라는 이름을 붙여야만 설명되는 건가, 그냥 지금 있는 도구가 조금씩 나아지고 있다는 얘기 아닌가. 대부분은 후자로도 충분히 설명되는 것 같습니다. 이름이 커지면 대응도 커져야 할 것 같은 느낌이 드는데, 실제로 할 일은 그렇게 크지 않은 경우가 많습니다.
그리고 미래 시제로 밀어놓으면 지금 벌어지는 걸 안 보게 됩니다.
"AGI가 오면 일자리가 어떻게 되나"를 얘기하는 동안 이미 신입 채용 공고가 줄고, 주니어가 맡던 작업이 없어지고, 팀 구성이 조용히 바뀌고 있습니다. 그런데 이건 아직 AGI가 아니니까 논외로 칩니다. 큰 이름이 붙은 미래를 기다리는 동안 이름 없는 변화가 다 지나갑니다.
대부분의 사람이 실제로 겪게 될 건 어떤 극적인 전환점이 아니라 이쪽일 것 같습니다. 어느 날 갑자기가 아니라 몇 년에 걸쳐 자기 일에서 몇 가지가 빠져나가고, 남은 것으로 자기를 다시 설명해야 하는 상황. 훨씬 덜 극적인데 훨씬 더 실제입니다.
일자리 얘기가 늘 어긋나는 지점
일자리 얘기가 자꾸 헛도는 건 단위 때문인 것 같습니다. 사람들은 직업 단위로 셉니다. 개발자가 사라지나, 회계사가 사라지나, 번역가가 사라지나.
그런데 실제로 빠져나가는 건 직업이 아니라 그 직업 안의 작업입니다. 한 직업은 보통 수십 가지 작업의 묶음이고, 그중 몇 개가 빠지면 직업은 남되 모양이 바뀝니다. 어떤 작업이 빠지느냐에 따라 들어오기가 얼마나 어려운지, 몇 명이 필요한지, 연차가 어떻게 분포하는지가 다 달라집니다.
개발자로 좁혀 보면 이미 그렇게 되고 있습니다. 화면 하나 붙이는 일, 표준적인 API를 연동하는 일, 비슷한 폼을 열 개 만드는 일. 이런 건 실제로 빠져나갔습니다. 그런데 하필 이게 신입이 처음 맡던 일이었습니다.
그러니까 물어야 하는 건 "개발자가 사라지나"가 아니라 "개발자가 되는 경로가 남아 있나"인 것 같습니다. 둘은 완전히 다른 질문인데 자주 같이 뭉쳐서 얘기됩니다. 직업은 남는데 그 직업으로 들어가기가 점점 어려워지는 상황은 충분히 있을 수 있고, 지금 보이는 그림은 오히려 그쪽에 가깝습니다.
진입 경로가 막힌 직군이 어떻게 되는지는 여러 번 본 그림입니다. 도제로 배우던 기술직들이 대체로 그렇게 갔습니다. 기계가 초급 작업을 가져가면 초급 일자리가 없어지고, 초급 일자리가 없으면 중급이 안 길러지고, 20년쯤 지나면 그 일을 제대로 할 줄 아는 사람이 은퇴를 앞둔 몇 명만 남습니다. 직업이 사라진 게 아니라 이어지지 못한 겁니다. 이건 되돌리기가 거의 불가능합니다. 수요가 다시 생겨도 가르칠 사람이 없으니까요.
수요가 는다는 얘기도 있습니다. 만드는 비용이 내려가면 더 많이 만들게 되니 일자리가 늘어난다는 얘기인데, 실제로 몇 번 맞았습니다. 컴파일러가 나와서 프로그래머가 줄지 않았고, 웹 프레임워크가 나와서 웹 개발자가 줄지 않았습니다. 이번에도 그럴 거라고 기대하는 게 자연스럽습니다.
그런데 그때 늘어난 건 만들 수 있는 것의 종류였던 것 같습니다. 어셈블리로는 아예 못 만들던 걸 만들게 됐고, 그래서 없던 수요가 생겼습니다. 지금 빠르게 늘어나는 건 종류보다는 같은 것의 양에 가까워 보입니다. 비슷한 화면과 비슷한 연동을 더 빨리 더 많이 만드는 것요. 이게 새 직무를 만들어낼지는 저도 잘 모르겠습니다.
수요가 늘어도 그게 초급 일자리로 내려오는지는 또 다른 얘기입니다. 만들 게 많아졌는데 만드는 방식이 판단하는 두 명에 에이전트를 붙이는 식이라면, 총량이 늘어도 입구는 안 넓어집니다.
2편에서 판단력이 어떻게 길러지는지 모르겠다고 썼는데 그게 이 얘기입니다. 구현하면서 겪던 고생이 판단력의 재료였다면, 그 고생을 AI가 가져간 뒤에 판단력은 어디서 오나요. 저는 아직 모르겠습니다. 아는 척하고 싶지도 않습니다.
이건 개인이 노력해서 풀 수 있는 문제가 아닌 것 같습니다. 혼자 열심히 해서 판단력을 기르라는 말은 기를 기회가 있는 쪽에 이미 있는 사람한테만 통합니다. 거기 못 들어간 사람한테는 아무 말도 아닙니다. 결국 잘 풀린 사람들이 나중에 붙이는 설명이 되기 쉽습니다.
옆에서 신입이 들어와서 일을 배우는 걸 떠올려보면, 처음 몇 달은 대부분 틀리면서 배웁니다. 틀린 걸 누가 봐주고, 왜 틀렸는지 듣고, 다시 해보는 식으로요. 그 틀릴 수 있는 일감이 없어지면 그 과정도 같이 없어지는 건데, 이걸 누가 대신 만들어줄지는 잘 안 보입니다. 회사 입장에서는 틀릴 일감을 일부러 남겨둘 이유가 없으니까요.
제 논지에서 제일 약한 고리
2편에서 책임 구조가 기술보다 훨씬 느리게 바뀐다고 썼습니다. 지금도 그렇게 봅니다. 그런데 느리다는 건 안 온다는 뜻이 아닙니다.
자율주행이 아직 기본값이 아닌 건 책임 문제가 안 끝나서인데, 그게 영원히 안 끝날 이유는 없습니다. 언젠가는 법이랑 보험이랑 판례가 붙어서 정리될 거고, 그러고 나면 사람이 운전석에 앉아 있을 이유가 없어집니다.
제 글은 사실 이 시차에 기대고 있었습니다. 기술은 빠르고 제도는 느리니까 그 사이에 사람이 필요하다는 것. 그런데 이건 영구적인 이유가 아니라 과도기의 이유입니다. 시차가 닫히면 제 얘기도 같이 약해집니다.
그럼 시차가 닫힐 때 개발자는 어디 있을까요. 저는 모릅니다. 닫히는 순서는 좀 짐작이 갑니다.
책임이 먼저 넘어가는 건 아마 위험이 작고 반복적이고 결과가 좁은 일일 겁니다. 틀려도 되돌릴 수 있고, 틀린 걸 금방 알 수 있고, 틀렸을 때 손해가 계산되는 일요. 이런 데는 이미 넘어가고 있습니다. 스팸 판정이나 이상 거래 1차 탐지 같은 건 사람이 하나씩 결재하지 않은 지 오래됐고, 아무도 그걸 책임 공백이라고 부르지 않습니다. 틀리면 되돌리면 되고, 되돌리는 비용이 사람을 붙이는 비용보다 싸니까요. 반대로 되돌릴 수 없거나, 여러 이해관계가 얽혀 있거나, 무엇이 옳은지가 사람마다 다른 일은 마지막까지 남을 것 같습니다. 거기서는 답을 계산하는 게 아니라 누군가 결정을 해야 하고, 결정에는 결정한 사람이 필요합니다.
저는 일하면서도 이 구분을 꽤 자주 씁니다. 되돌릴 수 있는 일은 AI한테 맡기고 나중에 봐도 되는데, 되돌릴 수 없는 일은 누가 하라고 했는지가 남아 있어야 마음이 놓입니다. 지우는 일, 밖으로 내보내는 일 같은 것들요. 이건 AI가 아무리 잘해도 제가 승인하고 싶습니다. 잘하는지 못하는지의 문제가 아니라, 잘못됐을 때 그 일을 누가 했다고 말할 수 있어야 해서 그런 것 같습니다.
이 구분이 좀 잔인한 게, 계산되는 쪽이 대체로 배우기 쉬운 쪽이기도 합니다. 조건이 명확하고 정답이 있는 일은 가르치기도 쉽고 익히기도 쉽습니다. 그래서 신입이 먼저 맡던 일이 정확히 그쪽이었고, 지금 먼저 빠져나가는 것도 그쪽입니다. 마지막까지 남을 일은 원래부터 들어가기 어려웠던 쪽이고, 거기 가려면 지금 빠져나가는 쪽을 한참 거쳐야 했습니다. 사다리 아래 칸부터 없어지고 있는 겁니다.
준비한다는 게 의미가 있다면 그 마지막 쪽으로 한 칸씩 걸어가는 일일 것 같습니다. 특정 기술을 새로 배우는 게 아니라요.
앞에서 낙관이든 비관이든 틀렸다는 소리를 들을 일이 없는 말이라고 써놓고, 제 글만 그냥 두면 좀 이상합니다. 무엇을 보면 제가 생각을 바꿀지도 적어두려고 합니다.
계약과 보험 쪽이 하나입니다. 2편에서 봐야 할 건 벤치마크 점수가 아니라 계약서라고 썼는데, 어떤 종류의 코드 변경에 대해 공급자가 결과까지 책임지는 계약이 실제로 표준이 되기 시작하면 제 시차 얘기는 거기서 성립하지 않습니다. 그때는 사람이 마지막 관문에 서 있을 이유가 없습니다.
신입 채용도 봅니다. 초급 작업이 빠져도 다른 종류의 초급 작업이 생길 수 있다고 썼는데, 그건 본 게 아니라 기대에 가깝습니다. 앞으로 몇 년 동안 신입 공고가 계속 줄고 그걸 메우는 새 입구가 안 보이면, 경로가 끊기는 쪽 그림이 맞았던 겁니다.
설명을 요구하는 습성도 지켜볼 수 있을 것 같습니다. 뒤에서 이게 제 글에서 제일 덜 흔들리는 부분이라고 쓸 건데, 사고가 났을 때 "AI가 판단해서 이렇게 처리했습니다"라는 공지가 별 항의 없이 받아들여지는 일이 쌓이면 그 습성이 생각보다 얕았던 거겠죠.
이걸 안 적어두면 나중에 판단을 슬그머니 바꿔놓고 처음부터 그렇게 생각했다고 말하게 될 것 같습니다. 사람이 제일 흔하게 하는 게 그거라고 봅니다. 생각을 바꾸는 게 문제라기보다, 바꿨다는 걸 본인도 모르고 지나가는 게 문제입니다. 틀렸으면 틀렸다고 적어둬야 다음에 같은 식으로 안 틀립니다. 적어두지 않은 판단은 틀려도 아무것도 안 남습니다.
1편에서 쓴 것도 시한부일 수 있습니다
약한 데가 하나 더 있는데, 이건 앞의 것보다 더 가까이 있습니다.
1편에서 AI가 회사의 비공개 규칙을 모른다고 썼습니다. 네이버 랭킹처럼 공개하면 힘을 잃는 규칙은 학습 데이터에 영원히 안 들어간다고도 했습니다. 지금은 맞습니다. 그런데 영원히 맞을 이유는 없습니다.
지금 기업들이 하는 일이 정확히 그 규칙을 AI한테 먹이는 일이니까요. 사내 문서를 연결하고, 위키를 인덱싱하고, 코드베이스를 통째로 붙이고, 티켓과 의사결정 기록을 넣습니다. 공개 학습 데이터에 안 들어가도 그 회사 안에서는 볼 수 있게 됩니다. 이 일을 잘하면 잘할수록 제가 1편에서 짚었던 영역이 좁아집니다.
그러니까 다시 쓰면 이렇게 됩니다. AI가 회사를 모르는 게 아니라 그 회사가 자기를 설명해놓지 않았을 뿐이다. 설명해놓은 회사에서는 AI도 압니다.
이렇게 고쳐 쓰고 나니 좀 서늘합니다. 제가 안전하다고 생각했던 데가 사실은 아직 정리를 안 해서 남아 있었을 뿐이라는 거니까요.
그럼 뭐가 남나요. 설명을 만드는 일이 남는 것 같습니다. 무엇을 적어둘지, 어떤 예외가 왜 생겼는지, 어떤 규칙이 이미 죽었는지를 판단해서 정리하는 일. 규칙을 아는 것과 규칙을 정리해서 남기는 건 다른 일이고, 뒤쪽은 아직 사람 몫입니다. 3편에서 하네스 얘기를 길게 쓴 것도 결국 이 얘기였습니다.
두 번 밀린 것 같습니다. 코드를 쓰는 일에서 규칙을 아는 일로 밀렸고, 이제 규칙을 아는 일에서 규칙을 정리하는 일로 밀리고 있습니다. 계속 밀린다는 게 좋은 신호는 아닙니다. 밀리는 방향이 매번 더 위쪽이라는 건 조금 다행인데, 위로 갈수록 폭이 좁아진다는 것도 같이 봐야 할 것 같습니다.
세 번째로도 밀릴 수 있냐고 하면, 그럴 것 같습니다. 규칙을 정리하는 일도 형태가 정해지면 상당 부분 넘어갈 겁니다. 어떤 문서가 낡았는지 알아보는 것도 신호가 충분히 모이면 자동화될 수 있습니다. 안전한 데를 찾는 식으로 이 얘기를 하면 계속 뒤로 밀리기만 합니다. 그래서 요즘은 어디가 안전한지보다, 밀렸을 때 다음 칸으로 넘어가는 속도를 더 보게 됩니다. 실제로 남는 건 그 속도인 것 같습니다.
그런데 "준비"라는 말도 좀 이상합니다
무엇을 준비해야 하냐는 질문을 자주 받는데, 성실하게 답할수록 오히려 도움이 안 되는 것 같습니다.
준비라는 말에는 목표가 정해져 있다는 전제가 깔려 있습니다. 시험이 있으니 범위를 알고 공부하는 식이죠. 그런데 지금은 시험 범위가 매달 바뀝니다. 3편에서 바뀌는 속도 자체가 빨라지고 있다고 썼는데, 그런 상황에서 "무엇을"에 답하면 대체로 반년짜리 답이 됩니다.
그래서 이 질문을 받으면 좀 다르게 답하려고 합니다. 무엇을 배울지보다 어떻게 배우는지가 지금은 더 중요한 것 같다고요.
새로운 게 나왔을 때 얼마나 빨리 손에 익히는지, 안 되는 걸 봤을 때 원인을 어디까지 파고드는지, 자기가 틀렸다는 신호를 얼마나 빨리 받아들이는지. 이런 건 도구가 바뀌어도 안 바뀝니다. 배우는 거라기보다 습관에 가까워서 하루아침에 생기지도 없어지지도 않습니다.
솔직히 말하면 이건 준비라기보다 그냥 잘하는 사람의 특징입니다. AI 시대라서 새로 생긴 덕목도 아닙니다. 예전에도 그런 사람이 오래 갔습니다. 예전에는 그렇지 않아도 버틸 여유가 있었고 지금은 그 여유가 줄어드는 것뿐입니다.
이 시대가 실제로 한 일은 새로운 능력을 요구한 게 아니라 원래 있던 차이를 벌려놓은 쪽에 가깝다고 보고 있습니다. 원래 빨리 배우던 사람은 더 빨리 배우게 됐고, 원래 그렇지 않던 사람은 따라잡을 시간이 없어졌습니다. 도구가 좋아지면 모두 같이 올라갈 것 같은데 실제로는 잘 그렇게 안 됩니다. 도구를 쓸 줄 아는 정도가 원래부터 사람마다 달랐으니까요.
그런데 차이가 벌어진다는 걸 능력 차이로만 보면 또 틀리는 것 같습니다. 빨리 배우는 데는 시간이 필요하고, 시간은 능력이 아니라 조건입니다. 야근이 많은 팀에 있거나 돌볼 사람이 있으면 새 도구를 붙잡고 있을 저녁이 없습니다. 회사가 도구 비용을 안 내주면 그것도 조건입니다. 2편에서 중간에 낀 층 얘기를 한 게 이 때문입니다. 지금 벌어지는 차이의 상당 부분은 배우는 능력이 아니라 배우는 데 쓸 수 있는 여유의 차이인 것 같습니다. 이걸 능력 차이로 정리해버리면 조언하기는 훨씬 쉬워지는데, 쉬워진 만큼 틀립니다.
"어떻게 배우는지가 중요하다"는 제 말도 다시 보면 남는 사람 쪽 언어 같습니다. 이미 배울 시간이 있는 사람한테나 의미가 있는 얘기니까요. 저녁이 없는 사람한테 배우는 방식을 바꾸라고 하면 그건 그냥 숙제를 하나 더 주는 겁니다.
이건 조언으로 풀리지 않습니다. 그래서 "이렇게 준비하세요" 같은 글을 볼 때마다 좀 불편합니다. 저도 지금 그런 글을 쓰고 있어서 더 그렇습니다.
그래도 안 바뀔 것 같은 게 하나 있습니다
기술 예측을 하다 보면 자꾸 기술만 보게 되는데, 사람 쪽에서 안 바뀔 것 같은 게 하나 있습니다. 사람은 사람한테 설명을 요구합니다.
검사 결과를 기계가 판독했어도 환자는 의사한테 듣고 싶어 합니다. 판결을 알고리즘이 거들었어도 판결문에는 판사의 이름이 들어갑니다. 사고가 났을 때 사람들이 원하는 건 원인 분석 보고서만이 아니라 누군가 나와서 설명하는 장면입니다.
이건 효율의 문제가 아니라서 성능이 좋아진다고 없어지지 않을 것 같습니다. 제 글에서 제일 덜 흔들리는 부분이 여기라고 생각합니다. 책임 제도는 언젠가 바뀔 수 있지만 설명을 요구하는 습성은 제도보다 더 밑에 있습니다.
설명이 정보 전달만은 아니라서 그런 것 같습니다. 사고 후 기자회견에서 사람들이 확인하고 싶어 하는 건 사실 관계가 아닙니다. 누가 이걸 자기 일로 여기고 있는지를 봅니다. 원인 분석은 문서로 읽으면 되는데 굳이 사람이 나와서 말하라고 하는 이유가 그겁니다.
개발자한테 갖다 붙이면 좀 멀게 느껴질 수 있습니다. 개발자가 카메라 앞에 설 일은 거의 없으니까요. 그런데 조직 안에서는 같은 게 매일 돌아갑니다. 회의실에서 "이거 왜 이렇게 했어요"라는 질문이 나오면 그건 대체로 기술적인 근거만 묻는 게 아닙니다. 이 결정을 누가 자기 것으로 들고 있는지를 확인하는 겁니다. 거기 아무도 없으면 회의가 이상하게 끝납니다.
위에서만 오는 것도 아닙니다. 옆에서도 옵니다. 다른 팀이 우리 API를 붙일 때 사람을 찾아와 물어보는 것도 같은 종류입니다. 문서만 보면 될 일을 굳이 확인하는 건 그 문서가 지금도 맞는지 아는 사람이 따로 있다는 걸 다들 알기 때문입니다. AI가 문서를 잘 써줄수록 이 확인은 오히려 더 필요해질 것 같습니다. 잘 쓰인 문서는 틀렸을 때 더 믿음직해 보이니까요.
그렇다고 확신하는 건 아닙니다. 사람들이 자동응답에 적응해온 걸 보면 몇 세대 지나서 "AI가 판단했습니다"를 자연스럽게 받아들이는 사회가 될 수도 있습니다. 은행 창구에서 사람을 만나는 게 당연하던 때가 있었고 지금은 아무도 그러지 않습니다. 저는 판단과 응대는 다르다고 믿는 쪽인데, 이 믿음도 제가 그러길 바라는 마음이랑 잘 구분이 안 됩니다.
처음 질문으로 돌아가서
그래서 지인한테 지금이라면 뭐라고 할까 생각해봤습니다. 3년 뒤에도 값이 있느냐는 질문에요.
정직하게 말하면 지금 쌓고 있는 것 중 절반쯤은 아마 값이 떨어질 겁니다. 어떤 절반인지는 저도 정확히 모르겠는데 대체로 손이 기억하는 쪽일 것 같습니다. 특정 언어의 관용구, 특정 프레임워크의 함정, 자주 쓰는 패턴을 빠르게 치는 속도. 이건 이미 값이 떨어지고 있습니다.
남는 절반은 아마 30년 동안 틀려본 기억일 겁니다. 이 설계가 왜 나중에 문제를 일으켰는지, 저 결정이 왜 6개월 뒤에 발목을 잡았는지, 어떤 요구사항을 들었을 때 왜 뒷목이 서늘했는지. 이건 코드가 아니라 판별력이고, 지금 AI가 제일 못 하는 게 이 부분입니다. 이걸 가진 사람이 AI를 쓰면 못 가진 사람이 쓸 때랑 결과가 확실히 다릅니다.
30년이 무의미해지는 게 아니라 30년 중 어느 부분이 값을 하는지가 바뀌는 거라고 봅니다.
그런데 이게 위로만은 아닙니다. 그 30년 동안 손에 익은 것들이 곧 자기였던 사람한테는 남는 절반이 자기 것 같지 않게 느껴질 수 있습니다. 빠르게 잘 짜는 사람으로 살아온 것과, 남이 짠 걸 읽고 어디가 위험한지 말하는 사람으로 사는 건 같은 사람 안에 있어도 느낌이 다릅니다. 뒤쪽이 더 값지다고 아무리 말해도, 앞쪽으로 자기를 설명해온 사람한테는 잃는 쪽이 더 크게 느껴집니다.
이 부분을 그냥 넘어가는 글이 많은데 저는 여기가 제일 어려운 것 같습니다. 기술을 새로 배우는 것보다 자기를 다시 설명하는 게 어렵습니다. 연차가 쌓일수록 더 그렇고요.
지인한테 실제로 뭐라고 할지는 아직 정하지 못했습니다. 커리어를 바꾸라고 할 근거도 없고 괜찮다고 할 근거도 부족합니다. 지금 할 수 있는 말은 하나 정도입니다. 3년 뒤를 계산하려고 하지 말고, 올해 안에 남이 만든 걸 읽고 판단하는 데 자기 시간이 얼마나 들어가는지 한번 세어보라는 것. 그게 늘고 있으면 방향은 맞는 것 같습니다. 여전히 대부분을 직접 만드는 데 쓰고 있으면, 그게 그쪽이 편해서인지 그쪽이 더 값을 해서인지 한번 따져볼 만합니다.
충분한 답은 아닙니다. 판단력을 기르라는 말보다는 오늘 바로 해볼 수 있는 거라서 이렇게 말하고 있습니다.
그 사람이 이 말을 들으면 아마 "그걸 세어서 뭐 하냐"고 할 것 같기도 합니다. 그래도 세어보는 건 3년 뒤를 맞히는 것보다는 훨씬 쉽고, 틀려도 손해 볼 게 없습니다.
그럼 왜 이런 글을 쓰나
여기까지 쓰고 보니 이 시리즈가 좀 이상한 모양이 됐습니다. 다섯 편 내내 뭔가를 주장했는데 마지막에 와서 그 주장들이 어디가 약한지를 제가 적고 있습니다.
그런데 지금은 이게 제일 정직한 형태인 것 같습니다. 확신을 갖고 쓴 글은 읽기 편한데 대체로 반년을 못 갑니다. 반년 전에 만든 발표 자료를 다시 열어봤던 적이 있는데, 그때 제일 민망했던 건 틀린 내용이 아니라 단정적인 문장들이었습니다. 내용은 반쯤 맞았는데 확신이 근거보다 컸습니다.
그래서 요즘은 어디까지가 본 거고 어디부터가 짐작인지를 글에 드러내려고 합니다. 읽는 사람은 좀 답답할 수 있는데, 몇 년 뒤에 다시 읽을 사람이 결국 저라는 걸 생각하면 이쪽이 낫습니다.
그런데 자기 편향을 스스로 가려내는 건 잘 안 되는 것 같습니다. 앞에서 개발자라서 개발자 위치가 남기를 바란다고 적어놓고도, 어느 문장이 그 바람에서 나온 건지는 여전히 잘 모르겠습니다. 편향을 아는 것과 편향을 빼는 건 다른 일입니다.
그래서 제가 걸러내기보다는 남이 걸러주길 기대하고 있습니다. 개발자가 아닌 사람이 이 글을 읽으면 어디가 자기 위안인지 훨씬 잘 보일 겁니다. 공개해놓고 쓰는 이유 중 하나도 그겁니다. 혼자 적어두면 반년 뒤에도 같은 편향으로 다시 읽게 됩니다.
이 주제는 특히 그런 것 같습니다. 지금 나오는 예측 중 상당수는 3년 뒤에 다시 읽으면 웃길 겁니다. 제 것도 포함해서요. 그때 뭐가 틀렸는지 보려면 지금 무엇을 보고 그렇게 생각했는지가 남아 있어야 합니다. 결론만 적어두면 나중에 왜 틀렸는지도 모릅니다. 2편에서 결정의 "왜"를 남기라고 썼는데 이 글도 그런 용도입니다.
개발자의 위치
1편에서 개발자가 사라지는 게 아니라 개발자라는 말이 가리키는 대상이 바뀐다고 썼습니다. 그 문장은 지금도 그대로 두려고 합니다.
다만 한 줄을 붙이고 싶습니다. 그 대상이 바뀌는 속도가 사람이 적응하는 속도보다 빠를 수 있다는 것.
저는 이게 진짜 문제라고 봅니다. 위치가 없어지는 게 아니라, 위치는 있는데 거기 서 있으려면 매년 다른 사람이 되어야 하는 상황. 개인이 노력해서 될 종류가 아닙니다. 그래서 "판단 근육을 기르세요" 같은 말이 절반은 맞고 절반은 무책임하게 들립니다. 기를 수 있는 조건에 있는 사람한테만 맞는 말이니까요.
남는다고 해서 편한 건 아니고, 남는 폭이 넓어진다고 해서 거기 들어갈 수 있는 사람이 늘어나는 것도 아닙니다. 이 시리즈 내내 남는 위치 얘기만 했으니 이 말도 같이 적어두고 싶었습니다.
그렇다고 할 수 있는 게 아무것도 없다고 생각하지는 않습니다. 우리 시스템에서 무엇이 지켜져야 하는지 알고 있는 것, 결과를 설명할 수 있는 것, 도구를 자기 일에 맞게 바꿔 쓰는 것. 앞에서 쓴 이런 것들은 AGI가 오든 안 오든 손해 보는 쪽은 아닌 것 같습니다. 이 기술이 나오기 전에도 값을 하던 것들이라 예측이 틀려도 버려지지 않습니다. 제가 확신하는 건 사실 그 정도까지고, 그 이상은 예측인데 예측은 대체로 틀립니다.
3년 뒤에 지인을 다시 만나면 이 글을 같이 열어보게 될 것 같습니다. 그때 뭐가 맞았고 뭐가 틀렸는지 보려고요. 이게 관찰이었는지 희망이었는지도 그때쯤이면 알 수 있을 겁니다.
댓글
댓글 쓰기