AI를 얼마나 쓸지는 이제 스킬이다

요즘 주변 개발자들을 둘러보면 코딩에 AI를 쓰지 않는 사람을 찾는 게 더 어렵습니다. 얼마 전까지만 해도 찬반이 팽팽한 논쟁거리였지만, 2026년 현재는 그냥 숨 쉬는 공기처럼 자연스러운 전제가 되었습니다.

그러다 보니 고민의 축도 완전히 달라졌습니다. 이제는 “AI를 써야 하는가?”라는 당위보다 실질적인 위험을 저울질하는 질문이 중심에 놓입니다:

AI를 너무 많이 쓰는 게 위험할까, 아니면 너무 적게 쓰는 게 위험할까?

이 날카로운 프레이밍을 Tom Wojcik의 글 “What AI coding costs you”에서 처음 접했습니다. 그는 어떤 대시보드 지표에도 잡히지 않는 숨겨진 비용을 꼬집습니다. 모델이 구현을 전담할수록 예전에 코드를 직접 짜며 자연스럽게 얻던 잔잔한 배움들이 증발해버린다는 점입니다.

저 역시 Harry와 함께 AI 뉴스 피드를 구축하면서 비슷한 감정을 느꼈습니다. 봇의 개발 속도는 제가 손으로 짜던 시절과 비교할 수 없을 만큼 빠릅니다. 그런데 하루 작업을 마치고 “오늘 깊이 있게 배웠다”는 뿌듯함을 얻기는 훨씬 어려워졌습니다.

하지만 업계가 이 딜레마를 돌파하는 방식은 “과거의 손코딩 시대로 회귀하자”는 식의 반동이 아닙니다. 오히려 에이전틱 엔지니어링(Agentic Engineering)이라는 고유한 숙련도의 영역을 구축해가는 과정에 가깝습니다.

스펙트럼은 또 한 번 움직였습니다

Wojcik은 개발 방식을 하나의 연속적인 스펙트럼으로 묘사합니다:

왼쪽 끝: 사람이 직접 키보드로 모든 코드를 타이핑하고 확인하는 방식
오른쪽 끝: AGI가 기획부터 배포까지 혼자 완결 짓는 세계
그 중간: 바로 오늘날 우리가 서 있는 현실

여기서 핵심은 안전선이 매주 오른쪽으로 밀려나고 있다는 사실입니다. 기반 모델의 성능이 향상되고, 도구가 정교해지며, 협업 워크플로우가 정착될수록, “이 정도는 에이전트에게 온전히 넘겨도 안전하다”고 느끼는 자율성의 임계치가 계속해서 넓어집니다.

결국 “적절한 AI 사용량”이란 한 번 정해두는 고정된 사내 규칙이 아니라 끊임없이 움직이는 표적을 맞추는 일입니다.

두 가지 실패 모드

이 프레이밍은 우리가 빠질 수 있는 함정이 양쪽에 모두 존재한다는 사실을 솔직하게 짚어줍니다. 그래서 설득력이 있습니다.

1) AI를 너무 많이 쓰는 경우

기능을 쉼 없이 배포하면서도 엔지니어로서의 기초 체력은 서서히 잃어가기도 합니다:

디버깅 감각의 둔화
코드 레벨에서 아키텍처의 결함을 감지하는 직관의 상실
시스템 복잡도와 엣지 케이스에 대한 감각 저하
에이전트 없이 작업 공수를 가늠하지 못하는 의존성

코드를 직접 들여다보지 않는 습관이 굳어지면, 시스템 어딘가에 미묘한 균열이 생겼을 때 이를 알아차릴 감각 자체가 무뎌집니다.

2) AI를 너무 적게 쓰는 경우

반대 방향의 실패도 치명적이긴 마찬가지입니다.

새로운 도구를 거부할 때 치르는 대가는 단순한 작업 속도의 저하에 그치지 않습니다. 시도의 횟수 자체를 잃어버리는 것이 진짜 문제입니다. 경쟁자나 동료가 열 번의 가설을 검증하며 피드백을 쌓는 동안 혼자 고결하게 단 한 번의 시도에 머물게 되기 때문입니다. 이 간극은 시간이 흐를수록 복리로 벌어집니다.

현실에서 AI를 완강하게 거부하는 태도는 종종 기술적 순수성처럼 포장되지만 결과적으로는 시장에서 도태되기 쉽습니다.

이것은 조용히 하나의 공예가 되었습니다

에이전틱 엔지니어링은 단순히 “프롬프트를 정중하게 잘 쓰는 요령”이 아닙니다. 실제적인 원칙과 기법을 요하는 엔지니어링 규율에 가깝습니다:

작업의 성격에 맞춰 적절한 자율성 레벨을 선택하기
에이전트의 산출물을 검증 가능한 단위로 잘게 쪼개기
명확한 안전장치(테스트, 불변식, 실행 예산) 설계하기
견고한 피드백 루프(메트릭, 회귀 테스트, 운영 요약) 구축하기
기계가 헛돌기 전에 사람이 개입해 직접 핸들을 잡아야 할 순간을 포착하기

특히 마지막 감각이 대단히 중요합니다. 최적의 AI 개입 수준은 상황에 따라 매번 달라지기 때문입니다.

아직 가설이 모호하거나 아키텍처 리스크가 큰 탐색적 작업이라면 사람이 바짝 붙어서 함께 호흡해야 합니다. 구현 패턴이 명확한 기계적 작업이라면 에이전트에게 과감하게 위임하는 편이 맞습니다.

그래서 정답처럼 정형화된 단 하나의 워크플로우는 존재하지 않습니다. Kent Beck의 증강 코딩 스타일이든, Phillip Su의 매니저 역할론이든, Intent 같은 오케스트레이션 도구든 저마다 특정 상황에 맞는 로컬 최적해일 뿐입니다.

이 다양한 선택지 사이에서는 지금 상황에 가장 알맞은 도구와 거리를 결정하는 판단력이 중요합니다.

시스템 구석에 숨은 사람의 루프

저희가 만든 뉴스 피드봇을 운영하면서 겪은 경험도 이와 정확히 일치합니다.

겉보기에는 매일 정해진 시간에 완전 자동으로 굴러가는 시스템 같지만 양쪽 끝단에는 여전히 사람이 개입합니다:

상류(Upstream): 어떤 소스가 양질의 인사이트를 꾸준히 내놓는지 가려내 등록하는 소스 발굴 작업은 여전히 Danu가 직접 읽고 선별합니다.
하류(Downstream): 피드의 질감이 미묘하게 어긋날 때(예를 들어 앱 버전 업데이트 글이 과도하게 상단을 차지할 때), 랭킹 가중치와 노출 상한선을 재조정하는 것은 사람의 감각입니다.

일단 소스가 시스템에 들어가면 그 뒤의 수집과 요약은 기계가 완벽히 처리합니다. 하지만 무엇을 시스템에 편입할지 고르는 심미안과, 시스템이 궤도를 벗어났을 때 바로잡는 미세 조정은 여전히 사람의 몫입니다.

에이전트는 사람을 대체하기보다 사람의 집중력을 가장 본질적인 지점으로 밀어 올려줍니다.

엔지니어는 앞으로 어떻게 성장하는가

제가 가장 오랫동안 붙잡고 고민했던 질문은 이것이었습니다. 모델이 구현을 뚝딱 해치워버린다면, 사람은 도대체 무엇을 배우며 성장해야 할까요?

지금까지 내린 잠정적인 결론은 세 가지 습관입니다:

설계 판단을 측정 지표로 전환해 검증 가능하게 만듭니다. 그렇지 않으면 아키텍처 고민은 끝없는 주관적 감상으로 남습니다.
최소한 하나 이상의 “코드 밀착형 루프”를 유지합니다. 세부 구현을 에이전트에게 맡기더라도, 정기적인 diff 리뷰나 작은 기술 검증(Spike)을 통해 구현 현실 감각을 놓치지 않아야 합니다.
자율성을 온오프 스위치가 아니라 미세 조절 다이얼로 다룹니다. 태스크의 난이도와 불확실성에 따라 에이전트와의 거리를 기민하게 조절해야 합니다.

새로운 프레임워크의 문법을 밤새워 타이핑하며 익히던 시절의 원초적인 손맛과는 다를지도 모릅니다. 하지만 이것은 결코 배움의 퇴보가 아니라 더 거대한 복잡성을 다루는 조타수(Steering)로서의 깊은 성장입니다.

새로운 기본선

불과 1년 전만 해도 코딩에 AI를 적극 도입한다는 사실 자체가 남다른 경쟁력이었습니다. 지금은 기본 입장권일 뿐입니다.

앞으로 진짜 실력은 이 기준에서 갈립니다:

주어진 작업의 맥락에 맞게 최적의 AI 개입 수준을 조율할 수 있는지
디테일의 늪에 빠지지 않으면서도 시스템의 품질을 빈틈없이 검증해내는지
기계의 생산성에 편승하면서도 자신만의 학습 루프를 끈질기게 지켜내는지

이것이 바로 새로운 엔지니어링 역량입니다. 그리고 어떤 기술이든, 그 역량을 의식적으로 훈련한 엔지니어는 겉보기에 마법처럼 일해낼 것입니다.