10월 15일, 개발자 Pinecoder가 글 하나를 올렸습니다. 제목은 "My old job feels very distant now". 옛 직무가 아주 멀리 떨어져 나간 느낌이라는 뜻입니다. 18일 GeekNews에서 다시 주목받았습니다.

이 글의 값어치는 결론이 아니라 과정에 있습니다. AI 코딩 도구를 몇 년에 걸쳐 쓰면서 개발자의 일 자체가 어떻게 바뀌었는지, 단계별로 아주 구체적으로 적었습니다. 그리고 마지막에 정직한 질문 하나를 남깁니다. "코드가 빨라질수록, 나는 그 코드를 어떻게 계속 이해할 것인가."

중요한 단서를 먼저 붙입니다. 이 글은 개인 경험이고, 생산성 수치는 본인이 스스로 보고한 값입니다. 벤치마크가 아닙니다. 그러니 숫자를 일반화하지 말고, 변화의 방향과 실천 방식을 읽는 게 좋습니다.

起: 단계별로 본 변화

글의 흐름을 시간순으로 정리하면 이렇습니다.

[Pinecoder가 지나온 단계]

1. ChatGPT = 더 나은 구글
   - 코딩 검색 결과가 쓸모없던 시절, "일단 물어보기"가 기본값

2. 코드 복사·붙여넣기
   - 손으로 쓰기 싫은 Ruby 스펙 등을 대신 생성
   - 러닝 커브를 잠시 유예하는 도피처

3. 탭 완성 + 새 도메인 복붙
   - VSCode에서 갈라져 나온 Cursor
   - 컴퓨터 비전(Python)을 검색+생성으로 동시에 학습
   - 환각이 경계에서 나타난다는 감각을 여기서 얻음

4. 에이전트 코딩 (Claude)
   - 탭 완성에서 프롬프팅으로 이동
   - "코드베이스는 여전히 머릿속에, 모든 줄을 리뷰"
   - PR이 병목이 되기 시작

5. Opus 4.5/6
   - 생산성 약 3배 (수개월간 병합된 PR 기준, 자기 보고)
   - 스캔을 잘하게 됨, "중요한 부분"만 보게 됨

6. Opus 5
   - 코드는 더 좋아졌지만, 비용과 장황함이 문제

7. Opus 5.5
   - "동결, 제로" — 다시 적응해야 하는 단계

재미있는 건 3단계에서 얻은 통찰입니다. AI의 환각은 "모르는 것의 경계"에서 나타나고, 그 경계는 곧 사람이 메워야 할 지점이라는 것. 즉 AI가 유용할수록, 사람이 채워야 할 자리가 어디인지 더 선명해집니다.

承: 무엇이 실제로 달라졌나

5단계 이후 저자가 관찰한 변화가 이 글의 핵심입니다. 요약하면 이렇습니다.

[일의 무게 중심이 옮겨간 지점]

계획 수립
  예전 : 작업을 계획하고, 단계별로 직접 구현
  지금 : "내가 하고 싶은 코드 리뷰"가 아니라
         "내가 하고 싶은 QA"를 먼저 생각한다

아키텍처
  - 결정은 되돌릴 수 있어야 한다(reversible)를 전제로
  - UI가 확신이 안 서면? 그냥 더 많이 만들어 본다
  - 비슷한 아이디어 세 개? 셋 다 만든다
  - 이걸 단일 HTML 페이지로 뽑을 수 있나?

산출물
  - 계획·진행·프로젝트 노트를 노트 앱에 덤프하게 한다
    (때로는 채팅 대신 이 노트에서 작업한다)
  - 데이터로 뒷받침되는 산출물을 더 만든다
  - 그것을 AI가 쓸 도구(작업 상태·이력 추적)로 바꾸고,
    내가 진행을 시각화할 도구로도 바꾼다
  - 취약점 보고서는 배치로 일괄 수정
  - 주요 시점을 표시한 번다운 차트
  - 성능이 걱정되면 성능 모니터링도 붙인다

특히 눈에 띄는 것은 "서브에이전트"와 "감독자(supervisor)" 패턴입니다.

[여러 에이전트를 굴리는 방식]

서브에이전트들이 작업을 나눠 맡는다
        ↑
감독자(supervisor)가 위에서 전체 그림을 본다

저자가 던지는 다음 질문:
- 아키텍처를 어느 수준까지 내가 지정해야 하나?
- 어떤 결과에 집중해야 하나?
- 빈틈이 생기면, 다른 모델에게 그걸 공격하게 해서
  찾아내고, 모델들이 협력해 설계를 강화할 수 있나?

이건 도구 사용법이 아니라 워크플로 설계입니다. 사람이 코드를 다 쓰던 시절의 "리뷰"가, 여러 에이전트를 감독하고 검증하는 일로 바뀌는 지점입니다.

轉: 제약이 지시를 대신한다

가장 실무적인 대목은 7단계의 일화입니다. 저자는 UI를 빠르게 만들고 싶었습니다. 예전 같으면 옵저버블이나 특정 최적화 방식을 지시했을 것입니다. 이번에는 다르게 했습니다.

[지시 → 제약]

예전: "옵저버블을 쓰고, 이렇게 최적화해"
지금: "이미지는 15ms 안에 처리돼야 해" <엔터>

저자: 어, 150ms라고 쓰려던 건데… 일단 모델이 하는지 보자
결과: 모델이 해냈다

→ 저자가 다시 생각하게 된 것:
  "내가 가능하다고 생각하는 것의 한계 자체를
   재평가해야 한다."

그리고 결정적인 일화가 이어집니다. Electron으로 만든 노트 앱을 iPhone으로 옮겨 달라고 프롬프트합니다. 네이티브 Swift로 원하는 대로 다시 짜라는 요청이었습니다. 그냥 아이디어를 던지고 자리를 떴습니다. 몇 시간 뒤 핸드폰으로 뉴스를 보다가, 동작하는 앱이 네트워크로 설치되어 나타나 인터럽트합니다. 모델이 QA를 요청할 수 있도록 스스로 설치한 것입니다. 20달러 구독의 5시간 한도 중 40%를 썼습니다. 기능이 완성된 건 아니지만, 동작했습니다.

저자가 화면을 멍하니 바라봤다는 대목에서 이 글이 개인 에세이로서 갖는 힘이 나옵니다.

結: 그래서 남는 질문

글은 이렇게 닫힙니다.

"코드가 빨라질수록,
 나는 그 코드를 어떻게 계속 이해할 것인가?

 → 새로운 지표를, 새로운 대시보드를 만든다
 → 설계의 가장 중요한 부분과 제약을 더 깊이 생각한다
 → 그곳에만 주의와 노력을 쏟을 가치가 있다
 → 나를 이해시키는 도구와, 모델이 쓸 도구를 만든다"

이 결말은 앞선 흐름과 정확히 맞물립니다. 코드 한 줄씩 읽는 방식이 무너지면, 이해의 방식 자체를 다시 설계해야 합니다. "이해했다"를 증명하는 방법이 코드 리뷰에서 지표·대시보드·제약으로 옮겨갑니다.

같은 고민을 다른 각도에서 다룬 글이 있습니다. Anthropic의 Claude Code 팀은 "사람이 코드를 읽었는가"라는 질문 자체를 버리고 리뷰를 자동화하고 위험 기반 승인으로 옮겼습니다(Claude Code 팀의 코드 리뷰 6계층). 두 글은 같은 벽을 다른 면에서 밀고 있습니다.

결론: 브리핑 액션을 나만의 프로토콜로

브리핑이 제안한 액션은 "에이전트 작업마다 완료 조건·테스트 결과·성능 지표·되돌리기 방법을 기록하라"였습니다. 이를 프로토콜로 다듬으면 이렇습니다.

[AI 에이전트 작업 기록, 미니 프로토콜]

작업 하나가 끝날 때마다 네 가지를 남긴다

1. 완료 조건 (Definition of done)
   [ ] 무엇이 되면 끝인가를 한 문장으로
   [ ] 제약으로 적는다 (예: 렌더 150ms 이내)

2. 검증 증거
   [ ] 테스트 결과
   [ ] 성능 지표
   [ ] 되돌리기 방법 (reversible한가)

3. 이해의 흔적
   [ ] 중요한 부분(비즈니스 로직·고객 데이터·비가역 변경)에
       대한 설명을 한 단락
   [ ] 설명하지 못하는 변경은 "이해 필요"로 표시

4. 지표와 대시보드
   [ ] 진행 상태를 눈으로 볼 수 있게
   [ ] 취약점·성능 같은 것은 배치로 묶어 추세를 본다

핵심 문장은 이렇습니다.

개발자의 경쟁력은 코드 작성 능력에서
문제 정의·시스템 설계·검증 능력으로 확장된다.

이 글의 진짜 메시지는 "AI가 대단하다"가 아닙니다. 도구가 좋아질수록 사람이 붙잡아야 할 것이 위로 올라간다는 것입니다. 저자는 그것을 "설계의 가장 중요한 부분과 제약"이라고 부릅니다. 그리고 그곳에 집중하는 것이 지금 이 직업의 핵심이라고 말합니다. 여러 에이전트를 감독하고 루프를 설계하는 감각은 에이전트 성과 지표와 루프 엔지니어링이란 무엇인가에서 더 구체적으로 이어 볼 수 있습니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

에이전트를 감독하고, 완료 조건을 정의하고, 검증 루프를 설계하는 일은 결국 하네스와 루프를 직접 만들어 볼 때 몸에 붙습니다. 여러 에이전트를 그래프로 엮고 결과를 검증하는 흐름을 다뤄 보면, 위 프로토콜이 왜 필요한지 체감이 됩니다.