AI 가 다해주는 시대, 기술 깊이 학습 vs 빠르게 실행

요즘 가장 자주 받는 질문 세 개가 있어요.

"AI가 다 해주는데, 기술 계속 공부해야 하나요?"

"그냥 AI 잘 쓰는 사람이 되는 게 맞지 않나요?"

"근데 AI만 믿기엔 불안합니다…"

세 번째 문장이 이 질문의 본질입니다. 공부해야 하는지 아닌지 정말 모르는 게 아니에요. 공부하는 게 맞는 것 같은데, 예전처럼 파고 있는 스스로가 맞는지 불안한 거예요. 최근에 자주 이 질문을 받고, 저도 스스로에게 던집니다.

결론부터 말씀드리면, 답은 "깊이를 더 파야 한다"도 "빠르게 만들기만 하면 된다"도 아닙니다. 빠르게 실행하기 위해 깊이 이해하는 것에 대해 자세히 살펴볼게요.

많은 사람들이 착각하는 선택지

요즘 이 질문을 받는 사람들의 머릿속엔 보통 이런 구도가 깔려 있어요.

깊이 파는 엔지니어 vs 빠르게 만드는 AI 빌더
이해 vs 실행

둘 중 하나를 골라야 할 것처럼 보입니다. 한쪽은 "기본기가 우선이다" 말하고, 다른 쪽은 "시대가 바뀌었다, 빠르게 만들어라" 말해요. 양쪽 다 맞는 말 같아서 더 혼란스럽죠.

그런데 이건 선택의 문제가 아닙니다.

flowchart TB
    subgraph MYTH["오해 — 선택의 문제"]
        direction LR
        M1["깊이 이해"] -. vs .- M2["빠른 실행"]
    end
    subgraph REAL["실제 — 순서의 문제"]
        direction LR
        R1["깊이 이해"] --> R2["빠른 실행"]
    end
    MYTH --> REAL
    style M1 fill:#fee2e2,stroke:#ef4444,color:#111827
    style M2 fill:#fee2e2,stroke:#ef4444,color:#111827
    style R1 fill:#dbeafe,stroke:#3b82f6,color:#111827
    style R2 fill:#dcfce7,stroke:#22c55e,color:#111827

왜 '깊은 이해 vs 빠른 실행'은 틀린 질문인가

빠르게 만들었는데 실패하는 프로젝트들을 보면 공통점이 있어요. 결과물이 돌아가긴 합니다. 그런데 방향이 틀려 있어요. 엉뚱한 기능을 먼저 만들었거나, 확장할 수 없는 구조를 짜놨거나, 정작 중요한 문제를 건드리지도 못한 상태예요.

방향이 틀리는 이유는 대부분 이해가 얕아서입니다. 문제를 얕게 이해하면, 엉뚱한 해결책에 빠르게 도달해요. AI가 실행을 빠르게 해주는 만큼, 잘못된 방향으로도 빠르게 갑니다.

깊이 이해하지 않으면, 빠르게 틀린 걸 만듭니다.

이해와 실행은 둘 중 하나를 선택해야 하는 경쟁 관계가 아니에요. 오히려 보완 관계에 더 가까워요. 이해가 방향을 정하고, 실행이 그걸 현실로 만들기 때문이에요. 순서가 뒤집히거나, 기술적으로 잘못된 선택을 한다면 구현이 아무리 빨라도 의미가 없습니다.

AI가 다 해주는 시대, 진짜 변한 것은 무엇인가

그럼 AI가 바꾼 건 정확히 뭘까요. 개발 작업을 세 층으로 나눠서 보면 선명해집니다.

층위	질문	과거	지금
What	무엇을 구현할까	사람이 직접 코드로	AI가 대부분 대체
How	어떻게 설계할까	사람이 주도	AI가 점점 도움
Why	왜 이걸 만들까	사람	여전히 사람

What(구현)은 빠르게 대체되고 있고, How(설계)는 점점 도와받을 수 있는 영역이 됩니다. 하지만 Why — 무엇을 풀어야 하고, 누구를 위해 풀고, 어떤 트레이드오프를 선택할 것인가 — 이건 AI가 대신 결정해주지 않아요. 도구가 아무리 좋아져도, 왜 만들지 그 이유를 결정하는 책임은 사람에게 남습니다.

flowchart TB
    subgraph EXPAND["AI 대체 영역 · 위로 확장 중"]
        direction TB
        WHAT["What — 구현<br/>AI 주도"]
    end
    subgraph MIX["사람 + AI · 점점 혼합"]
        direction TB
        HOW["How — 설계<br/>사람 주도 · AI 보조"]
    end
    subgraph HUMAN["사람의 영역 · 고정"]
        direction TB
        WHY["Why — 방향<br/>사람"]
    end
    WHAT --> HOW --> WHY
    style EXPAND fill:#dcfce7,stroke:#22c55e,color:#111827
    style MIX fill:#e0e7ff,stroke:#6366f1,color:#111827
    style HUMAN fill:#dbeafe,stroke:#3b82f6,color:#111827
    style WHAT fill:#fff,stroke:#22c55e,color:#111827
    style HOW fill:#fff,stroke:#6366f1,color:#111827
    style WHY fill:#fff,stroke:#3b82f6,color:#111827

그렇다면 어디까지 깊이 이해해야 하는가

"그럼 다 공부해야 하는 거 아니냐"는 질문이 바로 따라옵니다. 아니에요. 모든 걸 다 이해할 필요는 없어요. 그건 과거에도 불가능했고, 지금은 더 그렇습니다.

기준은 하나입니다. 내가 책임지는 영역인가.

책임지는 영역인지 판단하는 세 가지 질문이 있어요.

내가 고칠 수 있어야 하는가 — 문제가 생겼을 때 직접 수정할 수 있어야 한다면, 이해해야 합니다.
내가 의사결정을 내려야 하는가 — 이 기술을 쓸지 말지, 이 구조로 갈지 말지를 내가 결정해야 한다면, 이해해야 합니다.
내가 설명할 수 있어야 하는가 — 문제가 터졌을 때 팀에게, 사용자에게, 고객에게 무슨 일이 일어났는지 말할 수 있어야 한다면, 이해해야 합니다.

세 가지 중 하나라도 해당되면, 그 영역은 깊이 이해해야 합니다. 하나도 해당되지 않으면, 굳이 깊이 팔 필요 없어요. AI에게 맡기면 됩니다.

AI가 만들어도, 책임은 내가 집니다.

flowchart TB
    Q["책임지는 영역인가?"]
    Q --> A1["① 내가 고칠 수 있어야 하는가"]
    Q --> A2["② 내가 결정을 내려야 하는가"]
    Q --> A3["③ 내가 설명할 수 있어야 하는가"]
    A1 --> R["하나라도 YES<br/>→ 깊이 이해 필요"]
    A2 --> R
    A3 --> R
    style Q fill:#e0e7ff,stroke:#6366f1,color:#111827
    style A1 fill:#dbeafe,stroke:#3b82f6,color:#111827
    style A2 fill:#dbeafe,stroke:#3b82f6,color:#111827
    style A3 fill:#dbeafe,stroke:#3b82f6,color:#111827
    style R fill:#dcfce7,stroke:#22c55e,color:#111827

깊이의 '목적'이 바뀌었다

여기까지 왔으면 이제 이 글에서 말하고자 하는 핵심을 이해할 수 있습니다.

과거에는 "스스로 잘 짜기 위해" 깊이 팠습니다. 프레임워크 내부를, 언어 스펙을, 시스템 동작을 이해해야 직접 손으로 잘 구현할 수 있었어요. 이해의 목적지는 더 좋은 구현이었습니다.

지금은 다릅니다. 구현은 AI가 상당 부분 대체해요. 하지만 그 결과물이 맞는 방향인지, 올바른 구조인지, 프로덕션에서 버틸 만한 코드인지 — 판단은 여전히 사람이 합니다. 그래서 지금의 깊이는 내가 구현하기 위해서가 아니라, AI의 결과물을 판단하기 위해서 필요해요.

시대	깊이의 목적
과거	내가 잘 구현하기 위해
지금	AI 결과물을 판단하고 방향을 선택하기 위해

정의는 그대로예요. 깊이 있게 이해하는 것, 동작 원리를 아는 것, 본질을 파는 것. 바뀐 건 그걸 하는 이유입니다.

이제 깊이는 코드를 잘 짜기 위한 것이 아니라, 올바른 방향을 선택하기 위한 것입니다.

flowchart LR
    subgraph PAST["과거 — 구현 지향"]
        direction LR
        P1["깊이 이해"] --> P2["내가 직접 구현"]
    end
    subgraph NOW["지금 — 판단 지향"]
        direction LR
        N1["깊이 이해"] --> N2["AI 가 구현"]
        N2 --> N3["사람이 판단<br/>방향 결정"]
    end
    style PAST fill:#fff7ed,stroke:#f59e0b,color:#111827
    style NOW fill:#eff6ff,stroke:#3b82f6,color:#111827
    style P1 fill:#fef3c7,stroke:#f59e0b,color:#111827
    style P2 fill:#fef3c7,stroke:#f59e0b,color:#111827
    style N1 fill:#dbeafe,stroke:#3b82f6,color:#111827
    style N2 fill:#e0e7ff,stroke:#6366f1,color:#111827
    style N3 fill:#dcfce7,stroke:#22c55e,color:#111827

이 관점에서 보면 "깊이 파는 엔지니어 vs AI 빌더" 구도가 왜 틀렸는지도 분명해져요. AI를 잘 쓰려면 깊이가 더 필요합니다. 결과물을 평가할 수 있는 기준이 있어야 AI를 내가 원하는 방향대로 끌고 갈 수 있기 때문이에요.

'React 까보기, Next.js 까보기'를 계속 했던 이유

저는 유튜브에서 React와 Next.js 소스코드를 직접 뜯어보는 시리즈를 만들어 왔어요. 프레임워크가 왜 등장했는지, 내부에서 어떻게 동작하는지, 설계자는 어떤 트레이드오프를 했는지를 코드 단위로 따라가는 콘텐츠입니다.

처음에는 스스로도 "호기심이었다"고 설명했어요. 그런데 시간이 지나고 보니 단순한 호기심 그 이상이었습니다. 나만의 판단 기준을 세우는 과정이었어요.

어떤 기술을 선택할지
어떤 구조를 가져갈지
무엇을 버릴지

이 세 가지 결정을 할 때마다, 까보기를 통해 쌓인 멘탈 모델이 기준이 됩니다. 예를 들어 Next.js의 렌더링 방식을 뜯어본 경험이 있으면, "서버 컴포넌트로 가야 할까, 클라이언트로 가야 할까"를 감이 아니라 원리로 결정할 수 있어요. "이 상황에서 어떤 레이어에 상태를 둬야 하는가"라는 질문에도 답이 나옵니다.

까보기를 안 했다면 같은 질문에 막연히 "요즘 트렌드가…" 정도로 답했을 거예요. 그건 판단이 아니라 단순 따라가기입니다. 한계가 명확해요.

까보기 시리즈는 방향을 결정하기 위해, 기술적 판단 기준을 만드는 과정이었습니다.

AI가 구현을 도와주는 시대에는 이 판단 기준이 더 중요해져요. 기준이 없으면 AI가 만들어 온 결과물을 검토할 수 없습니다. 결과물 이전에, 어떻게 시켜야할지 그 방향성을 검토할 수도 없고요. "좋아 보이네" 하고 넘기거나, 잘못된 방향인데도 그럴싸하게 포장되었다는 이유로 통과시키게 되어요.

판단 기준이 준비 되었다면, 이제 실행할 차례입니다

여기서 사고의 전환이 필요합니다. 판단 기준이 충분히 쌓였다면, 이제 실행을 미룰 이유가 없어요. 더 공부한다고 기준이 배로 튼튼해지지 않아서요. 어느 지점부터는 실행을 통해서만 다음 단계를 이해할 수 있습니다.

과거에는 이해 → 실행의 사이클이 길었어요. 직접 구현하는 데 시간이 많이 걸렸으니까요. 지금은 그 사이클이 짧아졌습니다. AI 덕분에 이해에서 실행까지 가는 비용이 극적으로 줄었어요.

그래서 이제는 공식을 추가합니다.

깊이 이해하고, 빠르게 실행합니다.

AI는 실행을 가속하지만, 방향은 가속하지 않습니다.

사람이 방향을 잡아주면, 그 다음은 AI가 빠르게 실행해요. 반대로 방향이 잘못되어 있으면, 빠르게 실행할수록 더 빨리 틀린 곳에 도착합니다. 울트라 플랜, 랄플랜 등 — AI에게 맡기기 전에 정확한 계획을 먼저 세우는 방식 — 이 최근 계속 회자되는 이유도 같아요. 실행을 가속하려면, 그만큼 방향을 정확히 구체화하는 앞단이 필요합니다.

flowchart LR
    subgraph HUMAN["사람 영역 — 방향"]
        direction LR
        A["깊이 이해"] --> B["정확한 계획"]
    end
    subgraph AI_ZONE["AI 영역 — 가속"]
        direction LR
        C["빠른 실행"]
    end
    B --> C
    style HUMAN fill:#eff6ff,stroke:#3b82f6,color:#111827
    style AI_ZONE fill:#f0fdf4,stroke:#22c55e,color:#111827
    style A fill:#dbeafe,stroke:#3b82f6,color:#111827
    style B fill:#e0e7ff,stroke:#6366f1,color:#111827
    style C fill:#dcfce7,stroke:#22c55e,color:#111827

진짜 차이를 만드는 건 '사용자를 만난 경험'입니다

한걸음 더 나아가 볼게요. 실행해야겠다는 건 알겠는데, 그럼 무엇부터 실행하지? 시작점은 사용자를 만난 경험이 되어야 합니다. 내가 만든 것을 누군가가 실제로 써본 경험.

저는 얼마전에 챙겨콘이라는 앱을 만들어서 iOS와 Android에 출시했어요. 기프티콘 만료일을 관리해주는 작은 앱입니다. 지금 AdMob 대시보드를 보면 이런 숫자가 찍혀 있어요.

지표	금액
지난달 예상 수익	US$0.35
이번 달 현재까지	US$0.17
오늘까지	US$0.01

솔직히 수익만 보면 작습니다. 커피 한 잔 값도 안 돼요. 그런데 저는 이 숫자가 제 개발자로서의 관점을 완전히 바꿔놨다고 말할 수 있습니다.

바뀐 건 세 가지예요.

문제 정의가 달라졌어요. "뭘 만들면 재밌을까"가 아니라, "뭐가 진짜 불편한가"로 질문이 바뀝니다. 실제 사용자가 쓰는 순간, 유용하지 않은 기능은 바로 드러나요.
기술 선택이 달라졌어요. 쓰는 사람이 있으니 안정성과 크래시율이 현실적인 지표가 됩니다. 트렌디한 기술보다 배포·운영이 효율적인 기술을 고르게 돼요.
사고 방식이 달라졌어요. "완성하는 것"이 목표가 아니라 "사용자에게 도달시키는 것"이 목표가 됩니다. 코드는 수단이고, 가치 전달이 목적입니다.

수익 US$0.35의 진짜 의미는 돈이 아니에요. 누군가가 내 앱을 실제로 썼고, 광고가 노출됐고, 그 흐름이 데이터로 돌아왔다는 신호예요. 그리고 그 흐름을 성장시키기 위해 업데이트를 계속 해야겠다는 동기부여. 이걸 경험하면 이전과 다른 더 올바른 방향을 스스로 찾을 수 있습니다.

영역	배포 전	배포 후
문제 정의	"뭘 만들면 재밌을까"	"뭐가 진짜 불편한가"
기술 선택	트렌디한 기술 우선	안정성 · 크래시율 · 배포 효율
사고 방식	완성이 목표	사용자 도달이 목표

왜 어떤 개발자는 계속 빠르게 움직이고, 어떤 개발자는 제자리를 도는지 오랫동안 관찰했어요. 가장 큰 차이는 실력이 아니에요. 사용자를 만나본 적이 있는가입니다. 한 번이라도 만든 걸 세상에 내보낸 사람은, 다음 프로젝트의 문제 정의부터 달라져요.

질문이 바뀌어야 합니다

정리합니다.

AI는 구현을 대체합니다.
AI는 설계를 점점 도와줍니다.
하지만 방향은 여전히 사람 몫입니다.

그래서 깊이는 여전히 필요해요. 다만 목적이 바뀌었을 뿐입니다. 구현하기 위해서가 아니라, 판단하기 위해서. 코드를 잘 짜기 위해서가 아니라, 올바른 방향을 선택하기 위해서.

이제 개발자의 질문도 바뀌어야 해요.

"얼마나 더 공부해야 할까?" — 아니에요.
"왜 이걸 만들어야 하는가?" — 이게 지금 던져야 할 질문입니다.

이제 개발자는 코드를 잘 짜는 사람이 아니라, 만들어야 하는 이유를 아는 사람입니다.

그럼 어떻게 실행해야 실제로 사용자를 만날 수 있을까요. 깊이 있게 이해한 사람이 빠르게 실행으로 넘어가기 위한 구체적인 방법은, 다음 글에서 이어서 풀어보려고 해요. 이런 흐름을 함께 탐구하고 싶다면 회원 가입해 주세요.