What I''d Learn Instead of Prompt Engineering in 2027?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

2027년을 준비하며 프롬프트 엔지니어링 대신 배울 역량으로, 영상은 AI에 검증 가능한 목표와 맥락을 주고 결과·비용을 관리하는 ‘역할 엔지니어링’을 제안한다.

📌 핵심 요점

1. 요청 작성에서 업무 관리로: 발표자는 AI 활용의 중심이 개별 질문에 답하는 도구에서, 장시간 작업을 맡기고 진행 상황을 점검하는 상시 구성원으로 이동하고 있다고 설명한다.
2. 목표는 검증 가능해야 한다: SMART 목표 중에서도 측정 가능성을 강조한다. ‘웹사이트 개선’보다 ‘아이폰에서 홈페이지가 2초 이내에 로드되도록 개선’처럼 완료 여부를 판단할 수 있어야 한다.
3. 맥락과 좋은 결과물의 예시를 제공한다: 지식베이스로 업무 배경을 전달하고, 직접 만든 우수 사례와 피해야 할 실수를 알려줘야 AI가 기대 수준을 이해할 수 있다는 주장이다.
4. 반복 평가를 표준 절차로 남긴다: 같은 업무를 5~10회 수행하게 한 뒤 결과의 공통 문제를 찾아 피드백하고, 개선 사항을 SOP로 문서화해 다른 에이전트에도 재사용한다.
5. 성능만큼 비용을 관리한다: 업무 난도에 맞는 모델 선택, 프롬프트 캐싱, 배치 처리와 청구액 점검을 제안한다. 새 모델은 기존 업무 목록으로 비교해 품질과 비용을 함께 평가한다.

🧩 배경과 문제 정의

영상은 ‘2027년에 프롬프트 엔지니어링 대신 무엇을 배울 것인가’라는 질문에, AI를 관리하는 역량을 답으로 제시한다. 발표자는 최근 AI가 매번 질문을 받는 도구에서 장시간 업무를 수행하는 상시 구성원으로 바뀌고 있다고 보고, 이를 활용하는 방식을 ‘역할 엔지니어링’이라고 부른다.

문제는 AI에 일을 맡긴 뒤 기대한 결과가 나왔는지 어떻게 판단하고, 같은 품질을 반복하며, 늘어나는 비용을 어떻게 통제하느냐는 것이다. 영상은 직원에게 업무를 위임하는 관리 방식을 빌려 목표·맥락·모범 사례·피드백·비용 점검을 하나의 운영 과정으로 연결한다. 제시되는 성과와 비용은 발표자의 설명 및 사례이며, 별도의 검증 자료는 전사에 포함되지 않는다.

🕒 시간순 섹션별 상세정리

1. 프롬프트 작성에서 상시 AI 구성원 관리로

• Boris Cherny가 Claude Code를 주로 Slack으로 사용한다는 사례로 시작한다. 발표자는 최근 6개월의 변화를 AI 도구 사용에서 상시 구성원 운영으로 설명하고, 요청 작성보다 관리가 중요해진다는 ‘역할 엔지니어링’을 보여준다. [00:42]
• Anthropic 직원들이 Claude에 업무를 맡기고 수 주간 백그라운드에서 실행하게 하며 중간 진행을 확인한다는 사례를 든다. 이어 Anthropic에서 병합하는 코드의 80% 이상을 AI가 작성한다고 주장한다. [01:25]
• 과거에는 원하는 답을 얻기 위한 요청 문구가 핵심이었다면, 이제는 직원에게 업무 개요를 주듯 목표를 전달하는 방식이 가능해졌다는 관점을 제시한다. [01:56]

2. SMART 목표로 완료 기준을 명확히 하기

• 발표자는 Anthropic 가이드의 취지를 인용해 Claude를 조직의 규범과 업무 흐름을 아직 모르는 유능한 신입 직원처럼 대하라고 보여준다. 목표와 배경, 목표의 이유, 좋은 결과물과 피해야 할 실수를 함께 제공하라고 권한다. [02:28]
• SMART를 구체적이고, 측정 가능하며, 달성 가능하고, 관련성이 있고, 기한이 있는 목표로 풀어 보여준다. 특히 에이전트가 자신의 작업을 확인하려면 측정·검증 가능한 기준이 중요하다고 강조한다. [03:00]
• ‘웹사이트를 더 좋게 만들어 달라’는 요청과 ‘아이폰에서 홈페이지가 2초 이내에 로드되게 해 달라’는 요청을 비교해, 후자가 완료 여부를 판단하기 쉽다고 보여준다. [03:17]

3. 지식베이스와 모범 결과물로 기대 수준 전달하기

• 발표자는 이메일, 영상 전사, AI 대화, GitHub 기록 등을 포함한 5만 건 이상의 개인 기록을 지식베이스에 보관한다고 드러낸다. 매번 배경을 다시 구성하는 대신 AI가 목표와 동기를 이해할 자료에 지속적으로 접근하게 한다는 구상이다. [03:55]
• ‘잘해 달라’는 말만으로는 좋은 결과의 기준을 전달하기 어렵다고 지적한다. 사람이 적어도 한 번은 직접 수행해 모범 결과물을 만들고, AI가 비교할 수 있도록 제공하라고 권한다. [04:28]
• 직원처럼 업무를 맡기려면 지식베이스와 여러 소프트웨어 서비스에 대한 연결이 필요하다고 보여준다. 소개한 도구들이 이런 연결 설정을 배경에서 처리해 준다고 드러낸다. [05:07]

4. 장시간 실행과 여러 에이전트의 활용 사례

• Boris Cherny가 Electron 기반 Claude 데스크톱 앱을 Swift로 다시 만들도록 요청하면서, 기존 앱의 스크린샷과 새 버전을 픽셀 단위로 비교하도록 했다는 사례를 보여준다. 발표자에 따르면 작업은 2주 넘게 실행됐다. [05:32]
• Claude가 Slack 대화에 참여해 여러 도구의 데이터를 하나의 답으로 모으고, 디자인 시안을 만드는 사례를 든다. 이를 직원에게 자연스럽게 업무를 요청하는 방식과 연결한다. [05:47]
• Anthropic 연구자 Nick Carlini가 Claude 에이전트 16개와 C 컴파일러를 약 2주간 개발했다는 사례를 보여준다. 발표자는 이런 협업을 조직 구성원에게 일을 맡기는 관점으로 이해하라고 강조한다. [06:11]

5. 반복 평가를 SOP와 모델 비교 체계로 만들기

• 업무를 한 번만 맡기지 말고 5~10회 실행해 결과를 평가하라고 권한다. 여러 결과의 전반적인 수준을 살피고, 개별 작업에서 드러난 문제와 누락을 구체적인 개선 목록으로 만들어 반복 수정하게 한다. [06:58]
• 개선 절차를 문서화하면 다른 에이전트에도 전달할 수 있는 SOP가 된다고 보여준다. 발표자는 자신의 하루 약 절반을 업무 구상, 에이전트 위임, 결과 피드백에 쓴다고 드러낸다. [07:34]
• 향후 모델의 역량이 크게 개선될 것이라고 전망하면서, 반복 업무 목록을 보관해 새 모델과 기존 모델을 같은 과제로 비교하라고 제안한다. 이 방식으로 품질 향상과 비용 차이를 함께 평가할 수 있다는 설명이다. [08:16]

6. 비용 통제와 팀 운영, 마지막 홍보

• 발표자는 하루에 약 2,500달러의 토큰을 사용한 사례를 월 20일 기준 약 5만 달러로 환산하며 비용 부담을 경고한다. 정기적인 성과·비용 점검과 함께 Haiku, Sonnet, Opus 등을 업무 난도에 맞춰 배정하라고 제안한다. [09:14]
• 프롬프트 캐싱 혜택을 놓치지 않도록 사용 방식을 점검하고, 즉시 끝낼 필요가 없는 업무는 배치 API로 처리하라고 권한다. 청구액을 계속 확인하며 에이전트 수를 무작정 늘리지 말라고 강조한다. [10:15]
• 하나의 에이전트를 팀 소통 채널에 배치해 함께 사용하는 방식을 제안한다. 마지막에는 AI 사업 기회의 확대와 기회가 열려 있는 기간의 단축을 주장하며, 90일 내 첫 유료 고객 확보 또는 환불을 내세운 Maker School 프로그램을 홍보한 뒤 댓글·구독을 요청하고 마무리한다. [11:02]

🧾 결론

• 영상이 말하는 역할 엔지니어링은 목표 설정, 업무 맥락 제공, 모범 결과물 제시, 반복 피드백을 AI 업무에 적용하는 관리 방식이다.
• 좋은 결과를 반복해서 얻으려면 사람이 먼저 품질 기준을 정하고, 결과를 평가해 재사용 가능한 절차로 정리해야 한다.
• 장시간 자율 실행 사례는 가능성을 보여주지만, 영상의 일화만으로 모든 업무에서 같은 성과를 기대할 수는 없다.

📈 투자·시사 포인트

• AI 활용 역량의 초점이 요청 문구 작성에서 업무 설계·검수·비용 관리로 넓어진다는 시사점이 있다.
• 지식베이스, 소프트웨어 연결, 팀 소통 채널은 AI를 실제 업무에 배치하는 기반으로 제시된다. 도입 효과는 업무 맥락과 평가 기준을 얼마나 잘 준비하는지에 달려 있다는 해석이 가능하다.
• 발표자의 고액 토큰 사용 사례는 생산성 기대와 함께 운영비를 살펴야 함을 보여준다. 모델 성능 향상이 곧바로 비용 대비 성과 개선을 보장하지는 않는다.
• 영상에는 개별 기업의 실적·가치평가 자료가 없으므로, 소개된 활용 사례를 특정 종목의 투자 근거로 직접 연결하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• Anthropic에서 병합하는 코드의 80% 이상을 AI가 작성한다는 수치, 수 주간의 자율 실행, Swift 재작성과 C 컴파일러 개발 사례는 발표자의 소개다. 원문 자료와 성공 판정 기준은 전사에 포함되지 않는다.
• 향후 Opus 모델의 역량이 크게 개선되고 오류율이 급감할 것이라는 발언은 전망이다. SOP를 향후 5~10년간 재사용할 수 있다는 주장도 검증된 보장으로 볼 수 없다.
• 프롬프트 캐싱으로 두 번째 요청 비용이 통상 요금의 5~10%가 된다는 설명에는 적용 조건과 비용 산정 범위가 충분히 제시되지 않는다. 실제 사용 전 해당 서비스의 조건을 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복해서 수행하는 업무 하나를 골라 구체성·측정 가능성·달성 가능성·관련성·기한을 갖춘 목표와 완료 판정 기준을 작성한다.
• 업무의 배경, 목표를 정한 이유, 참고 자료와 피해야 할 실수를 정리해 에이전트가 사용할 지식베이스를 준비한다.
• 기대하는 품질을 보여주는 결과물을 직접 한 번 만들고, 비교 기준으로 제공한다.
• 같은 업무를 5~10회 수행하게 한 뒤 공통 오류와 누락을 모아 수정 목록을 만들고, 개선된 절차를 SOP로 남긴다.

❓ 열린 질문

• 우리 업무에서 에이전트가 스스로 확인할 수 있는 완료 기준과 사람이 판단해야 하는 품질 기준은 각각 무엇인가?
• 지식베이스와 모범 결과물을 제공했을 때, 반복 실행의 품질 편차가 얼마나 줄어드는가?
• 고성능 모델을 계속 사용하는 방식과 업무별로 모델을 나누는 방식 중 어느 쪽이 검수 시간을 포함한 총비용에서 유리한가?