AI/Technical

vibe coding과 ADHD: 생산성 올리고 사고 줄이는 운영법

Royzero 2026. 2. 4. 18:27
반응형

TL;DR

  • vibe coding은 “AI에게 원하는 걸 말하고, 코드 내부를 깊게 이해하지 않은 채 결과물을 만드는 방식”에 가깝습니다.
  • ADHD는 주의·조직화·충동성 조절 같은 실행기능(Executive function) 영역에서 업무 수행 난이도를 올릴 수 있습니다.
  • 두 개가 만나면 “빠르게 만들고(생산성) 빠르게 망가뜨릴(사고)” 가능성도 같이 커집니다. 연구에선 AI 코딩 보조가 보안 취약 코드와 과신을 늘릴 수 있었습니다.
  • 해결책은 ‘의지’가 아니라 운영 설계입니다: 프로토타입-프로덕션 분리, 작은 diff, 자동 검증 게이트, 사람 책임 명시로 굴리면 됩니다.

본문

TOC

  • 사전 요구사항
  • 단계별 절차
  • 검증 방법(관찰 포인트/로그/명령)
  • 트러블슈팅(증상→원인→해결)
  • 운영 팁
  • FAQ

사전 요구사항

1) 개념 정리(정의/범위/오해)

vibe coding 1문장 정의: AI에게 원하는 결과를 말로 지시하고, 생성된 코드를 “검증/이해”보다 “결과” 중심으로 쌓아가는 개발 방식입니다.

  • 포함 범위: 프로토타입/해커톤/실험처럼 “망가져도 되는” 환경에서 빠른 반복.
  • 제외 범위(무엇은 아닌가): LLM이 쓴 코드를 리뷰·테스트·이해한 뒤 책임지고 반영하는 “AI 보조 개발”은 엄밀히 vibe coding과 구분하자는 주장이 있습니다.
  • 대표 오해 1개: “AI 쓰면 무조건 빨라진다.” → 실제 환경/숙련도/과업에 따라 반대로 느려질 수도 있다는 RCT 결과가 있습니다.

ADHD 1문장 정의: ADHD는 주의력, 과잉행동, 충동성의 지속적 패턴이 일/학업/생활 기능에 영향을 주는 신경발달 관련 장애입니다.

  • 포함/제외: “가끔 산만함”이 아니라 빈도·지속성·상황 전반에서 기능 저하가 있어야 합니다.
  • 대표 오해 1개: “성인이면 사라진다.” → 증상은 성인기까지 이어질 수 있고, 요구 수준이 올라갈수록 더 두드러질 수 있습니다.

의료 조언이 아니라 업무 운영 관점의 일반 정보입니다. 진단/치료는 의료 전문가와 상의하셔야 합니다.

Why it matters: 정의를 헷갈리면 운영도 헷갈립니다. “AI 보조 개발”과 “vibe coding”을 구분해야 사고 방지 설계를 제대로 할 수 있습니다.

2) 왜 ‘vibe coding + ADHD’ 조합이 위험/기회가 동시에 커지나

  • vibe coding은 즉각 피드백과 낮은 진입장벽으로 반복을 폭발적으로 늘립니다. (용어 자체가 2025년 초에 대중화되며 ‘코드 이해 없이 AI로 만든다’는 뉘앙스를 포함합니다.)
  • ADHD는 “지금 당장 보이는 보상(새 기능/화면)”에 강하게 끌리고, 조직화/계획/점검 같은 실행기능 부담이 커질 수 있습니다. CBT-ADHD가 시간관리·조직화·계획을 직접 다루는 이유가 여기입니다.
  • 결과적으로 “만드는 속도”는 올라가는데, “검증·정리·운영”이 무너지기 쉬운 구조가 됩니다. 그리고 AI 코딩 보조는 보안 측면에서 취약 코드 생성과 사용자 과신을 증가시킨 연구가 있습니다.

Why it matters: 이건 의지 문제가 아니라 구조 문제입니다. 구조를 고치면 생산성은 살리고 사고는 줄일 수 있습니다.

단계별 절차 (운영 플레이북)

아래는 “생산성 올리고 사고 줄이는” 목적에 맞춘 최소 운영 단위입니다.

Step 0. ‘2-레인(Prototype vs Production)’을 강제로 분리

구분 Prototype 레인 Production 레인
목적 속도/탐색 안정성/유지보수
허용 vibe coding OK vibe coding 금지(=반드시 이해/검증)
산출물 데모/PoC 배포 가능한 변경
게이트 최소 테스트 CI + 보안 스캔 + 리뷰 + 롤백 계획
  • “재미로 만든 프로토타입이 압력에 떠밀려 운영으로 들어가는 순간”이 가장 위험하다는 경고가 반복됩니다.

Why it matters: 분리가 없으면 결국 “실험 코드가 운영을 먹습니다.” 분리만 해도 사고 확률이 크게 떨어집니다.

Step 1. 프롬프트를 ‘요구사항 계약서’로 바꾸기 (Prompt Contract)

아래 템플릿을 그대로 쓰시면 됩니다.

[목표] 무엇을 만들 것인가(한 문장)
[성공조건] 동작/성능/정확성/호환성 기준(측정 가능하게)
[제약] 보안(입력검증/인증), 비용, 레이턴시, 의존성 금지 목록
[비범위] 이번 변경에서 하지 않을 것(스코프 고정)
[테스트] 반드시 추가/수정할 테스트(케이스 3개 이상)
[출력] (1) 변경 요약 (2) 파일별 diff (3) 테스트 명령 (4) 롤백 방법
  • AI 코드 생성은 “요구사항을 말하지 않으면 요구사항을 가정”합니다. 보안 요구사항을 명시하지 않으면 위험한 기본값으로 갈 수 있다는 연구/재현 결과가 있습니다.

Why it matters: 프롬프트 계약서는 ADHD의 약점으로 자주 거론되는 “스코프 이탈/기억 누락”을 구조적으로 막아줍니다.

Step 2. “큰 변경 1번” 대신 “작은 변경 5번” (Diff 상한)

  • PR 하나의 상한을 정합니다(예: 200라인/파일 10개/30분 리뷰).
  • AI가 한 번에 크게 바꾸면 사람은 검증을 포기합니다. 검증 포기가 사고입니다.

Why it matters: 작은 diff는 집중·검증 비용을 낮춰서 “완료(merge)”까지 끌고 갑니다.

Step 3. 자동 게이트(로컬 → CI)로 사람 실수를 대체

3-1) pre-commit으로 로컬에서 1차 차단

# .pre-commit-config.yaml (예시)
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v5.0.0
    hooks:
      - id: end-of-file-fixer
      - id: trailing-whitespace
      - id: check-yaml
  - repo: https://github.com/psf/black
    rev: 24.10.0
    hooks:
      - id: black
  - repo: https://github.com/PyCQA/flake8
    rev: 7.1.1
    hooks:
      - id: flake8

3-2) GitHub Actions로 테스트+보안 스캔 강제

# .github/workflows/ci.yml (예시)
name: ci
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest -q
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install bandit
      - run: bandit -r . -q
  • “AI가 만든 코드가 취약할 수 있다”는 건 여러 연구에서 반복됩니다. 그러면 답은 단순합니다: 사람의 주의력 대신 자동화된 게이트로 막습니다.

Why it matters: ADHD 여부와 상관없이, 운영에서 사람의 주의력은 신뢰할 수 있는 안전장치가 아닙니다. 자동 게이트가 표준입니다.

Step 4. 리뷰는 “AI 리뷰 + 사람 책임”으로 고정

  • AI로 1차 리뷰(스타일/테스트 누락/잠재 버그)를 돌리되, 최종 승인 책임은 사람에게 둡니다.
  • vibe coding은 “코드 이해 없이 결과만”을 뜻하므로, 프로덕션에서는 책임성(understand & own)이 필요하다는 주장과 일치합니다.

Why it matters: “누가 책임지나”가 불명확하면 결국 아무도 책임지지 않습니다.

검증 방법 (관찰 포인트/로그/명령)

1) 최소 검증 체크(로컬)

pytest -q
python -m compileall .
bandit -r . -q

2) 배포 전 관찰 포인트

  • 변경 영향도: API/DB 스키마/권한/IAM 변경 유무
  • 롤백 가능성: feature flag, migration rollback, canary 범위
  • 보안 요구사항 충족: 입력 검증/인증/비밀키 하드코딩 여부(특히 AI가 자주 실수하는 지점)

NIST SSDF는 취약점 위험을 줄이기 위해 SDLC에 보안 활동을 통합하라고 권고합니다(요구사항→설계→구현→검증 전 단계).

3) 팀 대시보드로 보는 운영 지표(권장)

  • Change failure rate, rollback 횟수, hotfix 비율
  • PR당 평균 라인수/리뷰 시간(“큰 diff” 방지용)

Why it matters: vibe coding은 속도가 빨라져 “측정 없이 낙관”하기 쉽습니다. 지표가 없으면 사고가 나도 원인을 못 찾습니다.

트러블슈팅 (증상→원인→해결) 3가지 이상

1) 증상: PR이 계속 커지고, 리뷰가 멈춥니다

  • 원인: AI가 한 번에 넓게 수정 + 사람이 검증 포기
  • 해결: PR 상한(라인/파일/시간) 강제 + “Step 2 작은 변경”으로 분할

2) 증상: 기능은 되는데 보안 스캐너가 계속 터집니다

  • 원인: AI가 “흔한 패턴”을 우선 추천해 취약 코드가 섞임(연구/재현에서 관찰)
  • 해결: Prompt Contract에 보안 제약/금지 API를 명시 + CI에서 보안 스캔 필수 + 실패 시 merge 차단

3) 증상: 생산성이 올라간 줄 알았는데, 실제론 더 늦습니다

  • 원인: AI 출력 검증/수정 비용이 과소평가됨(숙련 OSS 개발자 대상 RCT에서 ‘AI 사용 시 19% 더 오래’ 결과)
  • 해결: “AI가 잘하는 구간(보일러플레이트/초안)”과 “사람이 해야 하는 구간(요구사항/경계조건/리스크)”을 분리해서 사용 범위를 좁히기

Why it matters: 트러블슈팅을 규격화하면 ADHD 특성에서 흔한 “그때그때 땜질”을 줄이고 재발을 막습니다.

운영 팁 (생산성↑, 사고↓)

1) ADHD 친화적 운영은 ‘실행기능 외주화’입니다

CBT-ADHD가 시간관리·조직화·계획을 기술로 훈련하는 것처럼, 개발 운영도 동일하게 “환경을 설계”합니다.

  • 작업을 마이크로 스텝으로 쪼개고(30분 단위)
  • 기억을 체크리스트/템플릿/자동화로 빼고
  • 스코프를 계약서(Prompt Contract)로 잠급니다

Why it matters: “집중하겠다”가 아니라 “집중 없이도 굴러가게” 만드는 게 운영입니다.

2) 배포 전 체크리스트

  • Prototype 레인 코드가 Production에 섞이지 않았나
  • 테스트 추가/수정이 있는가(최소 3케이스)
  • 입력 검증/인증/권한 변경이 안전한가
  • 롤백/feature flag/canary 계획이 있는가
  • CI(테스트+보안 스캔) 통과했나

3) 운영 중 체크리스트

  • 실패 알림이 “행동 가능한 형태”인가(누가/무엇을/어떻게)
  • hotfix 비율이 증가했나(품질 붕괴 신호)
  • PR 크기 상한이 지켜지나
  • 주 1회 “AI로 만든 변경” 샘플링 보안 리뷰를 하고 있나

Why it matters: 체크리스트는 ADHD 여부와 무관하게 “사고를 통계적으로 줄이는 장치”입니다.

FAQ (5개 이상)

  1. vibe coding을 완전히 금지해야 하나요?
    아니요. 프로토타입 레인에서는 효과적일 수 있습니다. 다만 프로덕션은 책임성(이해·검증)이 필요합니다.

  2. ADHD면 AI 코딩을 쓰면 더 위험한가요?
    ADHD 자체가 위험을 “결정”하진 않습니다. 다만 실행기능 부담이 큰 환경에서 vibe coding이 검증을 밀어낼 수 있어, 운영 설계가 더 중요해집니다.

  3. AI가 만든 코드가 진짜로 덜 안전한가요?
    사용자 연구에서 AI 보조를 쓴 그룹이 더 취약한 코드를 작성했고, 스스로는 더 안전하다고 믿는 경향이 관찰됐습니다.

  4. 그럼 답은 사람 리뷰만 늘리면 되나요?
    아니요. 사람 리뷰는 한계가 있습니다. 자동 게이트(테스트/보안 스캔/정적 분석)로 실패를 강제하는 게 표준입니다.

  5. “AI 쓰면 무조건 빨라진다”는 믿음은 틀렸나요?
    상황에 따라 다릅니다. 숙련 OSS 개발자 환경에선 오히려 느려진 RCT 결과가 있으니, 조직은 측정 기반으로 도입 범위를 정해야 합니다.

결론 (요약 정리)

  • vibe coding은 프로토타입에서 강력하지만, 프로덕션에서는 이해·검증·책임이 전제입니다.
  • ADHD는 실행기능 부담을 키울 수 있어, 체크리스트·템플릿·자동화가 특히 효과적입니다.
  • 운영법의 핵심은 4개입니다: 2-레인 분리 → Prompt Contract → 작은 diff → 자동 게이트/사람 책임.

Summary

  • 프로토타입과 프로덕션을 물리적으로 분리하십시오.
  • 프롬프트를 요구사항 계약서로 만들고, diff를 작게 유지하십시오.
  • 테스트·보안 스캔을 CI 게이트로 강제하십시오.
  • 최종 책임은 사람에게 고정하십시오.

References

반응형
저작자표시 비영리 변경금지 (새창열림)

'AI > Technical' 카테고리의 다른 글

vibe coding과 ADHD: 잘 맞는 지점과 위험 구간  (1) 2026.02.04
LLM data lineage 설계: 학습셋 manifest와 재현성  (12) 2026.02.01
AI training data governance checklist: 옵트아웃·목적 제한·보관 기간  (7) 2026.02.01
임베딩(Embedding)이란 무엇인가: 머신러닝을 위한 기초 개념  (5) 2026.01.19
NVIDIA 그래픽 카드 모델(대표)별 Ollama 추천 모델 표  (13) 2026.01.09

'AI/Technical'의 다른글

  • 현재글vibe coding과 ADHD: 생산성 올리고 사고 줄이는 운영법

관련글

티스토리툴바