소프트웨어 티켓은 LLM에 맡기지 말고 문제를 직접 정확히 써야 한다

티켓 작성의 책임을 LLM에 넘기지 말라는 주장은 설득력 있지만, LLM을 아예 쓰지 말라는 결론은 지나치게 넓습니다. 티켓은 팀이 무엇을 문제로 보고 어떤 결과를 성공으로 판단할지 정하는 인터페이스라고 기사도 강조합니다. 그렇다면 핵심은 누가 문장을 타이핑했느냐보다, 누가 문제의 정의와 우선순위, 완료 기준에 책임을 지느냐에 있다고 봅니다.

기사가 짚은 가장 중요한 위험은 해결책이 문제를 가리는 순간입니다. 잘못된 해결책이 티켓에 먼저 박히면, 팀은 더 나은 방법을 찾기보다 처방을 구현하는 데 집중할 수 있습니다. 특히 티켓 제목과 짧은 설명이 조직의 주의를 어디로 돌릴지 결정한다는 점에서, 표현을 검토하고 가정을 드러내는 일은 단순한 문서 작업이 아닙니다. 이 판단을 모델에 맡기면 맥락의 빈틈까지 그럴듯한 문장으로 덮을 가능성이 큽니다.

다만 LLM은 문제를 대신 정하는 도구가 아니라 문제 정의를 시험하는 편집자로 쓸 수 있습니다. 초안을 만든 뒤 “이 설명에서 모호한 요구는 무엇인가”, “해결책을 사실처럼 가정한 문장은 어디인가”, “주니어 구성원이 오해할 용어는 무엇인가”를 물으면 작성자가 놓친 구멍을 발견하는 데 도움이 될 수 있습니다. 이런 용도는 책임을 넘기는 것과 다릅니다. 최종 문장과 판단을 사람이 검증하고 승인해야 한다는 조건이 붙습니다.

기사의 “직접 작성해야 한다”는 표현은 팀의 책임감을 강조하는 데는 효과적이지만, 작성 노동 자체를 전문성의 증거처럼 만들 위험도 있습니다. 고객 성공이나 영업에서 들어온 문제를 엔지니어 한 사람이 혼자 번역하면, 현장의 맥락이 빠질 수 있습니다. 티켓이 여러 팀이 만나는 지점이라면 작성자는 한 명일 수 있어도, 문제의 사실관계와 성공 기준은 관련자들이 함께 확인하는 편이 낫습니다.

그래서 더 유용한 규칙은 “LLM에게 티켓을 맡기지 말라”가 아니라 문제의 소유권을 자동화하지 말라일 겁니다. 모델이 만든 초안이라도 담당자가 사용자 영향, 재현 조건, 가정, 완료 기준을 확인하고, 해결책을 제시했다면 왜 필요한지 설명해야 합니다. 그 검토를 할 수 없다면 모델이 아니라 티켓 자체가 아직 준비되지 않은 셈입니다.

앞으로 LLM이 티켓 초안 작성을 더 쉽게 만들수록, 티켓 수는 늘어도 중요한 문제를 가려내는 능력은 저절로 좋아지지 않을 가능성이 큽니다. 오히려 작성이 쉬워진 만큼 검토와 우선순위 판단이 더 중요해질 겁니다. 좋은 티켓의 기준은 사람이 처음부터 끝까지 혼자 썼는지가 아니라, 팀이 같은 문제를 보고 올바른 결과를 향해 움직이게 하는지에 있어야 합니다.