사용자가 관심 있는 지역의 실거래 내역을 검색하고, AI 분석을 통해 부동산 트렌드를 빠르게 파악할 수 있도록 도와주는 부동산 정보 서비스의 프론트엔드 레포입니다.
Homecode는 다음과 같은 사용자 경험을 제공합니다:
- 지역 및 날짜를 선택하여 실거래 내역을 빠르게 조회
- 지도 기반으로 시세를 시각적으로 파악
- OpenAI 기반의 AI 분석을 통해 해당 지역의 부동산 트렌드 요약 제공
- JWT 인증 기반의 회원가입 / 로그인 시스템
| 구분 | 기술 |
|---|---|
| 프레임워크 | Vite + Vue.js 3 |
| 상태관리 | Pinia |
| 비동기통신 | Axios |
| 디자인 | Figma, CSS |
| 협업 | SSAFT GIT |
| 기타 | Kakao Map API (지도 서비스) |
- JWT 기반 인증 구현
- 로그인 후 사용자 상태를 상태관리(Pinia)로 관리
- 토큰은 HTTPOnly Cookie 방식으로 저장
- 지역, 연도, 월, 매물 키워드 등 필터를 선택해 실거래 정보를 조회
- 결과는 표 형식과 함께 지도 위 마커로 시각화
- 실거래 리스트에서 매물을 선택하면 상세 정보도 확인 가능
- 사용자가 조회한 조건을 기반으로 OpenAI API에 요청
- 해당 지역의 주거환경, 개발현황, 투자 가치 등 트렌드를 자연어로 요약해 사용자에게 제공
- 응답 결과는 캐싱하여 동일 요청 시 빠르게 재응답
- 모바일 환경에서도 실거래 확인 및 트렌드 분석이 용이하도록 설계
- Figma와 CSS를 활용하여 UI/UX 설계
아래는 실제 Homecode 서비스 구동 화면입니다.
캐싱을 통해서 응답 속도 단축을 체감할 수 있습니다.
# 패키지 설치 (package.json에 해당 라이브러리들 있어요)
npm install
# 개발 서버 실행
npm run dev기본 포트는 localhost:5173입니다.
백엔드 서버는 포트 8080 기준으로 연결되어 있으므로 .env 설정을 확인해주세요.
src/
├── api/ # 백엔드와 통신하는 API 함수 모음
├── assets/ # 이미지, 아이콘, 스타일 파일 등 정적 리소스
├── axios/ # Axios 인스턴스 및 인터셉터 설정
├── components/ # 재사용 가능한 UI 컴포넌트
├── composables/ # Vue 3 Composition API 훅(hook) 모음
├── router/ # Vue Router 설정
├── store/ # Pinia 상태 관리
├── utils/ # 공통으로 쓰이는 유틸 함수
├── views/ # 페이지 단위 뷰 컴포넌트
├── App.vue # 루트 컴포넌트
└── main.js # 애플리케이션 진입점
- 공공데이터 자동 갱신을 위한 배치(Batch) 작업 도입
- 외부 API 안정성을 위한 서킷 브레이커 적용
- 요청 과부하 방지를 위한 Thread Pool 및 TPS 제어 전략 적용
- 화이트리스트/블랙리스트 기반 접근 제어 로직 추가
- FE: 김민준, 김세민
- 디자인 협업: 김민준, 김세민
프론트엔드를 처음으로 직접 다뤄보며, Vue의 컴포넌트 기반 구조에 대한 이해를 키울 수 있었습니다. 처음에는 어떤 기준으로 UI를 나누고 구성해야 할지 막막했지만, 작업을 반복하며 역할 단위로 컴포넌트를 쪼개고 재사용하는 구조가 유지보수에 얼마나 중요한지 체감할 수 있었습니다. 덕분에 불필요한 중복을 줄이고 구조를 깔끔하게 유지하는 데 집중할 수 있었고, 컴포넌트 아키텍처의 실질적인 장점을 몸으로 익혔습니다.
Vue의 반응형 시스템 역시 인상 깊었습니다.
ref,computed,watch를 사용하면서 데이터와 UI가 실시간으로 동기화되는 흐름을 체감했고, 특히 이 과정에서 큰 삽질을 하며 성장할 수 있었습니다. 예를 들어,computed값을sessionStorage에 저장하려고 했지만 값이 저장되지 않아 한참을 헤맸습니다. 이후computed는 실제 상태 값을 가지는 것이 아니라 계산된 값을 반환하는 구조이므로, 저장하려면ref값을 직접 사용해야 한다는 것을 깨달았습니다. 이 시행착오를 통해 Vue의 내부 동작 원리를 더 깊이 이해할 수 있었고, 단순한 시도에서 비롯된 실패조차 값진 학습이 될 수 있다는 걸 느꼈습니다.보안 설계 측면에서도 큰 배움이 있었습니다. 처음에는 access token과 refresh token이 어디에 저장되는지도 모른 채 개발을 진행했고, 결국 둘 다 메모리에 저장된 상태였습니다. 새로고침 시 로그아웃이 되는 원인을 뒤늦게야 이해하게 되었고, 토큰 저장 위치가 보안과 사용자 경험 모두에 큰 영향을 미친다는 점을 실감하게 되었습니다. 일반적으로는 access token은 메모리, refresh token은 HttpOnly 쿠키에 저장하며, 유효성 검증은 서버 DB에서 수행하는 구조가 권장되는데, 이는 XSS로부터 refresh token을 보호하고 access token의 노출 범위를 최소화하기 때문입니다. 이러한 구조를 적용하지 못한 것이 아쉽지만, 이 과정에서 JWT 탈취 위험, 세션 방식과의 비교, 쿠키 기반 CSRF 방어 전략 등에 대해 깊이 고민해볼 수 있었고, 프론트엔드 개발자도 보안 설계에 대한 인식이 필수적이라는 점을 절감했습니다.
상태 관리 측면에서는 Pinia와 Axios를 함께 사용하며 구조적 설계의 중요성을 경험했습니다. 처음에는 각 컴포넌트에서 직접 Axios를 호출했지만, 이후에는 요청 로직을 Pinia store 내부로 통합하여 데이터를 중앙에서 관리하는 방식으로 개선했습니다. 컴포넌트는 화면 표현에만 집중할 수 있었고, 상태 흐름은 예측 가능하고 일관된 구조로 정리되었습니다. API 요청과 상태 갱신을 하나의 흐름으로 묶으면서 코드 재사용성과 유지보수성이 높아졌고, 실제 서비스 환경을 염두에 둔 설계 연습이 되었습니다.
이번 프로젝트는 단순히 UI를 만드는 것을 넘어, 상태 관리, 데이터 흐름, 인증 로직, 보안 설계까지 아우르는 전체적인 프론트엔드 설계 경험이었고, 그만큼 도전적이면서도 의미 있는 시간이었습니다. 시행착오도 많았지만, 그 하나하나가 실력 향상으로 이어졌고, 프론트엔드의 고충을 직접 겪으며 깊이 있는 이해와 성장의 기회로 삼을 수 있었습니다.
처음엔 그저 **‘보이는 걸 만들면 되는 일’**이라 여겼던 프론트엔드가, 결국 ‘보이지 않는 흐름까지 설계하고 조율해야 하는 정교한 영역’이라는 사실을 실감하게 되었습니다.
처음 Figma로 화면을 설계하고 그것을 코드로 옮기는 과정은, 생각보다 훨씬 많은 결정을 요구하는 일이었습니다. 색상 하나, 여백 하나에도 이유가 있어야 했고, 사용자의 시선을 어디에 둘 것인지까지 고민해야 했죠. 이 과정을 통해 느낀 건, 디자인은 정답이 있는 작업이 아니라, 계속해서 질문을 던지고 타협하는 과정이라는 점이었습니다. 사용자 경험을 위해 예쁘기만 한 UI가 아니라, 기능과 목적이 뚜렷한 인터페이스가 필요하다는 것을 직접 부딪히며 배웠습니다.
또한 Vue 라우터를 사용해 전체 화면 흐름을 설계하면서, ‘페이지’는 기술적으로 나뉘는 단위가 아니라 사용자의 경험이 끊기지 않게 이어져야 하는 흐름의 단위라는 점을 깨달았습니다. 동선 하나 바꾸는 것만으로도 사용자의 심리적 부담이 확 달라지는 걸 보며, 설계는 결국 편리를 추구하는 작업이라는 생각이 들었습니다. 지도와 연동된 기능을 구현하면서는 데이터와 UI가 밀접하게 연결될수록 예외 처리와 오류 상황에 대한 고민이 더 중요해진다는 것을 체감했습니다. 단순히 좌표를 찍는 것 이상으로, 잘못된 입력이나 빈 응답, 느린 로딩 상황을 어떻게 처리할 것인지에 따라 서비스의 완성도가 결정되었기 때문입니다.
특히 백엔드 API와의 연동 과정에서는 프론트엔드는 혼자 동작할 수 없다는 점, 즉 항상 다른 계층과의 ‘커뮤니케이션’ 안에서 움직여야 한다는 현실을 절실히 느꼈습니다. 이런 과정을 통해 프론트엔드 개발자는 단순히 화면을 그리는 사람이 아니라, 백엔드가 그렇듯, 전체 시스템의 흐름을 이해하고 조율하는 사람이어야 한다는 책임감을 갖게 되었습니다.
마지막으로, 성능 테스트를 진행하면서 로직을 제대로 이해하지 못하면 아무리 측정을 해도 그 결과에 신뢰를 가질 수 없다는 사실을 뼈저리게 느꼈습니다. 크롬 개발자 도구나 Postman 수준에서 벗어나 JMeter라는 테스트 도구를 써보았습니다. 이 경험은, 앞으로 어떤 프로젝트든 ‘성능은 구현이 끝난 후의 부가 작업’이 아니라 처음부터 함께 고려해야 하는 요소라는 걸 인식하게 만든 계기가 되었습니다.
돌아보면 이 프로젝트는 제게 프론트엔드는 결국 ‘사용자의 흐름을 설계하는 일’이라는 본질을 온전히 이해하게 해준 여정이었습니다. 디자인, 페이지 이동, API 연동, 예외 처리, 성능 개선까지—하나의 작업도 단순한 구현에 그치지 않았고, 매 순간 ‘왜 이 선택을 했는가’라는 질문을 던지며 성장할 수 있었던 값진 시간이었습니다.