masonfe-hyunsu
🧵 1. 개요 : 한 줄로 보면.
AI를 개발에 쓰기 시작하면서, "어떻게 시키면 결과가 좋아지나"에 대한 관심도 같이 바뀌어 왔다.
처음에는 채팅으로 질문하는 정도였는데, 지금은 Cursor, Claude Code처럼 코드를 직접 고치는 도구까지 들어왔다.
그래서 관심사도 대략 이렇게 옮겨졌다.
말을 잘 쓰기 (Prompt)
프로젝트 정보를 미리 주기 (Context)
AI가 일할 환경을 만들어 두기 (Harness)
영어로 부르면 Prompt Engineering → Context Engineering → Harness Engineering이다.
Cursor를 쓰다 보면 "프롬프트를 더 잘 쓰면 되지 않나?"만으로는 설명이 안 되는 순간이 자주 있었다.
이 포스팅에서는 세 단계를 쉬운 말로 나눠 정리해 본다.
Prompt : 이번 요청을 어떻게 말할지. (말 잘 시키기)
Context : 프로젝트 정보를 어떻게 미리 넣을지. (미리 알려두기)
Harness : AI가 어떤 규칙과 검사 안에서 일하게 할지. (일할 환경 만들기)
💬 2. Prompt Engineering : 말을 잘 시키기.
ChatGPT가 막 나왔을 때는, AI에게 어떻게 말하느냐가 거의 전부였다.
Prompt Engineering은 쉽게 말해 질문 문장을 잘 써서 답을 더 좋게 만드는 일이다.
자주 쓰이던 방법들.
더 구체적으로 말하기.
"더 자세하게 설명해줘"
"단계별로 생각해줘"
"전문가처럼 답변해줘"
문장을 조금만 바꿔도 답이 달라지는 걸 많이 겪었다.
역할 주기. (Role Play)
"너는 시니어 개발자야"
"너는 코드 리뷰어야"
"너는 보안 전문가야"
역할을 주면, 그 시선으로 답해주는 경우가 많다.
생각 과정을 보여 달라고 하기. (Chain of Thought)
"문제를 단계별로 분석해줘"
"답을 바로 내지 말고, 중간 과정을 보여줘"
한 번에 답을 내기보다, 과정을 적게 하면 틀린 답이 줄어드는 느낌이 있었다.
예시를 먼저 보여주기. (Few-Shot)
원하는 형식의 예시 몇 개를 먼저 주고다.
그다음 같은 패턴으로 이어서 쓰게 한다.
예를 들면 이렇게 준다.
회원가입 API → UserController
로그인 API → AuthController
비밀번호 변경 API → ??출력:
PasswordController당시 기준은 단순했다.
좋은 결과 = 좋은 프롬프트
🤖 3. AI 코딩 도구 : 채팅을 넘어 코드 수정까지.
이제는 AI가 채팅창에만 있지 않다.
GitHub Copilot, Cursor, Claude Code, Codex, Gemini CLI처럼 에디터나 터미널에서 코드를 직접 고치는 도구가 늘었다.
"설명해줘"에서 "이 파일 수정해줘"로 역할이 넓어진 셈이다.
같은 말을 해도 결과가 제각각인 문제.
같은 문장을 넣어도, 실행할 때마다 결과가 달라질 수 있다.
예를 들어 "React 로그인 페이지 만들어줘"를 여러 번 시키면 이런 식이다.
어떤 번은 함수형 컴포넌트
어떤 번은 클래스 컴포넌트
폴더 구조도 제각각
TypeScript를 안 쓰는 경우도 있다
코드 자체는 나오는데, 우리 프로젝트 규칙에 맞는 코드는 아닌 경우가 많았다.
Cursor에서 같은 요청을 반복해 보면, "돌아가긴 하는데 이 레포 스타일은 아닌" 결과가 자주 나와서 손이 더 갔다.
같은 프롬프트여도 실행마다 구조, 스타일, 파일 구성이 갈라질 수 있다.
📏 4. 프롬프트만으로 버티기 어려워진 이유.
프로젝트가 커질수록, 매 요청마다 붙여야 할 조건이 늘어났다.
"React, TypeScript 써줘"
"
any쓰지 마, ESLint 지켜""테스트도 작성해"
"폴더 구조, 스타일 규칙도 맞춰"
결국 매번 같은 말을 다시 적는 일이 된다.
사람이 기억해서 붙여 넣는 방식은, 글이 길어질수록 빼먹기 쉽다.
프롬프트를 길게 쓰는 걸로 버티다 보면, 검수도 사람이 계속 떠안게 된다.
📚 5. Context Engineering : 미리 알려두기.
그래서 방향이 바뀌었다.
프롬프트를 매번 길게 쓰기보다, 프로젝트 문서를 저장소에 두고 AI가 자동으로 보게 하는 쪽이다.
Context Engineering은 쉽게 말해 AI에게 미리 배경지식을 넣어 두는 일이다.
Cursor Rules를 한 번 잡아두면, 같은 제약을 매번 다시 안 적어도 되어서 체감이 컸다.
자주 두는 문서 예시:
README.md
아키텍처 정리
API 문서
디자인 시스템
코딩 컨벤션
도구마다 파일 이름만 다르고, 역할은 비슷하다.
Cursor: Rules
Claude Code: CLAUDE.md
Codex: AGENTS.md
Cursor Rules 예시. 프로젝트 규칙을 저장소에 두고 AI가 참고하게 한다.
Claude Code의 CLAUDE.md 예시.
이때 기준은 이렇게 넓어졌다.
좋은 결과 = 좋은 프롬프트 + 좋은 컨텍스트
⚠️ 6. 문서만 줘도 부족한 이유.
규칙 문서를 줘도, 아래 문제는 그대로 남을 수 있다.
빌드나 테스트가 깨짐
엉뚱한 파일을 수정함
규칙을 읽고도 안 지킴
코드 스타일이 어긋남
쉽게 말하면, 문서는 "이렇게 해"를 알려줄 뿐이고 "진짜 그렇게 했는지"를 검사하진 않는다.
Rules만 믿다가 lint, test에서 한 번에 깨지는 경험을 몇 번 하고 나서야, 다음이 보이기 시작했다.
🔧 7. Harness Engineering : 일할 환경을 만들기.
이제는 "뭐라고 말할지"보다, AI가 이 프로젝트에서 어떻게 일하게 할지를 설계하는 쪽으로 관심이 옮겨졌다.
Martin Fowler는 이렇게 말한다.
Agent = Model + Harness
쉽게 풀면 이렇다.
Model: AI 자체 (똑똑한 엔진)
Harness: 그 엔진이 일하는 바깥 환경 (규칙, 도구, 검사)
Harness Engineering은 그 바깥 환경을 잘 짜는 일이다.
예를 들면 이런 것들이다.
Rules, Skills (어떻게 일할지)
Hooks, Memory (언제 끼어들고, 무엇을 기억할지)
Context (무엇을 참고할지)
Lint, Test, Review, Workflow (결과를 어떻게 검사하고 흘릴지)
모델이 조금 더 좋은 것보다, 어떤 규칙과 검사 안에 두느냐가 체감이 더 컸다.
개인적으로는 Rules, Skills에 더해 format, lint, test를 저장소에 고정해 두는 쪽이, "같은 말 반복하기"를 줄이는 데 제일 도움이 됐다.
✅ 8. 정리.
한 줄로 보면 이 흐름이다.
말 잘 시키기 (Prompt)
↓
미리 알려두기 (Context)
↓
일할 환경 만들기 (Harness)Prompt: 이번 요청을 어떻게 말할까
Context: 프로젝트 정보를 어떻게 미리 넣을까
Harness: AI가 어떤 규칙과 검사 안에서 일하게 할까
결국 "문장을 잘 쓰는 일"에서 시작해, "문서를 잘 주는 일"로 넓어졌고, 지금은 "AI가 일할 자리를 만들어 두는 일"로 관심이 옮겨진 느낌이다. 실무에서는 그 자리를 저장소에 고정해 두는 쪽이 더 편했다.
댓글