brunch

You can make anything
by writing

C.S.Lewis

by 노랑자 Sep 11. 2024

부동산에 인공지능 접목하기

나는 석사과정 대학원생이다. 2년이라는 짧은 시간 동안, 연구 이외의 시간을 웹 서비스를 만드는 데 매진했다. 대학원 과정 동안 살 첫 전셋집을 구하면서, 어떻게 이렇게 위험한 시스템이 있는지 많은 의문이 있었다. 그런 의문에 스스로 내린 답이 다른 사람들에게도 도움이 될 수 있을지 검증해보고 싶었다. 1년 반에 가까운 시간 동안 팀을 꾸리고, 사업을 구체화하고, 지원을 받고 구현하는 단계까지. 그렇게 만들어진 AI 전세계약 진단 체크리스트 ‘깡전킬러’의 여정을 기록으로 남긴다. 이번 글에서는 서비스 깡전킬러 개발에 대한 소회를 남긴다.

프로젝트의 발단

나는 건축디자이너였다. 5년제 건축학부를 졸업하고, 대형 건축사사무소에서 다양한 지역, 타입, 규모의 도시 · 건축 프로젝트에 약 3년간 참여했다. 운이 좋게도 신사업 조직에 속해 있으면서 회사에 의뢰가 들어오는 많은 부동산/건설 사업의 개발 단계부터 어깨 너머 경험할 수 있었다. '디지털 전환'과는 거리가 가장 먼 산업에서 그나마 인공지능, 머신러닝, 데이터 사이언스를 미약하게나마 접해볼 볼 수 있는 포지션이었다.

토지에서 발생하는 비즈니스 니즈를 데이터사이언스에 기반해 정량적으로 발굴할 수는 없을까?

회사에서 품었던 궁금증이었다. 결국 건축을 하면서 토지가 개발되는 과정에 관심이 있었던 것. 회사에서 보아 왔던 사업계획서들의 공통점은 근거에 기반해 있다고는 하지만, "역세권 도보 5분", "9호선 황금노선 정차역", "OO택지개발사업으로 N 년 뒤 천지개벽할 지역"과 같은 몇 가지 사실만을 기반해 연역적으로 접근하고 있었다. 지하철 분양사업 광고에서 보이는 마케팅 문구들이 사업개발계획서에 그대로 담겨 있었다. 사업성 분석을 하는 경우에도 여러 가지 가정에 기반해 수익성을 분석하는 과정이었는데, 숫자에 기반한 판단이라고 하더라도 가정이 달라지면 결과에도 큰 차이가 발생하는 지점이 있다고 생각했다. 의사결정 과정을 좀 더 귀납적으로, 데이터에 기반한 방식으로 보완할 수는 없을까?

그래서 나는 데이터사이언스를 기반으로 토지나 건물의 가치를 추정하는 일을 해봐야겠다고 마음을 먹었다. 그렇게 대학원에 진학해 학교에서는 데이터사이언스와 머신러닝과 같은 지식을 습득하고, 그 외 시간에는 지식을 적용하기 위한 틀을 만드는 데 애를 썼다. 그 결과물이 깡전킬러다. (이렇게 비장한 마음을 먹었었더랬지만, 아직 갈 길이 멀었다)

프로젝트의 챌린지 요소들

(1) 머신러닝 모델 구축

깡전킬러는 그런 의미에서 전세계약의 위험성을 계량하고자 하는 시도였다. 2021년 젠세사기 대란이 있기 이전에는 '전세의 위험성'이라는 개념은 분명 사회에서 희박했다. 2021년도 초입은 내가 데이터사이언스를 시작한 시점이었다. 주택의 위험성을 계량하는 것은 분명 필요한 일이었다.

기술적 관점에서 깡전킬러는 단순했다. 머신러닝을 기반으로 경매낙찰가를 추정하는 일이었다. 회귀(Regression)를 푸는 문제였으니 아주 기본적인 난이도였다. 문제는 데이터였다. 경매낙찰가는 법원경매사이트에서 한시적으로 공개하고 개인정보보호를 위해 비공개처리하는 값이었다. 당시 온라인 경매 웹사이트에서는 차곡차곡 수집해 온 경매낙찰가 데이터로 경매투자자들을 대상으로 AI예측 경매낙찰가를 제공하는, 그야말로 돈 되는 사업에 착수하고 있었다.

우리에겐 당연히 그런 자료는 없었다. 머신러닝으로 경매낙찰가를 추정해 내는 수밖에. 그래서 정말 단순하게 실거래가에 경매낙찰가율을 곱했다. 실거래가와 경매낙찰가율 모두 머신러닝으로 추정했다. 모델은 테스트데이터셋에 대해 98~99%대의 성능(MdAPE)을 보였다. 하지만 낯선 신규 데이터셋에 대해서는 괴리율이 얼마나 될지 검증하기 어려웠다.

우리가 가진 값이 지리적으로 한정된 대한민국이라는 공간 안에서 얻을 수 있는 최대치였기 때문에. 부동산 분야에서 아파트를 제외하고 인공지능이 발전하기 힘든 이유를 몸소 깨달았다. 데이터가 적어 robust 한 모델을 만드는 데 한계가 있기 때문이다. 모델이 robust 하지 않으면 고객에게 신뢰할 수 있는 정보를 주기 어렵다. 더더욱 신뢰성과 근거가 생명인 분야(금융, 의료, 법규 등)에서 상용화하기 어려우며, 의사결정의 보조수단에서 시작할 수밖에 없는 상황이다.

(2) 데이터셋 확보

데이터 기반 부동산 서비스를 만드는 데 있어 가장 큰 곤란함을 줬던 것은 건축물대장 데이터였다. 건축물대장은 건물의 타입에 따라 크게 4가지로 나뉘는데, 이 데이터셋 간의 PK가 잘 맞지 않았다. 또 어려움을 준 것은, 지리정보의 단위였다. 칼럼레벨에서 정의하고 있는 구분가능한 지리정보의 단위는 도로명주소였다. 하지만 한국 아파트의 특성상 대규모 아파트단지들은 하나의 주소로 묶이는데, 이를 한 번 더 세분화하려면 상세주소를 봐야 했다. 이 과정에서 단지마다 '동'의 표현이 달랐다. 여러 개의 룰을 적용해서 필터를 걸어도 계속해서 예외가 발생했던 덕에, 데이터엔지니어가 고생을 토로하곤 했다.

충분한 규모의 샘플만 얻으면 되는 연구와 달리, 서비스를 만드는 과정은 단 하나의 주소에 대한 누락도 허용할 수 없었다. 서비스에 들어왔을 때 내가 찾고 있는 집이 제공되고 있지 않다는 걸 알게 되었을 때, 서비스에 대한 신뢰가 떨어질 것이기 때문이다. 그런 의미에서 호갱노노가 지리정보 가공에 있어 톡톡한 공헌을 했다는 걸 많이 느꼈다. 제한적인 데이터를 기반으로 유의미하게 단위를 더 쪼개고, 의미를 뽑아볼 수 있도록 시각화했다는 점에서 얼마나 많은 토론과 시행착오를 거쳤을지! (그것도 전국 단위로)

머신러닝을 위한 데이터셋의 경우엔, 서비스를 위한 데이터셋과 맞물리는 지점이 있었기에 어렵지 않았다. 다만 모든 주소지에서 각종 거점까지의 최단경로를 계산하는 지리적 연산과정에서 시간을 많이 잡아먹었다. 코딩의 고수라면 이런 지점을 최적화할 수 있었을 텐데, 블로그 글(이때는 chatGPT 출시 직전이었으므로, 블로그를 잘 참고하는 게 중요했음)에 의존하던 코딩 초보에겐 어려운 일이었다.

(3) 협업의 어려움

위의 어려움은 해결할 수만 있다면 기꺼이 엉덩이를 의자에 붙여놓을 수 있는 그런 종류의 어려움이다. 더 큰 어려움은 협업에 있었다. 우리는 각자 연구, 건축설계, 개발을 완결성 있게 끝낼 수 있는 개인들의 모임이었다. 하지만 서비스 개발은 처음이었다. 서비스 개발은 긴 호흡으로 기 - 승 - 전전전전 ··· 을 유지해야 하는 종류의 일이었다. 나에겐 기승전결식 사고방식이 기본이었던지라, '서비스를 구축'해보는 경험 목표로 팀이 움직이게 되었다. 하지만 완성도 있는 서비스를 구축한다는 것은 잘 운영될 수 있도록 기반을 닦아놓는 것이라는 점을 완성 이후 깨닫게 되었다. 운영될 수 있는 기반을 닦아놓는다는 것은, 누가 와서 보더라도 재생산할 수 있을 정도로 일관성 있는 코드 작성 체계, 원활하게 데이터를 업데이트받을 수 있는 환경, 유저의 활동을 모니터링하고 또 피드백을 받을 수 있는 체계를 의미한다. 기승전결식 사고방식에서는 당연히 신경 쓸 수 없는 부분이다.

따라서 자연스럽게 무늬만 애자일이었던 것 같다. 완결성 있는 전체를 만들기 위해, 기승전결을 만들기 위해 매 프로세스 최대한의 공을 들여 워터폴 프로젝트를 진행했다. 우리가 체크리스트 수준의 첫 베타를 출시할 때쯤, 투자받을 당시 경쟁자들은 법률지원서비스로 확장하고 있었다. 능력과 의지가 넘치는 구성의 팀이었지만, 각자가 프로젝트를 대해왔던 태도에서 오는 관성의 힘은 강력했다. (그나마 스타트업 경험이 있는 개발자가 진행방식에 챌린지를 많이 걸어주었다.)

더 해봤으면 좋았을 점

아파트 / 오피스텔이 아닌 저층주택을 타깃으로 했어야

깡통전세 위험 진단이 가장 필요한 영역은 다가구주택과 다세대주택이다. 부끄럽지만 데이터와 잠재적 수요자의 풍부함을 따졌을 때, 아파트와 오피스텔을 타깃으로 한 서비스가 우선순위라고 생각했다. 완성에 1년에 가까운 시간이 걸리기도 했지만, 오히려 인기(있을 것 같은!)를 선택하다 보니 뾰족한 서비스가 되지도 못했거니와, 본질에 충실하지 못하기도 했다.

LLM 서비스로 만들어졌더라면

우리는 서비스를 체크리스트 형태로 만들었다. 전세입주에는 따져야 할 리스크들이 꽤 있는데, 법적인 이슈도 혼재되어 있다 보니 유저가 직관적으로 정보를 처리할 수 있도록, "쉽게 꼼꼼해질 수 있도록", 진행률이 표시되는 체크리스트로 서비스를 만들었더랬다. 지금 와서 보니 이런 일을 가장 잘해줄 수 있는 게 GPT 아니던가. 미니 리스크 검토용 LLM 서비스 형태로 만들었다면 정말 효과적이었을 텐데! 일일이 리스크를 쉽게 설명하는 텍스트를 작성하고 페이지 레이아웃을 고민할 필요가 없었을 것이다. 유저도 궁금한 점에 대해 인터렉션 할 수 있는 아주 날카로운 서비스가 될 수 있었을 것 같다.

IT 컨설턴트로 일하고 있는 지금

대학원에서의 우여곡절 끝에 나는 현재 IT컨설턴트로 일하고 있다. 도시에서의 삶을 개선할 수 있는 데이터기반 서비스를 만들어보고자 시도했던 깡전킬러의 경험을 토대로, 산업과 공공영역에서 보다 전문적으로 필요한 IT 서비스를 기획하는 일을 하고 싶었다.

지금 와서 돌이켜보면 깡전킬러를 만든 경험은 작은 수주와 이행 경험이었다. 프로젝트를 만드는 입장에서는 완결만 되면 되었지만, 프로덕트로 가치를 만들어야 하는 사람 입장에서는 프로세스에 대한 지속적 관리 역량이 요구된다는 점을 배웠다. 일을 완결하는 것에서 나아가 상품에 대한 관리 역량의 관점을 얻게 된 소중한 경험이다.

당장은 주니어라 관리 역량까지 전방위적으로 요구받고 있진 않지만, 앞으로 직급이 올라가면서 더 큰 일, 더 많은 일에 대한 관리를 요구받을 것이다. 커리어에서뿐만 아니라 인생에서도 마찬가지 원리가 적용되고 있다고 본다. 눈앞에 닥친 과제를 완성하는 것에서, 학점관리, 가족 챙기기, 건강 관리하기, 재산 관리하기 등등. 완벽한 완성이란 없으며, 꾸준히 일관되게 굴러갈 수 있도록 환경을 조성하는 것이 중요하다고 느끼게 되었다. 이다음에 나에게 주어질 프로덕트 개발 기회를 고대하며, 대학원에서의 장정을 마무리한다.