우아한 테크코스[프리코스] 4주차 회고록

오픈 과제: 강의실 관리 시스템 개발기

오픈과제란?

이번 기수에 처음 도입된 오픈 과제를 시작했다. 처음에는 '오픈'이라는 단어 때문에 팀 협업 프로젝트인지, 커뮤니티 활동인지, 오픈소스 기여 같은 것인지 여러 추측을 했다.

실제로는 '열린 과제', 즉 스스로 도전 과제를 정의하고 해결하는 자유도 높은 프로젝트였다.

과제 예시

• 낯선 도구 해커톤
  • 설명: 난이도는 평범하나 평소에 잘 사용하지 않는 개발 도구나 언어(예: Rust, Kotlin, WebAssembly, 하드웨어 보드 등)로 문제를 해결한다.
  • 과제: 반드시 동작하는 작은 결과물(예: 간단한 앱, CLI 툴, 시뮬레이션) 제출한다.
• 고난도 문제 해커톤
  • 설명: 평소에 익숙한 기술을 사용하여 난이도가 높은 문제를 해결한다.
  • 과제: 난도가 높은, 정답이 없는 문제를 정의하고, 해결해 가는 과정, 결과물을 제출한다.
• 제한 협업 미션
  • 설명: 2~3명이 한 팀이 되어 처음 보는 사람과 협업한다.
  • 과제: 제한 조건을 만들어서 진행한다.
    • 예) “소통은 하루 15분 화상회의만 가능”, “코드 작성은 깃허브 이슈/PR로만”

심지어 바리스타 자격증 따기 같은 개발과 무관한 도전도 가능했다. 참신하고 재미있는 접근이었다.

나의 도전 과제

나는 낯선 도구 사용과 테스트 코드 기반 개발을 도전 목표로 삼았다. 전체 개발 과정을 처음부터 끝까지 직접 경험하는 것이 목표였다. 팀원을 구해볼까도 했지만 결국 혼자 진행하기로 결정했다. 😂

개발계획

1. 프로젝트 주제 정하기
2. 기능 요구사항 기능명세서 작성
3. UI/UX 디자인
4. API 명세서 작성
5. DB 설계
6. 프런트 개발
7. 백엔드 개발
8. API 연동

가장 어려울 것으로 예상한 부분은 프론트엔드 개발과 UI/UX 디자인이었다. 그 예상은 정확했다...

리액트를 처음 사용해보았고, 학교 수업에서 간단한 실습과 클론 코딩만 해본 상태였다. useEffect, useState 등 기본 개념도 제대로 모르는 채로 시작했다.

이번 주차에는 프로젝트 주제 선정부터 디자인 초안, 기능 명세서, DB 설계, API 명세서까지 정리한 내용을 공유하려고 한다.

(상세 문서는 노션 링크 참조)

프로젝트 주제: 강의실 관리 시스템

왜 이 주제를?

언뜻 보면 너무 간단한 프로젝트 아닌가 싶을 수 있다. 하지만 이 주제를 선택한 이유는 실제로 교내에서 사용할 서비스를 개발하기 위함이다. 지원서에도 적었듯이, 실제 사용자가 있는 서비스를 만들고 싶다는 욕구가 컸기에 나에게 가장 적합한 주제라고 판단했다.

문제 상황

현재 학교에서 근로를 하며 강의실 시스템과 기자재를 관리하고 있다. 이 과정에서 많은 불편 사항들이 있고, 특히 고장 신고 대응이 번거롭다는 문제가 있다.

해결 방안: 고장 신고, 강의실 예약, 사용 가이드라인을 통합 제공하는 시스템을 개발하면 업무가 훨씬 효율적으로 진행될 것으로 기대된다.

 

기능 명세서

초기 기능 요구사항을 다음과 같이 분류했다:

1. 신고하기
   
   • 고장 기자재 선택
   • 오류 상황 기술
   • 이미지 첨부
   • 강의실 정보 및 신고 시간 입력
2. 관리자 기능
   • 관리자 등록/삭제
   • 관리자 정지/휴면 처리
   • 신고 목록 조회
   • 처리 완료 상태 업데이트
   • 관리자 로그인
3. 가이드라인
   • 가이드라인 등록
   • 특정 가이드라인 조회
   • 가이드라인 전체 목록 조회
4. 강의실 예약
   • 예약 시간 및 호수 설정
   • 예약 정보 수정
5. 메인화면
   • 각 기능 페이지로 이동

개발 과정에서 기능 추가 및 수정이 많았고, 설계와 실제 개발의 차이를 체감할 수 있었다.

UI/UX 디자인

공대생의 디자인은 정말 처참하다... 😂 아무리 수정해도 만족스럽지 않아서 협업의 필요성을 절실히 느낀 순간이었다. 디자이너분들을 진심으로 존경한다.

Figma로 초안을 작성했고, 부족한 부분은 개발 과정에서 직접 수정하며 진행했다.

(디자인은 노션에서 확인 가능...)

 

DB 설계

개념적, 논리적, 물리적 설계를 모두 진행한 것은 이번이 처음이다. 이전에는 무작정 테이블을 만들고 사용했지만, 제대로 설계하고 개발을 진행하니 테이블 수정 횟수가 줄어들어 개발 피로도가 크게 감소했다.

 

개념적 모델링

프리코스 기간 동안 다양한 정보 공유 글을 보며 Mermaid를 알게 되어 이번에 활용해보았다. 다이어그램 작성이 편리했고, 앞으로도 계속 사용할 것 같다.

 

논리적 모델링

개념적 모델링과 논리적 모델링의 차이는 무엇일까?

• 개념적 모델링: 비즈니스 요구사항을 추상적으로 표현
• 논리적 모델링: 개념적 모델을 데이터베이스 구현 가능한 형태로 변환

처음에는 이 차이가 와닿지 않았다. 하지만 직접 설계하면서 이해할 수 있었다.

예를 들어, File 엔티티는 개념적 설계에서 다른 엔티티들과 연결된 관계였지만, 실제 구현에서는 relatedId와 relatedType을 사용해 독립적으로 분리했다. 이처럼 개념적 관계와 실제 데이터베이스 구현이 달라질 수 있기 때문에 두 단계의 모델링이 필요하다는 것을 깨달았다.

 

물리적 모델링

실제 코드로 구현하며 진행했고, IntelliJ에서 제공하는 다이어그램을 활용했다.

 

API 명세서

여러 프로젝트를 진행하며 항상 어려웠던 부분은 "RESTful한 API란 무엇인가?"였다.

• 명사로 표현해야 하나?
• RESTful이 곧 가독성 높은 API인가?

과제를 진행하면서도 아직 많이 부족하다고 느낀다. 더 많이 고민하고, 다른 사람들의 코드를 보고, 경험을 쌓아야 할 것 같다.

(상세 API 명세는 노션 참조)

 

소감

처음으로 전체 개발 프로세스를 혼자 경험하며 많은 것을 배웠다. 특히 설계의 중요성과 협업의 필요성을 절실히 느꼈다. 앞으로도 계속 개선하며 실제 서비스로 발전시켜 나갈 계획이다.

 

https://versed-music-9b1.notion.site/2a1242c6313480c3900cd502271b3527

오픈 과제 | Notion