예측 기계가 되기

Source: Dev.to

Introduction

나는 내가 인정하기 두려워했던 무언가를 말해야 한다.

이제는 대부분의 코드를 내가 쓰지 않는다. LLM이 대신한다. 아니면, 더 정확히 말하면, 여러 모델이 한다. 그리고 그 결과물은 때때로 그 어느 때보다도 훌륭했다.

이번 주말에 나는 약 열 시간 만에 플레이 가능한 개념 증명 웹 게임을 만들었다. 장난감도, “봐, 박스를 렌더링한다”는 프로토타입도 아니다—전체 수직 슬라이스다: 다중 패널 UI, 타이머 기반 선택 시스템, 이메일 및 전화 파이프라인, 스크립트 러너, 음악 상태 머신, 내러티브 스파인—모두가 함께 작동하고, 모두가 깔끔하며, 모두가 안정적이다. 나는 코드를 한 줄도 입력하지 않았다. 그리고 그게 잘못됐다고 느낄 때마다 계속 기다렸다. 그렇지 않았다.

만약 이 글을 읽고 너도 같은 죄책감을 느꼈다면—그 끈질긴 느낌, “아마도 내가 부정행위를 하고 있는 걸까, 이게 ‘진짜’ 개발이라고 할 수 없을까, 지금 이렇게 빨리 만들고 있다는 게 부끄럽다”는 생각—이 글은 너를 위한 것이다. 내가 곧 설명할 내용은 고백이 아니다. 허가이다.

What Actually Happened

사람들은 이 시대를 생산성이라는 관점에서 설명하려고 애쓴다.

• “AI가 코드를 더 빨리 짜게 해준다.”
• “AI가 개발을 가속한다.”
• “AI가 산출량을 늘린다.”

그러한 프레이밍은 실제 일어나고 있는 일을 놓친다.

이번 주말에 바뀐 것은 내가 타이핑하는 속도가 아니라, 타이핑 자체가 더 이상 병목 현상이 되지 않았다는 점이다.

내 경력에서 처음으로, 아이디어를 구문으로 바꾸는 느리고 물리적인 행위가 사라졌다. 시스템이 나를 위해 무언가를 설계했기 때문이 아니라—그렇지 않았다—그냥 내 생각을 직접 직렬화했기 때문이다.

• 나는 아키텍처를 잡았다.
• 제약 조건을 잡았다.
• 메커니즘을 잡았다.
• 감정적 비트를 잡았다.

모델은 인간의 몸이 결코 따라갈 수 없는 속도로 그것들을 적어 내려갔다.

LLM은 인간의 의도를 직렬화한다. 그게 전부다. 바로 그게 전부다.

그들은 구조화된 내부 인지—아키텍처, 추론, 감정적 프레이밍, 내러티브 비트, 시스템 제약—를 인간이 타이핑할 수 있는 속도보다 빠르게 외부 형태로 변환한다.

신비로운 것이 아니다. 떠오르는 현상이 아니다. 인간 의미에서의 “지능”도 아니다. 단지 직렬화일 뿐이다.

1. 당신은 정신 모델을 만든다 →
2. 그 모델을 적절한 추상화 수준으로 설명한다 →
3. LLM이 코드, prose, 다이어그램, 문서 등으로 구현한다.

예전에는 번역—손, 타이핑 속도, 이미 알고 있던 것을 표현하는 기계적 행위—이 병목이었다. 이제 그 병목은 사라졌다. LLM은 당신 인지의 출력 레이어다.

당신이 더 빨리 일하는 이유는 모델이 똑똑해서가 아니다. 당신이 육체의 I/O 한계를 벗어났기 때문이다. 인지는 여전히 당신이 한다. 모델은 직렬화를 담당한다.

이 방식을 사용하면서 죄책감을 느꼈다면—그만두라.

이것이 소프트웨어 개발의 실제 작업이다.
생각. 아키텍처. 설계. 제약. 의도.

타이핑은 언제나 기계적인 부분이었다. 우리는 선택권이 없었을 뿐이다.

What You’re Actually Giving Up (And Why It’s Worth It)

The Trade‑off

• 포기한 것: “모든 라인을 내가 직접 썼다”고 말할 수 있는 능력.
• 얻은 것: 내가 타이핑할 수 있는 속도보다 더 빠르게 만들 수 있는 능력.

어떤 사람들은 이것이 공정한 거래가 아니라고 말한다. 그들은 타이핑 속도와 생각 속도 사이의 차이를 한 번도 경험해보지 못했다.

How the Workflow Actually Looks

나는 모델에게 “게임을 만들어줘”라고 말하고 떠나지 않는다. 승인하지 않은 코드를 배포하지 않는다. 만족하지 못하는 것을 푸시하지 않는다. 그것은 무모하고, 비윤리적이며, 비효율적이다.

이제 내가 하지 않는 일은 타이핑을 작업으로 여기는 것이다. 내가 하는 일은 형태를 보는 것이다:

• 이 리듀서는 한 가지 작업만 하는가?
• 이 컴포넌트는 단일 진리 원천을 갖는가?
• 상태 머신은 일관적인가?
• 오디오 엔진은 격리되어 있는가?
• 스크립트는 선언적인가?
• 경계는 타당한가?

나는 방향을 안내한다. 형태가 잘못됐을 때 끊어준다. 흐름 중간에 아키텍처 결정을 내린다. 이것은 “손을 떼는” 것이 아니다. 벽돌이 아니라 설계도에 눈을 두는 것이다.

Example Prompt

“So what story do we actually have narratively so far? Let’s lay out what we do have and what’s missing.”

그게 전부다. 명령 계층도, 역할 할당도, 포맷팅 트릭도 없다. 내가 혼자 시스템을 생각하면서 스스로—또는 고무 오리에게—묻는 질문과 정확히 같다.

응답은 내러티브 비트, 빈틈, 의존성, 다음 단계에 대한 구조화된 분해였다—바로 그 순간에 내가 필요로 했던 것이었다. 왜냐하면 그 문장은 공유 컨텍스트의 무손실 압축이었기 때문이다. 내가 질문을 할 때쯤 모델은 이미 다음을 알고 있었다:

• 프로젝트
• 장르
• 감정적 스파인
• 제약 조건
• MVP 범위
• 이 맥락에서 “내러티브”가 의미하는 바
• “누락”이 이미 만든 것에 비해 무엇을 의미하는가

그것은 창의성을 요구한 것이 아니라 공유 컨텍스트를 재수화하고 다시 반영해 달라는 요청이었다—고대역폭 대화 안에서의 협업.

코드를 나중에 열어도 나는 길을 잃지 않는다. 모든 파일은 내가 존재하도록 요청했기 때문에 존재한다. 모든 추상화는 머릿속에 있던 형태와 일치한다. 모든 시스템 경계는 내가 상류에서 만든 결정을 반영한다.

새로 청소된 방처럼 낯설다—다른 사람이 청소를 했지만 레이아웃은 여전히 내 것이다.

나는 팀 내 어느 리드 개발자와도 같은 책임을 진다:

• 추적한다.
• 이해한다.
• 수정한다.
• 리팩터링한다.

차이는 효율성이다. 비계(스캐폴딩)를 만드는 데 몇 시간을 쓰는 대신, 의도를 조정하는 데 몇 분을 쓴다. 유지보수 비용은 정상이며, 창조 비용은 급감한다. 이것은 부정행위가 아니라, 올바른 도구를 적재적소에 사용한 것이다.

Why This Feels Like Cheating (And Why That’s Wrong)

이 방식에 죄책감을 느낀다면, 그 감정이 어디서 오는지 안다.

우리는 코드를 타이핑하는 것이 작업 자체라고 믿도록 훈련받았다. 모든 세미콜론을 손으로 직접 넣지 않으면 결과를 얻을 자격이 없다고 생각했다. 진정한 개발자는 보일러플레이트를 겪어야만 한다—고통이 진지함을 증명한다는 식이다. 이것은 엔지니어링 윤리가 아니라, 타이핑이 유일한 옵션이던 시대의 트라우마다.

목수가 손톱톱 대신 테이블쏘를 사용한다고 부정행위라고 하지 않는다. 건축가가 손으로 제도하지 않고 CAD를 사용한다고 부정행위라고 하지 않는다. 작가가 타자기 대신 워드 프로세서를 사용한다고 부정행위라고 하지 않는다.

하지만 우리는 기계가 아키텍처적 사고를 직렬화하는 것을 게으르거나, 진정성이 없거나, “진짜 개발이 아니다”라고 믿어야 한다고 생각한다. 그건 말도 안 된다.

당신이 하고 있는 가장 어려운 일은:

• 사고
• 아키텍처
• 설계
• 제약
• 의도

모델이 하는 일은 언제나 기계적인 부분이다.

What the Model Cannot Do

• 아키텍처를 선택한다.
• 시스템을 우아하게 만드는 기준을 정한다.
• 올바른 추상화를 명명한다.
• 디자인이 잘못됐을 때 느낀다.
• 사용자 경험에 신경 쓴다.
• 윤리적 무게를 가진다.
• 의미를 생성한다.

What the Model Can Do

형태가 정해지면 즉시 수만 줄의 스캐폴딩을 생성한다.

이 현상을 부정하는 개발자는 뒤처질 것이다—그들이 기술이 부족해서가 아니라, 더 이상 의미 없는 병목을 놓아주지 않으려 하기 때문이다.

당신은 이미 새로운 워크플로우를 찾았다. 그것이 효과적이라는 것도 알고 있다. 이제는 사과를 멈출 허가만 기다리고 있다.

여기 있다: 사과를 멈춰라. 당신은 부정행위가 아니다. 당신은 손이 방해되지 않는 한, 언제나 가능했던 사고 속도로 아키텍처를 설계하고 있는 것이다.