Harness Engineering은 얼마나 갈까

하네스로 만들 수 있는 유용한 건 결국 전부 vanilla로 빨려 들어간다. 그러고 나면 남는 건 유용한 기능이 아니라, Claude가 구조적으로 안 하거나 못 하는 것뿐이다. 1년을 부어 만든 harness-maker가 나한테 그걸 가르쳐줬다. 그 안의 loop와 review를 Claude Code가 덮어버렸기 때문이다. Goal이랑 Dynamic Workflows를 기본으로 탑재하면서, 정확히 그 자리를.

시작은 단순했다. harness engineering이 한창 화제였고, 나도 내 하네스를 갖고 싶었다. 그래서 1년치 경험을 통째로 부은 harness-maker를 만들었다. 프로젝트마다 취향이 다른데, 그걸 하네스에 녹이는 게 나한테는 필요했다. 회사일에 사이드 프로젝트, 거기다 실제로 파는 프로젝트까지 같이 굴리다 보니 오픈소스 하네스 하나로 전부 최적화하는 건 무리였다. Spec Driven으로 가는 프로젝트랑 가볍게 Task Driven으로 가는 프로젝트는 workflow 자체가 다르다.

그런데 Dynamic Workflows를 보는 순간 생각이 바뀌었다. 아, 웬만한 OSS 하네스는 다 흡수되겠구나. 내 harness-maker의 loop랑 review라고 예외일 리 없다. 이미 흡수당한 걸로 치는 게 맞다.

그래서 묻게 된다. 앞으로 harness engineering엔 뭐가 남을까. prompt에서 context로, context에서 harness로 넘어왔는데. 이것도 결국 prompt engineering이나 context engineering처럼 한 시절 반짝하고 사라지는 용어일까.

요즘 Claude Code vanilla로 돌아가는 사람이 주변에 부쩍 보인다. 그럴 만하다. vanilla는 앞으로 더 세지고 더 개인화될 거고, 쓸 만한 건 죄다 native로 빨려 들어간다. 그러면 남는 건 정의상 딱 하나다. 유용한 기능은 전부 흡수됐으니, 그 자리엔 Claude가 구조적으로 안 하거나 못 하는 것만 걸린다.

예를 들면 vendor-neutral한 기능. 그리고 vendor한테 적대적인 기능. 이런 건 살아남는다. ccusage 같은 도구가 그렇다. 내 토큰 비용을 로컬 로그에서 추적해 덜 쓰게 만드는 물건. vendor가 제 매출 깎아먹을 걸 만들 리 없기 때문이다. 방법론적인 취향도 짧게나마 당분간은 버틴다고 본다. 방법론적인 취향이라는 건, 몇몇 OSS 하네스가 workflow를 인코딩해둔 것을 말한다. SDD를 강제하는 workflow, plan을 짜거나 spec을 정의할 때 deep interview를 강제하는 방법론, 뭐 그런 것.

그런데 이것도 오래는 못 간다. dynamic한 취향 설정이든 방법론 설정이든, 유용하다고 판명되는 순간 vendor가 vanilla에 기본으로 넣어버린다. 그럼 곧장 흡수다.

그래서 나는 이제 흡수가 뻔한 자리엔 하네스를 더 쌓지 않는다. vendor가 구조적으로 못 가거나 안 갈 자리에만 시간을 쓴다.

결국 OSS든 개인 하네스든, 벤더가 내 취향을 학습하게 만드는 training signal이다. 잘 인코딩할수록 더 빨리 학습당하고, 더 빨리 낡는다. 다만 그 짧은 전환기 동안만큼은, 이게 진짜 leverage가 된다.