AGI가 와도 사람 자리는 남는다고 썼는데, 그게 observation인지 hope인지 저도 모르겠습니다

이 시리즈를 시작할 때 지인이 물었던 걸 그대로 적어뒀습니다.

"내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?"

30년 넘게 코딩한 사람이 한 질문이었습니다. 그 자리에서 저는 제대로 답을 못 했고, 얼버무리고 넘어갔습니다. 네 편을 쓰고 난 지금도 사실 그 자리에서 크게 움직이지 못했습니다. 그래서 마지막 글은 답을 정리하는 대신, 제가 앞에서 쓴 것들이 어디가 약한지를 짚어보는 쪽으로 가려고 합니다.

저는 계속 "남는다"고 썼습니다

앞의 네 편을 다시 읽어보면 결론이 거의 같은 방향입니다.

AI가 못 보는 자리가 있다, 그 자리에 회사의 규칙이 있다, 책임은 사람에게 고정돼 있다, 그러니까 도구를 다룰 줄 아는 사람의 값이 올라간다. 다 제가 실제로 그렇게 보고 있는 것들입니다.

그런데 이 글들을 쓰면서 계속 걸리는 게 있었습니다. 이게 관찰인가, 아니면 제가 그러길 바라는 건가.

저는 개발자입니다. 20년 넘게 이 일을 했고 지금도 이 일로 먹고삽니다. 그런 사람이 "개발자의 자리는 남는다"는 결론에 도달했을 때, 그 결론이 순수하게 데이터에서 나왔다고 자신하기가 어렵습니다. 저는 남길 바라니까요.

이건 그냥 넘길 수 있는 편향이 아닙니다. 어떤 직군이 위험해질 때 그 직군 안에서 나오는 글은 거의 항상 "우리는 대체되지 않는다"로 끝납니다. 사진이 나왔을 때 회화 쪽에서 나온 반응이 그랬고, 조판이나 타이핑처럼 기계가 먼저 들어간 일들에서도 비슷한 얘기가 나왔습니다. 그중 일부는 결국 맞았고 일부는 완전히 틀렸는데, 쓸 당시에는 둘이 똑같이 설득력 있게 읽혔습니다.

그러니까 제 글도 그 목록에 들어갈 수 있습니다. 이걸 인정하지 않고 시작하면 뒤에 뭘 써도 자기 위안이 됩니다.

그런데 반대쪽도 사정이 같습니다. AI를 만드는 회사들은 이게 세상을 바꾼다고 말할 유인이 아주 큽니다. 투자를 받아야 하고 쓰게 만들어야 하니까요. "곧 대부분의 일을 대신하게 됩니다"라는 문장은 제품 설명이면서 동시에 자금 조달 문서입니다. 그쪽 발언을 중립적인 관측으로 읽으면 안 되는 이유가 여기 있습니다.

그래서 이 주제에는 이해관계에서 자유로운 관측자가 사실상 없습니다. 개발자는 남는다고 말할 이유가 있고, AI 회사는 다 바뀐다고 말할 이유가 있고, 컨설팅 쪽은 지금이 전환점이라고 말할 이유가 있습니다. 다 어딘가에 걸려 있습니다.

그래서 요즘은 누가 무슨 말을 하면 그 사람이 뭘로 먹고사는지를 먼저 봅니다. 냉소해서가 아니라 그게 정보이기 때문입니다. 제 글도 같은 기준으로 읽히면 됩니다. 이 글을 쓰는 사람은 개발자고, 개발자의 자리가 남기를 바랍니다.

그래서 반대쪽 시나리오를 한 번 진지하게 써보려고 했습니다. 제가 틀렸다면 그림이 어떻게 되나.

아마 이렇게 될 것 같습니다. 지금 남는다고 말한 자리들이 하나씩 시스템으로 흡수됩니다. 회사의 규칙은 사내 문서 연결로 대체되고, 책임은 계약과 보험으로 정리되고, 설명은 자동으로 만들어진 사후 보고서가 대신합니다. 그 과정에서 개발자가 사라지는 게 아니라 필요 인원이 줄어듭니다. 열 명이 하던 일을 두 명이 하고, 그 두 명은 지금보다 훨씬 위쪽에서 판단만 합니다. 나머지 여덟 명은 다른 일을 찾습니다.

이게 별로 극적이지 않은데, 그래서 더 그럴듯합니다. 대체는 직업이 사라지는 방식으로 오지 않고 인원이 줄어드는 방식으로 옵니다. 그리고 이 시나리오에서는 제 글의 문장들이 전부 맞은 채로 결론만 달라집니다. 자리는 정말 남고, 판별력은 정말 값을 하고, 책임은 정말 사람에게 있습니다. 그 자리가 여덟 명에게는 없다는 것만 빼면요.

제 논지의 진짜 약점이 여기라고 봅니다. 저는 계속 "어떤 자리가 남는가"를 물었는데, 사람들이 실제로 걱정하는 건 "내가 그 자리에 있을 수 있는가"입니다. 두 질문의 답이 같지 않습니다.

AGI라는 말부터 흐릿합니다

"AGI가 오면 어떻게 되나"라는 질문이 자주 나오는데, 저는 이 질문이 성립하는지부터 좀 의심스럽습니다. AGI가 뭔지 합의된 적이 없기 때문입니다.

오픈AI가 연내에 AGI를 만들겠다고 한 인터뷰를 놓고 한 번 정리해본 적이 있는데, 그때 제일 걸렸던 게 기준이 없다는 점이었습니다. 무엇을 통과하면 AGI인지가 정해져 있지 않으니 "만들었다"는 선언도 "아직이다"는 반박도 둘 다 반증이 안 됩니다. 며칠 뒤에 실제로 제품이 나왔을 때도 논쟁은 성능이 아니라 요건 쪽에서 붙었습니다. 무엇이 빠졌느냐를 두고 갈렸습니다.

예측 시점이 몇 년씩 당겨지는 일도 반복됩니다. 당겨지는 것 자체는 이상하지 않은데, 무엇이 당겨졌는지를 물으면 대답이 매번 다릅니다.

그래서 "AGI 시대"라는 말을 쓸 때 사람들이 실제로 가리키는 건 대개 시점이 아니라 감각인 것 같습니다. 지금 속도가 유지되면 언젠가 대부분의 지적 노동이 흡수되는 지점이 온다는 감각. 그 감각은 저도 있습니다. 정의가 없어도 방향은 느껴집니다.

다만 정의가 없다는 건 예측이 틀렸을 때 뭐가 틀렸는지 확인할 방법도 없다는 뜻입니다. 이게 이 주제로 진지하게 얘기하기 어려운 이유입니다. 낙관도 비관도 둘 다 반증 불가능한 자리에 서 있습니다.

정의가 없는 게 실무에서도 걸립니다. 회사에서 "AGI 오면 어떻게 하실 거예요" 같은 질문을 받으면 답할 수가 없습니다. 무엇이 오는지가 안 정해져 있으니까요. 그래서 저는 그 질문을 받으면 되묻는 편입니다. 지금 하고 계신 일에서 어느 작업이 없어지면 곤란한지를요. 그건 답할 수 있는 질문이고, 답하고 나면 대비할 것도 구체적으로 나옵니다.

추상적인 대비는 대개 아무것도 안 하는 것과 구별이 안 됩니다. 준비해야 한다고 말하면서 이번 분기에 실제로 바뀐 게 없는 상태요. 큰 단어가 그걸 가려줍니다.

그리고 가정법이 논의를 망치는 방식이 하나 더 있습니다. 미래 시제로 밀어놓으면 지금 벌어지는 걸 안 보게 됩니다.

"AGI가 오면 일자리가 어떻게 되나"를 얘기하는 동안, 이미 신입 채용 공고가 줄고 주니어가 맡던 작업이 없어지고 팀 구성이 조용히 바뀌고 있습니다. 그런데 이건 아직 AGI가 아니니까 논외로 칩니다. 큰 이름이 붙은 미래를 기다리는 동안 이름 없는 변화가 다 지나갑니다.

제 생각엔 대부분의 사람이 실제로 겪게 될 일은 어떤 극적인 전환점이 아니라 이런 것들입니다. 어느 날 갑자기가 아니라, 몇 년에 걸쳐 자기 일에서 몇 가지가 빠져나가고 남은 걸로 다시 자기를 설명해야 하는 상황. 이게 훨씬 덜 극적이고 훨씬 더 실제입니다.

일자리 얘기가 늘 어긋나는 지점

일자리 논의가 자꾸 헛도는 이유는 단위 때문이라고 보고 있습니다. 사람들은 직업 단위로 셉니다. 개발자가 사라지나, 회계사가 사라지나, 번역가가 사라지나.

그런데 실제로 빠져나가는 건 직업이 아니라 그 직업 안의 작업입니다. 한 직업은 보통 수십 가지 작업의 묶음인데, 그중 몇 개가 빠지면 직업은 남되 모양이 바뀝니다. 그리고 어떤 작업이 빠지느냐에 따라 그 직업의 진입 난이도, 필요 인원, 평균 연차 분포가 전부 달라집니다.

개발자로 좁혀 보면 이미 그렇게 되고 있습니다. 화면 하나 붙이는 일, 표준적인 API를 연동하는 일, 비슷한 폼을 열 개 만드는 일. 이런 건 실제로 빠져나갔습니다. 그런데 이 작업들이 하필 신입이 처음 맡던 일이었습니다.

그러니까 정확한 질문은 "개발자가 사라지나"가 아니라 "개발자가 되는 경로가 남아 있나"입니다. 이 둘은 완전히 다른 질문인데 자주 뭉쳐서 얘기됩니다. 직업은 남는데 그 직업으로 들어가는 문이 좁아지는 상황은 충분히 가능하고, 오히려 그쪽이 지금 실제로 보이는 그림에 가깝습니다.

진입 경로가 막힌 직군이 어떻게 되는지는 이미 여러 번 본 그림입니다. 도제로 배우던 기술직들이 대체로 그렇게 갔습니다. 기계가 초급 작업을 가져가면 초급 자리가 없어지고, 초급 자리가 없으면 중급이 안 길러지고, 20년쯤 지나면 그 일을 제대로 할 줄 아는 사람이 은퇴를 앞둔 몇 명만 남습니다. 직업이 사라진 게 아니라 이어지지 못한 겁니다.

그리고 이 상태는 되돌리기가 거의 불가능합니다. 수요가 다시 생겨도 가르칠 사람이 없기 때문입니다. 사라진 게 일자리가 아니라 전수 경로라서 그렇습니다.

개발이 반드시 그렇게 된다고 말하는 건 아닙니다. 소프트웨어는 여전히 수요가 늘고 있고, 초급 작업이 빠져도 다른 종류의 초급 작업이 생길 수도 있습니다. 다만 이 경로가 실제로 존재한다는 걸 알고 보는 것과 모르고 보는 건 꽤 다릅니다.

수요가 는다는 얘기도 조금 나눠 봐야 합니다. 만드는 비용이 내려가면 더 많이 만들게 되니 일자리가 늘어난다는 논리는 역사적으로 몇 번 맞았습니다. 컴파일러가 나와서 프로그래머가 줄지 않았고, 웹 프레임워크가 나와서 웹 개발자가 줄지 않았습니다. 그래서 이번에도 그럴 거라는 기대가 자연스럽습니다.

다만 그때 늘어난 건 만들 수 있는 것의 종류였습니다. 어셈블리로는 아예 못 만들던 걸 만들게 됐고, 그래서 없던 수요가 생겼습니다. 지금 빠르게 늘어나는 건 종류가 아니라 같은 것의 양쪽에 가까워 보입니다. 비슷한 화면과 비슷한 연동을 더 빨리 더 많이 만드는 것요. 이게 새 직무를 만들어내는지는 아직 잘 모르겠습니다.

그리고 수요가 늘어도 그 수요가 초급 자리로 내려오는지는 별개입니다. 만들 게 많아졌는데 만드는 방식이 판단하는 두 명에 에이전트를 붙이는 형태라면, 총량이 늘어도 입구는 안 넓어집니다. 수요 총량과 진입 경로를 같은 얘기로 다루면 여기서 틀립니다.

2편에서 판단력이 어떻게 길러지는지 모르겠다고 썼는데, 그게 이 얘기입니다. 구현의 고통이 판단력의 재료였다면, 그 고통이 흡수된 뒤에 판단력은 어디서 오나요. 저는 아직 답을 못 찾았고, 대충 아는 척하고 싶지 않습니다.

그리고 이건 개인이 노력해서 풀 수 있는 문제가 아닙니다. 혼자 열심히 해서 판단력을 기르라는 조언은, 기를 기회가 있는 자리에 이미 앉아 있는 사람에게만 유효합니다. 그 자리에 못 들어간 사람에게는 아무 말도 아닙니다. 이 구분을 안 하고 조언하면 결국 잘 풀린 사람들의 사후 설명이 됩니다.

제 논지에서 제일 약한 고리

2편에서 책임 구조가 기술보다 훨씬 느리게 바뀐다고 썼습니다. 그건 지금도 맞다고 봅니다. 그런데 여기에 함정이 하나 있습니다.

느리다는 건 안 온다는 뜻이 아닙니다.

자율주행이 아직 기본값이 아닌 건 책임 문제가 안 끝나서인데, 그 문제가 영원히 안 끝날 이유는 없습니다. 언젠가는 법과 보험과 판례가 붙어서 정리됩니다. 정리되고 나면 그때는 사람이 운전석에 앉아 있을 이유가 사라집니다.

제 글의 논지는 사실 이 시차에 기대고 있습니다. 기술은 빠르고 제도는 느리니까 그 사이에 사람이 필요하다는 것. 그런데 이건 영구적인 이유가 아니라 과도기의 이유입니다. 시차가 닫히면 논지도 같이 약해집니다.

그럼 시차가 닫힐 때 개발자는 어디 있을까요. 저는 모릅니다. 다만 닫히는 순서는 짐작해볼 수 있습니다.

책임이 먼저 넘어가는 건 아마 위험이 작고 반복적이고 결과가 좁은 영역일 겁니다. 틀려도 되돌릴 수 있고, 틀린 걸 금방 알 수 있고, 틀렸을 때 손해가 계산 가능한 자리. 이런 데는 이미 넘어가고 있습니다. 스팸 판정이나 이상 거래 1차 탐지 같은 건 사람이 하나씩 결재하지 않은 지 오래됐고, 아무도 그걸 책임 공백이라고 부르지 않습니다. 틀리면 되돌리면 되고, 되돌리는 비용이 사람을 붙이는 비용보다 싸기 때문입니다. 반대로 결과가 되돌릴 수 없거나, 여러 이해관계가 얽혀 있거나, 무엇이 옳은지가 사람마다 다른 영역은 마지막까지 남을 겁니다. 거기서는 답을 계산하는 게 아니라 누군가 결정을 해야 하고, 결정에는 그 결정을 한 사람이 필요하기 때문입니다.

이 구분이 좀 잔인한 게, 계산 가능한 쪽이 대체로 배우기 쉬운 쪽이기도 하다는 점입니다. 조건이 명확하고 정답이 있는 일은 가르치기도 쉽고 익히기도 쉽습니다. 그래서 신입이 먼저 맡던 일이 정확히 그쪽이었고, 지금 먼저 빠져나가는 것도 그쪽입니다. 마지막까지 남을 영역은 원래부터 진입이 어려웠던 자리고, 그 자리에 가려면 지금 빠져나가는 쪽을 한참 거쳐야 했습니다. 사다리의 아래 칸부터 없어지는 셈입니다.

그러니까 준비한다는 게 의미가 있다면, 그건 그 마지막 영역 쪽으로 한 칸씩 걸어가는 일일 겁니다. 특정 기술을 새로 배우는 게 아니라요.

그리고 앞에서 낙관도 비관도 반증 불가능한 자리에 서 있다고 써놓고 제 글만 그대로 두면 앞뒤가 안 맞습니다. 무엇을 보면 제 판단을 바꿀지도 같이 적어두는 게 맞겠습니다.

셋 정도입니다. 하나는 계약과 보험 쪽입니다. 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년 뒤에 다시 읽으면 웃길 겁니다. 제 것도 포함해서요. 그때 뭐가 틀렸는지 확인하려면 지금 무엇을 근거로 그렇게 생각했는지가 남아 있어야 합니다. 결론만 적어두면 나중에 왜 틀렸는지도 모릅니다. 2편에서 의사결정의 "왜"를 남기라고 썼는데, 이 글도 그 용도입니다.

결국 개발자의 위치는

1편에서 개발자가 사라지는 게 아니라 개발자라는 말이 가리키는 대상이 바뀐다고 썼습니다. 다섯 편을 쓰고 난 지금도 그 문장은 그대로 두겠습니다.

다만 거기에 한 줄을 붙이고 싶습니다. 그 대상이 바뀌는 속도가 사람이 적응하는 속도보다 빠를 수 있다는 것.

이게 진짜 문제라고 봅니다. 자리가 없어지는 게 아니라, 자리는 있는데 거기 서 있으려면 매년 다른 사람이 되어야 하는 상황. 이건 개인의 노력으로 해결되는 종류가 아닙니다. 그래서 "판단 근육을 기르세요" 같은 말이 절반은 맞고 절반은 무책임합니다. 기를 수 있는 조건에 있는 사람에게만 맞는 말이니까요.

저는 이 시리즈에서 계속 남는 자리 얘기를 했는데, 마지막에는 이 말도 같이 적어두는 게 맞을 것 같습니다. 남는다고 해서 편한 건 아니고, 남는 자리가 넓어진다고 해서 그 자리에 들어갈 수 있는 사람이 늘어나는 것도 아닙니다.

그래도 지금 할 수 있는 게 아무것도 없다고 생각하지는 않습니다. 앞의 네 편에서 쓴 것들이 그 답입니다. 우리 시스템에서 무엇이 지켜져야 하는지 알고 있을 것, 결과를 설명할 수 있을 것, 도구를 자기 일에 맞게 갈아 쓸 것. 이건 AGI가 오든 안 오든 손해 보는 투자는 아닙니다. 셋 다 이 기술이 나오기 전에도 값을 하던 것들이고, 그래서 예측이 틀려도 버려지지 않습니다.

제가 이 시리즈에서 확신하는 건 사실 그 정도까지입니다. 어떤 미래가 오든 손해 안 보는 것들을 골라두는 것. 그 이상은 예측인데, 예측은 대체로 틀립니다.

3년 뒤에 지인을 다시 만나면 이 글을 같이 열어보게 될 것 같습니다. 그때 뭐가 맞았고 뭐가 틀렸는지 확인하려고요. 그리고 이게 관찰이었는지 희망이었는지도 그때쯤이면 알 수 있을 겁니다.