대기업으로 이직하고 나서 가장 먼저 느낀 문화 충격은 '도구의 무게'였습니다. 스타트업 시절에는 옆자리 동료에게 "야, 서버 띄웠어?" 하고 소리치면 끝날 일을, 여기서는 지라(Jira) 티켓을 생성하고, 담당자를 지정하고, 워크플로우 상태를 변경하고, 컨플루언스(Confluence)에 문서를 남겨야 비로소 '일'이 시작되더군요. 솔직히 말해 처음엔 이 과정이 너무 답답했습니다. "개발은 언제 하지?"라는 생각이 머릿속을 떠나지 않았죠. 하지만 시간이 지나면서 깨달은 건, 이 복잡함이 때로는 안전장치가 되지만, 개인의 '몰입'을 방해하는 거대한 장벽이 되기도 한다는 사실이었습니다.
3년 차 즈음, 저는 소위 '생산성 도구 덕후'였습니다. Notion, Linear, Trello 등 힙하다는 툴은 다 써봤고, 복잡한 자동화 스크립트를 짜는 데 주말을 바쳤습니다. 그런데 어느 날, 배포 일정이 닥쳤는데 정작 기능 구현은 뒷전이고 티켓 상태를 동기화하느라 진땀을 빼고 있는 저를 발견했습니다. 배보다 배꼽이 더 큰 상황이었죠. 그때 뼈저리게 느꼈습니다. 도구가 일을 하게 만들어야지, 내가 도구를 위해 일해선 안 된다는 것을요.
최근 해커뉴스(Hacker News)에서 발견한 wedow/ticket이라는 프로젝트는 저의 이런 고민을 정확히 꿰뚫고 있었습니다. 이 도구는 기존의 beads라는 툴을 대체하기 위해 만들어졌는데, 핵심은 '극단적인 단순함'입니다. 데이터베이스도, 별도의 서버도 없습니다. 그저 단일 Bash 스크립트 하나와 Git만 있으면 됩니다.
이 도구의 철학은 명확합니다. "티켓은 Markdown 파일이어야 한다." 이게 왜 중요할까요? 우리는 지금 AI의 시대를 살고 있습니다. 제가 최근 코드를 짤 때 가장 많이 하는 행동은 IDE(통합 개발 환경)와 Claude, 혹은 Cursor 사이를 오가며 컨텍스트를 주입하는 일입니다. 기존의 복잡한 이슈 트래커들은 데이터를 JSONL 형태로 덤프하거나 API를 호출해야만 AI에게 정보를 줄 수 있습니다. 하지만 ticket은 .tickets/ 폴더에 있는 Markdown 파일 그 자체를 티켓으로 씁니다.
개발자는 그저 터미널에서 tk create로 할 일을 만들고, tk dep으로 의존성을 연결하면 끝입니다. jq나 ripgrep 같은 가벼운 리눅스 도구들이 뒤에서 조용히 움직일 뿐이죠. 특히 인상적인 건 AI 에이전트와의 호환성입니다. 수만 줄의 JSON을 컨텍스트 윈도우에 구겨 넣을 필요 없이, 그냥 Markdown 파일을 읽게 하면 끝납니다. 파일명에 티켓 ID가 포함되어 있어 VS Code 같은 에디터에서 Cmd+Click으로 바로 이동할 수도 있고요.
저는 이 프로젝트를 보며 다시금 '적정 기술'의 가치를 생각하게 되었습니다. beads라는 이전 도구는 SQLite를 동기화하기 위해 백그라운드 데몬이 필요했다고 합니다. 하지만 ticket은 그런 거추장스러운 것들을 다 걷어냈습니다. 우리 개발자들은 종종 더 멋진 아키텍처, 더 복잡한 기능을 추구하며 희열을 느낍니다. 하지만 진짜 실력은 문제를 해결하는 가장 '단순한' 방법을 찾아내는 데에서 나옵니다.
물론 팀 규모가 커지면 엔터프라이즈급 솔루션이 필요합니다. 저도 회사에서는 얌전히 지라를 씁니다. 하지만 개인 프로젝트나 소규모 팀, 혹은 나만의 로컬 태스크 관리를 위해서라면 무거운 웹 기반 툴보다 이런 터미널 기반의 도구가 훨씬 강력할 수 있습니다. 마우스에 손을 올리는 시간조차 아까운 '몰입의 순간'을 지켜주니까요.
여러분도 지금 쓰고 있는 도구가 나를 돕고 있는지, 아니면 나의 에너지를 갉아먹고 있는지 한번 점검해 보셨으면 합니다. 화려한 대시보드와 그래프에 현혹되지 마세요. 결국 코드를 짜고 가치를 만들어내는 건 도구가 아니라, 모니터 앞에 앉은 여러분 자신이니까요. 복잡함을 걷어내고 본질에 집중하는 것, 그것이 8년을 구르며 제가 얻은 생존 전략입니다.
