첫 동아리 프로젝트 ‘쉐프’, CRUD인 줄 알았는데요

대덕소프트웨어마이스터고에 입학하고 처음으로 동아리 프로젝트를 시작했다. 내가 낸 아이디어가 실제 프로젝트가 됐고, 처음 들어보는 문서들을 작성했으며, 자신 있게 시작한 개발에서는 예상보다 훨씬 자주 막혔다.

처음에는 ‘프롬프트를 공유하는 CRUD 프로젝트니까 해볼 만하지 않을까?’라고 생각했다. 그때는 내가 Spring Security와 JWT 앞에서 얼마나 오래 멈춰 서게 될지 몰랐다.

내 아이디어가 우리 프로젝트가 되었다

시작은 동아리 정규 회의였다. 선배님들은 1학년 프로젝트를 시작해 보자며 각자 아이디어를 세 개씩 준비해 오라고 하셨다.

나도 나름대로 고민한 아이디어 세 개를 준비했다. 그중 최종적으로 선택된 것은 내가 제안한 ‘Share Prompt’, 줄여서 ‘쉐프’였다.

쉐프는 자신이 작성한 AI 프롬프트를 다른 사람들과 간편하게 공유할 수 있는 서비스다. 프롬프트를 등록하고, 조회하고, 수정하고, 삭제하는 CRUD 기능을 중심으로 기획했다.

내 아이디어가 선택되니 기분이 좋았다. 동시에 머릿속에만 있던 서비스를 우리가 직접 만들어야 한다는 사실이 조금씩 실감 났다.

“이 부분은 어떻게 할 생각이야?”

아이디어를 정한 뒤에는 1학년 세 명이 따로 모여 회의했다. 팀 구성은 백엔드 두 명, Flutter 한 명이었다. 필요한 기능과 서비스의 모습을 이야기하며 기획을 구체화했다.

우리끼리는 어느 정도 정리가 됐다고 생각했다. 하지만 동아리 시간에 기획 내용을 보여드리자, 선배님들은 우리가 미처 생각하지 못한 문제들을 하나씩 짚어주셨다.

설명을 듣고 다시 살펴보니 빈틈이 생각보다 많았다. 회의할 때는 자연스럽게 넘어갔던 부분도, 실제로 구현하려고 생각하면 결정되지 않은 것이 많았다.

문제들을 수정한 뒤에는 새로운 과제가 기다리고 있었다.

기능 명세서, API 명세서, 그리고 ERD 작성.

당시 나는 주로 김영한 님의 자바 강의를 보며 공부하고 있었다. 코드를 따라 작성하는 일에는 조금 익숙해졌지만, 프로젝트를 시작하기 전에 어떤 문서를 만들고 무엇을 정리해야 하는지는 잘 몰랐다.

기능 명세서는 서비스가 제공할 기능을 정리하는 문서이고, API 명세서는 클라이언트와 서버가 어떤 요청과 응답을 주고받을지 정하는 문서였다. ERD는 데이터와 그 관계를 설계하는 그림이었다.

설명을 듣고 나니 무엇인지는 알겠는데, 막상 직접 작성하려니 어디서부터 시작해야 할지 막막했다.

다행히 선배님들이 본인들의 프로젝트에서 사용한 기능 명세서와 API 명세서를 보여주시고, ERD를 설계할 때 참고할 자료도 보내주셨다. 덕분에 우리도 방향을 잡고 생각보다 빠르게 초안을 완성했다.

물론, 빠르게 작성했다고 잘 작성한 것은 아니었다.

문서에서 남겨둔 빈틈은 코드에서 다시 만난다

작성한 문서를 회의 시간에 보여드렸더니, 이번에도 빠진 부분이 많다는 피드백을 받았다.

선배님들은 기능 명세서와 API 명세서, ERD에 빈틈이 많으면 나중에 코드를 작성할 때 훨씬 힘들어진다고 말씀하셨다.

처음에는 프로젝트를 시작하기도 전에 정리할 것이 왜 이렇게 많은지 싶었다. 그런데 피드백을 반영하다 보니, 문서를 작성하는 과정 자체가 우리가 만들 서비스를 제대로 이해하는 과정이었다.

‘이 정도면 됐겠지’ 하고 넘어간 부분은 아직 팀 안에서 답을 정하지 못한 부분이기도 했다. 지금 결정하지 않으면 결국 개발하다가 다시 멈춰서 이야기해야 했다.

그렇게 문서의 빈틈을 채우다 보니 어느새 여름방학이 됐다. 디자인도 1학년끼리 진행했고, 그 과정에서도 동아리 선배님이 많은 도움을 주셨다.

이제 본격적으로 개발할 차례였다. GitHub 저장소를 만들고 각자 맡은 작업을 시작했다.

CRUD를 조금 해봤다고 괜찮을 줄 알았다

내가 맡은 부분은 Spring Security를 활용한 인증·인가 기능이었다.

CRUD 코드를 몇 번 작성해 본 경험이 있어서, 처음에는 공부하면서 충분히 구현할 수 있을 거라고 생각했다. 하지만 체감 난도는 과장 조금 보태서 다섯 배쯤 됐다.

CRUD를 구현할 때와는 달리, 코드 하나를 이해하려고 하면 그 앞뒤의 처리 흐름까지 함께 알아야 했다. 낯선 개념이 이어지니 어디서부터 이해해야 할지도 헷갈렸다.

그런데 어려운 기술보다 더 큰 문제는 내 태도였다.

방학 동안 마음이 느슨해졌고, 개발을 거의 진행하지 못했다. 시간이 많다는 생각으로 미루다 보니, 얼마 만들지도 못한 채 방학이 끝났다.

개학하고 작업한 내용을 돌아보는데 이런 생각이 들었다.

그 많은 시간 동안 내가 개발한 게 겨우 이 정도라고?

스스로에게 화가 났다. 뒤처지고 있다는 생각도 들었다. 그렇다고 지나간 방학을 되돌릴 수는 없으니, 막혀 있던 Spring Security와 JWT부터 다시 공부하기로 했다.

일단 짜고 나중에 이해하려고 했는데

처음에는 코드를 완성한 뒤에 자세히 공부하려고 했다. 일단 동작하게 만들고, 그다음에 이해하면 될 거라고 생각했다.

하지만 직접 개발해 보니 이 방식은 나와 잘 맞지 않았다.

코드의 역할을 정확히 모르는 상태에서는 다음 코드를 작성하기도 어려웠다. 오류가 발생하면 어디를 살펴봐야 할지 몰랐고, 수정하면서도 내가 제대로 고치고 있는지 확신이 없었다.

그래서 공부하는 순서를 바꿨다. 코드를 작성하면서 각 부분의 역할을 살펴보고, 전체적인 처리 흐름을 이해하는 데 시간을 들였다.

주로 Spring 공식 문서와 티스토리의 기술 글, 선배님들의 코드를 참고했다. 오류가 발생했을 때는 ChatGPT를 활용해 오류 메시지를 해석했고, 혼자 해결하기 어려운 부분은 선배님들께 도움을 받았다.

처음에는 하나하나 확인하는 과정이 느리게 느껴졌다. 그런데 전체 흐름이 조금씩 보이기 시작하자 오히려 코드가 더 잘 써졌다. 무엇을 해야 하는지 알고 작성하는 것과, 잘 모르는 채 일단 작성하는 것의 차이가 생각보다 컸다.

적어도 나에게는, 이해하는 데 쓰는 시간이 개발을 앞으로 나아가게 하는 시간이었다.

마지막까지 헷갈렸던 JWT

조금씩 개발에 속도가 붙을 무렵, JWT 구현에서 다시 막혔다.

특히 어려웠던 부분은 JwtProvider였다. 내가 작성하던 코드에서는 이 클래스가 담당하는 일이 많게 느껴졌고, 각각의 역할이 전체 인증 흐름에서 어떻게 이어지는지 헷갈렸다.

개별 코드를 읽는 것과 그 코드들이 연결된 흐름을 이해하는 것은 또 다른 일이었다.

이번에도 동아리 선배님의 도움을 받으며 막힌 부분을 풀어나갔다. 혼자 볼 때는 복잡하게만 느껴졌던 코드도, 역할과 흐름을 차근차근 짚어보니 조금씩 정리됐다.

그렇게 지금은 JWT 구현을 마친 상태다.

아직 완성되지 않은 프로젝트에서 배운 것

쉐프는 아직 개발 중이다. 그래서 이 글은 프로젝트를 완성한 뒤 쓰는 회고라기보다, 첫 프로젝트를 진행하면서 남기는 중간 기록에 가깝다.

지금까지 가장 크게 달라진 것은 개발을 바라보는 방식이다. 처음에는 아이디어를 정하고 코드를 작성하면 프로젝트가 만들어질 줄 알았다. 직접 해보니 기능을 구체화하고, 팀원끼리 기준을 맞추고, 내가 작성하는 코드의 동작을 이해하는 데도 많은 시간이 필요했다.

방학을 제대로 활용하지 못한 아쉬움도 남는다. 그래도 그 경험 덕분에 내 공부 방식과 개발 태도를 돌아볼 수 있었다.

그리고 이 과정마다 선배님들의 도움이 있었다. 기획의 문제를 짚어주시고, 처음 보는 문서의 예시를 공유해 주시고, 막힌 코드를 함께 살펴봐 주셨다. 이번 프로젝트에서 받은 도움은 나중에 내가 후배를 도울 때도 기억하고 싶다.

다음에 쉐프에 관한 글을 쓸 때는 완성된 서비스를 소개할 수 있으면 좋겠다. 그때는 지금 어렵게 느끼는 것들을 얼마나 자연스럽게 설명할 수 있을지도 궁금하다.