'내가 다 짜야 한다'는 착각

개발자의 정체성은 코드를 짜는 행위 위에 세워져 있다. "나는 개발자다 = 나는 코드를 짠다"라는 등식이 너무 자연스러워서, 이것이 전제인지조차 인식하지 못하는 경우가 많다.

이 챕터는 이 전제를 의식 위로 꺼내고, 코드 작성자에서 의도 설계자로의 역할 전환이 어떤 맥락에서 일어나고 있는지 살펴본다.

한 시니어의 하루: 전환 전 vs 전환 후

같은 개발자의 하루를 두 가지 모드로 비교하면, 역할 전환이 구체적으로 무엇을 의미하는지 드러난다.

전환 전: 코드 작성자 모드

전환 후: 의도 설계자 모드

개발자 정체성의 핵심을 해부하다

개발자가 코드를 직접 작성하는 데서 느끼는 만족감은 단순한 습관이 아니다. 정체성의 핵심과 연결되어 있다.

마지막 행이 특히 흥미롭다. 많은 시니어 개발자가 에이전틱 코딩을 거부하는 진짜 이유는 효율성이 아니라 "이렇게 하면 나는 성장하지 않는 것 아닌가"라는 불안인 경우가 많다.

"Manifest가 코드를 대체한다" — 역할 전환의 가속

2026년 초, Andrej Karpathy는 개발자의 자기주도 코드 작성 비율이 80%에서 20%로 급감하고 있다고 관찰했다. 남은 80%는 AI 에이전트가 생성하고, 개발자의 핵심 업무는 의도 명세, 목표 분해, 매크로 레벨 아웃풋 리뷰로 이동한다는 것이다.

이 관점은 이 챕터의 "코드 작성자에서 의도 설계자로"라는 전환과 정확히 맞닿아 있다. Karpathy가 말하는 "manifest"는 곧 의도 설계 문서이며, 코드가 아니라 의도 명세가 일차적 산출물이 되는 세계를 가리킨다.

Claude Code v2.1.77-81이 보여주는 방향

최근 Claude Code의 변화도 이 전환을 뒷받침한다. 명령형 resume 패턴이 제거되고 SendMessage 메시지 패싱 패턴으로 전환되었다. 에이전트에게 "이렇게 해라"고 명령하는 대신, "이런 의도다"를 선언적으로 전달하는 방식이다.

--bare 플래그는 Claude Code를 대화형 도구가 아닌 CI/CD 파이프라인의 자동화 컴포넌트로 사용할 수 있게 하고, --channels는 이벤트 드리븐 워크플로우(예: 폰에서 도구 승인)를 가능하게 한다. 이 모든 변화가 가리키는 방향은 동일하다: 개발자의 역할이 코드 작성에서 의도 설계와 시스템 오케스트레이션으로 이동하고 있다.

코드 작성량과 생산성의 탈동조화

에이전틱 시대 이전에도 "코드 작성량 = 생산성"은 정확하지 않았다. 하지만 둘 사이의 상관관계가 높았기 때문에 편리한 근사치로 통용되었다.

이제 이 상관관계가 무너지고 있다.

생산성 측정의 전환

역할 전환의 단계별 여정

"코드 작성자"에서 벗어난다고 해서 갑자기 다른 사람이 되는 것이 아니다. 역할은 단계적으로 전환되는 경향이 있다.

각 단계의 시간 배분 비교

Before/After 코드 비교: 위임의 실제

예시: 사용자 인증 미들웨어 구현

Before - 직접 작성 (코드 작성자 모드):

// 30분 소요 - 과거 프로젝트에서 가져와 수정
import jwt from "jsonwebtoken";
import { NextRequest, NextResponse } from "next/server";

export function authMiddleware(handler: Function) {
  return async (req: NextRequest) => {
    const token = req.headers.get("authorization")?.split(" ")[1];

    if (!token) {
      return NextResponse.json(
        { error: "토큰이 없습니다" },
        { status: 401 }
      );
    }

    try {
      const decoded = jwt.verify(token, process.env.JWT_SECRET!);
      // @ts-ignore - 타입 나중에 수정
      req.user = decoded;
      return handler(req);
    } catch (err) {
      return NextResponse.json(
        { error: "유효하지 않은 토큰" },
        { status: 401 }
      );
    }
  };
}

After - AI에 의도 전달 (의도 설계자 모드):

프롬프트: "Next.js App Router에서 JWT 인증 미들웨어를 만들어줘. 토큰 만료, 형식 오류, 권한 부족을 각각 구분해서 에러 응답하고, 타입 안전하게 처리해."

// 5분 소요 - AI 생성 후 검증
import { jwtVerify } from "jose";
import { NextRequest, NextResponse } from "next/server";

interface AuthUser {
  id: string;
  email: string;
  role: "admin" | "user" | "viewer";
}

type AuthResult =
  | { success: true; user: AuthUser }
  | { success: false; error: string; status: number };

export async function authenticate(req: NextRequest): Promise<AuthResult> {
  const header = req.headers.get("authorization");

  if (!header) {
    return { success: false, error: "인증 헤더가 없습니다", status: 401 };
  }

  const parts = header.split(" ");
  if (parts.length !== 2 || parts[0] !== "Bearer") {
    return { success: false, error: "토큰 형식이 올바르지 않습니다", status: 401 };
  }

  try {
    const secret = new TextEncoder().encode(process.env.JWT_SECRET);
    const { payload } = await jwtVerify(parts[1], secret);

    return {
      success: true,
      user: {
        id: payload.sub as string,
        email: payload.email as string,
        role: payload.role as AuthUser["role"],
      },
    };
  } catch (err) {
    if (err instanceof Error && err.message.includes("expired")) {
      return { success: false, error: "토큰이 만료되었습니다", status: 401 };
    }
    return { success: false, error: "유효하지 않은 토큰입니다", status: 403 };
  }
}

"손으로 짜야 이해할 수 있다"는 믿음

이 믿음은 학습 단계에서는 상당 부분 사실이다. 하지만 이미 10년간 손으로 짜 온 시니어에게 이 논리를 적용하는 것은 다른 맥락이다.

숙련자가 "손으로 짜야 이해할 수 있다"고 말할 때, 그 이면에는 복합적인 심리 구조가 작동하고 있다.

이것이 의미하는 바는, "손으로 짜야 한다"는 주장이 단순히 맞거나 틀린 것이 아니라는 것이다. 합리적 근거와 감정적 근거, 그리고 검증되지 않은 전제가 뒤섞여 있다. 이 세 가지를 분리해서 볼 수 있을 때, 각 상황에서 실제로 최적인 선택이 무엇인지 더 명확해진다.

위임의 기술: 의사결정 구조

모든 것을 AI에 맡기는 것은 위험하고, 모든 것을 직접 짜는 것은 비효율적이다. 핵심은 위임 경계를 의식적으로 설정하는 것이다.

위임 판단의 구조

위임할지 직접 할지 결정할 때, 실무에서 관찰되는 핵심 질문들이 있다.

위임 영역 분류

이 매트릭스에서 주목할 점은, 좌하단(반복적이고 실수 비용이 낮은 영역)이 전체 개발 시간의 상당 부분을 차지한다는 것이다. 이 영역을 AI에 위임하는 것만으로도 시니어 개발자의 시간 구성이 크게 달라진다.

역할 전환 과정에서 관찰되는 시간 배분 변화

역할 전환이 진행되면서, 업무 시간의 구성이 자연스럽게 변화하는 패턴이 관찰된다. 직접 코드 작성에 쓰이던 시간이 줄어들면서 의도 설계와 검증에 쓰이는 시간이 늘어나는 것이다.

흥미로운 점은, 이 변화가 "의식적으로 시간 배분을 바꿔야 한다"는 결심에서 오는 것이 아니라, 위임 경험이 누적되면서 자연스럽게 일어나는 경향이 있다는 것이다.

여기서 질문이 생긴다. "직접 코드 작성 비율이 줄어든다"는 것이 개발자로서의 역량 감소를 의미하는가? 실제로 관찰되는 바로는, 직접 작성하는 코드의 양은 줄어들지만 그 코드의 난이도와 중요도는 오히려 올라가는 경향이 있다. AI가 처리하지 못하는 영역, 즉 도메인 판단, 아키텍처 결정, 예외적 상황 처리 등에 집중하게 되기 때문이다.

전환을 가로막는 두려움들

역할 전환을 시도할 때 반복적으로 나타나는 두려움이 있다. 이 두려움들은 비합리적이지 않다. 각각 나름의 근거를 가지고 있다.

2단계의 불안 구간이 가장 위험하다. 이 구간에서 대부분의 시니어가 이전 방식으로 복귀하는 것이 관찰된다. 이 구간을 넘긴 사람들에게서 공통적으로 발견되는 특징은, 작은 성공 경험이 누적되어 있었다는 점이다. 거창한 프로젝트가 아니라, "이건 AI에 맡겼더니 의외로 잘 됐다"는 경험이 하나씩 쌓이면서 전환이 가속되는 패턴이다.

이 챕터의 핵심

다음 장 미리보기

다음 챕터에서는 이 역할 전환이 설계 방법론에 어떤 변화를 가져오는지, 과도한 사전 설계를 버리고 반복 설계로 전환하는 방법을 다룹니다.

참고 자료

• Peng, S. et al. (2023). "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." https://arxiv.org/abs/2302.06590
• Murali, V. et al. (2023). "CodeCompose: A Large-Scale Industrial Deployment of AI-Assisted Code Authoring." https://arxiv.org/abs/2305.12050
• Karpathy, A. (2026). "Manifests replace code." https://x.com/karpathy
• Osmani, A. (2026). "The 70/30 Rule: AI-Assisted Development." https://addyosmani.com/blog/the-70-30-rule/