Norberto Lopes의 글 Growing as an engineer in a world of AI는 AI가 코드를 대부분 작성하는 환경에서 엔지니어가 어떻게 성장해야 하는지 묻는다. 저자는 AI 사용을 거부하지 않는다. 오히려 AI를 매일 사용하는 엔지니어이자 지난 10년 동안 채용·온보딩·멘토링을 해 온 사람으로서, AI를 단순한 결과 생산기가 아니라 학습을 가속하는 동료로 사용해야 한다고 주장한다.

원문은 AI가 주니어 엔지니어를 곧바로 대체한다는 주장보다 더 중요한 질문을 던진다. AI가 학습이 일어나는 과정을 너무 쉽게 만들어 버릴 때, 사람은 무엇을 통해 실력을 쌓는가?

1. 문제는 채용보다 성장 방식에 있다

AI 때문에 기업이 시니어만 원하고 초기 경력 엔지니어에게 기회가 사라질 것이라는 우려가 커지고 있다. 저자는 채용 시장의 변화 자체보다, 초기 경력 엔지니어가 AI 시대에 계속 배울 수 있는지가 더 중요한 문제라고 본다.

저자가 지난 10년 동안 빠르게 성장한 엔지니어들에게서 발견한 공통점은 특정 도구를 빨리 다루는 능력이 아니었다. 뛰어난 커뮤니케이션, 끈기, 호기심, 강한 오너십, 그리고 매우 빠르게 배우는 능력이 공통적으로 나타났다. 도구는 바뀌지만 이 특성들은 여전히 중요하다.

다만 성장에 필요한 환경은 달라졌다. 과거에는 답을 찾기 위해 문서를 읽고, 코드를 실행하고, 실패 원인을 추적하는 시간이 자연스럽게 발생했다. 지금은 AI에게 질문하면 몇 초 안에 실행 가능한 답을 받을 수 있다. 문제는 답을 얻는 시간이 줄어든 만큼, 답을 이해하고 자신의 지식으로 바꾸는 시간을 의식적으로 만들어야 한다는 데 있다.

2. 학습에 필요한 마찰과 낭비를 구분해야 한다

저자는 엔지니어가 성장하던 과거의 과정을 ‘마찰’로 설명한다. 문서가 쉽게 이해되지 않아 여러 번 읽고, 데이터베이스 쿼리가 느린 이유를 직접 추적하고, 오류 메시지를 읽으며 다시 시도하는 과정이다. 이런 과정은 느리고 답답하지만, 호기심과 반복을 통해 문제를 해결하는 감각을 만든다.

모든 마찰이 가치 있는 것은 아니다. 같은 CRUD 엔드포인트를 수십 번 손으로 작성하는 일처럼 단순 반복과 불필요한 대기 시간은 AI가 줄여도 된다. 그러나 다음과 같은 마찰은 학습을 위해 남겨 둘 가치가 있다.

  • 문제를 작은 단위로 쪼개고 가설을 세우는 과정
  • 오류 메시지와 관측 데이터를 읽으며 원인을 좁혀 가는 과정
  • 여러 설계 대안을 비교하고 맥락에 맞는 선택을 하는 과정
  • 답을 보기 전에 자신의 설명과 해결책을 먼저 만들어 보는 과정

학습 과학에서 말하는 desirable difficulties와 generation effect도 이 지점을 설명한다. 당장은 어렵고 느리더라도 스스로 답을 만들어 보는 경험이 단순히 완성된 답을 읽는 것보다 오래 남는다. 따라서 AI 시대의 핵심은 마찰을 모두 제거하는 것이 아니라, 성장을 만드는 마찰과 단순한 낭비를 구별하는 것이다.

3. 가장 위험한 상태는 작동하지만 설명할 수 없는 코드다

AI는 느린 쿼리를 고치거나 특정 패턴을 구현하는 답을 빠르게 제시한다. 초기 경력 엔지니어가 여기서 멈추면 최악의 상황이 생긴다. 코드는 작동하지만, 왜 그 방식을 선택했는지 설명할 수 없게 된다.

이 상태에서는 코드 리뷰가 형식적인 승인 절차로 변한다. 작성자는 자신이 만든 코드의 가정과 실패 조건을 모르고, 리뷰어도 결과물의 표면만 확인하게 된다. 평소에는 문제가 드러나지 않다가 장애가 발생하거나 요구사항이 바뀌는 순간, 이해되지 않은 코드의 비용이 한꺼번에 나타난다. 저자는 이를 인지 부채에 가까운 문제로 본다.

원문은 2025년 MIT Media Lab의 소규모 연구를 조심스럽게 인용한다. LLM을 사용해 에세이를 작성한 집단이 검색 엔진이나 도움 없이 작성한 집단보다 뇌 연결성과 내용 회상에서 약한 결과를 보였다는 연구다. 저자도 장기 연구가 아니므로 과도하게 일반화해서는 안 된다고 전제한다. 그럼에도 이 비유는 AI가 작성한 풀 리퀘스트를 작성자가 설명하지 못하는 상황을 생각하게 한다. 연구의 수치를 소프트웨어 개발에 그대로 적용할 수는 없지만, 생산과 이해가 분리될 때 생기는 위험은 분명히 점검할 가치가 있다.

4. AI 사용으로 놓치기 쉬운 네 가지 성장 자산

성장 자산AI를 과하게 위임할 때 놓치는 것
반복과 직관같은 유형의 문제를 직접 다루며 무엇인가 이상하다는 감각을 쌓는 과정
디버깅 직관증상·가설·관측 결과를 연결해 원인을 좁히는 능력
시스템 설계패턴의 존재가 아니라 현재 팀과 제품에 그 패턴이 맞는지 판단하는 능력
데이터 모델 사고스키마와 정규화·비정규화 선택의 이유, 그리고 잘못된 선택의 결과를 이해하는 능력

특히 디버깅은 AI가 정답처럼 보이는 후보를 제시한다고 해서 자동으로 습득되지 않는다. 실제 시스템에서 무엇을 관측해야 하는지, 어떤 가설부터 버려야 하는지, 로컬에서는 되지만 스테이징에서는 실패하는 이유가 무엇인지 직접 추적해야 한다.

시스템 설계도 마찬가지다. AI는 요청하면 두 명으로 구성된 팀에도 마이크로서비스 구조를 만들어 줄 수 있다. 하지만 좋은 엔지니어는 패턴을 많이 아는 사람이 아니라, 현재의 규모·팀 역량·운영 부담·변경 가능성을 함께 보고 필요한 복잡성만 선택하는 사람이다.

반대로 AI가 제공하는 기회도 있다. AI가 만든 코드를 진지하게 읽고 비판하면 코드 리뷰가 비판적 사고를 훈련하는 장이 될 수 있다. 구현 시간이 줄어든 만큼 동료와 시스템 설계 대화를 더 깊게 할 수도 있다. AI가 팀의 회의, 조직의 변화, 고객과의 긴장, 잘못된 요구사항까지 모두 알 수는 없으므로, 엔지니어는 결과를 지휘하고 트레이드오프를 판단하는 역할에 더 집중해야 한다.

5. AI를 학습 가속기로 사용하는 방법

답보다 이유를 먼저 묻는다

AI에게 코드를 요청한 뒤 바로 다음 작업으로 넘어가지 않는다. 다음 질문을 반복해서 던진다.

  • 왜 이 패턴을 선택했는가?
  • 다른 접근법은 무엇이며 각각의 비용은 무엇인가?
  • 입력이나 요구사항이 바뀌면 무엇이 깨지는가?
  • 이 코드가 실패할 수 있는 경계 조건은 무엇인가?
  • 내가 놓친 운영·보안·성능상의 가정은 무엇인가?

AI는 판단을 대신하는 도구가 아니라, 질문을 확장하는 도구로 사용할 때 학습 효과가 커진다. 부담스러워서 시니어에게 바로 묻기 어려운 기초 질문을 AI에게 먼저 던지는 것도 유용하다. 다만 AI의 설명으로 대화를 끝내지 말고, 더 나은 질문을 만든 뒤 동료와 실제로 논의해야 한다.

자신의 멘탈 모델을 먼저 만든다

코드를 붙여 넣기 전에 먼저 읽고, 자신의 방식으로 동작을 설명해 본다. 가능하면 AI에게 작은 코드 조각을 단계별로 요청하고 직접 입력한다. 입력 자체가 목표는 아니다. 직접 쓰는 동안 이해하지 못한 부분에서 멈추게 되고, 그 멈춤이 학습을 만든다.

좋은 순서는 다음과 같다.

  1. 문제와 제약을 자신의 말로 적는다.
  2. 해결 방법을 먼저 추측하고, 간단한 구현을 시도한다.
  3. 막힌 지점과 오류를 AI에게 보여 주며 설명을 요청한다.
  4. AI의 답을 그대로 복사하지 않고, 선택 이유와 대안을 비교한다.
  5. 완성된 코드를 자신의 언어로 설명하고 작은 변형을 직접 만들어 본다.

AI가 절약해 준 시간은 생각을 생략하는 데 쓰지 않고, 더 어려운 생각에 써야 한다.

책과 Unix 도구로 기반을 다진다

AI는 질문에 답할 수 있지만, 잘 구성된 교재를 따라가며 형성되는 정신 모델을 단번에 전달하지는 못한다. 원문은 다음 책들을 예시로 든다.

모든 책을 처음부터 끝까지 읽어야 한다는 뜻은 아니다. 중요한 것은 AI가 만들어 준 설명을 소비하는 데 그치지 않고, 오래 축적된 개념과 정신 모델을 직접 따라가는 경험을 확보하는 데 있다.

Unix 학습도 같은 맥락이다. AI에게 셸 명령을 만들어 달라고 하기 전에 터미널에서 grep, sort, uniq, awk를 조합해 로그를 직접 읽어 본다. man, apropos, info를 사용하면 당장 찾던 답뿐 아니라 관련된 주변 지식까지 발견할 수 있다. 명령어의 결과보다 작은 도구들이 어떻게 조합되어 시스템을 설명하는지가 중요하다.

문서와 대화로 이해를 외부화한다

문서를 쓰면 코드를 읽을 때보다 더 강하게 이해를 점검하게 된다. 무엇을 만들었는지, 어떤 가정을 했는지, 어떤 선택지를 버렸는지 설명해야 하기 때문이다. 잘 문서화된 코드베이스는 사람의 학습뿐 아니라 AI의 결과 품질에도 도움을 준다.

또한 자신이 직접 쓴 부분과 AI가 생성한 부분을 매니저·리뷰어·자신에게 명확히 밝히는 것이 좋다. 이는 감시를 위한 표식이 아니라 코칭과 리뷰의 초점을 맞추기 위한 정보다. 결과물만 평가해 달라고 요청하지 말고, 내가 세운 가정과 사고 과정도 리뷰해 달라고 요청해야 한다.

아키텍처 논의, 설계 리뷰, 장애 회고, 시니어와의 페어링도 계속 필요하다. 여러 시스템을 넘나드는 디버깅, 조직의 맥락 이해, 이해관계자와의 커뮤니케이션, 요구사항이 잘못되었다고 판단하는 일은 프롬프트를 잘 작성하는 능력과 다른 종류의 역량이다. 이런 역량은 경력이 쌓일수록 복리처럼 커진다.

6. 성장의 책임은 개인에게만 있지 않다

초기 경력 엔지니어에게 AI를 잘 사용하라고 말하는 것만으로는 충분하지 않다. 엔지니어링 매니저는 단기 속도만 최적화하지 않고 학습할 시간을 보장해야 한다. 성과 체계가 처리량만 측정하면, 구성원은 AI를 최대한 많이 사용하고 기초 역량을 발전시키지 않는 방향으로 유도된다.

AI가 산출량의 격차를 줄일수록 평가 기준은 다른 곳으로 이동해야 한다. 판단력, 디버깅 능력, 시스템 이해, 불확실성 속에서의 의사결정, 결과의 품질과 영향이 더 중요해진다. 코드 줄 수나 생성된 풀 리퀘스트 수만으로는 이러한 차이를 측정할 수 없다.

채용에서도 같은 원칙이 적용된다. 원문은 초기 경력 채용을 완전히 중단하면 3~5년 뒤 시니어 인재 파이프라인이 고갈될 수 있다고 지적한다. AI를 활용해 팀이 더 작고 시니어 중심으로 운영될 가능성은 있지만, 그렇다고 성장 중인 인재를 없애는 것은 단기 생산성을 위해 미래의 역량 공급을 포기하는 결정이 된다.

저자는 특히 미드레벨 엔지니어가 위험한 위치에 놓일 수 있다고 본다. 아직 지식의 공백이 있지만 결과물의 표면은 AI로 쉽게 비슷해질 수 있기 때문이다. 따라서 기업은 직급이나 산출량보다 실제로 무엇을 이해하고, 어떤 판단을 내리며, 결과에 어떤 책임을 졌는지를 보아야 한다.

결론 및 시사점

한 줄 결론: AI는 학습을 대신하는 지름길이 아니라, 더 깊은 사고와 실험에 시간을 재배치하는 도구로 사용해야 한다.

AI는 초기 경력 엔지니어에게 이전 세대보다 강력한 도구와 지식 접근성을 제공한다. 빠르게 만들고, 모르는 것을 질문하고, 다양한 대안을 실험할 수 있다는 점은 분명한 장점이다. 하지만 그 장점이 기초를 건너뛰는 이유가 되어서는 안 된다.

성장하는 엔지니어는 AI에게 결과만 요구하지 않는다. 답의 이유를 묻고, 대안을 비교하고, 자신이 먼저 세운 가설과 충돌시키며, 직접 읽고 쓰고 설명한다. 반복과 디버깅, 책과 Unix, 문서와 동료와의 대화에서 얻는 마찰을 의도적으로 남긴다.

조직도 초기 경력 인재의 성장을 비용이 아니라 미래의 역량 파이프라인으로 보아야 한다. AI 시대에 더 가치 있는 사람은 코드를 가장 많이 생산하는 사람이 아니라, 무엇을 만들어야 하는지 판단하고, 시스템을 이해하며, 결과에 책임질 수 있는 사람이다.