TL;DR

  • 소프트웨어 개발에서 팀 간 가장 중요한 인터페이스인 티켓은 조직의 업무와 성공 지표를 결정하므로 LLM(대형 언어 모델)에 맡기지 않고 직접 작성해야 함.
  • 티켓은 장황할 필요 없이 문제를 최대한 정확하게 설명해야 함.
  • 해결책을 제시하면 문제 설명의 효과가 줄어들 수 있으므로 사용자 스토리 등 필요한 경우에만 신중하게 포함해야 함.
  • 해결책을 적을 때는 가정을 밝히고, 주니어 구성원이 이해하기 어려운 전문 용어를 풀어 쓰며, 지나치게 처방적인 표현을 피해야 함.
  • 티켓은 엔지니어링, 프로젝트 관리, 고객 성공, 영업이 만나는 중요한 인터페이스이므로 직접 작성하는 역량을 길러야 함.

티켓은 문제를 정확히 설명해야 함

  • 2026년 9월 29일 기준, 티켓은 소프트웨어 개발에서 팀 간 가장 가치 있는 단일 인터페이스임. LLM으로 작성하지 말아야 함.
  • 티켓은 조직이 어떤 업무를 수행할지 결정하는 주요 수단이며, 성공을 측정하는 지표도 정의함.
  • 따라서 티켓 이름은 극도로 신중하게 정해야 함. 단어 하나가 잘못되면 개발 시간을 낭비하거나, 간단한 문제에 복잡한 해결책을 적용하게 될 수 있음.
  • 좋은 티켓은 문제를 가능한 한 정확하게 설명함. 반드시 철저하게 상세할 필요는 없으며, 정확성이 핵심임.
  • 좋은 문제 설명은 지렛대의 긴 쪽을 누르는 것과 같음. 적은 힘으로도 큰 효과를 냄.

해결책을 제시할 때의 주의점

  • 좋은 티켓에 문제의 해결책이 포함되는 경우도 있음. 사용자 스토리로 표현하는 것이 유용하다면 그렇게 작성하는 등, 상황에 맞는 관례를 따를 수 있음.
  • 다만 해결책을 설명하기 시작하면 지렛대 효과가 줄어듦. 지렛대의 받침점에 가까운 곳에서 힘을 쓰는 셈이며, 단순히 문제를 설명할 때보다 원하는 결과를 얻는 데 더 큰 힘과 섬세함이 필요함.
  • 해결책의 형태를 실제로 알고 있다고 생각하더라도 포함하기 전에 잠시, 말 그대로 1분 동안 다시 검토해야 함.
  • 특정 가정을 하고 있다면 이를 명시해야 함. 주니어 구성원이 이해하지 못할 전문 용어를 사용한다면 명확히 설명해야 함.
  • 해결책은 정보 손실이 있는 형식임. 지나치게 지시적인 해결책을 제시하기보다 가능한 접근 방식을 설명하는 편이 나음.
  • 팀원들이 스스로 방향을 찾을 수 있다고 신뢰하고, 막힐 때 도와야 함. 그러면 팀원들이 더 많이 배움.

티켓 작성은 직접 해야 함

  • LLM은 사소해 보이는 많은 일을 실제로 사소하게 처리함. 문제는 어떤 일이 사실은 사소하지 않을 때임.
  • 좋은 티켓을 작성하는 일은 어렵지 않지만, 그 노고는 주목받지 못함. 그럼에도 티켓은 소프트웨어 조직에서 가장 중요한 인터페이스 중 하나임.
  • 티켓은 엔지니어링, 프로젝트 관리, 고객 성공, 영업이 꾸준히 만나는 지점임.
  • 따라서 티켓 작성 역량을 키워야 함. 이는 티켓을 직접 작성한다는 뜻임.