프로젝트 개요
개발을 하면서 순간순간 떠오르는 아이디어나 오류 해결 과정, 새롭게 배운 것들을 효과적으로 정리할 방법이 없을까 고민해왔다. 물론 Notion 같은 툴이 있지만, 개발자나 디자이너, PM을 위한 맞춤형 기록 도구라기보다는 일반적인 노트 앱에 가까웠다.
그래서 중앙 해커톤 공모전에 나가기 위해 꿈을 시련해보려 했다.
별다줄은 개발자와 디자이너가 프로젝트 기록을 쉽게 정리할 수 있도록 설계된 서비스다.
단순한 일기 형식이 아니라, 개발과 디자인 작업 흐름에 맞춰 프로젝트 정보를 체계적으로 관리할 수 있도록 하는 것이 목표다.
목표 및 기대
1. 개발자와 디자이너가 프로젝트를 체계적으로 기록할 수 있도록
2. 회고록, 기술 스택, 작업 로그 등을 구조적으로 정리할 수 있도록
3. 협업도 고려한 직관적인 UI/UX 제공
4. 기록을 효율적으로 관리할 수 있는 다양한 기능 제공
이 네가지의 목표들에 집중했다
주요 기능
1. 다양한 템플릿 제공
: 기본 템플릿을 제공하고, 사용자가 직접 템플릿을 추가할 수 있도록 구현
2. GPT-4o를 활용한 하루 요약
: 생성형 AI 를 활용하여 하루 동안의 기록을 요약하고 포트폴리오 작성에 도움을 주는 간당한 회고 지원
3. 해시태그 분류
: 태그 기반으로 글을 분류하고, 직관적인 검색 기능 제공
4. 아이디어 보드
: 프로젝트 진행 중 떠오른 아이디어를 빠르게 기록하고 시각적으로 정리할 수 있도록
5. 마크다운 형식 지원
: 개발자 친화적인 글쓰기를 위해 Markdown 형식 지원
사용 기술
프론트엔드: HTML5, CSS3, JavaScript
백엔드: Java, Spring Boot 3.3.1, MySQL 8.0, AWS S3, GPT-4o
디자인: Figma
에러 및 해결
매번 질리도록 찾아오는 CORS 에러가 별다줄 개발중에서도 발생했다.
우선, CORS란 Cross-Origin Resource Sharing 의 약자로 브라우저의 보안 정책인 SOP(same-Origin-Policy,동일 출처 정책) 을 우회하여 다른 출처의 리소스에 접근할 수 있도록 허용하는 매커니즘이다.
기본적으로 CORS에러가 나는 이유는 API 섭버가 브라우저의 CORS 요청을 허용하지 않으면, 브라우저가 이를 차단하고 CORS 에러를 발생시키는 원리에서 에러가 발생한다.
주요 원인
1. 요청하는 프론트엔드와 API 서버의 출처가 다른 경우
예를 들어,
프론트엔드의 주소가 http://localhost:3000 인데
백엔드 API 주소가 http://api.example.com 인 경우
다른 도메인에서 요청을 보내면 SOP 정책 때문에 차단된다.
2. 서버에서 Access - Control - Allow - Origin 헤더를 설정하지 않은 경우
CORS 정책을 허용하려면 백엔드에서 특정 출처를 허용하는 HTTP 헤더를 추가해야하는데 그렇지 않은 경우 차단된다.
3. 프리플라이트(Preflight) 요청이 차단되는 겨우
브라우저는 CORS 요청 전에 OPTION 매서드를 사용한 사전 요청을 보내는데 백엔드에서 이를 허용하지 않으면 CORS 에러가 발생한다.
우리의 경우 또한 첫번째 경우였기에.
백엔드에서 Port 를 추가해주거나, 만약 나의 라이브 서버 Port 가 있는데 에러가 나는 경우라면,
프론트에서 Method를 잘 써서 코드를 작성했는지 확인해야한다.
알게된 점
늘 api 통신에서 어려 워했던 나 이기에 이번 통신 코드 작성은 너무나도 많은 배움이 있었다.
기본적으로 통신을 하고자 한다면 api 명세서는 보고 읽을 줄 알아야하며 이해 또한 완벽하게 해야한다 .
우리의 기능 중 하나인 일기작성기능(POST) 의 명세서이다
Http Status Code 를 제공하고 별다른 response 가 없을 때는 .then 에 data 형식의 값을 불필요하게 추가하지 않아도 되고
if 조건문으로 처리해주어도 된다.
또한, resoponse 를 읽어와서 처리해야 할 때는 보통 GET 요청인 경우가 대부분이다.
GET은 즉, 데이터를 불러오는 Method 이기 때문에 받아온 데이터를 기반으로 기존에 생성되어야하는 div 에 넣어주는 경우가 많기 때문에 그렇다.
통신의 경우 가장 중요한 것은 URL 이다. 이 주소가 틀리게 되면 기능 또한 잘 작동하지 않는다.
여기서 GET , DELETE, PUT 요청의 경우 URL 뒤에 {id} 이런 값이 붙어있을 때가 있다.
이 id 를 Pathvariable(경로변수) 이라고 한다.
Pathvariable 은 UTL 경로의 일부를 변수로 사용하여 데이터를 전달하는 방법이다.
REST API 에서는 보통 특정 리소스를 조회하거나 조작할 때 URL에 직접 변수를 포합시키는 경우가 많다.
그렇기에, 프론트에서 잘 해주어야 할 것은.....
이 경로변수를 어떻게 가져올 것인지 어떻게 받아서 전달할 것인지를 잘 설계해주어야 한다.
느낀점
이번 별다줄 프로젝트를 진행하면서 가장 크게 느낀점은 무작정 코드를 작성하기보다, 먼저 설계를 하는 것이 얼마나 중요한지 였다. 처음에는 기능부터 빠르게 구현하려고 했지만, 막상 개발을 시작하고 보니 구조적인 문제가 발생했다. 데이터 모델을 명확하게 정의하지 않거나, UI/UX 흐름을 구체적으로 생각하지 않고 개발을 진행하면, 나중에 수정을 반복해야하는 상황이 많이 발생한다. 기능을 구현하기 전에 사용자가 이 서비스를 이떻게 사용할지 먼저 정의하고, 이를 기반으로 데이터 구조와 UI를 설계하는 과정이 필수적임을 깨달았다. 앞으로 다른 프로젝트를 진행할 때도, 이 경험을 바탕으로 더 효율적이고 사용자 친화적인 서비스를 만들 수 있을 것 같다.