"두 페이지만 만들면 돼요.” 라는 팀장님의 한마디에 시작된 이번 프로젝트는, 단순하지만 결코 간단하지 않았습니다. 회사에서 일주일 동안 프로젝트를 진행하면서 겪었던 과정을 적어볼까 합니다.

두 페이지만 만들어 주세요~

이번 프로젝트의 주제는 ChatGPT를 활용해 보고서를 작성하는 프로젝트입니다. 기업에 제안하기 위한 목적으로 급하게 만들어야 했으며, 초기 단계에서는 프리파일럿으로 사용해 보고 기업이 원할 경우 정식 서비스로 발전시키는 계획이었죠.

팀장님이 저에게 리액트로 두 페이지만 만들어달라고 부탁하셨습니다. 사실 해야 할 다른 업무가 있었지만, 두 페이지쯤은 기본이잖아요? (아님 말고 😭) 게다가 저에겐 GPT라는 스승님도 있어서 어렵지 않게 해낼 수 있을 것 같았습니다!

그렇게 시작한 프로젝트는 로그인 페이지와 보고서 작성 페이지였습니다.

하지만 시작 전 부터 쉽지 않았습니다. 요구사항이 명확하지 않았거든요.

• 디자인을 고려해야 할까요? NO!
• 기능은 이게 다일까요? YES!
• 만들면 쓰긴 할까요? 모르겠다!
• 이런 기능이 필요할까요? 아직 정해지지 않았다!

이런 상황에서 저는 로그인 페이지와 보고서 페이지를 바로 제작했습니다. 이제 API만 붙이면 되겠다 싶었는데, 다 만들고 난 뒤에 타 팀에서 급하게 새로운 레이아웃을 전달받았습니다. 기존 보고서 페이지와 완전히 다른 레이아웃이었죠.

레이아웃 변경과 회의

레이아웃 수정 자체는 어렵지 않았지만, 왜 이런 형태로 만들어야 하는지 의문이 들어 바로 회의를 요청했습니다. “이렇게 만들면 사용성이 떨어질 수 있다”고 말씀드렸지만, 타 팀장님께서는 “일상생활에서 GPT를 사용하는 것처럼, 한 화면에 모든 정보가 나와야 한다”고 설명하셨습니다. 회의를 통해 프로젝트의 방향성을 조금 더 이해할 수 있었습니다.

하지만 레이아웃을 수정하고 나니 생각지도 못한 이슈들과 요구사항이 하나둘씩 등장하기 시작했습니다.

계속 바뀌는 요구사항들

1. 1.타이머 컴포넌트 (타이머 필요 없다!)
   • 요구: 타이머 추가 필요 → 삭제 요청
   • 타이머 컴포넌트를 구현했으나 불필요하다는 결정으로 인해 레이아웃을 다시 수정해야 했습니다.
   • 에디터 기능 추가 (테이블 기능이 필요하다!)
   • 초기 구현 : 간단한 Quill 라이브러리로 에디터 구현
   • 추가 요구 : 테이블 기능이 필요하다!
   • 두 번째 구현 : TinyMCE 라이브러리로 에디터 구현
   • TinyMCE를 도입하고 나서야 모든 요구사항을 충족했다고 생각했지만, 라이선스 제한 문제로 SunEditor로 교체하는 과정을 거치며 추가 작업 시간이 2일 정도 소요되었습니다…
   • 세 번째 구현 : 최종적으로 SunEditor 라이브러리로 구현. 하지만 개발 도중 onChange 함수가 제대로 작동하지 않아 keydown 이벤트로 텍스트 변화를 감지하는 방식으로 해결했습니다.
2. 2.보고서 작성 기능 확장 (보고서를 여러 개 쓰고싶다!)
   • 초기: 단일 보고서 작성
   • 변경: 다중 보고서 작성 및 데이터 유지
   • 페이지 이동 시 작성 데이터를 유지하도록 구현해야 했기에 추가적인 상태 관리 로직과 에디터 라이브러리를 커스텀하여 개발했습니다.
3. 3.추가 페이지 구현 (페이지가 더 필요해요..)
   • 두 페이지라고 하셨지만 결국에는 총 5페이지 정도를 개발했네요..

추가적인 문제들

1. 1.팀장님의 부재
   • 팀장님이 3일간 연차를 사용하셔서 백엔드 코드 수정까지 맡게 되었습니다. DB 구조를 분석하고 수정된 요구사항에 맞는 API를 구현해야 했습니다.
2. 2.기존 업무와 병행
   • 기존에 진행 중이던 업무를 처리하면서 프로젝트를 병행해야 했습니다.
3. 3.기술적인 문제
   • SSR 빌드 문제로 몇 번의 삽질을 해야했습니다
   • 다양한 라이브러리와 새로운 요구사항으로 인해 예상보다 많은 시간이 소요되었습니다.

프로젝트의 핵심은 속도

이 프로젝트에서 가장 중요한 것은 ‘속도’였습니다. 수정사항이 생길 때마다 배포하고 실시간으로 테스트하면서 개선점을 찾고, 요구사항을 반영했습니다. 말로 설명하고 회의하기보다는 실제 작동하는 사이트를 보여주며 테스트하는 방식이 훨씬 효율적이었습니다.😅

결론 및 회고

일주일이 지난 지금, 요구사항은 모두 구현된 상태지만, 정확한 오픈 날짜가 정해지지 않아 계속 수정이 이루어지고 있습니다.

요구사항이 불분명한 상태에서 속도와 유연성이 얼마나 중요한지 다시금 느끼게 해주었습니다. 요구사항이 명확하지 않은 상태에서도 과감히 시작할 수 있는 용기 ( 이 부분은 두 페이지라는 용기로 시작 된 것 같습니다..ㅎㅎ )가 필요했고, 실시간으로 피드백을 반영하며 수정해 나가는 방식이 생각보다 훨씬 효과적 임을 깨달았습니다.

하지만 동시에 프로젝트의 성공은 단순히 빠르게 만드는 데서 끝나지 않고 명확한 요구사항을 정의하고 더 나은 제안을 할 수 있는 능력 또한 필요하다고 느꼈습니다.

프로젝트는 여기서 끝이 아니라 이제부터가 시작이라고 생각합니다. 요구사항 변화에 맞춰 꾸준히 유지보수하고, 필요한 부분은 리팩토링하며, 장기적으로 확장 가능성까지 고려해야 하는 작업이 남아있어요. 남은 시간 동안 더 안정적인 결과물을 만들어 갈 수 있도록 집중할 것 입니다!