기본 콘텐츠로 건너뛰기

Pinned Post

Aside 브라우저를 Claude Code에 MCP로 연결하기: Windows 설치 및 설정 가이드

Aside 브라우저를 Claude Code에 MCP로 연결하기: Windows 설치 및 설정 가이드 웹 개발을 하다 보면 코드를 작성하는 것만으로는 부족할 때가 있습니다. 실제 브라우저에서 페이지를 열어 보고, 화면이 제대로 표시되는지 확인하고, 웹 애플리케이션의 동작까지 살펴봐야 하죠. Claude Code에서 이런 브라우저 작업을 활용하고 싶다면 Aside와 MCP를 연결하는 방법을 살펴볼 만합니다. 설정 과정은 복잡하지 않습니다. 다만 Aside에서 CLI를 설치하는 것과 Claude Code에 MCP 서버를 등록하는 것은 별개의 작업이므로 순서대로 진행해야 합니다. 이 글에서 다루는 내용 Aside 브라우저와 CLI 설치 Claude Code용 Skill 설정 Aside MCP 서버 활성화 Windows 경로를 사용한 MCP 설정 연결 상태 확인 및 문제 해결 작성 기준일: 2026년 10월 28일 대상 환경: Windows 11, Aside 브라우저, Claude Code CLI 참고: 아래 절차는 제공된 설정 내용을 바탕으로 정리했습니다. 실제 PC에서 설치하거나 연결 테스트를 진행한 결과는 아닙니다. 1. 먼저 준비할 것 시작하기 전에 Aside 브라우저와 Claude Code를 준비합니다. Claude Code는 터미널에서 claude 명령을 실행할 수 있는 상태여야 합니다. Aside 브라우저: 설치 후 실행할 수 있어야 합니다. Aside CLI: 브라우저의 Developers 화면에서 설치합니다. Claude Code CLI: 터미널에서 실행할 수 있도록 설치와 초기 설정을 마칩니다. 2. Aside 브라우저 설치 먼저 Aside 공식 홈페이지 에서 브라우저를 설치한 뒤 실행합니다. 이후 CLI 설치와 MCP 설정은 Aside 앱 안에서 진행합니다. 브라우저를 설치했다고 해서 Claude Code와 자동으로 연결되는 것은 아니므로 다음 단계를 이어서 진행해야 합니...

AI 코딩 에이전트 프롬프트 활용법: GitHub 스킬 6가지로 작업 품질 높이기

AI 코딩 에이전트 프롬프트 활용법: GitHub 스킬 6가지로 작업 품질 높이기

AI에게 코드를 작성해 달라고 요청했는데, 필요하지 않은 파일까지 수정하거나 기존 프로젝트의 규칙을 무시하는 경우가 있습니다. 문서를 작성할 때도 표현이 반복되거나, 이전 작업에서 정한 조건이 다음 요청에 반영되지 않는 일이 생깁니다.

이런 문제를 줄이려면 프롬프트를 길게 작성하는 것보다 무엇을 요청할지, 어떤 순서로 작업할지, 결과를 어떻게 검증할지를 명확하게 정하는 편이 좋습니다.

GitHub에는 이런 작업 방식을 돕는 AI 에이전트 스킬이 여럿 공개되어 있습니다. 이번 글에서는 Karpathy Guidelines, Claude Video, Humanizer, Agent Memory, Superpowers, Skill Creator를 살펴보고, 각 스킬을 활용할 때 어떤 프롬프트를 입력하면 좋은지 예제 중심으로 정리합니다.

이 글에서 다루는 내용

  • AI가 요청 범위를 벗어나 코드를 수정하지 않도록 지시하는 방법
  • 동영상 분석 결과를 개발 문서로 정리하도록 요청하는 방법
  • 한국어 기술 문서를 자연스럽게 윤문하는 프롬프트
  • 이전 작업의 결정 사항을 다음 세션에 전달하는 방법
  • 설계·구현·테스트를 단계별로 진행하도록 지시하는 방법
  • 반복 작업을 전용 스킬로 만들고 결과를 평가하는 방법

작성 기준일: 2026년 10월 28일

확인 범위: 공개 GitHub 저장소와 공식 문서의 설명을 확인했습니다. 아래 프롬프트는 실제 사용에 참고할 수 있도록 구성한 예제이며, 실제 IDE에서 실행한 결과나 성능 측정값은 아닙니다.

1. 프롬프트를 잘 작성하려면 무엇이 달라야 할까?

AI에게 작업을 요청할 때 가장 흔한 실수는 목표만 전달하고 작업 범위와 완료 조건은 정하지 않는 것입니다.

예를 들어 다음과 같이 요청할 수 있습니다.

게시판 검색 기능을 개선해 줘.

요청 자체는 간단하지만 검색 대상, 정렬 규칙, 페이징 처리, 수정 가능한 파일, 테스트 기준이 정해져 있지 않습니다. AI가 프로젝트를 분석한 뒤 합리적인 방향을 선택할 수도 있지만, 사용자가 의도한 결과와 다르게 구현할 가능성도 있습니다.

같은 요청을 다음과 같이 구체화할 수 있습니다.

기존 게시판의 검색 기능을 개선해 줘.

작업 전에 다음 항목을 확인해 줘.
1. 현재 검색 조건과 페이징 처리 방식
2. 관련 컨트롤러, 서비스, 데이터 접근 코드
3. 기존 테스트와 코딩 규칙
4. 요구사항에서 확인이 필요한 부분

수정 범위:
- 검색 기능과 직접 관련된 코드만 변경한다.
- 기존 API 계약과 프로젝트 구조를 유지한다.
- 요청하지 않은 리팩터링은 하지 않는다.

검증 기준:
- 검색어가 있는 경우 정상적으로 조회되는지 확인한다.
- 검색 결과가 없는 경우를 확인한다.
- 페이징과 정렬이 기존 규칙에 맞게 동작하는지 확인한다.
- 실행한 테스트와 실행하지 못한 테스트를 구분해 보고한다.

두 번째 프롬프트에는 작업 범위와 함께 요청한 결과를 확인할 수 있는 조건이 들어 있습니다. 프롬프트가 길든 짧든, 이 조건이 있어야 결과를 검증할 수 있습니다.

프롬프트를 구성하는 다섯 가지 요소

  1. 목표: 무엇을 해결하려는가?
  2. 맥락: 현재 프로젝트와 기존 구현은 어떤 상태인가?
  3. 제약: 수정하면 안 되는 부분과 반드시 지켜야 할 규칙은 무엇인가?
  4. 절차: 어떤 순서로 분석하고 구현할 것인가?
  5. 검증: 어떤 조건을 만족해야 작업이 완료되는가?

이 다섯 가지 요소를 모든 요청에 동일한 분량으로 넣을 필요는 없습니다. 단순한 작업에는 목표와 제약만으로 충분할 수 있고, 여러 계층을 수정하는 작업에는 분석 절차와 검증 기준까지 지정하는 편이 좋습니다.

2. Karpathy Guidelines: 불필요한 코드 변경을 줄이는 프롬프트

영상 타임스탬프: 00:26

GitHub 저장소: multica-ai/andrej-karpathy-skills

Karpathy Guidelines는 AI 코딩 에이전트가 작업할 때 지켜야 할 행동 원칙을 정리한 프로젝트입니다. 공식 지침은 구현 전에 가정을 확인하고, 단순한 해결책을 우선하며, 요청과 직접 관련된 코드만 수정하고, 검증 가능한 완료 조건을 설정하는 데 초점을 맞춥니다.

이런 상황에서 활용합니다

  • 간단한 버그 수정인데 여러 파일을 불필요하게 변경하는 경우
  • 기존 코딩 스타일과 다른 구조를 새로 도입하는 경우
  • 요구사항이 모호한데도 확인하지 않고 구현하는 경우
  • 테스트를 실행하지 않았는데 작업이 완료되었다고 보고하는 경우

실무 프롬프트 예제

현재 프로젝트의 기존 코드를 기준으로 요청한 기능만 수정해 줘.

작업 원칙:
1. 수정 전에 관련 코드와 호출 관계를 확인한다.
2. 요구사항이 불명확하면 임의로 결정하지 말고 질문한다.
3. 가장 단순한 해결책을 우선한다.
4. 요청과 직접 관련된 코드만 변경한다.
5. 기존 프로젝트의 코딩 스타일과 설계 규칙을 유지한다.
6. 기존의 사용하지 않는 코드나 무관한 부분은 임의로 삭제하지 않는다.
7. 변경 사항을 검증할 방법을 제시한다.

작업 결과에는 다음 내용을 포함한다.
- 변경한 파일과 변경 이유
- 주요 변경 사항
- 실행한 테스트와 결과
- 추가 확인이 필요한 사항

이 프롬프트는 프로젝트 공통 지침이나 개별 작업 요청에 활용할 수 있습니다. 공통 지침으로 관리할 경우에는 프로젝트의 실제 규칙과 충돌하지 않는지 확인해야 합니다.

결과를 어떻게 검증할까?

코드 변경 전후의 Git diff를 비교하고, 요청과 관계없는 파일이 수정되었는지 확인합니다. 관련 테스트를 실행할 수 있다면 테스트 결과도 함께 확인합니다.

  • 변경한 모든 파일이 요청과 관련되어 있는가?
  • 불필요한 리팩터링이나 의존성 추가가 없는가?
  • 테스트 결과가 실제 실행 기록과 일치하는가?

이 점검은 프롬프트를 적용한 결과를 평가하는 방법입니다. 지침을 사용했다고 해서 불필요한 변경이 반드시 사라지는 것은 아닙니다.

3. Claude Video: 동영상 분석을 개발 문서로 연결하기

영상 타임스탬프: 03:43

GitHub 저장소: bradautomates/claude-video

Claude Video의 Watch 스킬은 동영상 URL이나 로컬 파일을 분석에 활용할 수 있도록 프레임과 음성 전사 정보를 준비합니다. 저장소는 Claude Code뿐 아니라 Codex와 다른 Agent Skills 호환 환경에서 활용하는 방법도 안내합니다.

동영상을 요약해 달라는 요청에서 끝내지 말고, 어떤 정보를 추출할지, 시간 정보를 유지할지, 결과를 어떤 문서 형식으로 정리할지까지 지정하면 결과를 개발 작업에 활용하기 쉬워집니다.

프롬프트 예제: 동영상에서 설정 절차 추출하기

제공한 동영상을 분석해 개발 도구의 설정 절차를 정리해 줘.

분석 기준:
1. 화면에서 실제로 확인되는 작업을 순서대로 정리한다.
2. 중요한 장면에는 타임스탬프를 기록한다.
3. 화면에 표시된 명령어와 설정값은 가능한 한 원문 그대로 기록한다.
4. 화면에서 확인한 사실과 음성 설명을 구분한다.
5. 영상에서 확인할 수 없는 설정은 추측하지 않는다.

출력 형식:
- 단계 번호
- 타임스탬프
- 수행한 작업
- 화면에서 확인한 명령어 또는 설정값
- 추가 확인이 필요한 사항

마지막에는 공식 문서로 검증해야 할 항목을 별도로 정리한다.

분석 결과를 실제 문서로 만드는 후속 프롬프트

앞서 추출한 동영상 분석 결과를 설치 가이드로 정리해 줘.

다음 순서를 유지한다.
1. 사전 준비
2. 설치
3. 설정
4. 실행
5. 정상 동작 확인
6. 자주 발생하는 문제와 해결 방법

작성 규칙:
- 영상에서 확인한 내용과 추가로 확인해야 할 내용을 구분한다.
- 영상에 없는 명령어나 설정값을 임의로 추가하지 않는다.
- 실제로 실행하지 않은 절차를 테스트 완료라고 표현하지 않는다.
- 공식 문서와 대조해야 할 항목에는 확인 필요라고 표시한다.

결과 검증 시 주의할 점

동영상에 나온 명령어가 오래된 버전의 도구를 기준으로 작성되었을 수 있습니다. 화면에 표시된 명령어를 그대로 복사하기보다 공식 문서에서 현재 지원 여부를 확인해야 합니다.

또한 저장소의 안내에 따르면 Watch는 자막을 우선 활용하고, 설정에 따라 로컬 또는 외부 서비스를 통한 음성 전사를 사용할 수 있습니다. 외부 서비스를 사용하는 경우에는 데이터 전송 범위와 API 설정을 확인해야 합니다.

4. Humanizer: 한국어 문장을 자연스럽게 윤문하는 프롬프트

영상 타임스탬프: 06:12

GitHub 저장소: DaleSeo/korean-skills

한국어 기술 블로그를 작성할 때는 문법이 맞는지만 확인해서는 부족합니다. 번역투가 반복되거나, 같은 의미를 여러 번 설명하거나, 필요 이상으로 추상적인 표현을 사용하면 글을 읽는 흐름이 끊길 수 있습니다.

Humanizer는 한국어 텍스트를 다듬는 스킬입니다. 저장소에서는 문장 개선 이후 맞춤법·문법 검사와 문체 일관성 검사를 이어서 진행하는 워크플로도 안내합니다.

프롬프트 예제: 의미를 유지하면서 윤문하기

아래 글을 자연스러운 한국어 기술 블로그 문체로 윤문해 줘.

가장 중요한 원칙은 원문의 의미와 기술적 정확성을 유지하는 것이다.

수정할 항목:
1. 반복되는 표현과 불필요한 접속어
2. 번역투와 지나치게 추상적인 문장
3. 문맥에 맞지 않는 어색한 조사와 어순
4. 불필요하게 장황한 설명
5. 문단 사이의 부자연스러운 연결

반드시 유지할 항목:
- 원문의 사실, 수치, 날짜, 인과관계
- 기술 용어, 제품명, 버전, API 이름
- 코드, 명령어, 파일 경로, URL
- 오류 메시지와 직접 인용문
- 원문에서 명시한 조건과 불확실성

작성 규칙:
- 자연스러운 문장은 불필요하게 다시 쓰지 않는다.
- 모든 문장을 짧게 만들거나 종결어미를 억지로 바꾸지 않는다.
- 원문에 없는 사실이나 경험을 추가하지 않는다.
- 실제 실행하지 않은 검사나 테스트를 완료했다고 표현하지 않는다.

최종 결과는 수정된 글 전체를 제공하고,
기술적 의미가 달라질 수 있는 부분은 별도로 알려 줘.

[원문]
여기에 윤문할 글을 입력한다.

윤문 전후를 비교하는 예시

수정 전

이 기능을 통해 개발 생산성을 향상시킬 수 있으며, 이를 통해 효율적인 개발 환경을 구축할 수 있습니다.

윤문 예시

이 기능을 활용하면 반복 작업을 줄이고 개발 환경을 더 효율적으로 관리할 수 있습니다.

위 문장은 윤문 원칙을 설명하기 위해 작성한 예시이며, Humanizer를 직접 실행한 결과는 아닙니다.

권장하는 후속 검토 순서

  1. Humanizer: 문장과 표현을 다듬습니다.
  2. Grammar Checker: 맞춤법, 띄어쓰기, 문법을 확인합니다.
  3. Style Guide: 용어, 어조, 문서 형식의 일관성을 검토합니다.

이 순서는 저장소에서 안내하는 권장 워크플로입니다. 다만 문체 교정 도구가 기술적 사실까지 검증하는 것은 아닙니다. 최종 단계에서 원문과 수정본을 비교해 기술적 의미가 달라지지 않았는지 확인해야 합니다.

5. Agent Memory: 이전 작업의 맥락을 활용하는 프롬프트

영상 타임스탬프: 07:39

GitHub 저장소: rohitg00/agentmemory

장기간 개발하는 프로젝트에서는 이전 세션에서 결정한 내용이 중요합니다. 예를 들어 데이터 접근 방식이나 인증 규칙, 특정 오류의 원인을 다음 세션에서도 유지해야 합니다.

Agent Memory는 코딩 세션과 작업 결정, 해결 방법 등을 저장하고 나중에 검색할 수 있도록 지원합니다. 저장소는 기억 저장소를 활용하는 방법과 에이전트 연동 기능을 안내합니다.

프롬프트 예제: 작업 시작 전에 기존 맥락 확인하기

새 작업을 시작하기 전에 현재 프로젝트와 관련된 이전 작업 기록을 확인해 줘.

확인할 항목:
1. 이전에 결정한 설계 원칙
2. 관련 기능의 구현 상태
3. 이전 작업에서 해결한 오류
4. 아직 해결하지 못한 문제
5. 이번 요청과 충돌할 수 있는 기존 결정

작업 규칙:
- 기록에서 찾은 사실과 새롭게 추론한 내용을 구분한다.
- 관련 기록이 없으면 기억하고 있다고 가정하지 않는다.
- 오래된 기록이 현재 코드와 일치하는지 확인한다.
- 중요한 충돌이 있으면 코드 수정 전에 알려 준다.

확인 결과를 요약한 뒤 구현 계획을 제시해 줘.

프롬프트 예제: 세션 종료 시 작업 인계 정보 만들기

현재 작업을 정리해 다음 세션에서 이어서 진행할 수 있도록 인계 정보를 작성해 줘.

포함할 내용:
- 이번 작업의 목표
- 실제 변경한 파일과 변경 사항
- 실행한 테스트와 결과
- 아직 해결하지 못한 문제
- 검토가 필요한 설계 결정
- 다음 작업에서 수행할 단계

주의사항:
- 실행하지 않은 테스트를 완료로 기록하지 않는다.
- 계획한 작업과 실제 완료한 작업을 구분한다.
- 민감한 정보와 비밀 키는 기록하지 않는다.
- 지원되는 기억 저장 기능이 있다면 저장 여부를 확인한다.
- 저장 기능을 사용할 수 없다면 인계 내용을 문서로 제공한다.

이 프롬프트는 이전 기록을 무조건 신뢰하지 않도록 지시합니다. 기억 저장소에 남은 정보가 현재 코드와 다를 수 있으므로, 중요한 결정은 실제 프로젝트 파일과 비교해야 합니다.

실무 적용 시 주의할 점

프롬프트에 기억을 요청했다고 해서 해당 내용이 자동으로 영구 저장되는 것은 아닙니다. 실제 저장 기능이 연결되어 있는지, 어떤 방식으로 기록이 생성되는지, 이후 검색할 수 있는지 확인해야 합니다.

API 키나 비밀번호, 개인 정보와 같은 민감한 데이터는 기억 저장소에 남기지 않는 것이 좋습니다. Agent Memory의 저장 위치와 보존 정책, 데이터 삭제 방법도 도입 전에 검토해야 합니다.

6. Superpowers: 설계부터 테스트까지 단계별로 진행하는 프롬프트

영상 타임스탬프: 09:28

GitHub 저장소: obra/superpowers

복잡한 기능을 한 번의 요청으로 구현하게 하면 요구사항 확인, 설계 검토, 테스트가 충분히 이루어지지 않을 수 있습니다. Superpowers는 브레인스토밍, 구현 계획, 테스트 주도 개발, 디버깅, 코드 리뷰 등 개발 절차를 지원하는 스킬 모음입니다.

이 접근법을 프롬프트에 적용할 때는 모든 과정을 한꺼번에 진행하라고 요청하기보다, 각 단계의 결과를 확인한 다음 다음 단계로 넘어가도록 구성할 수 있습니다.

프롬프트 예제: 구현 전에 계획부터 검토하기

기존 게시판에 검색과 페이징 기능을 추가하려고 한다.

이번 단계에서는 코드를 수정하지 말고 분석과 구현 계획만 작성해 줘.

확인할 항목:
1. 기존 검색과 페이징 처리 방식
2. 관련 컨트롤러, 서비스, 데이터 접근 코드
3. 현재 테스트와 코딩 규칙
4. 검색 조건과 정렬 규칙
5. 페이지 번호와 페이지 크기 처리
6. 빈 결과와 잘못된 입력에 대한 동작

계획에는 다음 내용을 포함한다.
- 변경이 필요한 파일과 이유
- 작업 순서
- 각 단계의 완료 조건
- 필요한 테스트
- 예상되는 위험과 확인할 사항

불명확한 요구사항은 임의로 결정하지 말고 질문한다.
계획을 제시한 뒤 구현을 시작하지 말고 검토를 기다린다.

이 프롬프트는 설계 검토와 구현을 분리합니다. 요구사항이 충분히 정리되지 않은 상태에서 코드부터 수정하는 일을 줄이려는 목적입니다.

프롬프트 예제: 승인된 계획에 따라 구현하기

앞서 검토한 구현 계획을 기준으로 작업을 진행해 줘.

작업 원칙:
1. 승인된 계획의 범위를 유지한다.
2. 구현 전에 필요한 테스트와 기존 테스트를 확인한다.
3. 테스트 주도 개발이 적합한 부분은 실패하는 테스트부터 작성한다.
4. 작은 단위로 구현하고 변경 사항을 확인한다.
5. 계획과 다른 변경이 필요하면 이유를 설명한다.
6. 테스트를 실행할 수 없는 경우 그 원인을 보고한다.

작업 완료 시 다음을 보고한다.
- 변경한 파일
- 주요 구현 내용
- 실행한 테스트와 결과
- 남아 있는 문제
- 추가 확인이 필요한 사항

테스트 주도 개발은 모든 작업에 반드시 적용해야 하는 규칙은 아닙니다. 기존 테스트 구조와 작업 성격을 고려해 적합한 방식으로 선택해야 합니다.

결과 검증 방법

구현 결과가 계획과 일치하는지 확인하고, 검색어 입력, 결과가 없는 경우, 페이지 이동, 정렬 조건 변경 등 요구사항에 해당하는 시나리오를 테스트합니다.

복잡한 기능일수록 작업을 작은 단위로 나누고 각 단계의 완료 조건을 명시하는 것이 중요합니다. 다만 단순한 수정까지 모든 단계를 거칠 필요는 없습니다.

7. Skill Creator: 반복 가능한 프롬프트를 전용 스킬로 만들기

영상 타임스탬프: 11:19

GitHub 저장소: anthropics/skills

같은 종류의 작업을 반복하다 보면 매번 프롬프트를 새로 작성하는 일이 번거로워집니다. 이때 반복 작업의 목적과 절차, 출력 형식을 스킬로 정리하면 재사용할 수 있습니다.

Anthropic의 저장소에는 스킬을 작성하는 예제와 Skill Creator가 포함되어 있습니다. 공식 지침은 스킬의 목적을 정의하고, 초안을 작성한 다음, 테스트 프롬프트를 실행해 결과를 평가하고 개선하는 흐름을 안내합니다.

스킬을 만들기 전에 정할 사항

  • 어떤 작업을 해결할 것인가?
  • 어떤 요청에서 스킬을 사용해야 하는가?
  • 필요한 입력과 출력 형식은 무엇인가?
  • 정상적으로 동작했다고 판단할 기준은 무엇인가?
  • 실제 사례로 결과를 평가할 수 있는가?

프롬프트 예제: 전용 스킬 설계하기

우리 프로젝트에서 반복 사용하는 작업을 전용 스킬로 만들고 싶다.

대상 작업:
기존 ASP.NET Core 프로젝트의 코드 변경 검토

먼저 다음 항목을 정리해 줘.
1. 스킬이 해결해야 하는 문제
2. 스킬이 적용되어야 하는 요청 유형
3. 필요한 입력 정보
4. 수행할 작업 순서
5. 출력 형식
6. 예외 상황과 안전 제약
7. 정상 동작을 확인할 테스트 사례

스킬 작성 원칙:
- 프로젝트의 실제 규칙을 우선한다.
- 요청하지 않은 코드 변경을 유도하지 않는다.
- 실행하지 않은 검증을 완료했다고 표현하지 않는다.
- 민감한 정보를 출력하거나 저장하지 않는다.
- 확인되지 않은 기능을 지원한다고 가정하지 않는다.

먼저 설계 초안을 제시하고, 부족한 요구사항이 있다면 질문한다.
설계를 검토한 뒤 스킬 파일을 작성한다.

프롬프트 예제: 스킬의 품질 평가하기

작성한 스킬을 실제 사용 사례로 평가해 줘.

테스트 사례를 다음 유형으로 구성한다.
1. 일반적인 정상 입력
2. 요구사항이 모호한 입력
3. 서로 충돌하는 제약 조건
4. 스킬의 적용 대상이 아닌 요청
5. 입력 정보가 부족한 상황

각 테스트에서 확인할 항목:
- 스킬이 적절한 상황에서 적용되는가?
- 필요한 확인 질문을 하는가?
- 출력 형식과 제약을 준수하는가?
- 근거 없는 내용을 추가하지 않는가?
- 기대 결과와 실제 결과가 어떻게 다른가?

실행하지 않은 테스트는 실행 결과로 보고하지 않는다.
평가 결과를 바탕으로 수정이 필요한 지침과 테스트 사례를 제안한다.

이 방식은 작성한 스킬이 실제 요청에서도 의도대로 작동하는지 확인하기 위한 것입니다. 스킬의 설명과 실행 조건이 너무 넓거나 모호하면 의도하지 않은 요청에서 활성화될 수 있으므로 테스트를 통해 확인해야 합니다.

8. 프롬프트를 작성한 뒤 결과를 검증하는 방법

프롬프트가 구체적이라고 해서 결과까지 자동으로 정확해지는 것은 아닙니다. 프롬프트의 품질과 결과의 품질은 구분해서 확인해야 합니다.

다음 체크리스트는 앞서 살펴본 여섯 가지 스킬을 실제 개발 작업에 적용할 때 사용할 수 있는 검토 기준입니다.

프롬프트 검증 체크리스트

  • □ 요청한 목표와 완료 조건이 명확한가?
  • □ 수정할 범위와 수정하지 않을 범위를 구분했는가?
  • □ 불확실한 가정을 임의로 확정하지 않도록 지시했는가?
  • □ 결과물의 형식과 필요한 정보를 지정했는가?
  • □ 테스트와 검증 방법을 정의했는가?
  • □ 실행한 결과와 추정한 결과를 구분하도록 했는가?
  • □ 민감한 정보의 저장과 전송을 고려했는가?
  • □ 결과가 원래 요구사항과 일치하는지 확인했는가?

같은 작업으로 프롬프트를 비교하는 방법

프롬프트의 효과를 직접 비교하려면 동일한 프로젝트 상태와 동일한 작업을 기준으로 평가해야 합니다. 한 번의 실행만으로 결론을 내리기보다는 여러 사례에서 결과가 일관되는지 확인하는 것이 좋습니다.

  1. 평가할 작업을 하나 선정합니다.
  2. 기본 프롬프트와 개선한 프롬프트를 각각 준비합니다.
  3. 가능하면 동일한 초기 코드와 환경에서 실행합니다.
  4. 변경 파일 수, 요구사항 충족 여부, 테스트 결과, 불필요한 변경을 비교합니다.
  5. 각 결과의 차이를 기록하고 프롬프트를 수정합니다.

이때 변경 파일 수가 적다고 무조건 좋은 결과는 아닙니다. 필요한 구현을 빠뜨렸다면 변경 범위가 작더라도 실패한 결과입니다. 요구사항 충족 여부와 테스트 결과를 함께 평가해야 합니다.

실측 관련 참고: 위 절차는 결과를 직접 측정하기 위한 평가 방법입니다. 이 글에서는 해당 실험을 실행하지 않았으므로 개선율이나 작업 시간 단축 수치를 제시하지 않습니다.

9. 어떤 스킬부터 활용하면 좋을까?

현재 겪는 문제 먼저 검토할 스킬 프롬프트의 핵심
요청 범위를 벗어난 코드 수정 Karpathy Guidelines 최소 범위 수정과 완료 조건
동영상에서 설정 정보 추출 Claude Video 타임스탬프와 근거 구분
한국어 문장의 번역투와 반복 Humanizer 의미 보존과 문체 개선
이전 작업 내용을 다시 설명해야 함 Agent Memory 기억 검색과 작업 인계
복잡한 기능 개발 과정이 불안정함 Superpowers 계획 승인과 단계별 검증
같은 작업을 반복해서 요청함 Skill Creator 스킬 정의와 테스트 평가

모든 스킬을 설치할 필요는 없습니다. 현재 문제가 코드 변경 범위에 있다면 Karpathy Guidelines부터 살펴보고, 복잡한 기능 개발이 문제라면 Superpowers의 작업 흐름을 검토하는 식으로 시작하면 됩니다.

10. 자주 묻는 질문

Q1. 프롬프트는 길수록 좋은가요?

그렇지 않습니다. 중요한 것은 작업 목표와 제약, 완료 조건이 명확한지 여부입니다. 단순한 요청은 짧게 작성하고, 여러 파일과 계층을 수정하는 작업에는 필요한 맥락과 검증 기준을 추가하는 편이 좋습니다.

Q2. 프롬프트와 스킬은 어떻게 다른가요?

프롬프트는 특정 작업에 대한 요청과 지시입니다. 스킬은 반복해서 사용할 작업 지침과 관련 자료를 구조화한 것입니다. 자주 사용하는 프롬프트가 있다면 스킬로 정리하는 방법을 고려할 수 있습니다.

Q3. 스킬을 설치하면 프롬프트를 작성할 필요가 없나요?

그렇지 않습니다. 스킬은 정해진 작업 방식을 재사용하도록 돕지만, 실제 작업의 목표와 제약은 여전히 중요합니다. 필요한 맥락을 전달하고 결과를 확인하는 과정은 유지해야 합니다.

Q4. Humanizer로 윤문하면 기술적 오류도 해결되나요?

문장 표현을 다듬는 작업과 기술적 사실을 검증하는 작업은 다릅니다. 윤문 후에는 코드, 버전, URL, 수치와 인과관계가 원문과 일치하는지 별도로 확인해야 합니다.

Q5. 프롬프트 개선 효과는 어떻게 확인하나요?

동일한 작업과 초기 조건을 기준으로 결과를 비교하고, 요구사항 충족 여부와 테스트 결과, 불필요한 변경, 수정에 필요한 후속 작업을 기록합니다. 실제로 실행하지 않은 비교 결과를 개선 효과로 제시해서는 안 됩니다.

마무리

AI 코딩 에이전트의 결과를 개선하려면 프롬프트에 지시를 더 많이 넣는 것보다 작업 목표와 범위, 검증 기준을 명확하게 전달하는 것이 중요합니다.

Karpathy Guidelines는 코드 변경 원칙을 정리할 때, Claude Video는 동영상에서 필요한 정보를 추출할 때, Humanizer는 한국어 문서를 다듬을 때 활용할 수 있습니다. Agent Memory는 작업 맥락을 이어가는 데 도움이 되고, Superpowers는 복잡한 개발 절차를 나누는 데 활용할 수 있습니다. 반복 작업을 표준화하려면 Skill Creator를 참고해 전용 스킬을 만들고 평가할 수 있습니다.

처음부터 모든 스킬을 도입하기보다는 현재 프로젝트에서 반복되는 문제 하나를 선택해 프롬프트를 개선해 보세요. 같은 조건에서 결과를 비교하고, 실제로 효과가 확인된 지침만 프로젝트 공통 규칙이나 전용 스킬로 정리하면 됩니다.

참고 자료

업데이트 및 면책: 2026년 10월 28일 기준으로 공개 GitHub 문서를 확인했습니다. 저장소의 기능과 설치 방법은 변경될 수 있으므로 실제 사용 전 최신 README와 라이선스, 의존성, 보안 안내를 확인하세요. 이 글의 프롬프트는 활용 예제이며, 실제 IDE에서 실행한 결과나 성능 비교를 의미하지 않습니다.

#AI프롬프트 #프롬프트엔지니어링 #AgentSkills #KarpathyGuidelines #ClaudeVideo #Humanizer #AgentMemory #Superpowers #SkillCreator #ASP.NETCore #AI코딩 #개발자동화

댓글

이 블로그의 인기 게시물

ChatGpt 의 유료결제 영수증 및 청구서 다운로드

ChatGpt 의 유료결제 영수증 및 청구서 다운로드   https://chatgpt.com/  사이트에 접속하며 회원가입을 합니다.   ChatGpt 유료 결제를 위해서는 왼쪽 하단에 있는 " Team 워크스페이스 추가 "를 선택합니다.   https://chatgpt.com/     ChatGPT의 요금제는 세 가지로 나뉩니다:  Free ,  Plus , 그리고  Custom Plan (기업용 요금제). 각 요금제의 특징과 차이점은 다음과 같습니다. 1.  Free Plan (무료 플랜) 사용 모델:  GPT-3.5 제공 기능:  기본적인 질문 응답, 텍스트 생성 접속 가능성:  트래픽이 많을 때는 사용이 제한될 수 있으며, 응답 속도가 느릴 수 있습니다. 제한 사항:  최신 모델이나 고급 기능을 사용할 수 없고, 성능이나 속도 면에서 제한이 있습니다. 2.  Plus Plan (플러스 플랜) 월 요금:  $20 사용 모델:  GPT-4 장점:  더 빠른 응답 속도, 트래픽이 많을 때도 안정적인 접속 가능 차이점:  GPT-4의 향상된 성능으로 더 복잡한 질문이나 고급 작업에도 우수한 결과를 제공합니다. 접속 가능성:  트래픽이 많아도 안정적이며, 더 나은 응답 속도를 제공합니다. 3.  Custom Plan (맞춤형 플랜) 대상:  대규모 기업 또는 특정 요구사항이 있는 고객 요금:  고객의 요구에 따라 맞춤 설정 특징:  기업 맞춤형 기능과 성능을 제공하며, 보안, 데이터 정책, API 액세스와 같은 맞춤형 옵션을 포함할 수 있습니다. 차이점:  대규모 기업에 특화된 기능으로, 추가 지원과 고급 기능 제공이 가능합니다. 주요 차이점 모델 사용:  Free는 GPT-3.5,...

인천국제공항 제1여객터미널에서 일본으로 가는 출국 절차 안내 ✈️

인천공항 제1여객터미널 출국 절차 가이드 (탑승동 이동 및 셔틀트레인 완벽 정리) 공항 도착부터 체크인, 보안검색, 출국심사, 그리고 셔틀트레인을 타고 탑승동으로 이동하는 전체 출국 단계를 빠짐없이 안내합니다. 1. 공항 도착 시간 항공기 출발 3시간 전 제1여객터미널 3층 출국장 도착 권장 2. 탑승구 확인 101~132번 게이트는 셔틀트레인을 타고 탑승동 으로 이동 필수 3. 되돌아오기 불가 셔틀트레인은 편도 이동만 가능하므로 본동 면세품 인도 후 탑승 Step 1. 공항 도착 및 체크인 (3층 일반지역) 항공기 출발 3시간 전 공항 3층 출국장에 도착하는 것을 권장합니다. 셀프 체크인 & 자동 수하물 위탁(Self Bag-Drop): 키오스크에서 모바일·지류 탑승권을 발급받고 전용 카운터를 이용하면 대기시간을 크게 단축할 수 있습니다. 유인 카운터: 여권과 항공권(e-티켓)을 제시하여 좌석 배정 및 위탁 수하물을 처리합니다. Step 2. 출국 전 사전 준비 (환전 및 통신) 환전 수령: 사전 신청한 외화를 3층 또는 지하 1층 환전소·은행 영업점에서 수령합니다. 로밍 및 통신: 통신사 부스에서 데이터 로밍 확인 또는 신청한 USIM/eSIM/와이파이 단말기를 수령합니다. 기타 편의시설: 외투 보관 서비스, 약국, 여행자 보험 창구 이용은 보안검색장 진입 전 일반지역에서 마쳐야 합니다. Step 3. 출국장 진입 및 보안 검색 3층 출국장 게이트(2~5번)로 이동하여 탑승권과 여권을 확인받고 보안검색대로 이동합니다. 주의 (액체류 규정 안내) 기내 반입 액체류는 개별 용기당 100ml 이하, 1인당 총 1L 투명...

엑셀·워드와 호환되는 최신 WYSIWYG 웹 에디터 강추

최신 자료를 기반으로 엑셀과 워드 호환이 잘 되는 상위 10개의 WYSIWYG 웹에디터를 조사하겠습니다. 이 목록은 사용량, 기능, 개발자 선호도를 고려하여 선정되며, 각 웹에디터의 공식 웹사이트 링크도 함께 제공해드리겠습니다.  엑셀·워드와 호환되는 최신 WYSIWYG 웹 에디터 10선 1.  CKEditor 5 오픈 소스 기반의  CKEditor 5 는 높은 완성도의 WYSIWYG 웹 에디터로, Drupal 등 주요 CMS에서 기본 에디터로採용될 정도로 널리 쓰입니다 ( Drupal and CKEditor: a history of advanced content editing | CKEditor | CKEditor ). 풍부한 플러그인과 커스터마이징 기능을 제공하며,  Microsoft Word  문서를 댓글이나 변경 추적 내용까지 포함하여 불러오는 고급 호환 기능도 갖추고 있습니다 ( Wysiwyg Editors Statistics 2025 ). 또한 별도 플러그인을 통해 편집한 내용을 바로  .docx  워드 파일로 내보낼 수 있어 워드 호환성이 뛰어납니다 ( Export to Word | CKEditor 5 Documentation ). 개발자들은 CKEditor 5의 모듈식 설계와 활발한 커뮤니티 지원을 선호하며, 기업용 협업 편집 기능 등의 프리미엄 옵션도 제공됩니다. 2.  TinyMCE TinyMCE 는 오랜 역사와 함께 가장 널리 사용되는 웹 에디터 중 하나로, WordPress에서는 수년간 기본 편집기로採用되어 왔습니다. Joomla, Umbraco, Shopify 등 수많은 CMS에 내장되어 있으며, 전 세계 웹 콘텐츠의 약 40%가 TinyMCE로 작성·출판되고 있다고 합니다 ( Configure TinyMCE for your CMS to rival Wix and WordPress | TinyMCE ). 기본 기능만으로도 강력하지만,...