문제
부동산 앱에서 집을 찾는 일은 대체로 같은 매물을 여러 번 보는 일이다. 중개사무소마다 같은 방을 올려두고, 광고비를 낸 매물이 위로 오고, 전화를 열 군데 돌려야 조건에 맞는 게 하나 나온다. 찾는 쪽이 노동을 다 하는 구조다.
어디살지는 이걸 뒤집는다. 세입자가 조건을 남기면 중개사가 찾아서 제안한다. 이 방향 전환은 화면 몇 개를 바꾸는 문제가 아니라, 세입자·임대인·중개사·관리자 네 역할이 하나의 거래를 각자의 시점에서 보는 시스템을 통째로 만드는 문제였다.
구조
백엔드는 헥사고날(포트 & 어댑터) 로 갔다. 도메인 27개가 각자 entities / ports / use_cases 를 갖고, 외부 기술은 전부 어댑터로 밀어냈다. 도메인 코드에서 sqlalchemy 나 httpx 를 import 하면 CI 가 막는다(import-linter).
domains/{properties, contracts, matching, messaging, ...27개} ├── entities/ 순수 도메인 모델 — 외부 의존 0 ├── ports/ ABC 인터페이스 └── use_cases/ 비즈니스 로직 (port 만 의존) adapters/ SQLAlchemy · Qdrant · Redis · S3 · OAuth · Socket.io 구현체 api/ · workers/ composition root — 여기서만 wiring
예외를 던지는 대신 Result[T, E] 모나드로 실패를 값으로 다뤘다. 결제·계약처럼 부분 실패가 치명적인 흐름에서 "이 함수가 실패할 수 있는가"가 타입에 드러나야 했기 때문이다.
프론트는 역할별 서브도메인 분기 로 하나의 SPA를 네 개의 앱처럼 쓴다. eodisalji.com 은 세입자, agent.eodisalji.com 은 중개사 콘솔이고, 같은 코드베이스가 뷰포트와 역할을 조합해 세 가지 레이아웃(mobile / desktop-consumer / desktop-dashboard)으로 갈린다. PC로 접속한 세입자에게는 브랜딩 배경 안에 모바일 프레임을 씌우고, 중개사에게는 풀스크린 대시보드를 준다.
만든 것
대화로 조건을 받는 흐름. 마스코트 '열무'가 라이프스타일을 묻고(어디로 출퇴근하는지, 반려동물이 있는지, 예산이 얼마인지), 그 대화에서 추출한 조건이 요청서로 굳는다. 매물 검색 챗봇과 라이프스타일 챗봇을 별도의 헥사곤으로 두고 핸드오프 게이트 하나로 연결했다 — 두 봇의 대화 상태가 섞이면 사용자가 같은 질문을 두 번 받게 되기 때문이다.
같은 거래의 네 시점. 세입자가 낸 요청 하나가 중개사 요청함에 뜨고, 중개사가 보낸 제안이 세입자 제안함에 쌓이고, 채팅에서 방문 일정을 조율하면 거래 단계(상담 → 일정조율 → 예약확정 → 계약진행 → 완료)가 양쪽 화면에서 동시에 움직인다. 상태 전이는 백엔드 이벤트 핸들러가 소유하고 Socket.io 로 밀어준다.
바깥 세계와의 연결. 카카오 맵·다음 우편번호·건축물대장(data.go.kr)·대중교통(TAGO)·학교 정보·전자계약(ModuSign). 외부 서비스는 예외 없이 port 를 먼저 정의하고 어댑터로 붙였다 — 건축물대장 API 가 죽어도 매물 등록은 계속돼야 했다.
운영 도구. LLM 사용량·비용 추적, AI 대화 로그 감사, 채팅방 모니터링, 정산·결제, 중개사 인증 심사. 서비스가 도는 동안 무엇이 일어나는지 운영자가 볼 수 없으면 AI 기능은 관리 불가능한 비용이 된다.
이 데모에 대해
실제 서비스는 로그인해야 하고 실데이터가 걸려 있어 포트폴리오에 그대로 붙일 수 없다. 그래서 프로덕션 프론트엔드를 그대로 옮기고 네트워크 계층만 목업으로 갈아끼운 데모를 따로 만들었다.
fetch 를 가로채는 방식이라 컴포넌트·훅·상태관리는 원본 코드 그대로 돈다. 로딩 스켈레톤도, 낙관적 업데이트도, 에러 토스트도 실제와 같은 경로로 동작한다. 데이터만 대전 유성구를 무대로 한 목업이다.
위 데모 실행 을 누르면 방문자·세입자·중개사 세 시점을 직접 오갈 수 있다. 세입자로 낸 요청이 중개사 요청함에 그대로 있고, 중개사가 보낸 제안 3건이 세입자 화면에서 같은 상태로 보인다.