이슈 트래커는 쓰레기통이 아닙니다: Ghostty의 결정에서 배운 것

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

개발자라면 누구나 한 번쯤 들어보셨을 새로운 터미널 에뮬레이터 프로젝트, Ghostty의 저장소를 살펴보다가 흥미로운 정책 하나를 발견했습니다. 보통의 오픈소스 프로젝트와 달리 사용자가 직접 ‘Issue(이슈)’를 생성할 수 없도록 막아둔 것입니다. 버그를 제보하거나 기능을 요청하려면 반드시 ‘Discussions(토론)’ 탭을 먼저 거쳐야 한다는 규칙이었죠.

처음에는 다소 폐쇄적인 정책이 아닌가 싶었지만, 그 이유를 설명한 메인테이너의 글을 읽고 무릎을 쳤습니다. 그리고 우리 풀링포레스트의 엔지니어링 문화, 더 나아가 개발 조직이 겪는 고질적인 문제에 대해 다시금 생각하게 되었습니다.

솔직히 고백하자면, 저 역시 주니어 시절에는 무언가 잘 동작하지 않으면 일단 이슈부터 등록하곤 했습니다. "이거 안 돼요", "로그인 안 됨" 같은 제목으로 말이죠. 반대로 시니어 개발자나 리더가 된 이후에는 그런 불친절하고 정제되지 않은 티켓들을 처리하느라 하루 업무 시간의 절반을 날려버린 적도 많았습니다.

Ghostty의 메인테이너인 미첼 하시모토(Mitchell Hashimoto)가 밝힌 통계는 꽤 충격적이면서도 공감이 갑니다. 사용자가 ‘버그’라고 생각해서 올리는 제보의 80~90%는 실제 소프트웨어의 결함이 아니라, 사용자의 오해나 환경 설정 문제, 혹은 단순한 설정 오류라는 것입니다. 나머지 10% 중에서도 상당수는 ‘버그’가 아니라 아직 구현되지 않은 ‘기능 요청’이고요.

문제는 이 섞여 있는 정보들이 개발자의 작업 공간인 ‘이슈 트래커’로 쏟아져 들어올 때 발생합니다. 개발자가 코드를 작성하고 문제를 해결해야 할 공간이, 질문과 답변, 하소연이 뒤섞인 ‘게시판’으로 변질되는 순간 생산성은 급격히 떨어집니다.

Ghostty가 정의하는 이슈 트래커의 목적은 명확합니다. "명확하고 실행 가능한 항목(Well-understood, actionable item)"만이 이곳에 들어올 자격이 있다는 것입니다. Discussions에서 충분히 논의되어, 이것이 진짜 버그임이 확인되거나, 구체적인 스펙이 결정된 기능 요청만이 메인테이너에 의해 Issue로 승격됩니다.

이 방식은 개발자에게 심리적 안정감을 줍니다. "이슈 트래커에 있는 항목은 내가 지금 당장 코드를 짜서 해결할 수 있는 일감이다"라는 확신을 주기 때문입니다. 불필요한 커뮤니케이션 비용을 줄이고, 엔지니어링 리소스를 온전히 문제 해결에 집중하게 만드는 아주 영리한 전략입니다.

이 사례를 보며 우리 조직의 일하는 방식을 되돌아봤습니다. 기획팀이나 운영팀, 혹은 고객사로부터 들어오는 요청들이 과연 개발자가 바로 착수할 수 있는 ‘Actionable Item’의 형태를 갖추고 있을까요? 혹은 개발자들이 "재현 경로가 어떻게 되나요?", "어떤 브라우저 환경인가요?"라고 되묻는 핑퐁 게임에 지쳐가고 있지는 않은지 점검해야 합니다.

풀링포레스트에서는 이 문제를 해결하기 위해 AI를 적극적으로 도입하고 있습니다. 모호한 요청이 들어오면 LLM을 활용해 1차적으로 내용을 구체화하거나, 필수 정보(재현 시나리오, 기대 결과 등)가 누락되었을 때 자동으로 반려하고 추가 정보를 요구하는 봇을 실험 중입니다. 또한, 내부적으로도 ‘질문’과 ‘작업 요청’을 명확히 구분하는 문화를 정착시키려 노력하고 있습니다.

개발자의 시간은 비쌉니다. 하지만 그보다 더 중요한 것은 개발자의 ‘몰입’입니다. 노이즈를 필터링하고, 진짜 중요한 문제에 집중할 수 있는 환경을 만들어주는 것. 그것이 기술 리더가 해야 할 가장 중요한 역할 중 하나라고 생각합니다.

여러분의 이슈 트래커는 지금 건강한가요? 아니면 온갖 잡음이 섞인 쓰레기통이 되어가고 있나요? Ghostty의 단호한 결정을 보며, 우리 팀의 생산성을 지키기 위한 ‘문지기’ 역할을 어떻게 수행해야 할지 한 번쯤 고민해 보셨으면 좋겠습니다.