사이드 프로젝트로 시작해 사내 업무 시스템에 적용하기 — Node.js, Prisma, GraphQL

새 기술은 보통 사이드 프로젝트에서 먼저 만난다. 나도 Node.js 기반으로 작은 서비스를 만들며 Prisma와 GraphQL 조합을 익혔고, 그 감각을 나중에 사내 일정관리 사이트에 옮겨 본 적이 있다. 흥미로웠던 점은 개인 프로젝트에서는 매끄럽게 보이던 구조가 실무에 들어오면 바로 다른 질문을 받는다는 사실이었다. 누가 유지보수할지, 데이터 모델을 얼마나 예측 가능하게 만들지, 기존 화면 흐름과 어떻게 연결할지가 훨씬 중요해졌다. 덕분에 "새 기술 적용"보다 "조직 안에서 읽히는 구조 만들기"가 핵심이라는 걸 더 분명히 배웠다.

Prisma를 쓰면서 가장 좋았던 부분은 데이터 모델을 코드와 함께 읽기 쉬운 형태로 다룰 수 있다는 점이었다. 기존에 MongoDB 중심으로 빠르게 만들던 화면은 자유도가 높은 대신, 시간이 지나면 데이터 구조가 머릿속에만 남기 쉬웠다. 반면 PostgreSQL과 Prisma 조합은 스키마를 기준으로 대화를 나누기 편했다. GraphQL도 처음에는 멋진 선택처럼 보이지만, 실제로는 화면이 필요한 데이터 단위를 정리해 주는 도구로 접근했을 때 더 실용적이었다. 필요한 필드만 명확히 가져오는 구조는 일정관리 같은 업무 화면에서 생각보다 큰 장점이 됐다.

물론 그대로 옮기면 끝나는 일은 아니었다. 사이드 프로젝트에서는 내가 모든 맥락을 알고 있으니 빠르게 결정할 수 있지만, 사내 시스템은 다른 개발자와 운영 담당자도 함께 봐야 한다. 그래서 스키마 이름과 리졸버 책임을 최대한 단순하게 유지하려고 했다. 실무에서는 화려한 추상화보다 "이 데이터는 여기서 온다"가 분명한 구성이 오래 간다. 그 차이를 몸으로 배우면서 기술 선택 기준도 조금 바뀌었다.

지금 돌아보면 사이드 프로젝트의 진짜 가치는 결과물보다 실험장을 가진 데 있었다. 실무에 바로 들이기 어려운 조합을 미리 써 보며 장단점을 체감했기 때문에, 실제 적용 때도 무리하지 않고 필요한 만큼만 가져올 수 있었다. 다음에도 새로운 스택을 익힌다면 먼저 작은 서비스에서 검증하고, 실무에는 팀이 이해할 수 있는 밀도로 번역해서 넣을 생각이다.