2025 제주 갭이어(5)

개발이라는 현실, 눈앞의 흐름을 쫓다

제주에 도착한 이후, 현장의 온도를 느낀 직후부터는 빠르게 개발을 시작해야 했다. 사용자를 만나고 나니 머뭇거릴 시간이 없었다. 서비스를 구현해놓고 피드백을 받아야 하니까. 그게 우리가 만든 프로젝트 구조의 순서였고, 일단 “띄우자”는 목표 아래 움직였다.

먼저 한 일은 CI/CD 파이프라인을 정비하는 일이었다. 지난 프로젝트 경험들을 바탕으로 GitHub Actions를 활용해 자동 배포 환경을 구축했다. main 브랜치에 머지되면 서버에 바로 반영되도록 설정했고, 서버 측에서는 Docker Compose를 통해 모든 프로세스를 컨테이너 단위로 관리했다. 우리가 쓰는 Oracle Cloud 환경은 익숙한 AWS와는 달랐지만, 직접 인스턴스를 열고 Nginx, Docker 등을 셋업하면서 의외로 빠르게 안정적인 환경을 만들 수 있었다.

문서 없는 명세, 눈앞의 기능으로 구체화되다

그러나 기술적인 셋업보다 더 많은 시간이 걸린 건 기능 정의의 세부화였다. 처음부터 모든 기능을 문서로 정의하지는 못했다. 짧은 기간 안에 설계, 사용자 인터뷰, 개발을 동시에 진행하다 보니, 자연스럽게 ‘일단 만들어보자’는 흐름이 되었다. 이 방식은 분명 빠르긴 했지만, 동시에 작은 충돌들을 계속 만들어냈다.

프론트엔드 쪽에서는 화면 UI를 먼저 그려두고, 실제로 돌아가는 흐름을 바탕으로 기능 구현에 들어갔는데, 이 과정에서 없는 API가 요청되기도 했다. 버튼은 있는데, 눌러도 아무 동작이 없고, 백엔드에서는 아직 해당 기능을 정의조차 하지 않은 상태였다. 화면설계를 정리해놓지 않은 채 개발을 진행한 결과, 서로 다른 기준선에서 작업을 하게 된 셈이다.

충돌보다 앞선 조율

이 문제는 다행히 빠르게 인지하고, 매일 아침 짧은 스크럼 회의를 도입하면서 해소할 수 있었다. 어떤 API가 필요하고, 어떤 흐름이 실제 사용자와의 인터랙션을 만들어낼지, 그날그날 결정하고 명세를 구체화해나갔다. 개발 도중 기능을 뺄 수도 있었고, 사용자 반응을 듣고 다시 넣을 수도 있었다. 그런 유연함은 우리가 이 프로젝트에서 얻은 중요한 감각 중 하나였다.

이 시점부터는 우리도 몰입의 밀도로 움직이기 시작했다. 지금 뭘 만드는지, 왜 만드는지를 명확히 이해하고 있다는 감각. 문서가 없더라도, 흐름과 방향이 일치하는 팀이라면 빠르게 맞춰갈 수 있다는 확신. 그리고 그 확신은 우리가 실제로 화면을 띄워보고, 누군가가 그것을 눌러봤을 때 비로소 현실이 되었다.