AI 티 나는 문장은 다른 모델로 지운다, 코드는 포니테일로 맞춘다

오전 9시36분, 한 참여자가 "ai로 ppt 틀잡을때 어색한 텍스트는 어떻게하시나요 다들? 너무 ai 스러운 텍스트들이 나오는데 페이블로해도"라고 물으며 대화가 시작됐다. 9시42분 "sonnet이나 luna 같은 것으로 검토시키면 꽤 지워지긴 하더군요"라는 답이 붙었고, 곧이어 "luna가 저런 말투 제일 잘해요"라는 평가가 이어졌다.

저녁 5시49분에는 화제가 코드 쪽으로 옮겨갔다. "고수님들 질문 하나 드립니다. ponytail 이 astra 의 성능 발휘에 장애가 될까요? 혹시 그렇다면 적절히 사용하는 방법은 무엇일까요?"라는 물음에, 5시51분 "코드 구현이 좀 아리까리 할 때에는 ponytail 플러그인으로 정합성 검사하고", "조건 상황에서 새로운 함수를 만들거나 재사용하게 agents.md 나 claude.md 에 넣으면 좋음"이라는 구체적인 요령이 돌아왔다. 이날 이 화두에는 7명이 참여해 40건의 발화를 남겼다.

두 팁은 서로 다른 모델·도구를 문제 해결에 쓴다는 공통점을 지닌다. 말투 교정에서는 글을 쓴 모델이 아닌 다른 모델(sonnet·luna)에게 검토를 맡기는 교차 검증 방식이 쓰였고, 코드 정합성에서는 포니테일(ponytail)이라는 별도 플러그인으로 점검한 뒤 그 규칙을 agents.md·claude.md 같은 설정 파일에 박아 재사용하는 방식이 제안됐다. 두 경우 모두 한 도구·한 모델에 기대기보다, 역할을 나눠 서로 점검하게 하는 구조를 취하고 있다는 점에서 공통된 작업 습관을 보여주는 것으로 보인다.

이 두 팁이 같은 날 나란히 공유됐다는 점도 눈에 띈다. 문서 작업에서는 말투를, 코드 작업에서는 정합성을 각각 다른 확인 절차로 관리하려는 시도가 같은 방에서 동시에 나타난 셈이다. 이는 결과물을 한 번에 완성하기보다 일단 만들어보고 별도 단계에서 다듬는 이중 확인 흐름이 실무에서 자연스럽게 자리잡아가고 있음을 시사한다.

전일 digest에는 이 두 화두가 따로 등장하지 않아 직접 비교할 추세는 확인되지 않는다. 다만 전날에도 아스트라의 성능 저하 불만이 이어졌던 만큼, 오늘 나온 "ponytail 이 astra 의 성능 발휘에 장애가 될까"라는 질문은 그 연장선에서 나온 우려로 읽힌다. 도구 하나를 더 얹었을 때 원래 모델의 성능이 흔들리지 않는지를 미리 점검하려는 조심스러운 태도로 보인다. 새 도구를 무작정 받아들이기보다 먼저 부작용 가능성부터 묻는 이런 태도는, 이 방이 도구 도입에서도 검증을 앞세우는 습관을 공유하고 있음을 보여주는 것으로 읽힌다.