이 프로젝트를 하면서 가장 의식했던 건 '기술적으로 멋진 것'을 만드는 게 아니라, 우리 팀에 정말 필요한 문제 해결에 집중하자는 것이었습니다. 릴레이 최적화, Supabase 마이그레이션 같은 기술적 선택도 모두 속도와 유지보수, 네트워크 트래픽 등 현실적인 조건을 반영한 결정이었고, 불필요한 오버 엔지니어링은 최대한 피하려고 노력했습니다. 단순히 기능을 제공하는 도구가 아니라, 팀이 자연스럽게 '일하는 방식'을 바꾸게 만드는 것이 핵심 목표였고, 실제로 그런 변화가 이루어졌다는 점에서 의미 있는 경험이었습니다.

이 시스템은 단순한 티켓 관리 도구가 아니라, 개발자, PM, 기획자, 팀장 모두가 함께 사용할 수 있도록 설계된 '일의 흐름'을 담은 구조였습니다. 예를 들어 개발자는 브랜치를 생성할 때 시스템의 티켓 번호를 따르도록 유도했고, PM은 구두가 아니라 시스템에 직접 업무를 등록하게 되었고, 관리자급은 트리 뷰를 통해 전체 일정을 한눈에 파악할 수 있게 되었습니다. 직관적인 UI나 풍부한 기능보다도, '팀이 지금보다 편하게 협업할 수 있는가?'를 계속 고민하며 설계했고, 15명 남짓한 팀원이 실제로 일상적으로 사용하는 도구가 되었다는 점에서 큰 보람이 있었습니다.

처음부터 완벽한 시스템을 만드는 것보다는, 일단 '써볼 수 있는 최소한'을 빠르게 만들어서 피드백을 받고 점진적으로 개선하는 방식이 가장 현실적인 접근법이라는 걸 이번 프로젝트에서 깊이 체감했습니다. AppSheet → Next.js + Google Sheets → Supabase + Relay로 점진적으로 구조를 바꾸면서도 항상 리소스 대비 효율이 높은 방향을 선택하려고 노력했고, 그 과정에서 '운영 가능한 기술 구조'가 얼마나 중요한지도 느꼈습니다. 특히 내가 없는 상황에서도 계속 쓰일 수 있는 시스템을 만드는 것이 혼자서 만드는 것보다 더 중요한 목표라는 것도 알게 되었습니다.

최소한의 리소스를 쓰려고 했지만, 아무래도 혼자 설계·개발·운영까지 하다 보니 주말이나 연휴, 야근 시간을 많이 썼습니다. 현재는 프리랜서라는 위치에서 자발적으로 할 수 있었지만, 정규직이었다면 오히려 이런 방식이 아닌 다른 접근도 가능했을 것 같습니다. 예를 들어 법무팀이나 운영팀에 도움을 요청하거나, 사내 툴 권한 부여를 공식적으로 협의하는 절차를 밟을 수도 있었을 것 입니다. 수평적인 조직이었다면, 동료들을 더 적극적으로 설득하는 방식도 고려할 수 있었을 것 같습니다. 이번 경험을 통해, 내가 직접 해결하지 않더라도 문제 해결을 위한 리소스를 조직 내부에서 확보하는 것도 하나의 중요한 스킬이라는 점을 느꼈습니다.