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

요즘 내가 아는 개발자 중에 AI를 안 쓰는 사람을 찾는 게 더 어렵습니다.

예전엔 이게 논쟁거리였는데, 2026년엔 그냥 기본 공기 같아요.

그래서 싸움의 축이 바뀌었죠. 이제는 “AI를 써야 해?”가 아니라 이런 질문이 더 정확해요.

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

이 프레이밍을 Tom Wojcik의 글, “What AI coding costs you”에서 봤어요. 그는 대시보드에 안 찍히는 비용을 말합니다. 모델이 구현을 대신할수록, 우리가 일을 하면서 자연스럽게 얻던 작은 배움들이 사라진다는 것.

저도 비슷한 감각을 느꼈어요. Harry랑 AI 뉴스 피드를 만들면서, 기능은 빨리 나가는데 “오늘 뭔가 배웠다”는 느낌은 예전만큼 쉽게 오지 않더라고요.

근데 업계가 찾는 해법은 “손코딩으로 돌아가자”가 아닌 것 같아요.

agentic engineering은 이제 ‘배워야 하는 스킬’이 되고 있어요.

스펙트럼은 또 움직였다

Wojcik은 스펙트럼으로 설명해요.

  • 왼쪽: 사람이 키보드로 한 줄씩 치면서 모든 코드를 보는 세계
  • 오른쪽: AGI가 혼자 다 만드는 세계
  • 중간: 지금의 우리

핵심은 이거예요. 경계선이 매주 이동합니다. 모델이 좋아지고, 도구가 정리되고, 워크플로우가 굳으면서 “이 정도까지 맡겨도 괜찮다”의 범위가 커져요.

그러니 “적정 AI 사용량”은 고정된 정책이 아니에요.

움직이는 타겟이에요.

두 가지 실패 모드

이 프레이밍이 좋은 이유는, 틀리는 방법이 두 가지라는 걸 인정하거든요.

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

많이 배포하면서도 조용히 잃을 수 있어요.

  • 디버깅 감각
  • 코드 레벨의 아키텍처 직관
  • 복잡성과 엣지 케이스에 대한 촉
  • 에이전트 없이도 대략 견적을 내는 능력

코드를 안 보면, 언젠가부터 “뭔가 이상한데?”를 잡아낼 능력이 약해져요.

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

반대로도 틀릴 수 있습니다.

도구를 거부하면 속도만 잃는 게 아니에요. 시도 횟수를 잃어요. 팀(혹은 시장)은 열 번 던지는 동안 나는 한 번 던지죠. 이 격차는 복리로 커져요.

실제로 “AI를 너무 적게 쓰는” 건 종종 도덕적 순수함처럼 보이다가, 어느 순간 그냥 무의미해지기도 합니다.

다들 말은 안 하지만: 이제 ‘공예’다

agentic engineering은 “에이전트한테 잘 부탁하기”가 아니에요.

진짜 기술이 생깁니다.

  • 작업마다 적절한 자율성 레벨을 고르기
  • 검증 가능한 단위로 쪼개기
  • 가드레일 설계 (테스트, 불변식, 비용/시간 예산)
  • 피드백 루프 만들기 (지표, 회귀 체크, ops summary)
  • 필요할 땐 다시 사람이 가까이 붙기

특히 마지막이 중요해요. 적정 AI 사용량은 상황에 따라 바뀌거든요.

탐색적이거나 리스크가 큰 작업은 사람이 더 가까이 붙고, 기계적인 작업은 더 과감하게 맡겨요.

그래서 “정답 워크플로우 하나”는 없어요. Kent Beck의 augmented coding, Su의 매니저 프레이밍, Intent 같은 오케스트레이션 툴은 각각 다른 로컬 최적해에 가깝죠.

이제 중요한 건 그중에서 어떤 걸 언제 쓸지 고르는 능력이에요.

숨어있는 사람의 루프

우리 피드봇 이야기를 보면 이미 답이 있어요.

자동화처럼 보이는 부분에도, 양 끝에는 사람이 숨어 있어요.

  • Upstream: 소스 발굴은 여전히 Danu가 X/Google News를 보면서 좋은 소스를 찾아 수동으로 추가합니다.
  • Downstream: 피드가 “이상한데?” 싶을 때(예: SDK/앱 릴리즈가 상단을 잠식), 랭킹 규칙과 캡을 조정해요.

한 번 소스가 들어오면 자동으로 돌아갑니다. 하지만 무엇을 통합할지 고르는 일, 그리고 드리프트를 잡아내는 취향 보정은 인간의 일이에요.

에이전트가 사람을 없애는 게 아니라, 사람을 더 중요한 자리로 옮기는 거죠.

사람은 어떻게 계속 배우나

저한테 제일 큰 질문은 이거였어요. 구현을 모델이 해버리면, 사람은 뭘 배우지?

지금 제 답은 이렇습니다.

  1. 결정을 측정으로 바꿔서 검증 가능하게 만들기. 아니면 아키텍처는 계속 ‘감’으로만 남아요.

  2. 최소 한 개는 “코드에 가까운 루프”를 유지하기. 구현을 맡기더라도 현실 접촉은 필요해요. diff, 리뷰, 작은 스파이크 같은 것들.

  3. 자율성은 스위치가 아니라 다이얼로 다루기. 작업마다 적정 값이 달라요.

프레임워크를 몸으로 부딪치며 배우는 것만큼 짜릿하진 않아요.

근데 이건 진짜 성장입니다.

‘조종하는 법’을 배우는 거니까요.

새 기준

1년 전엔 “AI로 코딩한다”가 차별점이었어요.

지금은 기본값이에요.

이제 차별점은 이겁니다.

  • 일에 맞는 AI 사용량을 고를 수 있는가
  • 디테일에 빠지지 않고도 결과를 검증할 수 있는가
  • 내 배움 루프를 계속 살려둘 수 있는가

이건 스킬이에요.

그리고 어떤 스킬이든, 연습한 사람은 마법처럼 보입니다.

관련 글: 배움은 어디로 갔을까?, 에이전트가 커질 때 사람은 어떻게 배울까, 숨어있는 사람의 루프.