vibe coding과 ADHD: 잘 맞는 지점과 위험 구간

TL;DR

• vibe coding은 자연어로 요구사항을 말하면 LLM이 코드를 만들고, 사용자는 결과를 실행/수정 지시로 반복하는 방식입니다. (X (formerly Twitter))
• ADHD는 부주의/과잉행동/충동성의 지속 패턴이 핵심이며, 성인에서도 조직화·계획·시간관리(집행 기능) 어려움이 흔히 문제로 나타납니다. (nimh.nih.gov)
• 둘의 “연관성”은 의학적 인과가 아니라, 업무 방식(피드백 루프·검증 부담·주의 전환)이 ADHD 특성과 상호작용할 수 있다는 수준에서 이해하는 게 정확합니다.
• AI 코딩 보조에 과의존하면 보안적으로 더 취약한 코드가 나올 가능성이 실험 연구로 보고되어 있어, vibe coding은 품질 게이트가 없으면 특히 위험합니다. (arXiv)

---

본문

TOC

• vibe coding(바이브코딩) 정의
• ADHD 정의와 “집행 기능” 포인트
• 왜 둘이 자주 엮이는가: 작업 설계 관점
• 잘 맞는 시나리오 / 피해야 할 시나리오
• 비교표: vibe coding vs AI-assisted engineering
• 실무 가드레일(체크리스트/파이프라인 예시)
• 자주 하는 실수 Top 3
• 트러블슈팅
• FAQ

---

vibe coding(바이브코딩) 정의

1문장 정의

vibe coding은 “코드를 직접 읽고 쓰는 비중을 줄이고, 자연어 지시로 AI가 생성/수정한 코드를 실행 결과로만 검증하며 반복 개발하는 방식”입니다. (X (formerly Twitter))

포함/제외 범위

• 포함: 자연어 프롬프트 기반 생성/수정, “Accept All”에 가까운 빠른 반복, 실행 결과 중심 피드백 (X (formerly Twitter))
• 제외: AI가 코드를 써도 사람이 설계/리뷰/테스트로 이해·검증하는 일반적인 AI-assisted 개발(이건 “vibe”라기보다 “엔지니어링”) (Simon Willison’s Weblog)

대표 오해 1개

• 오해: “vibe coding = AI 코딩 자동화면 다 해당”
• 사실: 핵심 차이는 검증(읽기/리뷰/테스트) 책임을 사람이 얼마나 가져가느냐입니다. (Simon Willison’s Weblog)

Why it matters:
vibe coding을 “도구”가 아니라 “개발 운영 방식”으로 봐야, 품질/보안/유지보수 리스크를 설계로 통제할 수 있습니다. (NIST 기술 시리즈 간행물)

---

ADHD 정의와 “집행 기능” 포인트

1문장 정의

ADHD는 부주의(inattention), 과잉행동(hyperactivity), 충동성(impulsivity) 중 하나 이상이 지속되어 일상 기능에 영향을 주는 신경발달장애입니다. (nimh.nih.gov)

포함/제외 범위(무엇은 아닌가)

• “가끔 집중이 안 됨”은 누구에게나 있을 수 있고, ADHD 진단은 증상의 지속성과 여러 삶의 영역에서의 기능 저하를 포함한 전문 평가가 필요합니다. (질병통제예방센터)

대표 오해 1개

• 오해: “ADHD = 집중을 못 하는 것만”
• 사실: 성인에서는 조직화·계획·시간관리·작업 실행(집행 기능) 이슈가 핵심 문제로 나타나는 경우가 많고, 치료/중재도 이런 기술을 강화하는 방향을 포함합니다. (AAFP)

Why it matters:
vibe coding은 “빠른 생성” 대신 검증 부담(리뷰/테스트/보안 점검)이 뒤로 밀릴 수 있는데, 집행 기능이 약한 환경에서는 이 부담이 더 크게 느껴질 수 있습니다. (AAFP)

---

왜 둘이 자주 엮이는가: 작업 설계 관점

의학적으로 “vibe coding ↔ ADHD”의 직접 상관을 입증한 표준 가이드라인은 확인되지 않았고, 현재 연구는 주로 학습/인지적 오프로딩(cognitive offloading), 개발 흐름(flow), 품질·보안 같은 축으로 진행됩니다. (arXiv)

다만, 업무 방식 특성 때문에 ADHD 특성과 “맞물릴 여지”는 충분합니다.

맞물리는 지점 3가지

1. 즉각적인 피드백 루프: 프롬프트 → 코드 생성 → 실행/에러 → 재지시의 루프가 짧습니다. (karpathy)
2. 인지적 오프로딩: 구문·보일러플레이트를 AI가 대신 처리해, 사용자는 목표/행동 단위로 지시합니다. (arXiv)
3. 검증 부담의 이동: “쓰는 일”이 줄어든 만큼 “검토·테스트·보안 확인”의 비중이 상대적으로 커집니다. (NIST 기술 시리즈 간행물)

Why it matters:
ADHD 여부와 무관하게, vibe coding의 핵심 리스크는 “생성 속도”가 아니라 “검증의 누락/지연”입니다. 프로세스 설계로 이 부분을 막으면 생산성만 남길 수 있습니다. (NIST 기술 시리즈 간행물)

---

잘 맞는 시나리오 / 피해야 할 시나리오

잘 맞는 시나리오

• 프로토타이핑/개인 자동화/일회성 도구: “버려도 되는 코드”에서 강합니다. (karpathy)
• 명확한 성공 조건이 있는 작업(예: 데이터 파이프라인 변환 스크립트, 내부 리포트 생성): 테스트로 정답을 빨리 판별 가능
• 시간이 아니라 실행이 병목인 작업(보일러플레이트/CRUD/UI 뼈대)

피해야 할 시나리오(또는 강한 통제가 필요한 시나리오)

• 프로덕션/규정 준수/고가용성: 유지보수·감사·보안 요구가 있는 코드베이스
• 보안 민감 코드(인증/인가, 암호화, 결제, 비밀/키 처리): AI 보조 사용 시 보안이 약해질 수 있다는 연구 결과가 존재합니다. (arXiv)
• 리뷰 없이 “Accept All”이 습관화된 팀: 누가 어떤 의사결정을 했는지 남지 않습니다. (karpathy)

Why it matters:
vibe coding을 “어디에 쓰면 이득이고, 어디에 쓰면 사고가 나는지”로 나누면, 개인 특성(ADHD 포함)과 무관하게 팀 품질이 안정됩니다. (NIST 기술 시리즈 간행물)

---

비교표: vibe coding vs AI-assisted engineering

항목	vibe coding	AI-assisted engineering(권장)
사람 역할	목표/수정 지시, 실행 결과로 판단	설계/리뷰/테스트로 이해·검증
코드 읽기/리뷰	최소화되기 쉬움 (karpathy)	필수(코드리뷰/테스트) (NIST 기술 시리즈 간행물)
속도	초기 속도 매우 빠름	안정적으로 빠름
리스크	품질/보안/유지보수 폭탄	리스크 관리 가능
ADHD 관점(실무적)	“즉시 보상”은 좋지만 검증 루틴이 무너지면 손해	외부 구조(체크리스트/게이트)가 도움이 됨 (AAFP)

Why it matters:
ADHD든 아니든 “AI가 코드를 쓰는 시대”의 승패는 검증 자동화와 운영 규칙이 가릅니다. (NIST 기술 시리즈 간행물)

---

실무 가드레일: ADHD 친화적으로 “구조를 밖에 두기”

아래는 의료 조언이 아니라 개발 운영 팁입니다. ADHD가 의심되거나 진단이 필요하면 의료진 상담이 우선입니다. (질병통제예방센터)

원칙 5가지

1. AI 생성 코드는 기본적으로 untrusted로 취급
2. “생성”과 “병합” 사이에 품질 게이트(테스트/리뷰/보안스캔)를 강제(사람 의지에 맡기지 않기) (NIST 기술 시리즈 간행물)
3. 작업을 “프롬프트 단위”가 아니라 PR 단위로 쪼개기(작게 병합)
4. Definition of Done을 문장으로 고정(프롬프트보다 강함)
5. 회고는 “집중력”이 아니라 프로세스 결함을 고치기

배포 전 체크리스트

• PR은 300~500라인 이상 커지지 않게 쪼갰다
• 단위 테스트/통합 테스트가 추가되거나 갱신됐다
• 인증/인가/입력검증/비밀키 처리 코드는 사람이 직접 리뷰했다
• 의존성 추가 시 라이선스/취약점 스캔을 통과했다
• “왜 이 설계인가”가 PR 설명에 남아 있다(미래의 나를 위해)

운영 중 체크리스트

• 보안 스캔/시크릿 스캔이 CI에서 자동 실행된다 (NIST 기술 시리즈 간행물)
• 에러/로그/성능 지표를 먼저 보고, 프롬프트로 뛰어들지 않는다
• AI가 만든 대규모 변경은 “리팩토링 PR”로 분리한다
• 2주~4주마다 AI 사용 규칙(금지 구역/승인 절차)을 업데이트한다

예시: GitHub Actions로 “의지 대신 자동화”

name: ci
on: [pull_request]
jobs:
  test-and-scan:
    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
      # 예: 시크릿 스캔 / SAST / 의존성 취약점 스캔 도구를 여기에 연결
      # - run: <secret-scan-tool>
      # - run: <sast-tool>
      # - run: <dependency-scan-tool>

Why it matters:
ADHD 특성에서 자주 언급되는 “루틴/구조의 외부화(체크리스트·알림·단계화)”는, 소프트웨어 개발에선 CI/CD 게이트로 구현하는 게 가장 확실합니다. (AAFP)

---

자주 하는 실수 Top 3

1. 에러 로그를 그대로 붙여넣고 무한 루프: 원인 가설 없이 “다시 해줘”만 반복
2. 보안/인증 코드를 vibe로 처리: 연구상 AI 보조 사용 그룹이 더 insecure한 해법을 낼 수 있었습니다. (arXiv)
3. 코드가 커져도 이해를 미룸: 나중에 “디버깅 비용”으로 이자 폭탄

Why it matters:
실수는 개인 탓이 아니라 “검증 단계가 프로세스에 박혀 있지 않아서” 생깁니다. (NIST 기술 시리즈 간행물)

---

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

1) 증상: 코드가 갑자기 10배로 커지고 손을 못 대겠다

• 원인: 큰 단위 프롬프트 + 자동 수용(accept all) + 설계 부재 (karpathy)
• 해결: PR을 기능 단위로 쪼개고, “삭제 가능한 프로토타입”과 “프로덕션”을 repo/브랜치로 분리

2) 증상: 테스트는 통과하는데 운영에서 계속 터진다

• 원인: 테스트 범위가 행동(behavior)을 커버 못함 + 관측성 부족
• 해결: 실패 케이스(입력검증/권한/경계값) 테스트 추가, 로그/메트릭 먼저 설계(NIST SSDF의 “Produce/Respond” 관점) (NIST 기술 시리즈 간행물)

3) 증상: 보안 취약점/시크릿 노출이 반복된다

• 원인: 사람 리뷰가 “선의”에 의존 + 자동 스캔 부재
• 해결: 시크릿 스캔/의존성 스캔/코드리뷰 규칙을 CI에서 강제 (NIST 기술 시리즈 간행물)

Why it matters:
vibe coding은 “개발자 생산성”보다 “개발 시스템 설계” 문제입니다. 시스템이 잡히면, 개인 특성 차이는 훨씬 덜 중요해집니다. (NIST 기술 시리즈 간행물)

---

FAQ

1. vibe coding이 ADHD에 “좋다/나쁘다”를 말할 수 있나?
   직접적으로 그렇게 단정할 근거는 부족합니다. 대신 검증 부담을 뒤로 미루는 방식은 누구에게나 위험합니다. (NIST 기술 시리즈 간행물)

2. ADHD가 있으면 오히려 개발을 잘할 수도 있나?
   개인차가 큽니다. “과집중(hyperfocus)” 관련 연구는 존재하지만, 범위와 해석에는 제한이 있습니다. (PMC)

3. 그럼 안전한 최소 규칙 1개만 꼽아달라
   “프로덕션 코드는 테스트+리뷰+스캔을 통과하지 않으면 병합 금지.” 이 한 줄이 제일 큽니다. (NIST 기술 시리즈 간행물)

4. AI 코딩 보조가 보안에 실제로 나쁜가?
   실험에서 AI 보조 접근권을 준 그룹이 더 insecure한 솔루션을 더 자주 작성한 결과가 보고되었습니다. (arXiv)

5. 진단/치료 정보도 다뤄줄 수 있나?
   가능하지만, 여기선 개발 방식에 집중했습니다. 진단은 의료진과 상담이 우선입니다. (질병통제예방센터)

Why it matters:
질문이 “내가 ADHD라서…”로 흐르면 해결이 늦어집니다. 개발에서는 대부분 프로세스 레버(게이트/자동화/분리)가 더 강력합니다. (NIST 기술 시리즈 간행물)

---

결론 (요약 정리)

• vibe coding은 빠르지만, 검증(리뷰·테스트·보안)을 밀어내면 부메랑이 됩니다. (karpathy)
• ADHD의 핵심은 부주의/충동성뿐 아니라 집행 기능(계획·조직화·시간관리) 이슈가 자주 포함된다는 점입니다. (Psychiatry)
• 둘의 “연관성”은 인과가 아니라 업무 방식의 상호작용으로 보셔야 정확합니다.
• 해결책은 의지보다 외부 구조(체크리스트 + CI 게이트)입니다. (NIST 기술 시리즈 간행물)

발행 직후 A/B 제목 후보 2개

• A안: vibe coding과 ADHD: 생산성 올리고 사고 줄이는 운영법
• B안: vibe coding(바이브코딩) 실무 가이드: ADHD 친화적 개발 프로세스

References

• (There's a new kind of coding I call "vibe coding"… | X (Andrej Karpathy), 2025-02-03)[https://x.com/karpathy/status/1886192184808149383]
• (Vibe coding MenuGen | karpathy.bearblog.dev, 2025-04-27)[https://karpathy.bearblog.dev/vibe-coding-menugen/]
• (Vibe coding (Slang & Trending) | Merriam-Webster, 2025-03-08)[https://www.merriam-webster.com/slang/vibe-coding]
• (Attention-Deficit/Hyperactivity Disorder (ADHD) | NIMH, page updated, access 2026-02-04)[https://www.nimh.nih.gov/health/topics/attention-deficit-hyperactivity-disorder-adhd]
• (ADHD in Adults | American Psychiatric Association, page updated, access 2026-02-04)[https://www.psychiatry.org/patients-families/adhd/adhd-in-adults]
• (Symptoms of ADHD | CDC, 2024-05-16)[https://www.cdc.gov/adhd/signs-symptoms/index.html]
• (Do Users Write More Insecure Code with AI Assistants? | arXiv, 2023-12-18)[https://arxiv.org/html/2211.03622v3]
• (Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218) | NIST, 2022-02)[https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf]
• (Adult ADHD: Treatment and Management | AAFP, 2026-01 (crawled))[https://www.aafp.org/family-physician/patient-care/prevention-wellness/emotional-wellbeing/adhd-toolkit/treatment-and-management.html]
• (Hyperfocus: the forgotten frontier of attention | PMC, 2019-01-xx)[https://pmc.ncbi.nlm.nih.gov/articles/PMC7851038/]