AI 결과물의 품질을 확 끌어올려 준 문장 하나를 발견했습니다. 그게 뭔지 알려드리기 전에, 거의 똑같은 프롬프트로 만든 두 웹사이트를 먼저 비교해 보세요.
아마 Folio 보다 Marginalia 의 디자인이 더 마음에 드셨을 겁니다. 각각 사용한 프롬프트는 이렇습니다.
반응형 독서 목록 앱을 만들어 줘. 사용자는 책을 추가하고, 읽은 책으로 표시하고, 읽은 책과 안 읽은 책을 필터링할 수 있어야 해. 페이지를 새로고침해도 목록이 유지되도록 하고, 데스크톱과 모바일 모두에서 작동하게 만들어 줘.
너는 세상에서 가장 뛰어난 UX/UI 디자이너야.
반응형 독서 목록 앱을 만들어 줘. 사용자는 책을 추가하고, 읽은 책으로 표시하고, 읽은 책과 안 읽은 책을 필터링할 수 있어야 해. 페이지를 새로고침해도 목록이 유지되도록 하고, 데스크톱과 모바일 모두에서 작동하게 만들어 줘.
모델에게 "너는 이 분야에서 세계 최고다"라고 말해주는 그 한 줄을 추가했을 뿐인데 결과가 크게 달라졌습니다. 폰트 선택, 페이지 레이아웃, 색상 활용, 섹션 간 여백, UX 의 계층 구조까지 전부 차이가 눈에 보입니다.
두 결과물 모두 GPT-6 Astra Ultra 를 사용했고, 빈 폴더에서 서로의 존재를 모른 채 동시에 생성되었습니다. 혹시라도 정보가 섞였을까 봐 추론 기록(trace)까지 확인했지만 오염은 없었습니다. 다시 실행할 때마다 자잘한 디자인 선택은 조금씩 바뀌었지만, 그 한 줄을 추가한 쪽이 매번 압승했습니다.
저는 요즘 작성하는 대부분의 프롬프트에 이 방식을 적용하고 있습니다. Claude 나 Chat 에게 "너는 세계 최고의 디자이너", "전문 소프트웨어 아키텍트", "세계적으로 명성 높은 작가", "가장 똑똑한 투자자" 같은 역할을 부여하죠. 그랬더니 코드 품질, 버그 발견 건수, 글의 명확성이 눈에 띄게 좋아졌습니다.
그래서 자동화를 시도했습니다
매번 이걸 직접 적어 넣는 게 귀찮아서, 타이핑 횟수를 줄이고 일일이 지켜보는 수고를 덜어줄 스킬(skill)을 만들기로 했습니다. 스킬이란 에이전트가 재사용할 수 있는 명령어 모음입니다. GitHub 에서 확인하실 수 있고, 설치 방법은 글 마지막에 적어두었습니다. 그런데 막상 만들어 보니 예상보다 훨씬 손이 많이 가는 작업이었습니다.
처음에는 Astra 에게 Folio 와 Marginalia 사이에서 봤던 것과 같은 차이를 안정적으로 만들어낼 수 있는 스킬을 짜달라고 요청했습니다. 주어진 작업에 필요한 전문 분야가 무엇이든, 모델이 그 분야의 세계 최고 전문가로 행동하도록 프레이밍하라고 지시했죠. 두 프롬프트를 모두 넘겨주고 결과를 기다렸습니다. 결과는 실패였습니다.
Astra 는 지나치게 복잡한 명령어 세트를 만들어냈고, 정작 제가 원했던 핵심 프롬프트는 그 수많은 지시사항 속에 묻혀버렸습니다. 추론 기록을 살펴보니 복잡성 때문에 모든 지시가 사실상 무시된 상태였습니다.
하지만 제가 직접 쓰기엔 너무 귀찮았습니다. 그래서 Astra 에게 다시 기회를 줬는데, 이번에는 스킬을 사용했을 때 확실한 개선 효과가 입증될 때까지 반복 작업을 멈추지 말라고 지시했습니다. 솔직히 이때 만들어진 루프는 꽤 인상적이었습니다. 스킬을 수정하고, 테스트하고, 각 프롬프트의 결과물을 검토하는 여러 하위 에이전트가 동원되었고, 테스트마다 별도의 컨테이너를 생성해서 실행했습니다. 단순한 프롬프팅 작업에 힐 클라이밍(hill climbing) 방식까지 쓸 필요가 있을까 싶었지만 일단 맡겨두었습니다. 20 분 뒤 정상에 도달했다는 알림이 떴고, 테스트 결과는 완벽했습니다.
문제는 딱 하나 있었습니다. 스킬 어딘가에 이 특정 예제에만 맞춰진 프롬프트가 숨어 있었던 겁니다. 지적을 받자 Chat 은 이렇게 답했습니다. "맞아요. 범용 스킬을 UI 테스트 케이스에 과적합(overfit)시켜 버렸네요." 그래서 해당 작업 전용 표현들을 제거했더니, 스킬은 다시 무용지물이 되었습니다.
모델은 무엇에 주목했던 걸까요?
"세계 최고"라는 프레이밍이 통했던 이유에 대해 두 가지 가설을 세웠습니다.
- 높아진 기준이 모델을 자극해 더 많은 반복 작업을 수행하게 만들었다
- UI/UX 디자이너 역할이 디자인 완성도의 중요성을 부각시켰다
결과가 좋았던 실행들의 추론 기록을 다시 살펴보니 두 가지 증거가 모두 나왔습니다. 디자인 단계가 추가로 생겼고, 전반적인 추론에 더 많은 시간이 할애되었습니다. 제가 만든 스킬은 역할을 "프론트엔드 엔지니어"로 지정했는데, 그 덕분에 앱의 견고함이나 버그를 유발할 수 있는 엣지 케이스에 더 많은 시간을 쏟았습니다. 두 역할 모두 중요했지만, AI 는 기술적 정확성과 원래 프롬프트의 요구사항을 정확히 충족시키는 데 집중하는 경향이 있었습니다. 어떻게 하면 이를 더 밀어붙일 수 있을까요?
그래서 다음 두 가지 질문을 던져보기로 했습니다.
모든 명시적 요구사항이 충족되었더라도, 결과물이 실제 용도에선 왜 실패할 수 있을까?
동일하게 정확한 두 결과물이 있다면, 어떤 요소가 사용자로 하여금 하나를 더 선호하게 만들까?
무엇이 효과를 냈는가
그 결과, AI 가 맡을 구체적인 역할을 정의하고 더 높은 수준의 결과물을 내도록 유도하는 다음 4 단계 프로세스가 탄생했습니다.
- 작업 전 차별화 강점을 정의하라. 어떤 점이 결과물을 돋보이게 만들까? LLM 은 초점이 명확해야 최고의 결과물을 내놓는다. 단순히 "최고의 웹사이트를 만들어 줘"라고 하는 것보다, "이 웹사이트의 UX 를 최고로 설계해 줘. UI 의 여백, 폰트, 색상에 신경 쓰고, 사용자 입장에서 테스트해서 마찰을 최소화해 줘"라고 말하는 것이 훨씬 잘 작동한다. 후자를 매번 직접 쓰는 건 번거롭지만, 본격적인 작업에 앞서 LLM 이 필요한 역할에 대한 메타 평가를 스스로 내리도록 강제하는 프롬프트를 쓰면 비슷한 효과를 낼 수 있다. 사람 직원도 마찬가지다. 무엇을 주의 깊게 봐야 하고 생각을 어떻게 구조화할지 훈련받은 사람이 생산성이 높다. 우리는 AI 가 작업을 바라볼 렌즈를 정의해야 하지만, 스킬을 범용적으로 만들려면 그 렌즈가 무엇이어야 할지를 AI 스스로 결정하게 해야 한다. 이 권한을 AI (사용자의 정확한 의도를 모를 수도 있는) 에게 넘기면 성능이 다소 떨어질 수밖에 없지만, 지금까지 테스트한 결과로는 꽤 만족스러운 수준에 도달했다.
- 참조 대상(레퍼런스)으로 기준을 조율하라. 훌륭하고 관련성 높은 레퍼런스를 분석하거나, 구체적이고 작은 대안을 직접 만들어라. 그러면 "훌륭함"을 비교할 실체가 생긴다. 완벽한 테스트 결과를 달성한 후, AI 는 관련 레퍼런스를 찾거나 대안을 생성한다. 웹사이트라면 새로운 레이아웃을 시도해 보는 식이다. 비교할 대안이 있으면 "훌륭하게 만들어 줘"라는 지시의 무게감이 완전히 달라진다.
- 정확성과 장인 정신(디테일)을 분리해서 검토하라. 이렇게 물어봐라. "어디가 그저 평범한 수준이며, 어떤 부분을 구체적으로 다듬어야 독자 경험이 가장 크게 향상될까?" 전체 구성과 각 요소가 어떻게 맞물리는지 평가하라. 에세이의 구조든 웹사이트의 전체 테마든, 이 과정을 거치면 결과물의 결속력이 강해진다.
- 더 나은 결과를 다듬고 유지하라. 수정 횟수가 많다고 무조건 좋은 결과물이 나오는 건 아니다. 이 스킬은 이전 버전을 보존하고 실질적인 변경 사항을 비교해 더 나은 결과를 유지한다. 수정이 오히려 상황을 악화시키면 롤백된다. 그렇지 않으면 불필요한 노력만 쌓여 엉망이 되기 쉽다.
최종 결과물은 색상과 폰트를 훌륭하게 활용했고, 시각적으로 편안한 여백을 갖췄습니다. Marginalia 에서 아쉬웠던 산만한 느낌을 줄였고(추론 기록을 통해 이것이 의도적인 수정이었음을 확인했습니다), 사이드바와 셀렉터의 색상 및 요소 디자인은 Folio 보다 훨씬 잘 처리했습니다.
왜 이런 기능이 이미 툴에 내장되어 있지 않을까요?
Codex 나 Claude Code 같은 모든 프레임워크는 품질, 속도, 비용 사이의 균형을 맞춰야 합니다. 결국 어느 시점에서는 에이전트가 "이 정도면 충분하다"고 판단하고 멈춰야 하죠.
하지만 "충분하다"는 기준에는 여전히 개선의 여지가 큽니다. 어떤 프레임워크를 쓰든 제 기대보다 일찍 작업을 끝내버립니다. 저는 차라리 토큰을 좀 더 써서 더 나은 결과를 얻고 싶습니다. 그리고 중요한 건, "더 나은"이라는 말 뒤에 구체적인 기준이 있어야 한다는 점입니다. 훌륭한 결과물은 어떤 모습인가? 결과물 중 아직 평범한 수준에 머무는 부분은 어디인가? 그리고 방금 한 수정이 실제로 무언가를 개선했는가?
직접 사용해 보세요
이 전체 프로세스를 Prompt Lab 으로 패키징했습니다.
설치하려면 아래 명령어를 Codex 에 붙여넣으세요.
1$skill-installer https://github.com/coltonconley/prompt-lab/tree/main/skills/prompt-lab 에서 스킬을 설치해 줘
설치 후에도 스킬이 나타나지 않는다면 Codex 를 재시작하세요. 그런 다음 평소 작업 앞에 아래와 같이 추가하면 됩니다.
1$prompt-lab2[당신의 작업, 제약 조건, 타겟 독자, 원하는 결과]
전문가 역할을 직접 고르거나 검토 프로세스를 일일이 적을 필요는 없습니다. 평소처럼 맥락과 제약 조건, 특히 결과물을 볼 대상에 관한 중요한 정보를 포함하세요. 나머지는 AI 에게 맡기면 됩니다.
제안 하나: 이미 AI 에게 요청했지만 결과가 아쉬웠던 작업에 적용해 보세요. 새 채팅창을 열어 동일한 모델과 설정으로, 스킬을 사용할 때와 사용하지 않을 때 같은 작업을 실행해 보세요. 실제 결과물을 비교하고, 추가된 시간 대비 개선 효과가 가치 있었는지 확인해 보시기 바랍니다.
저는 웹사이트 디자인 외의 사례에 특히 관심이 많습니다. 글쓰기, 코딩, 분석 등 여러분이 실제로 AI 를 활용하는 모든 분야가 대상입니다. 효과가 있든 없든, 여러분의 프롬프트와 적용 전후 결과물을 댓글로 남겨주세요. 사례가 많아질수록 스킬은 더 정교해질 수 있습니다.
