구조가 생긴 이유를 묻는다는 것

AI 에이전트, 하네스 엔지니어링, 워크플로우 공개 같은 콘텐츠를 자주 보게 된다.

처음에는 꽤 좋아 보인다. 누군가가 실제로 Claude Code를 어떻게 쓰는지, 어떤 흐름으로 AI에게 일을 맡기는지, 어떤 방식으로 반복 작업을 줄이는지 보여주는 일은 분명 도움이 된다.

나도 처음에는 저렇게 세팅하면 더 빨리 만들 수 있지 않을까 생각했다.

그런데 같은 영상을 몇 번 다시 보다 보면, 방법보다 다른 것이 보이기 시작한다.

그 구조는 왜 그렇게 생겼을까.

따라 하는 것도 배움이다

누군가의 방법을 먼저 따라 해보며 배우는 방식은 유효하다. 처음부터 모든 이유를 이해하고 시작하는 사람은 많지 않다.

손이 먼저 가고, 머리가 나중에 따라오는 배움도 있다. 직접 해봐야 왜 그렇게 짰는지 느껴지는 경우도 있다.

이 글은 그런 방식을 부정하려는 것이 아니다.

저 구조는 왜 필요했을까.

그 사람은 어떤 문제를 반복해서 겪었을까. 내 프로젝트도 같은 병목을 가지고 있을까.

같은 도구를 쓴다고 해서, 같은 문제를 가지고 있다는 뜻은 아니다.

워크플로우는 단순한 세팅 모음이 아니다.

어떤 명령어를 저장해두었는지, 어떤 에이전트를 나누었는지, 어떤 훅을 걸었는지보다 먼저 보아야 할 것이 있다. 그 사람은 어디에서 반복해서 막혔는가. 무엇을 매번 다시 설명해야 했는가. 어떤 판단을 줄이고 싶었는가.

워크플로우는 그런 반복의 흔적에 가깝다. 불편함이 쌓이고, 실수가 반복되고, 그때마다 사람이 다시 붙잡아야 했던 기준이 구조로 남은 것이다.

겉모양은 빌릴 수 있다. 하지만 그 구조를 만들어낸 문제는 각자의 것이다.

좋은 방법을 따라 하는 일도 배움이다. 하지만 그 방법이 왜 생겼는지 묻는 일은, 그 배움을 내 것으로 만드는 과정에 가깝다.

따라 하는 것은 시작이 될 수 있다. 이유를 묻는 순간, 그 구조는 남의 방식에서 내 판단의 재료가 된다.

구조를 빌리는 일은 나쁘지 않다. 다만 그 구조가 내 문제를 대신 찾아주지는 않는다.

내가 무엇을 만들고 있는지, 어디에서 반복해서 막히고 있는지, 무엇을 자동화하고 무엇을 직접 판단해야 하는지 말할 수 있을 때, 남의 워크플로우는 비로소 쓸모 있는 참고가 된다.

그전까지 그것은 답이라기보다, 아직 내 문제에 닿지 않은 좋은 모양일 뿐이다.