프롬프트를 더 단순하게 써라

원제: Make Your Prompts Dumber
URL: https://www.youtube.com/watch?v=m-B3jIMMmUE
채널: t3dotgg
원본 업로드일: 2026-10-18
노트 작성일: 2026-10-19
영상 길이: 약 31분 44초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

에이전트를 잘 쓰려면 프롬프트를 더 복잡하게 설계해야 하는가, 아니면 원하는 결과를 직접 요청하고 에이전트가 움직일 수 있게 시스템을 열어야 하는가? 더 단순한 말로 더 큰 결과를 요청하고, 실제 엔지니어링은 데이터·도구·권한·워크플로 같은 기반을 에이전트에 제공하는 데 집중하라.

• 많은 개발자는 프롬프트를 지나치게 기술적으로 설계하면서 에이전트가 가진 기능을 충분히 요청하지 않는다.
• 한 번 쓰고 버릴 만한 대시보드·분석·진단 기능은 제품 기능으로 만들기 전에 에이전트에게 결과를 요청해 볼 수 있다.
• 반복 가능한 기능은 스킬이나 지침으로 정리하고, 에이전트가 접근할 수 없는 데이터와 시스템 연결은 엔지니어링으로 해결한다.

핵심은 프롬프트를 아무렇게나 쓰라는 뜻이 아니다. 문제와 원하는 결과를 분명하게 말하되, 구현 방법과 UI를 미리 좁히지 말라는 뜻이다. 에이전트가 한 번에 풀 수 있는 임시 요구는 요청으로 처리하고, 여러 에이전트가 계속 필요로 하는 능력·맥락·접근 경로는 재사용 가능한 기반으로 만들면 제품 개발도 더 큰 문제를 향해 나아갈 수 있다.

---

1. 프롬프트 엔지니어링의 과잉에서 벗어나라

프롬프트를 더 정교하게 꾸미는 일보다, 에이전트에게 어떤 결과를 요청할 수 있는지 다시 생각하는 일이 먼저다.

1.1. 개발자의 익숙한 사고틀이 요청의 범위를 줄인다

1. 프롬프트를 복잡하게 만들면 에이전트가 성공한다는 믿음
   1. 유행이 만든 기대: 한때 프롬프트 엔지니어링은 에이전트를 성공시키려면 명령을 아주 구체적으로 설계하고 그 기술을 따로 공부해야 하는 분야처럼 여겨졌다.
   2. 문제의 실제 원인: 개발자가 프롬프트를 못 쓰는 까닭은 대개 충분히 공학적으로 다듬지 않아서가 아니라, 구현 세부 사항에 과도하게 매달리고 에이전트가 할 수 있는 일을 작게 상정하기 때문이다.
2. 프롬프트는 컴퓨터와 일하는 방식을 다시 생각하는 수단
   1. 요청의 크기: 단순히 코드를 생성해 달라는 데 그치지 말고, 평소 업무에서 얻고 싶은 결과와 해결하고 싶은 문제를 말하라.
   2. 기술과 요청의 경계: 모델이 현재 가진 도구와 정보로 처리할 수 있는 일은 제품 기능을 새로 만들지 않고 요청으로 해결할 수 있다.

1.2. 엔지니어는 과거의 자동화 비용을 기준으로 가능성을 판단한다

1. 국립공원 사진 예시가 보여 주는 기술 격차
   1. 위치 판정은 익숙한 문제다: 사진 촬영 위치가 국립공원 안인지 확인하는 일은 GPS 좌표를 구하고 공원별 경계 상자와 비교하면 된다고 엔지니어가 반응한다.
   2. 새 기능의 연구 비용은 달랐다: 사진 속 새를 식별하는 일은 과거라면 연구팀이 수년간 컴퓨터 비전 AI를 만들어야 하는 문제였지만, 현대의 비전 모델은 이를 훨씬 쉽게 처리한다.
2. 익숙한 구현 방식은 에이전트의 능력을 가린다
   1. 요청 자체를 떠올리지 못한다: 과거에 직접 구현하기 어려웠던 일을 개발자는 이제도 제품 기능으로 먼저 상상하므로, 에이전트에게 결과부터 요청할 가능성을 놓친다.
   2. 프롬프트를 통해 재정의한다: 구현 방법을 정하기 전에 “이 결과를 에이전트에게 부탁할 수 있는가?”라고 물으면 문제를 다루는 경계가 넓어진다.

1.3. 팀의 문제도 고정된 자동화와 짧은 지침으로 다룰 수 있다

1. Macroscope의 PR별 코드 검토 에이전트
   1. 도구의 쓰임: Macroscope는 팀의 코드 리뷰와 최근 변경 사항, 기여자별 병합 현황을 보여 주며, 프로젝트 안의 설정을 통해 사용자 지정 실행 에이전트를 PR에 붙일 수 있다.
   2. 좁게 발동하도록 설계: 새 UI 컴포넌트 대신 기존 컴포넌트를 쓰도록 검사하는 UI 일관성 지침은 어떤 모델과 도구를 쓸지, 무엇을 찾아볼지 Markdown으로 적고 관련 파일을 바꾼 PR에서만 실행한다. 테스트 파일만 수정한 PR은 제외한다.
2. 대형 구현보다 적절한 범위의 규칙이 낫다
   1. 팀의 반복 오류를 겨냥한다: 기존 컴포넌트가 있는데 새 컴포넌트를 만드는 문제처럼 실제 반복되는 오류에 한정해 자동 검토를 걸면 불필요한 검사를 줄일 수 있다.
   2. 사람의 역할을 보완한다: 이런 규칙과 코드 리뷰 도구는 팀이 무엇을 배포하는지 파악하고 더 나은 코드를 내보내도록 돕는다.

---

2. 원하는 결과를 묻고, 일회성 기능을 프롬프트로 바꿔라

분석·시각화·작업 분류처럼 잠깐 필요한 결과를 매번 앱 기능으로 구현하지 말고, 에이전트가 이미 읽을 수 있는 데이터를 활용하라.

2.1. 로그와 컨텍스트는 새로운 UI 없이도 분석할 수 있다

1. 도구 호출 실패 원인을 먼저 조사한다
   1. 셸 호환성 문제: 여러 기기의 에이전트 작업 기록을 살펴보니 Claude의 도구 호출 실패 상당수가 ripgrep에 Bash에서는 동작하지만 Zsh에서는 통하지 않는 개행 형식·구문을 사용한 데서 발생했다.
   2. 측정 기능은 이미 존재했다: 동료는 가장 느린 도구 호출과 오래 걸리는 명령을 보여 주는 기능을 원했지만, T3 Code에는 도구 호출 기록을 분석할 수 있는 기능이 데스크톱과 모바일 앱에 이미 있었다.
2. 기록을 요청하면 유용한 리포트가 생긴다
   1. 구체적으로 요청한다: “이 컴퓨터의 T3 Code 도구 호출 전체를 분석해 가장 느린 호출과 환경 최적화 지점을 정리해 달라”고 요청하면 에이전트가 기록을 훑어 리포트를 만들 수 있다.
   2. 수치가 원인을 드러낸다: 리포트에서 홈 디렉터리 검색 하나는 41.7분, 다른 검색은 거의 10분 걸린 사례가 발견됐다. 이런 측정치는 어떤 디렉터리 검색이 낭비를 만드는지 확인하게 해 준다.
3. 컨텍스트 사용량도 시각화 대상으로 삼는다
   1. 원하는 산출물을 명시한다: 현재 대화의 컨텍스트 창 사용량을 분석하고 보기 좋은 시각화로 만들라고 요청하면 별도 기능을 개발하지 않아도 결과를 얻을 수 있다.
   2. 숨은 설정 문제를 찾는다: Railway 프록시 설정이 매 요청에 컨텍스트 70,000토큰을 추가하고 있었고, 이 상태가 두 달가량 지속됐지만 작업자는 뒤늦게 알아챘다.
   3. 실시간성이 없으면 기다릴 수 있다: 백그라운드에서 분석을 실행하고 결과가 준비됐을 때 받아보면, 즉시 응답해야 한다는 요구가 없는 작업의 실행 시간이 덜 중요해진다.

2.2. 미리 만든 대시보드 대신 여러 실행을 관리하는 메타 대화를 활용한다

1. 고정 대시보드는 요구가 늘수록 비대해진다
   1. 처음엔 명확해 보이는 요구: 약 40개의 실행 스레드를 모아 상태를 판정하고, 병합할 PR·닫을 스레드·이름을 바꿀 작업을 제안하는 대시보드는 유용해 보인다.
   2. 버튼과 옵션이 계속 늘어난다: 실행별 조작 버튼, 제목 일괄 재생성, 재분류처럼 예상 가능한 요구를 모두 고정 UI로 만들려 하면 복잡한 관리 기능이 끝없이 커진다.
2. 필요한 결과를 채팅으로 요청한다
   1. 여러 환경을 한 메타 스레드로 연결한다: 모든 환경의 T3 Code 실행에 접근할 수 있는 대화형 스레드를 두고 작업 상태를 요약하거나 원하는 형태의 대시보드를 만들어 달라고 요청할 수 있다.
   2. 요청하지 않은 형식도 얻는다: 실제로 리포트 요청만 했는데도 에이전트가 페이지 형태의 결과를 만들었고, 작업자는 도구 호출과 소요 시간의 시각화를 확인했다.
   3. 반복되면 재사용한다: 결과를 바꾸거나 추가 질문을 하고, 반복적으로 쓸 만한 요청이라면 스킬로 정리해 다음에도 불러 쓸 수 있다.

2.3. 원하는 모델과 작업 분담도 고정 설정 대신 프롬프트로 정한다

1. 모델 선택 기능보다 원하는 작업 지시가 간단하다
   1. 모델은 이미 하위 에이전트를 고를 수 있다: 사용자가 어느 하위 에이전트를 쓸지 선택하는 기능을 요청했지만, 오케스트레이터 모델 자체가 하위 작업자를 선택할 수 있는 상황이었다.
   2. 역할·순서·모델을 명시한다: 성능 개선점을 탐색하도록 Opus 5.5 에이전트 둘을 실행하고 결과를 요약한 뒤, 새 스레드에서 Grok 4.7을 사용해 구현하라고 지시할 수 있다.
2. 한 번만 필요한 조합은 UI로 고정하지 않는다
   1. 실행 환경도 함께 지정한다: 필요한 경우 작업을 어느 컴퓨터에서 실행할지도 프롬프트에 넣어 요구에 맞는 자원을 사용할 수 있다.
   2. 반복이 확인된 뒤 추상화한다: 같은 역할 분담을 자주 반복할 때만 스킬이나 에이전트 지침으로 옮겨 고정 비용을 들인다.

---

3. 복잡한 디버깅 흐름은 코드를 덧붙이기보다 에이전트에게 넘긴다

모든 예외 경로를 제품 코드로 예측하기 어렵다면, 디버깅 맥락과 절차를 지침으로 제공해 코딩 에이전트가 사용자와 직접 문제를 풀도록 하라.

3.1. T3 Triage는 거대한 기능 대신 CLI와 Markdown으로 구성된다

1. 앱이 열리지 않아도 진단을 시작한다
   1. CLI로 진입한다: Windows에서 T3 Code가 자주 충돌해 사용자가 문제를 겪자, npx t3 triage 명령으로 실행되는 진단 도구를 T3 CLI에 넣었다.
   2. 원하는 코딩 하네스를 고른다: 명령을 실행하면 Claude Code 또는 Codex를 선택하고, 진단 프롬프트를 해당 에이전트 하네스로 전달한다. 데스크톱 앱이 고장 나 열리지 않는 경우도 고려한 구조다.
2. 프롬프트가 사용자와 함께 진단을 진행한다
   1. 재현 정보부터 모은다: 처음에는 무슨 문제가 있었는지 사용자의 말로 설명하게 하고 스크린샷을 붙이게 한다. 설명이 모호하면 후속 질문을 하며, 정확한 재현 단계 확보를 가장 가치 있는 일로 둔다.
   2. 기계와 제품의 맥락을 읽는다: 명령이 수집한 기계 정보와 최신 공개 플레이북을 확인하고, 오픈소스 저장소와 상위 버전을 살펴 버그가 이미 수정됐는지 조사한다.
   3. 적절한 해결 경로를 고른다: 설정 문제면 사용자를 해결로 이끌고, 제품 버그라면 이슈를 작성하되 먼저 중복 이슈를 찾는다. 외부 이슈에 데이터를 올리기 전에 비밀 정보와 민감한 데이터를 제거한다.
3. 절차를 한 번에 전달해 분기 코드를 줄인다
   1. 다단계 UI를 만들 필요가 없다: 질문을 한 단계씩 꺼내는 복잡한 워크플로 대신, 모델이 대화를 진행하도록 흐름 전체를 하나의 긴 프롬프트에 적는다.
   2. 구현 규모가 크게 줄었다: 처음엔 수천 줄짜리 복잡한 진단 기능을 상상했지만 실제 접근은 약 5줄의 코드와 30줄의 Markdown으로 단순해졌다.

3.2. 데이터가 부족하면 에이전트에게 필요한 관측 가능성을 설계하게 한다

1. 렌더링 문제의 과거 기록을 질문한다
   1. 구체적인 실패를 기준으로 한다: 새 스레드를 열 때 화면이 깜박이는 문제를 겪었고, 해결 여부를 판단할 수 있도록 앱의 렌더링 상태를 충분히 기록하지 않는다는 점을 발견했다.
   2. 있는 정보와 없는 정보를 묻는다: 에이전트에게 과거 렌더링 상황을 확인할 데이터가 있는지, 없다면 앞으로 어떤 데이터를 노출해야 유용한지 제안하라고 요청한다.
2. 에이전트를 제품 설계 파트너로 사용한다
   1. 정답 대신 조사 방향을 얻는다: 지금 접근할 수 있는 정보와 그렇지 않은 정보를 구분하고, 이후 진단에 필요한 로그·데이터를 에이전트가 구체화하도록 한다.
   2. 터미널 선호를 절대 조건으로 만들지 않는다: 긴 음성 입력을 터미널에 붙여 넣고 읽기 어려운 상황을 예로 들며, 사용자가 더 편한 인터페이스를 활용하라고 권한다.

---

4. 에이전트의 실제 능력을 물어보고 시스템과 연결하라

에이전트가 볼 수 있는 맥락, 실행할 수 있는 도구, 접근 가능한 앱을 먼저 확인하고 부족한 능력을 채우면 대화형 요청이 실제 업무 처리로 이어진다.

4.1. 에이전트가 할 수 있는 컴퓨터 조작을 직접 열거하게 한다

1. 컨텍스트에 이미 있는 능력 정보를 꺼낸다
   1. 질문으로 도구 명세를 얻는다: ChatGPT/Codex 데스크톱 앱이 제공하는 컴퓨터 사용 능력을 자세히 설명해 달라고 요청하면 모델 컨텍스트에 있던 기능을 정리할 수 있다.
   2. 기능의 차이를 비교한다: 현재 도구와 다른 도구를 비교해 달라고 하면 어느 쪽에 어떤 권한이나 접근 수단이 부족한지 파악할 수 있다.
2. 능력 목록을 구현 계획에 연결한다
   1. 화면을 다루는 기능: 앱을 찾고 열며, 접근성 트리의 구조화된 정보와 스크린샷으로 화면을 읽고, 클릭·더블클릭·우클릭·드래그·스크롤을 사용할 수 있다.
   2. 작업을 완결하는 기능: 키보드 입력과 필드 편집, 브라우저 탭과 파일 처리를 하고 결과를 확인할 수 있다.
   3. 차이를 복제로 옮긴다: 이 능력 목록을 다른 모델에게 전달하고 가능한 범위만큼 복제하라고 요청해 컴퓨터 사용 기능을 구현하는 PR을 만들었다.

4.2. 잘못된 결과를 비난하기보다 필요한 맥락과 도구를 진단한다

1. 문제의 원인을 에이전트에게 묻는다
   1. PR의 스크린샷 누락: 왜 스크린샷을 추가하지 않았는지, 다음 PR에서 추가하려면 어떤 도구가 필요한지 질문한다.
   2. 해결되지 않은 버그: 왜 버그를 찾지 못했는지, 직접 실행해 재현할 수 있는지, 다른 스레드의 기록을 읽고 실패 원인을 찾을 수 있는지 물어본다.
2. 질문의 범위를 시스템 전체로 넓힌다
   1. 프롬프트를 다시 프롬프트한다: 프롬프트, 프로그램, 시스템, 질문 자체를 점검하도록 요청하면 실패를 수정하고 다음 실행에 필요한 조건을 찾을 수 있다.
   2. 에이전트가 못 하는 일을 발견한다: 데이터·도구·권한이 없어 답하지 못하는 경우를 찾아 그 경계에 맞는 연결 기능을 구현한다.

4.3. 반복할 수 없었던 개인 업무도 대화형 요청의 대상이다

1. 여러 의료 포털에서 자료를 모은다
   1. 수작업을 자동화할 수 있다: 여러 병원 웹사이트에 흩어진 MRI 파일을 모으고 PDF를 정리하는 프로그램을 직접 만들 수도 있다.
   2. 일회성 요구는 에이전트에게 맡길 수 있다: 포털을 오가며 자료를 찾는 일을 에이전트에게 설명하고 처리하게 하면, 별도 프로그램을 만들기 어려웠던 작업도 시도할 수 있다.
2. 요청은 대면 활동의 대체가 아니라 새로운 접근을 만든다
   1. 이메일과 비슷한 변화다: 이메일이 대면 대화나 편지를 완전히 없애기보다 예전에는 연락하지 않았을 사람에게 닿게 한 것처럼, 에이전트 요청도 기존 활동 대신만이 아니라 새로 가능해진 일에 쓰인다.
   2. 쓰지 않을 도구와는 다르다: 원래라면 비용과 시간 때문에 만들지 않았을 일을 요청으로 처리해 보는 것이 핵심이다.

---

5. 프롬프트의 한계는 엔지니어링할 기반을 알려 준다

프롬프트만으로 해결되지 않는 데이터 접근·시스템 연결·반복 작업을 찾아내고, 에이전트가 쓸 수 있는 기초 도구와 파이프라인을 설계하라.

5.1. 개인 업무 자동화에서 시스템 간 연결로 확장한다

1. 이메일을 에이전트에 연결한 뒤 확인 빈도가 달라졌다
   1. 여러 받은 편지함을 통합한다: 다섯 개의 메일함 중 네 개를 꾸준히 확인해야 했고, 이메일 앱을 직접 만들까 고민한 기간도 약 4년이었다.
   2. 확인을 하루 한 번으로 줄인다: 손을 다쳐 메일을 직접 처리하기 어려워진 뒤 여러 계정을 ChatGPT에 연결했고, 하루 약 10번 확인하던 받은 편지함을 하루 한 번 정도만 확인하게 됐다.
2. 메일에서 비용 분석과 코드 변경까지 이어 간다
   1. 조건부 감시를 맡긴다: Amazon 메일이나 큰 AWS 청구서를 감시하라고 요청하고, 청구액이 높으면 AWS 대시보드를 조사해 원인을 찾아 비용 절감안을 제시하게 할 수 있다.
   2. 연결된 에이전트를 실행한다: 다른 에이전트와 T3 Code 작업을 띄우고, Codex와 Dot에 T3 Code MCP를 연결해 클라우드 스레드까지 시작하도록 구성한다.
   3. 데이터 파이프가 업무를 잇는다: 이메일에서 경보를 읽는 일과 다른 프로그램을 거쳐 실제 변경을 배포하는 일을 이어 주는 것은 각 시스템의 접근 경로와 데이터를 연결했기 때문에 가능하다.

5.2. 반복되는 요청이 요구하는 기반을 개발한다

1. 프롬프트는 엔지니어링의 종착점이 아니다
   1. 새로운 기반이 필요하다: 에이전트가 활용할 데이터와 맥락, 도구, 워크플로, 파이프라인을 만들수록 프롬프트가 해낼 수 있는 일이 커진다.
   2. 애플리케이션 인터페이스를 공유한다: 앱의 기능을 MCP로 노출하고 대시보드에 웹 MCP를 추가하면 다른 에이전트가 앱을 조작하고 결과물을 더 넓은 방식으로 사용할 수 있다.
2. 기능보다 조합 가능한 프리미티브를 제공한다
   1. 시각화를 인라인으로 연다: 현재는 에이전트가 HTML 페이지를 만들어 별도 브라우저로 보여 줄 수 있지만, 앱을 벗어나지 않고 결과를 볼 인라인 렌더링 같은 기초 요소가 있으면 더 자연스럽다.
   2. 사용자별 동적 기능을 허용한다: 이런 프리미티브의 목적은 버튼 하나를 더 추가하는 게 아니라, 사용자들이 자기 상황에 맞는 기능을 에이전트로 직접 구성하도록 하는 것이다.

---

6. 엔지니어의 역할은 사라지기보다 더 깊은 문제로 이동한다

코드의 모든 세부 사항을 직접 조립하는 비중이 낮아져도, 어떤 시스템을 만들고 에이전트에게 어떤 기반을 줄지 결정하는 엔지니어링의 가치는 커진다.

6.1. 가치의 중심은 코드 작성량에서 시스템 문제로 옮겨 간다

1. 일부 세부 구현은 예전만큼 중요하지 않다
   1. 언어와 프레임워크의 비중 변화: 에이전트가 기능을 구현하면 어떤 언어와 프레임워크를 골랐는지에 대한 관심이 줄어들고, 이 때문에 엔지니어로서 정체성이 흔들릴 수 있다.
   2. 작동하는 결과에는 품질 기준이 남는다: 코드가 생성됐다는 사실만으로 충분하지 않으며, 기능이 올바르고 테스트되며 안정적으로 동작하는지 살피는 책임은 유지된다.
2. 더 어려운 기반 문제를 직접 해결한다
   1. 데이터베이스 연결을 최적화한다: 모든 SQL 문을 직접 들여다보는 대신 데이터베이스와 서버 사이의 연결 방식을 개선하고, 비용을 급격히 늘리지 않으면서 연결을 따뜻하게 유지할 방법을 고민할 수 있다.
   2. 에이전트가 달릴 실행 환경을 만든다: 올해 Rust 앱 다섯 개를 만들고 메모리 관리를 더 깊이 익힌 사례처럼, 격리 환경에서 에이전트를 낮은 한계 비용으로 실행할 미래를 위해 런타임과 운영체제 같은 기반을 다룬다.
   3. 단독 개발의 범위가 커진다: 운영체제와 컴파일러, 클라우드용 JavaScript 런타임처럼 이전에는 인력과 비용 때문에 착수하기 어려웠던 문제도 더 실현 가능한 과제가 된다.

6.2. AI에 대한 상실감은 새로운 엔지니어링 범위를 발견하기 전의 골짜기다

1. 숙련된 개발자도 정체성의 흔들림을 겪는다
   1. 익숙한 전문성이 무의미해 보인다: 오랫동안 쌓아 온 코딩 능력이 프롬프트 한 줄로 대체되는 듯 보이면 엔지니어링이 덜 즐겁고, 자신이 해 온 일이 쓸모없어진 것처럼 느껴질 수 있다.
   2. 변화에는 감정적 저점이 있다: 초보에서 자신감을 얻고 다시 자신의 부족함을 깨달으며 숙련되는 기존의 성장 곡선에 AI가 변곡점을 더해, 익숙한 기술이 빠르게 평가절하되는 듯한 골짜기를 만든다.
2. 관점이 바뀌면 더 높은 층위의 문제를 풀게 된다
   1. 기능 조립에서 제품·시스템 설계로 이동한다: 구독과 광고로 수익을 내는 제품을 만들던 역할에서 운영체제와 컴파일러, 자체 클라우드 런타임을 설계하는 역할로 문제의 깊이가 확장된다.
   2. 비판보다 실제 한계를 찾아야 한다: AI가 생성한 코드가 잘 작동하고 충분히 테스트됐는데도 이를 곧바로 “두뇌가 망가졌다”고 단정하면, 에이전트가 작동할 시스템을 설계하는 더 어려운 일을 놓친다.
   3. 만들 가치가 커진다: 에이전트가 해낼 수 없는 경계를 확인하면 더 나은 데이터·도구·인프라를 만들 이유가 생기며, 이전보다 더 깊은 엔지니어링에 투자할 수 있다.

---

주요 발언 모음

“대부분은 충분히 세게 프롬프트하지 않는다.”

“만들고 싶은 것을 구현하기 전에, 그것을 얻을 방법을 에이전트에게 먼저 물어봐라.”

“기능처럼 보이는 것 가운데 절반은 사실 프롬프트일 수 있다.”

“에이전트가 원하는 일을 하게 하려면, 에이전트가 작동할 더 나은 시스템을 만들어야 한다.”

“엔지니어링은 지금처럼 재미있었던 적이 없다.”

핵심 데이터 & 수치

• 도구 호출 분석: 홈 디렉터리 검색 한 건은 41.7분, 다른 검색 한 건은 거의 10분을 사용했다.
• 컨텍스트 낭비: Railway 프록시 설정은 매 요청에 약 70,000토큰을 넣었고, 이 사실을 약 두 달간 알아채지 못했다.
• T3 Triage 구현 규모: 거대한 진단 기능을 약 5줄의 코드와 30줄의 Markdown 지침으로 대체했다.
• 메일 처리: 다섯 개 메일함 중 네 개를 적극 관리하던 작업자는 확인 빈도를 하루 약 10회에서 한 번으로 낮췄다.
• 기반 기술 투자: 올해 Rust 앱 다섯 개를 만들었고, 메모리 관리와 에이전트 실행 환경에 대한 이해를 넓혔다.
• 촬영 시점: Macroscope 팀 현황 화면은 10월 2일 기준이었고, 촬영일은 10월 6일이었다.

결론 및 시사점

1. 기능 요청을 검토할 때 먼저 결과를 요청하라: 사용자나 팀이 원하는 결과를 에이전트가 이미 접근할 수 있는 데이터와 도구만으로 만들어낼 수 있는지 확인하라.
2. 프롬프트는 방법보다 목표를 말하라: 사용자의 문제와 성공 조건을 선명하게 적되, UI·모델·구현 절차를 불필요하게 미리 고정하지 말라.
3. 반복 요청은 스킬로 정리하라: 한 번의 대화로 충분하지 않고 같은 절차를 되풀이한다면 Markdown 지침이나 재사용 가능한 스킬로 옮겨라.
4. 프롬프트가 막히는 지점을 엔지니어링하라: 부족한 로그, 권한, MCP 인터페이스, 데이터 파이프, 실행 환경을 찾아 에이전트가 접근할 수 있도록 만들어라.
5. 에이전트의 출력을 검증하라: 생성된 코드가 테스트되고 실제로 올바르게 작동하는지 확인하고, 외부에 이슈를 제출할 때는 민감한 정보를 제거하라.
6. 더 높은 층위의 문제를 맡아라: 코드 조립 비용이 낮아질수록 제품 경험, 시스템 구조, 런타임, 데이터 연결처럼 더 많은 사람과 에이전트를 뒷받침하는 문제에 집중하라.

20줄 핵심 요약

프롬프트 엔지니어링의 유행은 성공을 위해 명령을 더 복잡하게 써야 한다는 착각을 키웠다.

개발자는 프롬프트를 과도하게 공학화하기보다 에이전트에게 원하는 결과를 더 과감하게 요청해야 한다.

국립공원 위치 확인은 좌표와 경계 상자로 처리할 수 있지만 새 사진 판별은 과거에 수년의 연구가 필요했다.

현대의 비전 모델은 예전에는 전문 연구가 필요했던 사진 속 새 식별을 쉽게 수행한다.

Macroscope의 PR 검토 에이전트는 Markdown 지침과 관련 파일 필터만으로 UI 컴포넌트 재사용을 검사한다.

Zsh와 Bash의 명령 차이를 분석하면 에이전트 도구 호출 실패의 원인을 찾아낼 수 있다.

도구 호출 로그를 분석하면 홈 디렉터리 검색이 41.7분이나 걸린 사례처럼 최적화 지점을 발견할 수 있다.

한 번의 요청으로 도구 호출 시간과 컨텍스트 사용량을 분석하는 시각화 리포트를 만들 수 있다.

Railway 프록시는 매 요청에 70,000토큰을 넣었지만 이 설정은 두 달 가까이 눈에 띄지 않았다.

약 40개 실행 스레드를 관리하는 고정 대시보드보다 필요한 작업을 메타 대화에 요청하는 방식이 유연하다.

원하는 모델과 하위 에이전트의 수, 역할, 실행 순서도 프롬프트에서 지정할 수 있다.

T3 Triage는 앱이 열리지 않을 때도 CLI에서 Claude Code나 Codex로 진단을 시작하게 한다.

T3 Triage는 문제 재현, 기계 정보 확인, 최신 플레이북 조사, 저장소 분석, 중복 이슈 확인을 지침으로 처리한다.

복잡한 진단 워크플로는 수천 줄의 코드 대신 약 5줄의 코드와 30줄의 Markdown으로 구현할 수 있다.

에이전트에게 접근 가능한 컴퓨터 기능과 부족한 도구를 물으면 다음 구현의 요구사항을 구체화할 수 있다.

여러 의료 포털의 파일 수집처럼 원래 만들지 않았을 일도 에이전트에게 요청하면 실행해 볼 수 있다.

여러 메일함을 ChatGPT에 연결한 뒤 하루 열 번 하던 받은 편지함 확인을 한 번으로 줄였다.

이메일 감시에서 AWS 비용 분석과 코드 변경으로 이어지는 자동화는 시스템 간 데이터 파이프가 뒷받침한다.

프롬프트가 못 하는 일은 MCP, 로그, 데이터 접근, 실행 환경 같은 엔지니어링 기반을 만들 신호다.

에이전트 시대의 엔지니어링은 코드 조립보다 더 큰 제품과 시스템 문제를 해결하는 방향으로 확장된다.