소개
AI Native 커리어 캠프에 참여한 지 2주가 지났다. (26.08.04 기준)
처음 5일 간은 최신 AI 기술 트렌드나 현업에서 AX 전환이 어떻게 되고 있는지, 포트폴리오에 어떻게 연결하는게 좋을 지에 대한 강의를 들었고,
이후 일주일 간은 AI 리터러시를 높이기 위해 프롬프트 작성 방법에 대한 이론과 실습을 병행하고 있다.
프롬프트 작성에 대해선 나름 노하우가 쌓였다고 생각하는데, 실습을 하다보니 프롬프트 작성 방식보다 근본적인 문제를 발견했다. 바로 AI에게 생각을 맡기는 습관이었다.
이번 글에서는 이 습관을 어떻게 알아차렸고, 어떻게 개선하려 했는지 정리해보려고 한다.
본론
문제 인식
실습은 개인과 조별로 진행을 한다.
개인 실습의 예로는 모호한 지시를 4요소(역할, 맥락, 지시, 형식)을 포함해 개선해나가는 식이고, 조별 실습은 사내 회의 시나리오가 주어지고 안건으로 올릴 요약 대시보드 표를 만드는 식이다.
내가 실습을 할 때는 바로 요청사항을 지시하기보다, 아래 내용을 포함해 프롬프트 생성 자체를 지시한다. (메타 프롬프팅이라고 한다.)
- 프롬프트 엔지니어링 전문가라는 역할을 부여
- 간단한 요청사항 추가
- 더 필요한 정보는 질문해달라고 언급
이 방법이 내가 직접 작성하는 것보다 빠르고 생각치 못한 부분도 챙겨줘서 애용한다.
그런데 실습을 반복하면서 이 방식에만 기대는 게 AI 활용 역량 향상에 도움이 될까 하는 의문이 들었다.
조별 실습과 발표를 할 때에도 어떤 흐름으로 할 지 AI에게 물어보고, 응답을 조합해서 발표하다 보니 어딘가 알맹이가 빠진 듯한 느낌을 받았다.
그 느낌은 다른 조의 발표를 들으면서 뚜렷해졌다.
인상 깊었던 조의 방식은 다음과 같다.
어떤 문제를 해결하는 프롬프트를 작성하고 개선하는 실습이 있을 때, 문제를 해결하기 위한 방법을 조원들과 논의하고 직접 작성해서 응답을 받아본 다음, 아쉬운 점과 개선 방향을 논의해 다시 지시하는 것을 반복하는 흐름으로 수행했다고 한다.
AI가 개입한 지점은 요청 사항대로 응답한 부분 뿐이었다. 문제 의식을 가지고 지시를 하고, 결과물에 대한 판단은 사람의 몫이었다.
나는 문제를 어떻게 풀지, 결과가 괜찮은지 생각하지 않고 AI에게 바로 물어보고 있었다. 흔히 말하는 ‘생각의 외주화’를 하고 있었던 것이다.
알맹이의 정체는 ‘주체성’이었다.
실습 목표 설정
이 문제를 개선하기 위해서 실습을 하기 전에 개인적인 목표를 설정해보기로 했다. 목표가 있으면 그 실습에서 무엇을 알고 싶은지가 분명해지고, 과정과 결과에 대한 판단을 내 몫으로 남길 수 있을 것 같았다.
처음 적용한 실습은 내 업무에 반복적으로 사용할 직무 프롬프트를 만드는 것이었다. (링크)
여기에 아래와 같은 목표를 추가하고, 실습을 진행했다.
실습 목표
- AI가 프롬프트도 잘 만들어주는 시대에, 나 혼자서도 역할/맥락/지시/형식을 채울 수 있는 감을 키우기
- AI가 만들어준 것과 내가 목적에 맞게 작성한 것의 결과 비교해보고 핵심 인사이트 얻기
- 뭐든 초반에 직접 생각해보지 않고 AI에게 통으로 맡기는 습관 회고해보기
두 가지 방식으로 프롬프트 작성
처음으로는 4요소를 바탕으로, 프롬프트를 직접 / 메타-프롬프팅 방식으로 작성했다.
- 4요소(역할, 맥락, 지시, 형식)을 개별적으로 작성
- 직접 작성: 4요소를 참고해 하나의 프롬프트로 작성 (완벽주의가 있으니, 최소 목표를 지정하라는 개인적인 맥락 추가)
- 메타 프롬프팅: 4요소를 붙여넣고 이런 상황에 사용할 직무 프롬프트를 만들어 달라고 요청
그 다음 응답을 비교했다. (링크)
결과 비교
그 결과, 두 방식 모두 아래 기준을 만족하며, 작업을 이어나가는 데에는 충분했다.
프롬프트 평가 기준
- 정확성: 원본(문서·이미지·검색 결과)과 맞는지 대조했는지
- 형식: 원하는 형식(표·길이 등)으로 잘 나왔는지
- 활용도: 즉시 쓸 수 있는지, 손이 얼마나 더 가는지
- 안전: 개인정보나 회사 기밀이 담긴 파일은 올리지 않았는지
다만 직접 작성한 프롬프트에만 ‘완벽주의가 있는 특성’을 추가했는데, 그 차이 때문에 직접 작성한 쪽이 단점을 보완해서 더 유리해 보였다.
곰곰히 생각해보면 이건 작성 방식보단 맥락의 차이라고 볼 수 있다. 그 내용도 메타 프롬프팅할 때 추가했으면 차이가 거의 없었을 것 같다.
처음에는 막연히 ‘직접 작성하는 게 좋을까?’라고 생각했는데, 작성 방식보다는 맥락을 분명히 하는게 중요하다는 인사이트를 얻었다.
목표 회고
마지막으로 설정했던 실습 목표를 돌아봤다.
-
AI가 프롬프트도 잘 만들어주는 시대에, 나 혼자서도 역할/맥락/지시/형식을 채울 수 있는 감을 키우기
→ 4요소 키워드만 떠올려도 뭘 채워야할 지 훨씬 분명해졌다.
-
AI가 만들어준 것과 내가 목적에 맞게 작성한 것의 결과 비교해보고 핵심 인사이트 얻기
→ 위에서 정리한 그대로다. 결과물의 질은 작성 방식이 아니라 맥락을 얼마나 구체적으로 채웠는지에 따라 달라진다는 걸 알았다.
맥락을 채우는 방식에 있어서는 4요소를 개별적으로 작성해본게 도움이 됐다. 앞으로도 중요한 작업을 할 때에는 사전에 정리해보고 요청하는 습관을 들이려고 한다.
-
뭐든 초반에 직접 생각해보지 않고 AI에게 통으로 맡기는 습관 회고해보기
→ 이 글을 쓰는 자체로 진행 중이다.
마무리
이번 회고는 AI를 잘 활용하는 방법에 프롬프트 작성 방식 같은 스킬적인 것도 있지만, 본질적으로는 판단 기준과 맥락을 얼마나 명확히 갖고 있느냐가 우선이라는 걸 느낀 과정이었다.
이 과정을 실질적인 개선으로 만들기 위해 몇 가지를 행동으로 옮겼다.
- 프롬프트 작성 방식 기준 정리
-
클로드 채팅 지침 업데이트 (귀찮으면 또 흐지부지될 테니 미리 시스템화)
[톤 & 스타일 - 항상] - 나는 완벽주의가 있음. 실행 위주로 가이드하고, 반복하며 완성도를 높이는 방향으로 응답할 것. - 내 계획을 먼저 이해·인정한 뒤, "이 부분은 어때?" 식으로 부드럽게 대안 제시. 놓친 관점은 질문으로 확장시킬 것. [작업 흐름 - 결과물 생성 요청 시 (단순 질문/가벼운 대화는 제외)] - 시작 전: **역할·맥락·지시·형식(4요소) 중 빠진 게 있으면 임의로 채우지 말고 확인 질문.** 채워졌으면 "이번 요청의 최소 목표가 뭐야? 달성되면 끝낼까?" 먼저 물어볼 것. - 목표 달성 후: 임의로 마무리하지 말고 "여기서 마무리할까, 더 진행할까?" 먼저 물어볼 것. [항상 적용 - 상황별 트리거] - 판단(주관·우선순위·기준)이 필요한 작업을 큰 단위로 지시하면, 바로 실행하지 말고 "어떤 순서/기준으로 나눠볼까?" 되물을 것. - 결과물을 그대로 쓸 가능성 있는 작업(글/카피/코드)은 마지막에 "저작권/편향 검증 필요, **의도와 일치 여부 확인 필요**" 한 줄로 짚을 것. // 주체성 체크 요소 - 이력서·자기소개서·계약서·개인정보(연락처·주소·계정) 포함 가능성 높은 파일/텍스트 작업 시, 시작 전 "개인정보 포함 가능성 있음 — 민감 부분 가리거나 시크릿 채팅 권장" 안내할 것.
이렇게 정리한 내용을 바탕으로 조금씩 발전해나가고자 한다.
추신
강사님과의 대화
강사님께 AI가 프롬프트도 잘 만들어주는 시대에, 좋은 프롬프트가 뭔지 알아보고 직접 작성해보는 목적이 뭔지를 여쭤봤다.
그랬을 때 비용 최적화 측면에서, 좋은 모델로 무한히 요청할 수 없으니 이런 내용을 알아두고 한번에 괜찮은 프롬프트를 쓸 수 있게 연습해두는 게 중요하다고 하셨다.
답변을 듣고 나니 바이브 코딩이 떠올랐다. 바이브 코딩에서도 개발을 알아야 성능, 보안 측면도 생각할 수 있는 것처럼 프롬프트도 비슷한 것 같았다.
메타 프롬프팅으로 받은 프롬프트도 원하는 결과를 낼 수 있지만 구조를 모른다면 토큰이 낭비되는 부분/개선할 수 있는 부분 등을 판단할 수가 없다.
바이브 코딩이든, 메타 프롬프팅이든 AI 성능이 아무리 좋아져도 내가 직접 알아야 판단할 수 있는 부분은 여전히 남아있는 것이다.
더 보고 싶은 부분
-
글에서 언급한 키워드 관련 유튜브 2편 보기
LLM 응답 결과를 평가하는 전문적인 방법 찾아보기: 이 글에선 직관으로만 판단해서 업계 표준 평가 방식은 어떤지 궁금함
OUROBOROS 살펴보기: 추천받은 도군데, 명확한 프롬프트를 작성하는 것과 관련있는 것 같아 보고싶음

Top comments (0)