---

한국공학대학교의 대동제(24.09.11~24.09.13) 기간에 맞춰, 6월 2일부터 두 달 반동안 진행한 프로젝트 Festino : 페스티노가 무사히 종료되었다!✨

Festino는 팀 Dev-Tino로서 진행한 두 번째 프로젝트였는데, 규모가 커짐에 따라 고생도 했지만 애정으로 끌어왔다. 결과적으로 만족으러운 성과를 달성해 뿌듯함도 그만큼 컸다. 배운 게 많았기에 두 달 반을 쏟아낸 Festino! 이에 대한 여정을 기록해 보고자 한다 :D

🥳 Festino 첫걸음 🥳

---

팀 구성

한국공학대학교 개발 소모임 Dev-Tino의 프론트 4명, 백 5명, 추가적으로 이번 축제 프로젝트에서 함께할 목적으로 모집한 디자인 3명까지 총 12명이 함께했다.

주제 선정 & 레퍼런스

학교 축제 웹사이트를 제작하자고 결정한 계기가 된, 핵심적인 문제점은 다음과 같았다.

1. 축제 관련 정보는 총학생회 인스타그램을 통해서만 확인할 수 있다.
2. 동아리의 공연 정보나 주간 부스 정보는 각 동아리의 SNS 게시물을 하나씩 확인해야만 알 수 있다.

→ ”웹사이트 하나로 모든 정보를 쉽게 확인할 수 있도록 하자!”

모든 정보를 한 눈에 확인할 수 있는 웹사이트 제작을 목표로 잡았고, 축제의 Festival과 한국공대 마스코트인 Tino를 합해 Festino라는 이름으로 프로젝트가 시작되었다!🎉

축제 웹사이트로 방향을 정한 후, 자대는 관련 프로젝트를 진행한 적이 없었기에 타 대학의 선례가 있는지 찾아봤다. 동국대 멋쟁이사자처럼에서 제작한 동국대 축제 웹사이트가 있었다. 이미 축제가 종료되어 사이트를 직접적으로 참고하진 못했으나, 홍보용으로 쓰였던 자료가 초장에 기획의 틀을 잡는 데 도움이 많이 되었다 :)

→ 공지 / 부스 / 홈 / 공연 / 홍보 탭으로 나뉘어 있는 것을 확인할 수 있다. 지도에서 부스 위치를 확인하고, 공연을 타임테이블로 나타내고, 공지를 모아 확인할 수 있는 기능이 Festino 기획 단계에 반영되었다.

🗓️ 협업 🗓️

---

Festino 프로젝트는 프론트 / 백 / 디자인 총 3개의 팀, 12명의 인원으로 진행했기에 원활한 프로젝트의 진행을 위해서 무엇보다도 협업이 잘 이루어져야 했다.

팀 간 협업을 위해서는 정기 회의, 팀 내 협업을 위해서는 Convention 적용을 하기로 했다.

1. 정기 회의

프로젝트가 진행되는 전 기간에 걸쳐, 매주 일요일 오후 3시에 정기 회의를 진행했다. 모두가 의견을 공유해 결정해야 할 사안들에 대해 논의하고, 팀 간 진행 정도를 파악하고 서로 조율해나감으로써 프론트, 백, 디자인의 팀 간 협업이 수월히 이루어지도록 했다.

정기 회의는 초기에는 폭포수 방법론에 맞게 진행되다가 도중 필요에 따라 애자일 방법론의 형태로 변형되었는데, 자세한 내용은 다음과 같다.

• 전반 - 폭포수 방법론
  : 주제를 정한 후로 전반에는 폭포수 방법론에 따라 요구사항 분석, 설계, ... 가 순차적으로 진행되었다. 필요한 기능을 정의하고, 와이어프레임을 작성하고, API와 DB를 설계하고, 그 후 개발을 시작했다. 각자 맡은 바를 한 뒤 정기 회의 시간에 백엔드와 프론트 팀이 이에 대한 의견을 공유하며 하나로 통일해가는 방식으로 진행했다.

• 후반 - 애자일 방법론
  : 기획을 마치고 개발을 시작한 뒤, 총학생회와 학과 미팅을 통해 피드백을 계속 받았다. 이에 따라 매주 기능의 수정 또는 추가가 지속적으로 발생하며 애자일 방법론으로 변경되었다. 즉, 일주일을 주기로 각자의 목표를 정하고 정해진 양의 일을 처리하는 방식으로 진행했다. 정기 회의 때 팀별 진행상황을 공유했으며, 팀별 일정을 공유해 선후관계가 있는 작업에 대한 일정을 조율해서 요구사항이 계속해서 변화하더라도 꾸준한 소통으로 팀 간 협업을 수월히 이루었다.

2. Convention

팀 내 협업을 위해서는 코드 컨벤션을 정해 두고 이에 따라 개발하는 것이 효율적인 협업에 중요할 것이라 판단했다. 따라서 백엔드 팀 내부에서 Code Convention을 지정하고 문서화두어 이에 맞춰 작업했다.

1. Naming Convention
   변수 및 함수는 camelCase, 클래스는 PascalCase, url은 kebab-case를 사용한다.

2. Git commit Convention
   커밋 시 변경 내용에 따라 다음과 같은 타입을 커밋 메시지에 기록한다.
   a. feat : 새로운 기능 추가
   b. fix : 버그 수정
   c. docs : 문서 수정
   d. style : 문법 및 변경사항 수정
   e. refactor : 코드 리팩토링
   f. rename : 파일명 및 폴더명 수정
   g. remove : 파일 삭제
   h. comment : 주석 수정 및 추가
   i. test : 테스트코드 추가 및 변경

3. Github Pull Request Convention
   a. 모든 작업은 브랜치를 생성해 작업하고 pull request를 통해 BE 팀장이 리뷰한다.
   b. PR 작성 시 정해진 양식에 따른다.
   c. PR 리뷰 시 이슈가 있다면 넘버링을 사용해 문제 상황을 간결히 전달한다.
   ( 1. Commit Convention Issue / 2. Indentation Issue / 3. Comment Issue / 4. Class Naming Issue / 5. Variable Naming Issue / 6. Code Separation Issue )

4. Method Naming Conventions for Controller and Service
   Controller와 Service에서 메서드 명은 CRUD-based의 동사로 시작한다.
   : check, get, save, update, delete

5. DAO and DTO Naming Conventions
   a. 엔티티 명은 모두 DAO를 붙인다.
   b. DTO는 두 가지 카테고리로 나눈다 : RequestDTO / ResponseDTO

6. Bean Method Naming Conventions
   Bean 내부의 메서드 명은 모두 exec로 통일한다.

7. Repository Naming Conventions
   엔티티 명 바로 뒤에 RepositoryJPA를 붙인다.

💡 기획 💡

---

Main 기능

‘축제 정보 확인 웹사이트’로 시작했는데 기획을 진행하다 보니 여러 기능이 추가되어 규모가 불어났다. 결론적으로 Main은 공지사항, 공연 타임테이블, 부스, 예약, 주문의 기능이 확정되었다! :)

1. 공지사항
축제 관련 공지를 한 번에 확인할 수 있는 페이지이다.
(축제 관련 공지는 총학 인스타그램 계정만 업로드하도록 하겠다는 총학의 의견에 따라, 웹페이지 Festino 관련 공지만 올리는 용도로 사용되었다.)

2. 공연 타임테이블
축제 날짜별로 동아리, 연예인 공연 정보를 시간에 따라 확인할 수 있다.

3. 부스
주간부스, 야간부스[주점], 푸드트럭, 편의시설의 정보를 확인할 수 있는 페이지이다.
지도의 마커로 위치 정보를 확인할 수 있고, 부스별 컨셉과 먹거리 등 모든 정보를 확인할 수 있다.

4. 예약
학과의 주점에 전화번호를 적어두거나 직접 줄을 서서 기다려야 하는 기존의 불편함을 해결하고자 도입한 테이블링(예약) 시스템이다.
이름과 전화번호를 기입해 주점에 예약을 걸어둘 수 있고, 학과는 Admin 페이지에서 예약을 관리할 수 있다.

5. 주문
학과의 요청에 따라 추가한 것으로, QR코드로 접속한 웹페이지에서 학과의 메뉴를 확인하고 주문하는 기능 및 학과의 계좌 정보를 제공하는 페이지이다.
예약 기능과 마찬가지로, 학과는 Admin 페이지에서 주문을 관리할 수 있다.

💡 학과에서 예약 및 주문을 관리할 수 있는 Admin 페이지는 학과별로 지정된 계정으로 로그인하면 각 학과의 부스 정보, 예약, 주문을 다룰 수 있도록 기획했다.

Admin 기능

1. 부스 정보 관리
학과에서 직접 부스 이미지, 설명, 메뉴 등의 정보를 등록하고 수정할 수 있는 기능이다.

2. 예약 관리

• Main에서 생성된 예약을 학과에서 관리할 수 있는 기능
• 예약 시 기재된 예약자의 정보를 확인할 수 있음
• 예약이 등록 / 취소 / 입장 처리될 때 자동으로 예약자에게 메시지 전송

3. 주문 관리

• Main에서 생성된 주문을 학과에서 관리할 수 있는 기능
• 테이블별 주문 진행 현황 조회, 입금대기 / 조리중 / 조리완료 / 취소 상태별 주문 조회
• 주문 진행 상태 관리
• 날짜별 주문 통계

API / DB 설계

우선 확정한 기능에 대해 와이어프레임을 작성한 후 API 설계를 진행했다.

여담. 기획 단계에서 있었던 작은 이슈들

1. 총학생회와 협업 X

축제는 총학생회가 주관하는 행사이다 보니, 총학생회와 협업이 이루어지면 정보 제공 등이 쉽게 이루어질 것 같아 컨택을 시도했다. 그러나 총학 측은 협업을 하게 되면 웹사이트에서 문제가 발생할 시 총학의 잘못으로 돌아갈 것을 우려해 거절했다.

(우리 학교 내에서는 선례가 없을 뿐더러, 미팅 당시에는 완전한 결과물이 없었기에 신뢰하기 힘들었을 것이다. 아쉽지만 어쩔 수 없는 것이 사실이다.)

총학과 협업은 성사시키지 못했지만, 정보 제공이나 서버비 지원 등의 도움을 받지 못하는 것일 뿐이기에 제한선 안에서 기존의 계획대로 프로젝트를 진행했다 :)

2. 지속적인 기능 추가, 초기 목표해 비해 커진 규모

축제 프로젝트는 개발팀이 원하는 기능만 넣어서 되는 것이 아니라, 축제를 즐기고자 하는 학우분들의 니즈에 맞춰가야 한다. 이에 따라 기획을 진행하면서도 초기에 설정된 목표(단순 정보 제공)에 더해 외부의 의견이 여러 번 더해졌다.

까다롭고 규모가 큰 기능 중 하나인 주문 기능도 과학생회의 요청으로 추가되었다. 주문을 포함한 여러 기능이 추가된 기획 후반부터는 초기 목표였던 "정보 제공"에서 한 단계 뛰어 축제에 필요한 종합적인 서비스를 제공하는 방향으로 진행되었다.

(물론 사용자의 소중한 의견 덕에 폭넓은 기능을 갖추게 된 것은 감사하게 생각한다! :>)

💻 개발 💻

---

프론트엔드 Vue.js, 백엔드는 SpringBoot를 사용해 개발했다.

필자는 백엔드 팀원으로서 Admin 공지사항 / 공연 타임테이블 / 주문 파트를 담당했다.

개발 관련 내용은 발생했던 문제를 위주로 정리해 보겠다. (필자가 BE 팀원으로서 개발을 진행했으므로 BE에서 발생한 문제에 치중하게 되는 점 양해 바란다)

1. 타임테이블 API 무효화

admin의 타임테이블(연예인/동아리 공연) 파트를 담당했다. 그런데 와이어프레임에서 admin 연예인/동아리 공연 관리 페이지가 없었고, 디자인 최종본이 나오고 한참 후까지도 (심지어 API 구현이 완료된 후에도) 인지하지 못했다.

→ admin에서 관리할 수 있는 기능 없이 직접 DB에 정보를 넣기로 결정했다.

타임테이블 연예인/동아리 공연은 기획회의 때 나온 간략한 DB 구조와 API를 모두 다듬고 수정 후 10개의 API를 구현하는 데 일주일이 걸렸다. 어렵지 않지만 시간을 요하는 작업이었기에 일주일의 시간을 낭비한 것이 되어버렸다.

개발의 전체적인 틀을 확인하지 않고 ‘내가 할 일’로 시야를 좁혀두는 바람에 발생한 문제라고 생각한다. 더 책임감을 가지고 꼼꼼히 확인해야 했다.

지난 PLAY-TINO 프로젝트는 ‘기획에서 생략되면 수정 시간이 길어짐’을 배웠다면, 이번 Festino 프로젝트는 ‘기획에서 생략되면 개발 결과물이 무효화될 수 있음’을 배웠다.

→ 와이어프레임 작성 시, 특히 내가 담당한 파트는 넓은 시야로 부족한 것이 없는지 꼼꼼히 살펴 보도록 하자.

2. Save / SaveAll

입금 확인 시 조리(Cook)을 생성하는 메서드에서 문제 발생 가능성이 있는 부분을 발견했다.

다음은 주문(Order)에 포함된 메뉴 정보를 사용해 조리(Cook) 리스트를 생성하고 저장하는 코드이다.

// Before

    public void exec(OrderDAO orderDAO){
    
        List<Map<String, Object>> menuList = orderDAO.getMenuInfo();

        for (Map<String, Object> menu : menuList){

            CookDAO cookDAO = createCookDAOBean.exec(menu, orderDAO);
            saveCookDAOBean.exec(cookDAO);

        }
    }

위 메서드는 for 반복문 내부에서 save 를 호출하고 있다. 이 경우 다음과 같은 단점이 있다.

• 원자성 보장X
  • 하나의 Order 정보에 해당하는 특정 개수의 Cook을 생성하는 작업이므로 for문 내에서 개별적으로 저장하면 ‘Cook 생성 작업’의 원자성이 보장되지 못한다.
  • ex) menuList의 size가 5라고 가정하고, 첫 번째 Cook의 생성 및 저장을 완료했다고 가정하자. 이때 두 번째 Cook을 생성하는 도중 오류가 발생해 프로세스가 종료될 경우, 한 개의 Cook만 DB에 반영된 것이므로 원자성은 깨진 상태가 된다.
• 비효율성
  • save 메서드의 반복 호출이 saveAll 메서드의 호출보다 비효율적이다.
  • 사실상 saveAll 내부는 save를 여러 번 호출하는 것이기에 동일하다 생각할 수 있으나 다름
    • save와 saveAll은 @Transactional 어노테이션이 있음
    • @Transactional 은 REQUIRED 를 기본 속성으로 가짐 : 트랜잭션 수행 중 트랜잭셔널 메서드가 호출되면 새로운 트랙잭션이 생성되는 것이 아니라 상위(기존) 트랜잭션에 합류됨
    • 즉, for문의 save는 호출될 때마다 새로운 트랜잭션이 생성되는데 saveAll의 save는 호출되어도 하나의 트랜잭션 내에서 돌아가므로 그 시간적 비용에서 차이가 난다!

// After

    public void exec(OrderDAO orderDAO){
    
        List<Map<String, Object>> menuList = orderDAO.getMenuInfo();
        
        // Cook DAO 리스트 생성
        List<CookDAO> cookDAOList = new ArrayList<>();

        // menuList에서 하나씩 꺼내서
        for (Map<String, Object> menu : menuList){

            // 메뉴 정보로 Cook DAO 생성
            CookDAO cookDAO = createCookDAOBean.exec(menu, orderDAO);

            // 생성한 Cook DAO 리스트에 적재
            cookDAOList.add(cookDAO);

        }
        
        // Cook DAO 리스트 저장
        saveCookDAOBean.exec(cookDAOList);
        
    }

→ for 반복문 내에서는 주 목적인 DAO 생성만 하고, 저장할 DAO는 List에 적재해 두었다가 saveAll 하는 방식으로 변경했다.

3. 조리중 주문 조회 : 처리 시간

조리중 주문 조회 API 호출 시 처리 시간이 꽤 오래 걸리는 것을 발견했다.

조리중 주문 조회는 각 메뉴별로 조리(Cook)을 조회해 보여주는 방식인데, 이때 테이블번호(tableNum)을 함께 응답으로 보내줘야 하기에 주문 테이블에서 테이블번호를 조회해서 보내는 로직이었다. 이것이 처리시간에 영향을 많이 미쳤을 것이라 판단, 수정하기로 했다.

애초에 조리(Cook) 생성 시에 tableNum 필드에 테이블 번호를 저장해두는 방식으로 변경했다.

기존에는 존재하는 모든 조리(Cook)에서 각각 테이블 번호를 조회해야 했는데, 그 작업이 사라지니 훨씬 효율적이다. Entity에 필요한 정보만 남기는 것도 중요하나, 처리 속도를 위해 불필요한 조회 작업을 줄이는 것도 매우 중요함을 다시 한 번 느꼈다.

4. menuId 추가 : 조리와 메뉴의 관계

주문(Order)로부터 조리(Cook)이 만들어진다. 팀원 간 의견 조율 결과에 따라, 주문과 조리 모두 메뉴는 아이디 없이 이름으로만 다루고, 조회할 때에도 메뉴 이름을 기준으로 조회한다. 즉, 굳이 menuId를 저장해두고 메뉴를 조회하는 방식으로 메뉴-주문, 메뉴-조리 간의 관계를 만들지 않고 menuName을 저장해 사용한다.

→ 그러나 이 방식의 문제점이 많이 발견되어 수정하게 되었다.

문제1. 통계

메뉴 이름이 변경되면 기존의 이름으로 저장된 조리(Cook)은 통계에 포함이 안 된다.

메뉴 이름이 동일하면 해당 학과의 조리(Cook)이 아닌데도 통계에 포함된다. → 얘는 학과별 DB 분리가 안 되어 있어서 그런 것이기도 하지만, 동일 학과에서 같은 이름의 다른 메뉴를 두는 경우도 생각한다면 문제가 맞다!

문제2. 조리중 주문 조회

메뉴 이름이 변경되면 기존의 이름으로 저장된 조리(Cook)은 조리중 주문 조회 시 조회되지 않는다.

(+) 메뉴가 삭제되는 경우도 고려해 soft-delete된 메뉴에 대해서도 하려고 했으나 이는 품절이라는 옵션이 있기에 불필요하다 판단했다.

해결

주문 자체의 메뉴 정보를 보기 위한 API의 로직은 그대로 남겨, 즉 menuName을 가지고 있다가 그대로 보여준다. 문제가 발생한 통계&조리중 주문 조회 API는 Cook을 조리할 때 menuName이 아닌 menuId로 조회한다.

이 방안을 적용하기 위해 다음과 같이 수정이 필요했다.

Order 생성 시 메뉴 정보를 담는 Map에 menuId도 함께 저장하도록, Cook 생성 시에도 Order의 메뉴아이디를 받아서 하나의 필드로 저장하도록. 대신 Cook에서는 기존의 menuName 필드를 제거.

고찰

사실 문제1 : 통계 얘기까지만 나왔을 때에도 기존 로직을 유지하려고 했었다. 발생하는 문제에 비해 수정사항이 비대하다는 BE팀장님의 판단 하에 그러했다. 그러나 조리중 주문 조회 API의 문제는 그냥 둘 수 없어서 수정하게 되었고, 막상 수정사항을 정리하니 고칠 건 그렇게나 많지는 않았다.

불필요한 관계를 두지 않자는 의도에 따라 결정한 방법이지만 여러 문제가 발생함에 따라 수정되었다. 앞으로도 “관계를 두지 않는다.”, “발생한 문제의 정도”, “해결에 드는 시간적 비용”을 적절히 고려해 최선의 방안을 선택할 필요가 있겠다고 생각했다.

📢 홍보 📢

---

온라인 홍보

인스타그램, 대학생 커뮤니티 에브리타임 으로 웹사이트 홍보를 시작했다.
실제로 웹사이트를 공개하기 전, 인스타그램과 에브리타임으로 티저를 올렸는데 반응이 매우 뜨거웠다!!❤️‍🔥

24년 하반기의 3번째 BEST 게시글이 되는 영광스러운 일도 있었다 :)

오프라인 홍보

오프라인 홍보는 포스터를 제작해 교내 곳곳에 부착했다!
최대한 많은 학우분들이 포스터로 웹사이트를 접하실 수 있도록 눈에 잘 띄는 게시판마다 꼼꼼히 붙여 두었다 :)

🚨 배포 후 이슈 🚨

---

축제 당일이 되기 전까지도 약 2~3주 간 수도 없이 많은 테스트를 거쳐 버그픽스를 했지만 결국 당일에도 문제는 발견되었다. 절대 완벽하다고 확신할 수 없는 것이 소프트웨어이기에 당연한 일이지만, 심적인 압박감은 어쩔 수 없이 따라왔다...🥲

1. 특정 주문이 중복 생성되는 문제

하나만 생성되어야 하는 주문이 동시에 3개씩 생성되는 문제가 발생했다.
확인해 보니 '입금 완료' 버튼을 누르고 API 요청이 완료되기까지 시간이 걸리는데, 요청을 처리하는 동안 버튼을 여러 번 누르면 누른만큼 요청이 보내진 것이었다.

이는 하나의 요청을 처리하는 동안 버튼이 눌리지 않도록 수정해 해결했다.

2. 예약 번호 불일치 문제

Main에서 부스 예약 시 표시되는 예약 대기 팀 수와 Admin에서 표시되는 실제 예약 대기 팀 수가 일치하지 않는 문제가 발생했다.

이는 축제 두 번째 날에 발견되었는데, 확인해 보니 전날에 처리가 완료되지 않은 (예약 대기 상태인) 예약들이 남아 있어 발생하는 문제임을 확인했다.

문제 파악 시점에는 이미 부스가 운영되고 있는 상황이라 로직을 수정하기에 적절하지 않았기에, 아직 처리되지 않은 예약들을 직접 완료 상태로 변경함으로써 임시로 해결했다.

→ 위와 같은 이슈들이 있었지만, 사고라 할 만큼의 큰 문제는 터지지 않아 개인적으로는 다행이라고 생각한다!😎 (물론 이는 지속적인 테스트와 여러 상황에 대한 대비에 힘써준 모든 팀원들 덕이다)

🏆 프로젝트 성과 🏆

---

위는 축제 첫날인 9월 11일의 통계이며, 서비스가 이루어진 5일(9/9 ~ 9/13) 간의 최종적인 통계는 다음과 같다.

📊
누적 사용자수 3091명
누적 전체 조회수 80357회

누적 전체 예약 건수 72건
누적 전체 주문 건수 1308건

🔥결론적으로 약 3천 명의 사용자 수, 8만 회의 조회 수를 달성했고, 약 1,300 건의 주문을 받았다!!🔥
약 7천 명의 재학생 수 대비 10배가 넘는 조회 수를 달성한 것이 뿌듯하고, 값진 경험을 얻은 것 같아 굉장히 만족스럽다! 😊

😓 아쉬운 점 🥲

---

총학과 협업 X

• 연예인 공연 정보 X
  : 총학생회와 기획사에서 계약 시, 연예인 공연 관련 정보는 총학생회 인스타그램을 통해서만 게재할 수 있다는 내용이 포함되어 있었다. 이에 따라 Festino 웹사이트에서 연예인 공연 정보를 제외한 동아리 공연 정보만 게시할 수 있었고, '총학생회 인스타그램 바로가기' 버튼을 두는 정도로 마무리되었다.
• 공지사항 X
  : 총학생회가 작성해 총학생회 인스타그램에 업로드된 글이 Festino 웹사이트에도 게재된다면 학우들의 혼란을 초래할 수 있다는 총학생회의 우려에 공지사항 기능이 사실상 중심을 잃었다.

→ 사실상 처음에 생각했던 "하나의 웹사이트에서 모든 정보를 쉽고 편리하게 보자!" 라는 목표를 온전하게 달성하지는 못했다. 총학생회와 협업이 이루어지지 않아 그렇게 된 점에서 아쉬움이 많이 남는다.

리팩토링

• 일정이 당겨짐에 따라 리팩토링 X
  : 축제 기간을 예상했던 9월 3~4주차에 추석 연휴가 걸침에 따라 축제가 9월 2주차로 평소보다 앞당겨 진행되었고, 예상 개발 기간이 약 일주일 축소되었다. 이에 따라 기획했던 전체 리팩토링은 진행하지 못했기에 아쉬움이 남는다.
• 특히, Converter
  : Map 형태의 데이터를 DB에서 관리하기 위해 직렬화/역직렬화하는 과정에서 문제가 발생했었다. 막간에 진행한 리팩토링 과정 중 급하게 삽입한 DTO가 있었는데, 여기서 제대로 변환되지 못한 데이터로 인한 것이었다. 이는 데이터를 읽을 때 Converter를 사용해 String으로 우선 변환 후 다시 Map으로 매핑하는 로직을 사용해 해결했으나, 더 깔끔하게 해결할 수 있을 것 같아 아쉬움이 남는다.

🫧 마치며

---

이렇게 두 달 반이라는, 길지만 촉박했던 시간이 모두 지나갔다 :>
앞서 짚은 것처럼 아쉬운 점도 있었지만, 결과도 만족스럽고, 분명히 값진 경험을 만들어준 프로젝트였다.
이번에 아쉬웠던 점들은 기회가 된다면 다음 해 대동제에서 리팩토링을 진행하며 반영해 발전시킨다면 더욱 좋을 것 같다!😊