AI가 생성한 코드의 타당성을 검증하는 능력을 생각하다 보니, 제 존재 의미가 게슈탈트 붕괴했습니다

엔지니어에게는 흔히 '자신의 일을 없애는 일을 하라'고 말하곤 합니다.

저 역시 지금까지 GitHub Actions나 GAS를 사용해 번거로운 작업을 자동화하는 데 전력을 다해왔습니다. 최근에는 생성형 AI(Generative AI)에 '이것을 자동화할 스크립트를 작성해 줘'라고 던지기만 하면, 순식간에 깔끔한 코드가 돌아오는 시대입니다.

'와, 정말 편해졌구나.'

그렇게 생각하며 AI와 '자동화의 미래'에 대해 벽치(사고 토론)를 하고 있었습니다. 그 과정에서 문득, 등골이 오싹할 정도의 치명적인 막연함에 부딪혔습니다.

그 질문은 이것입니다.

'AI가 몇 초 만에 뱉어낸 고도화된 처리를, 앞으로 우리는 어떻게 '정말로 맞는가(타당성)'를 체크해야 할까?'

처리를 만드는 것은 순식간이지만, 그것을 평가하는 우리의 '눈'이 지금 엄청난 위기에 처해 있는 것이 아닐까요? 이번 글에서는 AI와의 대화에서 보인 엔지니어의 '평가력 위기'와 도저히 답을 내릴 수 없는 '육성(교육)의 모순', 그리고 그 너머에 있는 깨달음에 대해 공유하겠습니다.

토론 과정에서 다시 한번 충격을 받은 것이 1983년에 제창된 **자동화의 역설(Ironies of Automation)**이라는 유명한 이야기입니다.

요약하자면 이렇습니다.

'시스템을 자동화할수록 인간은 편해지지만, 막상 자동화를 예상했던 범위를 넘어서는 대형 트러블(미지의 버그 등)이 발생했을 때, 시스템은 그 문제를 사람에게 떠넘긴다. 하지만 평소에 편하게 지내는 인간에게는 그 중대한 트러블을 해결할 수 있는 스킬(기반 지식) 자체가 남아있지 않다.'

지금 개발 현장에서 바로 이것이 일어나고 있지 않나요?

평소에는 AI가 코드를 작성하고 CI/CD가 자동으로 배포해 줍니다. 하지만 만약 파이프라인이 알 수 없는 오류로 고장 나거나, AI의 코드에 미묘한 버그가 심어져 있을 때, 시스템을 블랙박스처럼 사용했던 주니어(혹은 자기 자신)가 아무도 고칠 수 없게 되는 공포입니다.

AI는 순식간에 대량의 코드나 복잡한 구성을 만들어주지만, 인간의 뇌(작업 기억/Working Memory) 용량은 예전부터 변하지 않았습니다.

코드를 '작성하는' 비용이 제로가 된 결과, '타인이 (AI가) 작성한 복잡한 시스템을 올바르게 이해하고 검증하는' 뇌의 비용이 비정상적으로 높아지고 있습니다.

게다가 인간에게는 'AI가 깔끔하게 작성한 코드니까 괜찮겠지'라고 방심하는 편향(Bias)이 있습니다. 한 줄씩 코드를 읽으며 버그를 찾는 기존의 '디버깅(Debugging)'은, 인간 뇌의 한계로 인해 이미 끝을 맞았을지도 모릅니다.

여기서 저 자신 안에서 더 큰 '질문(혹은 답할 수 없는 공포)'가 커지고 있습니다.

저희처럼 'AI가 없던 시대'를 경험한 엔지니어는 과거에 직접 손으로 만져가며 번거롭게 코드를 작성해 온 '기반 지식'이 있습니다. 그렇기에 AI가 내놓은 결과물에 대해 '어, 이거 뭔가 이상한데'라는 직감이 작동합니다.

하지만 처음부터 AI가 옆에 있고, AI가 코드를 작성하는 것이 당연한 시대에 들어온 신입이나 주니어는, 도대체 어떻게 그 '타당성을 간파하는 관점'을 키워야 할까요?

예전에는 '직접 코드를 작성하는 것' 자체가 시스템을 이해하기 위한 최대의 훈련(기반 지식 만들기)이었습니다. 하지만 지금은 AI에게 맡기는 시대입니다. 쓰는 기회가 사라진다면, '검토하는 관점(평가력)'을 갈고닦는 수밖에 없습니다.

그렇다면, '무엇을 기준으로 그 검토 관점을 가져야 할까요?'

아마도 앞으로의 교육은 '이론 학습(코드 설계 패턴이나 안티패턴 지식)'이 중심이 될 수밖에 없다고 예상합니다.

깊이가 얕은 지식 기반의 검토 관점(체크 기준)이라면, 그것이야말로 프롬프트나 CI 메커니즘(하우징/Harness)으로 녹여내어 인간이 체크할 필요조차 없어질 것입니다. 나아가 '비즈니스 맥락(Context)'마저도 사양이나 도메인 지식을 인풋으로 AI에게 먹여버리면, AI는 그것에 맞춰 최적의 평가를 해낼 수 있을 것입니다.

그렇다면 자동화 메커니즘을 한계까지 정비한 세상에서, 신입이나 주니어가 '이론 학습을 넘어선', AI를 능가하는 『진짜 평가력』을 습득할 경로는 어디에 남아있을까요?

겨우 억지로 말하자면, 이론 학습으로 얻은 지식을 기반으로 'AI의 코드를 체크하는 메커니즘(시스템)'을 인간이 정비해 나간다고 가정해 봅시다.

하지만 이 메커니즘을 정비하기 위해서는 눈앞에 있는 소스 코드의 특성을 100% 이해하고 있어야 합니다.

'요즘 젊은 세대는 코드의 한 줄 한 줄이 아니라, 처음부터 시스템 전체의 데이터 구조나 아키텍처 레이어 단위로 머릿속에서 구축하고 있기 때문에, 구세대와 기반 다지기 방식이 다르다'는 긍정적인 의견도 있을 수 있습니다.

하지만, 직접 써보고, 실패하며, 밑바닥부터 구르는 경험이 없는 사람이, 그저 화면에 표시된 소스 코드(Source Code)를 「읽기만」 해서 그 진정한 특성이나 구조를 정말로 이해할 수 있을까요?

지금 젊은 세대에게서 사라지고 있는 것은 「코드를 작성할 기회」만이 아닙니다. 「작성하며 실패할 기회」 그 자체가 사라지고 있는 것입니다.

앞으로 시대의 「실패」는 자신이 타이핑 실수를 했다는 수준이 아니라, AI가 출력한 내용이 막상 운영 환경(Production Environment)에서 제대로 작동하지 않았다는 형태가 될 것입니다.

그때 「왜 실패했는가?」를 이해하려고 한다면, 결국 AI가 뱉어낸 복잡한 소스 코드를 끝까지 깊게 파헤치며 그 이면에 있는 사양(Specification)을 추적할 수밖에 없습니다.

「제로(Zero)에서 쓰지 않아도, AI에게 내용을 해설하게 하거나 (화이트박스화 (White-boxing)) 할 기회가 있으니 괜찮다」라는 의견도 있을 것입니다.

하지만 실제 개발 현장은 그렇게 만만하지 않다고 저는 생각합니다.

AI가 내놓는 코드가 「어쩐지 한 번에 작동해 버린다면」, 현장의 사람들은 「일단 돌아가고 있고, 테스트도 통과했으니 OK!」라며 내용을 읽지 않고 그냥 넘어가 버리는 것이 현실이 아닐까요.

왜냐하면, 「대체로 문제없으니까」 입니다.

굳이 시간과 뇌의 메모리(Memory)를 써가며 작동하는 코드의 내용을 구석구석 밝혀내는 일은, 납기에 쫓기는 현장에서는 인센티브가 작동하지 않습니다. 결과적으로 화이트박스화할 수단은 있음에도 불구하고, 현장의 역학 관계상 「블랙박스 (Black-box) 상태로 진행하는 것」이 최적해(Optimal Solution)가 되어 버립니다.

그렇게 「대체로 문제없음」을 쌓아가며 나아간 끝에, 어느 날 갑자기 자동화 하네스(Harness)도 AI의 예측도 빠져나가는 『치명적인 문제』를 밟게 되는 순간이 찾아옵니다.

그때 우리에게, 혹은 신입이나 젊은 세대에게 그것에 대응할 수 있는 「기반(下地)」은 남아 있을까요? 여기서 완전히 머리가 버그(Bug)가 나는 듯한 모순(Loop)에 빠지게 됩니다.

루트 1: AI에게 코드를 쓰게 하고, 평소에는 대체로 문제가 없으니 블랙박스 상태로 진행한다. 하지만 치명적인 문제를 밟았을 때, 왜 실패했는지를 이해하기 위해 스스로 쓰는 것 이상의 뇌 비용을 지불하며 타인(AI)의 코드를 처절하게 읽어낸다. -
루트 2: 예전 방식 그대로, 처음부터 직접 손을 움직여 코드를 쓰고, 스스로 실패하며 기반을 단련한다.

이것은 효율화의 가성비(타이파, Time Performance)를 추구하기 위해 루트 1을 선택했을 텐데, 엔지니어의 성장이나 만약의 사태를 대비한 생존 전략의 가성비로서는 최악의 함정에 빠져 있는 것이 아닐까요.

AI 덕분에 편해지려고 AI를 사용하고 있는데, 정작 만약의 사태를 위해 스스로 쓰는 것 이상의 뇌 비용을 지불하며 코드를 읽어야만 한다.

우리는 도대체 무엇을 위해 자동화를 하고, 어디를 향해 가고 있는 것일까요. 정말로 모르겠습니다.

……라고, 여기까지 머리를 싸매고 고민하다가 저는 또 하나의 거대한 모순을 깨달았습니다.

내가 「기반이 부족해질 것이다」, 「타당성을 평가할 수 없게 될 것이다」라며 두려워하는 것은, 「직접 코드를 써서 실패한다」는 구시대의 잣대를 그대로 미래에 적용하려고 하기 때문이 아닐까 하는 점입니다.

패러다임 시프트(Paradigm Shift)가 일어나고 있는 한복판에서, 과거의 잣대를 끌어안은 채 「미래의 육성」이나 「기술의 필요성」을 논하는 것 자체가 애초에 무의미한 일일지도 모릅니다. 주판의 달인이 계산기의 등장을 두려워했듯이, 우리는 단순히 「변해가는 OS」에 대해 오래된 가치관으로 경종을 울리고 있는 것뿐일지도 모릅니다.

그렇다면 우리는 앞으로 무엇을 기준으로, 어떻게 메커니즘이나 육성 체계를 정비해 나가야 할까요?

답은 아마도, 그때마다 탐색적으로 적응해 나갈 수밖에 없다고 생각합니다.

미래의 정답을 가진 사람은 아무도 없습니다. AI의 진화 속도에 맞춰 발생한 과제에 대해 그때마다 부딪히며, 실시간으로 「적응적인 최적해」를 처절하게 계속 내놓는 것. 그 실험과 애자일(Agile)한 적응 프로세스의 연속이야말로 새로운 시대의 엔지니어가 갖춰야 할 「기반」이 되어가는 것일지도 모릅니다.

「과거의 잣대」가 완전히 부서지고, 치명적인 문제조차 AI가 고치게 되어 인간이 코드를 읽지 않아도 되는 세상이 올지도 모릅니다.

솔직히 말해서 미래가 어떻게 변하든 그것은 시대의 변화이며, 딱히 상관없다고조차 생각합니다. 엔지니어의 존재 의의니 가치니 하는 거창한 이야기에 겁을 먹고 있는 것도 아닙니다.

다만, 현장의 최전선에 있는 한 명의 개발자로서, 「그렇다면 우리는 앞으로 구체적으로 어떤 방침으로 시스템을 정비하고, 어떻게 나아가야 하는가」를 순수하게 모르겠습니다.

정답이라는 척도가 없는 과도기 속에서도, 그럼에도 내일의 개발은 계속해서 진행됩니다.

이러한 정답의 로드맵 (Roadmap)이 없는 시대에, 어떤 방침으로 구조를 정비하거나 팀을 움직여야 하는 것일까요?