그런데 웃기면서도 씁쓸한 건, 1년 전만 해도 “AI는 강력한 협업 도구일 뿐”이라고 했다는 점입니다. 절대 대체는 못 한다고도 했고요. 그런데 올해 들어서는 저만 봐도 회사에서 IDE를 거의 켜지 않았습니다. “IDE 뭐가 좋아?” 하던 이야기가 어느새 “AI CLI 쓸 때 터미널 뭐가 좋아?”로 바뀌어 있었죠. AI는 이제 코드를 짜는 것에 그치지 않고, 리뷰하고, 테스트 코드를 만들고, 복잡한 리팩터링까지 해내고 있으니까요.

회사 생활을 시작하면서 늘 듣던 말도 있습니다. “대체 불가능한 존재가 돼라.” 예전에는 코딩을 잘하면 그게 곧 대체 불가능하다는 뜻이었거든요. 그런데 이제는 코딩을 아무리 잘해도 AI에 밀릴 수 있는 시대가 됐습니다. 그렇다면 AI 시대에 대체 불가능한 사람이 되려면, 무엇을 해야 할까요? AI에게 일을 잘 시킨다는 건 어떤 의미일까요?

미리 요점만 콕 집어보면?

AI는 시키지 않으면 아무것도 안 한다. 그래서 "잘 시키는 능력"이 AI 시대의 핵심 역량이 됐다.
잘 시키는 방법은 프롬프트 엔지니어링(어떤 말을 쓸까) → 컨텍스트 엔지니어링(어떤 정보를 줄까) → 하네스 엔지니어링(어떤 환경을 만들까)으로 진화하고 있다.
프롬프트가 많아지면 관리가 필요하고, 관리를 잘하면 동시에 여러 프로젝트를 굴리는 "멀티 서클"이 가능해진다.

AI가 못 하는 것

저는 요즘 매일 AI와 같이 일합니다. 터미널에 Claude Code를 띄워놓고, 하루 종일 이 녀석에게 이것저것 시키며 코딩하죠. 그런데 여기서 재미있는 게 하나 있습니다. 아침에 출근해서 터미널을 켜고, Claude Code를 실행한 뒤 아무 말 없이 가만히 둬보세요. 어떻게 될까요? 아무 일도 일어나지 않습니다.

커서만 깜빡거리면서 저를 바라보고 있을 거예요. 아무리 기다려도 “오늘 뭐 하면 좋을까요?” 하고 먼저 묻지 않습니다. “어제 코드 보니까 여기 버그 있던데, 제가 좀 고쳐놓을까요?” 같은 말도 절대 하지 않죠. 그냥 가만히 있습니다. 제가 시킬 때까지요.

물론 시키면 정말 잘합니다. “이 함수 리팩터링해 줘”라고 하면 깔끔하게 해내고, “테스트 코드 짜줘”라고 하면 바로 만들어내죠. 하지만 시키지 않으면 가만히 있다는 겁니다. 그래서 AI가 못 하는 일은 결국, “시키지 않은 일”입니다.

당연한 이야기처럼 들릴 수도 있는데요. 여기에는 조금 더 중요한 의미가 담겨 있습니다. 모든 서비스의 니즈는 결국 사람에게서 나온다는 점이죠. 가령 AI가 혼자서 일할 수 있도록 환경을 구성한다고 해보겠습니다. 혼자 기획하고, 혼자 구현하고, 혼자 테스트하고, 혼자 운영하는 식으로요. 모든 걸 혼자 할 수 있는 구조를 만들었다고 해도, 어떤 고객군과 조직, 구성원이 무엇을 필요로 하는지 정확하게 파악하는 건 결국 사람입니다.

그래서 오직 사람만이 AI에게 정확한 니즈와 비즈니스 로직을 줄 수 있다고 생각합니다. 그리고 그 “시키는 일”을 어떻게 하면 더 잘할 수 있을지를 고민하는 것, 바로 그 지점이 앞으로 사람이 깊이 파고들어야 할 포인트라는 생각이 들었습니다.

"잘 시킨다"는 게 뭔가요?

그렇다면 “잘 시킨다”는 건 뭘까요? 이 단순한 질문에 답하려는 시도는 이제 하나의 분야가 됐습니다. 처음에는 “프롬프트 엔지니어링”이라는 이름으로 시작했는데, AI가 발전하면서 이 개념도 함께 빠르게 진화하고 있죠. 조금 거창해 보일 수 있지만, 결국 AI에게 어떻게 시켜야 원하는 결과가 나오느냐를 다루는 이야기입니다. 그리고 이 ‘어떻게’라는 부분이 생각보다 훨씬 빠르게 바뀌고 있습니다.

프롬프트 엔지니어링: 어떤 말을 쓸까

초기에는 같은 일을 시키더라도, 프롬프트를 어떻게 작성하느냐에 따라 결과가 크게 달라졌습니다.

나쁜 예시
로그인 기능 만들어줘

좋은 예시
우리 프로젝트는 Express + TypeScript 백엔드야. 기존에 JWT 기반 인증을 쓰고 있어.
로그인 API를 만들어줘.

POST /api/auth/login
이메일/비밀번호로 로그인
비밀번호는 bcrypt로 검증
성공 시 accessToken(15분), refreshToken(7일) 발급
실패 시 401 에러와 명확한 메시지

첫 번째 예시처럼 시키면 AI가 뭔가를 만들기는 합니다. 그런데 높은 확률로 제가 원하는 결과는 아니었죠. 프레임워크도 다르고, 인증 방식도 다르고, 구조 역시 우리 프로젝트와 맞지 않았거든요. 결국 “아니, 그거 말고” 하면서 다시 시키게 됩니다.

반면, 두 번째 예시는 훨씬 더 정확한 결과를 내놓았습니다. 프로젝트 맥락과 기술 스택, 구체적인 요구사항까지 함께 줬으니까요. 이 시기에 사람들은 이른바 “마법의 단어”를 찾아다녔습니다. “Think step by step”을 붙이면 수학 문제 정답률이 올라간다는 논문이 나왔고, “You are an expert”를 넣으면 결과물의 퀄리티가 좋아진다는 이야기도 있었죠. 심지어 “I’ll tip you $200”이라고 쓰면 더 잘한다는 밈까지 돌았습니다. 거의 주문에 가까웠습니다.

프롬프트 마켓플레이스라는 것도 생겨났습니다. “잘 동작하는 프롬프트”를 사고파는 시장이었죠. 그만큼 어떤 단어를 쓰느냐가 중요하던 시대였습니다.

컨텍스트 엔지니어링: 어떤 정보를 줄까

그런데 AI가 빠르게 똑똑해지면서, 이른바 ‘마법의 주문’은 점점 의미를 잃고 있습니다. 대신 중요해진 건, AI에게 얼마나 충분한 맥락을 넘겨주느냐입니다. AI가 한 번에 읽을 수 있는 양을 ‘컨텍스트 윈도우’라고 하는데요. 이 크기가 엄청나게 커졌습니다. 처음에는 4천 토큰 수준이었지만, 지금은 100만 토큰까지 확장됐죠. 그만큼 넣을 수 있는 정보량이 폭발적으로 늘어난 겁니다.

그래서 요즘 AI 코딩 도구들은 작업 디렉토리 전체를 그대로 읽어갑니다. 프로젝트 구조와 기존 코드, 설정 파일까지 AI가 직접 확인하는 방식이죠. 사람이 일일이 “우리 프로젝트는 이런 구조야”라고 설명하지 않아도, AI가 스스로 파악할 수 있게 된 겁니다.

이게 바로 컨텍스트 엔지니어링의 핵심입니다. 질문이 “어떤 말을 쓸까?”에서 “어떻게 맥락을 줄까?”로 바뀌었습니다. AI가 판단하는 데 필요한 정보를 빠짐없이 전달하는 것, 그것이 핵심입니다. 배경을 설명하고, 기술 스택을 알려주고, 기대하는 결과물을 구체적으로 정의하며, “이건 하지 마”라는 제약 조건까지 함께 전달하는 방식이죠.

하네스 엔지니어링, 어떤 환경을 만들까

그리고 요즘은 여기서 한 단계 더 나아가고 있습니다. 바로 “하네스 엔지니어링”이라는 개념인데요. 하네스(harness)는 원래 말의 고삐나 안장 같은 마구를 뜻하는 단어입니다. 컨텍스트 엔지니어링이 “AI가 잘 생각하도록 돕는 것”에 가까웠다면, 하네스 엔지니어링은 “AI가 탈선하지 않게 만드는 것”에 더 가깝습니다. 비유하자면 이렇죠. 말에게 “우회전해”라고 말하는 것이 프롬프트이고, 지도와 표지판을 보여주는 것이 컨텍스트라면, 고삐와 안장, 울타리, 그리고 길 자체를 만드는 것이 하네스입니다.

컨텍스트를 아무리 잘 줘도 해결되지 않는 문제들이 있거든요. AI가 팀 코드 컨벤션을 무시한다거나, 아키텍처 규칙을 어긴다거나, 여러 작업을 동시에 시켰더니 서로 충돌한다거나 하는 식이죠. 이건 “무엇을 보여줄까”의 문제가 아니라, “무엇을 막고, 무엇을 측정하고, 어떻게 수리할까”의 문제입니다.

그래서 하네스 엔지니어링은 에이전트 바깥의 인프라를 설계하는 일에 가깝습니다. 프로젝트 루트에 설정 파일을 넣어두면 AI가 우리 규칙을 따르게 할 수 있고, MCP 서버를 연결하면 DB나 외부 API를 직접 조회하면서 일하게 만들 수 있죠. 또 코드를 저장할 때마다 자동으로 린트가 돌도록 훅을 걸고, 위험한 명령은 실행 전에 차단하는 가드레일까지 둘 수 있습니다.

이제는 매번 “우리 프로젝트는 이런 컨벤션이야” 하고 말해줄 필요가 없습니다. 환경 자체가 그 규칙을 강제하니까요. 흐름을 한눈에 보면 이렇습니다.

이 세 가지는 서로 대체하는 관계가 아니라, 포함 관계에 가깝습니다. 좋은 프롬프트를 쓰는 일은 여전히 중요하고, 여기에 맥락을 잘 전달하는 것이 더해지며, 나아가 환경까지 설계하는 단계로 확장되는 흐름이죠. 결국 “잘 시킨다”의 의미 자체가 계속 넓어지고 있는 셈입니다. 그리고 이 영역을 잘 다루는 사람이, AI 시대에 점점 더 대체 불가능한 존재가 되어간다고 생각합니다.

그 프롬프트, 어디에 쌓고 있나요?

프롬프트든 컨텍스트든 하네스든, 공통점이 하나 있습니다. 어떤 방식이든 결국 우리는 AI에게 “말”로 전달하고 있다는 점입니다. 텍스트든, 채팅이든, 설정 파일이든, 사람이 언어로 의도를 전달하는 구조라는 거죠. 그렇다면 그 “말”들은 어떻게 관리하고 계신가요? 저는 요즘 하루 종일 프롬프트를 만듭니다. 정말로 그렇습니다. 아침에 출근하면 그날 할 일을 정리하고, 그걸 프롬프트로 만들어 AI에게 넘기죠. 그런데 이게 하나로 끝나지 않습니다. AI가 첫 번째 프롬프트를 처리하는 동안, 저는 이미 다음 프롬프트를 만들고 있습니다. 그다음 것도, 또 그다음 것도 이어서 만들게 되죠.

어느 순간 깨달았습니다. 아, 나는 이제 코딩을 하는 사람이 아니라 프롬프트를 만드는 사람이 되어가고 있구나. 그 자체는 괜찮았습니다. 앞에서 말했듯이, “시키는 일”이 사람의 몫이 된 시대니까요. 문제는 그다음이었습니다.

프롬프트가 점점 관리되지 않기 시작한 겁니다. 처음에는 VSCode에서 텍스트 파일로 관리해봤습니다. 프로젝트별로 폴더를 만들고, 그 안에 프롬프트를 하나씩 정리해 두는 방식이었죠. 그런데 파일이 쌓이다 보니 어떤 것은 이미 실행한 것인지, 어떤 것은 아직 대기 중인지 구분이 되지 않았습니다. 그래서 Notion으로 옮겨봤습니다. 페이지별로 나누고, 상태도 표시해봤죠. 하지만 이것도 불편했습니다. 프롬프트를 작성하다가 Notion 탭으로 왔다 갔다 하면서 흐름이 끊겼고, 실제로 AI에 전달하려면 결국 복사해서 붙여넣어야 했습니다.

그래서 다시 생각해봤습니다. 진짜 문제는 무엇일까? 프롬프트는 계속 쌓이고 있고, 이를 프로젝트 단위로 묶어서 보고 싶었습니다. 어떤 것은 완료됐고, 어떤 것은 대기 중인지 상태도 한눈에 알고 싶었죠. 가능하다면 AI에게 바로 전달까지 할 수 있으면 더 좋겠다고 생각했습니다. 그런데 이런 요구를 충족하는 도구는 쉽게 찾기 어려웠습니다.

그래서 그때 이런 생각이 들었습니다. ‘직접 만들어봐야겠다’고 말이죠.

그래서 만들어 본 ‘Idea Manager’

그래서 직접 한번 만들어봤습니다. 아이디어에서 프롬프트까지 이어지는 흐름을 하나로 연결해주는 CLI 도구, Idea Manager(IM)라는 이름을 붙였죠.

구조는 단순하게 3단계로 구성했습니다.

Brainstorming → Task → Prompt

첫 번째는 브레인스토밍입니다. 머릿속에 떠오르는 생각을 두서없이 적어두는 공간이죠. “로그인 방식을 바꿔야 할 것 같은데”, “대시보드 성능이 좀 느린 것 같아” 같은 것들입니다. 이 단계에서는 굳이 정리할 필요가 없습니다. 일단 꺼내놓는 게 중요하죠.

두 번째는 태스크입니다. 브레인스토밍에서 나온 생각을 실제 할 일로 쪼개는 단계인데요. “로그인 방식 바꾸기”가 브레인스토밍이었다면, “JWT에서 세션 기반으로 전환”, “소셜 로그인 추가”처럼 구체적인 태스크로 나누는 식입니다.

세 번째는 프롬프트입니다. 태스크별로 AI에게 시킬 수 있는 프롬프트를 만드는 단계죠. 기술 스택과 요구사항, 제약 조건 같은 맥락을 담아서 바로 실행할 수 있는 형태로 만드는 겁니다.

워크플로우는 이렇게 돌아갑니다.

아이디어를 브레인스토밍으로 꺼낸다 → 태스크로 쪼갠다 → AI와 채팅하면서 구체적인 계획을 세운다 → 프롬프트를 던진다 → AI가 처리하는 동안 다른 아이디어를 브레인스토밍한다

여기서 재미있는 시도를 하나 해봤는데, 바로 MCP 연동입니다. 프롬프트에 상태를 달아두면 AI가 태스크 목록을 직접 읽어가면서 대기 중인 작업을 처리하고, 완료되면 상태도 자동으로 바꿉니다. 하나하나 “이거 해줘” 하고 던질 필요 없이, AI가 알아서 대기열에서 꺼내 작업하는 셈이죠.

이걸 쓰기 전과 후를 비교해보면 차이가 더 분명합니다. 예전에는 아침에 출근하면 “어제 뭐 했더라?”부터 떠올려야 했습니다. 채팅 기록을 뒤져보고, Notion을 찾아보고, 그렇게 꽤 많은 시간을 썼죠. 지금은 아침에 IM을 열면 프로젝트별로 대기 중인 태스크가 쭉 보입니다. 바로 프롬프트를 만들고 시작하면 됩니다. 얼핏 보면 작은 차이처럼 보이는데요. 이런 차이가 매일 쌓이면 생각보다 훨씬 커집니다.

그리고 이건 저 혼자만의 이야기로 끝나지 않을 수도 있다고 생각합니다. 팀에서 프롬프트를 공유하면 어떨까요? 누군가 잘 만들어둔 프롬프트가 팀 전체의 자산이 되는 겁니다. 프롬프트가 계속 쌓이면, 팀 전체에 맞는 프롬프트를 만들어주는 모듈도 만들 수 있을 것이고, 결국 전체 생산성도 더 올라갈 수 있지 않을까요.

꼭 이 도구를 쓰라는 이야기를 하고 싶은 건 아닙니다. 제가 말하고 싶었던 건 도구 자체보다 이 흐름에 가깝습니다. 아이디어를 꺼내고, 할 일로 쪼개고, 프롬프트로 만들어 관리하는 이 사이클 말이죠. 이 흐름을 자기만의 방식으로 만들어두면, 확실히 일하는 방식이 달라지더라고요.

몇 서클 마법사인가요?

이렇게 프롬프트를 관리하기 시작하면, 재미있는 질문이 하나 떠오릅니다.

“동시에 몇 개나 굴릴 수 있나?”

AI에게 프롬프트를 던지고, 그 작업이 처리되는 동안 다른 프로젝트의 프롬프트를 만들고, 또 다른 프로젝트의 결과를 확인하게 됩니다. 이런 사이클이 돌아가기 시작하면, 자연스럽게 여러 프로젝트를 동시에 진행하게 되죠.

주변에서 동시에 7개 프로젝트를 돌리는 사람을 본 적이 있습니다. AI에게 이쪽 프로젝트를 맡기고, 저쪽 프로젝트 결과를 확인하고, 또 다른 프로젝트의 프롬프트를 만드는 식이었죠. 옆에서 보고 있으면, 여러 개의 마법을 동시에 시전하는 마법사 같다는 느낌이 들었습니다.

반면, 저는 솔직히 3~4개 정도가 한계입니다. 그 이상 넘어가면 머릿속이 금방 뒤죽박죽이 되더라고요. 프로젝트마다 맥락이 다르기 때문입니다. A 프로젝트는 Express, B 프로젝트는 Next.js, C는 React Native처럼 환경이 제각각이다 보니, 머리가 계속 다른 영역으로 점프하는 느낌이 들었습니다. 그래서 문득 이런 생각이 들었습니다. 이건 마치 7서클 마법사와 3서클 마법사의 차이 같다는 생각이요.

그렇다면 이 ‘서클’을 늘리는 열쇠는 무엇일까요. 생각해 보면 결국 프롬프트 관리 능력으로 돌아옵니다. 프로젝트별로 프롬프트가 잘 정리돼 있으면, 컨텍스트 전환 속도가 훨씬 빨라지거든요. “이 프로젝트 어디까지 했더라?” 하고 되짚을 필요 없이, 대기 중인 태스크를 보고 바로 이어서 진행하면 됩니다.

앞으로는 “몇 서클이세요?” 같은 질문이 개발자들 사이에서 자연스럽게 오가는 날이 올지도 모르겠습니다. 그때를 떠올리며 한번 생각해보면 어떨까요. 지금 나의 프롬프트는 어떻게 관리하고 계신가요?

Q. 프롬프트 엔지니어링은 이제 의미 없는 건가요?

여전히 중요합니다. 다만 예전처럼 “마법의 단어”를 찾는 일이 핵심은 아니게 됐죠. AI가 점점 더 똑똑해지면서, 맥락을 얼마나 잘 전달하느냐가 더 중요해졌기 때문입니다. 좋은 프롬프트와 충분한 컨텍스트, 그리고 잘 설계된 환경. 이 세 가지가 함께 가야 합니다.

Q. CLAUDE.md 같은 설정 파일, 꼭 써야 하나요?

필수는 아니지만, 사용하면 확실히 달라집니다. 매번 “우리 프로젝트는 TypeScript고, 컨벤션은 이거고”라고 설명할 필요가 없어지거든요. 한 번만 잘 만들어두면, AI가 알아서 규칙을 따르게 됩니다. 그래서 처음에는 간단한 형태라도 직접 만들어보는 것을 추천합니다.

Q. Idea Manager 같은 도구가 꼭 필요한가요?

꼭 이 도구일 필요는 없습니다. 핵심은 “아이디어 → 태스크 → 프롬프트”로 이어지는 흐름을 자기만의 방식으로 만드는 데 있습니다. Notion이든, 텍스트 파일이든, Obsidian이든 상관없죠. 프로젝트별로 프롬프트 상태를 관리할 수만 있다면 충분합니다.

Q. 동시에 몇 개 프로젝트를 돌리는 게 현실적인가요?

사람마다 다릅니다. 저는 3~4개 정도가 한계인데, 7개를 동시에 돌리는 분도 봤습니다. 중요한 건 숫자 자체가 아니라, 컨텍스트 스위칭을 얼마나 빠르게 하느냐입니다. 프롬프트 관리가 잘되면 자연스럽게 서클도 늘어나더라고요. 처음에는 2개부터 시작해보는 걸 추천합니다.