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

개발자의 정체성은 코드를 짜는 행위 위에 세워져 있다. "나는 개발자다 = 나는 코드를 짠다"라는 등식이 너무 자연스러운 나머지, 이게 전제라는 사실조차 깨닫지 못할 때가 많다.

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

한 시니어의 하루: 전환 전 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/