긍정적 사고, 음식의 절제, 규칙적인 운동

경력자에겐 날개, 청년에겐 벽…저연차 청년 직군부터 강타하는 AI 고용 충격

https://www.itworld.co.kr/article/4213910

AI가 노동 시장에 미치는 영향이 가시화되면서, 그 충격이 경력을 막 시작한 청년층에 집중되고 있다는 연구 결과가 나왔다. 스탠퍼드대학교 디지털경제연구소 연구팀의 최신 연구에 따르면, AI는 이미 고용 시장에 영향을 미치기 시작했으며 주로 커리어 초기의 청년층에 타격을 주고 있다. 연구팀은 HR 플랫폼 ADP의 익명 급여 데이터를 분석하고, AI 노출 정도가 서로 다른 직종들을 비교해 결론을 도출했다.

22세에서 25세 연령대를 분석한 결과, AI 노출도가 높은 직종의 고용률이 노출도가 낮은 직종보다 19% 낮은 것으로 나타났다. 지난해에는 그 격차가 13%였다.

스탠퍼드 연구팀은 2026년 6월 기준 데이터를 반영한 개정 논문에서 청년 고용 감소를 이끄는 메커니즘도 새롭게 규명했다. 핵심은 ‘형식지(codified knowledge)’와 ‘암묵지(tacit knowledge)’의 구분이다. 형식지란 교육과 교재, 문서화된 절차를 통해 습득할 수 있는 공식적·표준화된 지식으로, 생성형 AI는 이런 지식을 재현하고 적용하는 데 강점을 보인다. 반면 현장 경험과 멘토링, 반복적인 실무를 통해 쌓이는 암묵지에 의존하는 직종에서는 오히려 고연차 근로자의 고용이 증가했다. 연구팀은 생성형 AI가 텍스트로 부호화된 지식을 복제하고 적용하는 데 특히 효과적이라는 점이 이 같은 패턴을 설명한다고 밝혔다.


노동 시장 전반으로 시야를 넓히면 격차는 상당히 줄어든다. 고연차 근로자와 경험이 많은 직원은 같은 방식으로 영향을 받지 않았다. 연구팀은 기존 직원 해고보다 AI 노출 직종에서 청년층 신규 채용 자체가 감소하는 방식으로 변화가 일어나고 있다고 분석했다.

골드만삭스도 8월 19일 공개한 보고서 ‘글로벌 경제 논평: AI는 글로벌 노동 시장에 영향을 미치고 있는가’에서 유사한 결론을 내놨다. 800개 이상의 직종을 분석한 결과, AI 자동화 노출도가 높은 산업에서 2022년 하반기 이후 채용 공고 증가세가 둔화된 것으로 나타났으며, 미국·독일·호주에서 그 패턴이 특히 뚜렷했다. AI 노출도 10%포인트가 연간 고용 증가율에 미치는 부정적 영향은 전체 노동자 기준으로 0.1%포인트에 그쳤지만, 저연차 근로자에게는 미국 기준 0.2%포인트 이상, 호주에서는 0.6%포인트 이상으로 집계됐다. AI 노출 직군 가운데 고용 감소폭이 가장 큰 분야는 콜센터였다. 미국 내 콜센터 고용은 추세선 대비 39% 낮은 수준에 머물렀으며, 캐나다는 33%, 독일은 27%로 나타났다.

국제노동기구(ILO)도 8월 11일 발표한 ‘2026 청년 고용 글로벌 동향: 미래로의 귀환’ 보고서에서 우려를 표명했다. 보고서에 따르면 2025년 전 세계 청년 실업률은 12.4%로, 6,700만 명에 달하는 15~24세 청년이 일자리를 갖지 못한 것으로 나타났다. 청년층 일자리 중 6.1%가 AI에 의한 업무 대체 위험에 높은 수준으로 노출돼 있으며, 노출 직종 일자리 중 10%만 사라져도 최대 560만 명의 청년 근로자가 영향을 받을 수 있다고 ILO는 경고했다.


청년층에서의 감소세는 AI가 특정 업무를 대체하는 방식으로 활용되는 직종에서 가장 두드러지게 나타났다. AI가 직원의 업무를 보완하는 방식으로 활용되는 경우에는 양상이 훨씬 복잡했다. 한국도 예외는 아니다. 한국은행이 분석한 자료에 따르면, 2022년 6월부터 2026년 6월 사이 15~29세 청년 고용이 28만 5,000명 감소했으며, 그 중 26만 8,000명(94%)이 AI 노출도가 높은 산업에서 발생한 감소분이었다. 정보서비스, 출판, 컴퓨터 프로그래밍, 전문 서비스 분야에서 감소폭이 가장 컸다. 골드만삭스는 한국은행 분석을 인용하며, AI 고용 충격이 특정 국가만의 현상이 아닌 선진국 전반에 걸친 구조적 변화임을 강조했다.

에이전트가 소극적인 건 성격 문제가 아니라 지시문 문제입니다. 어디서 멈춰야 할지를 알려주지 않으면, 에이전트는 가장 안전한 지점 — 첫 번째 답변 — 에서 멈춥니다.

대상: 로컬 VS Code에서 Claude Code를 쓰는 개발자 목적: 매번 확인받지 않고 한 번의 지시로 끝까지 진행시키기

1. 에이전트가 멈추는 세 지점

능동성을 설계하려면 먼저 어디서 멈추는지를 알아야 합니다. 실제로 멈추는 이유는 딱 세 가지입니다.

아래 다섯 요소는 이 세 지점을 지시문 안에서 미리 막아두는 방법입니다.

2. 능동적 요청문의 다섯 요소

순서는 상관없지만, 다섯 개가 다 있으면 에이전트는 되묻지 않고 끝까지 갑니다.

2-1. 목표 — 행동이 아니라 "상태"로 쓴다

"~를 해줘"는 한 번의 행동으로 끝납니다. "~인 상태로 만들어"는 그 상태가 될 때까지 반복하게 만듭니다. 이 한 끗 차이가 능동성의 대부분을 결정합니다.

• ❌ 테스트 고쳐줘
• ✅ npm test가 전부 통과하는 상태로 만들어

2-2. 완료 판정 — 에이전트가 직접 실행할 수 있는 검증 명령을 준다

사람이 눈으로 확인하는 기준 말고, 터미널에서 참/거짓이 나오는 기준을 주세요. 그래야 에이전트가 자기 작업을 스스로 채점하고 다시 시도합니다.

완료 기준: npm run lint, npm run build, npm test 세 개가 모두 exit 0.

2-3. 중단 규칙 — "멈추지 마"와 "여기선 멈춰"를 함께 준다

중간 확인을 금지하되, 진짜 위험한 예외는 명시적으로 열어두세요. 예외를 안 주면 에이전트는 불안해서 계속 되묻거나, 반대로 건드리면 안 되는 걸 건드립니다.

중간에 확인 요청하지 말고 끝까지 진행해. 단 운영 DB 접근 · git push --force · 시크릿 파일 수정은 실행 전에 반드시 멈추고 물어봐.

2-4. 판단 기준 — 갈림길에서 쓸 기본값을 미리 준다

"애매하면 물어봐"는 곧 중단입니다. 대신 "애매하면 이렇게 해"를 주면 진행됩니다. 가정 세우는 걸 막지 말고, 대신 나중에 보고하게 하세요.

판단이 갈리면 기존 코드 스타일을 따르는 쪽으로 결정하고, 세운 가정은 마지막에 목록으로 보고해.

2-5. 작업 범위 — 마음대로 해도 되는 영역을 못 박는다

범위가 열려 있으면 에이전트는 조심스러워집니다. 자유 영역과 금지 영역을 같이 주면 그 안에서는 확실히 능동적으로 움직입니다.

src/**, tests/** 안에서는 파일 생성·삭제·수정 다 알아서 해. migrations/, .env*, package-lock.json은 손대지 마.

2-6. (보너스) 보고 — 끝에 무엇을 받을지 정한다

보고 형식을 지정하면 에이전트가 중간 설명을 줄이고 실행에 집중합니다. 진행 중 수다가 줄어드는 부수 효과도 큽니다.

진행 중 설명은 최소로. 끝나면 변경 파일 목록 / 세운 가정 / 남은 리스크 세 항목만 보고해.

3. 같은 일, 다른 지시문 (Before / After)

사례 A. 버그 수정

❌ 멈추는 지시문

로그인 API에 버그 있는 것 같은데 좀 봐줘.

범위·완료조건·권한이 전부 비어 있음. 에이전트는 코드를 읽고 "이런 것 같습니다" 리포트를 쓰고 멈춥니다.

✅ 끝까지 가는 지시문

로그인 API에서 만료 토큰이 401 대신 500을 반환하는 버그를 재현부터 수정까지 끝내줘.

1) 실패하는 테스트를 먼저 작성해서 재현하고
2) 원인을 고치고
3) npm test가 전부 통과할 때까지 반복해.

src/auth/**, tests/** 안에서는 알아서 수정해.
중간 확인 없이 진행하고, 끝나면 변경 파일과 원인 한 줄만 보고해.

상태 목표 + 검증 명령 + 범위 + 중단 금지. 재현 → 수정 → 검증 루프가 지시문 안에 들어 있습니다.

사례 B. 리팩터링

❌ 멈추는 지시문

이 코드 리팩터링 좀 해줘.

"리팩터링"은 끝이 없는 동사입니다. 어디까지가 완료인지 모르니 한두 개만 고치고 "이런 것도 가능합니다"로 끝납니다.

✅ 끝까지 가는 지시문

src/services 아래에서 200줄 넘는 파일이 하나도 없는 상태로 만들어줘.

먼저 대상 파일 목록과 분리 계획을 세우고, 승인 기다리지 말고 바로 실행해.
각 파일을 쪼갤 때마다 npm test를 돌려서 초록이면 다음 파일로 넘어가.
빨간불이면 최대 3번까지 스스로 고쳐보고, 그래도 안 되면 그 파일만 원복하고 목록에 남겨줘.

공개 API 시그니처는 바꾸지 마.

측정 가능한 완료 조건(200줄), 파일 단위 검증 루프, 실패 시 재시도 횟수와 폴백까지 지정.

사례 C. 의존성 업그레이드

❌ 멈추는 지시문

이 라이브러리 최신 버전으로 올려줄 수 있어?

가능 여부를 묻는 문장은 가능 여부에 대한 답을 받습니다. 게다가 breaking change 앞에서 반드시 멈춥니다.

✅ 끝까지 가는 지시문

axios를 최신 메이저로 올리고 빌드·테스트가 통과하는 상태로 만들어줘.

CHANGELOG의 breaking change를 먼저 확인하고, 우리 코드에서 영향받는 호출부를 전부 찾아서 고쳐.
마이그레이션 방법이 여러 개면 공식 문서 권장안을 택하고 이유를 마지막에 한 줄로 적어줘.

작업은 upgrade/axios 브랜치에서 하고, 커밋은 하되 push는 하지 마.

기본 판단 기준(공식 권장안)을 미리 주어 되묻기를 차단하고, 위험한 동작(push)만 명시적으로 금지.

4. 지시문만으로 안 되는 부분: 권한

지시문을 아무리 잘 써도 승인 프롬프트가 뜨면 거기서 멈춥니다. 자율 진행의 실질적인 병목은 대개 여기입니다.

⚠️ 주의 — 모든 검사를 건너뛰는 모드(bypassPermissions 계열)는 사내 코드베이스에서 기본값으로 쓰지 마세요. 자유 영역을 지시문으로 좁히고 --allowedTools로 필요한 도구만 여는 쪽이 훨씬 안전하면서 체감 속도는 같습니다.

5. 매번 쓰지 말고 한 번만 박아두기 (CLAUDE.md)

다섯 요소 중 중단 규칙 · 판단 기준 · 작업 범위 · 보고 형식은 매 요청마다 달라지지 않습니다. 프로젝트 루트의 CLAUDE.md에 넣어두면 모든 세션에 자동 적용되고, 지시문은 목표와 완료 조건 두 줄로 짧아집니다.

# 작업 방식

- 작업은 계획 → 실행 → 검증 순서로 진행하고, 중간 확인 요청 없이 끝까지 간다.
- 완료 전 반드시 `npm run lint`와 `npm test`를 직접 실행해 통과를 확인한다.
- 테스트가 실패하면 최대 3회까지 스스로 수정하고, 그래도 안 되면 시도한 내용과 함께 보고한다.
- 판단이 갈리면 기존 코드 스타일과 기존 패턴을 따르는 쪽을 택하고, 세운 가정은 마지막에 목록으로 보고한다.
- 진행 중 설명은 최소로 한다. 완료 보고는 변경 파일 / 가정 / 남은 리스크 세 항목.

# 손대면 안 되는 것

- `migrations/`, `.env*`, `package-lock.json` 수정 금지
- `git push --force`, 운영 DB 접근은 실행 전 반드시 확인

이렇게 해두면 평소 요청은 이 정도로 줄어듭니다.

결제 취소 API에서 중복 취소가 막히는 상태로 만들어줘.

6. 이벤트에 자동으로 반응시키기 (Hooks)

지시문은 사람이 말을 걸어야 시작됩니다. 훅은 말을 걸지 않아도 특정 시점에 무조건 실행되는 규칙입니다. 프롬프트로 "저장하면 린트 돌려줘"라고 부탁하는 것보다 확실합니다.

.claude/settings.json 예시 — 파일을 편집할 때마다 prettier와 eslint를 자동 실행:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_FILE_PATHS\" && npx eslint --fix \"$CLAUDE_FILE_PATHS\"",
            "timeout": 60
          }
        ]
      }
    ]
  }
}

• 훅 스크립트는 stdin으로 이벤트 JSON을 받고, 종료 코드로 결과를 알립니다.
• PreToolUse에서 exit 2를 반환하면 그 도구 호출이 차단됩니다.
• 팀 공통 규칙은 .claude/settings.json(커밋), 개인 설정은 .claude/settings.local.json(gitignore)에 둡니다.
• 이벤트 이름과 필드는 버전에 따라 늘어나므로, 적용 전 공식 훅 레퍼런스에서 현재 스키마를 확인하세요.

7. 반복되는 요청은 아예 명령으로 만든다

• 슬래시 커맨드 — .claude/commands/fix-tests.md에 다섯 요소를 다 갖춘 지시문을 저장해두면, 다음부터는 /fix-tests 한 단어로 같은 품질의 요청이 나갑니다. $ARGUMENTS로 인자를 받을 수 있습니다.
• 서브에이전트 — .claude/agents/*.md의 description에 "코드를 수정한 뒤에는 반드시 먼저 사용"처럼 언제 쓰는지를 적어두면, 사용자가 호출하지 않아도 Claude가 알아서 위임합니다. 능동성의 상당 부분이 이 한 줄에서 나옵니다.
• /loop — 배포 상태나 CI처럼 "될 때까지 지켜봐야 하는" 일은 세션 안에서 주기적으로 다시 확인하게 할 수 있습니다.
• GitHub Actions — PR·이슈처럼 사람이 자리에 없을 때 발생하는 이벤트는 anthropics/claude-code-action으로 넘기는 게 맞습니다. 로컬 VS Code 세션이 할 일이 아닙니다.

8. 복붙 템플릿

새 작업을 시킬 때 이 골격만 채우면 됩니다. CLAUDE.md를 이미 세팅했다면 앞의 두 항목만 써도 충분합니다.

[목표]  ______가 ______인 상태로 만들어줘.

[완료]  다음이 모두 통과하면 완료야: ______, ______

[절차]  1) ______  2) ______  3) 검증이 실패하면 최대 3회까지 스스로 고쳐

[범위]  ______ 안에서는 알아서 수정해. ______는 손대지 마.

[진행]  중간 확인 요청 없이 끝까지 진행해.
        단 ______는 실행 전에 멈추고 물어봐.
        판단이 갈리면 ______ 쪽으로 결정하고 가정은 마지막에 보고해.

[보고]  끝나면 변경 파일 / 세운 가정 / 남은 리스크만 알려줘.

9. VS Code 확장에서의 주의점

• 입력창의 자동 승인 토글이 체감상 가장 큰 차이를 만듭니다. 여기부터 켜보세요.
• 훅, 서브에이전트, 슬래시 커맨드, CLAUDE.md는 확장에서도 그대로 동작합니다. 설정 파일은 프로젝트의 .claude/ 아래에 두면 됩니다.
• claude -p 같은 비대화형 자동화는 터미널 CLI 쪽입니다. cron이나 git hook에 물릴 작업은 확장이 아니라 CLI로 실행하세요.

AI 코드 리뷰는 몇 번 돌려야 할까

https://edgelog.dev/ko/blog/how-many-ai-code-reviews/

AI 코드 리뷰는 몇 번 돌려야 할까? 약 400번의 LLM 호출로 직접 측정해봤습니다

AI로 코드를 작성하고 리뷰까지 맡기다 보면 생각보다 자주 이런 상황을 만납니다.

코드 작성 → 리뷰 → 수정 → 다시 리뷰 → 다시 수정 → 또 리뷰...

처음 리뷰에서 문제를 몇 개 찾아 고쳤는데, 다시 리뷰하면 새로운 문제가 나옵니다.
그걸 고치고 다시 돌리면 또 다른 지적이 나옵니다.

리뷰 → 수정 → 리뷰 → 수정이 끝나지 않습니다.

그러다 보면 애매해집니다.

대체 언제 끝내야 할까?

• 지적(이슈)가 0개가 될 때까지?
• 테스트가 모두 통과하면?
• 2~3번 정도 돌리면 충분한가?
• 계속 돌릴수록 실제로 코드가 좋아지는가?

특히 이 과정을 에이전트나 CI에 자동화하려고 하면 더 문제가 됩니다.

review → fix → review → fix

루프를 만드는 건 어렵지 않은데, 언제 멈춰야 하는지에 대한 근거가 없습니다.

저도 최대 3라운드까지 자동 반복하는 워크플로를 사용하고 있었는데, 어느 순간 궁금해졌습니다.

정말 리뷰와 수정을 반복할수록 코드가 좋아질까?

그래서 실제 C 펌웨어 코드와 별도의 벤치마크 과제를 대상으로 리뷰어와 수정자를 분리하고, 약 400회의 LLM 호출을 돌려 직접 측정해봤습니다.

결과는 생각했던 것과 조금 달랐습니다.

1. 리뷰만 반복하는 것은 효과가 있었습니다

같은 코드를 수정하지 않고 반복해서 리뷰하면 실제 결함 커버리지가 대략

34% → 61% → 76%

로 증가했습니다.

같은 코드, 같은 모델이어도 매번 보는 문제가 달랐습니다.
어떤 실제 결함은 10번 중 한 번만 발견되기도 했습니다.

즉, AI 리뷰 한 번만으로 충분하다고 보기는 어려웠습니다.

2. 하지만 리뷰와 수정을 반복하는 것은 다른 문제였습니다

리뷰 → 수정 → 리뷰 → 수정

루프를 반복했을 때 테스트/계약 준수율은 그대로인데, 코드는 조건에 따라

+24% ~ +152%

까지 커졌습니다.

즉,

리뷰를 반복하는 것과 리뷰-수정 루프를 반복하는 것은 같은 일이 아니었습니다.

발견의 이득은 리뷰에서 나오지만, 수정할 때마다 새로운 변경과 새로운 위험도 함께 생깁니다.

3. 여러 번 지적됐다고 더 정확한 것도 아니었습니다

처음에는 여러 리뷰에서 반복적으로 나온 finding일수록 진짜일 가능성이 높을 거라고 생각했습니다.

그런데 대상 파일 하나만 보여준 조건에서는 반대였습니다.

오탐이 실제 결함보다 더 자주 반복적으로 보고됐습니다.

여러 AI가 독립적으로 리뷰하더라도 모두 같은 context를 잃고 있다면,
같은 잘못된 가정에서 출발해서 같은 방향으로 틀릴 수 있었습니다.

4. Repository context가 오탐 제거에 상당히 중요했습니다

대상 파일 하나만 보여준 조건에서는 고유 지적의 29%가 오탐이었습니다.

반면 호출자, 헤더, 초기화 경로 등 repository를 읽을 수 있게 하자 동일한 오탐들이 사라졌습니다.

코드 리뷰에서는 모델 자체뿐 아니라,

모델에게 어디까지 볼 수 있게 할 것인가

도 상당히 중요한 변수였습니다.

5. AI가 조용해졌다고 리뷰가 끝난 것도 아니었습니다

몇 라운드 이후 "지적 없음"이 나오더라도 같은 코드를 다른 관점으로 구조화해서 리뷰하면 새로운 failure mode가 다시 나왔습니다.

그래서 단순히

finding == 0

을 종료 조건으로 쓰기도 어려웠습니다.

6. 테스트 통과만으로도 종료를 판단하기 어려웠습니다

여러 조건에서 테스트 결과는 계속 동일했습니다.

그런데 코드 크기와 복잡도는 크게 달라졌습니다.

즉,

테스트를 계속 통과한다 = 코드가 계속 좋아지고 있다

라고 보기는 어려웠습니다.

그래서 현재 제가 쓰고 있는 가장 단순한 원칙은:

리뷰는 여러 번, 수정은 한 번.

여러 독립 리뷰에서 finding을 먼저 모으고, 사람이 한 번 선별한 다음 수정자에게 한꺼번에 넘깁니다.

그리고 수정 폭이 충분히 크다면 다음 리뷰는 단순한 '재리뷰'가 아니라,

새로 생긴 코드에 대한 첫 리뷰

라고 보는 편이 더 맞다고 생각합니다.

다만 아직 일반화하기에는 작은 실험입니다.

다른 조건이나 모델에서도 다시 확인된 결과는 일부뿐이고, Python 벤치마크 과제도 두 개뿐입니다. 언어나 코드베이스가 달라졌을 때 결과가 달라진 경우도 있었습니다.

그래서 이 결과를 모델 성능 비교보다는,

“AI 코딩 에이전트의 review/fix loop를 어떻게 설계하고, 어디서 멈출 것인가?”

에 대한 실험으로 보는 것이 맞습니다.

실험 과정에서 초기 결론이 여러 번 뒤집혔고, 그 과정과 원 데이터, 벤치마크 코드, 현재의 실무 처방, 한계까지 모두 공개했습니다.

관련 자료

• 연구 전문 — EdgeLog
  https://edgelog.dev/ko/blog/how-many-ai-code-reviews/

• GitHub 연구 원문
  https://github.com/Ecro/harness-bench/…

• 측정 결과를 기반으로 정리한 실전 처방
  https://github.com/Ecro/harness-bench/…

• 자신의 AI 코딩 파이프라인에 적용하기 위한 가이드
  https://github.com/Ecro/harness-bench/…

• 이 실험으로 주장할 수 없는 것 / 연구의 한계
  https://github.com/Ecro/harness-bench/blob/main/docs/LIMITS.ko.md

https://www.ddaily.co.kr/page/view/2026081208245230655

최근 AI 솔루션을 공급하는 한 기업 대표를 만나 AI 생산성 향상의 불편한 이면을 들었다. 이 기업은 자체 솔루션을 공급하면서 고객사 요구에 맞춘 시스템 구축 사업도 병행하고 있다.

"AI 코딩으로 개발 생산성이 높아졌지만 발주사로부터 그만큼 사업비를 낮추라는 요구를 받고 있다"는 얘기였다.

일반적으로 국내 시스템 구축 현장에서는 투입할 개발자 수와 기간이 견적을 산정하고 협의하는 기준으로 쓰이곤 한다.

이때 흔히 사용하는 단위가 ‘맨먼스(M/M·Man-Months)’다. 개발자 한 명을 한 달간 전일제로 투입하면 1인월, 개발자 10명을 6개월간 전일제로 투입하면 60인월로 계산한다.

실제로 AI가 코드 작성과 오류 점검을 도우면서 예전보다 개발 시간이 줄었다. 같은 업무를 더 적은 인원과 짧은 기간에 끝낼 수 있게 된 것이다.

발주사 입장에서는 자연스럽게 “그렇다면 투입 인력과 사업비도 줄어야 하지 않느냐”는 계산이 나온다.

그런데 문제는 AI로 줄어든 공수는 사업비를 낮추는 근거가 되지만 수행사가 AI를 도입하고 운영하느라 쓴 비용은 계산에 잘 반영되지 않는다는 점이다.

발주사는 AI로 줄어든 인력과 시간부터 따지지만 정작 AI 사용료와 검증 비용, 개발 환경을 갖추는 데 들어간 투자는 별도로 인정하지 않는다. 결국 "AI 때문에 인건비가 줄었으니 사업비를 깍자"는 단순 무지한 논리가 작동하는 것이다.

그러나 AI가 공짜로 일하는 것은 아니다.

먼저, 생성형 AI 모델을 호출하면 사용량에 따라 토큰 비용이 발생한다. AI가 작성한 코드가 고객사 시스템에서 제대로 작동하는지, 보안과 품질에 문제가 없는지도 사람이 다시 검증해야 한다. AI를 실제 개발 현장에 적용할 환경을 갖추고 시행착오를 거치는 데도 시간과 비용이 든다.

계약을 따내기 전부터 비용이 발생하기도 한다.

발주사가 기술력을 확인하기 위해 무상 개념증명(PoC)을 요구하는 일은 새삼스럽지 않다. 다만 예전에는 인력 투입이 주된 부담이었다면 이제는 여기에 AI 사용 비용까지 더해진다. 수주 여부가 정해지지 않은 상태에서 인력과 AI 비용을 먼저 부담해야 하는 셈이다.

AI 덕분에 줄어든 시간은 바로 보이지만 그 시간을 줄이기 위해 들인 비용은 가격표에 잘 잡히지 않는다. 생산성을 높였다는 이유로 사업비가 낮아진다면 수행사가 AI를 적극적으로 도입할 유인은 약해진다.

AI를 활용한 개발까지 사람의 투입 시간만으로 계산하는 방식에는 한계가 있다. 줄어든 공수뿐 아니라 AI를 적용하고 검증하는 데 든 비용과 개발 기간을 단축해 만들어낸 가치까지 함께 보는 계산법이 필요한 시점이다.

아마존이 인공지능(AI) 모델 학습용 데이터를 확보하기 위해 희귀·절판 도서를 대량으로 사들인 뒤 제본을 잘라내어 스캔하고 원본을 폐기하고 있는 것으로 드러나 논란이 일고 있습니다

배경과 목적: AI 생성물이 섞이지 않은 2022년 이전의 순수 '인간 저작물'과 양질의 텍스트 데이터가 귀해졌기 때문입니다. 인터넷에 AI 생성 콘텐츠가 범람하면서 모델 성능 저하(모델 붕괴)를 막기 위한 조치입니다.

방식: 404미디어 등의 조사에 따르면, 중고 및 희귀 서적을 대량 매입한 후 책등을 절단해 페이지 단위로 스캔하고 실물 책은 폐기하는 방식으로 진행됩니다. 추적 장치를 통해 최종 목적지가 미국 네바다주 라스베이거스에 있는 아마존 시설(VGT3)인 것으로 확인되었습니다.

파장과 논란: 앤스로픽 등 다른 빅테크 기업들도 유사한 방식을 써온 것으로 알려졌습니다. 합법적으로 구매한 책의 스캔 및 폐기 자체는 '공정 이용'으로 인정받는 추세이나, 자본력을 앞세워 희귀 도서 원본을 없앰으로써 후발 기업의 데이터 접근을 차단하고 인류의 지식 유산을 독점·훼손한다는 비판이 제기되고 있습니다. 미국 소비자연맹 등 시민단체들은 이를 불공정 경쟁 및 반독점 이슈로 규정하고 연방거래위원회(FTC)에 조사를 촉구했습니다.

https://www.choicestock.co.kr/stock/news_view/176396?bu=

「AI 시대의 필수 지식 MCP 이 영상 하나로 끝내세요!」 — 조코딩 JoCoding

https://youtu.be/46HxP7kO9oY?si=9S_C51BLPhje4J6M 이 영상의 자막과 내용, 요약 정리

MCP는 AI 모델과 외부 도구를 잇는 USB-C 같은 표준 규격이다. 이 영상은 "왜 필요한지 → 어떻게 쓰는지 → 직접 만드는 법 → 회사에 도입하는 법"까지 한 번에 훑는다.

1부. MCP가 왜 필요한가

• 정의: Model Context Protocol. Anthropic이 2024년 11월에 내놓은 표준으로, AI 모델이 외부 도구·데이터에 접근하는 방식을 통일한 규격.
• 문제: LLM은 다음 단어를 예측할 뿐이라 실시간 정보를 모른다. 도구 없이 "오늘 날씨 어때?"를 물으면 그럴듯한 거짓말(할루시네이션)을 만들어낸다.
• 해결: 날씨 API 같은 도구를 붙여주면 AI가 알아서 그 도구를 호출해 실제 데이터로 답한다.
• 표준화의 의미: Gmail, 캘린더, Slack마다 제각각 연동을 만들면 개발 부담이 폭증한다. MCP는 이 연결 방식을 하나로 통일해 그 부담을 없앤다. → USB-C 비유.

2부. 실제 사용 — 이미 만들어진 MCP 쓰기

• Blender 사례: 3D 툴을 전혀 못 다루는 사람도 Claude Desktop에 Blender MCP를 붙이면 AI가 프로그램을 직접 조작해 3D 오브젝트를 만들어준다.
• Smithery: MCP 모음 플랫폼. 영상 시점 기준 6,341개 이상의 MCP가 등록돼 있어 검색해서 바로 연결하면 된다(코딩 불필요).
• Context7 MCP: Next.js 등 개발 공식 문서를 AI가 참조하게 해주는 도구. 코딩할 때 최신 문서 기준으로 답하게 만든다.
• Claude Desktop 연결법: 데스크톱 앱 설치 → 설정 → 개발자(Developer) → MCP 서버 → JSON으로 설정 추가.

3부. 직접 만들기

• FastMCP(파이썬 라이브러리) 사용. 함수 위에 @mcp.tool 데코레이터만 붙이면 끝날 만큼 간단하다.
• 예제: 두 수를 더하는 함수 하나로 MCP를 만들어 시연.
• 로컬 vs 원격
  • 로컬: 내 PC에서 STDIO(표준 입출력) 방식으로 구동
  • 원격: 클라우드에 배포해 HTTP 방식으로 연결 → 내 컴퓨터를 켜두지 않아도 됨
• VSCode 연동: Ctrl+Shift+P로 MCP 연결, 원격 서버는 HTTP 방식 사용.
• 배포: 파이썬 파일을 Git·클라우드 서비스에 올리면 URL이 생기고, 그 URL로 어디서든 접근 가능.

4부. 회사에 도입하기

• 현실적 문제: VSCode나 Cursor로 MCP를 붙이는 방식은 비개발자 동료에게 배포하기가 사실상 불가능하다.
• Porter AI(소개된 솔루션): 웹 기반으로 기술 지식 없이 MCP를 붙여 쓰게 해주는 플랫폼.
  • 모델 선택 자유: GPT-5, OpenRouter 경유 커스텀 모델 등 외부 모델 추가 가능
  • 사내 데이터 연결: 내부 DB(회원 정보)나 Notion 연동 → 예) "출장 시 식대 얼마인가요?" 질문에 Notion MCP가 사내 규정을 찾아 답변
  • 팀 초대: '팀 초대' 버튼 한 번이면 비개발자도 MCP 설정 없이 사용
  • 사용량 모니터링: 팀원별 AI 사용 통계·모델 선택·소비 패턴을 대시보드로 확인
  • Slack 연동: 채널에서 봇을 태그해 "지난달 신규 가입자 몇 명?"이라고 물으면 DB MCP를 호출해 실제 수치를 가져옴

핵심 흐름은 "할루시네이션 → 도구 연결로 해결 → 그 연결을 표준화한 게 MCP → 쓰기·만들기·팀 배포" 입니다.