URL: https://keleshev.com/ai-equals-true-is-an-anti-pattern

Title: AI=true is an Anti-Pattern

AI=true is an Anti-Pattern

AI=true

is an Anti-Pattern

Vladimir Keleshev • 2026-02-25 최근 나를 꽤 많이 놀라게 한 프로그래밍 트렌드가 하나 있다. 회사에서도 오픈소스에서도 모두 일어나는 일인데, 사람들이 갑자기 다음과 같은 일을 하기 시작했다:

• 관련성이 높고, 오래 미뤄졌던, 날카롭고, 간결하며, 요점만 짚는 문서를 잔뜩 작성해 놓고… 그걸 copilot-instructions.md나 AGENTS.md 같은 파일에 넣는다.
• 대단히 가치 있는 워크플로를 구현해 놓고… skills나 MCP 서버 형태로만 노출한다.
• 테스트와 커맨드라인 도구의 출력 품질을 개선해 놓고… AI 지향 플래그나 환경 변수(예: AI=true)를 켰을 때만 활성화한다.

음, 이제는 한 번 크게 숨을 들이쉬고 한 걸음 물러서서 생각해 볼 필요가 있다고 본다.

Documentation

그렇다. 좋은 문서는 AI 에이전트에게 가치가 있다. 특히 그 문서가 학습 데이터셋에 포함되어 있지 않다면 더욱 그렇다. 그리고 좋은 문서의 요약(digest) 은 종종 더 중요하다. 컨텍스트 윈도우를 덜 차지하기 때문이다. 하지만… 그런 문서는 사람에게도 똑같이 가치가 있다. 우리도 컨텍스트 윈도우가 제한되어 있고, 좋은 요약으로 똑같이 이득을 본다.

게다가 우리는 문서를 사람과 AI 에이전트 모두에게 잘 발견 가능한 곳에 두도록 노력해야 한다. README.md는 그런 선택지 중 하나다.

몇 가지 기술적인 사정이 있다는 건 안다. 예를 들어 어떤 도구들은 AGENTS.md 같은 파일을 컨텍스트에 미리 로드한다. 하지만 실제 관례는 빠르게 변하고 있고, 종종 벤더 종속적(즉, 신뢰해서는 안 되는)이다. 그리고 대부분의 이점은 적절한 곳에 “README.md를 보라(See README.md)”라고만 적어도 얻을 수 있다.

Tools

우선 대체로 사람을 위한 도구, 즉 그래픽 사용자 인터페이스를 가진 도구들이 있다. 그리고 주로 AI 지향인 새로운 종류의 도구들, 즉 MCP 도구들이 있다. 하지만 개발자와 AI 에이전트가 똑같이 사용할 수 있는 도구들의 집합도 있다: 커맨드라인 도구와 API. 이들은 스크립팅 가능하고, 조합 가능하며, 텍스트 지향적이고, 개발자와 AI 에이전트 모두에게 기능을 아주 잘 노출할 수 있다. 그걸 기본값으로 삼지 않을 이유가 있을까?

나는 분명 커맨드라인을 선호하는 편이지만, GUI 도구도 꽤 사용한다. 하지만 MCP에 관해서는, 커맨드라인 도구보다 우월한 단 하나의 사례도 아직 본 적이 없다. 시간이 지나면 내가 틀렸다는 것이 증명될지도 모르겠다.

예를 하나 들자면: 실제 커맨드라인 도구는 실행 시간이 오래 걸리고, 출력이 전혀 없어서, 그 때문에 에이전트가 종종 착각하여 너무 일찍 종료해 버리곤 했다는 이유로 MCP 도구를 도입하는 경우를 본 적이 있다. 그건 누군가가 떠오르게 한다… 나다! 새로운 도구를 돌릴 때 커맨드라인이 멈춘 것처럼 보이면, 10초 동안 아무 일도 안 일어났을 때 Ctrl-C로 끊어 버리지 않는 사람이 과연 누가 있을까?

혹은 반대로—불필요한 출력이 엄청나게 쏟아져 나올 때 압도되지 않는 사람이 있을까? 나는 그렇다. 그리고 똑같은 이유로 AI의 컨텍스트 윈도우도 밀려나서, 더 유용할 수 있는 정보를 놓치게 된다. 정신적 과부하, 다들 한 번쯤 겪지 않나?

테스트가 빠르게 실행되고, 실패했을 때는 문제를 쉽게 좁혀갈 수 있는 출력을 내주면 누가 좋아하지 않겠는가? 요점은 알 것이다… 거위에게 좋은 것이 거위 수컷에게도 좋다.

새로운 내부 도구를 만들고 있나? 웹 앱으로 만들어 보라… 그러면 개발자들이 기능이 빠졌다고 계속 불평하는 모습을 보게 될 것이고, 당신은 스코프 크립을 관리하느라 애를 먹을 것이다. 아니면 API를 먼저 만들라. 더 좋은 방법은 그 위에 커맨드라인 래퍼까지 씌우는 것이다. 그러면 개발자와 AI 에이전트 모두가 이를 섞고, 맞추고, 스크립팅하고, 자동화하면서, 당신이 상상도 못 했던 워크플로를 만들어 내고, 자신의 필요를 주도적으로 충족시키는 모습을 보게 될 것이다.

Let’s sum it up

1. 문서는 사람 개발자와 AI 에이전트 모두가 예상할 수 있는 곳에 둬라. 예: AGENTS.md가 아니라 README.md.
2. GUI나 MCP 도구보다, 개발자와 AI 에이전트 모두가 접근하기 쉬운 커맨드라인 도구와 API로 기능을 노출하는 쪽을 선호하라.
3. 사람과 AI 에이전트 사이에서 워크플로를 분리(seggregate)하는 매개변수(커맨드라인, 환경 변수 등)를 피하라. 예를 들어 AI=true는 피하고 --quiet를 선호하라. 혹은—더 좋게는!—컨텍스트 제한/정신적 과부하를 염두에 두고 도구를 설계하라.
4. 일반적으로, AI에게는 가능하지만 사람에게는 접근하기 어렵거나, 그 반대인 워크플로를 만들지 마라.

---

나는 보통 이런 주제로 글을 쓰지 않지만, 이는 프로그래밍 실천의 흐름을 사람과 AI 워크플로의 통합 쪽으로 돌려 보려는 나의 외침이었다.

우리 사이에는 같은 텍스트 인터페이스와 관례를 유지할 만큼의 유사성이 충분히 있다. 가능한 한 상호운용성을 유지하려고 노력해야 한다. 하지만 그에 따른 함의가 가볍지 않다는 점 또한 나는 잘 알고 있다.

---