AI를 강화하는 다섯 가지 기본 인간 기술

AI 코딩 도구로 소프트웨어를 만드는 데 컴퓨터 과학 학위가 필요하지 않습니다. 하지만 어떤 AI도 대체할 수 없는 작은 기술 세트가 필요합니다. 이것들이 필수 불가결한 토대입니다 — 다른 모든 것을 가능하게 하는 것들.

짧은 목록

기술	필수적인 이유
Git	안전망 — 무엇이든 실행 취소하고, 두려움 없이 브랜치하고, 작업을 잃지 않음
TDD	AI가 생성한 코드를 정직하게 유지하는 방법론
터미널 리터러시	AI 도구는 터미널에서 실행됩니다; 출력을 읽을 수 있어야 합니다
영어	문서, 오류, AI 프롬프트 모두 영어에서 가장 잘 작동합니다
취향	AI가 옵션을 생성합니다; 여러분이 어떤 것이 옳은지 결정합니다

그것이 전부입니다. 다섯 가지. 언어 구문, 프레임워크 API, 디자인 패턴 등 다른 모든 것은 — AI가 처리합니다.^[1]

Git — 안전망

Git은 여러분의 무기고에서 가장 중요한 단일 도구입니다. 리베이스나 체리픽을 마스터해야 해서가 아니라 — AI가 그것을 처리합니다 — Git이 여러분에게 두려움 없는 실험 을 제공하기 때문입니다.^[2]

실제로 알아야 할 것

명령어	기능	사용 시점
git status	변경된 내용 표시	모든 AI 세션 전후
git diff	정확한 변경 사항 표시	커밋 전 AI가 작성한 내용 검토
git add + git commit	체크포인트 저장	모든 작동 상태 후
git log	변경 기록	무슨 일이 있었는지 이해할 때
git stash	변경 사항 임시 보관	다른 접근법을 시도하고 싶을 때
git checkout -- file	파일 변경 실행 취소	AI가 무언가를 더 나쁘게 만들었을 때
git worktree	여러 브랜치 동시 작업	병렬로 아이디어를 탐구하고 싶을 때

멘탈 모델

Git을 무한 실행 취소 로 생각하세요. 모든 커밋은 돌아갈 수 있는 저장 지점입니다. 이는 다음을 의미합니다:

• 위험한 변경을 자유롭게 시도 — 언제든지 돌아갈 수 있습니다
• AI가 실험하게 허용 — 무언가를 망가뜨리면 롤백하세요
• 여러 아이디어 작업 — 브랜치로 병렬 탐구
• 수락 전 검토 — git diff가 AI가 변경한 것을 정확히 보여줍니다

AI가 여러분을 위해 커밋, 브랜치, 풀 리퀘스트를 만들 것입니다. 하지만 이것들이 무엇인지 이해해야 합니다. 언제 저장하고, 언제 브랜치하고, 언제 병합할지 결정하는 사람은 여러분이기 때문입니다.

Git 워크트리 — 평행 우주

일찍 배울 가치 있는 Git 기능 중 하나는 워크트리 입니다. 워크트리는 현재 작업을 전환하지 않고 별도의 디렉터리에서 다른 브랜치를 체크아웃할 수 있게 합니다:

# 새 기능을 위한 워크트리 만들기
git worktree add ../my-feature -b feature/new-idea

# 거기서 작업
cd ../my-feature
claude    # 이 브랜치에서 AI 세션 시작

# 메인 작업으로 돌아가기 — 변경 없음
cd ../vmark

이것은 AI 코딩 도구와 함께 특히 강력합니다: 한 AI 세션이 기능 브랜치에서 실험하는 동안 메인 브랜치가 깨끗하고 작동하는 상태로 유지될 수 있습니다. 실험이 실패하면 워크트리 디렉터리를 삭제하세요. 혼란 없고, 위험 없습니다.

Git을 건너뛰지 마세요

Git 없이, 잘못된 AI 편집 하나가 되돌릴 방법 없이 몇 시간의 작업을 망칠 수 있습니다. Git이 있으면 최악의 경우는 항상 git checkout -- .이고 마지막 저장으로 돌아갈 수 있습니다. 다른 무엇보다 먼저 Git 기초를 배우세요.

TDD — AI를 정직하게 유지하는 방법

테스트 주도 개발 (TDD)은 AI 코딩을 "작동하기를 바란다"에서 "작동한다는 것을 증명한다"로 바꾸는 방법론입니다. 단순한 좋은 관행이 아닙니다 — AI가 생성한 코드가 실제로 여러분이 요청한 것을 수행하는지 검증 하는 주요 메커니즘입니다.^[3]

RED-GREEN-REFACTOR 사이클

TDD는 엄격한 3단계 루프를 따릅니다:

1. RED     — 원하는 것을 설명하는 테스트를 작성합니다. 실패합니다.
2. GREEN   — AI에게 테스트를 통과하기 위한 최소 코드를 작성하도록 요청합니다.
3. REFACTOR — 동작을 변경하지 않고 정리합니다. 테스트가 여전히 통과합니다.

AI 코딩 도구와 함께 이것이 놀랍도록 잘 작동하는 이유:

단계	여러분의 역할	AI의 역할
RED	예상 동작 설명	테스트 assertion 작성 도움
GREEN	테스트가 통과하는지 확인	구현 작성
REFACTOR	코드가 충분히 깔끔한지 판단	정리 수행

AI와 함께 TDD가 더 중요한 이유

직접 코드를 작성할 때, 암묵적으로 이해합니다 — 직접 작성했기 때문에 무엇을 하는지 알고 있습니다. AI가 코드를 작성할 때, 외부 검증 메커니즘 이 필요합니다. 테스트가 그 메커니즘입니다.^[4]

테스트 없이 일어나는 일:

1. AI에게 기능을 추가하도록 요청합니다
2. AI가 200줄의 코드를 작성합니다
3. 읽어보니, 올바르게 보입니다
4. 배포합니다
5. 무언가를 망가뜨립니다 — 미묘한 엣지 케이스, 타입 불일치, 오프 바이 원 오류

TDD와 함께:

1. 동작을 테스트로 설명합니다 (AI가 작성하는 것을 도와줍니다)
2. 테스트가 실패합니다 — 실제로 무언가를 테스트하고 있음을 확인
3. AI가 통과하는 코드를 작성합니다
4. 테스트를 실행합니다 — 통과합니다
5. 그냥 느낌이 아닌 작동한다는 증명 이 있습니다

테스트가 어떻게 생겼는지

처음부터 테스트를 작성할 필요가 없습니다. 원하는 것을 일반 언어로 설명하면 AI가 테스트를 작성합니다. 하지만 테스트를 읽을 수 있어야 합니다:

// "사용자가 문서를 저장할 때, 수정 플래그가 지워져야 합니다"
it("저장 후 수정 플래그를 지웁니다", () => {
  // 설정: 문서를 수정됨으로 표시
  store.markModified("doc-1");
  expect(store.isModified("doc-1")).toBe(true);

  // 동작: 문서 저장
  store.save("doc-1");

  // 검증: 수정 플래그 지워짐
  expect(store.isModified("doc-1")).toBe(false);
});

패턴은 항상 동일합니다: 설정, 동작, 검증. 이 패턴을 인식하면 어떤 테스트든 읽을 수 있고 — 더 중요하게, AI에게 다음에 무엇을 테스트할지 말할 수 있습니다.

엣지 케이스 — 버그가 사는 곳

TDD의 진정한 힘은 엣지 케이스 — 버그가 숨는 비정상적인 입력과 경계 조건 — 에 있습니다. AI는 독자적으로 이것들을 생각하는 데 놀랍도록 나쁩니다.^[5] 하지만 프롬프트할 수 있습니다:

"파일 이름이 비어 있으면 어떻게 됩니까?" "사용자가 저장 버튼을 두 번 클릭하면 어떻게 됩니까?" "요청 중간에 네트워크가 끊어지면 어떻게 됩니까?" "이름에 유니코드 문자가 있는 파일은요?"

각각이 테스트가 됩니다. 각 테스트가 보장이 됩니다. 더 많은 엣지 케이스를 생각할수록 소프트웨어가 더 강력해집니다. 이것이 인간의 취향 과 AI의 구현 속도 가 결합하여 어느 쪽도 단독으로는 달성할 수 없는 것을 만드는 곳입니다.

AI와 함께 실제 TDD

실제 워크플로우:

여러분:   파일 이름이 유효한지 확인하는 함수를 추가하세요.
          실패하는 테스트부터 시작하세요.

AI:    [테스트 작성] it("빈 파일 이름을 거부합니다", () => { ... })
       [테스트 실패 — RED ✓]

여러분:   이제 통과하게 만드세요.

AI:    [isValidFilename() 작성]
       [테스트 통과 — GREEN ✓]

여러분:   다음에 대한 테스트를 추가하세요: 공백만 있는 것, 경로 구분자,
          255자 이상의 이름, null 바이트.

AI:    [테스트 4개 더 작성, 일부 실패]
       [모든 경우를 처리하도록 함수 업데이트]
       [모든 테스트 통과 — GREEN ✓]

여러분:   좋아요. 필요하면 리팩터링하세요.

AI:    [정규식 단순화, 테스트 유지 — REFACTOR ✓]

코드 한 줄도 작성하지 않았습니다. 하지만 모든 결정을 이끌었습니다. 테스트가 코드가 작동한다는 것을 증명합니다. 그리고 누군가 나중에 함수를 변경하면 테스트가 회귀를 잡아냅니다.

커버리지 래칫

VMark는 테스트 커버리지 임계값을 강제합니다 — 커버리지가 바닥 아래로 떨어지면 빌드가 실패합니다. 이는 모든 새 기능이 반드시 테스트가 있어야 한다는 것을 의미합니다. AI가 이것을 알고 자동으로 테스트를 작성하지만, 코드 줄이 아닌 의미 있는 동작을 테스트하는지 확인해야 합니다.

터미널 리터러시

AI 코딩 도구는 명령줄 프로그램입니다. Claude Code, Codex CLI, Gemini CLI — 모두 터미널에서 실행됩니다. 수백 개의 명령어를 암기할 필요는 없지만, 소수에 익숙해야 합니다:

cd ~/projects/vmark      # 디렉터리로 이동
ls                        # 파일 목록
git status                # 변경된 것 확인
git log --oneline -5      # 최근 커밋
pnpm install              # 종속성 설치
pnpm test                 # 테스트 실행

AI가 여러분을 위해 명령어를 제안하고 실행할 것입니다. 여러분의 역할은 출력을 읽고 성공했는지 실패했는지 이해하는 것입니다. 테스트 실패는 빌드 오류와 다르게 보입니다. 권한 거부는 파일 없음과 다릅니다. 직접 수정할 필요는 없습니다 — 하지만 AI가 수정할 수 있도록 보이는 것을 설명할 수 있어야 합니다.

여기서 시작하세요

터미널을 사용해본 적이 없다면 MIT의 The Missing Semester에서 시작하세요 — 특히 셸 도구에 관한 첫 번째 강의. 한 시간의 연습으로 AI 코딩 도구와 작업하기에 충분합니다.

영어 능력

완벽한 산문을 쓰는 것이 아닙니다. 읽기 이해 — 오류 메시지, 문서, AI 설명 이해 — 에 관한 것입니다. 전체 소프트웨어 생태계가 영어로 운영됩니다:^[6]

• 오류 메시지 는 영어로 되어 있습니다
• 문서 는 영어로 먼저 (그리고 종종 단독으로) 작성됩니다
• Stack Overflow, GitHub 이슈, 튜토리얼이 압도적으로 영어입니다
• AI 모델은 영어 프롬프트에서 측정 가능하게 더 잘 수행합니다 (왜 영어 프롬프트가 더 나은 코드를 생성하는가 참조)

유창하게 쓸 필요가 없습니다. 다음이 필요합니다:

1. 오류 메시지를 읽고 요점을 이해
2. 기술 용어를 효과적으로 검색
3. AI에게 원하는 것을 충분히 명확하게 설명

영어가 모국어가 아니라면, VMark의 :: 프롬프트 훅이 자동으로 프롬프트를 영어로 번역하고 정제합니다. 하지만 AI의 응답을 읽는 것 — 영어로 되어 있는 — 은 지속적으로 하게 될 것입니다.

취향 — AI가 대체할 수 없는 한 가지

이것이 정의하기 가장 어렵고 가장 중요합니다. 취향 은 좋은 것이 어떻게 보이는지 아는 것입니다 — 아직 직접 만들 수 없어도.^[7]

AI가 문제를 해결하기 위한 세 가지 접근법을 제시할 때, 취향이 다음을 말해줍니다:

• 간단한 것이 영리한 것보다 낫습니다
• 종속성이 더 적은 솔루션이 선호됩니다
• 산문처럼 읽히는 코드가 "최적화된" 코드를 이깁니다
• 10줄 함수는 5줄로 충분하면 의심스럽습니다

취향을 키우는 방법

1. 좋은 소프트웨어 사용 — 무엇이 올바르게 느껴지고 무엇이 서툴게 느껴지는지 주목하세요
2. 좋은 코드 읽기 — GitHub의 인기 오픈 소스 프로젝트를 탐색하세요
3. 출력을 읽기 — AI가 코드를 생성할 때, 쓸 수 없어도 읽으세요
4. "왜"를 물어보기 — AI가 선택을 할 때, 트레이드오프를 설명하도록 요청하세요
5. 반복 — 무언가가 잘못된 느낌이 든다면, 아마도 그럴 것입니다. AI에게 다시 시도하도록 요청하세요

취향이 복합됩니다. 더 많은 코드를 읽을수록 (AI가 생성한 코드조차도), 직관이 더 좋아집니다. AI 보조 개발 몇 달 후에, AI가 놓치는 문제를 잡아낼 것입니다 — 더 많은 구문을 알기 때문이 아니라, 결과가 어떻게 느껴져야 하는지 알기 때문입니다.

취향 테스트

AI가 작업을 마친 후, 스스로 물어보세요: "사용자라면 이것이 올바르게 느껴질까요?" 답이 즉각적인 예가 아니라면, AI에게 무엇이 잘못 느껴지는지 말하세요. 수정 방법을 알 필요는 없습니다 — 그냥 느낌만으로 됩니다.

필요 없는 것

필수 사항을 아는 것만큼 중요한 것은 안전하게 건너뛸 수 있는 것을 아는 것입니다:

필요 없음	이유
프로그래밍 언어 마스터리	AI가 코드를 작성합니다; 여러분은 검토합니다
프레임워크 전문 지식	AI는 대부분의 인간보다 React, Rails, Django를 더 잘 알고 있습니다
알고리즘 지식	AI가 알고리즘을 구현합니다; 여러분은 목표를 설명합니다
DevOps 기술	AI가 CI 구성, Docker 파일, 배포 스크립트를 작성합니다
디자인 패턴 암기	AI가 동작을 설명할 때 올바른 패턴을 적용합니다
수년의 경험	신선한 관점 + AI > AI 없는 경험[8]

이 기술들이 가치 없다는 것이 아닙니다 — 더 빠르고 더 효과적으로 만들어 줍니다. 하지만 더 이상 전제 조건 이 아닙니다. AI가 가르치는 동안 점진적으로, 현장에서 배울 수 있습니다.

복합 효과

이 다섯 가지 기술 — Git, TDD, 터미널, 영어, 취향 — 은 단순히 더해지지 않습니다. 복합됩니다.^[9]

• Git 안전이 자유롭게 실험할 수 있게 하고, 취향이 더 빠르게 발전
• TDD가 AI 출력에 대한 확신을 주어 더 빠르게 움직일 수 있음
• 터미널 유창성이 테스트와 Git 명령어를 마찰 없이 실행하게 함
• 영어 이해력이 오류 메시지와 문서를 읽을 수 있게 함
• 취향이 프롬프트를 더 정확하게 만들고, 더 나은 코드를 생성
• 더 나은 코드가 배울 더 나은 예시를 제공

AI 보조 개발 몇 주 후에, 공식적으로 공부한 적 없는 것들을 이해하기 시작할 것입니다. 이것이 복합 효과가 작동하는 것입니다 — 그리고 이 다섯 가지 토대, 그리고 오직 이 다섯 가지만이, 진정으로 필수 불가결한 이유입니다.

---

1. "노코드" 및 "로우코드" 운동은 수년간 프로그래밍 장벽을 제거하려고 노력했습니다. AI 코딩 도구는 만들 수 있는 것을 제한하지 않기 때문에 더 효과적으로 이것을 달성합니다 — 자연어 설명에 기반하여 어떤 언어로든 임의의 코드를 작성합니다. 참조: Jiang, E. et al. (2022). Discovering the Syntax and Strategies of Natural Language Programming with Generative Language Models. CHI 2022. ↩︎

2. Git의 브랜칭 모델은 사람들이 실험에 접근하는 방식을 근본적으로 바꿉니다. 빈번한 소규모 커밋과 브랜치를 사용하는 팀이 위험한 변경을 시도할 가능성이 훨씬 높다는 연구가 있습니다. 참조: Bird, C. et al. (2009). Does Distributed Development Affect Software Quality?. ICSE 2009. ↩︎

3. 테스트 주도 개발은 Kent Beck이 2002년에 공식화했으며 전문 소프트웨어 엔지니어링의 초석이 되었습니다. 먼저 테스트를 작성하는 규율은 구현 전에 요구 사항을 명확히 하도록 개발자를 강제합니다 — "개발자"가 정확한 지침이 필요한 AI일 때 더욱 강력한 이점. 참조: Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley. ↩︎

4. AI 코드 생성에 관한 연구는 AI가 생성한 코드가 명시적인 테스트 케이스로 안내되지 않는 한 인간이 작성한 코드보다 낮은 비율로 기능 테스트를 통과한다는 것을 일관되게 발견합니다. 프롬프트에 테스트 케이스를 제공하면 올바른 코드 생성이 20–40% 증가합니다. 참조: Chen, M. et al. (2021). Evaluating Large Language Models Trained on Code. arXiv:2107.03374. ↩︎

5. AI 모델은 엣지 케이스와 경계 조건에서 체계적으로 저성능입니다. "행복한 경로" 코드를 생성하는 경향이 있어 일반적인 입력은 처리하지만 비정상적인 것에서는 실패합니다. 이것은 트랜스포머 기반 코드 생성의 문서화된 한계입니다. 참조: Pearce, H. et al. (2022). Examining Zero-Shot Vulnerability Repair with Large Language Models. IEEE S&P 2022. ↩︎

6. 영어가 프로그래밍 및 기술 문서를 압도적으로 지배합니다. GitHub 공개 저장소 분석에서 README 파일과 코드 주석의 90% 이상이 영어로 되어 있음을 보여줍니다. 마찬가지로, Stack Overflow의 2,300만 개 질문이 주로 영어입니다. 참조: Casalnuovo, C. et al. (2015). Developer Onboarding in GitHub. ESEC/FSE 2015. ↩︎

7. 소프트웨어 엔지니어링에서의 "취향" — 좋은 디자인과 나쁜 디자인을 구분하는 능력 — 은 핵심 기술로 점점 더 인식되고 있습니다. Fred Brooks는 "위대한 디자인은 위대한 디자이너에서 나온다"고 썼습니다, 위대한 프로세스가 아닌. AI가 코딩의 기계적 측면을 처리함으로써, 이 미적 판단이 주요 인간 기여가 됩니다. 참조: Brooks, F. (2010). The Design of Design. Addison-Wesley. ↩︎

8. AI 보조 프로그래밍에 관한 연구에서 경험이 적은 개발자가 전문가보다 AI 도구에서 더 많은 이점을 얻는 경우가 많다는 것을 보여줍니다. AI 지원으로 "설명할 수 있다"와 "구현할 수 있다"의 격차가 극적으로 줄어들기 때문입니다. 참조: Peng, S. et al. (2023). The Impact of AI on Developer Productivity. arXiv:2302.06590. ↩︎

9. "복합 학습" — 기초 기술이 관련 기술의 습득을 가속화하는 곳 — 개념은 교육 연구에서 잘 확립되어 있습니다. 프로그래밍에서 특히, 몇 가지 핵심 아이디어를 이해하면 그 위에 구축된 모든 것의 빠른 학습이 가능합니다. 참조: Sorva, J. (2012). Visual Program Simulation in Introductory Programming Education. Aalto University. ↩︎