들어가며
매년 부처님 오신 날에는 이모부가 계신 절을 찾아 행사일을 거듭니다. 올해도 도왔습니다.
행사가 끝난 후, 다같이 커피타임을 가지며 여러 이야기를 나눴습니다. 그러던 중
이모부께서 절 홍보 웹을 만들어 보려다 정보가 부족해 포기했다는 이야기를 하셨습니다.그래서 CLAUDE로 만들어 드리기로 했습니다.
"경기도 양주 월암산 보현사 사찰 홍보 페이지를 React + Next.js로 만들어줘."
"딸깍"
30분 뒤, 배포까지 끝나 있었습니다.
https://월암산보현사.kr
(사용 스택: Next.js 16 / React 19 / Tailwind v4 / Vercel)개발자는 앞으로 쌀을 사먹지 못하는 걸까요?
'딸깍"의 시대에서 우리는 어떤 능력을 키워야 될까요?
단순 구현 능력의 종말
AI는 30분만에 만듭니다.
CRUD 화면, 랜딩 페이지, 간단한 어드민, 흔한 모양의 폼과 리스트, 사람이 한 줄씩 깎아 만드는 비용은 빠르게 0에 수렴하고 있습니다. 부정할 이유가 없습니다.다만 "그러므로 코딩 능력은 필요 없다" 로 직진하면 다음과 같은 시스템 앞에서 곧장 무너집니다.
- 초당 수천 건의 요청을 정합성 잃지 않고 처리해야 하는 시스템
- 수십 개 마이크로서비스가 메시지로 협력하는 구조
- 한쪽이 죽었을 때 다른 쪽이 살아남고 복구되는 환경
- 동시에 누른 두 번의 결제 버튼이 한 번으로만 처리되어야 하는 시나리오
이런 영역에서 비싸지는 것은 코드를 짜는 능력이 아닙니다. 그 코드가 옳은지 판단하는 능력입니다. AI는 코드를 빠르게 만듭니다. 그러나 그것이 정말 안전한지는 다른 차원의 문제입니다.
미묘하게 race condition이 있는 코드, N+1 쿼리가 숨어 있는 코드, 인덱스를 타지 못하게 짜인 SQL, 멱등성이 빠진 결제 처리 등 이런 결함은 첫눈에 드러나지 않습니다.
평소에는 멀쩡히 동작하다가, 트래픽이 몰리거나 동시 요청이 겹치거나 네트워크가 살짝 흔들리는 순간 무너집니다.
질문을 바꿔야 합니다. AI 시대에 개발자에게 남는 것은 무엇인가. 제가 도달한 답은 두 가지입니다.
결과물의 신뢰도를 보장하는 능력, 그리고 도메인 지식.
1. 신뢰도를 보장하는 능력
AI는 코드를 생성하지만, 가장 그럴듯한 답을 내놓는 모델의 구조상, 자기 확신과 정확도가 일치하지 않습니다. 이 판단의 공백을 사람이 메워야 합니다.
필요한 능력은 셋입니다.
1. CS 지식
AI 코드를 받았을 때 즉시 던져야 하는 질문들입니다.
- 이 함수의 시간 복잡도는 입력이 10배 늘면 어떻게 변하는가? 100배라면?
- 이 프레임워크는 메모리를 어떻게 잡고, GC가 어떻게 도는가?
- 이 트랜잭션의 격리 수준은 어떤 동시성 이상을 허용하는가? phantom read인가, lost update인가?
- 이 SQL은 어떤 인덱스를 타는가? 인덱스가 없으면 풀 스캔인가, 정렬 비용은 얼마인가?
- 이 HTTP 호출이 실패하면 무엇이 일어나는가? 재시도는 안전한가, 멱등성이 보장되는가?
- 이 캐시 무효화 전략은 stale read를 만들 수 있는가? read-through인가 write-through인가?
- 이 락 획득 순서는 일관적인가? 데드락 가능성이 있는가?
이 질문을 못 던지면 "AI가 했으니 맞겠지" 가 됩니다. AI는 거짓말은 하지 않지만, 그럴듯하게 틀립니다. 그 코드는 사람이 명백히 틀리게 짠 코드보다 훨씬 잡기 어렵습니다. "문법은 맞고, 동작도 한다, 그런데 운영에 올리면 무너진다" 는 종류의 결함은 CS 기초가 있어야만 감지됩니다.
CS 지식은 면접용이 아닙니다. AI가 모든 코드를 짜주는 세상에서, 그 코드가 옳은지 평가할 수 있는 사람과 그렇지 않은 사람의 격차는 오히려 점점 벌어집니다.
OS·자료구조·네트워크·DB 기초는 이제 AI 출력을 읽는 도구가 되었습니다.
2. 알고리즘적 사고
AI는 문제를 잘 풉니다. 그러나 문제 자체는 사람이 정의해야 합니다. 주어진 상황을 부분 문제로 분해하고, 입력과 출력을 명확히 잡고, 제약 조건을 식별하는 능력.
이것이 AI에게 의미 있는 요청을 던지는 출발점입니다.
같은 기능을 만들더라도, 다음 두 요청은 결과가 완전히 다릅니다.
A) "리스트에서 중복 제거해줘."
B) "리스트 중복 제거. n ≤ 10⁶, 64비트 정수, 메모리 256MB 제한, 원래 순서 유지, O(n) 기대, thread-safe."
A는 어떤 라이브러리든 한 줄로 끝납니다. 그러나 그 한 줄이 내가 처한 문제를 푸는지는 알 수 없습니다. 표면 아래의 제약이 보이지 않은 채로 답이 나오기 때문입니다.
B는 같은 "중복 제거"라는 표현 아래 숨어 있던 데이터 규모, 자료형, 메모리 한계, 순서 보존, 시간 복잡도, 동시성 — 여섯 가지 제약을 전부 끌어올렸습니다. AI는 B에 대해 훨씬 정교한 답을 내놓을 수 있고,
우리는 그 답이 우리 시스템에 맞는지를 명확한 기준으로 검증할 수 있습니다.좋은 질문은 한 번에 나오지 않습니다. 문제를 분해할 줄 알아야 던질 수 있고, 분해의 도구가 바로 알고리즘적 사고입니다. "이 문제의 진짜 모양은 무엇인가, 핵심 변수는 무엇인가, 어떤 제약을 잡지 않으면 답이 무의미해지는가." 이것없이는 AI에게서 좋은 답을 끌어낼 수 없습니다.
3) TDD
보현사 사이트에는 테스트 코드가 한 줄도 없습니다. 30분 안에 만든 사이트에 테스트를 까는 것은 과한 일이고, 페이지 하나하나를 눈으로 열어보는 것으로 충분했습니다. 이 규모에서 TDD를 강제하는 것은 비효율적입니다.
그러나 시스템이 MSA로 쪼개지는 순간 이야기가 완전히 달라집니다. 이전에 직접 만든 온라인 저지 시스템을 떠올려 보면, 그 시스템에서는 한 서비스의 한 줄 변경이 멀리 떨어진 다른 서비스를 침묵시킬 수 있었습니다.
- 채점 큐의 메시지 포맷을 살짝 바꾸면 워커가 침묵합니다.
- 멱등성 처리가 빠지면 동일 채점이 두 번 돌아 점수가 틀어집니다.
- 워커의 타임아웃 설정과 큐 재전송 주기가 어긋나면 동일 작업이 좀비처럼 무한 반복됩니다.
- 한 서비스의 응답 스키마에 필드가 하나 늘어나는 것만으로, 그것을 엄격하게 검증하던 다운스트림 전체가 죽기도 합니다.
이런 환경에서 AI 코드를 눈으로만 읽고 머지하는 것은 불가능합니다. 사람의 검토 속도는 AI의 생성 속도를 따라가지 못합니다. 따라가지 못하면 읽지 않은 코드가 시스템에 누적되는 구조가 됩니다. 이것은 보안 측면에서도, 운영 측면에서도 위험합니다.
그래서 검증을 자동화해야 합니다. AI 시대의 TDD가 들어설 자리가 바로 여기입니다. 흥미롭게도, AI 시대의 TDD는 원래의 TDD와 결이 조금 다릅니다.
원래 TDD는 "실패하는 테스트를 먼저 쓰고, 그 테스트를 통과시키는 최소한의 코드를 사람이 쓴 다음, 리팩토링한다" 라는 흐름이었습니다. AI 시대에는 이 흐름이 다음과 같이 재해석됩니다.
1. 사람이 원하는 동작을 테스트로 명세화합니다.
이 단계가 도메인 지식과 만나는 지점입니다. 어떤 입력에 어떤 출력이 나와야 하는지, 어떤 예외 상황에서 어떻게 동작해야 하는지, 어떤 성능을 보장해야 하는지 — 사람이 도메인 기반으로 정의합니다.2. AI에게 그 테스트를 통과시키는 코드를 요청합니다.
코드 작성의 양적 부담은 이 단계에서 AI가 거의 다 가져갑니다. 사람은 명세를 제공하고, AI는 구현을 제공합니다.3. 통과하면 합격, 실패하면 같은 루프를 반복합니다.
실패 시 AI에게 왜 실패했는지를 그대로 넘기면 다음 시도에서 통과시키는 경우가 많습니다. 사람의 개입은 명세를 더 정교하게 다듬는 쪽에 집중됩니다.
이 흐름에서 사람이 보장하는 것은 테스트의 정확성과 도메인 정합성, AI가 보장하는 것은 그 테스트를 만족하는 구현의 생산성입니다. 코드는 일종의 부산물이 되고, 명세(테스트)가 진짜 자산이 됩니다.
구현은 언제든 다시 생성할 수 있는 결과물이지만, 어떤 테스트를 어떤 의도로 짰는가는 다시 만들 수 없는 자산입니다.
위 구조에서 테스트의 품질이 곧 시스템의 품질입니다. 어떤 엣지 케이스를 잡을지, 어떤 성능을 보장할지, 어떤 동시성 시나리오를 검증할지, 어떤 실패 모드를 가정할지, 이것이 그 어느 때보다 중요한 질문이 됩니다. MSA + AI + TDD 의 조합이 신뢰도가 요구되는 대규모 시스템의 새로운 정합점이 되어가고 있다고 봅니다.
2. 도메인 지식
검증 능력만으로는 절반입니다. 무엇을 만들지 정하는 능력인 도메인 지식이 나머지 절반을 채웁니다.
도메인은 UX/UI보다 훨씬 넓습니다.
도메인 지식을 UX/UI 결정 능력 으로 좁히면 일부 개발자에게만 해당하는 이야기가 됩니다. 도메인 지식은 자기가 만드는 제품의 사용자, 산업, 비즈니스 맥락 전반을 읽어내는 능력입니다.
- 보현사: 어르신 신도를 위한 글자 크기 조절, 지역 사찰 로컬 SEO, 폼이 아닌 전화 우선 CTA, 단청 적색·명조체로 표현되는 시각 정체성. 이것은 UI 결정이 아니라 60대 후반 사찰 사용자라는 것을 아는 사람만 던질 수 있는 지시입니다.
- 결제: 정산 주기와 회계 처리 규칙, 부분 환불과 분할 결제의 흐름, 카드사별 매입·취소 타이밍의 차이, PG사 장애 시의 대체 경로, 환불·재결제의 멱등성 모델. 같은 "결제 모듈 만들어줘" 라는 요청이라도 이 도메인을 아는 사람과 모르는 사람이 받는 결과는 전혀 다릅니다.
- 의료 SaaS: HIPAA·개인정보보호 규제, EMR 데이터 교환 표준(HL7·FHIR), 진료 흐름과 보험 청구 절차, 의료진과 환자의 권한 분리 모델, 처방·투약 이력의 감사 로깅 의무.
- 핀테크: KYC와 자금세탁 방지 규제, 실시간 시세와 체결의 일관성, 원장(ledger)의 회계 정확성, 시장 이상 상황에서의 거래 정지 규칙, 잔액과 거래 내역의 회복력.
- 게임: 사용자 행동 패턴과 보상 곡선, 이탈 지점과 재방문 트리거, 밸런스 붕괴 시 경제 시나리오, 점검·패치가 사용자 신뢰에 미치는 영향, 신규 콘텐츠의 학습 곡선.
분야는 달라도 공통점은 하나입니다. AI는 이 도메인을 일반론 수준까지만 압니다. "결제에는 멱등성이 필요하다" 같은 교과서는 알지만, 우리 회사의 정산 주기와 환불 정책, 우리 카드사의 매입 타이밍이 어떻게 충돌하는가는 알지 못합니다. 이 마지막 한 뼘은 항상 사람이 메워야 합니다. 그리고 시스템의 품질을 결정하는 것은 이 마지막 한 뼘인 경우가 많습니다.
왜 점점 더 중요해지는가
코드 작성 비용이 0에 수렴할수록 무엇을 만들지 정하는 비용이 상대적으로 부각됩니다. 과거에는 짤 시간이 없어서 못 하던 일이 많았습니다. 지금은 무엇을 짤지 정의하지 못해서 못 하는 일이 많아집니다. AI는 정의되지 않은 문제를 풀지 않습니다. 정의를 던질 수 있는 사람만이 AI를 활용할 수 있고, 정의를 던지려면 도메인을 알아야 합니다.
같은 기능을 만들더라도 도메인 맥락이 들어가면 결과가 완전히 달라집니다. 보현사 사이트가 "무난한 사찰 사이트" 가 아니라 "양주 보현사의 사이트" 가 된 것은 코드의 차이가 아니라 프롬프트에 담긴 요구사항의 차이였습니다. 단청 적색을 메인 컬러로, 명조체를 헤더에, 전화번호를 폼보다 위에 이런 결정은 사찰이라는 도메인과 60대 후반 신도라는 맥락을 아는 사람만 던질 수 있는 지시입니다. AI는 그 지시를 받으면 정확히 구현하지만, 그 지시를 처음부터 던지지는 못합니다.
도메인은 어떻게 쌓는가
답은 진부하지만 단순합니다. 사용자를 직접 만나고, 운영하는 사람의 이야기를 듣고, 자기 제품을 실제로 써보는 일의 누적입니다. 사용자의 환경에 들어가서 보고, 그 산업의 규제와 관습을 익히고, 비즈니스가 어떻게 돈을 벌고 어디서 잃는지를 이해하는 일입니다. 코드 짤 시간이 줄어든 만큼 그 시간을 사용자와의 거리를 좁히는 데 쓸 수 있습니다. 앉아서 키보드를 두드리던 시간이 일어서서 사용자를 만나는 시간으로 일부 옮겨갑니다. 이것이 AI 시대에 개발자의 일이 변화하는 가장 큰 방향이라고 봅니다.
무엇이 더 중할까
둘 중 무엇이 더 상위인가, 라는 질문을 받는다면 저는 도메인 지식이라고 답하겠습니다.
검증 능력은 프로젝트 안에서 AI를 부리는 능력이고, 도메인 능력은 프로젝트 자체를 정의하는 능력입니다. 도메인을 모르면 무엇을 검증해야 하는지조차 정할 수 없습니다. 어떤 테스트 케이스를 짜야 하는지, 어떤 성능이 충분한 성능인지, 어떤 UX가 좋은지, 어떤 실패를 가정해야 하는지, 모든 기준의 출처는 도메인입니다.
도메인 없는 검증은 형식적 통과에 가까워집니다. 테스트는 통과하는데 사용자가 떠나는 시스템, 모든 코드 리뷰를 받았는데 시장에서는 외면받는 제품이런 결과의 출처가 도메인 부재입니다.
거꾸로, 도메인만 알고 검증할 수 없으면 AI 결과를 그대로 받아들이게 됩니다. 도메인 전문가가 "이런 기능이 필요해" 라고 말하고 AI가 "네 짰습니다" 라고 답한 결과를 그대로 운영에 올리는 것은 가장 위험한 시나리오입니다. 시스템은 그럴듯해 보이지만 안에서는 동시성 이상이 쌓이고, 데이터가 미묘하게 비뚤어지고, 어느 날 갑자기 무너집니다. 더 위험한 것은 무너지기 전까지는 멀쩡해 보인다는 점입니다. 사용자 클레임이 한두 건 들어와도 일시적인 버그로 분류되고, 진짜 원인은 한참 뒤에야 드러납니다.
도메인은 방향키, 검증은 안전망입니다.
방향이 틀린 곳에 안전망을 깔아봐야 의미가 없고, 방향만 있고 안전망이 없으면 멀리 갈 수 없습니다.
두 능력은 동시에 서로를 지탱합니다. 도메인 능력이 어떤 테스트를 짤지를 결정하고, 검증 능력이 그 테스트가 정말 통과하는지를 보장합니다.
대체가 아니라 재분배
AI가 코드 작성이라는 공정을 가져가는 만큼, 사람은 코드 작성 이전과 이후 무엇을 만들지 정의하고, 만들어진 것이 옳은지 검증하는 자리로 옮겨갑니다. 이는 대체가 아니라 재분배입니다.
새 균형점에서 개발자에게 요구되는 능력은 두 가지로 정리됩니다.
1. 신뢰할 수 있는 결과를 만들어내는 능력
깊은 CS 기반(시간 복잡도·동시성·인덱싱·트랜잭션), 알고리즘적 사고(문제를 분해하고 정의하는 능력), 그리고 대규모 시스템에서의 TDD 운용 능력(검증을 자동화하는 능력).2. 자신이 만드는 제품의 도메인을 읽는 능력
UX/UI를 포함한 사용자·산업·비즈니스 맥락 전반에 대한 이해. 그리고 그것을 AI가 받아들일 수 있는 명세로 옮기는 힘.빠르게 짜는 능력은 AI 몫이 되었습니다. 그 코드가 옳은지, 그 코드가 풀려는 문제가 무엇인지는 여전히 사람 몫입니다. "딸깍"의 시대일수록 우리가 키워야 할 것은 더 빠른 손이 아니라, 무엇을 만들지 정의하는 도메인 감각과 그것이 옳은지 가려내는 검증 능력이라고 생각합니다.
