지난달에 주니어 팀원이 나에게 조용히 물었다.
“선배님, 솔직히 말씀해주세요. 우리 지금 배우고 있는 게 의미가 있는 건가요? AI가 다 짜줄 것 같은데요.”
나는 잠깐 침묵했다. 쉽게 “괜찮아"라고 할 수 없었다. 그 질문이 진짜 불안에서 나온 것을 알았고, 나도 같은 질문을 나 자신에게 가끔 던지기 때문이었다.
지금 실제로 무슨 일이 벌어지고 있는가 #
과장 없이 말해보자.
2026년 현재, Cursor나 Claude로 생성되는 코드의 비율이 팀마다 다르지만 평균적으로 전체 코드의 40~60%에 달한다는 이야기가 나온다. GitHub 자체 조사에서는 Copilot 사용자의 46%가 AI 제안 코드를 그대로 수용한다는 결과가 있었다.
하버드 연구는 더 직접적이다: AI 도입 후 6분기 만에 주니어 개발자 고용이 9~10% 감소했다. 시니어는 거의 변화 없이.
이건 팩트다. “AI가 개발자를 대체할 것인가"는 더 이상 추측이 아니라 진행 중인 현실이다. 적어도 특정 레벨의 특정 유형의 작업에서는.
그러면 어떻게 되는가?
사라지는 것과 남는 것 #
사라지는 것들:
- CRUD 보일러플레이트 코드 작성
- 문서에 나온 내용을 그대로 구현하는 작업
- 반복적인 테스트 케이스 작성
- 단순 리팩토링 (함수명 변경, 구조 정리)
- 스택오버플로에 있는 답을 조합하는 작업
솔직히 이 목록을 보면, 내 경력 초기에 “이게 나의 일"이라고 생각했던 것들의 상당수가 포함된다.
남는 것들:
- 문제를 제대로 정의하는 능력
- 요구사항의 모순을 발견하는 능력
- 시스템의 트레이드오프를 이해하고 선택하는 능력
- 실패를 예측하고 설계에 반영하는 능력
- 기술적 결정이 가져올 비즈니스 결과를 연결하는 능력
- 사람들과 함께 일하면서 방향을 조율하는 능력
이 목록을 보면 공통점이 있다. “왜"와 “무엇을"에 대한 판단, 그리고 인간 맥락 이해다.
AI는 “어떻게"를 점점 잘한다. “왜"와 “무엇을"은 여전히 인간의 영역이다.
가장 위험한 착각 — “AI를 잘 쓰면 된다” #
AI 도구 사용 능력이 중요해진 건 사실이다. 하지만 “AI 프롬프팅 잘 하는 사람"이 미래 엔지니어의 모습이라는 생각에는 동의하지 않는다.
이유가 있다.
프롬프팅 기술은 빠르게 범용화된다. 지금 Cursor를 잘 쓰는 게 차별점이 될 수 있지만, 1~2년 후에는 대부분이 잘 쓴다. 그 시점에 차별점은 무엇인가?
더 근본적으로, AI가 생성한 코드의 품질을 판단하는 능력은 결국 그 도메인의 깊은 이해에서 나온다. AI가 만든 회로 설계가 맞는지 틀린지를 판단하려면 전자공학을 알아야 한다. AI가 생성한 알고리즘이 최적인지 판단하려면 알고리즘을 알아야 한다.
“AI가 다 해줄 텐데 기초를 왜 배워요?“라는 질문의 역설은, AI가 생성한 것을 검증하려면 결국 기초가 필요하다는 것이다.
하드웨어 엔지니어의 관점 #
나는 소프트웨어만 하는 사람이 아니다. PCB를 설계하고 WPT 회로를 만지고 임베디드 펌웨어를 짠다.
이 물리 세계와의 접점이 있는 작업에서 AI의 한계를 더 명확하게 본다.
AI는 ESP32의 I2C 코드는 잘 짜준다. 하지만 그 코드가 실제로 BMP280과 통신이 안 될 때, 오실로스코프로 SCL 파형을 보면서 “풀업 저항이 너무 작아서 라이징 타임이 부족하다"는 걸 진단하는 건 AI가 모른다. 현장에서 손으로 만지고 측정하고 수정하는 경험의 축적이 필요하다.
소프트웨어도 마찬가지다. 서비스가 실제로 1000명의 사용자를 받았을 때 어디서 무너지는지, 어떤 엣지 케이스가 프로덕션에서 터지는지 — 이건 코드를 많이 생성한다고 알 수 있는 게 아니다. 실제로 배포하고, 모니터링하고, 장애를 경험해봐야 안다.
AI가 속도를 높여줄 수 있는 건 구현이다. 하지만 무엇을 구현할지, 그것이 왜 틀렸는지, 다음엔 어떻게 할지 — 이것들은 경험의 집적에서 나온다.
“오케스트레이터"라는 프레임에 대해 #
요즘 많이 나오는 말이다. “엔지니어는 AI를 오케스트레이션하는 사람이 된다.”
나는 이 프레임을 반만 동의한다.
맞는 부분: 확실히 엔지니어의 역할에서 직접 구현의 비중이 줄고, 방향 설정과 결과 검증의 비중이 늘어난다. 이건 실제로 일어나고 있다.
동의하지 않는 부분: “오케스트레이터"라는 표현이 마치 구현 능력은 필요 없는 것처럼 들린다는 것이다. 오케스트라 지휘자가 악기를 못 다뤄도 된다고 생각하는 사람이 있지만, 최고의 지휘자들은 대부분 여러 악기를 수준 이상으로 다룬다. 직접 연주하지 않더라도, 그 이해가 지휘의 질을 결정한다.
AI를 잘 쓰는 엔지니어는 구현의 세부 사항을 완전히 이해하는 사람이다. “이 코드가 왜 이렇게 작동하는지"를 아는 사람이 AI에게 더 정확한 방향을 준다. 반대로 모르는 사람은 AI가 틀린 방향으로 가도 따라가다가 뒤늦게 발견한다.
주니어 팀원의 질문에 어떻게 답했나 #
나는 이렇게 말했다.
“솔직히 말하면, 네가 지금 배우는 방식이 10년 전 내가 배우던 방식이랑 달라야 한다고 생각해. 예전엔 ‘어떻게 구현하는가’를 외우는 게 중요했어. 지금은 ‘왜 이렇게 설계하는가’를 이해하는 게 더 중요해졌어. AI가 구현은 해줄 수 있지만, 설계의 이유를 이해하는 건 여전히 네가 해야 하거든.”
“그리고 하나 더. AI가 코드를 잘 짜줄수록, 그 코드가 잘못됐다는 걸 알아보는 능력이 더 가치 있어져. 그 능력은 기초를 아는 사람한테만 있어.”
팀원이 고개를 끄덕였는지는 모르겠다. 하지만 내가 할 수 있는 가장 정직한 답이었다.
에세이의 결론이 아니라 계속되는 질문 #
이 글에 깔끔한 결론을 달고 싶었는데, 쓰면서 오히려 질문이 더 많아졌다.
AI가 시니어 엔지니어의 판단력까지 흉내내는 날이 온다면? 그 날이 10년 후인가, 20년 후인가, 아니면 안 오는가? 그 판단력이란 게 정말 복제 불가능한 것인가, 아니면 충분한 데이터가 쌓이면 가능한가?
모른다. 아무도 모른다.
하지만 내가 확신하는 것 하나: 이 불확실성 속에서 최선의 전략은 배우는 속도를 유지하는 것이다. 특정 기술 스택에 묶이는 것이 아니라, 새로운 도구와 패러다임을 빠르게 흡수하는 능력을 키우는 것. 그리고 그 능력의 기반은 역설적으로 기초에 대한 깊은 이해다.
13년을 이 일을 해오면서 가장 변하지 않은 것이 있다면, 진짜로 문제를 이해하고 싶어 하는 마음이 결국 가장 강한 경쟁력이었다는 것이다. 도구가 뭐가 됐든, 그 마음을 가진 사람은 적응한다.
주니어 팀원도 그 마음이 있어서 나에게 그 질문을 했을 것이다.
그 마음만 있으면, 아직 걱정할 것 없다.