2026년 10월 회고 — AI Native 는 '딸깍'이 아니다

회사 기조가 점점 AI Native 로 가려 하고 있다. 우리 팀도 차츰 바꿔 왔다. 코딩 에이전트, AI 코드 리뷰, 테스트 자동화는 그 전부터 써 왔고, 올해 중반에는 SDD(Spec-Driven Development)를 몇몇 프로젝트에 프로토타입으로 시도했다. Spec Kit 을 그대로 쓰기도 하고, 우리 상황에 맞게 직접 고쳐 쓰기도 했다.

AI Native 는 '딸깍'이 아니다

AI Native 가 버튼 한 번에 다 되는 걸 바라는 건지 모르겠지만, 그건 말이 안 된다고 본다.

'딸깍'을 끝까지 밀어붙이면 이런 그림이다. 회장 한 명만 남기고 다 내보낸 뒤 AI 에게 "이 회사 키워 줘" 하면 알아서 굴러간다. 조금 덜 극단적으로는, 피라미드 구조에서 아래 라인이 사라지고 위에서 의사결정하는 사람들만 남는다.

그런데 위로 갈수록 한 번의 결정에 걸린 액수가 커지고, 결정을 잘못했을 때 치르는 비용도 커진다. 그 결정이 AI 가 가져온 보고서를 토대로 한다면 얼마나 믿을 수 있을까. AI 가 0.1%의 확률로 틀린 정보를 가져오고, 그걸 토대로 실무까지 잘못 처리한다면?

지금 AI 는 구조적으로 확률 모델이다. 사람 개입 없이 100%, 아니 99% 품질까지 가려면 토큰을 얼마나 써야 할까. 가로축을 토큰 비용, 세로축을 품질로 두면 이 관계는 로그 곡선을 그릴 거라고 본다. 90% 품질까지는 지금도 적당한 가격에 AI 가 만들어 준다. 하지만 남은 10%를 토큰으로 메우려면 비용이 가파르게 늘어난다. 그 10%는 사람이 메워야 비용과 품질이 맞는다.

남은 10%는 두 가지로 나뉜다. 하나는 정보가 없어서 생기는 문제다. 요구사항에 적히지 않은 의도, 팀 머릿속에만 있는 규칙(암묵지)은 모델이 아무리 좋아져도 추론해 낼 수 없다. 다른 하나는 정보를 줬는데도 생기는 구멍이다. 컨텍스트 일부를 놓치거나, 충돌하는 규칙 중 하나만 따르거나, 예외를 건너뛴다. 확률 모델이라 생기는 일이다.

앞의 것은 좋은 컨텍스트로 메우고, 뒤의 것은 사람의 검토와 검수로 메운다. 이 이야기는 뒤에서 다시 한다.

돈으로 계산해 보면

하루 생산성을 돈으로 바꿔서 생각해 봤다. 아래 숫자는 전부 계산을 위한 예시다. 개발자 일당을 40만 원이라고 하자.

AI 없이 일하던 개발자가 하루에 100만~120만 원어치 성과를 냈다면, 개발자에게 1만 원을 쓸 때 2.5만~3만 원이 나온 셈이다. 편하게 ROI 3이라고 하자.

개발자와 AI 를 같이 굴리면 어떨까. 일당 40만 원에 AI 토큰 비용 10만 원을 더한다. AI 전후 생산성 차이는 체감으로 대략 3배다. 커밋량, 버그 발견율, 에러가 났을 때 원인을 찾는 속도, 줄어든 운영 리소스, 설계 품질까지 따지면 5배, 6배로 늘어나기도 한다. 여기서는 보수적으로 3배로 잡는다. 그러면 50만 원을 써서 300만~360만 원이 나오고, ROI 는 적어도 6이다.

그럼 개발자 개입을 줄이고 AI 개입을 늘리면? 사람에게 쓰는 돈을 줄이고 AI 에 쓰는 돈을 늘리는 거다.

개발자 20만 원에 토큰 30만 원을 쓰면 300만~360만 원이 나올까? 나는 안 나온다고 본다. 같은 성과를 내려면 토큰에 60만 원, 못해도 90만 원은 써야 한다.

단위: 만 원 / 일, 모두 예시 숫자

마지막 줄을 보면 ROI 가 2.7~4.5로 떨어진다. 사람을 빼고 AI 를 더 넣으면 ROI 가 AI 없던 시절(2.5~3) 근처까지 내려갈 수 있다는 얘기다. 앞에서 말한 로그 곡선이 숫자로는 이렇게 보인다.

그래서 지금 우리가 찾는 건, 사람 비용은 적게 들이고 토큰도 적당히 넣어서 성과를 가장 많이 내는 지점이다. 사실 회사가 토큰 비용을 월 100만 원 정도로 정해서 주니까, 현실적으로는 그 안에서 최대한 뽑아내려는 중이다.

"모델이 좋아지면 다 의미 없는 얘기 아냐?"

주변에서 AI 로 바이브 코딩하는 사업자가 이렇게 말한다. 더 좋은 모델이 나오면 다 의미 없는 얘기 아니냐고, 지금까지 계속 그렇게 증명돼 왔지 않냐고.

맞는 말일 수도 있다. AI 비용과 품질의 관계가 직선인지, 지수 곡선인지, 로그 곡선인지 사실 모른다. 우리도 모른다. 그래서 일단 AI 를 최대한 쓰면서 생산성을 올린다. 자동화할 수 있는 건 자동화하고, 품질이 아주 높지 않아도 되는 건 빨리 붙여서 제품으로 만든다.

다만 내 짐작은 이렇다. 모델이 좋아지면 곡선 전체가 위로 올라가고 구멍도 줄겠지만, 끝에서 납작해지는 모양은 그대로일 것이다. 컨텍스트에 없는 정보는 어떤 모델도 만들어 내지 못하니까.

그래서 AI Native 는 뭔가

결국 지금 상황에서 AI Native 는 개발자는 적당히 개입하고, 생산은 대부분 AI 가 하는 것으로 귀결되는 것 같다.

요즘 내가 일하는 걸 봐도 그렇다. 대부분 검토, 검수, 설계에서 끝난다. 이미 답이 여기 있다.

AI Native 업무 프로세스에서는 기획서, 요구사항, 개발 설계서, QA 에 개발자의 리소스가 몰린다. 그러면 이걸 어떻게 효율적으로 할지 고민하게 되고, 자연스럽게 SSOT, RAG, SDD, QA 자동화 같은 단어가 따라 나온다.

네 단어를 역할로 묶으면 이렇다.

• SSOT: 컨텍스트를 한곳에 둔다 — 어디에 둘까
• RAG: 필요한 컨텍스트만 골라 AI 에게 건넨다 — 어떻게 줄까
• SDD: 스펙을 먼저 쓰고 그 스펙으로 AI 가 구현한다 — 무엇을 시킬까
• QA 자동화: 결과를 사람 대신 일부 검증한다 — 어떻게 검수할까

넷 다 우리 팀에서 이미 쓰고 있다. 도구는 갖춰졌다는 얘기다. 남은 문제는 거기에 무엇을 넣느냐다.

결국 컨텍스트 싸움이다

AI 에게 컨텍스트를 주고 개발을 맡기고, 우리는 결과를 검토한다. 그러니 좋은 컨텍스트를 줘야 한다.

좋은 컨텍스트는 좋은 설계서, 좋은 기획서, 좋은 정책서에서 나온다. 기존 도메인 지식과 규칙도 다 포함된다. 이걸 잘 모아 뒀다가 AI 에게 알맞게 줘야 좋은 결과가 나온다.

그럼 좋은 컨텍스트는 어떻게 만들까. 신규 프로젝트의 설계, 기획, 정책, 그리고 기존 프로덕트에 대한 같은 종류의 문서들. 이것들의 품질이 올라가야 한다. 크게 두 갈래로 나눠 봤다.

1. 기존 프로덕트 — 개발자가 관리

기존 프로덕트 문서는 지금 코드와 맞으면 된다. 그리고 암묵지가 없어야 한다. 이게 끝이다. 현재 돌아가는 프로덕트의 모든 걸 담고, 정합성과 신뢰성이 있으면 된다.

코드와 맞춰 두는 방법은 순서를 뒤집는 것이다. 코드를 고치고 문서를 따라 고치는 게 아니라, 프로덕트 정책서를 먼저 고치고, 코드는 무조건 그 정책서를 토대로 만든다. 문서가 코드를 따라가면 언젠가 어긋나지만, 코드가 문서에서 나오면 둘이 같은 방향을 본다.

2. 신규 요구사항 — 기획자가 관리

신규 요구사항은 명확해야 하고, 그 자체로 논리가 맞아야 한다. 기존 프로덕트를 빼고 봐도 요구사항 자체가 말이 되는지.

기획자가 새 기획서를 가져올 때, 그 기획에 엮인 여러 프로덕트와 정책들을 살펴보고 만들어 왔다면 그게 좋은 기획서다. 좋은 기획서의 조건은 두 가지면 된다. 명확한 요구사항, 그리고 그 요구사항에 필요한 정책들의 논리적 타당성. 물론 전달력도 좋으면 좋다.

여기서 재밌는 점이 있다. 명확한 요구사항은 기획자의 역량이다. 그런데 필요한 정책들의 논리적 타당성은 1번, 즉 기존 프로덕트의 정책서와 설계서 품질에도 달려 있다. 기획자가 아무리 잘해도 참고할 정책서가 엉망이면 좋은 기획서가 나오기 어렵다.

그래서 우리가 하려는 건 두 가지다. 우리가 관리하는 프로덕트의 정책서를 잘 만들어 두는 것. 그리고 기획자들에게 "우리도 이렇게 할 테니 기획 컨텍스트도 좋은 품질로 유지해 달라"고 요청하는 것.

아직은 첫 번째 단계다. 10월에는 개발 조직 안에서 정책서의 바운더리와 형태를 잡아 가고 있다. 기획 쪽에 요청하는 건 그다음이다.

따라오는 고민들

정책서를 어디서 관리할까

정책서가 중요해졌는데, 예전처럼 Confluence 에서 관리하는 게 맞을까? Confluence 에서는 가드레일을 세울 수 없다.

가장 큰 문제는 승인 없이 고칠 수 있다는 점이다. 정책서가 AI 에게 들어가는 컨텍스트가 되면, 누군가 검토 없이 한 줄 고친 게 그대로 AI 가 만드는 코드에 반영된다. 그 밖에도 PR 승인, CODEOWNERS 로 도메인별 책임자 지정, CI/CD 연결, 각종 자동화 같은 것들이 Confluence 에서는 부족하다.

그래서 GitHub 에서 관리하기로 했다. 정책서도 코드처럼 리뷰와 승인을 거쳐야 바뀐다.

무엇을, 어떤 형식으로 넣을까

정책서에 무엇을 넣을지(바운더리), 어떻게 넣을지(포맷)도 정해야 한다. 어떻게 관리해야 AI 가 정책서와 기획서를 읽고 우리가 원하는 결과를 낼까? 기획서는 믿을 수 있을까? 기획자들에게 기획서를 이렇게 관리하라고 요구할 수 있을까?

커머스의 정산 도메인을 예로 들어 보자. 정책서에는 이런 규칙이 들어갈 수 있다.

정산 금액이 0원이면 파이낸스 API 를 호출하지 않고 자체적으로 완료 처리한다.

코드에는 if (amount === 0) 한 줄로 남겠지만, 이게 왜 있는지는 아는 사람만 안다. 이런 규칙이 정책서에 없으면 AI 는 금액과 상관없이 똑같이 API 를 호출하는 코드를 만들 것이다. 이런 규칙을 어디까지 정책서에 넣을지가 바운더리고, 어떤 모양으로 적을지가 포맷이다.

바운더리의 트레이드오프

고민이 줄줄이 따라오는데 아직 정답을 모른다. 정답이 있다고 생각하지도 않는다.

정책서 바운더리를 좁히면 관리할 게 줄어서 개발 프로세스가 가벼워진다. 대신 기획서에 더 기대게 된다. 바운더리를 넓히면 반대다. 개발 프로세스가 무거워지는 대신 기획서에 덜 기댄다.

마치며

만들고 싶은 결과는 그려져 있다. 좋은 컨텍스트를 관리해서 좋은 개발을 하는 것. 그 안에서 어디를 얼마나 덜어 내고 어디를 늘릴지 고민하는 중이다.

조금 더 멀리 보면, "개발자는 철밥통이다"에는 반대한다. 오히려 "개발자는 사라진다"에 가깝다고 본다. 다만 사라지는 건 IT 회사가 아니라 지금 모습의 개발자라는 직무다. IT 회사는 남고, 그 안에서 새로운 직무가 생길 것이다. 이미 FDE(Forward Deployed Engineer) 같은 직무가 나왔다. SI 의 다른 이름이긴 하지만. 개발자도 개발만 하지 않게 되면 이름부터 바뀔 것이다.