AI가 엔지니어에게 주는 가장 위험한 것: 거짓 자신감

Source: Dev.to

(번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 내용을 알려주시면 도와드리겠습니다.)

소개

지난 몇 년 동안 저는 주로 프론트엔드 엔지니어로 일했습니다. 백엔드에 대한 대역폭이 부족할 때 간단한 문제를 해결하기 위해 가끔씩 백엔드에 뛰어들었지만, 제 작업의 초점은 언제나 프론트엔드에 있었습니다.

AI 도구들의 도움을 받아 최근에는 백엔드 작업을 더 많이 하고 있습니다. 새로운 POST 엔드포인트와 몇 가지 데이터베이스 업데이트가 필요한 기능이 있었습니다. 변경 사항은 비교적 직관적이었지만, 오랜만에 하는 일이고 익숙하지 않은 서비스였기 때문에 다소 복잡했습니다. 인근 서비스에서는 백엔드 작업을 많이 해봤지만, 이 서비스에서는 그리 많이 해본 적이 없었습니다. 그래도 변경 사항이 간단해 보였기에 크게 생각하지 않았습니다.

그래서 바로 시작했습니다. AI 도구에 작업을 맡기고 자유롭게 진행하도록 했습니다. 모든 것이 괜찮아 보였어요! 가끔씩 수정해 주어야 했지만, 전체적인 흐름은 이해가 되는 듯했습니다. 작업을 계속 진행하면서 코드를 생성하고 필요에 따라 업데이트했습니다. 어느새 모든 작업이 끝났습니다!

그렇게 생각했지만…

PR을 열자마자 여러 개의 실패한 작업이 나타났습니다. “괜찮아,” 라고 생각했죠, “금방 해결할 수 있겠지.”

아니면, 그렇지 않을 수도 있겠죠.

결국 모든 것을 정리했지만, 그 과정에서 그 서비스에 대해 많은 것을 배웠습니다: 눈에 띄지 않았던 필수 체크, PR에서는 실행되지만 커밋/푸시에서는 실행되지 않는 작업, 그리고 제가 전혀 몰랐던 아키텍처 결정들 등.

놀라운 점은 실패 자체가 아니라, 풀 리퀘스트를 열기 전 제가 느꼈던 자신감이었습니다. 시스템을 충분히 이해하고 변화를 만들 수 있다고 생각했죠. AI가 빠르게 진행하도록 도와줬지만, 동시에 제 이해가 얼마나 얕은지 감추어 주었습니다.

그 자신감, 즉 실패보다 더 위험한 것은 AI가 엔지니어에게 제공한 가장 위험한 요소입니다.

거짓 자신감이 무지보다 더 나쁜 이유

시스템에 익숙하지 않다는 것을 알면 조심스럽게 움직입니다. 질문을 합니다. 주변 코드를 읽습니다. 데이터가 시스템을 통해 어떻게 흐르는지 추적합니다. 내부 나침반과 같은 자신의 지식에 의존하며 시스템을 탐색합니다.

그 시스템을 이해하고 있다고 생각하면 빠르게 움직이고 질문을 멈춥니다.

이것이 함정입니다. AI 도구는 최대한 도움이 되도록 설계되었습니다. 깨끗해 보이고, 패턴을 따르며, 합리적으로 보이는 코드를 생성합니다. 출력이 익숙하게 느껴지기 때문에 이해했다는 착각을 만들게 됩니다. 그리고 그 착각은 전염성이 있는데, 특히 이전에 해결한 유사한 문제와 AI의 출력을 패턴 매칭할 수 있는 경험 많은 엔지니어들에게 그렇습니다.

AI가 나를 위해 생성한 코드는 좋은 코드였습니다. 규칙을 따르고, 적절한 디자인 패턴을 사용했으며, 오류 없이 컴파일되었습니다. 하지만 “좋은 코드”와 “특정 시스템에서 동작하는 코드”는 동일하지 않습니다. AI는 암묵적인 제약조건, 아키텍처 경계, 혹은 내 실수를 잡아낼 CI 파이프라인 검증에 대해 알지 못했습니다.

이는 특히 경험 많은 엔지니어에게 위험합니다. 우리의 과거 성공이 AI가 볼 수 없는 빈틈을 메워줍니다. 코드는 충분히 익숙해 보여서 무슨 일이 일어나는지 안다고 가정하게 됩니다. 그러나 익숙함은 시스템이 압박을 받을 때 어떻게 동작하는지를 아는 것과는 다릅니다.

AI가 볼 수 없는 것

• 큰 시스템은 역사를 축적한다. 결정은 문서가 아니라 코드에 존재한다. 아키텍처는 시간이 지나면서 퇴화한다. 패턴은 느슨하게 적용된다. 때때로 고객에게 중요한 수정을 제공하기 위해 특정 측면을 타협하기도 한다. 시스템은 수백만 줄의 코드가 제약, 트레이드오프, 정치적 현실에 의해 형성된 역사적 유물—이는 AI가 코드만으로 추론할 수 없다.

• 아키텍처는 보이지 않는 경계로 존재한다. 특정 모델이 특정 레이어를 벗어나지 못하도록 하는 엄격한 경계가 있을 수 있다. 이것이 명확히 문서화되지 않으면 AI는 이를 놓친다. 모든 데이터베이스 테이블에 특정 감사 컬럼을 포함해야 한다는 규칙이 있을 수도 있다. AI는 CI 파이프라인이 실패할 때까지 이를 알지 못한다. 이러한 경계는 컴파일러가 아니라 사람과 프로세스에 의해 강제된다.

• 암묵적인 지식이 생존을 좌우한다. 내 경우, 문서나 코드를 읽어서 제약을 발견한 것이 아니다. 풀 리퀘스트가 내가 알지 못했던 방식으로 실패했을 때 제약을 알게 되었다. CI 파이프라인에 숨겨진 검사, 코드 리뷰에서만 적용되는 아키텍처 패턴, 그리고 팀 모두가 그냥 “알고 있다”고 생각하는 시스템에 대한 가정들이 있었다.

현재 어떤 AI 도구도 마음을 읽거나 복잡한 시스템에서 이루어진 모든 결정을 쉽게 추론할 수 없다. 그때까지는 인간이 루프에 참여해 깊은 사고와 방향 수정 작업을 해야 한다. 이런 시스템에서 정확성은 단순히 논리만을 의미하지 않는다. 코드 외부에 존재하는 역사, 위험, 그리고 맥락이 중요하다.

내가 해야 했던 일

돌아보면, 내 실수는 AI를 사용하지 않은 것이 아니라 내가 느낀 자신감을 믿은 것이었다.

AI가 코드를 건드리게 하기 전에 나는 다음을 해야 했다:

1. 서비스의 아키텍처 문서와 주변 코드를 30 분 동안 읽었다.
2. 최근 PR을 살펴보며 팀이 따르는 패턴과 일반적으로 문제가 되는 체크를 확인했다.
3. 팀원에게 물었다: “이 서비스에서 주의할 점은 무엇인가요?”

그 대신 나는 AI가 이미 이 모든 것을 알고 있는 듯한 느낌을 주도록 내버려 두었다.

해결책은 AI 도구를 피하는 것이 아니다—그렇다면 실제 이점을 포기하는 것이 된다! 해결책은 우리가 AI와 관계를 맺는 방식을 바꾸는 것이다. 좋은 엔지니어는 AI를 권위로 사용하지 않는다. 그들은 AI를 가속기로 활용한다.

AI를 과도한 자신감 없이 사용하는 방법

AI는 옵션을 생성하고, 패턴을 드러내며, 기계적인 노력을 줄여줄 수 있습니다. 하지만 시스템에 대한 정신 모델을 구축하는 것을 대체할 수는 없습니다.

익숙하지 않거나 복잡한 코드베이스에서 작업할 때는 자신감을 의도적으로 재구축해야 합니다. 이는 다음을 의미합니다:

• Read the surrounding code before accepting AI‑generated changes. Understand the patterns the codebase follows, not just the patterns the AI suggests.

(The original list was truncated here; retain the existing bullet as is.)

# AI‑Assisted Development: Stay Curious, Stay Safe

Guiding Principles

• 데이터 흐름을 추적하세요.
  시스템을 통해 데이터가 어떻게 이동하는지 따라가세요. 데이터는 어디서 오나요? 어디로 가나요? 그 과정에서 무엇이 변환되나요?

• 전문가에게 물어보세요.
  시스템을 잘 아는 사람들과 이야기하세요. 코드에 보이지 않는 이유—기술 부채, 과거 사고, 고객 요구사항, 성능 제약—가 항상 존재합니다.

• 중요한 것이 누락되었다고 가정하세요.
  모든 AI 출력은 증명될 때까지 불완전하다고 간주하세요. 이것은 편집증이 아니라 보정입니다.

A Helpful Shift

AI를 답변만이 아니라 질문을 생성하도록 사용하세요.

• 이 변경이 전제하는 가정은 무엇인가요?
• 이 엔드포인트가 예상치 못한 방식으로 사용될 경우 무엇이 깨질 수 있나요?
• 시스템의 어떤 부분에 간접적으로 영향을 미치나요?

AI는 우리가 더 빠르게 움직이도록 도와주지만, 언제 속여야 할지 알려주는 데는 능숙하지 않습니다. 그 책임은 여전히 엔지니어에게 있습니다.

실제 비용

AI는 우리가 코드를 생산하는 속도를 바꾸었습니다. 하지만 시스템을 이해한다는 의미는 바뀌지 않았습니다.

자신감은 여전히 맥락, 경험, 판단을 통해 얻어야 합니다. AI 도구가 당신을 더 호기심 있게 만들지 않고 자신감을 느끼게 한다면, 이미 위험에 처한 것입니다.

다음에 AI가 변화를 쉽게 만든다고 느낄 때, 멈추세요. 당신이 놓치고 있는 것이 무엇인지 스스로에게 물어보세요—AI가 틀렸기 때문이 아니라, AI가 주는 자신감이 가장 중요한 이해의 틈을 가릴 수 있기 때문입니다.

실행 항목

• 이번 주에 최근에 적용한 AI‑생성 변경 사항 하나를 골라 시스템 전체를 추적해 보세요.
• 처음에 놓쳤던 점을 기록하세요.

기억하세요: Claude나 Cursor가 당신을 10배 엔지니어처럼 느끼게 할 때, 실제로는 아직 보지 못한 문제를 향해 10배 속도로 움직이는 1배 엔지니어일 뿐일 수 있습니다.