로버트 C. 마틴 "하네스 다시 생각해보기"

소프트웨어 장인정신의 기준을 세운 그의 말을 꼭 들어보시길. 클린 코드 부터..

💬

요즘은 생각을 조금 다시 해볼 때가 된 것 같아요.

지난 몇 달 동안 저는 에이전트들을 모아서 오케스트레이션하는 하네스를 만들고 있었습니다.

에이전트끼리 일을 넘기면서도 서로의 컨텍스트를 오염시키지 않는 방법을 찾느라 꽤 애를 먹었고요.

각 에이전트가 엉뚱한 방향으로 가거나 바보 같은 일을 하지 않도록, 쓸 수 있는 결정론적 도구들을 정해 주는 작업에도 공을 많이 들였습니다.

그래서 결국 돌아가게 만들었고, 하네스가 작동하기 시작한 뒤에 몇 가지를 측정해 봤어요. 그러다 이런 생각이 들었습니다.

“같은 일을 에이전트 하나한테만 시켜 보면 어떨까?”

그런데 에이전트 하나가, 그 하네스보다 꽤 큰 차이로 더 잘했습니다.

그 결과물을 보면서 문득 이런 생각이 들었어요. “잠깐만요, 얘네가 원래 이 정도는 아니었는데요?” 에이전트들이 정말 많이 좋아진 겁니다.

그래서 실험을 몇 번 더 해봤습니다. 예를 들면, 제 하네스라면 서너 시간이 걸리고, 결과도 “그럭저럭 쓸 만하지만 썩 뛰어나진 않은” 수준의 작업이 있었어요.

그걸 이제 Grok 인스턴스 하나가 40분 만에 해내고, 하네스보다 더 잘합니다.

문제는 그 하네스도 같은 Grok 모델을 쓰고 있었다는 점이에요.

그렇다면 손상을 입히고 있는 쪽은 하네스 쪽이라는 얘기입니다. 이건 제가 예상한 바가 아니었어요.

그래서 실험을 하나 해봤습니다.

하네스가 아니라, Grok 에이전트 하나에게 아주 사소하지는 않은 일을 맡겼어요.

프롬프트는 단순하게 주고, 일은 만만치 않은 걸로요.

그 에이전트가 40분 동안 그 일을 하게 했습니다. 제가 걸어 두던 제약도 거의 다 풀었어요.

“CRAP은 12 아래로 유지하고, 뮤테이션 테스트 좀 하고, 유닛 테스트 좀 작성해. Gherkin 같은 건 하지 마. 그런 거 다 빼고 기본만 해.”

평소라면 CRAP을 6 아래로 유지하라고 했을 텐데, 이번에는 “아니, 12 아래면 된다”고 했습니다.

그리고 그냥 자리를 비우고 돌게 놔뒀어요. 40분 뒤에 보니 결과가 놀라울 정도로 좋았습니다.

완벽하진 않았어요. 자잘한 흠이 몇 개 있긴 했습니다.

그래도 하네스 결과보다는 훨씬 나았어요. 게다가 일부러 한 것도 아닌데 CRAP이 어차피 6 아래로 나왔습니다.

에이전트가 자기가 적절하다고 생각한 모듈로 쪼개 놨더니, CRAP이 전부 6 미만이 된 거예요. 그래서 “그래, 됐다” 싶었습니다.

뮤테이션 테스트는 어땠느냐고 물었더니, 버그와 빠진 부분을 찾는 데는 도움이 됐다고 했어요.

그런데 동시에 흉터도 남겼습니다. 그 흉터를 따라가 보니, 이건 제가 손봐야 할 문제라는 생각이 들었어요.

뮤테이션 테스트 알고리즘이 에이전트에게 멍청한 짓을 강요하기 때문입니다.

좋은 일도 하게 만들긴 해요. 그런데 그중 일부는 너무 멍청해서, “도대체 왜 이런 짓을 하는 거야?” 싶은 수준입니다. 그건 다음에 따로 설명하겠습니다.

아무튼, 이제 이걸 다시 생각해 볼 때예요.

어쩌면... 어쩌면 에이전트를 소프트웨어 설계 안의 부품처럼 취급하면 안 되는 건지도 모릅니다.

https://t.co/GxoYvIBRuG