「왜 여기서 이 타입을 사용하고 있나요?」

동료에게 그런 질문을 받았을 때, 내 입에서 나온 말은 「잠시만 조사해 보겠습니다」였다. 구현을 담당하고 있는 것은 나인데, 그 자리에서 바로 설명하지 못한다. 동작은 한다. 테스트도 통과했다. 하지만 왜 그렇게 작성했느냐고 물으면 말문이 막힌다. AI 코딩 툴이 보급되면서, AI에 의한 구현이 늘어나고 있는 폐해가 조금씩 나타나기 시작하고 있다.

AI 코딩 툴을 사용하기 시작한 이후, 생산성은 분명히 올라갔다. 새로운 라이브러리 도입도, 에러 해결도, 이전이라면 반나절이 걸렸을 작업이 수십 분 만에 끝난다. 그리고 그것은 사실이다. 다만 내가 「코드를 작성할 수 있는 엔지니어」가 아니라, **「코드를 AI에게 생성하게 해서 작성할 수 있는 것처럼 느껴지는 엔지니어」**가 되어가고 있다는 사실을 깨달았다.

돌이켜보면 나의 경우, 주로 다음과 같은 4가지 요인이 겹쳐 있었다.

컨텍스트(Context) 부족

사용하고 있는 라이브러리의 설계 사상이나, 그 툴이 왜 그 API 디자인을 채택하고 있는지를 이해하지 못한 채, AI에게 질문하여 요구 정의에 따라 만들어 달라고 하고 있다. 표면적으로는 동작하며 에러도 없지만, 근본적인 이해가 수반되지 않는다. -
「동작함 = 옳음」의 오인

에러가 나지 않는다, 테스트가 통과한다. 그것만으로 「이해하고 있다」고 착각했다. 하지만 에러가 나지 않는 것과, 왜 그 구현이 옳은지를 설명할 수 있는 것은 전혀 별개의 문제다. -
사고의 외주화

본래의 엔지니어링으로서 새로운 기능을 구현할 때 「어떤 설계로 할까」, 「이 데이터 흐름이라면 어떤 패턴이 맞을까」라고, 우선 그 사람 자신의 머리로 생각했을 것이다. 그런데 AI를 사용하기 시작한 이후로는, 그 공정이 통째로 「AI에게 issue를 전달하고, 계획을 세우게 하고, 규칙을 참조하게 하여 구현 형식을 통일시킨다」는 흐름으로 대체되어 있었다.

내가 하고 있는 것은 설계 판단이 아니라, AI가 잘 동작하기 위한 환경 정비가 되어 있었다. 문제의 분해나 설계 판단과 같이, 실무 경험을 통해 본래 익혀야 할 스킬을 자신도 모르게 AI에게 맡겨버리고 있었던 것이다.

회고하는 시간을 갖지 않음

이것이 실무에서는 가장 큰 요인일지도 모른다. 업무에는 기한이 있다. 「동작했다면 OK」라며 다음 태스크로 넘어가고, 자신이 작성한 코드를 회고할 시간을 확보하지 않는다. 납기가 있는 상황에서 이해를 깊게 하기 위한 시간은 의식적으로 만들지 않으면 영원히 생기지 않는다. 결과적으로 「어떻게든 동작하는」 코드를 어떻게든 알고 있는 것처럼 착각하며, 자기 자신의 스킬로 습득하지 못한다.

이 문제 의식을 가지고 있는 것은 나뿐만이 아니었다. 해외에서도 같은 테마가 연구·논의되고 있다.

InfoWorld의 기사에서는, Anthropic의 연구 팀이 52명의 주니어 개발자를 대상으로 실시한 실험이 소개되고 있다.

실험에서는 개발자를 「AI 사용 그룹」과 「AI 미사용 그룹」으로 나누어, 경험이 없는 Python 라이브러리를 사용한 과제를 수행하게 한 후, 이해도 테스트를 실시했다. 결과,

AI 사용 그룹은 AI 미사용 그룹보다 테스트 점수가 17포인트 낮았다. 특히 디버깅이나 코드 독해력에서 큰 차이가 나타났다.

흥미로운 점은, AI 이용자 스스로가 그 상태를 자각하고 있었다는 점이다. 그들은 「게을러졌다」, 「이해에 아직 많은 격차가 있다」고 보고했다. 반면, AI를 사용하지 않은 그룹은 과제를 「즐거웠다」고 느꼈으며, 라이브러리에 대한 이해가 깊어졌다고 실감했다.

단, AI를 사용한 전원의 점수가 낮았던 것은 아니다. AI에게 코드 생성뿐만 아니라 「왜 그렇게 쓰는가」라는 개념적인 질문을 던진 개발자는 높은 점수를 유지하고 있었다. 즉, 문제는 AI를 사용하는 것 자체가 아니라, 사용법에 있다는 것이다.

Rithwik Shetty 씨의 기사에서는, Andrej Karpathy가 제창한 **「인텔리전스 브라운아웃 (intelligence brownout)」**이라는 개념이 소개되고 있다.

이는 AI 시스템이 완전히 정지하는 것이 아니라 부분적으로 사용할 수 없게 되는 상태를 가리키는데, 그때 느끼는 것은 단순한 불편함이 아니라, 자신의 판단력 자체가 흔들리는 감각이라고 한다.

AI를 사용할 수 없게 된 순간, 타이핑 속도뿐만 아니라 스스로 생각하고 판단하는 힘까지 잃어버렸다는 사실을 깨닫는다. 이것은 「툴을 사용할 수 없는 불편함」이 아니라 「사고의 의존」 문제다. 「AI는 단순한 툴이 아니라, 판단 프로세스 그 자체에 영향을 주는 존재다」라는 지적은 무겁다.

여기까지 읽고 「나도 해당될지도 모른다」고 느낀 사람도 있을 것이다. 다음은 자신의 AI 의존도와 이해도를 측정하기 위한 지표다. 위에서부터 차례대로 확인하며, 자신이 지금 어느 단계에 있는지 파악해 보길 바란다.

체크: AI가 작성한 코드를 각 행의 의미를 포함하여 구두로 설명할 수 있는가?

"이 변수는 왜 필요한가", "이 타입은 왜 선택되었는가", "예외 케이스(Exception case)는 어떻게 되는가". 이에 답할 수 없다면 아직 "알고 있다는 착각"의 단계에 머물러 있는 것이다. 우선은 AI가 내놓은 코드에 스스로 주석을 달아보는 것부터 시작할 수 있다.

체크: 사용 중인 라이브러리의 내부 코드나 문서(Documentation)를 읽어본 적이 있는가?

라이브러리를 블랙박스(Black box) 상태로 그대로 사용하고 있는 상태. 공식 문서를 읽고, 타입 정의(Type definition)를 확인하고, 내부 구현을 들여다보는 것. 그러한 한 걸음이 표면적인 이용에서 탈피하는 계기가 된다.

체크: AI 없이 동일한 기능을 스스로 작성할 수 있는가?

"작성할 수 없다"는 것은 "이해하지 못하고 있다"는 가장 명확한 신호다. 완전히 동일한 것을 토씨 하나 틀리지 않고 재현할 필요는 없지만, 처리 흐름(Process flow)을 의사 코드(Pseudo code)로 써 내려갈 수 있는지, 혹은 다른 접근 방식(Approach)으로 구현할 수 있는지가 시험대(Touchstone)가 된다.

체크: 코드 단독이 아니라 설계의 의도를 설명할 수 있는가?

"왜 이 책임 분리(Separation of concerns)를 했는가", "왜 이 디렉토리 구조인가", "왜 이 의존 관계(Dependency)인가". 개별 코드가 아니라 아키텍처(Architecture) 레벨에서 이야기할 수 있게 되면 이해의 질이 한 단계 올라간다.

체크: AI가 내놓은 코드의 문제점을 즉시 지적할 수 있는가?

"이것은 향후 깨질 것이다", "확장(Scale)되지 않는다", "밀결합(Tight coupling)되어 있다", "테스트가 어렵다", "타입 안전(Type safe)하지 않다". 이러한 판단을 자신의 경험과 지식에 기반하여 내릴 수 있는 상태가 최종 목표다. 이 레벨에 도달하면 AI는 위협이 아니라 레버리지(Leverage)가 된다.

AI는 의심할 여지 없이 강력한 도구다. 생산성을 높여주고, 패턴을 망라하며, 몰랐던 접근 방식을 알려준다.

하지만 그것을 "생성 장치"로서 계속 사용하는 한, 자기 자신의 기술력은 쌓이지 않는다. 버그의 원인을 추적할 수 없고, 설계를 설명할 수 없으며, 면접에서 막힌다. 그러한 문제들은 AI를 사용하기 시작한 직후에는 보이지 않지만, 확실하게 축적되어 간다.

최종적으로 지향해야 할 것은, **"AI에게 코드를 쓰게 하는 사람"이 아니라 "AI가 작성한 코드를 리뷰할 수 있는 사람"**이다.

이를 위해 필요한 것은 특별한 훈련 프로그램이 아니다. 생성된 것을 그대로 받아들이지 않고, 검증하고 이해하는 것이다. 예를 들어, AI에게 코드를 작성하게 한 직후에 다음과 같은 프롬프트(Prompt)를 던지는 것만으로도 이해도는 크게 달라진다.

이 코드의 설계상의 트레이드오프(Trade-off, 장단점)를 알려주세요.

이 구현에서 고려가 누락되기 쉬운 부분은 무엇인가요?

왜 다른 접근 방식이 아니라 이 방식을 권장했나요?

InfoWorld의 기사에서 소개되었던 전문가의 말이 인상 깊게 남아 있다.

**"기술의 쇠퇴는 현실적인 문제이지만, 그것은 피할 수 없는 것이 아니라 선택의 문제다"**라고.

AI와의 관계를 재고하는 것은 엔지니어로서의 자기 자신을 재고하는 것이기도 하다.