hwp 뽑는 도구가 마땅치 않자, 한 참여자는 이미지로 만들어 pdf로 냈다

9월 2일 저녁 6시 43분, 한 참여자가 hwp 문서를 잘 만들어 주는 도구가 없는지 물었다. kordoc mcp를 써 봤지만 결과물 품질이 너무 떨어진다는 게 이유였다. 참여자 2명이 13건을 주고받은 작은 화제였지만, 추천과 실사용 비교가 한자리에서 오갔다. 도구 이름을 묻는 질문이 곧바로 두 경로의 비교로 번진 셈이다.

"hwp 문서 잘만들어주는 거없을까요 흠.. kordoc mcp 써도 퀄리티가 넘 구데기로나와서"

대안은 저녁 7시 32분에 나왔다. Hwpx-skill을 써 보라는 짧은 추천이었다. 질문자는 그사이 다른 경로를 이미 시험한 뒤였고, 저녁 7시 36분에 자기 결론을 내놓았다. 양식을 주고 이미지로 생성한 다음 pdf로 만들게 하는 쪽이 낫겠다는 이야기였다.

"이미지생성식으로 뽑아서 pdf로만들어달라고하는게 나은거같네요"

그 판단에는 좌우 비교 결과가 함께 붙었다. 같은 양식을 두 방식으로 뽑아 나란히 놓고 견줬더니 이미지로 만든 쪽의 정확도가 더 높았다는 것이다. 추천한 쪽의 반응은 달랐다. 저녁 7시 43분, kordoc도 이 정도는 아닌데 이상하다는 말이 돌아왔다.

"오잉.. kordoc도 이정도는 아닌데"

같은 도구를 두고 체감이 정반대로 갈린 셈이다. 그래서 이야기는 원인을 도구 자체가 아니라 붙여 쓰는 방식에서 찾는 쪽으로 옮겨갔다. 에이전트에 물리지 말고 kordoc을 단독으로 돌려 보자는 검토가 곧바로 이어졌다. 변수를 하나씩 떼어 내 어디서 품질이 무너지는지 보자는 접근이다.

"kordoc을 아예따로? 써봐야하나 에이전트에 안붙이고"

질문자가 택한 대안 경로에는 대가가 따른다. 이미지로 생성해 pdf로 내면 화면에 보이는 양식은 맞출 수 있지만, 뒤에 고쳐 쓸 수 있는 한글 문서 파일 자체는 손에 남지 않기 때문이다. 그런데도 그쪽이 낫다는 판단이 나왔다는 것은, 이 자리에서 요구된 품질 기준이 편집 가능성보다 양식 재현 정확도에 있었음을 시사한다. 문서를 넘겨받는 쪽이 겉모습부터 확인하는 상황이라면 충분히 나올 수 있는 선택이다.

이 화제에 붙은 사람은 두 명뿐이었지만 오간 발화는 13건이었다. 추천 한 줄로 끝나지 않고 서로의 결과물을 대조하는 데까지 갔다는 뜻이다.

두 사람 사이의 짧은 대화지만 도구 평가가 갈리는 지점은 분명하게 드러났다. 같은 mcp를 쓰고도 한쪽은 쓸 수 없다고 하고 다른 쪽은 그 정도는 아니라고 하면, 남는 변수는 문서 양식의 난이도나 에이전트에 붙인 방식 같은 사용 환경이다. 도구 이름만으로는 결과 품질을 예측하기 어렵다는 점이, 단독 실행으로 조건을 좁혀 보자는 제안으로 이어진 것으로 보인다. 양식을 그대로 맞춰야 하는 작업일수록 추천 목록보다 각자의 실행 조건을 대조하는 대화가 더 실질적인 정보가 된다.