과거 거래, 현재 기준점, 미래 예상 범위를 나누어 보는 개념도

{ "version": "https://jsonfeed.org/version/1", "title": "alvin.ing", "home_page_url": "https://alvin.ing/blog", "description": "아파트 실거래가와 부동산 통계를 제대로 읽는 기준부터 취득세·양도세 거래비용 계산기, 분양권 손피 계산기까지 제공하는 데이터 아카이브입니다.", "items": [ { "id": "https://alvin.ing/blog/europe-bond-yield-surge-korea-apartment", "content_html": "

미국만 난리가 아닙니다. 9월 초 독일 10년물 국채금리는 2011년 5월 이후 처음으로 3.3%를 넘었고, 프랑스 금리는 2008년 이후, 영국 30년물 국채금리는 1998년 이후 최고 수준까지 올라섰습니다. 유럽중앙은행(ECB)은 9월 예금금리를 2.25%에서 2.50%로 올리면서 물가가 “상당 기간 목표를 크게 웃돌 수 있다”고 경고했습니다.

\n

유럽 국채 이야기는 한국 아파트와 거리가 멀어 보이지만, 금리·환율·에너지 가격을 거치면 생각보다 가깝습니다. 이 글은 유럽발 채권시장 충격이 한국 주택시장으로 들어오는 경로를 세 가지로 나눠 정리합니다.

\n

유럽 채권시장에서 벌어진 일

\n

구분	2026년 9월 보도 기준
독일 10년물	3.3% 돌파, 2011년 5월 이후 최고
프랑스 국채	2008년 11월 이후 최고 수준
영국 10년물	5.3%대, 2007년 이후 최고
영국 30년물	5.9%대, 1998년 이후 최고
유럽중앙은행	예금금리 2.25% → 2.50% 인상

\n

배경으로는 에너지 가격 상승, 끈질긴 물가, 주요 중앙은행의 긴축 신호가 함께 꼽힙니다. 9월 말 일부 유럽 금리가 숨을 고르긴 했지만, 같은 시기 미국 장기금리는 오히려 2000년대 초반 이후 최고치를 경신했습니다. 한 지역의 문제가 아니라 전 세계 장기금리가 함께 다시 올라가는 국면이라는 점이 핵심입니다. 미국 쪽 상황은 미국 30년물 금리와 주담대 금리에서 따로 정리했습니다.

\n

경로 1. 글로벌 금리 동조화 → 국내 대출금리

\n

채권시장은 국경을 넘어 연결돼 있습니다. 유럽과 미국의 장기금리가 함께 오르면 국내 국고채·은행채 금리도 상승 압력을 받습니다. 은행채 금리는 고정형·혼합형 주택담보대출 금리의 기준이 되기 때문에, 해외 채권시장의 흔들림이 시차를 두고 대출 창구까지 내려옵니다.

\n

실제로 국내 은행 주담대 신규취급 금리는 8월 기준 연 4.66%로 4개월 연속 올랐고, 한국은행도 7월과 8월에 기준금리를 연속으로 인상해 연 3.00%가 됐습니다. 해외발 금리 압력과 국내 긴축이 겹친 상황입니다.

\n

경로 2. 환율 → 수입물가와 금리 결정

\n

유럽·미국 금리가 오르면 해외 자산의 상대적인 수익률이 높아져, 원화 가치가 압력을 받을 수 있습니다. 원·달러 환율이 오르면 다음 순서로 주택시장에 간접적인 영향이 생깁니다.

\n

수입물가 상승 — 원자재·에너지 수입 비용이 커지면서 물가 부담이 늘어납니다.
금리 인하 여력 축소 — 물가와 환율이 불안하면 한국은행이 금리를 내리기 어려워집니다.
건설 원가 부담 — 수입 자재 가격이 오르면 신축 공사비와 분양가에 부담이 쌓입니다.

\n

환율은 집값을 직접 움직이기보다 금리가 내려오기 어려운 환경을 만드는 쪽으로 작용하는 경우가 많습니다.

\n

경로 3. 에너지 가격 → 물가 → 긴축 장기화

\n

이번 유럽 채권 매도의 직접적인 계기 중 하나는 에너지 가격입니다. 유가와 가스 가격이 오르면 물가가 쉽게 내려오지 않고, 중앙은행은 금리를 더 오래 높게 유지할 가능성이 커집니다.

\n

주택시장 입장에서는 “금리가 언제 내려오느냐”가 매수 수요의 가장 큰 변수인데, 에너지발 물가는 그 시점을 뒤로 미루는 요인입니다. 한국처럼 에너지를 대부분 수입하는 나라는 이 경로의 영향을 더 크게 받습니다.

\n

세 경로를 한 번에 보면

\n

경로	해외 변화	국내에서 나타나는 모습	주택시장 영향
금리 동조화	유럽·미국 장기금리 상승	은행채·주담대 금리 상승	대출 부담 증가, 매수 수요 위축
환율	해외 금리 매력 상승	원화 약세 압력	금리 인하 지연, 건설 원가 부담
에너지	유가·가스 가격 상승	수입물가·소비자물가 상승	긴축 장기화 가능성

\n

세 경로는 따로 움직이지 않고 서로를 강화합니다. 금리·환율·유가가 동시에 불리한 방향으로 움직일 때 주택시장의 부담이 커지고, 반대로 하나라도 방향이 바뀌면 분위기가 빠르게 달라질 수 있습니다.

\n

그래도 지역과 단지마다 결과는 다릅니다

\n

거시 충격은 전국에 같이 오지만, 가격이 반응하는 크기는 단지마다 다릅니다. 입주 물량이 많은 지역, 전세가율이 낮아 매매가를 받쳐 주는 힘이 약한 단지, 대출 의존도가 높은 가격대는 같은 충격에도 더 크게 흔들릴 수 있습니다. 반대로 공급이 적고 실수요가 두터운 곳은 거래만 줄고 가격은 버티는 경우도 있습니다. 전세가율이 왜 중요한지는 전세가율이 높으면 매수하기 좋을까?에서 다뤘습니다.

\n

관심 단지의 1년 뒤 범위부터 확인해 보기

\n

해외 뉴스가 쏟아질수록 “그래서 내가 보는 아파트는?”이라는 질문으로 돌아와야 합니다. 아파트 인사이트의 가입 없이 1년 시세 체험에서는 관심 단지와 평형을 고르면, 최근 실거래와 금리·환율 같은 시장 정보를 바탕으로 한 1년 뒤 예상 범위를 바로 볼 수 있습니다. 범위를 읽는 방법은 아파트 예상 범위의 아래·가운데·위 값 읽는 법을 참고하세요.

\n

자주 묻는 질문

\n

유럽 금리가 오르면 한국 금리도 오르나요?

\n

같은 폭으로 움직이지는 않지만, 글로벌 채권시장이 연결돼 있어 국내 국고채·은행채 금리에 상승 압력이 생깁니다. 특히 미국 장기금리까지 함께 오르는 시기에는 국내 대출금리에도 반영될 가능성이 커집니다.

\n

환율이 오르면 아파트 가격도 오르나요, 내리나요?

\n

환율은 집값을 한 방향으로 직접 움직이기보다 물가와 금리를 거쳐 간접적으로 영향을 줍니다. 환율 상승이 물가를 자극해 금리 인하를 늦추면 매수 수요에는 부담이 되고, 수입 자재 비용 상승은 신축 원가 부담으로 이어질 수 있습니다.

\n

해외 금리 뉴스가 나올 때마다 매수 계획을 바꿔야 하나요?

\n

뉴스 하나로 계획을 바꾸기보다 금리·환율·유가가 같은 방향으로 계속 움직이는지, 관심 단지의 실제 거래가 줄거나 가격 범위가 바뀌는지를 함께 확인하는 것이 좋습니다. 지켜볼 지표를 정리하는 방법은 거시지표가 흔들릴 때 아파트 매수 타이밍 체크리스트를 참고하세요.

\n

참고 자료

\n

\n

\n
이 글은 공개 보도를 바탕으로 해외 채권시장 변화가 국내 주택시장에 전달되는 일반적인 경로를 설명한 참고 자료입니다. 특정 아파트의 매수·매도를 권유하지 않으며, 예상 범위는 오차가 있을 수 있고 가격이나 수익을 보장하지 않습니다.
\n

", "url": "https://alvin.ing/blog/europe-bond-yield-surge-korea-apartment", "title": "독일 2011년, 영국 1998년 이후 최고… 유럽 국채 쇼크가 한국 아파트에 닿는 3가지 경로", "summary": "2026년 9월 독일·프랑스·영국 국채금리가 십수 년 만의 최고치를 기록하고 유럽중앙은행이 금리를 올렸습니다. 유럽 채권시장 충격이 환율, 에너지 가격, 글로벌 금리 동조화를 거쳐 한국 아파트 시장에 영향을 주는 경로를 정리합니다.", "date_modified": "2026-10-03T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "금융·세금", "아파트" ] }, { "id": "https://alvin.ing/blog/macro-volatility-apartment-timing-checklist", "content_html": "

미국 30년물 국채금리는 2002년 이후 최고, 독일 국채금리는 2011년 이후 최고, 영국 30년물은 1998년 이후 최고. 연준은 2023년 이후 처음으로 금리를 올렸고, 한국은행은 7월과 8월 연속 인상으로 기준금리를 연 3.00%까지 올렸습니다. 국내 은행 주담대 금리는 3년 9개월 만의 최고치입니다.

\n

이런 뉴스가 한꺼번에 쏟아지면 “지금 사면 꼭지 아닐까”, “더 떨어지기 전에 팔아야 하나” 같은 불안이 커집니다. 하지만 거시지표가 혼란스러운 시기일수록 바닥과 꼭지를 맞히려는 시도는 거의 실패합니다. 대신 무엇을 지켜보고, 어떤 신호가 나오면 움직일지 기준을 미리 정해 두는 쪽이 훨씬 현실적입니다.

\n

타이밍은 “맞히는 것”이 아니라 “기준을 정하는 것”

\n

금리 상승기에는 두 가지 실수가 자주 나옵니다.

\n

공포 매도·매수 포기: 뉴스 헤드라인만 보고 실수요 계획까지 무기한 미루거나, 급하게 매도를 결정합니다.
반등 기대 추격: 금리가 잠깐 내려가는 날 “이제 바닥”이라며 준비 없이 들어갑니다.

\n

둘 다 기준 없이 뉴스에 반응한 결과입니다. 아래 체크리스트는 “지금 사라”, “지금 팔아라”를 말하지 않습니다. 대신 어떤 지표가 어느 방향으로 바뀌는지 꾸준히 기록하는 틀입니다.

\n

체크리스트 1. 거시지표 5가지

\n

지표	확인할 질문	왜 중요한가
미국·유럽 장기금리	상승이 멈추고 몇 주 이상 안정되는가?	국내 은행채·고정형 대출금리의 바깥쪽 압력입니다.
한국 기준금리	다음 금융통화위원회에서 동결·인상 중 어느 쪽 신호인가?	변동형 대출금리와 시장 기대를 직접 바꿉니다.
국내 주담대 금리	신규취급 금리가 몇 달째 같은 방향인가?	매수 수요에 가장 직접적인 숫자입니다.
원·달러 환율	급등이 진정되는가?	물가와 금리 인하 여력에 영향을 줍니다.
유가·에너지 가격	물가를 다시 자극하는가?	긴축이 길어질지 가늠하는 단서입니다.

\n

이 다섯 가지를 매일 볼 필요는 없습니다. 한 달에 한두 번, 같은 날짜에, 같은 기준으로 기록하는 것만으로도 “분위기”가 아니라 “방향”을 볼 수 있습니다. 미국·유럽 금리 상황은 미국 30년물 금리와 주담대 금리, 유럽 국채 쇼크가 한국 아파트에 닿는 경로에서 정리했습니다.

\n

체크리스트 2. 관심 단지 신호 4가지

\n

거시지표가 “바람의 방향”이라면, 관심 단지의 거래는 “내 집 앞의 실제 날씨”입니다.

\n

같은 평형 최근 1년 거래 범위 — 최근 거래가 범위의 위쪽에 붙는지, 아래쪽으로 내려오는지 봅니다.
거래 건수 — 금리 충격은 가격보다 거래량에 먼저 나타나는 경우가 많습니다. 거래가 급감하면 가격 신호를 해석할 표본도 줄어듭니다.
전세가율 — 전세가가 매매가를 받쳐 주는 힘이 유지되는지 확인합니다. 해석 방법은 전세가율이 높으면 매수하기 좋을까?를 참고하세요.
1년 뒤 예상 범위의 변화 — 한 번의 예측값보다 지난달 대비 범위가 위·아래 어느 쪽으로 옮겨 갔는지가 더 유용합니다.

\n

체크리스트 3. 내 자금 조건 3가지

\n

금리 1%p 상승을 견디는가 — 지금보다 1%p 높은 금리에서도 월 상환액이 감당되는지 계산합니다.
거래비용까지 넣었는가 — 취득세·중개보수·이사비를 포함한 총자금은 아파트 거래비용 계산기로 미리 확인합니다.
언제까지 결정해야 하는가 — 전세 만기, 입학, 이직처럼 실제 마감일이 있는 실수요자는 “최적의 시점”보다 “감당 가능한 시점”을 기준으로 삼는 편이 안전합니다.

\n

신호가 엇갈릴 때 읽는 법

\n

현실에서는 지표가 한 방향으로 깔끔하게 정리되는 경우가 드뭅니다. 자주 나오는 조합을 정리하면 다음과 같습니다.

\n

상황	해석	할 일
거시지표 악화 + 관심 단지 거래 유지	실수요가 받치고 있지만 금리 부담이 누적되는 중	거래 범위가 아래로 이동하는지 계속 기록
거시지표 악화 + 거래 급감	관망세가 짙어짐, 가격 신호는 아직 불확실	표본이 다시 쌓일 때까지 범위 변화 위주로 관찰
장기금리 안정 + 거래 회복	분위기 전환 가능성, 다만 일시적 반등일 수 있음	몇 달 이상 같은 방향인지 확인 후 자금 계획 점검
금리 하락 + 환율·유가 불안	금리 인하 기대가 다시 꺾일 위험	금리 시나리오를 여러 개로 나눠 비교

\n

아파트 인사이트로 모니터링하는 방법

\n

체크리스트를 손으로 매달 채우는 것은 생각보다 번거롭습니다. 아파트 인사이트에서는 위 흐름을 한곳에서 이어서 볼 수 있습니다.

\n

부동산 시장 국면 — 홈 화면에서 지금 시장을 0~100점 점수와 “매우 우호·우호·관망·주의·위험” 단계로 요약하고, 지난번 대비 변화와 함께 금리·심리·정책·대외환경 가운데 유리·불리하게 작용하는 주요 신호를 보여줍니다.
관심 아파트와 실거래 변화 — 관심 단지를 등록해 두면 새 실거래가 반영된 흐름을 단지 상세에서 확인하고, 변경 사항을 알림으로 받을 수 있습니다.
조건을 바꾼 시나리오 비교 — 시뮬레이션에서 금리 같은 거시경제 조건을 직접 조절해, 기준 예측과 조건을 바꾼 결과를 나란히 놓고 볼 수 있습니다. “금리가 0.5%p 더 오르면”, “금리가 지금 수준에서 멈추면” 같은 경우를 미리 비교해 두면, 실제 뉴스가 나왔을 때 당황하지 않고 기준대로 판단할 수 있습니다.

\n

먼저 가입 없이 관심 단지의 1년 뒤 예상 범위만 보고 싶다면 가입 없이 1년 시세 체험에서 시작해도 됩니다.

\n

자주 묻는 질문

\n

금리가 오르는 지금은 아파트를 사면 안 되나요?

\n

금리 상승은 매수 부담을 키우지만, 그것만으로 매수 여부를 정할 수는 없습니다. 실거주 필요 시점, 금리 1%p 상승 시 상환 여력, 관심 단지의 실제 거래 흐름을 함께 확인하고, 여러 금리 시나리오에서도 감당 가능한지 따져 보는 것이 좋습니다.

\n

부동산 시장 국면 점수가 높으면 사도 된다는 뜻인가요?

\n

아닙니다. 시장 국면 점수는 전체 시장 분위기를 요약한 참고 지표이며 특정 단지의 매수 시점을 알려주는 신호가 아닙니다. 단지별 판단은 해당 단지의 거래 흐름과 예상 범위, 개인의 자금 조건을 함께 봐야 합니다.

\n

거시지표는 얼마나 자주 확인해야 하나요?

\n

뉴스가 많은 시기라도 한 달에 한두 번, 같은 기준으로 기록하는 정도면 충분합니다. 하루하루의 등락보다 몇 주에서 몇 달에 걸친 방향이 주택시장에는 더 의미가 있습니다.

\n

참고 자료

\n

\n

\n
이 글은 거시지표와 주택시장 신호를 정리하는 방법을 설명한 참고 자료이며, 투자 권유나 매수·매도 추천이 아닙니다. 시장 국면과 예상 범위는 오차가 있을 수 있고 가격·거래 가능성·수익을 보장하지 않습니다. 최종 결정과 책임은 이용자에게 있으며, 실제 계약 전에는 금융기관 조건과 공식 자료를 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/macro-volatility-apartment-timing-checklist", "title": "채권 발작에 금리 인상까지… 지금 아파트 사도 될까? 거시지표 혼란기 타이밍 체크리스트", "summary": "미국·유럽 장기금리 급등과 국내 기준금리 인상이 겹친 2026년 가을, 아파트 매수·매도 시점을 고민할 때 지켜봐야 할 거시지표 5가지와 관심 단지 신호를 체크리스트로 정리합니다.", "date_modified": "2026-10-03T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "금융·세금", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/us-long-bond-yield-surge-mortgage-rate", "content_html": "

미국 30년 만기 국채금리가 9월 말 2002년 이후 가장 높은 수준까지 올라섰습니다. 10월 2일 기준 30년물은 5.6%대, 10년물은 5.2%대에 머물러 있습니다. 미국 연방준비제도(연준)는 9월 16일 기준금리를 0.25%p 올려 3.75~4.00%로 맞췄는데, 2023년 이후 첫 인상입니다.

\n

“미국 채권 이야기가 내 아파트랑 무슨 상관이냐”고 생각하기 쉽지만, 같은 기간 한국의 은행 주택담보대출 금리는 연 4.66%로 3년 9개월 만에 최고치를 찍었습니다. 이 글은 태평양 건너 장기금리가 내 대출이자와 아파트 매수 수요까지 어떻게 이어지는지, 숫자를 볼 때 무엇을 헷갈리면 안 되는지 정리합니다.

\n

지금 무슨 일이 벌어지고 있나

\n

최근 한 달 동안 확인된 사실만 먼저 모아 보겠습니다.

\n

구분	최근 상황 (2026년 9월~10월 초 보도 기준)
미국 30년물 국채금리	9월 말 2002년 이후 최고 수준, 10월 2일 5.6%대
미국 10년물 국채금리	10월 2일 5.2%대
미국 기준금리	9월 16일 0.25%p 인상, 3.75~4.00% (2023년 이후 첫 인상)
한국 기준금리	7월·8월 연속 인상, 8월 27일 연 3.00%
국내 은행 주담대 금리	8월 신규취급 가중평균 연 4.66%, 2022년 11월 이후 최고, 4개월 연속 상승

\n

시장에서 꼽는 배경은 대체로 비슷합니다. 물가가 예상보다 오래 높게 유지되고 있고, 중동 정세로 유가가 올랐으며, 미국 정부 부채가 커지면서 장기채를 사려는 쪽이 더 높은 금리를 요구하고 있다는 것입니다. 10월 2일 발표된 미국 9월 고용지표가 예상보다 크게 약했는데도 장기금리가 다시 올랐다는 점은, 이번 금리 상승이 경기만으로 설명되지 않는다는 신호로 읽힙니다.

\n

미국 장기금리가 내 주담대까지 오는 4단계

\n

미국 국채금리가 한국 대출금리에 그대로 더해지는 것은 아닙니다. 다만 다음 경로로 압력이 전달됩니다.

\n

미국 장기금리 상승 — 전 세계 채권 금리의 기준점 역할을 하는 미국 국채금리가 오르면, 다른 나라 채권도 상대적으로 매력이 떨어집니다.
국내 시장금리 동반 상승 — 국고채, 은행채 같은 국내 채권 금리도 따라 오를 압력을 받습니다. 은행이 대출 재원을 마련하는 비용이 커집니다.
고정형·혼합형 주담대 금리 상승 — 은행채 금리를 기준으로 삼는 고정형·혼합형 대출 금리가 먼저 움직이고, 변동형은 코픽스 등 기준금리를 따라 시차를 두고 반영됩니다.
매수 수요와 거래량 변화 — 같은 소득으로 빌릴 수 있는 금액이 줄고, 매달 갚을 이자가 늘어나면서 매수 결정을 미루는 사람이 늘어납니다.

\n

여기에 한국은행이 7월과 8월에 기준금리를 연속으로 올린 것까지 겹쳤습니다. 이번 대출금리 상승은 미국발 장기금리 압력과 국내 통화 긴축이 동시에 작용한 결과라는 점이 이전과 다릅니다.

\n

금리 0.5%p가 매달 갚는 돈을 얼마나 바꿀까

\n

금리 변화는 퍼센트로 보면 작아 보이지만, 월 상환액으로 바꾸면 체감이 달라집니다. 3억 원을 30년 원리금균등상환으로 빌린다고 가정해 보겠습니다.

\n

대출금리	월 상환액(약)	연 4.0% 대비 차이
연 4.0%	143만 원	—
연 4.5%	152만 원	약 +9만 원
연 5.0%	161만 원	약 +18만 원
연 5.5%	170만 원	약 +27만 원

\n

\n
단순 계산 예시입니다. 실제 대출 조건은 상환 방식, 가산금리, 우대금리, 규제 비율에 따라 달라집니다.
\n

\n

같은 월 상환 여력으로 버틸 수 있는 대출 원금도 줄어듭니다. 금리가 오를 때 거래가 먼저 줄고 가격은 시차를 두고 움직이는 경우가 많은 이유가 여기에 있습니다. 금리와 아파트 가격의 일반적인 관계는 주택담보대출 금리와 아파트 가격의 상관관계에서 더 자세히 다뤘습니다.

\n

“금리 오르면 집값 폭락”이 항상 맞지 않는 이유

\n

금리 상승은 분명한 하방 압력이지만, 그것 하나로 가격 방향이 정해지지는 않습니다.

\n

공급: 같은 시기에 새 아파트 입주 물량이 적은 지역은 금리 부담이 커져도 가격이 쉽게 밀리지 않을 수 있습니다.
전세가율: 전세가가 매매가를 받쳐 주는 단지와 그렇지 않은 단지는 같은 금리 충격에도 반응이 다릅니다.
소득과 경기: 한국은행은 올해 성장률 전망을 3.3%로 올렸습니다. 소득이 함께 늘면 금리 부담 일부가 상쇄됩니다.
정책: 대출 규제나 세제 변화는 금리보다 더 직접적으로 매수 수요를 바꾸기도 합니다.

\n

그래서 “미국 금리가 올랐으니 지금 집을 팔아야 한다” 또는 “곧 폭락하니 기다리면 된다” 같은 단정은 위험합니다. 중요한 것은 금리 변화가 내가 보는 단지와 내 자금 계획에 얼마나 영향을 주는지를 따로 확인하는 일입니다.

\n

지금 확인해 볼 3가지

\n

내 대출의 금리 유형 — 고정형인지, 혼합형이라면 언제 변동으로 바뀌는지, 변동형이라면 몇 개월 주기로 재산정되는지 확인합니다.
금리 1%p 상승 시 월 상환액 — 지금 금리보다 1%p 높은 조건에서도 생활비가 버티는지 미리 계산해 둡니다.
관심 단지의 최근 거래 흐름 — 금리 뉴스보다 실제 거래가 줄고 있는지, 같은 평형 거래 범위가 아래로 움직이는지가 더 직접적인 신호입니다. 최근 거래를 읽는 순서는 지역별 아파트 실거래가 조회하는 법에 정리했습니다.

\n

금리 조건을 바꿔 내 단지에 적용해 보기

\n

뉴스의 금리는 “시장 평균”이고, 내가 궁금한 것은 “내 단지와 내 조건”입니다. 아파트 인사이트의 시뮬레이션에서는 관심 아파트를 고른 뒤 주담대 금리 같은 거시경제 조건을 직접 조절해, 기준 예측과 조건을 바꾼 결과를 나란히 비교할 수 있습니다. “금리가 지금보다 0.5%p 더 오르면 1년 뒤 예상 범위가 어떻게 달라지는가”를 한 화면에서 확인하는 식입니다.

\n

자주 묻는 질문

\n

미국 국채금리가 오르면 한국 주담대 금리도 바로 오르나요?

\n

바로 같은 폭으로 오르지는 않습니다. 다만 국내 국고채·은행채 금리가 함께 오를 압력을 받기 때문에, 은행채를 기준으로 하는 고정형·혼합형 대출 금리에 먼저 반영되는 경우가 많습니다. 변동형은 기준 지표에 따라 시차를 두고 움직입니다.

\n

지금 고정금리로 갈아타는 게 유리한가요?

\n

개인의 대출 잔액, 남은 기간, 중도상환수수료, 앞으로의 금리 경로에 따라 답이 달라집니다. 금리가 더 오를지 내릴지는 누구도 확정할 수 없으므로, 갈아타기 비용과 금리 1%p 상승·하락 시 월 상환액 차이를 함께 계산해 보고 결정하는 것이 좋습니다.

\n

금리가 오르면 아파트 가격은 반드시 떨어지나요?

\n

금리 상승은 하방 압력이지만 공급, 전세가율, 소득, 정책에 따라 지역과 단지별 반응이 다릅니다. 거래량이 먼저 줄고 가격은 시차를 두고 움직이는 경우가 많아, 금리 뉴스와 실제 거래 흐름을 함께 확인해야 합니다.

\n

참고 자료

\n

\n

\n
이 글은 공개 보도와 통계를 바탕으로 금리 변화의 전달 경로를 설명한 참고 자료이며, 특정 대출 상품이나 아파트의 매수·매도를 권유하지 않습니다. 금리와 가격 전망은 오차가 있을 수 있고 수익을 보장하지 않으므로, 실제 결정 전에는 금융기관 조건과 공식 자료를 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/us-long-bond-yield-surge-mortgage-rate", "title": "미국 30년물 금리 2002년 이후 최고… 왜 내 주담대 금리까지 오를까", "summary": "미국 30년 만기 국채금리가 2000년대 초반 이후 최고 수준까지 오르면서 국내 주택담보대출 금리도 3년 9개월 만에 최고치를 기록했습니다. 미국 장기금리가 한국 아파트 대출이자와 매수 수요로 이어지는 경로를 정리합니다.", "date_modified": "2026-10-03T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "금융·세금", "아파트" ] }, { "id": "https://alvin.ing/blog/apartment-app-guest-mode", "content_html": "

아파트 시세 앱을 설치했는데 첫 화면부터 회원가입을 요구하면, “그냥 우리 아파트 하나만 보고 싶은데”라는 생각이 들기 마련입니다. 관심 단지 하나의 시세와 앞으로의 흐름을 가볍게 확인하는 데 계정까지 만들 필요는 없습니다.

\n

이 글은 로그인 없이 아파트 앱에서 관심 단지의 시세와 전망을 확인하는 흐름을 정리합니다. 무엇을 고르면 되는지, 어떤 정보가 보이는지, 그리고 어떤 경우에 로그인이 필요한지를 순서대로 살펴봅니다.

\n

로그인 없이 보는 방식이 맞는 사람

\n

다음 상황이라면 로그인 없는 이용 방식으로 충분합니다.

\n

지금 사는 집이나 관심 있는 단지 한 곳의 시세가 궁금할 때
이사·갈아타기를 고민 중인데 특정 시점의 가격 흐름을 가볍게 보고 싶을 때
앱이 내 질문에 맞는지 먼저 써 보고, 필요하면 나중에 가입하고 싶을 때

\n

반대로 여러 단지를 저장해 비교하거나, 금리·세금 같은 조건을 바꿔 가며 시나리오를 돌려 보거나, 전망이 바뀔 때 알림을 받고 싶다면 로그인 후 기능이 더 맞습니다.

\n

고르는 것은 세 가지뿐입니다

\n

로그인 없는 이용 방식의 핵심은 선택지를 줄이는 것입니다. 앱에서 다음 세 가지만 고르면 됩니다.

\n

선택	의미	고를 때 확인할 점
아파트 1곳	시세와 전망을 확인할 단지	같은 이름의 단지가 있으면 지역과 준공 연도를 맞춰 봅니다.
평형 1개	비교 기준이 되는 면적	실제 관심 있는 전용면적과 같은지 확인합니다.
목표 월 1개	가격을 확인하고 싶은 시점	이사·매수·매도 계획과 맞는 달을 고릅니다.

\n

목표 월을 고르는 이유는 “1년 뒤”라는 막연한 기준보다 내 계획과 맞는 시점의 가격을 보기 위해서입니다. 다만 목표 월이 멀어질수록 금리·공급·정책이 바뀔 시간도 길어지므로 예상 범위가 넓어질 수 있습니다. 기간에 따라 결과를 어떻게 읽는지는 6개월·12개월·18개월 아파트 전망 비교하기에서 다뤘습니다.

\n

화면은 두 개: 전망과 내 아파트

\n

선택을 마치면 두 화면을 오가며 정보를 확인합니다.

\n

전망 화면

\n

대표 시세: 선택한 평형의 최근 유효 거래를 바탕으로 한 기준값
목표 월 전망: 고른 시점의 예상 가격과 예상 범위
최근 실거래: 기준월을 포함한 최근 12개월 거래 목록과 흐름 차트

\n

차트에서 궁금한 거래를 짚으면 그 거래의 시점과 가격이 강조되어 표시됩니다. 거래 하나하나를 읽기 전에 최근 거래 한 건만 믿으면 위험한 이유를 한 번 읽어 두면 해석이 훨씬 쉬워집니다.

\n

내 아파트 화면

\n

교통·학군·생활 인프라 같은 입지 정보
금리·환율 같은 시장 지표와 기준일

\n

입지와 시장 지표는 가격 전망을 해석할 때의 배경 정보입니다. 지표마다 갱신 주기가 다르므로 값 옆의 기준일을 함께 보는 습관을 들이세요. 기준일을 읽는 방법은 예측 결과의 기준일·시장 정보·표본 신뢰도 읽는 법에 정리했습니다.

\n

선택은 내 기기에만 저장됩니다

\n

로그인 없이 이용할 때는 서버에 계정을 만들지 않습니다. 고른 단지·평형·목표 월은 휴대폰 안에만 저장되고, 같은 앱을 다시 열면 이어서 볼 수 있습니다.

\n

그래서 다음 경우에는 선택이 사라질 수 있습니다.

\n

앱을 삭제했다가 다시 설치한 경우
앱 데이터를 초기화한 경우
다른 기기로 바꾼 경우

\n

계속 같은 단지를 추적하고 싶다면 로그인해 두는 편이 안전합니다. 로그인하면 기기에 저장된 선택을 회원 계정으로 이어서 사용할 수 있습니다.

\n

웹 체험·앱 비회원·회원 기능 비교

\n

같은 서비스라도 이용 방식에 따라 볼 수 있는 범위가 다릅니다.

\n

구분	웹 가입 없는 체험	앱 로그인 없이	앱·웹 회원
이용 방법	브라우저에서 단지 검색	앱에서 단지·평형·목표 월 선택	로그인 후 관심 단지 등록
가격 전망	1년 뒤 예상 범위	고른 목표 월의 전망	여러 시점·조건별 시나리오 비교
실거래	대표 시세 중심	최근 12개월 거래와 흐름	매매·전세 흐름, 평형별 분석
저장	저장하지 않음	내 기기에만 저장	계정에 저장, 여러 기기에서 이용
추적·알림	없음	없음	예측 변경 이력과 알림

\n

처음에는 웹이나 앱에서 로그인 없이 써 보고, 관심 단지가 두 곳 이상으로 늘어나거나 조건을 바꿔 비교하고 싶을 때 가입을 검토하는 순서가 자연스럽습니다.

\n

결과를 읽을 때 지킬 것

\n

로그인 여부와 상관없이 가격 전망은 확정 가격이 아닙니다. 다음 세 가지는 꼭 함께 확인하세요.

\n

평형이 맞는지: 다른 면적의 결과를 내 집 가격으로 읽고 있지 않은지 확인합니다.
범위의 폭: 가운데 값 하나보다 아래·위 값과 폭을 함께 봅니다. 자세한 방법은 아파트 예상 범위 읽는 법을 참고하세요.
기준일: 언제 계산된 결과인지 기록해 두면, 나중에 숫자가 바뀌었을 때 이유를 추적하기 쉽습니다.

\n

자주 묻는 질문

\n

로그인 없이 쓰면 개인정보가 저장되나요?

\n

로그인 없이 이용할 때는 계정을 만들지 않고, 고른 단지·평형·목표 월만 기기에 저장합니다. 화면을 이용하는 과정에서 자동 입력 방지 확인이 나타날 수 있습니다.

\n

단지를 여러 개 저장할 수는 없나요?

\n

로그인 없는 이용 방식은 단지 하나에 집중하도록 설계되어 있습니다. 여러 단지를 저장하고 비교하려면 로그인 후 관심 단지로 등록해야 합니다.

\n

검색한 단지의 자료가 아직 준비 중이라고 나와요.

\n

모든 단지의 자료가 항상 준비되어 있지는 않습니다. 자료가 준비되지 않은 단지에 다른 단지의 숫자를 대신 보여주지 않기 때문에, 준비가 끝날 때까지 기다리거나 다른 단지를 먼저 둘러볼 수 있습니다.

\n

웹에서 본 결과와 앱 결과가 다르면 어느 쪽이 맞나요?

\n

먼저 평형과 목표 시점이 같은지 확인하세요. 웹 체험은 1년 뒤를, 앱은 내가 고른 목표 월을 기준으로 보여주므로 시점이 다르면 숫자도 달라집니다. 같은 조건이라면 기준일 차이도 함께 확인해 보세요.

\n

앱에서 바로 확인하기

\n

아파트 인사이트 앱은 App Store와 Google Play에서 받을 수 있습니다. 앱을 열고 로그인 없이 시작하면 단지·평형·목표 월을 고르는 화면으로 이어집니다.

\n

설치 없이 먼저 보고 싶다면 웹에서 가입 없이 아파트 가격 확인하기를, 최근 거래부터 보고 싶다면 지역별 아파트 실거래가를 이용해 보세요. 웹 체험의 이용 순서는 가입 없이 아파트 가격 예측하기에 자세히 정리했습니다.

\n

\n
아파트 인사이트의 가격 전망은 공개 데이터와 경제 시나리오를 바탕으로 한 참고용 분석입니다. 예측값과 가격 범위는 실제 결과와 다를 수 있으며 가격·거래 가능성·수익을 보장하지 않습니다. 투자 권유·투자 자문·매수·매도 추천이 아니며, 최종 판단과 책임은 이용자에게 있습니다.
\n

", "url": "https://alvin.ing/blog/apartment-app-guest-mode", "title": "로그인 없이 아파트 시세 앱 쓰는 법: 단지·평형·목표 월 하나로 전망 보기", "summary": "회원가입이나 로그인 없이 아파트 앱에서 관심 단지의 대표 시세와 목표 월 전망, 최근 실거래와 입지 정보를 확인하는 방법과 웹 체험·회원 기능과의 차이를 정리합니다.", "date_modified": "2026-10-02T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트" ] }, { "id": "https://alvin.ing/blog/apartment-price-forecast-accuracy-backtest", "content_html": "

아파트 가격을 예측해 준다는 서비스는 많지만, “그래서 얼마나 맞았나요?”에 답하는 곳은 많지 않습니다. 답하더라도 “정확도 95%”처럼 무엇을 어떻게 잰 것인지 알 수 없는 숫자 하나만 보여주는 경우가 대부분입니다.

\n

이 글은 아파트 가격 예측의 정확도를 스스로 판단할 수 있도록 백테스트가 무엇인지, 오차율 지표는 어떻게 읽는지, 좋아 보이는 숫자에 속지 않으려면 무엇을 확인해야 하는지 정리합니다.

\n

정확도를 묻기 전에 고정해야 할 두 가지

\n

예측이 맞았는지 따지려면 먼저 두 가지를 고정해야 합니다.

\n

무엇을 예측했는가: 어느 단지의 어느 평형을, 언제 기준으로, 몇 개월 뒤 가격을 예측했는지
실제값은 무엇인가: 그 시점 이후 실제로 신고된 거래 중 어떤 거래와 비교했는지

\n

이 두 가지가 빠진 정확도 숫자는 비교할 수 없습니다. “서울 아파트 평균 상승률을 맞혔다”와 “특정 단지 84㎡의 1년 뒤 거래가를 맞혔다”는 전혀 다른 난이도의 질문이기 때문입니다.

\n

백테스트: 과거로 돌아가 다시 예측해 보기

\n

백테스트는 과거의 특정 날짜로 돌아가, 그 시점에 알 수 있었던 정보만으로 미래를 예측한 뒤, 이후 실제 거래와 비교하는 방법입니다.

\n

기준일: 2024년 9월
 ├─ 이 날짜까지의 실거래·시장 지표만 사용해 1년 뒤 가격을 예측
 └─ 2025년 9월 전후의 실제 신고 거래와 비교 → 오차 계산

\n

여기서 가장 중요한 원칙은 기준일 이후의 정보를 섞지 않는 것입니다. 나중에 알게 된 금리나 거래를 과거 예측에 몰래 넣으면 결과는 훨씬 좋아 보이지만, 실제로 그 시점에 쓸 수 있었던 예측의 실력은 아닙니다. 이를 흔히 “미래 정보 누수”라고 부릅니다.

\n

백테스트 결과를 볼 때는 다음을 확인하세요.

\n

기준일 당시 실제로 이용할 수 있었던 자료만 썼다고 밝히는가
비교한 실제 거래의 표본 수가 얼마인가
어느 기간을 검증했는가 (상승기만 골랐는지, 하락기도 포함했는지)

\n

오차율 지표 세 가지 읽는 법

\n

예측 정확도는 보통 몇 가지 오차 지표로 표현합니다. 각 지표가 답하는 질문이 다릅니다.

\n

지표	쉬운 뜻	읽을 때 주의할 점
평균 오차율 (MAPE)	예측 가격과 실제 가격이 평균적으로 몇 % 차이 났나	일부 큰 오차가 평균을 끌어올릴 수 있습니다.
중간 오차율 (MedAE)	오차를 크기순으로 세웠을 때 가운데 값	큰 오차 몇 건에 덜 흔들리는 대표 오차입니다.
예상 범위 적중률	실제 거래 가격이 예상 범위 안에 들어온 비율	범위가 넓을수록 쉽게 높아집니다. 범위의 폭과 함께 봐야 합니다.

\n

평균 오차율 예시

\n

10억 원으로 예측한 단지가 실제로 10억 5,000만 원에 거래됐다면 오차율은 약 4.8%입니다. 이런 오차를 여러 단지에서 구해 평균을 낸 것이 평균 오차율입니다. 평균 오차율이 6%라면 “대체로 실제 가격과 6% 안팎의 차이가 났다”고 읽을 수 있습니다.

\n

범위 적중률은 높을수록 좋은가?

\n

꼭 그렇지는 않습니다. 이 부분이 가장 많이 오해받는 지점입니다.

\n

예상 범위를 가운데 50% 구간으로 만들었다면, 잘 만든 범위일수록 실제 가격이 그 안에 들어오는 비율도 50% 안팎이어야 합니다.
적중률이 90%라면 범위를 지나치게 넓게 잡았을 가능성이 있습니다. “5억~20억 사이”라고 말하면 거의 항상 맞지만 아무 도움이 되지 않는 것과 같습니다.
반대로 적중률이 20%라면 범위가 너무 좁거나 가운데 값이 한쪽으로 치우쳤을 수 있습니다.

\n

그래서 범위 적중률은 범위가 몇 % 구간인지, 범위의 폭은 얼마인지와 함께 읽어야 의미가 있습니다. 예상 범위 자체를 읽는 법은 아파트 예상 범위의 아래·가운데·위 값 해석하기에서 다뤘습니다.

\n

좋아 보이는 숫자에 속지 않는 체크리스트

\n

정확도 숫자를 보면 다음 질문을 하나씩 던져 보세요.

\n

잘 맞은 사례만 고른 것은 아닌가? 성공 사례 몇 개만 보여주는 것은 정확도가 아니라 홍보입니다. 무작위로 고른 단지, 또는 오차가 가운데인 사례를 공개하는지 확인하세요.
표본 수는 충분한가? 10건으로 낸 평균 오차율과 3,000건으로 낸 평균 오차율은 신뢰도가 다릅니다.
어떤 시기를 검증했는가? 모두가 오르던 시기에는 “오른다”만 말해도 잘 맞아 보입니다. 하락기와 급등기를 따로 확인했는지 보세요.
학습에 쓴 자료로 다시 채점한 것은 아닌가? 모델을 만들 때 쓴 데이터로 다시 평가하면 점수가 높게 나옵니다. 학습에 쓰지 않은 단지나 기간에서 따로 검증했는지 확인하세요.
지표의 단위가 명확한가? 가격 오차(%)인지, 변동률 오차(%p)인지, 금액 오차(원)인지에 따라 같은 숫자도 의미가 완전히 다릅니다.
한계를 함께 밝히는가? 어떤 검증도 미래를 보장하지 않습니다. 검증 방식의 한계를 스스로 적어 두는 곳이 오히려 믿을 만합니다.

\n

실제 공개 사례로 읽어 보기

\n

아파트 인사이트는 검증 방법과 수치를 공식 검증 가이드에 공개하고 있습니다. 글 작성 시점(2026년 10월) 기준으로 공개된 내용을 위 체크리스트에 맞춰 읽어 보면 다음과 같습니다.

\n

체크 항목	공개된 내용
지표와 값	12개월 가격 평균 오차율 5.98%, 결정계수(R²) 0.630, 변동률 오차 7.94%p
표본	결정계수·변동률 오차는 과거 평가 3,228건, 12개월 가격 오차율은 별도 120건
단위 구분	변동률 오차는 가격 변동률의 %p 오차이며 금액 오차가 아니라고 명시
사례 선정	무작위로 고른 5개 단지 중 가장 잘 맞은 사례가 아니라 오차가 가운데인 결과를 공개
시기	안정기뿐 아니라 급등기·금리 충격 하락기를 별도로 확인
한계	검증 결과가 미래 가격이나 수익을 보장하지 않으며 최대 오차 보장값이 아니라고 명시

\n

이 표를 “정확하다/부정확하다”로 판정하자는 것이 아닙니다. 어떤 서비스를 보든 이 정도 수준의 정보가 공개되어 있어야 숫자를 비교할 수 있다는 기준으로 활용하세요. 수치는 모델이 바뀌면 달라질 수 있으므로 최신 값은 공식 페이지에서 다시 확인하는 것이 좋습니다.

\n

내 관심 단지에 적용할 때

\n

전체 평균 오차율이 낮아도 내 관심 단지의 결과가 꼭 그만큼 정확한 것은 아닙니다. 개별 단지 결과를 볼 때는 다음을 추가로 확인하세요.

\n

거래 표본: 최근 거래가 드문 단지는 오차가 커질 수 있습니다. 결과 화면의 표본 신뢰도를 확인하세요.
평형: 거래가 많은 평형과 적은 평형은 결과의 안정성이 다릅니다.
특수한 거래: 분양권·손피 거래가 섞인 신축 단지는 가격 기준 자체가 흔들릴 수 있습니다. 일반 매매와 분양권 실거래가 차이를 참고하세요.
기준일: 언제 계산된 결과인지 기록해 두면 나중에 실제 거래와 직접 비교해 볼 수 있습니다. 기록 방법은 기준일·시장 정보·표본 신뢰도 읽는 법에 정리했습니다.

\n

자주 묻는 질문

\n

평균 오차율 6%면 정확한 편인가요?

\n

비교 기준에 따라 다릅니다. 1년 뒤 개별 단지 가격을 예측했는지, 지역 평균을 예측했는지에 따라 같은 6%의 의미가 달라집니다. 10억 원 아파트라면 6%는 6,000만 원이므로, 계약 판단에서는 결코 작은 차이가 아닙니다. 그래서 가운데 값 하나보다 예상 범위를 함께 봐야 합니다.

\n

백테스트 성적이 좋으면 앞으로도 잘 맞나요?

\n

보장되지 않습니다. 백테스트는 과거의 시장 환경에서 검증한 결과이며, 금리·정책·공급 환경이 크게 달라지면 성능도 달라질 수 있습니다.

\n

예측이 틀렸다는 건 어떻게 확인하나요?

\n

예측을 확인한 날짜와 결과(가운데 값, 범위)를 기록해 두고, 목표 시점 이후 같은 평형의 실제 거래와 비교해 보세요. 실제 거래가 범위 안에 들어왔는지, 가운데 값과 몇 % 차이 났는지를 직접 계산할 수 있습니다.

\n

직접 비교해 보기

\n

관심 단지의 대표 시세와 1년 뒤 예상 범위는 가입 없이 아파트 가격 확인하기에서, 비교 기준이 되는 최근 거래는 지역별 아파트 실거래가에서 확인할 수 있습니다. 결과를 처음 읽는다면 가입 없이 아파트 가격 예측하기부터 읽어 보세요.

\n

\n
이 글의 수치는 작성 시점에 공개된 자료를 인용한 것이며 이후 달라질 수 있습니다. 아파트 가격 예측은 공개 데이터와 경제 시나리오를 바탕으로 한 참고용 분석이며, 가격·거래 가능성·수익을 보장하지 않습니다. 투자 권유·투자 자문·매수·매도 추천이 아닙니다.
\n

", "url": "https://alvin.ing/blog/apartment-price-forecast-accuracy-backtest", "title": "아파트 가격 예측, 맞았는지 확인하는 법: 백테스트와 오차율 읽기", "summary": "아파트 가격 예측의 정확도를 판단할 때 백테스트, 평균 오차율(MAPE), 중간 오차율, 예상 범위 적중률을 어떻게 읽어야 하는지와 좋아 보이는 숫자에 속지 않는 체크리스트를 정리합니다.", "date_modified": "2026-10-02T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-real-transaction-price-by-region", "content_html": "

“우리 동네 아파트가 요즘 얼마에 거래되나요?”라는 질문에는 생각보다 많은 조건이 숨어 있습니다. 같은 구 안에서도 단지마다 가격대가 다르고, 같은 단지 안에서도 59㎡와 84㎡는 전혀 다른 시장입니다. 그래서 실거래가는 지역 → 단지 → 평형 순서로 좁혀서 봐야 숫자가 흔들리지 않습니다.

\n

이 글은 지역별 아파트 실거래가를 조회할 때 어떤 순서로 범위를 좁히고, 단지 화면에서 어떤 숫자를 먼저 읽어야 하는지 정리합니다. 마지막에는 국토교통부 공개자료와 대조하는 방법도 함께 다룹니다.

\n

실거래가 조회 전에 알아 둘 세 가지

\n

실거래가는 “지금 이 집의 가격”이 아니라 이미 계약된 거래의 기록입니다. 조회 화면을 열기 전에 다음 세 가지를 알고 있으면 숫자를 오해할 가능성이 크게 줄어듭니다.

\n

알아 둘 점	이유
신고까지 시간 차이가 있다	아파트 매매 거래는 계약일로부터 30일 이내에 신고하므로, 최근 한 달 거래는 아직 덜 쌓였을 수 있습니다.
거래 한 건은 조건이 제각각이다	층·향·타입·수리 상태·직거래 여부에 따라 같은 평형도 가격 차이가 납니다.
해제·정정되는 거래가 있다	신고 후 계약이 해제되면 기록에 해제 표시가 붙습니다. 해제 거래를 시세로 읽으면 안 됩니다.

\n

그래서 실거래가를 볼 때는 “가장 최근 한 건”보다 같은 평형에서 최근 1년 동안 어떤 범위로 거래됐는지를 먼저 보는 편이 안전합니다. 한 건의 거래가 왜 시세를 대표하지 못하는지는 최근 거래 한 건만으로 아파트 시세를 판단하면 안 되는 이유에서 자세히 설명했습니다.

\n

1단계: 시군구를 먼저 고릅니다

\n

단지명을 바로 검색하면 같은 이름의 단지가 여러 지역에서 함께 나옵니다. “래미안”, “자이”, “센트럴”처럼 흔한 브랜드명은 물론이고, 같은 구 안에도 이름이 비슷한 단지가 여러 개 있을 수 있습니다.

\n

시군구를 먼저 고르면 다음 장점이 있습니다.

\n

같은 이름의 다른 지역 단지를 실수로 고를 가능성이 줄어듭니다.
해당 지역에 실거래가 꾸준한 단지가 어떤 곳인지 한눈에 볼 수 있습니다.
관심 단지와 같은 생활권의 비교 단지를 함께 찾을 수 있습니다.

\n

같은 시군구에 이름이 같은 단지가 두 곳 이상 있다면 준공 연도와 지번을 함께 확인하세요. 예를 들어 “1989년 준공 · ○○동 720”처럼 지번까지 맞춰 보면 다른 단지와 섞일 일이 없습니다.

\n

2단계: 단지 화면에서 대표 시세와 거래 범위를 읽습니다

\n

단지를 고르면 보통 다음 숫자가 함께 보입니다. 각 숫자가 답하는 질문이 다르므로 하나로 섞지 않는 것이 중요합니다.

\n

화면의 숫자	답하는 질문	읽는 방법
대표 시세	이 단지의 대표 평형은 지금 어느 수준인가?	최근 유효 거래를 바탕으로 한 기준값입니다. 개별 호가나 한 건의 거래와 다릅니다.
최근 1년 거래 범위	지난 1년 동안 얼마에서 얼마 사이로 거래됐나?	아래·위 끝값보다 범위의 폭을 봅니다. 폭이 넓으면 층·타입 차이나 시장 변화가 컸다는 뜻입니다.
최근 거래 목록	어떤 조건의 거래가 언제 있었나?	계약일·면적·층을 함께 확인하고, 해제 표시가 있는 거래는 제외해서 읽습니다.
최근 1년 거래 건수	비교할 표본이 충분한가?	거래가 드문 단지는 새 거래 한 건에도 대표 시세가 크게 움직일 수 있습니다.

\n

대표 시세와 최근 거래가 다르다고 해서 어느 한쪽이 틀린 것은 아닙니다. 대표 시세는 여러 거래를 비교하기 위한 기준값이고, 최근 거래는 특정 조건의 한 기록입니다. 두 숫자의 차이가 크면 그 거래가 저층·특수 타입·직거래였는지부터 확인해 보세요.

\n

3단계: 평형을 맞춰서 비교합니다

\n

같은 단지라도 평형이 다르면 비교 대상이 달라집니다. 단지 화면에서 평형 배지를 바꿔 가며 확인할 때는 다음 순서를 지켜 보세요.

\n

내가 찾는 전용면적과 화면에서 선택된 평형이 같은지 확인합니다.
그 평형에서 최근 1년 거래 건수가 충분한지 봅니다.
대표 시세와 최근 1년 거래 범위를 같은 평형끼리 비교합니다.
다른 단지와 비교할 때도 비슷한 전용면적을 기준으로 맞춥니다.

\n

59㎡ 거래가 많은 단지에서 84㎡ 가격을 판단하려고 59㎡ 거래를 끌어오면 숫자는 쉽게 왜곡됩니다. 평형별 거래가 부족하다면 무리하게 다른 평형으로 채우기보다 “표본이 부족하다”는 사실 자체를 기록해 두는 편이 낫습니다.

\n

같은 지역의 다른 단지와 비교하는 법

\n

관심 단지 하나만 보면 가격이 비싼지 싼지 판단하기 어렵습니다. 같은 시군구 안에서 다음 조건이 비슷한 단지 2~3곳을 함께 보면 감이 잡힙니다.

\n

준공 연도(연식)가 비슷한가
전용면적이 같은가
역·학교 같은 생활 인프라와의 거리가 비슷한가
최근 1년 거래 건수가 비슷한 수준인가

\n

이때도 대표 시세 한 숫자만 나란히 놓기보다 최근 1년 거래 범위의 위치를 함께 비교해 보세요. 한 단지의 대표 시세가 범위의 위쪽에 붙어 있고 다른 단지는 아래쪽에 있다면, 최근 흐름이 서로 다를 수 있습니다.

\n

국토교통부 공개자료와 대조하는 방법

\n

어떤 서비스로 실거래가를 보든 원자료는 국토교통부 실거래가 공개시스템입니다. 중요한 의사결정 전에는 원자료와 한 번 대조해 보는 습관이 좋습니다.

\n

공개시스템에서 같은 시군구와 단지를 선택합니다.
전용면적이 같은 거래만 남깁니다.
계약일, 층, 거래 유형(중개·직거래), 해제 여부를 확인합니다.
정리된 화면의 최근 거래 목록과 날짜·금액이 맞는지 봅니다.

\n

숫자가 조금 다르다면 대부분 신고 시점, 해제·정정 반영 시점, 면적 구분 기준의 차이입니다. 이 차이를 오류로 단정하기 전에 기준일을 먼저 맞춰 보세요.

\n

실거래가 다음에 확인할 것

\n

실거래가는 “지금까지”의 기록입니다. 매수·매도 시점을 고민하고 있다면 그다음 질문으로 넘어가야 합니다.

\n

앞으로의 가격 범위: 실거래 기준값에서 1년 뒤 어떤 범위가 가능한지는 아파트 예상 범위의 아래·가운데·위 값 읽는 법을 참고하세요.
거래에 드는 실제 비용: 취득세·중개보수·양도세까지 넣은 총자금은 아파트 거래비용 계산기로 계산할 수 있습니다.
분양권 거래가 섞였는지: 신축 단지는 일반 매매와 분양권 실거래가를 같은 시세로 합치면 안 되는 이유를 먼저 확인하세요.

\n

자주 묻는 질문

\n

왜 우리 단지는 목록에 없나요?

\n

거래가 적거나 마지막 거래가 오래된 단지는 대표 시세를 안정적으로 계산하기 어렵습니다. 이런 단지는 숫자가 한두 건의 거래에 크게 흔들리기 때문에 목록에서 제외되는 경우가 많습니다. 이때는 국토교통부 공개시스템에서 개별 거래를 직접 확인하고, 주변의 비슷한 단지를 함께 참고하세요.

\n

대표 시세는 호가와 같은 건가요?

\n

아닙니다. 호가는 매도자가 원하는 가격이고, 대표 시세는 실제 신고된 거래를 바탕으로 한 기준값입니다. 시장이 빠르게 움직이는 시기에는 호가와 대표 시세의 차이가 커질 수 있습니다.

\n

최근 거래가 대표 시세보다 훨씬 높으면 시세가 오른 건가요?

\n

한 건만으로는 판단하기 어렵습니다. 그 거래의 층·타입·수리 상태를 확인하고, 이후 비슷한 가격의 거래가 이어지는지 지켜보는 것이 좋습니다. 같은 수준의 거래가 여러 건 쌓이면 대표 시세도 따라 움직입니다.

\n

실거래가 화면에서 1년 뒤 가격도 볼 수 있나요?

\n

실거래가 화면은 지금까지의 거래 기록을 보여주는 데 집중합니다. 1년 뒤 예상 범위는 별도의 예측 화면에서 확인하는 것이 일반적이며, 그 결과는 확정 가격이 아니라 참고용 범위입니다. 읽는 방법은 가입 없이 아파트 가격 예측하기에 정리했습니다.

\n

지역별 실거래가 바로 확인하기

\n

시군구별·단지별 최근 거래와 대표 시세는 아파트 인사이트의 지역별 아파트 실거래가에서 바로 확인할 수 있습니다. 국토교통부 실거래가 공개자료를 바탕으로 대표 평형 기준 시세, 최근 1년 거래 범위, 최근 거래, 같은 지역 단지를 한 화면에 모아 보여줍니다.

\n

예를 들어 서울 강남구, 송파구, 노원구, 성남 분당구처럼 시군구를 먼저 고른 뒤 단지를 선택하면 됩니다.

\n

처음부터 통계를 읽는 전체 순서가 궁금하다면 부동산과 아파트 통계를 처음 읽는 순서를 함께 읽어 보세요.

\n

\n
실거래가와 대표 시세는 공개 자료를 바탕으로 정리한 참고 정보입니다. 신고·해제·정정 시점에 따라 실제와 차이가 날 수 있으며, 특정 거래 가격이나 수익을 보장하지 않습니다. 계약 전에는 공식 자료와 현장 조건을 반드시 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/apartment-real-transaction-price-by-region", "title": "지역별 아파트 실거래가 조회하는 법: 시군구에서 단지·평형까지 3단계", "summary": "아파트 실거래가를 시군구, 단지, 평형 순서로 좁혀 조회하는 방법과 최근 거래·대표 시세·최근 1년 거래 범위를 읽는 기준, 국토교통부 공개자료와 대조하는 방법을 정리합니다.", "date_modified": "2026-10-02T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/jeonse-ratio-and-gap-investment-risk", "content_html": "\n

부동산 시장에서 “전세가율이 80%를 넘었으니 소액으로 갭투자하기 좋다”거나 “전세가가 매매가를 밀어 올릴 타이밍”이라는 이야기를 자주 접합니다. 매매가와 전세가의 차이(Gap)가 줄어들면 매수에 들어가는 초기 자본이 줄어드는 것은 사실입니다.

\n

하지만 전세가율이라는 하나의 숫자만 보고 매수를 결정하면 시장의 가장 위험한 함정에 빠지기 쉽습니다. 전세가율이 높아진 원인이 무엇인지, 그리고 그 비율이 자산의 안전성을 보장하는지를 반드시 분리해서 살펴봐야 합니다.

\n

전세가율이 높아지는 두 가지 상반된 경로

\n

전세가율은 전세가격 ÷ 매매가격의 공식으로 계산됩니다. 분수가 커지는 방법은 두 가지입니다.

\n

분자(전세가)가 오르는 경우: 실거주 수요가 풍부하고 입주 물량이 부족해 전세보증금이 상승하는 건강한 흐름
분모(매매가)가 떨어지는 경우: 미래 가치에 대한 기대가 꺾여 매매가격이 하락하면서 상대적으로 전세가율이 치솟는 흐름

\n

겉으로 보이는 전세가율 수치는 똑같이 80%라도, 1번과 2번이 의미하는 시장 상황은 완전히 정반대입니다. 매매가격이 지속적으로 하락해 전세가율이 높아진 지역에 갭투자로 진입하면, 매매가 추가 하락 시 곧바로 보증금 미반환(깡통전세) 리스크에 노출됩니다.

\n

갭투자자가 놓치기 쉬운 5가지 위험

\n

1. 전세가는 하방 지지선이 아니라 변동성 지표다

\n

많은 사람들이 “전세가가 매매가의 하한선을 받쳐준다”고 믿지만, 전세가 역시 만기 시점의 입주 물량과 금리에 따라 급격히 흔들립니다. 인근에 대단지 신축 아파트가 입주하거나 전세대출 금리가 급등하면 전세가는 수개월 만에 수천만원에서 수억원씩 급락할 수 있습니다.

\n

2. 역전세 발생 시 유동성 버퍼가 있는가

\n

전세가율이 높은 상태에서 재계약 시점에 전세 시세가 하락(역전세)하면, 임대인은 그 차액을 현금으로 세입자에게 내어주어야 합니다. 초기 투자금이 적게 들었다는 이유로 현금 여력 없이 갭투자를 진행했다면 심각한 자금 경색에 직면하게 됩니다.

\n

3. 취득세와 보유세, 중개보수 등 거래비용의 누락

\n

매매가와 전세가의 단순 차액(Gap)만 계산하고, 취득세·지방교육세, 부동산 중개보수, 주택 채권 매입비, 그리고 보유 기간 중 발생하는 재산세와 종합부동산세를 계산에 넣지 않으면 실제 수익률은 마이너스로 돌아설 수 있습니다. 아파트 거래비용 계산기를 통해 실제 부대비용을 먼저 점검해야 합니다.

\n

4. 매매 수요가 없는 ‘임대차 전용 단지’의 함정

\n

지방 비역세권이나 노후 구축 단지 중에는 전세 수요는 꾸준하지만 매수하려는 사람이 거의 없는 단지들이 있습니다. 이런 곳은 전세가율이 85~90%에 육박하더라도 몇 년이 지나도 매매가격이 오르지 않아 자본 이득을 기대하기 어렵고, 매도하고 싶을 때 매수자를 찾지 못해 환금성이 크게 떨어집니다.

\n

5. 보증보험 가입 요건 강화와 깡통전세 규제

\n

최근 HUG(주택도시보증공사)의 전세보증금 반환보증 가입 기준이 공시가격의 126% 이내(공시가격 반영률 140% × 전세가율 90%) 등으로 엄격해졌습니다. 전세가율이 너무 높은 아파트는 다음 세입자가 전세보증보험에 가입할 수 없어, 새로운 임차인을 구하기가 극도로 어려워질 수 있습니다.

\n

전세가율을 제대로 읽는 4단계 점검 순서

\n

원인 구분하기: 매매가가 내려서 전세가율이 오른 것인지, 전세 실거래가가 상승해서 오른 것인지 확인합니다.
입주 물량 확인하기: 향후 2~3년간 해당 시·군·구 및 인접 지역의 아파트 입주 예정 물량을 점검합니다.
매매 거래량 동반 여부: 전세 거래만 활발하고 매매 거래가 완전히 끊겨 있다면 매수 전환 수요가 없다는 신호입니다.
역전세 시나리오 대비: 전세 시세가 10~20% 하락하더라도 보증금을 반환해줄 수 있는 현금 흐름이 확보되어 있는지 검토합니다.

\n

자주 묻는 질문 (FAQ)

\n

Q. 전세가율이란 무엇인가요?

\n

전세가율이란 아파트 매매가격 대비 전세보증금의 비율(전세가 / 매매가 × 100)을 의미하며, 통상 매매 수요와 임대차 수요의 상대적 강도를 가늠하는 지표로 활용됩니다.

\n

Q. 전세가율이 80% 이상으로 높으면 무조건 좋은 투자처인가요?

\n

아닙니다. 전세가율이 지나치게 높은 단지는 매매 수요가 정체되어 미래 자산 가치 상승 여력이 낮거나, 향후 매매가 소폭 하락 시 보증금을 반환하지 못하는 깡통전세·역전세 위험이 매우 큽니다.

\n

Q. 전세가율 상승이 매매가 상승으로 이어지려면 어떤 조건이 필요한가요?

\n

전세가 상승이 단순 공급 부족에 그치지 않고, 임차인의 소득 및 매수 전환 여력이 뒷받침되어야 하며 대출 금리와 공급 물량, 지역 일자리 여건이 함께 개선되어야 매매가 밀어올리기 효과가 나타납니다.

\n

함께 읽을 글

\n

\n

\n
이 글은 부동산 통계와 시장 지표를 해석하기 위한 정보 제공 목적의 아카이브입니다. 특정 지역이나 단지의 매수를 권유하지 않으며 투자 결과에 대한 책임을 지지 않습니다. 실제 거래 전에는 현장 임장과 전문가 상담을 권장합니다.
\n

", "url": "https://alvin.ing/blog/jeonse-ratio-and-gap-investment-risk", "title": "전세가율이 높으면 매수하기 좋을까? 갭투자 판단 시 놓치기 쉬운 5가지 함정", "summary": "전세가율이 높을 때 무턱대고 매수하거나 갭투자하면 위험한 이유와 매매가 대비 전세가 비율의 착시, 깡통전세 및 역전세 리스크를 객관적으로 분석하는 기준을 정리합니다.", "date_modified": "2026-09-13T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "금융·세금", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/presale-right-vs-general-trade-difference", "content_html": "\n

아파트 실거래가 조회 앱이나 포털을 보다 보면, 신축 입주 예정 단지의 실거래가가 인근 구축 아파트와 비슷하거나 오히려 낮게 찍혀 있는 것을 보고 “신축인데 생각보다 싸다”고 생각하는 경우가 많습니다.

\n

하지만 국토교통부 실거래가 공개시스템에 올라오는 기존 아파트 매매 자료와 분양권 전매 자료는 성격이 전혀 다른 데이터입니다. 표기된 숫자만 그대로 일대일 비교하면 실제 매수자가 지출해야 하는 총비용과 시세를 완전히 오판하게 됩니다.

\n

왜 두 데이터는 같은 선상에 놓일 수 없을까?

\n

기존 아파트 매매는 이미 건축이 완료되어 등기된 실물 부동산을 거래하는 것이며, 매매가격에 건축비·토지비·내부 인테리어 가치가 모두 녹아 있습니다. 반면 분양권은 **‘미래에 지어질 아파트에 입주할 수 있는 권리’**를 거래하는 계약입니다.

\n

따라서 계약서에 적히는 금액의 구성 항목 자체가 완전히 다릅니다.

\n

비교 항목	기존 아파트 일반 매매	분양권 전매
거래 대상	등기 완료된 실물 주택	완공 전 입주 권리
신고 금액 기준	실물 매매 총대금	기본 분양가 + 프리미엄(P)
추가 부담 항목	중개보수, 취득세	옵션비, 확장비, 후불 이자, 등기 취득세
취득세 납부 시점	잔금 납부 시 (즉시)	완공 후 소유권 이전등기 시
입주 가능 시기	계약 후 잔금 시점	준공 예정일 (통상 2~3년 뒤)

\n

분양권 실거래가에 숨겨진 3가지 비용

\n

국토교통부 실거래가 시스템에 분양권이 8억원으로 신고되었다고 해서 매수자가 8억원만 준비하면 되는 것이 아닙니다. 겉으로 드러나지 않는 세 가지 필수 비용이 숨어 있습니다.

\n

1. 발코니 확장비 및 유상 옵션비

\n

최근 신축 아파트는 발코니 확장을 필수로 전제하고 설계됩니다. 발코니 확장비만 1,500만~~3,000만원에 달하며, 시스템 에어컨, 중문, 엔지니어드 스톤 등 필수 유상옵션을 합치면 3,000만~~6,000만원의 추가 비용이 발생합니다. 이 비용은 분양권 실거래가 신고 시 별도 표기되거나 누락되는 경우가 많습니다.

\n

2. 중도금 대출 이자 후불제

\n

대다수 분양 단지는 공사 기간 동안 발생하는 중도금 대출 이자를 수분양자가 바로 내지 않고 입주 시점에 일괄 정산하는 ‘이자 후불제’를 적용합니다. 고금리 기조에서는 입주 시 정산해야 할 누적 이자만 2,000만~4,000만원에 이릅니다. 매수자가 이 이자를 승계받는 조건이라면 실질 매수가격은 그만큼 올라갑니다.

\n

3. 세금 대납 조건(손피) 여부

\n

분양권 시장에서는 매도자의 양도소득세를 매수자가 대신 부담하는 손피(손에 남는 프리미엄) 거래가 빈번합니다. 분양권 단기 양도세율은 60~~70%에 달하기 때문에, 겉으로 신고된 프리미엄이 3,000만원이라도 매수자가 대신 내주는 세금까지 합치면 실제 부담액은 5,000만~~8,000만원으로 불어납니다.

\n

실전 비교 체크리스트: 실질 매수가격 계산법

\n

인근 단지와 시세를 올바르게 비교하려면 다음 계산식을 사용해 실질 총 인수비용을 먼저 구해야 합니다.

\n

실질 총 인수비용
= 분양가 + 프리미엄(P) + 발코니 확장비 + 유상 옵션비 + 중도금 후불이자 + 손피 대납세액

\n

이 합계 금액에 향후 완공 시 납부할 취득세(통상 옵션비와 이자를 합산한 총 취득가액 기준 1~3%)를 감안해야만 비로소 기존 아파트 매매가와 공정한 비교가 가능해집니다.

\n

자주 묻는 질문 (FAQ)

\n

Q. 국토부 실거래가에 표시된 분양권 가격에는 옵션비와 중도금 이자가 포함되어 있나요?

\n

대부분 포함되어 있지 않습니다. 국토부 분양권 실거래가는 통상 공급계약서상 분양가와 프리미엄의 합계액으로 신고되며, 수천만원에 달하는 발코니 확장비, 유상옵션비, 중도금 이자 후불제 비용은 별도로 발생합니다.

\n

Q. 기존 등기 아파트와 분양권의 취득세 납부 시점은 어떻게 다른가요?

\n

기존 아파트는 잔금 지급일 또는 등기일 중 빠른 날에 취득세를 납부하지만, 분양권은 분양권 자체를 매수할 때는 취득세를 내지 않고 추후 아파트가 완공되어 소유권 이전등기를 할 때 실제 총 취득가액을 기준으로 취득세를 납부합니다.

\n

Q. 인근 구축 아파트와 신축 분양권 가격을 비교할 때 가장 중요한 것은 무엇인가요?

\n

분양권 표기 가격에 옵션비, 후불 이자, 등기 시 취득세를 더한 실질 총 매수비용을 산출한 뒤, 완공 시점까지의 금융 기회비용과 연식 차이를 감안해 비교해야 합니다.

\n

함께 읽을 글

\n

\n

\n
이 글은 부동산 거래 유형별 데이터 해석 기준을 설명하기 위한 정보 아카이브입니다. 특정 분양권이나 단지의 투자를 권유하지 않으며, 실제 거래 및 계약 전에는 공급계약서와 분양권 매매계약서 특약 사항을 전문가와 면밀히 확인하시기 바랍니다.
\n

", "url": "https://alvin.ing/blog/presale-right-vs-general-trade-difference", "title": "일반 매매와 분양권 실거래가를 같은 시세로 합쳐서 보면 안 되는 이유", "summary": "국토교통부 실거래가 조회 시 기존 등기 아파트 매매와 분양권 거래를 단순 비교하면 안 되는 이유와 옵션비, 중도금 이자 후불제, 프리미엄의 차이를 정리합니다.", "date_modified": "2026-09-13T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터", "금융·세금" ] }, { "id": "https://alvin.ing/blog/apartment-analysis-share-url", "content_html": "

아파트 분석 결과를 가족이나 함께 집을 보는 사람에게 전달할 때 숫자만 캡처하면, 며칠 뒤에는 어느 단지·평형·기준일의 결과였는지 잃기 쉽습니다. 아파트 인사이트의 공유 URL은 선택한 단지의 가격 흐름과 예상 결과를 한 화면에서 다시 볼 수 있게 전달하는 방법입니다.

\n

공유는 편리하지만, 링크를 받는 사람이 가운데 예상가만 보고 확정 가격이나 매수 추천으로 오해하지 않도록 맥락을 함께 확인해야 합니다. 이 글은 아파트 분석 공유 URL을 만들고 보내기 전에 점검할 다섯 가지를 정리합니다.

\n

1. 링크가 가리키는 단지와 평형을 확인합니다

\n

공유 전 첫 번째 확인 항목은 단지명과 평형입니다. 같은 단지라도 전용면적과 거래 조건이 다르면 최근 거래와 가격 흐름이 달라질 수 있습니다. 링크를 보내는 메시지에는 최소한 아래 정보를 적어 두세요.

\n

단지: 가상 단지
지역: 가상 시·군·구
평형: 전용 84㎡
조회일: 2026-09-07

\n

이 네 줄이 있으면 링크를 받은 사람이 비슷한 이름의 다른 단지나 다른 평형의 결과로 받아들이는 일을 줄일 수 있습니다. 면적·층·거래 유형에 따라 최근 거래가 달라지는 이유는 최근 거래 한 건만으로 아파트 시세를 판단하면 안 되는 이유를 참고하세요.

\n

2. 최근 거래와 예상 결과를 같은 숫자로 섞지 않습니다

\n

공유 화면에는 과거 실거래 흐름과 앞으로의 예상 결과가 함께 보일 수 있습니다. 둘은 같은 역할을 하지 않습니다.

\n

항목	답하는 질문	전달할 때의 표현
최근 거래	어떤 조건에서 실제 거래가 확인됐는가	최근 확인된 거래 흐름
대표 시세	여러 거래를 비교하기 위한 현재 기준값	현재 비교 기준
예상가	목표 시점에서 비교할 중심 결과	조건을 둔 참고 결과
예상 범위	조건 변화에 따라 가능한 가격의 폭	확정 가격이 아닌 범위

\n

메시지에 “내년 가격은 이거야”라고 적기보다 “전용 84㎡ 기준으로 최근 거래와 12개월 예상 범위를 함께 본 결과”처럼 적는 편이 정확합니다. 예상 범위의 아래·가운데·위 값을 읽는 방법은 아파트 가격 예측 결과의 아래·가운데·위 값 읽는 법에서 확인할 수 있습니다.

\n

3. 기준일과 조회일을 함께 보냅니다

\n

공유 URL은 생성한 순간의 결과를 전달하는 용도이므로, 링크를 보낸 날짜와 화면 속 자료 기준일을 구분해야 합니다. 특히 실거래는 계약일·신고일·공개일 사이에 시간차가 있을 수 있습니다.

\n

공유 메시지에 다음 두 날짜를 같이 적어 보세요.

\n

조회일: 내가 링크를 만들고 확인한 날짜
자료 기준일: 최근 거래와 시장 정보가 어떤 시점까지 반영됐는지 읽는 기준

\n

며칠 또는 몇 주 뒤에 같은 단지의 결과가 달라졌다면 이전 링크가 틀린 값이 되었다는 뜻은 아닙니다. 새 거래, 평형 변경, 목표 시점 변경, 시장 정보 갱신처럼 비교 조건이 달라졌을 수 있습니다. 기준일과 표본 상태를 확인하는 순서는 아파트 가격 예측 결과에서 기준일·시장 정보·표본 신뢰도 읽는 법에 정리했습니다.

\n

4. 공개 기간과 중지 상태를 확인합니다

\n

공유 주소를 아는 사람은 로그인하지 않고도 결과를 확인할 수 있습니다. 따라서 링크를 만들기 전에 화면에 표시되는 공개 기간을 확인하고, 더 이상 보여 줄 필요가 없으면 공유 설정에서 중지하세요.

\n

공유하려는 내용도 다시 한 번 살펴봅니다. 공유 화면은 단지와 가격 흐름을 함께 논의하기 위한 것이지, 개인의 대출·현금·거주 계획을 모두 공개하는 공간이 아닙니다. 전달 메시지에 개인 상황을 덧붙여야 한다면 링크와 분리해 필요한 범위만 직접 설명하는 편이 좋습니다.

\n

공유 설정에서는 공개 중인 링크의 상태를 확인하고, 더 이상 필요하지 않은 주소를 중지할 수 있습니다. 기간과 생성 한도는 계정 상태와 기존 링크에 따라 다를 수 있으므로, 공유하기 직전 화면에 표시된 안내를 기준으로 확인하세요.

\n

5. 계약 판단 대신 다음 질문을 남깁니다

\n

좋은 공유는 결론을 대신 내리는 링크가 아니라, 함께 확인할 질문을 남깁니다. 아래처럼 전달하면 대화를 시작하기 좋습니다.

\n

\n
전용 84㎡ 기준 결과입니다. 최근 거래와 12개월 예상 범위를 같이 봤고, 계약 전에는 같은 조건의 최신 실거래와 대출·거래비용을 추가로 확인해 보려고 합니다.
\n

\n

링크를 받은 뒤에는 국토교통부 실거래가 공개시스템에서 계약일, 전용면적, 층, 해제·정정 여부를 다시 확인하세요. 가격 전망의 범위는 계약 가능 가격이나 수익을 보장하지 않으며, 개인의 대출 한도·세금·이사 일정까지 대신 판단하지 않습니다.

\n

아파트 분석을 처음 시작한다면 지역·단지·이사 시점을 입력하는 순서부터 읽고, 가입 없이 현재 기준과 예상 범위를 확인하려면 가입 없이 아파트 가격 예측하기를 이어서 보세요.

\n

\n
아파트 인사이트의 공유 결과는 공개 데이터와 시장 조건을 바탕으로 한 참고용 분석입니다. 투자 권유나 매수·매도 추천이 아니며, 미래 가격·거래 가능성·수익을 보장하지 않습니다. 주소를 받은 사람이 누구인지와 공유 화면의 공개 상태를 확인하고, 최종 계약 전에는 최신 공식 자료와 개인 조건을 별도로 검토하세요.
\n

", "url": "https://alvin.ing/blog/apartment-analysis-share-url", "title": "아파트 분석 공유 URL을 보내기 전 확인할 5가지", "summary": "아파트 실거래 흐름과 가격 전망을 공유 URL로 보낼 때 평형·기준일·예상 범위·공개 기간을 확인하고 오해 없이 설명하는 방법을 정리합니다.", "date_modified": "2026-09-07T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-insights-start-guide", "content_html": "

아파트 가격을 비교하려고 할 때 가장 먼저 필요한 것은 더 많은 숫자가 아니라 같은 질문을 계속 비교할 수 있는 기준입니다. 관심 지역이 바뀌고, 단지·평형·이사 시점이 섞이면 실거래가와 예상 범위를 여러 번 봐도 무엇이 달라졌는지 알기 어렵습니다.

\n

이 글은 아파트 인사이트에서 분석을 시작할 때 지역·단지·평형·이사 시점을 어떤 순서로 정하면 좋은지 안내합니다. 특정 단지의 매수·매도를 권하는 글이 아니라, 공개 실거래와 분석 결과를 같은 조건에서 읽기 위한 준비 과정입니다.

\n

시작 전에 적어 둘 네 가지

\n

입력 화면을 열기 전에 아래 네 가지를 짧게 메모해 두면 검색 결과를 비교하기 쉬워집니다.

\n

항목	먼저 정할 내용	필요한 이유
지역	시·도와 시·군·구	같은 이름의 단지나 비슷한 이름을 구분합니다.
단지	공식 단지명과 주소	검색 결과가 관심 단지와 같은지 대조합니다.
평형	전용면적 또는 비교할 평형	면적이 다른 거래를 한 가격처럼 읽지 않습니다.
이사 시점	계약·잔금 또는 이사 목표 월	현재 거래와 미래 예상의 비교 기간을 고정합니다.

\n

네 값은 한 번 정하면 바꾸면 안 되는 규칙이 아닙니다. 비교 대상을 바꿨을 때 무엇을 바꿨는지 남기기 위한 기준입니다. 예를 들어 84㎡를 보다가 59㎡로 전환했다면, 가격 차이를 시장 변화로 해석하기 전에 평형이 달라졌다는 사실부터 확인해야 합니다.

\n

1. 지역부터 고르는 이유

\n

단지명에 인기 브랜드나 공통 단어가 들어가면 비슷한 결과가 여러 지역에서 나올 수 있습니다. 단지명을 먼저 검색해도 되지만, 지역을 선행하면 검색 결과의 주소와 단지명을 함께 대조할 수 있습니다.

\n

확인할 내용은 세 가지입니다.

\n

내가 찾는 시·군·구가 맞는지
단지 주소와 생활권이 내가 생각한 곳과 맞는지
같은 이름의 다른 단지를 선택하지 않았는지

\n

지역을 넓게 잡아 비교할 때도 기준을 따로 둡니다. 예를 들어 “서울 전체”와 “특정 구”의 거래량·매수심리·공급 정보를 같은 성격의 숫자로 보지 않고, 어느 범위의 정보인지 함께 기록합니다.

\n

2. 단지와 평형을 한 묶음으로 확인하기

\n

단지 이름만 같아도 전용면적, 동·층, 타입, 거래 시점에 따라 가격은 달라질 수 있습니다. 그래서 분석 결과나 실거래가를 볼 때는 단지명 옆의 평형을 바로 확인하는 습관이 필요합니다.

\n

다음 순서로 보면 됩니다.

\n

검색 결과의 단지명과 주소를 확인합니다.
화면에서 선택된 전용면적 또는 평형을 확인합니다.
최근 거래가 같은 면적에서 나온 값인지 살펴봅니다.
다른 평형을 비교할 때는 가격을 바로 연결하지 않고 면적 조건이 달라졌다고 표시합니다.

\n

최근 거래가 한 건뿐이거나 조건이 섞여 있으면 대표 시세처럼 단정하지 않는 것이 좋습니다. 거래 건수와 층·거래 유형을 확인하는 방법은 최근 거래 한 건만으로 아파트 시세를 판단하면 안 되는 이유에서 더 자세히 다룹니다.

\n

3. 이사 시점은 가격 숫자와 분리해서 기록하기

\n

이사 시점은 “언제 계약할지”, “언제 잔금을 치를지”, “언제 실제로 입주할지” 중 무엇을 뜻하는지에 따라 다르게 적을 수 있습니다. 분석을 시작할 때는 우선 내가 비교하려는 목표 월을 하나 정하고, 그 월이 계약·잔금·입주 중 어디에 가까운지 메모하는 편이 좋습니다.

\n

이 기준이 있으면 6개월·12개월·18개월 결과도 같은 질문으로 비교할 수 있습니다. 기간이 다르면 예상 범위의 폭과 조건도 달라질 수 있으므로, 결과의 가운데 값만 나란히 놓고 방향을 단정하면 안 됩니다.

\n

6개월·12개월·18개월 아파트 전망을 비교할 때 확인할 것에서 기간별로 어떤 질문을 해야 하는지 이어서 확인할 수 있습니다.

\n

4. 결과 화면에서는 기준일을 먼저 보기

\n

단지와 평형, 목표 시점을 정했다면 숫자를 읽기 전에 기준일을 봅니다. 화면을 오늘 열었다고 해서 모든 실거래와 시장 정보가 오늘 기준이라는 뜻은 아닙니다. 실거래는 계약·신고·공개 시점이 다를 수 있고, 시장 정보도 지표별 갱신 주기가 다릅니다.

\n

아래 네 항목을 한 줄로 기록해 보세요.

\n

조회일: 화면을 확인한 날짜
단지·평형: 비교한 단지와 전용면적
최근 거래일: 현재 기준에 포함된 최신 거래 시점
목표 시점: 비교하려는 계약·잔금 또는 이사 목표 월

\n

결과가 바뀌었을 때 이 기록이 있으면 새 거래가 반영됐는지, 평형이나 기간을 바꿨는지, 시장 정보가 갱신됐는지 순서대로 확인할 수 있습니다. 기준일·시장 정보·표본 상태의 역할은 아파트 가격 예측 결과에서 기준일·시장 정보·표본 신뢰도 읽는 법에서 설명합니다.

\n

5. 공식 실거래 자료와 나란히 보기

\n

분석 화면은 비교할 항목을 한곳에 모아 보는 출발점입니다. 계약 전에 필요한 거래 조건은 공식 자료에서 다시 확인해야 합니다.

\n

국토교통부 실거래가 공개시스템에서 계약일, 전용면적, 층, 거래금액과 해제·정정 여부를 확인합니다.
같은 단지라도 면적·층·거래 유형이 다른 가격을 한 줄로 합치지 않습니다.
공개 실거래와 분석 결과의 기준일이 다르면 어느 한쪽을 오류로 단정하기 전에 기준일과 표본 조건을 비교합니다.

\n

아파트 인사이트에서 관심 단지를 비교할 때도 결과를 매수·매도 신호로 바꾸기보다, 다음에 확인할 자료를 정하는 참고값으로 사용하세요. 최근 대표 시세와 예상 범위를 함께 보는 방법은 가입 없이 아파트 가격 예측하기에서 이어집니다.

\n

\n
아파트 인사이트의 분석 결과는 공개 데이터와 시장 조건을 바탕으로 비교하는 참고 정보입니다. 미래 가격, 거래 가능성, 수익을 보장하지 않으며 투자 권유나 매수·매도 추천이 아닙니다. 최종 계약 전에는 최신 공식 자료와 개인의 자금·거주 조건을 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/apartment-insights-start-guide", "title": "아파트 인사이트 처음 시작하기: 지역·단지·이사 시점을 입력하는 순서", "summary": "아파트 분석을 시작할 때 지역, 단지, 평형, 이사 시점을 먼저 정하는 이유와 실거래가·예상 범위를 같은 기준으로 비교하는 방법을 정리합니다.", "date_modified": "2026-09-07T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-price-forecast-without-signup", "content_html": "

“우리 아파트의 1년 뒤 가격을 먼저 확인해 보고 싶다”는 질문에 회원가입부터 요구하면, 결과를 보기 전에 사용자가 이탈하기 쉽습니다. 반대로 가입 없이 결과를 볼 수 있다고 해서 숫자 하나만 보여주면 그 숫자가 어떤 거래와 기준일에서 나온 것인지 알기 어렵습니다.

\n

이 글은 가입 없이 아파트 가격을 확인할 때 실제로 어떤 순서로 검색하고, 결과 화면에서 무엇을 확인해야 하는지 설명합니다. 핵심은 간단합니다. 단지명만 검색하지 말고 지역·평형·최근 거래·기준일을 한 묶음으로 읽어야 합니다.

\n

아파트 가격 예측은 미래 가격을 확정하는 기능이 아닙니다. 공개된 실거래와 시장 정보를 현재 시점에서 비교하고, 앞으로의 가능한 가격 범위를 살펴보는 참고 도구입니다. 계약금이나 대출 한도를 정하기 전에 사용하는 최종 답안이 아니라, 더 확인해야 할 질문을 찾는 첫 단계에 가깝습니다.

\n

먼저 알아둘 것: 가입 없이 볼 수 있는 것과 없는 것

\n

가입 없이 이용하는 공개 체험은 관심 단지의 기본 상황을 빠르게 확인하는 데 초점을 둡니다. 지역과 단지를 검색하고, 자료가 준비된 경우 최근 대표 시세와 12개월 뒤 예상가, 예상 범위, 표본 신뢰도, 시장 정보 기준일을 확인할 수 있습니다.

\n

반면 다음 질문은 공개 결과만으로 답하기 어렵습니다.

\n

공개 결과로 확인할 수 있는 내용	별도로 확인해야 하는 내용
최근 대표 시세와 기준 평형	내 대출 한도와 월 상환액
12개월 뒤 예상가와 예상 범위	실제 계약 가능한 가격과 협상 조건
표본 신뢰도와 시장 정보 기준일	세금·중개보수·수리비를 포함한 총자금
단지의 공개 체험 가능 여부	개인의 거주·이사 일정에 맞는 선택

\n

이 구분을 먼저 해 두면 “예측값이 나왔으니 매수해도 된다”거나 “범위가 넓으니 아무 의미가 없다”는 식의 극단적인 해석을 피할 수 있습니다.

\n

가입 없이 아파트 가격을 확인하는 5단계

\n

1. 시군구를 먼저 선택합니다

\n

단지명을 바로 입력하기보다 시군구를 먼저 고르는 편이 정확합니다. 같은 이름의 아파트가 다른 지역에 있을 수 있고, 비슷한 이름의 단지가 여러 곳 검색될 수 있기 때문입니다.

\n

예를 들어 “센트럴”이나 “자이”처럼 여러 지역에 반복되는 이름은 단지명만으로 구분하기 어렵습니다. 지역을 선택한 뒤 검색하면 결과에서 지역과 단지명을 함께 대조할 수 있어 잘못된 단지를 선택할 가능성이 줄어듭니다.

\n

검색 전에 다음 세 가지를 메모해 두면 좋습니다.

\n

시·도와 시·군·구
검색하려는 아파트의 공식 단지명
확인하려는 전용면적 또는 평형

\n

2. 단지의 자료 상태를 확인합니다

\n

검색 결과에 단지명이 보인다고 해서 모든 단지의 가격 전망을 즉시 볼 수 있는 것은 아닙니다. 공개 체험에서는 자료가 준비되어 결과를 확인할 수 있는 단지와, 이름은 검색되지만 자료 준비가 더 필요한 단지가 구분될 수 있습니다.

\n

자료가 준비되지 않은 경우에는 주변 단지의 숫자를 대신 보여주지 않습니다. 해당 단지와 다른 면적·연식·입지의 가격을 복사하면 그럴듯한 숫자는 만들 수 있지만, 실제 관심 단지의 시세라고 부르기 어렵기 때문입니다.

\n

이때 표시되는 등록 요청은 “요청 즉시 예측이 생성된다”는 뜻이 아닙니다. 단지 정보와 실거래 자료를 확인하고 공개 체험에 사용할 수 있는 상태가 되면 다시 확인하는 흐름입니다.

\n

3. 자동으로 선택된 평형을 확인합니다

\n

단지를 선택하면 화면은 최근 거래가 확인되는 대표 평형을 자동으로 선택합니다. 사용 가능한 다른 평형에 거래 자료가 있다면 평형을 바꿔 결과를 비교할 수 있습니다.

\n

여기서 가장 흔한 실수는 “단지 가격”을 하나의 숫자로 생각하는 것입니다. 전용면적이 59㎡인지 84㎡인지, 같은 면적이라도 층과 타입이 어떤지에 따라 비교해야 할 거래가 달라집니다. 결과 화면의 평형 탭을 먼저 확인한 뒤 가격을 읽어야 합니다.

\n

평형을 바꿀 때는 다음 질문을 함께 적어 보세요.

\n

내가 찾는 면적과 현재 선택된 면적이 같은가?
최근 거래가 해당 면적에서 실제로 확인되는가?
작은 면적의 거래를 큰 면적의 가격처럼 비교하고 있지는 않은가?

\n

4. 최근 대표 시세와 예상 범위를 함께 봅니다

\n

결과 카드에는 보통 다음 정보가 함께 표시됩니다.

\n

표시 항목	의미
최근 대표 시세	최근 유효 거래를 비교하기 위한 현재 기준값
12개월 뒤 예상가	현재 기준에서 1년 뒤를 바라본 중심 결과
예상 범위	조건 변화에 따라 달라질 수 있는 가격의 폭
변화율	최근 대표 시세와 예상가를 비교한 비율

\n

가운데 숫자인 예상가만 크게 보는 것보다 대표 시세와 범위를 같이 보는 편이 안전합니다. 예를 들어 예상가가 현재보다 높게 표시되어도 범위의 아래쪽이 현재 가격과 비슷하다면, “반드시 오른다”가 아니라 여러 조건 중 일부에서는 변화가 제한적일 수 있다는 뜻으로 읽어야 합니다.

\n

5. 표본 신뢰도와 시장 정보 기준일을 확인합니다

\n

결과 카드의 아래쪽에는 표본 신뢰도와 시장 정보 기준일이 표시될 수 있습니다. 표본 신뢰도는 예측이 맞을 확률이나 수익률이 아닙니다. 해당 단지의 거래 자료를 얼마나 안정적으로 비교할 수 있는지 판단하는 보조 정보입니다.

\n

시장 정보에는 금리, 환율, 지역 매수심리처럼 계산 시점에 함께 확인한 정보가 포함될 수 있습니다. 각 값은 같은 날 갱신되지 않을 수 있으므로 정보 옆의 기준일을 같이 봐야 합니다.

\n

가상의 결과를 읽어 보는 예시

\n

다음은 특정 단지의 실제 결과가 아닌 이해를 위한 가상 예시입니다.

\n

항목	가상 표시값
선택 평형	전용 84㎡
최근 대표 시세	10억 원
12개월 뒤 예상가	10억 4,000만 원
예상 범위	9억 5,000만 원 ~ 11억 2,000만 원
표본 신뢰도	결과 해석용 참고 지표

\n

이 표를 보고 “1년 뒤 10억 4,000만 원에 거래된다”고 결론 내리면 안 됩니다. 먼저 10억 원이 어떤 평형과 최근 거래를 기준으로 한 값인지 확인하고, 9억 5,000만 원에서 11억 2,000만 원까지 폭이 생긴 이유를 생각해야 합니다.

\n

또한 이 값은 대출이자, 취득세, 중개보수, 인테리어 비용을 포함하지 않습니다. 내 통장에 필요한 금액을 계산하려면 가격 전망과 별도로 거래비용과 현금흐름을 계산해야 합니다.

\n

공식 실거래 자료와 함께 확인하는 방법

\n

예측 화면을 본 뒤에는 공식 자료에서 최근 거래를 다시 확인해 보세요.

\n

국토교통부 실거래가 공개시스템에서 지역과 단지를 찾습니다.
전용면적과 계약일이 같은 거래를 우선 확인합니다.
층, 거래 유형, 해제·정정 여부를 함께 확인합니다.
공개 체험 화면의 대표 시세와 비교하되, 두 값이 다르다고 즉시 오류로 판단하지 않습니다.

\n

단지별 최근 거래를 평형 단위로 정리해 둔 지역별 아파트 실거래가 페이지를 함께 쓰면 대조가 더 빠릅니다. 예측 결과 화면의 “이 단지 실거래 전체 보기”를 누르면 같은 단지의 실거래 페이지로 이어집니다. 조회 순서는 지역별 아파트 실거래가 조회하는 법에 정리했습니다.

\n

공식 실거래가는 계약일·신고·공개 시점의 차이가 있을 수 있습니다. 따라서 “가장 최근에 보이는 한 건”과 “현재 대표 시세”는 서로 다른 질문에 답할 수 있습니다. 최근 거래 한 건을 해석하는 방법은 최근 거래 한 건만으로 아파트 시세를 판단하면 안 되는 이유에서 더 자세히 다룹니다.

\n

예측 결과가 어떤 원리로 범위를 보여주는지 궁금하다면 아파트 인사이트의 미래가격 예측 공식 가이드도 함께 읽어 보세요. 공개 설명과 실제 결과 화면을 이어서 보면 숫자의 역할을 구분하기 쉽습니다.

\n

앱에서는 로그인 없이 목표 월까지 고를 수 있습니다

\n

휴대폰에서 확인한다면 아파트 인사이트 앱도 로그인 없이 시작할 수 있습니다. 앱에서는 아파트 1곳·평형 1개·목표 월 1개를 고르면 해당 시점의 전망과 최근 12개월 실거래, 교통·학군·생활 인프라 같은 단지 정보를 볼 수 있습니다. 선택은 계정 없이 기기에만 저장됩니다.

\n

웹 체험이 “1년 뒤”라는 고정된 시점을 보여준다면, 앱은 이사·매수 계획에 맞춘 달을 직접 고를 수 있다는 점이 다릅니다. 자세한 흐름은 로그인 없이 아파트 시세 앱 쓰는 법에서 설명합니다.

\n

로그인은 언제 필요한가요?

\n

공개 체험은 “일단 이 단지의 현재 자료와 1년 전망을 확인해 보고 싶다”는 상황에 맞습니다. 여러 관심 단지를 저장하거나, 내 이사 시점·보유 조건·금리 조건을 바꿔 비교하거나, 변경 알림을 받아야 한다면 로그인 후 개인화 기능이 필요할 수 있습니다.

\n

공개 결과를 본 뒤 바로 가입해야 하는 것은 아닙니다. 다음 순서가 자연스럽습니다.

\n

먼저 공개 체험에서 단지와 평형이 맞는지 확인합니다.
결과의 기준일과 범위를 기록합니다.
더 긴 기간이나 개인 조건이 필요할 때 로그인 기능을 검토합니다.

\n

자주 묻는 질문

\n

가입 없이 모든 아파트를 조회할 수 있나요?

\n

아닙니다. 검색 결과에 표시되는 단지와 즉시 가격 전망을 확인할 수 있는 단지는 다를 수 있습니다. 자료가 준비되지 않은 단지는 등록 요청 안내가 표시될 수 있으며, 다른 단지의 가격을 대신 보여주지 않습니다.

\n

가입 없이 보는 예상가는 확정 가격인가요?

\n

아닙니다. 최근 거래와 시장 정보를 바탕으로 한 참고 결과입니다. 실제 가격은 거래 조건, 금리, 공급, 정책, 지역 수요와 개인 계약 조건에 따라 달라질 수 있습니다.

\n

평형을 바꾸면 왜 결과가 달라지나요?

\n

평형이 달라지면 비교하는 거래 표본과 현재 기준값이 달라지기 때문입니다. 59㎡와 84㎡의 가격을 같은 단지라는 이유만으로 하나의 시세로 합치면 해석이 흔들릴 수 있습니다.

\n

결과가 나왔는데 표본 신뢰도가 낮으면 어떻게 해야 하나요?

\n

예상가보다 최근 거래의 수·시점·면적·층 조건을 먼저 확인하세요. 거래가 드문 단지는 새 거래 한 건만 추가되어도 대표 시세와 예상 범위가 달라질 수 있습니다.

\n

예측이 얼마나 맞는지는 어떻게 알 수 있나요?

\n

과거 기준일로 돌아가 다시 예측한 뒤 실제 거래와 비교하는 백테스트 결과를 확인하세요. 평균 오차율·중간 오차율·예상 범위 적중률을 어떻게 읽는지는 아파트 가격 예측, 맞았는지 확인하는 법에서 정리했습니다.

\n

아파트 인사이트는 매수나 매도를 추천하나요?

\n

아니요. 아파트 인사이트는 공개 데이터와 시장 정보를 바탕으로 가격 흐름을 비교하는 참고 도구입니다. 대출, 세금, 거주 필요성, 계약 조건을 포함한 최종 판단은 별도로 해야 합니다.

\n

아파트 인사이트에서 직접 확인하기

\n

이제 관심 단지를 실제 화면에서 확인해 보세요. 아파트 인사이트 가입 없는 공개 예측에서 시군구와 단지명을 검색하면 대표 시세와 1년 뒤 예상 범위를 확인할 수 있습니다. 최근 거래부터 보고 싶다면 지역별 아파트 실거래가에서 시군구를 먼저 골라 보세요.

\n

기간을 바꿔 비교할 때는 6개월·12개월·18개월 전망 비교, 범위의 폭을 해석할 때는 아파트 예상 범위 읽는 법, 날짜와 자료 상태를 확인할 때는 기준일·시장 정보·표본 신뢰도 읽는 법을 이어서 보세요.

\n

처음부터 가격과 거래 조건을 같은 기준으로 확인하려면 부동산과 아파트 통계를 처음 읽는 순서에서 전체 체크리스트를 먼저 읽어 보세요.

\n

\n
아파트 인사이트의 공개 예측은 공개 데이터와 경제 시나리오를 바탕으로 한 참고용 분석입니다. 예측값과 가격 범위는 실제 결과와 다를 수 있으며 가격·거래 가능성·수익을 보장하지 않습니다. 투자 권유나 투자 자문이 아니며, 계약과 최종 판단 전에는 최신 공식 자료와 개인의 자금 조건을 별도로 확인해야 합니다.
\n

", "url": "https://alvin.ing/blog/apartment-price-forecast-without-signup", "title": "가입 없이 아파트 가격 예측하기: 검색부터 결과 해석까지", "summary": "가입 없이 아파트 단지를 검색하고 최근 대표 시세와 1년 뒤 예상 범위를 확인하는 방법을 설명합니다. 웹 체험과 앱의 로그인 없는 이용 방법, 평형·거래 표본·기준일을 함께 읽는 순서도 정리합니다.", "date_modified": "2026-09-01T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-forecast-periods", "content_html": "

아파트 가격 전망에서 “얼마나 오를까요?”만큼 중요한 질문이 있습니다. 언제의 가격을 묻는 것인가요? 6개월 뒤와 18개월 뒤는 같은 단지라도 전혀 다른 계획을 검토하는 시간입니다.

\n

기간을 길게 고르면 더 먼 미래를 볼 수 있지만, 그만큼 금리·공급·정책·거래 환경이 바뀔 시간도 길어집니다. 그래서 6개월·12개월·18개월 결과를 순위표처럼 놓고 가장 높은 숫자를 고르는 방식은 적절하지 않습니다. 먼저 각 기간이 내 질문과 맞는지 확인하고, 같은 기준일과 같은 평형에서 예상 범위를 함께 비교해야 합니다.

\n

이 글에서는 아파트 인사이트의 공개 12개월 체험과 로그인 후 조건 비교에서 볼 수 있는 기간별 결과를 어떤 순서로 읽을지 설명합니다. 기간별 전망은 매수·매도 시점을 알려주는 신호가 아니라, 서로 다른 일정과 가정을 비교하는 도구입니다.

\n

6개월·12개월·18개월은 서로 다른 질문입니다

\n

기간	어울리는 질문	가장 먼저 볼 항목
6개월	가까운 이사나 계약 일정까지 현재 환경이 어떻게 이어질까?	최근 거래, 단기 범위, 자금 부담
12개월	다음 1년 동안 가능한 가격 경로는 어느 정도일까?	현재 대표 시세와 1년 뒤 범위
18개월	더 긴 일정에서 가격 범위와 조건 변화는 어떻게 보일까?	범위 폭, 목표 월, 장기 변수

\n

6개월은 가까운 일정과 비교하기 쉽지만, 단기 거래 한두 건이나 정책 발표에 결과가 민감하게 보일 수 있습니다. 12개월은 연간 계획을 세울 때 이해하기 쉬운 기본 구간입니다. 18개월은 더 긴 미래를 보므로 계획의 여유를 검토하는 데 도움이 되지만, 그 숫자를 현재 계약 가격처럼 해석해서는 안 됩니다.

\n

기간을 바꾸면 목표 월과 비교 조건이 바뀝니다

\n

예측 기간은 단순히 화면에 붙은 숫자가 아닙니다. 조회 기준일에서 몇 개월을 이동해 목표 월을 정하고, 그 시점까지의 시장 조건을 비교합니다.

\n

예를 들어 2026년 9월 1일에 확인한다면 단순한 달력 계산은 다음처럼 됩니다.

\n

확인 기간	가상의 목표 시점
6개월	2027년 3월 전후
12개월	2027년 9월 전후
18개월	2028년 3월 전후

\n

실제 화면의 기준일과 목표 시점은 자료가 갱신되는 시점에 따라 달라질 수 있으므로 결과 카드의 날짜를 직접 확인해야 합니다. “1년 전망”이라고 써 놓고 다른 날짜의 결과를 비교하면 숫자 차이를 기간 효과로 잘못 이해할 수 있습니다.

\n

기간별 결과를 비교할 때 고정해야 할 5가지

\n

기간만 다르게 하고 나머지 조건은 가능한 한 같게 두어야 합니다.

\n

계산 기준일: 모든 결과를 같은 조회 시점에서 시작했는가?
단지와 평형: 같은 단지의 같은 전용면적을 보고 있는가?
대표 시세: 현재 비교 기준이 같은 거래 자료에서 나왔는가?
목표 월: 6개월·12개월·18개월의 끝나는 시점이 정확히 언제인가?
예상 범위: 중심값만이 아니라 아래쪽과 위쪽의 폭도 함께 변하는가?

\n

이 중 평형이 바뀌면 단순한 기간 비교가 아닙니다. 59㎡의 6개월 전망과 84㎡의 12개월 전망을 나란히 놓으면 기간뿐 아니라 주택 크기와 거래 표본까지 달라집니다.

\n

공개 체험의 12개월 전망은 비교의 출발점입니다

\n

아파트 인사이트의 가입 없는 공개 예측은 지역과 단지를 검색해 대표 시세와 12개월 뒤 예상 결과를 먼저 확인하는 흐름입니다. 회원가입 전에 데이터 상태와 평형을 확인하고 싶을 때 유용한 입구입니다.

\n

공개 결과를 본 뒤 더 긴 일정이나 개인 조건을 비교하려면 아파트 인사이트 웹 서비스에서 관심 단지와 조건을 확인할 수 있습니다. 기간 선택이 제공되더라도 결과는 미래 가격을 확정하는 기능이 아니라, 같은 단지에서 시간축을 바꿔 가능한 경로를 비교하는 기능으로 이해해야 합니다.

\n

가상의 기간별 결과를 읽는 방법

\n

다음은 실제 단지의 결과가 아닌 해석 방법을 보여주기 위한 예시입니다. 현재 대표 시세는 10억 원이고, 세 기간을 같은 평형과 같은 기준일에서 비교했다고 가정합니다.

\n

기간	중심 예상가	예상 범위	해석의 출발점
6개월	10억 1,000만 원	9억 7,000만 ~ 10억 6,000만 원	가까운 기간의 거래 흐름
12개월	10억 4,000만 원	9억 5,000만 ~ 11억 2,000만 원	1년 계획과 시장 조건
18개월	10억 7,000만 원	9억 2,000만 ~ 11억 8,000만 원	더 긴 기간의 불확실성

\n

이 예시에서 18개월의 중심값이 가장 높다는 사실만으로 18개월을 선택할 수는 없습니다. 범위의 폭도 넓어졌고, 그 사이에 금리·공급·정책·거래량이 달라질 시간도 많기 때문입니다.

\n

반대로 6개월의 범위가 좁다고 실제 가격을 더 정확하게 안다는 뜻도 아닙니다. 짧은 기간은 현재 조건과 가까운 만큼 범위가 작아 보일 수 있지만, 새 거래나 갑작스러운 정책 변화가 생기면 결과가 달라질 수 있습니다.

\n

일정에 따라 읽는 방법이 달라집니다

\n

6개월 뒤 전세 만기나 이사를 앞둔 경우

\n

6개월 전망은 계약 일정과 가까운 시간축입니다. 이때는 예상가보다 다음 항목이 더 중요할 수 있습니다.

\n

실제 매물과 전세·매매 거래량
대출 실행 가능 여부와 월 상환액
잔금일·입주일·계약갱신 일정
취득세·중개보수·이사비를 포함한 현금 필요액

\n

6개월 뒤 예상가가 현재보다 높아도 내 자금이 준비되지 않으면 계약 가능성은 별개의 문제가 됩니다. 기간별 전망을 현금흐름 계획으로 바로 바꾸지 말고, 별도 계산표로 나눠 관리하세요.

\n

12개월 계획을 세우는 경우

\n

1년은 현재와 미래를 비교하기 쉬운 구간입니다. 다만 결과를 본 날짜, 기준 평형, 예상 범위, 시장 정보 기준일을 함께 저장해야 나중에 결과가 갱신되어도 무엇이 달라졌는지 알 수 있습니다.

\n

18개월 이상 장기 계획을 보는 경우

\n

18개월은 결혼·출산·학군·직장 이동처럼 일정이 긴 경우에 참고할 수 있습니다. 먼 기간일수록 중심값 하나보다 범위 폭, 하락 쪽 여유, 금리와 공급 변화에 대한 민감도를 먼저 확인해야 합니다.

\n

기간별 예상가가 서로 반대 방향이면 어떻게 할까요?

\n

6개월은 하락하고 18개월은 회복하는 것처럼 기간별 방향이 다르게 보일 수 있습니다. 이때 어느 하나를 “정답”으로 고르기보다 경로를 나누어 읽어야 합니다.

\n

가까운 기간에는 거래와 자금 환경이 어떻게 보이는가?
긴 기간의 회복은 어떤 조건이 유지되어야 가능한가?
중간 구간의 범위가 넓어지는가?
내 일정은 단기 변동을 감당할 수 있는가?

\n

이런 질문은 특정 시점의 매수·매도를 추천하지 않습니다. 다만 일정과 자금 여유를 숫자 하나가 아닌 여러 조건으로 확인하게 해 줍니다.

\n

기간별 결과를 기록하는 표

\n

실제로 비교할 때는 아래 표를 복사해 확인일마다 채워 보세요.

\n

확인일:
단지·동네:
전용면적·타입:
최근 대표 시세:
6개월 목표 월 / 예상 범위:
12개월 목표 월 / 예상 범위:
18개월 목표 월 / 예상 범위:
시장 정보 기준일:
표본 신뢰도:
그날 확인한 공식 거래 자료:

\n

나중에 결과가 바뀌었을 때 이 기록이 있으면, 기간이 바뀐 것인지, 평형이 바뀐 것인지, 새 거래가 들어온 것인지, 시장 정보 기준일이 갱신된 것인지 구분할 수 있습니다.

\n

예상 범위를 기간별로 읽는 법

\n

기간별 비교에서 중심값만 보면 장기 결과가 자연스럽게 더 크거나 작아 보입니다. 하지만 아래·가운데·위쪽의 폭이 어떻게 달라지는지 봐야 불확실성의 변화까지 이해할 수 있습니다.

\n

아래쪽이 현재 가격보다 크게 낮아지는가?
위쪽과 아래쪽의 차이가 기간이 길어질수록 커지는가?
범위가 넓어진 이유를 시장 조건과 거래 표본에서 설명할 수 있는가?
범위 안의 값을 계약금·수익 계산의 확정값으로 사용하고 있지는 않은가?

\n

범위 자체를 해석하는 방법은 아파트 예상 범위의 아래·가운데·위 값을 읽는 법에서 예시와 함께 설명합니다.

\n

자주 묻는 질문

\n

12개월 전망이 가장 표준적인 기간인가요?

\n

12개월은 연간 계획과 비교하기 쉬운 기본 구간이지만, 모든 사람에게 가장 적합한 기간은 아닙니다. 이사일·대출 기간·거주 계획에 맞는 기간을 선택하고, 기간이 길어질수록 범위를 더 보수적으로 읽어야 합니다.

\n

6개월 전망이 18개월 전망보다 정확한가요?

\n

그렇게 단정할 수 없습니다. 6개월은 현재와 가까운 반면 단기 거래나 갑작스러운 변화에 영향을 받을 수 있고, 18개월은 미래 조건의 변화 가능성이 더 큽니다. 정확도 순위보다 각 기간의 질문과 전제를 확인해야 합니다.

\n

기간별 예상가가 높으면 그 기간까지 기다려야 하나요?

\n

아닙니다. 예상가는 가능한 경로를 비교하는 참고값입니다. 이사 필요성, 대출과 세금, 계약 조건, 실제 매물 상황이 함께 검토되어야 합니다.

\n

기간을 바꾸면 평형도 다시 확인해야 하나요?

\n

네. 기간 선택 전에 자동으로 선택된 평형과 대표 시세의 기준을 확인하세요. 평형이 달라지면 기간 외에 거래 표본도 달라집니다.

\n

아파트 인사이트에서 기간별 조건 확인하기

\n

먼저 가입 없이 아파트 가격 예측하기에서 관심 단지의 12개월 결과와 자료 상태를 확인해 보세요. 이후 개인 일정과 조건을 바꿔 비교해야 한다면 아파트 인사이트 웹 서비스로 이어갈 수 있습니다.

\n

관련해서는 가입 없이 결과를 읽는 전체 순서, 예상 범위의 폭을 해석하는 방법, 기준일과 표본 신뢰도 확인법을 함께 읽으면 좋습니다.

\n

아파트 통계를 처음부터 같은 기준으로 읽고 싶다면 부동산과 아파트 통계를 처음 읽는 순서에서 질문 정의와 비교 조건부터 확인해 보세요.

\n

\n
아파트 전망은 공개 데이터와 경제 시나리오를 바탕으로 한 참고용 분석입니다. 기간별 예상가와 범위는 실제 결과를 보장하지 않으며, 매수·매도 시점이나 투자 수익을 추천하지 않습니다. 실제 계약 전에는 최신 실거래, 대출 조건, 세금, 현금흐름을 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/apartment-forecast-periods", "title": "아파트 가격 전망 비교하는 법: 6개월·12개월·18개월 집값 예측 읽기", "summary": "아파트 가격 전망에서 6개월·12개월·18개월 기간별 차이와 목표 시점, 예상 범위, 기준일을 맞춰 집값 예측 결과를 객관적으로 비교하는 방법을 정리합니다.", "date_modified": "2026-09-01T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-forecast-range-reading", "content_html": "

아파트 가격 예측 결과 화면에서 가장 눈에 들어오는 숫자는 가운데에 있는 예상가입니다. 하지만 이 글의 질문은 “왜 범위가 필요한가?”보다 화면에 표시된 아래·가운데·위 값을 어떤 순서로 읽을 것인가에 가깝습니다. 가운데 숫자만 보고 “1년 뒤 가격은 정확히 이 금액”이라고 해석하면 전망이 가진 불확실성과 조건을 놓치게 됩니다.

\n

가격 전망에서 범위는 장식이 아닙니다. 현재 확인된 거래와 시장 정보를 바탕으로 여러 조건을 비교했을 때 결과가 어디까지 달라질 수 있는지 보여주는 정보입니다. 아래쪽·가운데·위쪽 모두 확정된 결과가 아니며, 범위의 폭과 그 폭을 만든 기준을 함께 읽어야 합니다.

\n

이 글에서는 아파트 인사이트 공개 체험 화면에서 예상 범위를 확인하는 순서, 가상의 숫자를 해석하는 법, 범위가 넓거나 좁을 때 추가로 확인할 내용을 정리합니다. 범위가 필요한 이유와 중심 추정값의 개념부터 살펴보고 싶다면 미래 아파트 가격을 하나의 숫자로 단정하면 위험한 이유를 먼저 읽어도 좋습니다.

\n

예상 범위가 필요한 이유

\n

아파트 가격은 기준일의 거래 한 건만으로 결정되지 않습니다. 전용면적, 층, 타입, 최근 거래의 구성, 금리, 공급, 지역의 거래 분위기가 함께 영향을 줄 수 있습니다. 앞으로 시간이 지나면 이 조건들이 달라질 가능성도 있습니다.

\n

미래를 하나의 숫자로만 표시하면 읽기는 쉽지만 다음 질문에 답하기 어렵습니다.

\n

현재 자료에서 확인할 수 있는 중심은 어디인가?
불리한 조건과 유리한 조건에서 결과가 얼마나 벌어지는가?
거래 표본이 충분해 범위를 해석할 수 있는가?
새 거래나 시장 변화가 생기면 결과가 달라질 수 있는가?

\n

그래서 예상 범위는 “미래 가격을 맞히는 띠”가 아니라, 현재 정보로 말할 수 있는 폭을 보여주는 참고값으로 보는 편이 정확합니다.

\n

아래쪽·가운데·위쪽은 각각 어떻게 읽을까

\n

위치	바른 해석	피해야 할 해석
아래쪽	불리한 조건이 이어질 때 참고할 수 있는 낮은 경계	반드시 이 가격까지 하락한다는 뜻
가운데	여러 가능성을 비교하기 위한 중심 기준	반드시 도달하는 확정 가격
위쪽	수요와 환경이 유지될 때 참고할 수 있는 높은 경계	반드시 도달하는 목표 가격

\n

범위의 위쪽이 높다고 좋은 결과라고 단정할 수도 없습니다. 그 값에 도달하려면 자금 여건, 거래 분위기, 공급과 정책 같은 조건이 특정 방향으로 이어져야 할 수 있습니다. 반대로 아래쪽이 낮다고 반드시 급락한다는 뜻도 아닙니다.

\n

범위의 세 위치를 읽을 때는 “어느 값이 맞나?”보다 다음 질문을 먼저 던져 보세요.

\n

현재 대표 시세는 어떤 평형과 거래를 기준으로 했는가?
기준일에서 목표 시점까지 얼마나 먼가?
범위의 폭이 거래 표본의 부족 때문인지, 미래 조건의 불확실성 때문인지 구분할 수 있는가?
내 자금 계획은 가운데 값이 아니라 아래쪽 결과에서도 유지되는가?

\n

가상의 숫자로 계산해 보기

\n

다음 표는 특정 단지의 실제 결과가 아닌 이해를 위한 예시입니다.

\n

항목	가상 값
최근 대표 시세	10억 원
12개월 뒤 아래쪽	9억 5,000만 원
12개월 뒤 가운데	10억 4,000만 원
12개월 뒤 위쪽	11억 2,000만 원

\n

이 경우 가운데 값의 변화율은 현재 대비 약 4%지만, 아래쪽은 약 5% 낮고 위쪽은 약 12% 높습니다. 중요한 것은 “12개월 뒤에 10억 4,000만 원이 된다”가 아니라, 현재 정보에서 서로 다른 조건을 고려하면 결과의 폭이 이 정도로 벌어질 수 있다는 점입니다.

\n

만약 매수 계획을 세우면서 가운데 값만 사용하면 취득세·중개보수·대출이자까지 포함한 현금흐름을 과소평가할 수 있습니다. 반대로 아래쪽 값만 사용해 모든 상황을 비관적으로 가정하는 것도 적절하지 않습니다. 가격 범위와 내 자금 계획은 별도 표로 관리해야 합니다.

\n

범위의 폭을 비교하는 방법

\n

범위는 아래쪽과 위쪽의 차이로만 볼 것이 아니라 현재 대표 시세와 비교해 상대적인 폭도 살펴야 합니다.

\n

범위 폭 = 위쪽 값 - 아래쪽 값
상대 범위 폭 = 범위 폭 ÷ 현재 대표 시세

\n

예를 들어 현재 대표 시세가 10억 원이고 예상 범위가 9억 5,000만 원에서 11억 2,000만 원이라면 범위 폭은 1억 7,000만 원입니다. 이 수치는 매수·매도 결론이 아니라, 가운데 값 하나로 현금 계획을 고정하기에는 변동 가능성을 더 고려해야 한다는 신호입니다.

\n

다른 단지와 범위를 비교할 때도 현재 가격 수준과 평형이 같아야 합니다. 6억 원 단지의 1억 원 범위와 20억 원 단지의 1억 원 범위는 같은 의미가 아닐 수 있고, 59㎡와 84㎡를 섞으면 거래 조건 차이가 범위 차이처럼 보일 수 있습니다.

\n

범위를 보기 전에 확인할 네 가지

\n

1. 기준일

\n

예상 범위는 언제의 자료를 기준으로 했는지에 따라 달라집니다. 최근 거래가 추가되거나 시장 정보가 갱신되면 같은 단지도 결과를 다시 확인해야 할 수 있습니다.

\n

2. 목표 기간

\n

6개월·12개월·18개월은 서로 다른 시간축입니다. 기간이 길수록 미래 조건이 바뀔 가능성이 커지므로, 중심값보다 범위 폭을 먼저 비교하는 것이 좋습니다. 기간별 결과를 맞춰 보는 방법은 6개월·12개월·18개월 전망 비교 가이드에서 설명합니다.

\n

3. 거래 조건

\n

같은 단지라도 평형·층·타입이 달라지면 비교할 거래가 달라집니다. 대표 시세와 예상 범위가 어떤 평형을 기준으로 계산되었는지 확인하지 않으면 다른 조건의 숫자를 한 줄에 섞게 됩니다.

\n

4. 표본 신뢰도

\n

표본 신뢰도는 결과가 맞을 확률이나 범위 안에 들어갈 확률을 보장하는 숫자가 아닙니다. 거래 표본이 충분한지, 최근 거래가 이어지는지, 비교 조건이 안정적인지 해석하는 참고 정보입니다.

\n

범위가 넓으면 분석이 무의미한가요?

\n

그렇지 않습니다. 범위가 넓다는 것은 현재 시점에 확인되지 않은 조건이 많다는 뜻일 수 있습니다. 이 정보는 다음과 같은 계획에 도움을 줍니다.

\n

계약금과 잔금 사이에 필요한 현금 여유를 다시 계산하기
대출 금리 변화가 월 상환액에 미치는 영향을 따로 확인하기
거래가 부족한 단지라면 현장 매물과 추가 실거래를 더 확인하기
정책·공급 변화가 일정에 미칠 가능성을 메모하기

\n

다만 범위가 넓은 상태에서 가운데 값만 골라 계약금이나 수익을 계산하면 안 됩니다. 가격과 별도로 대출이자, 세금, 중개보수, 수리비, 전세 보증금 등 실제 현금흐름을 계산해야 합니다.

\n

범위가 좁으면 안심해도 될까요?

\n

범위가 좁다고 실제 가격이 그 안에 반드시 들어간다는 뜻은 아닙니다. 현재 확인된 자료가 비슷한 조건으로 모여 있거나 목표 기간이 짧아 범위가 좁게 보일 수 있지만, 갑작스러운 금리·정책·공급 변화는 별도의 영향을 줄 수 있습니다.

\n

범위가 좁은 결과를 볼 때도 다음을 확인하세요.

\n

최근 거래의 면적과 층 조건이 일관적인가?
조회 기준일과 거래 계약일 사이의 간격이 큰가?
실거래가 적은데 범위만 좁게 표시된 것은 아닌가?
아래쪽 결과에서도 내 대출과 거주 계획이 유지되는가?

\n

공개 체험에서 범위를 확인하는 순서

\n

아파트 인사이트의 가입 없는 공개 예측에서 관심 단지를 검색했다면 다음 순서로 결과를 읽어 보세요.

\n

단지명과 지역이 맞는지 확인합니다.
자동 선택된 평형이나 직접 선택한 평형을 확인합니다.
최근 대표 시세의 기준을 확인합니다.
12개월 뒤 예상가와 아래·가운데·위 범위를 함께 봅니다.
표본 신뢰도와 시장 정보별 기준일을 확인합니다.
확인 날짜와 주요 숫자를 기록합니다.

\n

예상 범위가 만들어지는 공개 개념과 실제 화면의 설명은 아파트 인사이트 미래가격 예측 공식 가이드에서 이어서 볼 수 있습니다.

\n

가격 범위와 현금 계획을 분리하는 표

\n

가격 전망을 봤다면 아래처럼 가격과 비용을 나누어 적어 보세요.

\n

구분	기록할 내용
가격	현재 대표 시세, 예상 범위, 기준일
자금	자기자본, 대출 원금, 예상 금리, 월 상환액
세금·비용	취득세, 양도 관련 세금, 중개보수, 수리비
일정	계약일, 잔금일, 입주일, 전세 만기
확인 필요	공식 실거래, 매물 조건, 세법과 금융기관 안내

\n

이렇게 나누면 예상가가 올랐다는 사실과 실제로 필요한 현금이 늘었다는 사실을 혼동하지 않을 수 있습니다.

\n

자주 묻는 질문

\n

예상 범위 안에 실제 가격이 들어갈 확률은 얼마인가요?

\n

예상 범위는 여러 조건을 비교한 참고 구간이며, 실제 가격이 그 안에 들어갈 확률이나 적중을 보장하는 통계적 신뢰구간으로 해석하면 안 됩니다. 실제 결과는 미래의 거래·정책·금리 환경에 따라 달라질 수 있습니다.

\n

가운데 값이 가장 가능성이 높은 가격인가요?

\n

가운데 값은 결과를 비교하기 위한 중심 기준입니다. 반드시 가장 가능성이 높거나 실제로 도달하는 가격이라고 단정할 수는 없습니다.

\n

아래쪽 값으로 매수 예산을 잡으면 안전한가요?

\n

아닙니다. 아래쪽 값도 미래 가격을 보장하지 않습니다. 대출 승인, 금리, 세금, 중개보수, 생활비를 포함한 개인의 현금흐름을 별도로 검토해야 합니다.

\n

범위가 계속 바뀌는 이유는 무엇인가요?

\n

새로운 실거래가 반영되거나 시장 정보가 갱신되거나, 확인하는 평형·기간이 달라졌을 수 있습니다. 결과가 바뀌면 기준일과 평형부터 다시 확인하세요.

\n

아파트 인사이트에서 예상 범위 직접 확인하기

\n

아파트 인사이트 공개 예측 화면에서 시군구와 단지명을 검색해 보세요. 결과가 나오면 가운데 숫자보다 먼저 기준일, 거래 조건, 범위의 폭을 확인하는 습관을 들이는 것이 좋습니다.

\n

관련 글로는 가입 없이 아파트 가격을 확인하는 전체 순서, 최근 거래 한 건의 한계, 기준일·시장 정보·표본 신뢰도 읽는 법을 함께 추천합니다.

\n

아파트 통계의 전체 비교 순서는 부동산과 아파트 통계를 처음 읽는 순서에서 확인할 수 있습니다.

\n

\n
아파트 예상 범위는 공개 데이터와 경제 시나리오를 바탕으로 한 참고용 분석입니다. 아래쪽·가운데·위쪽 어느 값도 미래 가격이나 수익을 보장하지 않으며 투자 권유나 투자 자문이 아닙니다. 실제 거래와 계약 전에는 최신 공식 자료와 개인의 자금 조건을 별도로 확인해야 합니다.
\n

", "url": "https://alvin.ing/blog/apartment-forecast-range-reading", "title": "아파트 시세 예측 범위 읽는 법: 최저가·중간값·최고가의 의미", "summary": "아파트 시세 예측 결과 화면의 최저가·중간값·최고가 범위가 의미하는 바와 확정 가격이 아닌 불확실성 구간으로 해석하는 실전 가이드를 정리합니다.", "date_modified": "2026-09-01T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-single-trade-limit", "content_html": "\n

아파트 검색 결과에서 가장 최근 거래 한 건이 눈에 띄면, 그 가격을 곧바로 “현재 시세”라고 생각하기 쉽습니다. 하지만 거래 한 건에는 전용면적, 층, 타입, 거래 시점, 내부 상태, 급매 여부처럼 단지 전체를 대표하지 않는 조건이 함께 들어 있을 수 있습니다.

\n

최근 실거래 한 건은 중요한 관측값입니다. 다만 관측값과 대표 시세는 같은 말이 아닙니다. 대표 시세를 이해하려면 여러 거래가 같은 조건에서 반복되는지, 거래가 얼마나 자주 있었는지, 특수한 거래가 섞이지 않았는지를 함께 봐야 합니다.

\n

이 글에서는 국토교통부 실거래 자료를 읽는 기본 순서와 아파트 인사이트에서 거래 흐름을 확인할 때 볼 수 있는 항목을 연결해 설명합니다.

\n

최근 거래 한 건이 흔들릴 수 있는 6가지 이유

\n

1. 전용면적이 다릅니다

\n

전용 59㎡와 84㎡는 같은 단지에 있어도 수요와 가격이 다릅니다. 공급면적이나 방 개수가 비슷해 보인다는 이유로 다른 전용면적의 거래를 한 줄로 합치면, 면적 차이가 가격 변화처럼 보일 수 있습니다.

\n

2. 층이 다릅니다

\n

저층, 일반층, 고층은 조망·소음·일조·사생활 조건이 다를 수 있습니다. 같은 전용면적이라도 층이 다른 거래가 한 건씩만 있다면 층 차이를 시장 가격 변화로 오해하기 쉽습니다.

\n

3. 타입과 동·향이 다릅니다

\n

판상형·타워형, 남향·동향, 내부 동선과 수납 구조 같은 타입 차이가 있을 수 있습니다. 실거래 공개 화면에서 모든 세부 조건이 같은 수준으로 표시되지 않는 경우도 있으므로, 거래 한 건을 전체 단지의 기준으로 확대하지 않아야 합니다.

\n

4. 거래일과 공개일이 다릅니다

\n

실거래 자료에는 계약일, 신고일, 공개일 사이의 시간 차이가 생길 수 있습니다. 화면에서 최근에 보이는 거래가 실제로는 몇 주 전 계약일일 수 있으므로, 조회일만 보고 “오늘의 가격”으로 부르면 안 됩니다.

\n

5. 거래 유형이 다릅니다

\n

일반 매매와 직거래, 특수한 거래 조건은 같은 방식으로 비교하기 어렵습니다. 거래 유형이 다르거나 정상적인 시장 거래로 보기 어려운 사유가 있는 경우에는 대표 시세 계산에서 분리해 확인해야 합니다.

\n

6. 계약이 해제·정정될 수 있습니다

\n

계약 해제나 신고 정정이 뒤늦게 반영될 수 있습니다. 가장 높은 가격이나 가장 낮은 가격을 먼저 찾기보다 거래 상태와 공개 기준을 확인해야 하는 이유입니다.

\n

거래 한 건 대신 함께 볼 항목

\n

확인 항목	확인할 질문
전용면적	같은 크기의 거래인가?
층	저층·일반층·고층 차이가 있는가?
타입과 위치	동·향·구조 차이가 가격에 섞였는가?
거래일	실제 계약 시점은 언제인가?
거래 유형	일반 매매와 직거래가 섞였는가?
거래 빈도	최근 여러 달 동안 거래가 이어졌는가?
거래 상태	해제·정정 거래를 포함하고 있지 않은가?

\n

이 표의 질문에 답하지 않은 채 최근 가격만 복사하면 숫자는 빠르게 얻을 수 있지만, 비교 기준은 약해집니다.

\n

평균보다 먼저 중앙값과 분포를 보는 이유

\n

거래가 몇 건뿐인 달에 비정상적으로 높거나 낮은 거래가 하나 들어오면 평균은 크게 움직일 수 있습니다. 중앙값은 거래를 가격순으로 놓았을 때 가운데에 있는 값이라 특이한 한 건의 영향이 평균보다 작을 수 있습니다.

\n

다만 중앙값도 만능은 아닙니다. 거래가 두 건뿐이거나 면적과 층이 섞여 있다면 가운데 값이 생겨도 비교 조건은 여전히 불안정합니다. 따라서 가격 하나보다 다음 세 가지를 같이 보는 것이 좋습니다.

\n

같은 조건의 거래가 반복되는지
가격이 어느 구간에 모여 있는지
해당 기간에 거래가 실제로 얼마나 있었는지

\n

거래가 적은 단지에서는 거래 빈도 자체가 정보입니다

\n

거래가 적은 단지의 최근 한 건은 가격을 알려주는 동시에 “현재 관측이 부족하다”는 사실도 알려줍니다. 거래가 적은데 최근 최고가만 강조하면 가격 상승처럼 보일 수 있고, 최근 최저가만 강조하면 급락처럼 보일 수 있습니다.

\n

거래가 드문 단지를 확인할 때는 다음을 따로 기록해 보세요.

\n

최근 거래가 발생한 달
해당 달의 거래 건수
같은 전용면적의 거래 건수
층과 타입이 같은 거래인지
직전 거래와의 시간 간격

\n

이 기록은 가격 방향을 예언하기 위한 것이 아니라, 현재 자료로 어느 정도까지 말할 수 있는지 정하기 위한 것입니다.

\n

아파트 인사이트에서 거래 흐름을 보는 방법

\n

아파트 인사이트의 단지 분석 화면에서는 최근 거래 한 건 외에 거래 흐름을 여러 각도에서 확인할 수 있습니다. 화면과 제공 범위에 따라 다음 항목을 살펴볼 수 있습니다.

\n

화면에서 볼 항목	의미
면적별·층별 분포	거래가 특정 면적이나 층에 몰려 있는지 확인
거래 회전율	단지 규모에 비해 거래가 얼마나 있었는지 보는 참고값
월별 거래 빈도	한 달의 우연한 거래인지 반복 흐름인지 확인
직거래 비중	일반 중개 거래와 다른 유형이 얼마나 섞였는지 확인
층·거래 유형 필터	저층·일반층, 거래 유형을 나누어 비교
같은 조건의 중앙값	비교 조건을 맞춘 가격 기준을 확인

\n

이 정보는 “한 건을 제거해서 보기 좋은 가격을 만드는 기능”이 아닙니다. 거래를 어떤 조건으로 묶었는지 이해하고, 서로 다른 거래를 무심코 섞지 않도록 돕는 확인 화면입니다.

\n

아파트 인사이트 웹 서비스에서 관심 단지를 선택했다면, 가격 카드만 보지 말고 거래 분석 영역에서 면적·층·거래 유형을 바꿔 보세요. 필터를 바꾼 뒤 같은 조건의 중앙값과 거래 건수가 어떻게 달라지는지 확인하면 최근 한 건의 위치를 더 잘 이해할 수 있습니다.

\n

가상의 거래 세 건을 비교해 보기

\n

다음은 실제 단지의 값이 아닌 해석을 위한 가상 예시입니다.

\n

거래	전용면적	층	거래 유형	가격
A	84㎡	고층	일반 매매	10억 8,000만 원
B	84㎡	일반층	일반 매매	10억 1,000만 원
C	84㎡	저층	직거래	9억 6,000만 원

\n

A만 보면 “현재 시세는 10억 8,000만 원”처럼 보이고, C만 보면 “9억 6,000만 원이면 살 수 있다”고 생각할 수 있습니다. 하지만 세 거래는 층과 거래 유형이 다릅니다. 이럴 때는 같은 조건의 거래를 더 확보하고, 필터를 나누어 중앙값과 분포를 비교해야 합니다.

\n

또한 B가 최근 거래라는 이유만으로 단지 전체의 시세가 10억 1,000만 원이라고 단정할 수도 없습니다. 동·향·내부 상태와 계약 시점이 다를 수 있기 때문입니다. 예시는 최근 거래 하나를 버리자는 뜻이 아니라, 하나의 숫자에 설명을 더 붙이자는 뜻입니다.

\n

공식 실거래 자료와 분석 결과를 대조하는 순서

\n

1. 국토교통부 자료에서 거래 조건 확인

\n

국토교통부 실거래가 공개시스템에서 지역과 단지를 검색하고 계약일, 전용면적, 층, 거래금액을 확인합니다.

\n

2. 해제·정정 여부 확인

\n

거래가 현재 유효한지, 정정이나 해제 표시가 있는지 확인합니다. 공개 시점에 따라 표시가 달라질 수 있으므로 조회 날짜도 함께 기록합니다.

\n

3. 같은 조건만 먼저 묶기

\n

면적과 층을 맞춘 뒤 거래 유형을 나눕니다. 조건을 맞춘 거래가 너무 적다면 “대표 시세를 계산하기 어렵다”는 결과도 유효한 결론입니다.

\n

4. 대표 시세와 예상 범위를 함께 보기

\n

아파트 인사이트 공개 체험의 대표 시세는 최근 여러 유효 거래를 비교하기 위한 기준값입니다. 가장 최근 거래와 다를 수 있으며, 그 차이가 곧 오류라는 뜻은 아닙니다. 대표 시세의 기준 평형과 예상 범위는 함께 확인해야 합니다.

\n

최근 거래와 예상 범위를 연결해서 읽기

\n

최근 거래 한 건을 확인했다면 바로 미래 가격을 계산하기보다 다음 순서를 지켜 보세요.

\n

최근 거래가 어느 조건의 거래인지 확인합니다.
같은 조건의 거래가 최근 여러 달에도 있었는지 봅니다.
거래 빈도와 직거래 비중을 확인합니다.
대표 시세가 어느 조건을 기준으로 하는지 확인합니다.
12개월 뒤 예상가와 예상 범위를 중심값 하나로 단정하지 않습니다.

\n

예상 범위를 읽는 법은 아파트 예상 범위의 아래·가운데·위 값을 해석하는 법, 결과 카드의 기준일과 표본 신뢰도는 아파트 가격 예측 결과의 기준일 읽는 법에서 이어집니다.

\n

자주 묻는 질문

\n

최근 거래가 한 건뿐이면 그 가격을 사용하면 안 되나요?

\n

사용할 수는 있지만 “최근 확인된 한 건”이라고 표현해야 합니다. 단지 전체의 대표 시세로 확대하기 전에 면적·층·타입·거래 유형과 추가 자료를 확인해야 합니다.

\n

최신 거래가 가장 중요한 것 아닌가요?

\n

최신성은 중요하지만 조건과 자료 상태를 함께 봐야 합니다. 최신 거래가 특수한 층·면적·거래 유형에 해당하면 단지 전체의 기준으로 쓰기 어려울 수 있습니다.

\n

직거래는 무조건 제외해야 하나요?

\n

무조건 제외한다고 단정하기보다 일반 매매와 분리해서 비교하는 것이 좋습니다. 거래 유형이 다르면 가격 형성 과정과 비용 구조가 다를 수 있기 때문입니다.

\n

거래 회전율이 높으면 가격이 오른다는 뜻인가요?

\n

아닙니다. 거래 회전율은 거래 활발함을 보는 참고값이지, 가격 방향이나 상승률을 보장하는 지표가 아닙니다. 가격·거래량·기간을 함께 확인해야 합니다.

\n

아파트 인사이트에서 같은 조건으로 확인하기

\n

단지의 최근 거래 목록과 최근 1년 거래 범위는 지역별 아파트 실거래가에서 평형별로 바로 확인할 수 있습니다. 1년 뒤 흐름까지 보려면 가입 없이 아파트 가격 예측에서 지역과 단지를 검색하고, 자동 선택된 평형과 최근 대표 시세를 확인해 보세요. 거래 분포와 필터를 더 자세히 비교하려면 아파트 인사이트 웹 서비스에서 관심 단지의 분석 화면으로 이어갈 수 있습니다.

\n

관련 글로는 가입 없이 결과를 확인하는 5단계, 기간별 전망 비교, 표본 신뢰도와 기준일 읽기를 추천합니다.

\n

통계의 정의와 비교 조건부터 정리하려면 부동산과 아파트 통계를 처음 읽는 순서를 함께 읽어 보세요.

\n

\n
실거래 자료와 공개 예측은 시점·면적·층·타입·거래 상태에 따라 다르게 해석될 수 있습니다. 이 글은 특정 아파트의 매수·매도 판단을 권하지 않으며 가격·거래 가능성·수익을 보장하지 않습니다. 계약 전에는 최신 공식 자료와 실제 거래 조건을 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/apartment-single-trade-limit", "title": "아파트 실거래가 보는 법: 최근 거래 한 건만 믿으면 위험한 이유", "summary": "최근 실거래 한 건이 아파트 전체 시세를 대표하지 않는 이유와 면적·층·타입·직거래 여부 등 아파트 실거래가를 제대로 보는 6가지 기준을 정리합니다.", "date_modified": "2026-09-01T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-forecast-metadata", "content_html": "

아파트 가격 예측 결과에서 예상가만 확인하면, 그 숫자가 언제 계산되었고 어떤 자료를 함께 봤는지 알기 어렵습니다. 같은 단지라도 새 거래가 추가되거나 시장 정보가 갱신되면 결과가 달라질 수 있습니다.

\n

그래서 가격 카드 주변에 표시되는 기준일, 시장 정보, 표본 신뢰도를 함께 봐야 합니다. 이 세 항목은 숫자를 더 그럴듯하게 꾸미는 장식이 아니라, 결과를 어느 정도까지 믿고 어떤 자료를 추가로 확인할지 알려주는 맥락입니다.

\n

이 글에서는 아파트 인사이트 공개 체험에서 결과를 확인한 뒤 날짜와 자료 상태를 기록하는 방법을 설명합니다. 예측값의 정확도를 보장하는 방법이 아니라, 숫자의 출처와 한계를 놓치지 않는 읽기 방법입니다.

\n

1. 기준일: “언제까지의 정보인가”

\n

기준일은 예측이 어떤 시점의 자료를 바탕으로 했는지 이해하기 위한 날짜입니다. 예측을 화면에서 본 날짜와 항상 같은 뜻은 아닙니다.

\n

실거래에는 계약일·신고일·공개일 사이의 차이가 생길 수 있습니다. 시장 정보도 금리, 환율, 지역 매수심리처럼 지표마다 갱신 주기가 다릅니다. 따라서 “오늘 화면을 열었다”는 사실만으로 모든 값이 오늘의 정보라고 생각하면 안 됩니다.

\n

결과를 기록할 때는 적어도 다음 날짜를 나누어 적는 것이 좋습니다.

\n

날짜	확인할 내용
조회일	내가 화면을 본 날짜와 시간
가격 기준일	최근 대표 시세를 해석할 기준일
최근 거래일	가격 기준에 포함된 최신 계약일
목표 시점	6개월·12개월·18개월 뒤의 예상 시점
시장 정보 기준일	금리·환율·지역 정보 각각의 날짜

\n

이 날짜를 구분해 두면 며칠 뒤 결과가 바뀌었을 때 새 거래 때문인지, 시장 정보 갱신 때문인지, 기간이나 평형이 달라졌기 때문인지 추적할 수 있습니다.

\n

2. 시장 정보: 가격의 단독 원인이 아닌 맥락

\n

공개 예측 결과에는 계산 시점에 함께 확인한 시장 참고 정보가 표시될 수 있습니다. 예를 들어 금리, 환율, 지역 매수심리 같은 값과 각각의 기준일이 함께 제시될 수 있습니다.

\n

이 정보는 “금리가 올랐으니 아파트 가격이 반드시 내린다”처럼 단독 원인을 선언하기 위한 것이 아닙니다. 아파트 가격은 공급, 거래량, 자금 부담, 지역 수요, 단지의 거래 조건이 함께 작용할 수 있습니다.

\n

표시 정보	이렇게 읽기	이렇게 읽지 않기
금리	대출과 자금 부담을 살피는 시장 조건	금리 하나로 가격 방향 확정
환율·대외 환경	국내 시장에 영향을 줄 수 있는 주변 조건	환율 변화만으로 단지 가격 계산
지역 매수심리	해당 지역의 거래 분위기를 보는 참고값	특정 단지의 매수 의사로 단정
기준일	자료가 어느 시점에 갱신됐는지 확인	화면 조회일과 항상 같다고 가정

\n

시장 정보는 가격을 해석하는 배경입니다. 실제 거래가 추가되거나 지역 분위기가 달라지면 같은 단지의 결과가 이전과 달라질 수 있으므로, 값 자체보다 날짜와 함께 봐야 합니다.

\n

3. 표본 신뢰도: 정확도 보증이 아닌 자료 상태

\n

표본 신뢰도는 예측이 맞을 확률이나 수익률을 의미하지 않습니다. 해당 단지의 거래 표본이 얼마나 안정적으로 비교되는지 판단하기 위한 참고 지표입니다.

\n

표본 신뢰도가 높게 표시되어도 실제 가격이 반드시 예상 범위 안에 들어간다는 뜻은 아닙니다. 반대로 낮게 표시된다고 해서 결과가 반드시 틀린다는 뜻도 아닙니다. 다만 거래가 적거나 최근 거래가 드문 경우에는 결과를 더 보수적으로 읽고 최신 공식 자료를 추가로 확인해야 한다는 신호입니다.

\n

표본 신뢰도를 볼 때는 숫자만 보지 말고 다음 질문을 함께 확인하세요.

\n

대표 시세와 예상 범위가 같은 평형을 기준으로 하는가?
최근 거래가 같은 면적과 비슷한 조건에서 반복되는가?
거래일과 기준일 사이에 긴 공백이 있는가?
저층·고층, 타입, 직거래처럼 비교를 나눠야 할 조건이 섞였는가?

\n

표본 신뢰도는 “이 결과를 믿어도 되는가?”라는 이분법적 답이 아니라, “이 결과와 함께 어떤 자료를 더 봐야 하는가?”에 가까운 안내입니다.

\n

결과가 바뀌었을 때 원인을 찾는 순서

\n

어제 본 결과와 오늘 본 결과가 다르면 곧바로 분석 오류라고 결론 내리지 마세요. 아래 순서로 조건을 맞춰 보세요.

\n

첫째, 단지와 평형을 확인합니다

\n

자동으로 선택된 대표 평형이 달라졌거나 사용자가 다른 평형을 선택했을 수 있습니다. 같은 단지라도 전용면적이 달라지면 비교 거래와 현재 기준값이 달라집니다.

\n

둘째, 최근 거래의 추가 여부를 확인합니다

\n

새 거래가 공개되면 최근 대표 시세가 달라질 수 있습니다. 특히 거래가 드문 단지는 한 건의 추가 거래가 결과에 더 크게 보일 수 있습니다.

\n

셋째, 시장 정보 기준일을 비교합니다

\n

금리·환율·지역 매수심리의 기준일이 갱신됐는지 확인합니다. 모든 정보가 같은 날짜에 갱신되지 않으므로 항목별 날짜를 따로 봐야 합니다.

\n

넷째, 전망 기간을 맞춥니다

\n

6개월·12개월·18개월처럼 목표 기간이 달라지면 목표 시점과 불확실성의 폭도 달라집니다. 기간 비교 방법은 6개월·12개월·18개월 아파트 전망을 비교하는 방법에서 설명합니다.

\n

다섯째, 범위의 폭을 확인합니다

\n

중심 예상가가 비슷해도 아래쪽·위쪽 범위가 넓어졌을 수 있습니다. 결과가 바뀌었는지 확인할 때는 중심값 하나가 아니라 범위 전체를 비교해야 합니다.

\n

결과 카드 읽기: 실제 확인 순서

\n

아파트 인사이트 가입 없는 공개 예측에서 아파트를 검색했다면 다음 순서로 카드를 읽어 보세요.

\n

지역과 단지명이 내가 찾는 곳과 맞는지 확인합니다.
자동 선택 또는 직접 선택한 평형을 확인합니다.
최근 대표 시세와 최근 거래일을 확인합니다.
12개월 뒤 예상가와 아래·가운데·위 예상 범위를 함께 봅니다.
표본 신뢰도의 의미를 확인하고 정확도 보증으로 사용하지 않습니다.
시장 정보별 값과 기준일을 확인합니다.
조회일·평형·범위를 메모합니다.

\n

이 순서를 지키면 숫자만 캡처해 두었다가 나중에 의미를 잃는 일을 줄일 수 있습니다.

\n

가상의 기록 예시

\n

다음은 특정 단지의 실제 결과가 아닌 기록 방법을 보여주는 예시입니다.

\n

조회일: 2026-09-01
단지·지역: 가상 단지 / 가상 시군구
평형: 전용 84㎡
최근 대표 시세: 10억 원
최근 거래일: 2026-08-20
12개월 뒤 예상가: 10억 4,000만 원
예상 범위: 9억 5,000만 ~ 11억 2,000만 원
표본 신뢰도: 화면 표시값을 참고용으로 기록
금리 기준일: 2026-08-29
환율 기준일: 2026-08-29
지역 매수심리 기준일: 2026-08-26

\n

다음에 결과를 다시 확인했을 때 예상가가 10억 2,000만 원으로 바뀌었다면, 먼저 최근 거래일과 시장 정보 기준일을 비교합니다. 평형이 같고 새 거래가 들어왔다면 가격 기준이 달라진 것일 수 있고, 기간을 바꿨다면 목표 시점이 달라진 것입니다.

\n

공식 자료를 함께 확인해야 하는 이유

\n

예측 화면은 자료를 한 번에 비교하기 좋은 도구지만, 계약에 필요한 모든 정보를 대신하지는 않습니다. 다음 공식 자료를 함께 확인하세요.

\n

국토교통부 실거래가 공개시스템: 계약일·면적·층·거래금액 확인
한국부동산원 R-ONE: 주택가격지수와 거래 현황 확인
아파트 인사이트 미래가격 예측 공식 가이드: 예측 결과와 범위를 읽는 공개 설명

\n

공식 자료의 최신성과 공개 체험의 기준일이 다를 수 있으므로, 두 숫자를 억지로 하나로 맞추기보다 차이가 생긴 이유를 기록하는 편이 좋습니다.

\n

예상 범위와 표본 신뢰도를 함께 읽는 방법

\n

표본 신뢰도가 낮고 예상 범위도 넓다면, 가운데 값만 보고 계획을 고정하기보다 추가 거래와 현금흐름을 먼저 확인하세요. 표본 신뢰도가 높고 범위가 좁더라도 미래의 정책·공급·금리 변화까지 사라지는 것은 아닙니다.

\n

아래 표처럼 두 항목을 조합해 읽을 수 있습니다.

\n

표본 신뢰도	예상 범위	읽는 방법
높음	좁음	비교 조건과 기준일을 확인한 뒤 추적 관찰
높음	넓음	자료는 비교적 안정적이지만 미래 조건의 변화를 크게 봄
낮음	좁음	숫자가 정밀해 보여도 거래 표본을 먼저 재확인
낮음	넓음	추가 실거래·매물·공식 통계를 확인하고 보수적으로 해석

\n

이 표는 좋고 나쁨을 판정하는 등급표가 아닙니다. 결과를 어떤 강도로 사용할지 정하기 위한 질문표입니다.

\n

자주 묻는 질문

\n

기준일이 오늘 날짜와 다르면 결과가 오래된 건가요?

\n

반드시 그렇지는 않습니다. 실거래와 시장 정보는 계약·신고·공개·갱신 시점이 다를 수 있습니다. 어떤 항목의 기준일인지 확인하고, 최근 거래일과 함께 판단해야 합니다.

\n

표본 신뢰도가 높으면 예측이 맞나요?

\n

아닙니다. 표본 신뢰도는 거래 자료를 비교하는 상태를 알려주는 참고 지표입니다. 실제 가격과 거래 가능성, 수익을 보장하지 않습니다.

\n

시장 정보가 좋아지면 아파트 가격도 반드시 오르나요?

\n

아닙니다. 금리·환율·지역 매수심리는 여러 참고 정보 중 일부입니다. 공급, 거래량, 단지 조건과 개인의 자금 여건을 함께 확인해야 합니다.

\n

결과가 바뀌면 어느 값이 맞는 건가요?

\n

먼저 평형, 기준일, 최근 거래, 목표 기간, 시장 정보 기준일을 맞춰 보세요. 조건이 달라진 결과는 서로 다른 시점의 참고값일 수 있습니다.

\n

아파트 인사이트에서 기준일과 범위 확인하기

\n

아파트 인사이트의 가입 없는 공개 예측에서 관심 단지를 검색하고, 결과를 확인한 날짜와 평형을 함께 기록해 보세요. 예측 범위의 아래·가운데·위 값을 읽는 방법은 아파트 예상 범위 해석 가이드, 검색부터 결과 확인까지는 가입 없이 아파트 가격 예측하는 방법에서 이어서 볼 수 있습니다.

\n

더 긴 기간을 비교하려면 기간별 전망 비교, 거래 한 건의 한계를 확인하려면 최근 거래 한 건으로 시세를 판단하면 안 되는 이유를 참고하세요.

\n

가격·거래량·기간·지역을 어떤 순서로 비교할지 먼저 정리하려면 부동산과 아파트 통계를 처음 읽는 순서에서 기본 체크리스트를 확인할 수 있습니다.

\n

\n
아파트 인사이트의 가격 예측과 시장 정보는 공개 데이터와 경제 시나리오를 바탕으로 한 참고용 분석입니다. 화면의 요약과 표본 신뢰도는 정확도·적중률·수익을 보장하지 않으며, 투자 권유나 투자 자문이 아닙니다. 계약과 최종 판단 전에는 최신 공식 자료와 개인의 자금 조건을 별도로 확인하세요.
\n

", "url": "https://alvin.ing/blog/apartment-forecast-metadata", "title": "아파트 가격 예측 결과에서 기준일·시장 정보·표본 신뢰도 읽는 법", "summary": "아파트 가격 예측 결과의 기준일, 시장 참고 정보, 표본 신뢰도가 각각 무엇을 뜻하는지 설명합니다. 결과가 바뀌었을 때 원인을 추적하는 기록법도 정리합니다.", "date_modified": "2026-09-01T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-transaction-cost-calculator", "content_html": "\n

아파트 매매를 검토할 때 가장 먼저 보는 숫자는 매매가격입니다. 하지만 실제로 준비해야 하는 돈은 매매가격과 다를 수 있습니다. 매수할 때는 취득세와 중개보수 같은 비용이 더해지고, 매도할 때는 양도소득세와 중개보수 등이 빠지기 때문입니다.

\n

그래서 같은 아파트의 같은 가격을 보더라도 질문은 두 가지로 나누어야 합니다.

\n

매수한다면 현금이 얼마나 더 필요한가
매도한다면 최종적으로 얼마를 받을 수 있는가

\n

이 글에서는 이 두 질문을 분리해서 거래비용을 계산하는 방법과, 아파트 인사이트의 거래비용 계산기가 어떤 방식으로 결과를 보여주는지 정리합니다. 세율과 감면 요건은 거래일·자산 상태·가구 조건에 따라 달라질 수 있으므로, 특정 금액을 확정하기보다 계산 결과를 자금 계획을 위한 참고값으로 읽는 데 초점을 둡니다.

\n

거래비용은 가격 예측과 다른 숫자다

\n

가격 예측은 앞으로의 가격 경로를 추정하는 일이고, 거래비용 계산은 그 가격으로 실제 거래할 때 발생할 현금흐름을 가늠하는 일입니다. 둘을 한 숫자로 섞으면 “가격이 올랐다”와 “필요한 현금이 늘었다”를 혼동하기 쉽습니다.

\n

거래 방향에 따라 결과의 의미도 달라집니다.

\n

거래 방향	계산에 더하거나 빼는 항목	결과를 읽는 기준
매수	취득 관련 세금, 중개보수, 선택한 기타 비용	총 필요자금
매도	양도소득세, 지방소득세, 중개보수, 선택한 기타 비용	예상 순수령액

\n

시뮬레이션에서는 거래비용을 A안·B안의 최종 금액에 반영합니다. 매수의 + 보정은 예측가격이 상승했다는 뜻이 아니라, 거래를 위해 준비할 현금이 늘었다는 뜻입니다. 반대로 매도 결과의 음수 보정은 세금과 비용을 차감한 뒤 예상 순수령액이 줄어드는 구조를 나타냅니다.

\n

다만 모든 화면이 같은 기준을 쓰는 것은 아닙니다. 현재 가격과 비교하는 카드는 가격 자체의 변화를 보여주는 자리이므로 거래비용을 제외한 가격 기준을 유지하고, 확률 분포 역시 거래비용 반영 전 예측으로 표시합니다. 이 범위를 분리해야 가격 전망과 현금 계획을 서로 다른 질문으로 읽을 수 있습니다.

\n

기능은 어디에서 시작할까

\n

시뮬레이션의 가중 팩터 모델 영역에서 거래비용 버튼을 누르면 매수 또는 매도 한 방향을 선택해 조건을 입력할 수 있습니다. 적용 후에는 A안·B안 각각에 맞춘 거래비용 보정 카드가 추가됩니다.

\n

$\"시뮬레이션$

\n

화면의 보정 카드에서 확인할 수 있는 핵심은 세 가지입니다.

\n

거래 방향이 매수인지 매도인지
비용이 가격 예측이 아니라 총 필요자금 또는 예상 순수령액 기준인지
어떤 정책 기준일과 입력 조건으로 계산했는지

\n

거래비용 계산은 현재 시뮬레이션 화면의 조건을 바탕으로 동작합니다. 계산 결과가 과거 예측 이력이나 공유 결과에 그대로 저장되는 방식이 아니므로, 다른 조건을 비교할 때는 해당 조건을 다시 입력해 확인해야 합니다.

\n

매수: 예측가에 비용을 더해 총 필요자금 보기

\n

매수 쪽 계산은 다음과 같은 구조로 이해하면 쉽습니다.

\n

총 필요자금
= 매수 기준금액
+ 취득세 관련 비용
+ 중개보수
+ 선택한 기타 비용

\n

취득 관련 비용

\n

주택 매수에서는 취득세를 중심으로 지방교육세와 농어촌특별세가 함께 검토될 수 있습니다. 실제 적용 여부와 금액은 취득가액, 주택 보유 수, 조정대상지역 여부, 주택의 전용면적, 거래 형태 등에 따라 달라집니다.

\n

계산기에서는 일반 아파트 매매와 분양권 거래 조건을 구분하고, 주택 보유 수가 여러 채인 경우에는 중과 적용 여부를 별도로 확인합니다. 필요한 조건을 선택하지 않은 상태에서 임의의 세율을 적용하지 않고 계산 보류로 두는 이유도 여기에 있습니다.

\n

전용면적은 농어촌특별세 적용 여부를 판단하는 입력으로 사용됩니다. 단지 대표 면적을 참고값으로 채우더라도 사용자가 실제 계약 면적으로 수정할 수 있어야 하며, 면적이 표시되었다고 해서 다른 세금 요건까지 자동으로 확정되는 것은 아닙니다.

\n

중개보수와 기타 비용

\n

중개보수는 법정 상한요율을 기준으로 한 참고값입니다. 실제 보수는 지역 조례와 거래금액 구간, 중개의뢰인과 중개사 사이의 협의에 따라 달라질 수 있고 부가가치세가 별도로 붙을 수 있습니다. 따라서 계산기에서 중개보수를 포함하더라도 계약 전에는 중개사에게 실제 협의 금액을 확인해야 합니다.

\n

기타 비용은 법정 비용으로 단정하지 않고 사용자가 직접 입력하는 참고 항목으로 보는 편이 안전합니다. 법무사 비용, 인지대, 이사비, 대출 관련 비용처럼 거래 구조에 따라 달라지는 항목은 계약 조건과 금융기관 안내를 따로 확인해야 합니다.

\n

매도: 세금과 비용을 빼고 예상 순수령액 보기

\n

매도 쪽은 매수와 반대 방향으로 계산합니다.

\n

예상 순수령액
= 매도 기준금액
- 양도소득세
- 지방소득세
- 중개보수
- 선택한 기타 비용

\n

양도소득세는 단순히 “현재 가격과 미래 가격의 차이”만으로 결정되지 않습니다. 취득가액과 필요경비, 취득일과 양도일, 보유기간, 거주기간, 자산 상태, 주택 보유 수, 비과세·중과 요건 등을 함께 봐야 합니다.

\n

특히 A안과 B안의 목표 시점이 서로 다르면 보유개월과 거주기간도 달라집니다. 한 시나리오에서는 장기 보유 요건을 충족하고 다른 시나리오에서는 단기 세율이 적용되는 것처럼, 두 안의 세율 체계가 달라질 수 있습니다. 이럴 때 두 결과에 같은 비율을 적용하면 계산은 간단해 보여도 조건을 제대로 반영하지 못합니다.

\n

양도차손처럼 과세할 양도소득이 없는 경우에는 납부 세액이 0원으로 표시될 수 있습니다. 0원이 표시되었다고 해서 모든 신고 의무나 계약 관련 비용이 사라지는 것은 아니므로, 실제 신고와 비용 확인은 별도로 진행해야 합니다.

\n

입력 다이얼로그에서는 무엇을 확인할까

\n

$\"거래비용$

\n

입력 화면은 항목을 많이 채우는 것보다 계산 기준이 무엇인지 확인하는 것이 중요합니다.

\n

1. 매수와 매도 방향을 먼저 고르기

\n

매수와 매도 비용은 서로 다른 세금과 결과 표현을 사용합니다. 한 방향을 적용한 뒤 반대 방향으로 바꾸면 이전 거래비용 상태를 이어 붙이지 않고 새 조건으로 다시 계산하는 흐름이 안전합니다.

\n

2. 기준일과 금액을 실제 계약 조건에 맞추기

\n

취득가액, 취득일, 양도 예정일, 매수 예정일, 주택 보유 수 같은 입력은 세율 체계와 기간 요건에 영향을 줍니다. 빈 값을 0원이나 임의의 날짜로 채워 계산하는 것보다, 필요한 값이 없으면 계산을 멈추고 추가 입력을 요청하는 편이 낫습니다.

\n

3. 포함할 부대비용을 선택하기

\n

중개보수와 기타 비용은 체크한 항목만 합계에 들어갑니다. 포함 여부를 바꾸면 A안·B안의 보정값도 함께 달라지므로, 결과를 저장하거나 공유하기 전에 체크 상태를 다시 확인해야 합니다.

\n

4. 계산 보류 메시지를 무시하지 않기

\n

다주택 중과 여부를 선택하지 않았거나, 필요한 취득가·취득일이 없거나, 지원하지 않는 감면 특례를 주장하는 경우에는 정확한 금액 대신 계산 보류가 표시될 수 있습니다. 이것은 오류라기보다 근거가 부족한 숫자를 확정값처럼 보여주지 않기 위한 안전장치입니다.

\n

분양권은 일반 아파트 매매와 따로 봐야 한다

\n

분양권 거래에서는 분양가와 현재 거래금액이 같은 의미가 아닙니다. 기준 분양가에 기납부금, 옵션비, 프리미엄 또는 마이너스 프리미엄을 반영해 실제 거래금액을 구성해야 합니다.

\n

마피와 플러스피

\n

마이너스 피는 기준 분양가에서 프리미엄을 차감하는 구조이고, 플러스 피는 프리미엄을 더하는 구조입니다. 다만 마피 차감액만으로 매수 총액이 완성되는 것은 아닙니다. 중도금 미납분, 이자후불제 승계, 옵션·확장비 등은 별도로 확인해야 합니다.

\n

손피는 별도 계산이 필요하다

\n

손피는 매도자가 세후 프리미엄을 확보하고 매수자가 양도소득세와 지방소득세를 대신 부담하는 특수한 계약 조건입니다. 일반 거래비용 계산에 손피 세액을 섞으면 프리미엄·양도세·취득세의 기준금액이 혼동될 수 있습니다.

\n

1년 미만 70%, 1년 이상 60%의 단기보유 세율과 대납세액 재산입을 포함한 계산은 별도 글에서 자세히 설명하고 있습니다. 분양권 손피 계산기: 프리미엄 3,000만원이면 실제 부담액은?

\n

왜 모든 조건을 계산해 주지 않을까

\n

거래비용 계산기에서 일부 입력은 금액이 나오지 않고 보류됩니다. 대표적인 이유는 다음과 같습니다.

\n

생애 최초·지방 미분양·인구감소지역 등 취득세 감면 특례의 적용 여부가 개인 조건과 법령 해석에 따라 달라지는 경우
다주택 중과와 중과 유예 중 어느 기준을 적용할지 선택하지 않은 경우
취득일이 양도일보다 늦거나, 기준 분양가처럼 핵심 금액이 없는 경우
분양권의 전매제한 해제일과 매수 예정일 관계를 공식 근거로 확인하지 못한 경우

\n

세금 계산에서 가장 위험한 것은 빈칸을 그럴듯한 기본값으로 채워 정확해 보이는 금액을 보여주는 것입니다. 계산 보류는 사용자가 계약 조건과 공식 근거를 먼저 확인하도록 만드는 경계선입니다.

\n

거래비용을 적용한 결과를 읽는 순서

\n

실제 화면에서는 다음 순서로 읽으면 혼동이 적습니다.

\n

기준 예측: 거래비용을 적용하기 전 A안·B안 가격 확인
가격 조건 보정: 시나리오·보유세 등 가격 자체에 영향을 주는 조건 확인
거래비용 계산: 매수 총 필요자금 또는 매도 예상 순수령액 계산
최종 카드 확인: A안·B안별 세금·중개보수·기타 비용과 최종 금액 확인
범위 안내 확인: 현재 대비 카드와 확률 분포는 거래비용을 반영하기 전 가격 기준인지 확인

\n

이 순서를 지키면 “예상가격이 올랐는데 왜 현금 부담도 늘었나”와 같은 질문을 분리해서 볼 수 있습니다. 가격 비교는 가격대로, 자금 계획은 거래비용을 포함한 현금흐름대로 확인하는 것입니다.

\n

계산 전에 준비할 체크리스트

\n

거래 방향: 매수인지 매도인지
기준 금액: 취득가액·양도가액·분양가·프리미엄·기납부금
날짜: 취득일·양도 예정일·매수 예정일·전매제한 해제일
보유 조건: 세대의 주택 수, 보유기간, 거주기간
자산 상태: 등기 후 주택인지 분양권인지
중개보수: 지역 상한요율과 실제 협의 금액
감면·중과 조건: 공식 근거와 전문가 확인 여부
계산 기준일: 세법과 조례가 언제 기준인지

\n

자주 묻는 질문 (FAQ)

\n

Q. 아파트 매수 시 발생하는 주요 거래비용은 무엇인가요?

\n

매매가격 외에 취득세(지방교육세 및 농어촌특별세 포함), 부동산 중개보수, 국민주택채권 매입/할인비용, 등기 수수료(법무사 보수) 등이 추가로 발생합니다. 주택 수와 취득가액에 따라 취득세율이 1%~12%까지 달라집니다.

\n

Q. 아파트 매도 후 실제로 받는 돈(순수령액)은 어떻게 계산하나요?

\n

매도가격에서 기존 취득가액과 필요경비를 차감한 양도차익에 장기보유특별공제와 기본공제(250만원)를 적용한 과세표준을 구하고, 해당 세율을 곱한 양도소득세(지방소득세 포함)와 중개보수를 제외하면 실제 순수령액이 됩니다.

\n

Q. 아파트 거래비용 계산기와 시세 예측의 차이점은 무엇인가요?

\n

시세 예측은 해당 아파트의 미래 가격 범위를 추정하는 지표이며, 거래비용 계산기는 해당 가격으로 실제 계약할 때 필요한 추가 현금(매수 총 필요자금) 또는 세후 입금액(매도 순수령액)을 파악하는 도구입니다.

\n

참고할 공식 자료

\n

국세청 양도소득세 개요: 양도소득세의 과세 구조와 기본 개념을 확인할 수 있습니다.
국세청 양도소득세 세율 안내: 과세표준별 기본세율과 세율 변동 자료를 확인할 수 있습니다.
국가법령정보센터 지방세법: 취득세를 포함한 지방세 관련 현행 법령을 확인할 수 있습니다.
서울특별시 부동산 중개보수 요율표: 주택·분양권 중개보수의 상한요율과 적용 기준을 확인할 수 있습니다.

\n

공식 자료의 세율과 요건은 개정될 수 있습니다. 따라서 계산기에서 표시하는 정책 기준일을 확인하고, 실제 계약·신고 단계에서는 관할 지방자치단체, 국세청, 중개사, 세무 전문가의 최신 안내를 다시 확인하는 것이 좋습니다.

\n

거래비용 계산은 가격 전망과 별도로 실제 현금흐름을 확인하기 위한 참고 과정입니다. 취득세·양도소득세·중개보수의 기준금액과 적용 조건을 나누어 확인하면, 같은 가격이라도 매수에 필요한 자금과 매도 후 순수령액이 왜 달라지는지 더 정확하게 비교할 수 있습니다.

\n

\n
이 글과 계산 결과는 공개된 정책 기준과 입력 조건에 따른 참고용 정보입니다. 실제 세액·중개보수·신고금액·거래 가능 여부를 보장하지 않으며, 투자 권유나 매수·매도 추천이 아닙니다. 최종 계약과 신고 전에는 최신 공식 자료와 전문가 의견을 확인하세요.
\n

", "url": "https://alvin.ing/blog/apartment-transaction-cost-calculator", "title": "아파트 거래비용 계산: 취득세·양도세·중개보수까지", "summary": "아파트 매수·매도 때 필요한 실제 자금을 취득세·양도소득세·중개보수로 나눠 계산하고, 거래비용 계산기 결과를 읽는 방법을 정리합니다.", "date_modified": "2026-08-07T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "금융·세금" ] }, { "id": "https://alvin.ing/blog/sonpi-tax-calculator", "content_html": "\n

분양권 거래에서 “프리미엄 3,000만원”이라는 말만 보고 매수자 부담액을 판단하면 실제 준비해야 할 금액을 놓치기 쉽습니다. 손피 계약에서는 매도자가 손에 남길 프리미엄을 정하고, 매수자가 매도자의 양도소득세와 지방소득세를 대신 부담하기 때문입니다.

\n

이 글에서는 손피가 일반적인 프리미엄 거래와 어떻게 다른지 설명하고, 1년 미만·1년 이상 보유기간과 세금 재산입을 반영한 계산기를 함께 제공합니다.

\n

손피 계산기부터 확인하기

\n

매도자 취득원가와 손에 남길 프리미엄, 인정 필요경비를 입력한 뒤 보유기간을 바꿔보세요. 기본값은 프리미엄 3,000만원·분양권 보유 1년 미만입니다.

\n

SONPI TAX CALCULATOR

손에 남길 프리미엄을 입력해보세요

매도자의 양도세를 매수자가 대신 내는 경우, 대납세액을 다시 양도가액에 넣어 반복 계산합니다.

고정점 계산

빠른 예시

매도자 취득원가분양가·기납부금 등

억원

손에 남길 프리미엄세금 대납 전 기준

만원

이 데모에서는 세금 대납 전 양도가액을 ‘취득원가 + 프리미엄’으로 단순화합니다.

분양권 보유기간양도일 기준

인정 필요경비계약서·증빙 확인

만원

기본공제 250만원은 자동 반영합니다.

매수자 부담 중도금 이자계약상 확정 정산액

만원

손피 세금에는 포함하지 않고, 매수자 필요자금에서 차감합니다.

매수자가 준비할 프리미엄 관련 순자금

1억 2,207만원

프리미엄 3,000만원 + 대납세액 9,207만원 + 중도금 이자 0만원

결합 세율77%국세 70% + 지방소득세 7%

1차 계산2,118만원대납세액을 아직 재산입하지 않은 값

반복 횟수64회1원 이내로 수렴

계산 결과

세금 대납 전 신고금액12억 3,000만원

양도소득세8,370만원

지방소득세837만원

매수자 대납세액9,207만원

매수자 부담 중도금 이자0만원

매수자 프리미엄 관련 필요자금1억 2,207만원

대납세액 포함 신고금액13억 2,207만원

왜 이렇게 계산되나요?

92,065,209원를 양도가액에 더한 뒤 다시 계산하고, 직전 결과와 1원 이내로 같아질 때까지 반복했습니다.

분양권의 실제 세율·필요경비·신고금액은 거래일, 자산 상태, 계약 내용과 법령 해석에 따라 달라질 수 있습니다. 이 데모는 손피의 고정점 구조를 이해하기 위한 참고 계산입니다.

\n

이 데모는 세금 대납 전 양도가액을 매도자 취득원가 + 프리미엄으로 단순화합니다. 실제 계약에서는 취득일·양도일·기납부금·옵션비·필요경비·자산 상태를 별도로 확인해야 합니다.

\n

계산기에 입력하는 금액의 의미

\n

손피 계산에서 가장 자주 섞이는 숫자는 분양가, 양도가액, 프리미엄입니다. 계산기는 다음처럼 역할을 나누어 사용합니다.

\n

입력값	계산에서의 의미	확인할 자료
매도자 취득원가	매도자가 분양권을 취득하는 데 실제로 부담한 기준금액	분양계약서, 납부내역, 옵션·확장 계약서
손에 남길 프리미엄	세금을 납부한 뒤 매도자에게 남기려는 금액	매매계약서 특약, 협의한 프리미엄
인정 필요경비	양도차익에서 차감할 수 있다고 확인된 비용	영수증, 세금계산서, 계약 관련 증빙
보유기간	매도자의 취득일과 양도일 사이의 실제 경과기간	취득일·양도일 증빙
매수자 부담 중도금 이자	손피 세금과 별도로 매수자 필요자금에 더하는 금액	이자후불제 약정, 정산서, 계약 특약

\n

이 글의 데모에서는 세금 대납 전 양도가액 = 매도자 취득원가 + 손에 남길 프리미엄으로 계산합니다. 따라서 취득원가를 바꾸면 세금 대납 전 신고금액은 달라지지만, 취득원가와 양도가액을 같은 폭으로 바꾼다는 단순화 가정에서는 프리미엄에 대한 양도차익 자체는 그대로입니다.

\n

취득원가에 포함되는 금액은 거래마다 달라질 수 있습니다. 기납부금·옵션비·확장비·중도금 이자·승계금액을 분양가와 같은 숫자로 묶으면 실제 양도차익과 신고금액이 어긋날 수 있으므로, 계약서와 납부내역을 나누어 확인해야 합니다.

\n

손피란 무엇인가

\n

손피는 ‘손에 남는 프리미엄’이라는 뜻입니다. 매도자가 세금을 납부한 뒤에도 약속한 프리미엄을 확보하도록 매수자가 매도자의 양도소득세와 지방소득세를 대신 부담하는 계약 조건을 가리킵니다.

\n

일반적인 분양권 거래라면 프리미엄과 세금을 따로 보면 되지만, 손피에서는 매수자가 대신 낸 세금이 매도자에게 귀속되는 양도가액의 일부로 다시 계산될 수 있습니다. 그래서 프리미엄 × 세율 한 번으로 끝나지 않습니다.

\n

1년 미만이면 왜 금액이 급격히 커질까

\n

분양권은 보유기간에 따라 단기보유 세율을 적용합니다. **1년 미만 70%, 1년 이상 60%**라는 구분은 다주택 중과 가산세율이 아니라 분양권의 단기보유 세율입니다. 관련 세율 구조는 소득세법 제104조 현행 조문에서 확인할 수 있습니다.

\n

계산기에서는 양도소득세에 지방소득세를 함께 반영합니다.

\n

분양권 1년 미만: 양도소득세 70% + 지방소득세(양도소득세의 10%) = 과세표준의 약 77%
분양권 1년 이상: 양도소득세 60% + 지방소득세(양도소득세의 10%) = 과세표준의 약 66%

\n

이 비율은 프리미엄 전체에 바로 곱하는 값이 아닙니다. 인정 필요경비와 기본공제 250만원을 차감한 과세표준에 적용하며, 실제 계산에서는 원 단위 절사와 양도일 기준 보유기간 판정이 함께 들어갑니다.

\n

1년 경계는 하루 단위로 확인해야 한다

\n

“1년 정도 보유했다”는 표현만으로는 세율을 정할 수 없습니다. 예를 들어 취득일이 2026년 1월 15일이라면 다음처럼 달라집니다.

\n

취득일	양도일	완전 경과기간	적용 구분
2026-01-15	2027-01-14	12개월 미만	1년 미만, 70%
2026-01-15	2027-01-15	12개월	1년 이상, 60%

\n

계약일과 잔금일, 명의변경일 중 어느 날짜가 세법상 취득일·양도일이 되는지는 거래 구조에 따라 확인이 필요합니다. 계산기에서 날짜를 임의로 1년 뒤로 입력하기보다 실제 증빙에 맞춰 입력해야 하는 이유입니다.

\n

세금 위에 다시 세금이 붙는 구조

\n

손피의 핵심은 매수자가 대신 낸 세액을 양도가액에 다시 넣는 것입니다. 국세청도 2024년 11월 손피거래 관련 보도자료에서 매수자가 부담한 양도소득세 전액을 양도가액에 합산해 재계산하는 해석을 안내했습니다. 국세청 손피거래·다운거래 보도자료

\n

대납세액을 T라고 하면 단순화한 고정점 식은 다음과 같습니다.

\n

T = 적용세율 × (실질 양도가액 + T - 매도자 취득원가 - 인정 필요경비 - 기본공제)

\n

우변에 다시 T가 들어 있으므로 계산기는 다음 순서로 반복합니다.

\n

대납세액을 0원으로 두고 1차 세액을 계산합니다.
1차 세액을 양도가액에 더해 다시 세액을 계산합니다.
직전 결과와 1원 이내로 같아질 때까지 반복합니다.

\n

세율 구간을 오르내리거나 필수 입력이 없으면 숫자를 임의로 확정하지 않고 계산 보류로 두는 편이 안전합니다.

\n

반복 계산은 이렇게 진행된다

\n

프리미엄 3,000만원, 필요경비 0원, 기본공제 250만원, 1년 미만을 단순화하면 결합세율은 약 77%입니다. 첫 계산 이후의 대납세액을 다시 양도가액에 넣으면 다음과 같은 흐름이 됩니다.

\n

반복 단계	직전 대납세액	다시 계산한 대납세액
1차	0원	약 2,117만5,000원
2차	약 2,117만5,000원	약 3,748만원
3차	약 3,748만원	약 5,003만원
수렴	직전 세액을 계속 재산입	약 9,207만원

\n

이 표의 1차·2차·3차 숫자는 설명을 위한 반올림값입니다. 실제 계산기는 원 단위 절사 후 직전 결과와 1원 이내로 같아지는 시점까지 반복합니다.

\n

프리미엄 3,000만원이면 실제로 얼마인가

\n

다음 조건을 가정해보겠습니다.

\n

손에 남길 프리미엄: 3,000만원
보유기간: 1년 미만
인정 필요경비: 0원
기본공제: 250만원
다른 감면·중과·신고 이슈는 제외

\n

1차 계산에서는 과세표준이 3,000만원 - 250만원 = 2,750만원입니다. 양도소득세와 지방소득세를 합치면 약 2,117만5,000원이고, 프리미엄과 합친 금액은 약 5,117만5,000원입니다.

\n

하지만 이 2,117만5,000원을 다시 양도가액에 넣으면 세액은 더 커집니다. 반복 계산이 수렴하면 대납세액은 약 9,207만원, 프리미엄과 합친 매수자 부담액은 약 1억 2,207만원 수준이 됩니다.

\n

1년 이상 보유로 바꾸면 결합세율이 약 66%가 되어 같은 단순화 조건의 대납세액은 약 5,338만원, 프리미엄과 합친 금액은 약 8,338만원 수준으로 내려갑니다. 따라서 1년 경계는 단순히 세율 10%포인트 차이가 아니라, 대납세액이 다시 과세표준에 들어가는 반복 구조 전체를 바꾸는 기준입니다.

\n

분양권과 등기 후 주택은 같은 계산기로 보면 안 된다

\n

이 글의 핵심 예시는 분양권입니다. 분양권은 보유기간에 따른 단기세율을 중심으로 계산하고, 일반적인 1세대 1주택 비과세나 장기보유특별공제를 그대로 적용하지 않습니다.

\n

반면 등기 후 주택은 보유기간 외에도 세대의 주택 수, 조정대상지역 여부, 다주택 중과 적용 여부, 거주기간과 비과세 요건이 함께 들어갑니다. 등기 후 주택을 손피로 거래한다면 분양권용 70%·60%만 대입해서는 안 되고, 별도의 양도소득세 조건을 다시 확인해야 합니다.

\n

아파트 인사이트의 거래비용 계산기에서도 자산 상태에 따라 필요한 입력과 계산 보류 조건을 다르게 둡니다. 이 글의 계산기는 분양권 손피 구조를 이해하기 위한 전용 참고값으로 보는 것이 안전합니다.

\n

국세청의 12억 취득·17억 양도 예시

\n

국세청이 공개한 예시는 분양권을 12억원에 취득해 17억원에 양도하는 상황입니다. 1년 이상 보유한 분양권의 일반 양도에서는 양도차익 5억원에서 기본공제를 뺀 금액에 60%와 지방소득세를 반영해 약 3억2,800만원의 세금이 계산됩니다.

\n

손피로 매수자가 이 세금을 부담하면 대납액이 양도가액에 들어가고, 다시 계산된 세금도 양도가액에 포함됩니다. 이 과정을 전액 부담 기준으로 반복하면 매수자가 부담할 양도소득세와 지방소득세가 약 9억6,600만원까지 커질 수 있습니다. 이 사례는 모든 손피 거래의 견적이 아니라, 대납세액 재산입이 누적될 때 금액이 얼마나 커질 수 있는지를 보여주는 공식 예시입니다.

\n

계산기 상단의 국세청 12억 → 17억 버튼을 누르면 이 구조를 직접 확인할 수 있습니다.

\n

손피 세액과 취득세·중개보수는 별도다

\n

손피 대납세액은 매도자 양도소득세와 지방소득세를 매수자가 대신 부담하는 금액입니다. 취득세, 지방교육세, 농어촌특별세, 중개보수, 중도금 이자, 옵션·확장비까지 자동으로 포함한 총액이 아닙니다.

\n

아파트 인사이트의 거래비용 계산기에서는 분양가와 프리미엄을 기준으로 취득 관련 비용과 중개보수를 별도로 계산하고, 손피 대납세액을 별도 항목으로 더해 보여주는 흐름을 사용합니다. 대납세액을 취득세 과세표준에 다시 넣을지는 거래 형태와 해석에 따라 확인이 필요한 영역이므로, 계산기에서 확인되지 않은 비용을 임의로 중복하지 않습니다.

\n

중도금 이자는 일반적인 손피 계약에서 매수자가 함께 부담하는 경우가 많습니다. 그래서 이 글의 계산기에서는 중도금 이자를 손피 양도세 고정점에는 넣지 않고, 대납세액과 별도의 매수자 필요자금으로 더합니다. 이자후불제 약정, 이미 납부한 이자, 앞으로 승계할 이자, 매도자와의 정산액을 구분해서 입력해야 합니다.

\n

자주 묻는 질문

\n

프리미엄 3,000만원이면 5,000만원만 준비하면 되나요?

\n

1차 세액만 더하면 약 5,118만원이지만, 손피의 대납세액 재산입까지 반영하면 단순화한 예시에서는 약 1억 2,207만원까지 올라갑니다. 5,000만원대는 최종 수렴값이 아니라 첫 번째 계산에 가깝습니다.

\n

중도금 이자는 손피 세금에 합산하나요?

\n

아닙니다. 매수자가 부담하는 중도금 이자는 매도자 양도세의 과세표준에 다시 넣는 손피 대납세액과 별개의 현금 지출입니다. 계산기에서는 대납세액을 먼저 고정점으로 계산한 뒤, 중도금 이자를 매수자 필요자금에 더합니다. 매도자가 이자를 부담하기로 한 경우에는 별도 정산액으로 차감하는 방식으로 계약 내용을 다시 확인해야 합니다.

\n

70%는 다주택자 중과세율인가요?

\n

아닙니다. 이 글에서 설명하는 70%는 보유기간 1년 미만 분양권에 적용되는 단기보유 세율입니다. 다주택 중과는 주택의 자산 상태와 조정대상지역, 세대의 주택 수 등 별도 요건을 검토합니다.

\n

마이너스 피도 같은 방식으로 계산하나요?

\n

마이너스 피는 손에 남길 양도차익이 발생하는 플러스 프리미엄과 구조가 다릅니다. 매수자가 매도자의 양도세를 대납하는 손피 고정점 계산의 대상인지 먼저 확인하고, 기준 분양가에서 차감되는 거래금액·미납금·이자·옵션비를 별도로 정리해야 합니다.

\n

계산기 결과가 보류되면 무엇을 확인해야 하나요?

\n

매도자 취득원가, 취득일, 양도일, 전매제한 해제일, 실제 거래 가능 여부처럼 결과를 바꾸는 핵심 근거가 빠졌는지 확인합니다. 전매제한이 확인되지 않은 상태에서 세액만 계산하면 거래가 불가능한 계약을 숫자로 포장할 수 있으므로, 계산 보류가 정상적인 안내일 수 있습니다.

\n

계약 전에 따로 확인할 것

\n

손피 계산기 결과만으로 계약을 진행해서는 안 됩니다. 다음 항목은 계산기 입력과 별도로 확인해야 합니다.

\n

기준 분양가와 프리미엄을 합한 세금 대납 전 실제 거래금액
매도자의 실제 취득원가와 증빙 가능한 필요경비
매도자 취득일과 거래 예정일
분양권인지 등기 후 주택인지에 대한 자산 상태
양도세를 매수자가 부담한다는 계약 특약
전매제한 해제일과 실제 거래 가능 여부
대납세액을 포함한 계약서·실거래 신고금액

\n

손피 자체를 단순히 불법이라고 단정할 수는 없지만, 대납 세액을 제외한 금액으로 실거래를 신고하면 다운계약 문제가 생길 수 있습니다. 실제 계약과 신고 전에는 최신 공식 자료와 세무 전문가의 확인이 필요합니다.

\n

아파트 인사이트에서 실제 조건으로 확인하기

\n

아파트 인사이트에서는 단지 시뮬레이션의 거래비용 계산기에서 분양권 거래 조건을 따로 입력할 수 있습니다. 현재 분양권 전매가 가능한 신축 아파트처럼 전매제한 해제일과 매수 예정일을 확인할 수 있는 경우에는 거래비용 계산기에서 분양권 계산기가 활성화되어 기준 분양가·프리미엄·손피 대납세액을 함께 검토할 수 있습니다.

\n

전매제한 해제일이 확인되지 않거나 매수 예정일이 제한기간 안이면 금액을 억지로 확정하지 않고 거래 가능 여부 확인이 필요한 상태로 표시합니다. 계산기에서 분양권 조건을 먼저 확인한 뒤, 이 글의 손피 계산기로 대납세액이 어떻게 누적되는지 이어서 비교하면 됩니다.

\n

이 글은 먼저 발행한 아파트 매수·매도 거래비용 계산 가이드의 분양권·손피 내용을 분리해 확장한 글입니다. 전체 거래비용의 구조는 이전 글에서, 손피의 고정점 계산은 이 글에서 확인할 수 있습니다.

\n

공신력 있는 참고자료

\n

세율과 신고 기준은 개정될 수 있으므로, 아래 원문을 기준으로 거래일에 적용되는 내용을 다시 확인해야 합니다.

\n

국가법령정보센터 소득세법 제104조: 분양권의 1년 미만 70%, 1년 이상 60% 세율 근거
국세청 손피거래·다운거래 관련 보도자료: 대납세액을 양도가액에 포함하는 해석과 실제 거래금액 신고 안내
국세청 양도소득세 개요: 양도소득세의 과세 구조와 신고 기본 안내
국세청 양도소득세율 안내 PDF: 자산 종류·보유기간별 세율표
국가법령정보센터 지방세법: 지방소득세와 취득 관련 지방세 법령 확인

\n

자주 묻는 질문 (FAQ)

\n

Q. 분양권 손피(손에 남는 프리미엄) 거래란 무엇인가요?

\n

손피 거래란 매도자가 양도소득세 등을 납부한 뒤 온전히 손에 쥐는 프리미엄 금액을 확정하고, 매도자가 부담해야 할 양도소득세와 지방소득세를 매수자가 대신 납부(대납)해 주는 분양권 거래 방식입니다.

\n

Q. 분양권 단기 양도소득세율은 얼마인가요?

\n

현행 세법상 분양권의 양도소득세율은 보유기간 1년 미만 시 70%(지방소득세 포함 약 77%), 1년 이상 보유 시 60%(지방소득세 포함 약 66%)의 중과 단일세율이 적용됩니다.

\n

Q. 손피 계산 시 매수자가 대납한 세금을 왜 다시 양도가액에 합산(재산입)하나요?

\n

세법상 매수자가 매도자의 양도소득세를 대신 부담하기로 약정한 경우, 대신 낸 1차 세금 또한 매도자의 실질적인 양도가액(경제적 이익)으로 보아 양도차익에 재산입되어 2차 세금이 계산되기 때문입니다.

\n

함께 읽을 글

\n

아파트 매수·매도 거래비용 계산 가이드

\n

\n
이 글과 계산 결과는 공개된 정책 기준과 입력 조건에 따른 참고용 정보입니다. 실제 세액·신고금액·거래 가능 여부를 보장하지 않으며, 투자 권유나 매수·매도 추천이 아닙니다. 최종 계약과 신고 전에는 최신 공식 자료와 전문가 의견을 확인하세요.
\n

", "url": "https://alvin.ing/blog/sonpi-tax-calculator", "title": "분양권 손피 계산기: 프리미엄 3,000만원이면 실제 부담액은?", "summary": "분양권 손피 거래의 실제 매수자 부담액을 1년 미만 70%·1년 이상 60% 세율, 대납세액 재산입, 중도금 이자까지 반영해 계산하는 방법을 정리합니다.", "date_modified": "2026-08-07T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "금융·세금" ] }, { "id": "https://alvin.ing/blog/83-real-estate-tax-reform-calculator", "content_html": "\n

2026년 8월 3일 발표된 부동산 세제개편안은 같은 아파트를 보유하더라도 실거주인지, 여러 채를 보유하는지, 공시가격이 어느 구간인지에 따라 결과가 달라지도록 설계되어 있습니다.

\n

그래서 이번 글은 정책 요약만 하지 않습니다. 공시가격과 보유 조건을 직접 입력해 현행 세법, 2027년 중간 단계, 2028년 본격 시행안을 비교해볼 수 있는 계산기를 함께 준비했습니다.

\n

먼저 계산해보기

\n

아래 계산기는 시세나 호가가 아니라 세금 계산의 출발점인 공시가격을 입력받습니다. 결과는 정책안의 구조를 이해하기 위한 연간 추정치이며, 실제 고지서의 확정 세액을 대신하지 않습니다.

\n

PUBLIC POLICY CALCULATOR

내 조건으로 보유세 차이를 비교해보세요

공시가격과 보유 조건을 입력하면 2026년 현행 기준과 8.3 정부안 기준의 연간 보유세를 같은 조건에서 비교합니다.

8.3 정부안

계산 기준현재안과 단계별 정부안을 비교

대상 아파트 공시가격시세가 아닌 공시가격 기준

억원

국토부 실거래가나 호가가 아니라, 세금 계산에 쓰이는 공시가격을 입력하세요.

보유 주택 수대상 아파트를 포함해 입력

명의 형태부부 공동명의 세액 최적 판정

부부 공동명의는 인별 9억 공제(총 18억)와 1주택 특례 중 세액이 작은 최적안을 자동 산출합니다.

실거주 주택거주기간 공제와 주택 비중에 반영

만 나이

세

보유기간

년

거주기간

년

도시지역분 포함기본값은 포함입니다.

전년도 보유세세부담 상한을 적용할 때만 입력

만원

ESTIMATE RESULT

2028년 정부안 본격 시행

연간 추정

예상 연간 보유세672만원재산세·종합부동산세·부가세 포함 추정치

현행 세법 기준710만원

선택 기준과의 차이−37만원

세목별 구성20억원 합산

재산세297만원

도시지역분126만원

지방교육세59만원

종합부동산세158만원

농어촌특별세32만원

이번 결과가 만들어진 과정공개 정책 기준

01
합산 공시가격 20억원에서 기본공제 14억원를 뺍니다.
02
남은 금액에 공정시장가액비율 70%을 적용해 과세표준 4.2억원을 구합니다.
03
과세표준에 누진 세율을 적용하고 재산세 공제·세액공제를 반영합니다.
04
전년도 세액을 입력했다면 세부담 상한을 적용합니다.

계산 결과를 읽는 법

이 계산기는 공개된 정부안과 일반적인 세목 구조를 바탕으로 한 콘텐츠용 추정치입니다. 공동명의, 특례주택, 지방세 감면, 실제 공시가격 확정값과 고지 방식에 따라 실제 세액은 달라질 수 있습니다. 정부안은 국회 심의와 하위법령 과정에서 바뀔 수 있으므로 계약·신고 전에는 원문과 세무 전문가의 확인이 필요합니다.

\n

8.3 개편안에서 가장 중요한 변화는 ‘누구에게 적용되는가’입니다

\n

이번 개편안을 단순히 “세금이 오른다” 또는 “세금이 내려간다”로 요약하면 실제 조건을 놓치게 됩니다. 정부의 공식 FAQ는 크게 네 가지 대상을 나눠 설명합니다.

\n

1. 거주하는 1주택은 최대한 보호

\n

거주용 1주택은 공시가격 14억 원까지 종합부동산세 과세 대상에서 제외하는 방향입니다. 공식 문답에서는 시가 약 20억 원 수준을 공시가격 14억 원 수준으로 환산해 설명하고 있습니다.

\n

다만 “1주택이면 언제나 같은 혜택”이라는 뜻은 아닙니다. 일정 금액을 넘는 고가 주택은 별도의 세액공제 한도와 주택가액 기준을 적용하고, 실제 거주기간과 고령 여부 같은 조건도 결과에 영향을 줍니다.

\n

계산기에서 만 나이·보유기간·거주기간을 따로 입력하게 한 이유가 여기에 있습니다. 같은 공시가격이라도 어떤 조건을 입력하느냐에 따라 적용되는 공제가 달라질 수 있습니다.

\n

2. 비거주 1주택은 거주용 1주택과 분리

\n

보유하고 있지만 거주하지 않는 주택은 거주용 1주택과 동일한 방식으로 볼 수 없습니다. 정부안은 비거주 1주택에 대해 기본공제를 9억 원으로 두는 방향을 제시하고 있습니다.

\n

이 차이는 계산의 첫 단계에서 생깁니다. 세율을 적용하기 전, 공시가격에서 빼는 기본공제가 달라지기 때문입니다. 아래의 간단한 식을 보면 왜 공시가격이 과세표준으로 바로 이어지지 않는지 알 수 있습니다.

\n

과세표준
= (주택별 공시가격 합계 - 조건별 기본공제) × 공정시장가액비율

\n

계산기 결과의 “이번 결과가 만들어진 과정”에서 이 값들을 단계별로 확인할 수 있습니다.

\n

3. 다주택은 주택 수와 거주 주택의 비중을 함께 봄

\n

다주택자 계산에서는 단순히 공시가격을 모두 더하는 것만으로 충분하지 않습니다. 정부안은 다주택의 기본공제를 4억 원에 거주 주택의 공시가격 비중을 반영하는 방식으로 설계하고 있습니다.

\n

예를 들어 여러 주택 중 한 채에 거주한다면, 그 주택이 전체 공시가격에서 차지하는 비중이 계산에 들어갑니다. 그래서 계산기에서 “실거주 주택”을 대상 아파트 또는 다른 주택 중 하나로 선택하도록 했습니다.

\n

또 2028년 본격 시행 기준에서는 3채 이상 보유하거나 조정대상지역 주택이 포함되는지에 따라 공정시장가액비율이 달라질 수 있습니다. 이 조건을 모르면 같은 주택 수와 같은 합산 가격을 입력해도 결과를 잘못 읽을 수 있습니다.

\n

4. 바로 한 번에 바뀌지 않고 단계적으로 적용

\n

정부안은 시장과 납세자의 적응을 고려해 종합부동산세를 2년에 걸쳐 단계적으로 개편하는 방향입니다. 계산기에서는 다음 세 시점을 분리했습니다.

\n

2026년 현행 세법 기준: 현재 적용 중인 기준과 비교하는 기준선
2027년 정부안 중간 단계: 개편이 시작되는 중간 단계
2028년 정부안 본격 시행: 정부안이 제시한 본격 시행 단계

\n

따라서 2028년 결과만 보고 “내년부터 바로 이 금액을 낸다”고 해석하면 안 됩니다. 개정 법률안은 입법예고와 국회 심의, 하위법령 확정 과정을 거치며 내용이 바뀔 수 있습니다.

\n

계산식은 왜 여러 단계로 나뉠까

\n

보유세는 하나의 세율을 공시가격에 곱하는 계산이 아닙니다. 이 계산기는 앱의 보유세 추정 흐름과 같은 순서로 다음 요소를 누적합니다.

\n

1. 공시가격을 합산

\n

대상 아파트와 다른 주택의 공시가격을 합산합니다. 세금 계산에서 사용하는 가격은 실거래가·호가와 다를 수 있으므로, 화면에 표시된 기준연도와 공시가격을 확인해야 합니다.

\n

2. 조건에 맞는 기본공제 적용

\n

1주택인지, 거주 중인지, 여러 채를 보유하는지에 따라 기본공제가 달라집니다. 이 단계에서 과세 대상 여부가 갈립니다. 합산 공시가격이 과세 기준에 미치지 않으면 종합부동산세 과세표준은 0원이 될 수 있습니다.

\n

3. 공정시장가액비율로 과세표준 계산

\n

기본공제를 뺀 금액에 공정시장가액비율을 적용합니다. 이 값이 실제 세율을 곱하는 과세표준입니다.

\n

과세표준 = max(0, 공시가격 합계 - 기본공제) × 공정시장가액비율

\n

4. 누진세율과 재산세 공제 적용

\n

과세표준이 계산되면 구간별 누진세율을 적용합니다. 이후 종합부동산세 계산에서 이미 반영된 재산세 부분을 조정하고, 대상이 되는 경우 1주택 세액공제를 반영합니다.

\n

그래서 계산기에는 종합부동산세만 표시하지 않고 재산세·도시지역분·지방교육세·농어촌특별세를 나눠 보여줍니다. 총액만 보면 정책안 때문에 바뀐 부분과 원래 함께 내는 세목을 구분하기 어렵기 때문입니다.

\n

5. 전년도 세액이 있으면 세부담 상한 확인

\n

전년도 보유세를 입력하면 계산기에 세부담 상한을 반영할 수 있습니다. 전년도 세액을 입력하지 않으면 이 단계는 적용하지 않습니다.

\n

이 입력란을 필수로 만들지 않은 이유도 있습니다. 실제 고지된 전년도 세액을 모르는 상태에서 임의의 숫자를 넣으면 오히려 결과가 부정확해지기 때문입니다.

\n

계산식을 한 줄씩 따라가 보기

\n

계산 결과를 제대로 읽으려면 최종 금액보다 중간 숫자를 먼저 봐야 합니다. 계산기에서 입력값이 바뀔 때마다 실제로 달라지는 부분은 크게 합산 공시가격 → 기본공제 → 공정시장가액비율 → 누진세율 → 공제·세액공제 → 세부담 상한의 순서로 이어집니다.

\n

1. 과세표준을 먼저 만든다

\n

먼저 대상 아파트와 다른 주택의 공시가격을 합산합니다. 그다음 주택 수와 거주 여부에 맞는 기본공제를 빼고, 남은 금액에 해당 연도의 공정시장가액비율을 적용합니다.

\n

총 공시가격 = 대상 아파트 공시가격 + 다른 주택 공시가격의 합
과세표준 = max(0, 총 공시가격 - 기본공제) × 공정시장가액비율

\n

max(0, ...)는 공제액을 뺀 결과가 음수가 되지 않도록 0으로 처리한다는 뜻입니다. 따라서 공시가격 합계가 과세 기준에 미치지 않으면 과세표준과 종합부동산세 산출세액이 0원이 될 수 있습니다.

\n

2. 누진세율은 전체 금액에 한 번에 곱하지 않는다

\n

과세표준이 4억 2천만 원이라고 해서 4억 2천만 원 전체에 하나의 세율을 곱하는 방식은 아닙니다. 각 구간에 들어가는 금액을 잘라서 구간별 세율을 적용한 뒤 더합니다.

\n

누진 산출세액
= 1구간 금액 × 1구간 세율
+ 2구간 금액 × 2구간 세율
+ 3구간 금액 × 3구간 세율 ...

\n

예를 들어 2027년 정부안, 거주 1주택, 공시가격 20억 원을 가정하면 계산기 구조는 다음처럼 읽을 수 있습니다.

\n

단계	계산	결과
총 공시가격	20억 원	20억 원
기본공제	14억 원	6억 원이 남음
공정시장가액비율	6억 원 × 70%	과세표준 4억 2천만 원
구간별 산출	3억 × 0.5% + 1억 2천만 원 × 0.7%	234만 원

\n

여기서 234만 원은 재산세 공제·1주택 세액공제·세부담 상한을 반영하기 전의 종합부동산세 산출 단계 예시입니다. 실제 계산기의 최종 보유세는 재산세와 부가세목을 함께 계산하므로 이 숫자와 같지 않습니다.

\n

3. 재산세와 종합부동산세를 따로 계산한 뒤 합산한다

\n

계산기는 종합부동산세만 계산하지 않습니다. 주택별 재산세를 먼저 계산하고, 도시지역분과 지방교육세를 더한 다음, 종합부동산세에서 공제되는 재산세와 세액공제를 반영합니다.

\n

재산세 과세표준 = 공시가격 × 재산세 공정시장가액비율
도시지역분 = 재산세 과세표준 × 도시지역분 세율
지방교육세 = 재산세 × 지방교육세율
농어촌특별세 = 최종 종합부동산세 × 20%

연간 보유세
= 재산세 + 도시지역분 + 지방교육세
+ 최종 종합부동산세 + 농어촌특별세

\n

종합부동산세에서 빠지는 재산세 부분은 같은 세원을 두 번 과세하지 않기 위한 조정입니다. 그래서 과세표준 × 누진세율로 나온 금액이 그대로 최종 종합부동산세가 되지 않습니다.

\n

4. 1주택 세액공제는 산출세액에 적용한다

\n

1주택에 해당하는 경우에는 연령·보유기간·거주기간에 따라 세액공제율이 달라질 수 있습니다. 계산기에서는 해당 조건으로 계산한 공제액을 산출세액에서 빼고, 정부안 단계에서는 별도 공제 한도도 적용합니다.

\n

세액공제 후 종합부동산세
= max(0, 산출 종합부동산세 - 재산세 공제 - 1주택 세액공제)

\n

나이·보유기간·거주기간을 입력하지 않으면 관련 공제가 충분히 반영되지 않을 수 있습니다. 반대로 조건을 임의로 높여 입력하면 실제 증빙 요건을 충족하지 않아 결과가 달라질 수 있으므로, 확인 가능한 값만 입력해야 합니다.

\n

5. 전년도 세액이 있으면 세부담 상한을 마지막에 확인한다

\n

전년도 보유세를 입력한 경우에는 올해 계산액이 전년도보다 일정 비율 이상 커지지 않도록 상한을 확인합니다. 계산기의 구조를 단순화하면 다음과 같습니다.

\n

허용 보유세 = 전년도 보유세 × 해당 기준의 상한비율
상한 적용 후 세액 = min(상한 적용 전 보유세, 허용 보유세)

\n

실제 계산에서는 재산세처럼 이미 고정된 세목을 먼저 제외하고 종합부동산세와 농어촌특별세 쪽을 조정합니다. 전년도 세액을 입력하지 않으면 이 단계는 건너뜁니다.

\n

입력 조건이 바뀌면 어느 식이 달라질까

\n

입력 조건	계산에서 달라지는 부분
명의 형태 (단독 / 부부 공동명의)	인별 9억 공제(총 18억)와 1주택자 특례 신청(12억/14억+세액공제) 중 최적 세액 자동 선택
다른 주택 공시가격	총 공시가격, 주택 수, 기본공제와 누진 구간
실거주 주택 선택	거주 주택 비중에 따른 공제와 1주택 여부
만 나이	1주택 고령자 세액공제율
보유기간·거주기간	장기보유·장기거주 세액공제율
3채 이상·조정대상지역 주택	정부안의 공정시장가액비율과 세율 조건
전년도 보유세	세부담 상한 적용 여부와 상한 조정액

\n

따라서 같은 아파트의 공시가격을 입력하더라도 다른 주택을 추가하거나, 실거주 주택을 바꾸거나, 전년도 세액을 입력하면 최종 금액이 달라질 수 있습니다. 계산기를 사용할 때는 총액만 캡처하기보다 공시가격 합계·공제액·과세표준·공정시장가액비율·공제액·상한 조정액을 함께 기록하는 편이 좋습니다.

\n

결과를 읽을 때 확인할 네 가지

\n

공시가격 기준일: 내가 입력한 숫자가 어느 기준연도의 공시가격인지 확인합니다.
거주 주택 선택: 여러 주택을 보유한 경우 어느 집에 거주하는지에 따라 공제 구조가 달라집니다.
현행 기준과 정책안의 차이: 선택한 단계의 총액보다 현행 기준과의 차이를 먼저 봅니다.
정부안과 확정 세법 구분: 계산기의 2027·2028 결과는 정부안 시나리오이며, 확정 고지세액이 아닙니다.

\n

특히 계산기에서 +로 표시되는 차이는 정부안 기준 추정치가 현행 기준보다 높은 경우이고, −로 표시되는 차이는 낮은 경우입니다. 어느 쪽이든 결과만으로 매수·매도 결정을 내리는 것이 아니라, 공시가격·거주 여부·주택 수를 바꿔가며 민감도를 확인하는 용도로 사용하는 편이 안전합니다.

\n

자주 묻는 질문 (FAQ)

\n

Q. 8.3 세제개편안에서 거주용 1주택 종부세 면제 기준은 얼마인가요?

\n

정부안 기준으로 실제 거주하는 1세대 1주택자는 공시가격 14억원(시가 약 20억원 수준)까지 종합부동산세 과세 대상에서 제외하는 방향이 제시되었습니다.

\n

Q. 비거주 1주택과 거주용 1주택의 기본공제는 어떻게 다른가요?

\n

보유하지만 실거주하지 않는 1주택은 기본공제 9억원이 적용되어 거주용 1주택(14억원)과 분리하여 과세됩니다.

\n

Q. 다주택자의 종합부동산세 개편은 언제부터 적용되나요?

\n

정부안은 2026년 현행 기준을 거쳐 2027년 중간 단계, 2028년 본격 시행으로 2년에 걸쳐 단계적으로 개편하는 일정을 두고 있습니다.

\n

공식 원문

\n

\n

함께 읽기

\n

아파트 가격을 현재·과거·미래로 나눠 읽는 법: 가격 기준일과 예상 범위를 분리하는 방법
미래 아파트 가격을 하나의 숫자로 단정하면 위험한 이유: 조건별 범위를 읽는 방법
주택담보대출 금리와 아파트 가격은 어떻게 연결될까: 금리와 월 상환 부담을 함께 보는 순서

\n

계산 다음에 할 일

\n

블로그 계산기는 정책안의 구조와 내 조건의 차이를 빠르게 확인하는 용도입니다. 실제 관심 아파트의 공시가격, 최근 실거래 흐름, 이사 시점, 금리와 함께 비교하려면 아파트 인사이트에서 관심 단지와 조건을 확인해볼 수 있습니다.

\n

계산 결과는 의사결정 참고용 정보이며, 실제 신고·납부 전에는 최신 법령과 공식 안내를 다시 확인해야 합니다.

", "url": "https://alvin.ing/blog/83-real-estate-tax-reform-calculator", "title": "8.3 부동산 세제개편안, 보유세 계산기로 내 조건 비교하기", "summary": "2026년 8월 3일 발표된 부동산 세제개편 정부안을 현행 세법과 비교하고, 공시가격·주택 수·실거주 조건으로 연간 보유세를 직접 계산해봅니다.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "금융·세금" ] }, { "id": "https://alvin.ing/blog/real-estate-apartment-statistics-reading-order", "content_html": "

부동산과 아파트 통계는 숫자를 많이 보는 것보다 같은 기준으로 비교하는 순서를 정하는 일이 먼저입니다. 최근 실거래가 한 건, 월간 평균, 과거 차트, 미래 예상 범위는 서로 다른 질문에 답하기 때문입니다. 이 글은 특정 지역의 매수·매도를 권하는 글이 아니라, 관심 단지의 자료를 처음 확인할 때 어떤 순서로 숫자와 조건을 맞춰야 하는지 정리한 입문 안내서입니다.

\n

한눈에 보는 아파트 통계 읽기 순서

\n

아래 순서를 메모의 기본 틀로 사용하면 새로운 거래나 시장 자료가 추가되어도 같은 기준으로 다시 비교할 수 있습니다.

\n

순서	확인할 질문	놓치기 쉬운 부분
1	이 숫자는 무엇을 뜻하나?	실거래가·호가·평균·중앙값을 섞음
2	같은 단지와 평형을 비교했나?	전용면적·타입·층 조건이 달라짐
3	거래 표본이 충분한가?	한 건의 급매나 특수 거래가 평균을 바꿈
4	어느 기간과 지역을 봤나?	월간 변화와 장기 흐름을 혼동함
5	미래 결과의 기준일과 범위는?	예상가를 확정 가격처럼 받아들임
6	출처와 자료 시점은?	신고일·공개일·기준일이 달라짐

\n

1. 먼저 질문과 숫자의 이름을 확인합니다

\n

“지금 확인된 가격이 얼마인가요?”와 “1년 뒤 참고할 가격 범위는 어디인가요?”는 다른 질문입니다. 아파트 가격을 말할 때도 실거래가, 호가, 평균가, 중앙값은 서로 다른 숫자입니다. 실거래가는 계약이 신고된 가격이고, 호가는 매도자가 제시한 가격입니다. 같은 단지라도 표본과 집계 방식이 다르면 결과가 달라질 수 있으므로 차트의 숫자보다 먼저 지표의 정의와 질문을 확인해야 합니다.

\n

확인할 항목은 다음과 같습니다.

\n

어떤 가격을 집계했는가
거래가 발생한 시점과 공개된 시점은 언제인가
전용면적, 타입, 층처럼 비교 조건이 같은가
거래가 충분하지 않은 기간은 어떻게 표시했는가

\n

2. 단지와 평형을 먼저 맞춥니다

\n

같은 단지 안에서도 전용면적과 타입에 따라 거래 가격이 크게 달라질 수 있습니다. 59㎡와 84㎡를 평균으로 묶거나, 저층 거래와 고층 거래를 별도 확인하지 않으면 “단지 가격”이라는 말이 실제로 무엇을 가리키는지 불분명해집니다.

\n

관심 지역의 단지별 최근 거래와 대표 시세를 평형 단위로 확인하는 순서는 지역별 아파트 실거래가 조회하는 법에서 따로 정리했습니다.

\n

비교표를 만들 때는 최소한 다음 항목을 한 줄에 적어두는 편이 좋습니다.

\n

단지명과 주소 범위
전용면적 또는 평형
거래 유형과 층 조건
거래일과 자료를 확인한 날짜

\n

현재 거래와 과거 이력, 미래 예상 범위를 함께 보려면 아파트 가격을 현재·과거·미래로 나눠 읽는 법처럼 각 숫자의 역할을 먼저 분리해야 합니다.

\n

3. 최근 거래 한 건을 전체 시세로 확대하지 않습니다

\n

아파트 시장은 거래가 적은 기간에 한두 건만으로도 평균이 크게 움직일 수 있습니다. 최근 거래가 유용한 출발점이기는 하지만 급매, 고층, 내부 수리 상태, 직거래처럼 단지 전체를 대표하지 않을 수 있는 조건이 함께 들어 있을 수 있습니다.

\n

최근 거래를 볼 때는 거래 건수, 면적 분포, 층 분포, 거래 유형을 함께 확인합니다. 한 건의 가격이 이전 거래와 다르다면 가격 자체만 비교하기보다 비교 조건이 같은지부터 확인해야 합니다. 최근 거래 한 건만으로 아파트 시세를 판단하면 안 되는 이유에서 이 과정을 더 자세히 설명합니다.

\n

4. 한 달의 변화보다 비교 기간과 지역을 고릅니다

\n

전국 평균, 시·도 평균, 시·군·구 평균, 개별 단지의 수치는 서로 다른 질문에 답합니다. 먼저 관심 단지와 같은 생활권의 지표를 확인하고, 그다음 더 넓은 지역의 흐름과 비교하는 편이 해석하기 쉽습니다.

\n

아파트 시장은 한두 건의 거래만으로도 평균이 크게 움직일 수 있습니다. 그래서 월간 변화만 보고 결론을 내리기보다 최근 몇 달 또는 분기 흐름을 함께 봅니다. 같은 기간을 전년 동기와 비교하면 계절적 요인을 줄이는 데 도움이 되고, 장기 흐름과 단기 변화가 같은 방향인지도 확인할 수 있습니다.

\n

기간을 바꿔도 방향이 유지되는지 보는 것이 핵심입니다. 짧은 기간에서만 나타나는 변화라면 거래 구성이나 특정 면적의 영향일 수 있습니다. 비교표에는 지역 범위, 면적, 기간, 지표 정의를 한 줄에 함께 적어 기준이 흔들리지 않게 합니다.

\n

5. 가격 주변의 조건을 함께 봅니다

\n

가격만으로 시장을 설명하기는 어렵습니다. 금리와 대출 여건, 입주·분양 물량, 전세 시장, 세금과 정책 변화처럼 구매 여력과 공급에 영향을 주는 조건을 함께 확인해야 합니다. 다만 어떤 조건이 가격을 얼마나 움직였다고 단정하기 전에, 해당 기간의 변화와 자료 출처를 나란히 기록하는 것이 안전합니다.

\n

이 단계의 목적은 복잡한 예측을 만드는 것이 아니라, 가격 그래프 하나에 너무 많은 의미를 부여하지 않는 데 있습니다.

\n

6. 미래 가격은 기간과 범위를 나눠 봅니다

\n

미래 가격을 확인할 때는 목표 기간을 먼저 고릅니다. 6개월 뒤 이사 계획과 18개월 뒤 갈아타기 계획은 서로 다른 시간축을 사용하므로, 숫자만 나란히 놓으면 비교가 되지 않습니다. 6개월·12개월·18개월 아파트 전망을 비교할 때 확인할 것에서 기준일과 목표 월을 맞추는 방법을 정리했습니다.

\n

또한 예상가는 확정 가격이 아니라 여러 가능성 가운데 기준점으로 읽어야 합니다. 아래·가운데·위 값으로 표시된 범위가 있다면 범위의 폭과 거래 표본, 시장 정보의 시점을 함께 확인합니다. 아파트 예상 범위의 아래·가운데·위 값을 해석하는 법에서 실제 결과 화면을 읽는 순서를 이어서 볼 수 있습니다.

\n

예측 결과를 얼마나 믿을지는 과거 예측이 실제 거래와 얼마나 달랐는지로 판단합니다. 평균 오차율과 범위 적중률을 읽는 법은 아파트 가격 예측, 맞았는지 확인하는 법에서 다룹니다.

\n

7. 기준일·자료 상태·출처를 마지막에 기록합니다

\n

좋은 통계 메모에는 숫자뿐 아니라 출처와 한계가 함께 남습니다. 국토교통부 실거래가 공개시스템처럼 원자료에 가까운 출처를 우선하고, 작성일과 조회 범위를 기록합니다. 거래가 적은 지역이나 면적은 “자료 부족” 자체가 중요한 정보일 수 있습니다.

\n

미래 가격 결과를 참고했다면 계산 기준일, 시장 정보가 갱신된 날짜, 거래 표본 상태를 함께 적어두세요. 새 거래가 추가되거나 시장 자료가 갱신되면 같은 단지의 결과가 달라질 수 있습니다. 아파트 가격 예측 결과에서 기준일·시장 정보·표본 신뢰도 읽는 법에서 결과를 기록하는 방법을 설명합니다.

\n

자주 생기는 해석 오류

\n

최근 최고가를 현재 대표 시세로 생각하는 경우

\n

최고가 거래는 중요한 사례지만 대표값과 같은 뜻은 아닙니다. 면적, 층, 거래 시점과 거래 유형을 확인한 다음 여러 건의 흐름과 비교해야 합니다.

\n

예상가 가운데 값을 확정 가격으로 생각하는 경우

\n

가운데 값은 비교를 위한 기준점입니다. 실제 결과는 거래 조건과 시장 상황에 따라 달라질 수 있으므로 아래·가운데·위 값을 함께 보고 범위의 폭을 기록합니다.

\n

결과가 바뀐 것을 오류로만 생각하는 경우

\n

기준일, 새 거래, 시장 정보, 표본 상태가 바뀌었는지 먼저 확인합니다. 같은 질문을 같은 조건으로 다시 조회했는지까지 기록하면 결과 변화의 원인을 추적하기 쉽습니다.

\n

최종 체크리스트

\n

실거래가·호가·평균·중앙값 중 무엇인지 적었는가
단지, 전용면적, 타입, 층 조건을 맞췄는가
최근 거래 한 건이 아니라 거래량과 조건 분포를 봤는가
비교 기간과 지역 범위를 고정했는가
미래 결과의 목표 기간과 예상 범위를 확인했는가
기준일, 자료 갱신 시점, 출처와 한계를 기록했는가

\n

정리하면, 부동산과 아파트 통계를 읽는 순서는 질문 정의 → 조건 맞추기 → 거래 표본 확인 → 기간·지역 맞추기 → 주변 조건 확인 → 미래 범위 확인 → 출처와 한계 기록입니다. 이 순서만 지켜도 단기 숫자 하나에 흔들리지 않고, 다음에 들어오는 새 데이터를 같은 기준으로 비교할 수 있습니다.

\n

관심 단지의 최근 거래와 대표 시세는 지역별 아파트 실거래가에서, 1년 뒤 예상 범위는 아파트 인사이트 가입 없는 공개 예측에서 같은 기준으로 확인할 수 있습니다. 결과를 해석할 때는 숫자만 보지 말고 이 글의 체크리스트와 함께 기준일·평형·거래 표본을 확인하는 것이 좋습니다.

\n

더 깊은 데이터 해석은 개발 리서치 문서와 아래 글에서 이어서 확인할 수 있습니다.

\n

", "url": "https://alvin.ing/blog/real-estate-apartment-statistics-reading-order", "title": "부동산과 아파트 통계를 처음 읽는 순서", "summary": "부동산과 아파트 통계를 볼 때 가격, 거래량, 기간, 지역, 금리와 공급을 어떤 순서로 확인하면 좋은지 정리했습니다.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-price-current-history-forecast", "content_html": "

아파트 가격을 검색하면 실거래가, 호가, 과거 최고가, 예상 가격이 한 화면에 섞여 나오는 경우가 많습니다. 하지만 이 네 가지 숫자는 서로 다른 질문에 답합니다.

\n

지금 실제로 계약된 가격은 얼마인가
같은 단지가 과거에 어떤 흐름을 보였는가
앞으로 가능한 가격 경로는 어느 정도의 폭을 가지는가

\n

이 질문을 한 숫자로 합치면 시세를 빠르게 보는 것 같지만, 오히려 중요한 차이를 놓치기 쉽습니다.

\n

먼저 세 가지 층을 분리해 보기

\n

아파트 가격을 읽는 세 겹의 기준

과거 실거래 흐름현재 기준점미래 예상 범위

개념도입니다. 실제 단지 분석에서는 기준일·면적·거래 표본을 따로 확인해야 합니다.

\n

위 차트는 특정 단지의 실제 데이터가 아니라 가격 정보를 읽는 순서를 나타낸 개념도입니다. 과거 거래는 이미 관측된 기록이고, 현재 거래는 기준일의 앵커이며, 미래는 여러 조건에 따라 달라질 수 있는 범위입니다.

\n

1. 최근 실거래가는 ‘현재 확인된 거래’다

\n

국토교통부 실거래가 공개시스템의 아파트 거래는 계약일을 기준으로 조회합니다. 신고와 공개 사이에는 시간이 생길 수 있고, 계약이 해제되거나 정정될 수도 있으므로 조회 시점의 데이터 상태도 함께 봐야 합니다.

\n

실거래가를 볼 때는 가격만 복사하지 말고 다음 조건을 같이 기록하는 편이 좋습니다.

\n

전용면적과 평형
거래 시점과 층
동일 단지 안의 동·향·뷰 차이
직전 거래와의 시간 간격
거래량이 충분한지 여부

\n

같은 단지라도 면적과 층이 다르면 가격을 그대로 비교하기 어렵습니다. 특히 거래가 드문 단지는 최근 한 건이 단지 전체의 대표 가격처럼 보일 수 있습니다.

\n

2. 과거 이력은 방향보다 맥락을 보여준다

\n

과거 가격 흐름은 “얼마나 올랐나”만 계산하는 자료가 아닙니다. 다음과 같은 질문을 확인하는 자료입니다.

\n

가격 변화가 한두 건의 거래 때문인지, 여러 달 이어진 흐름인지
상승과 하락이 거래량 변화와 함께 나타났는지
비슷한 면적의 거래가 반복적으로 확인되는지
특정 시점의 정책·금리·공급 변화와 움직임이 겹치는지

\n

과거 최고가와 현재 거래가를 비교하는 것도 도움이 되지만, 최고가를 회복해야 한다는 목표처럼 사용하면 안 됩니다. 최고가는 특정 시점의 거래 조건을 포함한 기록일 뿐, 미래 가격의 기준선이나 보장값이 아니기 때문입니다.

\n

3. 미래는 한 줄보다 범위로 읽는다

\n

미래 예상은 아직 관측되지 않은 구간입니다. 금리, 공급, 거래량, 정책, 지역별 수요가 달라지면 같은 단지도 다른 경로를 보일 수 있습니다.

\n

따라서 “12개월 뒤 얼마인가요?”보다 다음 질문이 더 정확합니다.

\n

현재 기준점은 어떤 거래와 기준일로 만들어졌는가
예상 범위의 아래쪽과 위쪽은 어떤 불확실성을 담고 있는가
기간이 길어질수록 범위가 넓어지는가
내 보유·거주·대출 조건을 넣으면 해석이 달라지는가

\n

미래 가격을 범위로 읽는 방법은 하나의 숫자보다 범위로 봐야 하는 이유에서 더 자세히 설명했습니다.

\n

아파트 시세를 읽는 실전 순서

\n

첫째, 기준일을 고정한다

\n

“최근”이라는 말만으로는 부족합니다. 조회 기준일과 마지막 거래일을 함께 적어야 오래된 정보와 최신 정보를 구분할 수 있습니다.

\n

둘째, 비교 조건을 맞춘다

\n

전용면적·층·거래 유형이 다른 가격을 한 선에 올리면 차트가 정교해 보여도 해석은 흔들립니다. 같은 조건을 먼저 모은 뒤, 다른 조건은 별도 표본으로 분리합니다.

\n

셋째, 현재·과거·미래를 다른 색과 영역으로 본다

\n

과거는 선, 현재는 기준점, 미래는 띠나 범위로 표시하면 숫자의 성격이 한눈에 드러납니다. 세 값을 한 선으로 이어 그리면 예상과 사실이 같은 확실성을 가진 것처럼 보일 수 있습니다.

\n

넷째, 숫자와 함께 데이터의 빈틈을 적는다

\n

거래가 적은 단지, 면적이 섞인 표본, 해제 거래가 포함된 경우에는 “가격이 얼마다”보다 “이 가격을 얼마나 확실하게 비교할 수 있는가”가 먼저입니다.

\n

참고 자료와 다음 읽을거리

\n

국토교통부 실거래가 공개 안내: 계약일 기준 실거래가와 거래 통계의 차이를 확인할 수 있습니다.
국토교통부 실거래가 FAQ: 계약일·신고일·공개 시점과 해제 거래 표시 기준을 확인할 수 있습니다.
한국부동산원 부동산통계정보시스템 R-ONE: 주택가격지수와 거래현황처럼 실거래가와 함께 비교할 공식 통계를 제공합니다.
지역별 아파트 실거래가: 단지별 최근 거래, 대표 시세, 최근 1년 거래 범위를 평형 단위로 정리한 페이지입니다.
미래가격 예측 공식 가이드: 과거 거래와 미래 예상 경로를 구분해 읽는 공개 설명입니다.
미래 가격 범위를 읽는 방법: 하나의 숫자로 단정하지 않는 이유를 이어서 설명합니다.

\n

과거 거래 흐름을 확인한 다음 내 관심 단지와 보유 조건까지 함께 비교하고 싶다면 공개 아파트 분석 도구에서 같은 질문을 직접 적용해볼 수 있습니다.

\n

\n
실거래가와 예상 범위는 기준일·표본·조건에 따라 달라질 수 있습니다. 이 글은 투자 권유나 매수·매도 추천이 아니며, 최종 판단과 책임은 이용자에게 있습니다.
\n

", "url": "https://alvin.ing/blog/apartment-price-current-history-forecast", "title": "아파트 가격을 볼 때 현재 거래가·과거 이력·예상 범위를 나눠야 하는 이유", "summary": "아파트 시세를 읽을 때 최근 실거래가, 과거 가격 흐름, 미래 예상 범위를 한 숫자로 섞지 않는 방법을 차트로 설명합니다.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/apartment-price-range-not-single-number", "content_html": "

“그래서 1년 뒤 아파트 가격은 얼마인가요?”라는 질문은 자연스럽지만, 답을 하나의 숫자로만 받으면 오히려 중요한 정보를 잃을 수 있습니다.

\n

가격 전망에는 기준일, 거래 표본, 금리, 공급, 정책, 지역별 수요가 함께 들어갑니다. 이 조건들이 조금만 달라져도 결과가 달라질 수 있기 때문에, 좋은 전망은 숫자를 단정하기보다 가능한 범위와 그 범위를 만든 조건을 보여줍니다.

\n

이 글의 초점은 “왜 미래 가격을 범위로 봐야 하는가”라는 개념 설명입니다. 실제 결과 화면에 표시된 아래·가운데·위 값을 어떤 순서로 읽을지는 아파트 예상 범위의 아래·가운데·위 값을 해석하는 법에서 별도로 다룹니다.

\n

하나의 숫자보다 범위가 필요한 이유

\n

하나의 예측값보다 범위가 알려주는 것

가능한 결과의 폭범위 안의 중심 추정

범위는 보장이 아니라 불확실성을 보여주는 참고 정보입니다.

\n

위 차트는 특정 지역이나 단지의 실제 전망이 아니라, 시간이 멀어질수록 불확실성이 커지는 구조를 보여주는 개념도입니다. 세 경로가 모두 같은 현재 기준점에서 시작하더라도 미래로 갈수록 조건의 차이가 결과의 폭으로 나타납니다.

\n

중심 추정값은 결론이 아니라 기준점이다

\n

중심에 있는 추정값은 여러 가능성 중 하나를 읽기 위한 기준입니다. 그 숫자만 보고 “이 가격에 도달한다”고 해석하면 안 됩니다.

\n

중심 추정값을 볼 때는 다음을 확인하세요.

\n

기준일이 언제인가
마지막으로 반영된 거래는 언제인가
대상 면적과 비교 표본이 일치하는가
예상 기간이 6개월인지 12개월인지 18개월인지
금리와 공급 같은 조건이 고정되어 있는가

\n

기간이 길어질수록 확인해야 할 조건이 늘어나므로, 짧은 기간의 좁은 범위와 긴 기간의 넓은 범위를 같은 의미로 비교하면 안 됩니다.

\n

범위의 아래쪽과 위쪽은 무엇을 뜻할까

\n

범위의 아래쪽은 반드시 하락한다는 뜻이 아닙니다. 거래가 줄거나 자금 부담이 커지는 등 불리한 조건이 이어질 때 가능한 경로를 보여주는 참고선에 가깝습니다.

\n

범위의 위쪽도 반드시 도달한다는 뜻이 아닙니다. 수요가 유지되고 거래 환경이 개선되는 경우처럼 다른 조건에서 가능한 경로를 보여줍니다.

\n

따라서 범위를 읽을 때는 “아래냐 위냐”보다 다음을 묻는 편이 낫습니다.

\n

두 경계를 벌어지게 만든 조건은 무엇인가
지금 확인된 자료가 어느 구간까지 충분한가
내 아파트의 거래 표본이 같은 조건을 대표하는가
새 거래나 정책 변화가 생기면 범위가 다시 계산되는가

\n

범위가 넓다고 분석이 무의미한 것은 아니다

\n

범위가 넓다는 것은 현재 시점에서 모르는 것이 많다는 뜻이지, 아무 정보도 없다는 뜻은 아닙니다. 오히려 아래와 같은 판단에 도움이 됩니다.

\n

단기와 장기의 불확실성 차이
금리 변화에 민감한 자금 계획인지 여부
거래가 부족해 추가 확인이 필요한 단지인지 여부
특정 조건을 바꿨을 때 결과가 얼마나 움직이는지

\n

반대로 범위가 지나치게 좁은데 기준일·거래 표본·조건 설명이 없다면, 숫자가 정교해 보이는 것과 실제로 확실한 것은 구분해야 합니다.

\n

현재 가격과 미래 범위를 한 차트에 놓는 법

\n

아파트 가격 차트를 만들 때는 다음 세 가지 표현을 분리하는 것이 좋습니다.

\n

표현	보여주는 것	읽을 때 주의할 점
점	현재 기준점 또는 최근 대표 거래	어떤 조건의 거래인지 확인
선	과거 거래 흐름 또는 중심 경로	사실과 전망의 경계 확인
띠	가능한 가격 범위	보장값이 아닌 불확실성 표시

\n

이렇게 그리면 독자는 “이미 발생한 가격”과 “앞으로 가능한 경로”를 같은 확실성으로 받아들이지 않게 됩니다.

\n

전망을 읽기 전 체크리스트

\n

가격 기준이 실거래가인지 호가인지 확인하기
기준일과 마지막 데이터 시점 확인하기
면적·층·거래 유형이 같은지 확인하기
기간별 범위를 따로 비교하기
금리·공급·정책 조건이 바뀌었는지 확인하기
가격 범위를 매수·매도 추천으로 바꾸어 해석하지 않기

\n

참고 자료

\n

한국부동산원 부동산통계정보시스템 R-ONE: 주택가격지수·거래현황 등 공개 통계를 확인하고 전망의 기준 기간을 맞출 수 있습니다.
한국부동산원 전국주택가격동향조사: 통계의 작성기관·기준시점·공표 범위를 확인할 수 있습니다.
국토교통부 실거래가 공개 안내: 계약일 기준 실거래 자료와 거래 통계의 차이를 확인할 수 있습니다.

\n

앞서 읽은 현재 거래가·과거 이력·예상 범위를 나눠 보는 방법과 함께 보면 차트의 각 선과 띠가 어떤 역할을 하는지 더 쉽게 이해할 수 있습니다. 공개된 예측 개념을 더 자세히 보고 싶다면 미래가격 예측 공식 가이드와 기술 백서를 참고할 수 있습니다. 실제 결과 카드의 하단·중앙·상단 값을 확인하려면 아파트 예상 범위 화면 읽기로 이어서 읽어 보세요.

\n

내 관심 아파트의 기준일·거래 흐름·기간별 조건을 직접 비교해보고 싶다면 공개 아파트 분석 도구에서 같은 방식으로 조건을 확인해볼 수 있습니다.

\n

\n
가격 전망과 범위는 참고용 분석이며 실제 가격·거래 가능성·수익을 보장하지 않습니다. 이 글은 투자 자문이나 매수·매도 추천이 아닙니다.
\n

", "url": "https://alvin.ing/blog/apartment-price-range-not-single-number", "title": "미래 아파트 가격을 하나의 숫자로 단정하면 위험한 이유", "summary": "아파트 가격 전망을 중심값 하나가 아니라 가능한 범위로 읽어야 하는 이유와, 기간·거래 표본·금리 조건을 함께 비교하는 방법을 설명합니다.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "부동산 데이터" ] }, { "id": "https://alvin.ing/blog/transport-benefit-stages-apartment-price", "content_html": "\n

“새 노선이 들어온다”는 한 문장만으로 아파트 가격을 판단하기는 어렵습니다. 같은 교통 사업이라도 발표 단계인지, 검토가 끝났는지, 공사가 시작됐는지, 실제로 이용할 수 있는지에 따라 확인해야 할 내용이 완전히 달라집니다.

\n

교통 호재는 진행 단계가 핵심이다

\n

교통 호재는 단계별로 다시 확인해야 합니다

1

발표방향과 필요성

2

검토·타당성수요와 비용 확인

3

계획·설계노선·역·공법 구체화

4

착공공사가 실제로 시작

5

개통이용 가능한 교통

발표만으로 개통 시점이나 실제 통행 편의를 확정할 수 없습니다. 단계와 공식 문서의 기준일을 함께 확인하세요.

\n

국토교통부 철도산업 사업현황 공공데이터는 사업 추진 과정에서 조사·설계·고시·계획 수립·착공 등 여러 이력이 발생할 수 있음을 보여줍니다. 실제 사업마다 절차와 명칭은 다를 수 있으므로, 차트는 공통적으로 확인하기 쉬운 읽기 순서로 이해하면 됩니다.

\n

1. 발표: 방향과 필요성을 알리는 단계

\n

발표는 사업이 중요하다는 신호지만, 노선·역 위치·사업비·개통 시점이 모두 확정됐다는 뜻은 아닙니다.

\n

이 단계에서 확인할 질문은 다음과 같습니다.

\n

어떤 기관이 발표했는가
발표 자료에 사업 대상과 범위가 명확히 적혀 있는가
예산·재원·추진 주체가 함께 언급됐는가
목표 일정인지 확정 일정인지 구분되어 있는가

\n

기사 제목만 저장하기보다 발표 기관의 원문과 기준일을 먼저 저장하는 편이 안전합니다.

\n

2. 검토·타당성: 사업을 추진할 근거를 확인하는 단계

\n

수요, 비용, 기술적 가능성, 주변 사업과의 연계 등을 검토하는 단계입니다. 검토 결과에 따라 사업 범위와 일정이 달라질 수 있습니다.

\n

아파트 가격을 읽을 때는 “검토 중”이라는 표현을 “공사가 결정됨”으로 바꾸어 쓰지 않아야 합니다. 통과 여부와 조건, 이후 계획 수립 여부를 별도로 확인해야 합니다.

\n

3. 계획·설계: 노선과 이용 조건이 구체화되는 단계

\n

기본계획, 실시설계, 사업계획 승인 같은 문서가 나오면 노선·역·환승·공사 범위를 더 구체적으로 확인할 수 있습니다. 그래도 설계와 협의 과정에서 세부 내용이 바뀔 수 있습니다.

\n

이 단계에서는 단순히 “역이 생긴다”가 아니라 다음을 지도에 표시해보세요.

\n

단지에서 역까지 실제 보행 동선
환승 횟수와 주요 업무지구까지의 이동 시간
역 출입구와 생활권의 위치
공사 기간 동안의 우회·소음·교통 영향

\n

4. 착공: 기대와 공사가 분리되는 단계

\n

착공은 사업이 현장 단계로 넘어갔다는 강한 신호입니다. 하지만 착공했다고 바로 통행이 시작되는 것은 아닙니다. 공사 기간, 공정률, 개통 목표, 추가 공사 여부를 계속 확인해야 합니다.

\n

특히 교통 호재를 가격 차트에 반영할 때는 착공일 하나만 표시하지 말고, 착공 이후 실제 공정과 개통 일정의 변동도 별도로 기록하는 것이 좋습니다.

\n

5. 개통: 실제 통행 편의를 확인하는 단계

\n

개통은 계획이 실제 이용 가능한 교통 서비스로 바뀌는 시점입니다. 이때부터는 발표 자료가 아닌 실제 이동 시간, 배차 간격, 환승 편의, 혼잡도, 이용 요금을 확인할 수 있습니다.

\n

역이 개통되어도 모든 단지가 같은 혜택을 받는 것은 아닙니다. 도보권인지, 버스 환승이 필요한지, 출근 시간대에 실제로 편리한지에 따라 체감 편의는 달라집니다.

\n

교통 호재를 아파트 가격과 연결하는 순서

\n

사업 단계와 기준일을 먼저 적습니다.
공식 문서에서 노선·역·일정을 확인합니다.
단지에서 역까지의 실제 동선을 지도에서 봅니다.
개통 전에는 기대 요인과 일정 위험을 분리합니다.
개통 후에는 실제 통행 시간과 생활 편의를 다시 확인합니다.

\n

자주 묻는 질문 (FAQ)

\n

Q. 교통 호재는 발표, 착공, 개통 중 어느 시점에 집값에 가장 크게 반영되나요?

\n

통상적으로 초기 계획 발표 시 기대감으로 1차 선반영이 일어나고, 사업 확정 후 실제 착공 시 2차 상승, 그리고 완공 및 개통으로 실제 통행 편의가 입증될 때 3차 시세 형성이 이루어집니다.

\n

Q. 단순 계획 발표 단계의 교통 호재를 볼 때 주의할 점은 무엇인가요?

\n

발표 단계는 예비타당성조사, 재원 마련, 기본설계 등 거쳐야 할 관문이 많아 사업 지연이나 노선 변경, 무산 위험이 높으므로 목표 일정을 확정된 사실로 오해하지 말아야 합니다.

\n

Q. 역세권 아파트라도 개통 후 가격이 오르지 않는 경우가 있나요?

\n

착공 이전 단계에서 기대감이 과도하게 선반영되어 이미 높은 시세가 형성되었거나, 배차 간격이 길고 출퇴근 핵심 업무지구로의 직결성이 떨어지는 노선일 경우 개통 후 추가 상승 폭이 제한될 수 있습니다.

\n

참고 자료

\n

국토교통부 철도산업 사업현황 공공데이터: 철도 사업의 조사·설계·고시·계획·착공 관련 이력을 확인할 수 있습니다.
국토교통부 2026년 업무계획: 철도·도로 등 교통 인프라 사업의 정책 방향과 추진 계획을 확인할 수 있습니다.
국토교통부 교통 분야 정책 자료: 사업 제안·검토·계획 수립·고시 등 교통 사업 절차의 사례를 참고할 수 있습니다.

\n

교통 호재 하나만으로 아파트 가격이 정해지는 것은 아닙니다. 거래량, 공급, 전세 흐름, 직주근접, 생활 인프라를 함께 봐야 같은 지역 안에서 단지별 차이를 설명할 수 있습니다.

\n

아파트 가격을 현재 거래·과거 흐름·미래 범위로 나누어 읽는 방법은 아파트 가격의 세 가지 기준에서 이어집니다. 공개 분석의 기본 개념과 데이터 해석 원칙은 공식 가이드 모음에서 확인할 수 있습니다.

\n

교통과 거래 흐름을 내 관심 단지에 함께 적용해보고 싶다면 공개 아파트 분석 도구에서 직접 비교할 수 있습니다.

\n

\n
교통 사업의 일정과 범위는 공식 발표·고시·설계·공사 과정에서 달라질 수 있습니다. 이 글은 특정 지역이나 단지의 가격 상승을 보장하거나 매수를 권유하지 않습니다.
\n

", "url": "https://alvin.ing/blog/transport-benefit-stages-apartment-price", "title": "아파트 교통 호재 분석법: 발표·착공·개통 단계별 집값 반영 시점", "summary": "교통 호재가 아파트 가격에 반영되는 발표, 예비타당성조사, 착공, 개통 4대 핵심 단계와 단계별 집값 상승률 및 투자 유의점을 정리합니다.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트" ] }, { "id": "https://alvin.ing/blog/mortgage-rate-apartment-price", "content_html": "\n

금리가 오르면 집값이 내리고, 금리가 내리면 집값이 오른다는 설명은 이해하기 쉽습니다. 하지만 실제 아파트 시장에서는 금리 변화와 실거래가 움직임 사이에 시간이 생깁니다.

\n

금리는 먼저 대출을 이용하는 가계의 월 부담과 구매 가능한 가격대를 바꾸고, 그 다음 거래 속도와 협상 조건을 거쳐 가격에 영향을 줍니다.

\n

금리에서 아파트 가격까지는 여러 단계를 거친다

\n

금리 변화가 아파트 가격에 닿는 경로

1

대출금리 변화시장·정책·상품 조건→

2

월 상환 부담같은 금액을 빌려도 달라짐→

3

구매 가능한 가격대가계 현금흐름이 제약→

4

거래의 속도협상·관망·실행 시점

금리 변화 → 가계 현금흐름 → 거래 조건 → 실제 가격으로 이어지는 시간차가 있습니다.

\n

금리별 월 상환액과 총 이자 부담 직접 비교하기

\n

💡 주택담보대출 금리별 월 상환액 비교기

금리가 1%p 변할 때 매월 지출하는 원리금과 총 이자 부담이 얼마나 달라지는지 직접 확인해보세요. (원리금 균등상환 기준)

대출 원금

대출 기간

기준 금리 (인하 전)

비교 금리 (인하 후)

기준 금리 4.5% 적용 시

월 253만원

30년 총 이자: 4억 1,203만원

비교 금리 3.5% 적용 시

월 225만원

30년 총 이자: 3억 828만원

금리가 1.0%p 낮아지면:매달 29만원 절감 (30년 누적 총 1억 375만원 절약)

* 거치기간 없는 원리금균등분할상환 기준 단순 계산이며, 실제 은행 대출 취급 시 중도상환수수료, 우대금리 조건, 거치 여부 등에 따라 달라질 수 있습니다.

\n

이 흐름은 모든 지역과 모든 가구에 같은 크기로 적용되는 공식이 아닙니다. 기존 대출의 고정·변동 여부, 대출 만기, 소득, 보유 현금, 전세 상황에 따라 체감 부담이 달라집니다.

\n

1. 시장 금리와 내 적용 금리는 다르다

\n

한국은행 금융·경제 스냅샷과 경제통계시스템에서 확인하는 대출금리는 여러 금융기관의 평균을 보여주는 통계입니다.

\n

이 평균은 시장의 방향을 읽는 데 유용하지만, 개인이 실제로 적용받는 금리와는 다를 수 있습니다. 신용 조건, 담보 가치, 대출 기간, 고정·변동 선택, 우대 조건에 따라 달라지기 때문입니다.

\n

따라서 기사를 읽을 때는 “평균 금리가 몇 퍼센트인가”에서 멈추지 말고 다음 두 값을 분리해야 합니다.

\n

시장을 읽는 참고 금리
내 대출 계약에 실제 적용되는 금리

\n

2. 월 상환 부담이 먼저 바뀐다

\n

같은 금액을 빌려도 금리와 만기가 바뀌면 월 납입액과 전체 이자 부담이 달라집니다. 원리금균등상환인지, 원금균등상환인지, 만기일시상환인지에 따라서도 현금흐름은 달라집니다.

\n

그래서 아파트 가격을 금리와 연결할 때는 “금리 1%포인트 변화 = 집값 몇 퍼센트 변화”처럼 바로 환산하기보다 다음 순서가 현실적입니다.

\n

대출 잔액과 남은 기간 확인
고정·변동 여부 확인
월 상환액이 소득과 생활비에서 차지하는 비중 확인
금리가 바뀌어도 유지할 수 있는 현금흐름인지 확인

\n

3. 구매 가능한 가격대가 달라진다

\n

월 상환 부담이 커지면 같은 소득을 가진 가구가 감당할 수 있는 대출 규모가 줄어들 수 있습니다. 반대로 부담이 줄면 더 높은 가격대까지 검토할 여지가 생깁니다.

\n

하지만 이것이 곧바로 모든 아파트 가격의 등락으로 이어지지는 않습니다. 지역별 공급, 전세 가격, 보유자의 매도 필요성, 현금 구매자 비중이 함께 작용하기 때문입니다.

\n

금리 기사를 아파트 시세에 연결할 때는 지역별 거래량과 거래 간격을 같이 보는 것이 좋습니다. 가격이 유지되어 보여도 거래가 크게 줄었다면 시장의 조정이 거래량과 협상 과정에서 먼저 나타났을 수 있습니다.

\n

4. 가격보다 거래 속도와 협상력이 먼저 움직일 수 있다

\n

금리 변화 직후에 모든 계약 가격이 같은 방향으로 이동하지는 않습니다. 먼저 매수자는 관망하고, 매도자는 가격을 유지하려 하며, 실제 계약까지 걸리는 시간이 길어질 수 있습니다.

\n

이때 확인할 지표는 다음과 같습니다.

\n

월별 거래 건수
최근 거래 사이의 간격
같은 면적의 거래가 반복되는지 여부
호가와 실제 계약 가격의 차이
전세 가격과 매매 가격의 동반 움직임

\n

가격만 보면 변화가 늦게 보일 수 있으므로, 거래량과 거래 간격을 함께 차트에 그리는 편이 좋습니다.

\n

금리와 아파트 가격을 함께 읽는 체크리스트

\n

질문	확인할 자료	해석의 주의점
금리가 변했나	한국은행 평균 금리·기준금리	개인 적용 금리와 다름
내 부담이 변했나	대출 잔액·만기·상환 방식	가구별 차이가 큼
거래가 반응했나	거래량·거래 간격	가격보다 먼저 움직일 수 있음
가격이 반응했나	같은 면적·층의 실거래	표본이 적으면 과대해석 위험
다른 조건은 같은가	공급·전세·정책·지역 수요	금리 하나로 설명하지 않기

\n

자주 묻는 질문 (FAQ)

\n

Q. 기준금리가 인하되면 아파트 가격은 바로 반등하나요?

\n

기준금리가 인하되더라도 은행의 대출 가산금리 정책, 스트레스 DSR 규제 강화, 기존 주택 매물 소화 과정 등을 거치므로 시장 가격에 반영되기까지는 보통 3개월에서 6개월 이상의 시차가 발생합니다.

\n

Q. 주택담보대출 금리가 1%p 변할 때 월 상환액 부담은 얼마나 차이 나나요?

\n

대출 5억원 30년 만기 원리금 균등상환 기준, 금리가 1%p(예: 4.5%에서 3.5%) 낮아지면 매달 납부하는 원리금이 약 29만원 줄어들며, 30년간 누적 총 이자는 1억원 이상 절약됩니다.

\n

Q. 스트레스 DSR이란 무엇이며 대출 한도에 어떤 영향을 주나요?

\n

향후 잠재적 금리 인상 위험을 감안해 실제 대출 금리에 가산금리(스트레스 금리)를 얹어 연간 원리금 상환액을 산정하는 규제입니다. 금리 자체가 오르지 않아도 계산상 상환 부담이 커져 실제 빌릴 수 있는 총 대출 한도가 축소됩니다.

\n

참고 자료

\n

한국은행 금융·경제 스냅샷: 금리와 금융시장 관련 주요 지표를 한 화면에서 확인할 수 있습니다.
한국은행 경제통계시스템 ECOS: 대출금리와 거시경제 통계를 직접 조회할 수 있는 공식 통계 시스템입니다.
한국은행 경제연구원 주택담보대출 차입자의 금리 선택 분석: 고정·변동금리 선택과 가계 금융 부담의 관계를 살펴본 연구자료입니다.

\n

금리와 가격을 기간별로 비교하는 방법은 현재 거래가·과거 이력·예상 범위를 나눠 보는 글에서 이어서 확인할 수 있습니다. 금리 조건을 바꿨을 때 가능한 가격 경로를 어떻게 읽는지는 공식 가이드의 미래가격 예측 설명도 참고할 만합니다.

\n

내 관심 단지의 최근 거래와 금리 조건을 함께 놓고 비교해보고 싶다면 공개 아파트 분석 도구에서 확인할 수 있습니다.

\n

\n
금리와 주택 가격의 관계는 지역·가구·대출 상품·공급 조건에 따라 달라집니다. 이 글은 금융상품 가입이나 대출 실행을 권유하지 않으며, 최종 판단 전 금융기관의 최신 조건을 확인해야 합니다.
\n

", "url": "https://alvin.ing/blog/mortgage-rate-apartment-price", "title": "주택담보대출 금리와 아파트 가격의 상관관계: 금리 인하가 집값에 미치는 영향", "summary": "주택담보대출 금리가 아파트 가격에 바로 반영되지 않는 이유와 금리 변화에 따른 월 상환 부담, 구매 가능 가격대, 거래 흐름을 계산기와 함께 살펴봅니다.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "부동산", "아파트", "금융·세금" ] }, { "id": "https://alvin.ing/blog/introduction-to-flutter", "content_html": "

플러터란?

\n

플러터는 구글이 출시한 오픈소스 크로스플랫폼 GUI 애플리케이션 프레임워크입니다. 안드로이드, iOS, 윈도우즈, 리눅스 및 웹 애플리케이션과 구글 퓨시아 앱의 주된 소스코드로 사용됩니다. 2.0 버전부터 웹 애플리케이션을 지원했으며, 3.0 버전에서는 맥OS와 윈도우즈 애플리케이션도 지원하게 되었습니다.

\n

플러터 기반의 대표적인 서비스

\n

우리가 알만한 몇 가지 서비스를 소개하겠습니다. 플러터 공식 홈페이지에서 제공되는 각 서비스의 성공 지표는 다음과 같습니다. 네이버 지식iN에 대한 설명은 다음 장에서 계속됩니다.

\n

네이버 지식iN
구글 페이\n
- 엔지니어의 노력 70% 감소, 코드 라인 수 35% 감소
\n
텐센트\n
- 개발 시간이 33% 감소, 앱 코드에서 플러터의 비중은 90%
\n
eBay 모터스\n
- 네이티브보다 개발 속도가 2배 빠르다고 생각하는 개발자 비중이 70%
\n
BMW

\n

플러터 구조 및 동작 원리

\n

플러터는 세 가지 계층으로 구성됩니다. 하드웨어와 직접 통신하는 임베더 계층, C++로 작성된 엔진 계층, 그리고 개발자들이 주로 사용하는 프레임워크 계층입니다. 임베더 계층은 6개 플랫폼의 네이티브 플랫폼과 통신하며 운영체제 기능을 모듈화합니다. 엔진 계층은 플러터 코어 API, 스키아 그래픽 엔진, 파일 시스템, 네트워크 기능 등을 정의합니다.

\n

프레임워크 계층에는 플러터를 사용하는 데 필수적인 위젯, 애니메이션, 매터리얼 디자인 패키지, 쿠퍼티노 디자인 패키지 등이 포함됩니다. 이렇게 세 가지 계층으로 나뉘고 잘 모듈화된 아키텍처 덕분에 플러터는 다양한 플랫폼을 쉽게 지원하며, 일관된 API 및 개발 경험을 제공합니다.

\n

$\"image-1\"$

\n

플러터는 스키아 엔진을 지원하는 모든 플랫폼에서 실행될 수 있도록 구현됩니다. 플러터 팀은 iOS와 안드로이드 앱뿐만 아니라 윈도우, 리눅스, 맥OS 애플리케이션, 심지어 웹사이트까지 플러터 코드로 배포할 수 있도록 했습니다. 플러터를 사용하면 한 번에 6가지 플랫폼에 애플리케이션을 배포할 수 있습니다.

\n

플러터가 스키아 엔진을 사용할 때의 장점은 무엇일까요? 대부분의 크로스플랫폼 앱 개발 프레임워크들은 웹뷰를 사용하거나 각 플랫폼의 UI 라이브러리를 사용합니다. 하지만 플러터는 웹뷰를 사용하지 않고 직접 스키아 엔진을 이용하여 화면에 UI를 그립니다.

\n

\n
기존의 플랫폼에서 제공되는 UI를 모두 버리고 자체적으로 UI를 렌더링하기 때문에 iOS에서 매터리얼 디자인과 ripple 애니메이션을 볼 수 있고, 안드로이드에서 쿠퍼티노 디자인을 사용할 수 있습니다.
\n
플러터는 화면 전체를 2D 그래픽 API로 fillRect하고, drawText와 drawImage를 사용하여 앱을 만드는 것과 같은 방식으로 스키아 기반으로 렌더링해줍니다. 이는 웹 개발에서 HTML을 모두 무시하고 전체를 플래시나 캔버스로 만드는 것과 유사합니다.
\n

\n

예를 들어, 플러터의 대표적인 경쟁 프레임워크인 리액트 네이티브는 자바스크립트 브릿지를 통해 플랫폼과 통신합니다. 또한 플랫폼의 UI(OEM 위젯)를 그대로 사용합니다. 그래서 플랫폼과 리액트 네이티브 간의 통신에는 상당한 리소스 비용이 듭니다. 하지만 플러터는 위젯을 스키아 엔진에 직접 그려내고 필요한 제스처 및 이벤트를 브릿지를 통하지 않고 실행하기 때문에 리액트 네이티브에 비해 상당히 빠른 성능을 자랑합니다.

\n

참고로 플러터 팀은 초당 60프레임을 목표로 많은 노력을 기울인다고 합니다.

\n

$\"image-2\"$

\n

다트 언어를 채택한 이유

\n

다트는 2011년에 구글이 개발한 클라이언트-사이드 개발 언어입니다. 처음에는 자바스크립트를 대체하기 위한 언어로 소개되었으며, 실제로 처음 제공한 트랜스 컴파일 결과물도 자바스크립트였습니다. 다트는 JIT(Just-In-Time) 컴파일을 통해 VM 위에서 동작하는 방식과 AOT(Ahead-Of-Time) 컴파일을 통해 런타임에서 바로 동작하는 방식을 모두 지원합니다.

\n

JIT 컴파일은 인터프리터처럼 실행 전에 코드를 컴파일하지 않아도 되기 때문에, 코드 수정 시 발생하는 빌드 시간을 줄여 개발자들이 더 편리하게 개발할 수 있는 장점이 있습니다. 그러나 VM 위에서 동작하기 때문에 대부분의 코드가 네이티브 플랫폼에 비해 성능상 느리다는 단점이 있습니다. 그러나 다트는 AOT 컴파일도 지원하기 때문에 실제 배포 시 AOT 컴파일을 통해 런타임에서 바로 동작하는 코드를 생성할 수 있습니다.

\n

\n
AOT 컴파일은 다트 2버전이 나오면서 추가된 기능인데, 아마도 플러터 팀의 요청이 있었을 것이라고 생각합니다.
\n

\n

$\"image-3\"$

\n

혹시 다른 언어도 다트처럼 JIT와 AOT 컴파일러를 둘다 사용하는지 궁금해서 검색을 해봤는데, 다트처럼 개발 단계와 릴리즈 단계에서 각각 다른 컴파일 방식을 사용하는 언어는 없었습니다.

\n

C# / .NET: .NET Core와 .NET 프레임워크는 JIT 컴파일을 기본으로 하지만, .NET Native나 AOT 컴파일 옵션을 통해 AOT 컴파일도 가능합니다.
Dart: Dart 언어는 플러터에서 주로 사용되며, AOT와 JIT 둘 다 지원합니다. 개발 중에는 JIT 컴파일을 사용하여 빠른 개발 사이클을 유지하고, 릴리즈 시에는 AOT 컴파일을 사용하여 최적의 성능을 달성합니다.
JavaScript / TypeScript: 일반적으로 자바스크립트는 인터프리터 언어로 분류되며, JIT 컴파일이 많이 사용됩니다. 그러나 웹 어셈플리를 통해 AOT 컴파일도 가능합니다.
Rust: 러스트는 기본적으로 AOT 컴파일을 사용하지만, JIT 컴파일을 가능하게 하는 라이브러리도 존재합니다.
Go: Go 언어는 주로 AOT 컴파일을 사용하지만, 몇몇 특별한 상황에서는 JIT 컴파일을 사용하는 경우도 있습니다.

\n

hot reload

\n

플러터의 hot reload를 사용하면 개발 시간을 단축시키고 거의 즉시에 가까운 속도로 개발할 수 있습니다. 이 기능은 다트의 JIT 컴파일을 기반으로 하며, 다트가 JIT 컴파일을 지원하기 때문에 앱을 즉시 수정하고 실행할 수 있습니다.

\n

\n
제니퍼 화면 개발 중 웹팩 번들러에서 제공하는 hot reload를 사용합니다. 수정된 코드가 빌드되고 브라우저에 반영되는 과정에는 몇 초의 시간이 소요되어 답답한 경우가 종종 있습니다. 이는 제니퍼의 소스 코드 규모가 방대하고 웹팩을 그대로 사용하기 때문에 발생하는 현상일 수 있습니다. 물론 최근 Vercel에서 발표한 터보팩과 같은 번들러는 더 빠를 수도 있습니다.
\n

\n

네이버의 플러터 도입 과정

\n

최근에 데이빗과 플러터 스터디를 진행하면서 모니터링 스터디 주제로 선정해야겠다는 생각을 했었습니다. 관련해서 검색해보는데, 네이버의 플러터 도입 과정을 블로그에 자세히 올린게 있어서 개인적으로 느낀 점이 많아 이렇게 소개해보려고 합니다.

\n

먼저, 크로스플랫폼 도입을 검토하게 된 이유가 흥미로웠습니다. 네이버 정도되는 규모의 회사에서는 서비스 앱 개발을 어떤 프로세스로 진행하는지 어느 정도 파악할 수 있었습니다. 특히 디자인 단계에서의 어려움은 iOS와 안드로이드에서 모두 동일한 UI를 제공하려고 하더라도 구현하기 어려운 UI가 존재한다는 것이었습니다.

\n

각 플랫폼마다 개발, 테스트, 배포를 진행하며, 플랫폼 상황에 따라 배포 일정이 달라질 수 있고, 서비스 상황에 따라 개발자 불균형 문제가 발생할 수 있다는 점입니다. 또한, 기획을 제외하고 디자인부터 별도의 프로세스로 진행되는 것이 인상 깊었습니다.

\n

$\"image-4\"$

\n

이와 같은 상황에서 최대한 개발 효율성을 높이고자 다양한 방법을 시도했는데, 과거 네이버 블로그 앱 개발팀에 있던 시절에는 아래와 같은 방법을 시도했다고 말합니다.

\n

기술 공유
네이밍 컨벤션 맞추기
라이브러리 개발

\n

기술 공유의 경우에는 서로 다른 플랫폼 간에 도움을 주는 지식이 아니기 때문에 시간이 흐를수록 꾸준한 참여를 유지하기 어려웠으며, 플랫폼 별로 선호하는 네이밍 컨벤션이 다르고 개발 일정에 따라 매번 컨벤션을 맞추기 어렵다는 한계가 있었습니다.

\n

또한, 팀 내에서 라이브러리 개발을 담당하는 인원이 필요하다는 문제가 있었고, 꾸준한 관리가 어려워서 서비스 별로 다른 스펙을 라이브러리로 구현하기도 어렵다는 문제도 있습니다.

\n

다음은 플랫폼의 차이와 관련하여 비슷한 경험이 있는지 사내 모바일 개발자를 대상으로 설문 조사를 진행하여 다음과 같은 결과를 얻었습니다.

\n

$\"image-5\"$

\n

대다수 개발자들은 플랫폼에 특화된 스펙을 구현하는 것이 어려웠고, 개발자 불균형으로 인해 프로젝트 진행에 문제가 있었다는 것을 알 수 있습니다. 또한, 서비스 상황에 따라 크로스플랫폼이 필요하다고 생각하는 비율도 월등히 높았다고 언급합니다.

\n

결국 네이버는 프로토타입 프로젝트도 진행해 보고, 개발자 불균형 문제를 겪으면서 더 효율적인 개발 방법은 없을까 고민한 결과, 팀에서 크로스플랫폼을 검토하기로 결정했습니다. 대부분의 팀원들은 크로스플랫폼에 대해 회의적인 시각을 가졌으며, 네이티브 방식으로 개발한 앱보다 실행 성능이 낮을 것으로 예상하여 검토를 시작했다고 합니다. 하지만 검토를 진행하면서 이 부분이 편견이었음을 알았으며, 지식iN 앱을 플러터 기반으로 개발하고 정식 서비스를 시작했습니다.

\n

크로스플랫폼에 도전

\n

1차 테스트로 일주일 동안 6명의 개발자가 플러터, 리액트 네이티브, 자마린(xamarin), SCADE 4개의 크로스플랫폼에 대한 성능과 생산성을 검토했습니다. 크로스플랫폼 도입을 위한 과정이 체계적이고, 많은 노력을 기울였기 때문에 크로스플랫폼 도입을 검토하는 사람들에게 많은 도움이 될 것으로 생각합니다.

\n

$\"table-1\"$

\n

평가 기준을 바탕으로 각 플랫폼을 비교한 결과, 플러터가 가장 좋은 평가를 받았습니다. 특히, 플러터의 성능은 팀에서 기대한 것보다 훨씬 우수하게 나왔습니다. 화면 동작에서는 네이티브 방식과 구분하기 어려울 정도의 성능을 보였다고 합니다.

\n

네이버에서는 추가적인 검증을 위해 2차 테스트를 진행했는데, 플러터로 어떤 단계까지 구현이 가능한지 확인하기 위해 조금 더 난이도가 있는 앱을 과제로 삼았습니다. 약 2개월 동안 진행된 프로토타입 서비스를 플러터로 구현하기로 하고, iOS 개발자 4명과 안드로이드 개발자 3명이 약 2주 동안 테스트를 진행했습니다.

\n

추가 기능을 테스트하기 위해 라이브러리, Google 지도, 웹뷰, 커스텀 UI 등을 구현하여 확인한 결과, iOS 개발자 6명과 안드로이드 개발자 6명이 2개월 동안 개발한 서비스를 2주 만에 유사하게 구현했습니다.

\n

$\"table-2\"$

\n

팀원들의 공통적인 의견은 각각 네이티브 방식으로 개발할 때보다 훨씬 수월했다는 점입니다. 사용성 확인을 위해 UI에 굉장히 집중한 프로토타입 서비스에서는 플러터가 네이티브 방식보다 훨씬 빠르고 편하게 UI를 구현할 수 있기 때문입니다. 특히 안드로이드 개발자들의 만족도가 높았다고 합니다.

\n

다음은 2차 테스트를 마무리하고, 팀원들이 작성한 플러터에 대한 피드백을 요약한 내용입니다. 내용을 가볍게 살펴보시면 좋을 것 같습니다.

\n

$\"table-3\"$

\n

플러터 스터디를 하면서 느낀점

\n

다트 문법이 자바나 코틀린이랑 비슷하기 때문에 플러터 개발은 고대(?) 유물인 자바 스윙이 떠오르긴 했었는데, 전혀 아니었습니다. 네이버 팀에서 플러터로 개발할 때 개발 기간이 짧아진 이유에 대해 다트 언어의 어렵지 않은 문법과 플러터의 선언형 UI 방식 때문이라고 결론을 내렸는데, 제 생각도 동일합니다.

\n

선언형 UI 방식은 복잡한 UI를 작성할 때 이해하기에 더 직관적이기 때문에 유리합니다. 사실, 프론트엔드 개발자라면 익숙한 HTML이나 JSX, 뷰 템플릿 문법들은 모두 선언형으로 볼 수 있습니다.

\n

아래 코드를 비교하면 명령형과 선언형의 차이를 쉽게 이해할 수 있습니다.

\n

// Imperative style
b.setColor(red)
b.clearChildren()
ViewC c3 = new ViewC(...)
b.add(c3)

\n

Win32에서 웹, Android 및 iOS에 이르는 프레임워크는 일반적으로 명령형 UI 프로그래밍 스타일을 사용합니다. 이 스타일은 여러분이 가장 익숙한 스타일일 수 있는데, UIView 또는 이와 동등한 기능을 갖춘 UI 엔티티를 수동으로 구성하고 나중에 UI가 변경되면 메서드와 설정자를 사용하여 변경하는 방식입니다.

\n

// Declarative style
return ViewB(
  color: red,
  child: const ViewC(),
);

\n

반면, 플러터는 개발자가 다양한 UI 상태 간 전환 방법을 프로그래밍해야 하는 부담을 덜어주기 위해 개발자가 현재 UI 상태를 설명하고 전환은 프레임워크에 맡길 수 있도록 합니다.

\n

개발자 도구

\n

플러터 2.0부터 개발자 도구가 지원되었는데, 직접 사용해보니 매우 편리했습니다. 앞에서 언급한 hot reload와 함께 개발자 도구는 개발 생산성을 크게 향상시킬 것으로 기대됩니다.

\n

$\"image-6\"$

\n

예제 소개

\n

먼저, 웹툰 예제는 노마드코더의 클론 코딩 강의에서 다룬 내용을 따라서 구현한 것입니다. 플러터는 네이티브 앱 수준의 페이지 전환 효과를 쉽게 구현할 수 있도록 관련 API를 제공합니다. 강의 댓글 중에서 흥미로운 내용을 발견했는데, 리액트 네이티브로 동일한 기능을 구현하는 것은 매우 어렵다며, 플러터로는 정말 간단하게 구현할 수 있다는 점이 좋았다는 것이었습니다.

\n

플러터는 iOS의 쿠퍼티노 디자인 패키지를 지원하지만 네이티브 앱만큼 완벽하지는 않습니다. 시간이 지남에 따라 네이티브 앱과의 디자인 격차는 더 벌어질 것으로 예상됩니다. 필요에 따라 플러터의 디자인 패키지에서 제공하지 않는 UI를 개발해야 할 수도 있습니다. 이런 경우, 개발자는 CustomPainter 클래스를 상속받아 직접 캔버스에 그릴 수 있습니다.

\n

이렇게 구현한 클래스는 결국 플러터에서 제공되는 위젯들과 동일한 위젯으로 취급되기 때문에 기존의 위젯들과 함께 자연스럽게 사용할 수 있습니다. 제니퍼에서 캔버스를 활용하여 만든 컴포넌트들 중에는 기존의 마크업이나 스타일과 함께 사용되는 경우도 있지만, 서로 독립적인 부분도 있으며, 특히 이벤트를 구현할 때 고려해야 할 사항이 많습니다.

\n

마지막으로 플러터와 관련된 검색 중에 토스 앱에 있는 3D 인터랙션을 플러터로 구현한 예제를 발견했습니다. 개인적으로 토스의 UX/UI가 매우 훌륭하다고 생각하는데, 일부 기능 중 하나를 플러터로 쉽게 구현한 것을 보고 플러터의 가능성을 높게 평가하게 되었습니다.

\n

$\"image-7\"$

\n

페이지 전환 예제 : 페이지 전환시 효과를 쉽게 구현할 수 있습니다. (데스크탑 브라우저에서는 이미지가 보이지 않음)
캔버스 그리기 예제 : 캔버스에 그라디언트 효과를 주고, 심볼(별모양)을 직접 그려서 무작위로 화면에 보여지는 배경 위젯입니다.
3D 인터랙션 예제 : 토스 앱의 상품권 추가시 3D 인터랙션을 구현한 예제입니다.

\n

글을 마치며

\n

플러터 스터디를 진행하고 모니터링 스터디 발표 자료를 준비하면서 몇 가지 결론을 내리게 되었습니다. 첫째로, 데스크탑과 모바일은 완전히 다른 기획과 사용자 경험이 필요하다는 것입니다. 모바일은 프론트엔드 영역이 아니라 플랫폼에 종속된 전혀 다른 분야로 생각하고 크게 고민하지 않았습니다. 사실 플랫폼이 iOS와 안드로이드로 크게 나뉘어져 있기 때문에 어느 한 쪽을 선택하는 것이 어려웠습니다. 플러터 덕분에 이러한 선택의 어려움을 해결하고, 본격적으로 모바일 UX에 대해 알아볼 수 있게 되었습니다.

\n

두 번째로, 이건 지극히 개인적인 사정이긴 한데, 프레임워크의 발전과 ChatGPT의 등장으로 프론트엔드 개발자로서 성장의 한계를 느끼고 있던 시점에 플러터를 발견하여 데스크탑 웹을 넘어 여러 플랫폼으로 프론트엔드 역량을 확장해나가야겠다는 새로운 목표가 생겼습니다.

\n

데스크탑과 모바일을 모두 고려한 서비스가 무조건 성공하는 것은 아니지만, 현재 성공한 서비스들을 살펴보면 둘 중 하나만 지원되는 서비스는 드물다고 생각됩니다. 네이버의 플러터 도입 검토 과정을 보면 알 수 있듯이, 보다 적은 인원으로 네이티브 수준의 애플리케이션을 개발할 수 있다는 것은 개발 인원이 적은 조직에서 충분히 고려해볼 만하다고 생각합니다.

\n

참고 링크

\n

", "url": "https://alvin.ing/blog/introduction-to-flutter", "title": "크로스플랫폼 앱 개발을 위한 플러터 소개", "summary": "플러터란?", "date_modified": "2023-10-10T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "Dark", "Flutter", "iOS", "Android" ] }, { "id": "https://alvin.ing/blog/react-server-components", "content_html": "

개요

\n

2020년 12월 React 팀은 서버 주도(Server-Driven) 멘탈 모델로써 모던 UX를 가능하게 하는 것을 목표로 하는 zero-bundle React 서버 컴포넌트를 시연했습니다. 이때 소개한 서버 컴포넌트는 서버 사이드 렌더링(SSR)과는 상당히 다르며 클라이언트 측 번들 크기를 매우 줄일 수 있다고 하였으며, 서버와 클라이언트(브라우저)가 React 애플리케이션을 서로 협력하여 렌더링 할 수 있게 됩니다.

\n

그리고 2022년 10월 Next.js Conf에서 Next.js 13부터 React 서버 컴포넌트를 지원한다고 발표했습니다. 처음 서버 컴포넌트를 소개한 후, 시간이 꽤 지났음에도 불구하고, 아직도 실험적인 단계이긴 하지만 Next.js 기반으로 서버 컴포넌트를 구현해볼 수 있게 되었습니다. Next.js 관련해서는 데이빗이 작성한 문서를 참고하시면 됩니다.

\n

SSR의 한계

\n

오늘날 자바스크립트의 서버 사이드 렌더링(SSR)은 초기 페이지 로드 시간을 개선하기 위한 차선책입니다. 컴포넌트의 자바스크립트는 서버에서 HTML 문자열로 렌더링됩니다. HTML은 브라우저에게 전달되고 나타나며, 빠른 FCP(First Contentful Paint) 혹은 LCP(Largest Contentful Paint)를 가지게 됩니다.

\n

하지만 Hydration 단계를 통해 인터렉션이 가능해진 엘리먼트를 위해서는 여전히 자바스크립트가 필요합니다. 서버 사이드 렌더링은 일반적으로 최초 페이지 로드를 위해 사용되기 때문에 Hydration 이후에는 추가적으로 쓰이지 않습니다.

\n

클라이언트에서의 Hydration을 전혀 하지 않고, React와 SSR만 가지고 애플리케이션을 만들 수도 있지만 애플리케이션에서 인터렉션을 많이 해야 하는 경우에는 어쩔 수 없이 클라이언트 측으로 코드를 보내야 합니다. 서버 컴포넌트의 하이브리드 모델은 이 선택을 컴포넌트 기준으로 가능하도록 해줍니다.

\n

React의 서버 컴포넌트를 활용하면 컴포넌트들을 정기적으로 다시 받아올 수 있습니다. 새로운 데이터가 있을 때 서버에서 애플리케이션의 컴포넌트들을 리-렌더링 할 수 있으므로 클라이언트 측에 전송해야 하는 코드량을 줄일 수 있습니다.

\n

SSR은 서버에서 HTML을 생성하고 클라이언트로 전송하는 방식입니다. SSR은 초기 로딩 속도를 높일 수 있지만 RSC는 더 많은 기능을 제공합니다.

\n

\n
Hydration이란?
\n
\n
컴포넌트를 렌더링하고, 이벤트 핸들러를 연결하는 프로세스
\n
서버 단에서 렌더링한 정적 컨텐츠와 번들링 된 JS 파일을 클라이언트에게 보낸 뒤, 클라이언트 단에서 HTML 코드와 React인 JS 코드를 서로 매칭 시키는 과정
\n
\n

\n

RSC vs SSR

\n

결론부터 말하자면 RSC는 SSR을 대체할 수 없습니다. SSR은 해당 페이지의 HTML 코드를 미리 빌드합니다. 이것은 SEO에 효과적이고, 사용자가 자바스크립트 코드를 다운받는 동안 해당 페이지의 내용을 미리 볼 수 있습니다. 즉, SSR은 해당 페이지 자체를 렌더링하는 것이고, 서버 컴포넌트는 각각의 컴포넌트마다 클라이언트 컴포넌트로 렌더링 할 것인지 서버 컴포넌트로 렌더링 할 것인지를 선택해야 합니다.

\n

Next.js와 SSR의 차이점에 대해 Dan과 Lauren의 talk에서 언급한 내용을 정리해 보면:

\n

서버 컴포넌트의 코드는 클라이언트로 전달되지 않습니다. 하지만 서버 사이드 렌더링의 모든 컴포넌트의 코드는 자바스크립트 번들에 포함되어 클라이언트로 전송됩니다.
서버 컴포넌트는 페이지 레벨에 상관없이 모든 컴포넌트에서 서버에 접근 가능합니다. 하지만 Next.js의 경우 가장 top level의 페이지에서만 getServerProps()나 getInitialProps()로 서버에 접근 가능합니다.
서버 컴포넌트는 클라이언트 상태를 유지하며 re-fetch 될 수 있습니다. 서버 컴포넌트는 HTML이 아닌 특별한 형태로 컴포넌트를 전달하기 때문에 필요한 경우 포커스, 인풋 입력값 같은 클라이언트 상태를 유지하며 여러 번 데이터를 가져오고 리렌더링하여 전달할 수 있습니다. 하지만 SSR의 경우 HTML로 전달되기 때문에 새로운 re-fetch가 필요한 경우 HTML 전체를 다시 렌더링 해야 하며, 이로 인해 클라이언트 상태를 유지할 수 없습니다.

\n

탄생 배경

\n

React 팀은 다방면으로 성능 향상을 해왔으나 Data Fetching의 경우, 사용자와 개발자 경험 모두를 만족시킬 수있는 방법을 찾기가 어려웠습니다. React 컴포넌트의 비동기적 Data Fetching의 가장 큰 문제점은 클라이언트와 서버 간 요청의 High Latency와 연속된 클라이언트-서버 API 요청으로 발생하는 Waterfall이었습니다.

\n

$\"image-1\"$

\n

이와 같이 클라이언트 컴포넌트에서 비동기 Data Fetching은 클라이언트-서버의 Waterfall을 야기하고, 성능을 저하시키는 원인이 됩니다.

\n

이를 위한 해결책으로 서버 컴포넌트가 탄생하게 되었으며, RSC는 용어 그대로 서버에서 동작하는 React 컴포넌트입니다. 서버 컴포넌트를 사용하면 컴포넌트 렌더링을 클라이언트가 아닌 서버에서 수행할 수 있습니다.

\n

서버에서 렌더링을 수행하기 때문에 API를 통한 데이터 요청의 Latency를 줄일 수 있고, 클라이언트에서의 연속된 API 호출을 제거하여, 클라이언트-서버의 Waterfall을 막을 수 있습니다.

\n

$\"image-2\"$

\n

아쉽게도 서버 컴포넌트에서의 데이터 요청을 처리하여도 중첩된 컴포넌트에서의 여러 API 요청에 따른 네트워크 Waterfall은 여전히 존재합니다.

\n

하지만 서버 컴포넌트는 서버에서 동작하고 렌더링 된다는 특성상 다양한 종류의 백엔드 리소스에 접근할수 있고, HTML이 아닌 ‘특별한’ 형태로 렌더링 되어 클라이언트에 전달되기 때문에 클라이언트로 전달되는 번들 사이즈 또한 감소시킬 수 있습니다.

\n

서버 컴포넌트란?

\n

React가 UI를 구축하는 방식을 바꾼 것과 유사하게, 서버와 클라이언트를 활용하는 하이브리드 애플리케이션을 구축하기 위한 새로운 사고 모델을 도입했습니다.

\n

SPA의 경우처럼 전체 애플리케이션을 클라이언트 측에서 렌더링하는 대신, React는 이제 컴포넌트의 목적에 따라 렌더링할 위치를 선택할 수 있는 유연성을 제공합니다.

\n

$\"image-3\"$

\n

페이지를 더 작은 컴포넌트로 분할하면 대부분의 컴포넌트가 비대화형이며 서버에서 서버 컴포넌트로 렌더링 할 수 있음을 알 수 있습니다. 더 작은 인터랙티브 UI의 경우, 클라이언트 컴포넌트로 나타낼 수 있습니다. 이는 Next.js의 서버 우선 접근 방식과 일치합니다.

\n

서버 컴포넌트의 특징을 정리하면 다음과 같습니다.

\n

자유로운 서버 리소스 접근 : 데이터베이스, 파일 시스템 등등
제로 번들 사이즈 컴포넌트 : 서버 컴포넌트는 브라우저에 다운로드 되지 않고, 서버에서 미리 렌더링 된 정적 컨텐츠로 전달됨
자동 코드 분할 : 서버 컴포넌트에서 Import 되는 모든 클라이언트 컴포넌트를 코드 분할 포인트로 간주하기 때문에 Lazy 로드가 필요하지 않음

\n

클라이언트와 서버 컴포넌트 구성하기

\n

서버에서 React는 결과를 클라이언트로 보내기 전에 모든 서버 컴포넌트를 렌더링 합니다. 그리고 클라이언트에서 React는 클라이언트 컴포넌트를 렌더링하고 서버 컴포넌트의 렌더링 결과에 슬롯을 생성하여 서버와 클라이언트에서 수행한 작업을 병합합니다.

\n

클라이언트 컴포넌트는 코드 상단에 ‘use client’ 디렉티브를 명시해야 합니다. 그리고 서버 컴포넌트를 import 할 수 없습니다.

\n

대신 클라이언트 컴포넌트를 디자인 할 때, React 프로퍼티를 사용하여 서버 컴포넌트의 “holes”를 표시할 수 있습니다. 서버 컴포넌트는 서버에서 렌더링되고, 클라이언트 컴포넌트가 클라이언트에서 렌더링되면 서버 컴포넌트의 렌더링 된 결과로 “hole”이 채워집니다.

\n

일반적인 패턴은 React의 children 프로퍼티를 사용하여 “hole”을 만드는 것입니다.

\n

'use client';
 
import { useState } from 'react';
 
export default function ExampleClientComponent({
  children,
}: {
  children: React.ReactNode;
}) {
  const [count, setCount] = useState(0);
 
  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>
 
      {children}
    </>
  );
}

\n

<ExampleClientComponent>는 자식 컴포넌트가 무엇인지 전혀 알지 못합니다. 사실, 이 컴포넌트의 관점에서는 자식들이 결국 서버 컴포넌트의 결과에 의해 채워질 것이라는 사실조차 알지 못합니다.

\n

// This pattern works:
// You can pass a Server Component as a child or prop of a
// Client Component.
import ExampleClientComponent from './example-client-component';
import ExampleServerComponent from './example-server-component';
 
// Pages in Next.js are Server Components by default
export default function Page() {
  return (
    <ExampleClientComponent>
      <ExampleServerComponent />
    </ExampleClientComponent>
  );
}

\n

그리고 서버 컴포넌트는 클라이언트 컴포넌트를 Import 할 수 있지만 서버에서 클라이언트 컴포넌트로 전달되는 프로퍼티는 직렬화가 가능해야 합니다. 즉, 함수나 날짜 등과 같은 값은 클라이언트 컴포넌트에 직접 전달할 수 없습니다.

\n

다음은 클라이언트와 서버 컴포넌트의 특징을 정리한 표입니다.

\n

특징	서버	클라이언트
데이터 가져오기	O	X
백엔드 리소스에 직접 액세스 (직접)	O	X
서버에 민감한 정보 보관 (액세스 토큰, API 키 등)	O	X
서버에 대한 대규모 종속성 유지 / 클라이언트 측 자바스크립트 감소	O	X
인터랙티브 및 이벤트 리스너 추가 (onClick, onChange 등)	X	O
상태 및 라이프사이클 효과 사용 (useState, useReducer, useEffect 등)	X	O
브라우저 전용 API 사용	X	O
상태, 효과 또는 브라우저 전용 API에 의존하는 사용자 지정 후크 사용	X	O
React 클래스 컴포넌트 사용	X	O

\n

데모 살펴보기

\n

데모 화면은 Postgres DB에 저장된 사용자 목록을 가져와서 테이블 형태로 보여줍니다. 캐시 처리를 위해 Redis에 사용자 목록을 10초간 보관합니다.

\n

// lib/service.ts

import kv from \"@vercel/kv\";
import { sql } from \"@vercel/postgres\";

export interface User {
  id: number;
  name: string;
  image: string;
  email: string;
  createdAt: Date;
}

export async function getUsers(cacheKey: string) {
  const cachedData = await kv.get<User[]>(`users-${cacheKey}`);
  if (cachedData === null) {
    const data = await sql<User>`SELECT * FROM users`;
    await kv.set(`users-${cacheKey}`, JSON.stringify(data.rows), { ex: 10, nx: true })
    return data.rows;
  } else {
    return cachedData;
  }
}

\n

// app/api/route.ts

import { getUsers } from '@/lib/service';
import { NextResponse } from 'next/server';

export async function GET(request: Request) {
    return NextResponse.json({ users: await getUsers('client') });
}

\n

아래는 클라이언트 컴포넌트로 구현된 테이블 컴포넌트입니다. 데이터를 가져오기 위해 /api/users를 호출하고, API 내부에는 앞에서 구현한 서비스 함수를 사용합니다.

\n

// components/client-table.tsx

'use client'

import type { User } from '@/lib/service';
import { useState, useEffect } from 'react';
import ReloadButton from './reload-button'
import TableHead from './table-head';
import TableRow from '@/components/table-row';

export default function ClientTable() {
  const [users, setUsers] = useState<User[]>([]);
  const [duration, setDuration] = useState<number>(0);
  const [loading, setLoading] = useState<boolean>(false);

  const loadData = () => {
    let startTime = Date.now();
    setLoading(true);
    fetch('/api/users')
      .then((res) => res.json())
      .then((data) => {
          setUsers(data.users)
          setDuration(Date.now() - startTime)
          setLoading(false)
      })
  }

  useEffect(() => {
    loadData();
  }, [])

  return (
    <div className=\"bg-white/30 p-12 shadow-xl ring-1 ring-gray-900/5 rounded-lg backdrop-blur-lg max-w-xl mx-auto w-full\">
      <TableHead userCount={users.length} duration={duration}>
        <ReloadButton onClick={loadData} loading={loading} />
      </TableHead>
      <div className=\"divide-y divide-gray-900/5\">
        {users.map((user, index) => (
          <TableRow key={index} user={user}></TableRow>
        ))}
      </div>
    </div>
  )
}

\n

클라이언트 컴포넌트와 달리 API 호출을 위한 코드는 생략하고, 앞에서 구현한 서비스 함수를 바로 사용할 수 있습니다.

\n

// components/server-table.tsx

import { getUsers } from '@/lib/service';
import RefreshButton from './refresh-button'
import TableHead from './table-head';
import TableRow from './table-row';

export default async function ServerTable() {
  const startTime = Date.now()
  const users = await getUsers('server');
  const duration = Date.now() - startTime

  return (
    <div className=\"bg-white/30 p-12 shadow-xl ring-1 ring-gray-900/5 rounded-lg backdrop-blur-lg max-w-xl mx-auto w-full\">
      <TableHead userCount={users.length} duration={duration}>
        <RefreshButton />
      </TableHead>
      <div className=\"divide-y divide-gray-900/5\">
        {users.map((user, index) => (
          <TableRow key={index} user={user}></TableRow>
        ))}
      </div>
    </div>
  )
}

\n

데모 화면과 소스 코드는 아래 링크를 통해 직접 확인할 수 있습니다.

\n

Demo
GitHub

\n

글을 마치며

\n

이번 스터디 발표 준비를 하면서 RSC에 대해 알아보고 이해하는 과정을 겪으면서 느꼈던 점은 언젠가 APM 에이전트 라인업에 RSC가 포함될 수도 있을 것 같다는 생각이 들었습니다.

\n

지금처럼 프론트엔드와 백엔드 개발 영역의 구분이 명확하지 않았던 시절의 웹 개발을 했던 모습도 떠오릅니다. 물론 그때와 지금은 엄청난 차이가 있고, 자바스크립트는 웹 페이지의 인터랙티브 한 기능을 제공하기 위한 보조적인 역할만 했던 시기이기도 합니다.

\n

RSC가 추구하는 방향성을 이해하려고 하다보니 문득 이런 생각이 들었습니다. 어쩌면 다시 옛날처럼 프론트엔드와 백엔드를 구분하지 않고 개발하는 시대가 올 수도 있겠구나. 다만, 과거와 달리 앞으로는 메인은 화면 개발이고, 서브로 렌더링 성능 개선을 위한 서버 개발을 해야하는 상황이 올 수도 있겠다는 생각을 했습니다. (프론트엔드 개발자 기준에서…)

\n

앞으로 웹 생태계에 어떤 변화가 다가올지 알 수는 없지만 한가지 분명한 것은 RSC가 큰 영향을 줄 수 있을 것 같습니다. 그래서 꾸준한 관심과 기대를 가져볼만하다고 생각합니다.

\n

참고 링크

\n

문서를 읽고 이해하는 것보다 직접 구현해보는게 나을 것 같아서 이번에도 데모 개발에 시간을 많이 할애했습니다. 본문 내용의 대부분은 아래 문서를 인용한 것이니 참고하시길 바랍니다.

\n

", "url": "https://alvin.ing/blog/react-server-components", "title": "RSC(React Server Components) 살펴보기", "summary": "개요", "date_modified": "2023-03-15T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "React", "React Server Components", "Next.js" ] }, { "id": "https://alvin.ing/blog/d3-hierarchy", "content_html": "

children을 포함하는 계층 데이터

\n

D3에서 사용할 데이터를 정의할 때, 부모-자식 관계를 정하기 위해서 children을 반드시 포함시켜야 합니다.\nchildren에 자식 노드를 추가하면서 계층 데이터 형태로 구성할 수 있습니다.

\n

interface TreeData {
    id: string;
    children?: TreeData[];
}

const TREE_DATA: TreeData = {
    id: 'Chaos',
    children: [
        {
            id: 'Gaia',
            children: [
                {
                    id: 'Mountains',
                },
                {
                    id: 'Pontus',
                },
                {
                    id: 'Uranus',
                },
            ],
        },
        {
            id: 'Eros',
        },
        {
            id: 'Erebus',
        },
        {
            id: 'Tartarus',
        },
    ],
};

\n

기본적인 Hierarchy 객체 생성하기

\n

hierarchy 함수를 호출하면 D3에서 정의한 HierarchyNode 타입의 객체가 리턴되며, 각각의 프로퍼티에 대한 설명은 다음과 같습니다.

\n

children : 자식 노드들
data : 사용자가 정의한 데이터
depth : 트리에서 자신의 노드의 깊이
height : 자식 노드의 최대 깊이
parent : 부모 노드 없으면 null

\n

const root = hierarchy<TreeData>(TREE_DATA);

console.log(root);
{
  children: [Node, Node, Node, Node],
  data: {id:  \"Chaos\", children: Array(4)}
  depth: 0,
  height: 2,
  parent: null
}

\n

레이아웃 객체 생성하기

\n

앞에서 생성한 객체를 가지고, D3에서 제공하는 레이아웃 객체를 생성할 수 있습니다.\n아래는 트리를 그리기 위한 레이아웃 객체를 생성하는 코드이며, HierarchyNode 타입을 상속한 HierarchyPointNode 타입의 객체로 변경됩니다.

\n

x, y 프로퍼티가 추가된 것을 확인할 수 있으며, 캔버스나 SVG로 무엇인가 그릴 때, 해당 값을 그대로 사용하면 됩니다.

\n

HierarchyNode 타입을 상속하는 타입은 HierarchyPointNode 외에도 HierarchyRectangularNode, HierarchyCircularNode 타입이 있습니다.

\n

const treeLayout = tree().size([WIDTH, HEIGHT]);
treeLayout(root);

console.log(root);
{
  children: [Node, Node, Node, Node],
  data: {id:  \"Chaos\", children: Array(4)}
  depth: 0,
  height: 2,
  parent: null,
  x: 233.33333333333334,
  y: 0
}

\n

로우셋을 계층 데이터로 변환하기

\n

때로는 children 프로퍼티가 포함되어있지 않고, 부모 키만 알고 있는 데이터를 가지고 있을 수 있습니다.

\n

interface RowData1 {
    id: string;
    parentId?: string;
}
interface RowData2 {
    id2: string;
    pid?: string;
}

const ROW_DATA_1: RowData1[] = [
    { id: 'Chaos' },
    { id: 'Gaia', parentId: 'Chaos' },
    { id: 'Eros', parentId: 'Chaos' },
    { id: 'Erebus', parentId: 'Chaos' },
    { id: 'Tartarus', parentId: 'Chaos' },
    { id: 'Mountains', parentId: 'Gaia' },
    { id: 'Pontus', parentId: 'Gaia' },
    { id: 'Uranus', parentId: 'Gaia' },
];

const ROW_DATA_2: RowData2[] = [
    { id2: 'Chaos' },
    { id2: 'Gaia', pid: 'Chaos' },
    { id2: 'Eros', pid: 'Chaos' },
    { id2: 'Erebus', pid: 'Chaos' },
    { id2: 'Tartarus', pid: 'Chaos' },
    { id2: 'Mountains', pid: 'Gaia' },
    { id2: 'Pontus', pid: 'Gaia' },
    { id2: 'Uranus', pid: 'Gaia' },
];

\n

D3에서는 children과 마찬가지로 id와 parentId 프로퍼티를 스스로 인식합니다.\nstratify 함수를 사용하면 hierarchy 함수와 동일한 객체를 리턴하게 됩니다.

\n

하지만 데이터 id와 parentId 프로퍼티가 포함되어 있지 않다면 id와 parentId 메소드를 통해 부모-자식 관계를 설정할 수 있습니다.

\n

const root1 = stratify<RowData1>()(ROW_DATA_1);
const root2 = stratify<RowData2>()
    .id((data) => data.id2)
    .parentId((data) => data.pid)(ROW_DATA_2);

console.log(root2);
{
  children: [Node, Node, Node, Node],
  data: {id:  \"Chaos\", children: Array(4)}
  depth: 0,
  height: 2,
  parent: null
}

\n

Hierarchy 객체의 메소드 소개

\n

계층 데이터를 쉽게 핸들링할 수 있는 몇가지 메소드들을 소개합니다.

\n

const chaos = root2;
const gaia = chaos.children[0];
const pontus = chaos.children[0].children[1]
const tartarus = chaos.children[3];

\n

ancestors

\n

자신을 포함하여 루트까지 모든 부모 노드의 배열을 반환합니다.

\n

gaia.ancestors();

\n

$\"ancestors-1\"$

\n

pontus.ancestors();

\n

$\"ancestors-2\"$

\n

descendants

\n

자신을 포함하여 모든 자식 노드의 배열을 반환합니다.

\n

gaia.descendants();

\n

$\"descendants\"$

\n

leaves

\n

해당 노드의 자식 중에 자식이 없는 노드의 배열을 반환합니다

\n

gaia.leaves();

\n

$\"leaves\"$

\n

path

\n

해당 노드부터 대상 노드까지 연결된 모든 노드의 배열을 반환합니다.

\n

노드 순서

Tartarus -> Chaos -> Gaia -> Pontus

\n

tartarus.path(pontus);

\n

$\"path\"$

\n

links

\n

해당 노드의 자식 링크를 나타내는 객체 배열을 반환합니다. 각 링크 객체의 target은 자식이고, source는 부모입니다.\ngaia의 자식 노드인 mountains, pontus, uranus를 target으로 가진 HierarchyPointLink 타입을 가지는 배열을 리턴합니다.

\n

앞에서 트리 레이아웃을 사용했기 때문에 HierarchyLink가 아닌 HierarchyPointLink 타입의 객체를 리턴합니다.\n그 밖에도 HierarchyCircularLink, HierarchyRectangularLink 타입이 있습니다.

\n

gaia.links();

\n

$\"descendants\"$

", "url": "https://alvin.ing/blog/d3-hierarchy", "title": "D3 Hierarchy 모듈로 데이터 핸들링하기", "summary": "children을 포함하는 계층 데이터", "date_modified": "2023-02-12T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "D3.js" ] }, { "id": "https://alvin.ing/blog/offscreen-canvas-api", "content_html": "

캔버스 애니메이션의 문제점

\n

웹 개발시 다이나믹한 그래픽 처리가 필요하면 캔버스를 사용합니다.\n이제 캔버스는 HTML 엘리먼트 중에서 사용 통계가 40%가 넘을 정도로 아주 범용적입니다.

\n

$\"Example$

\n

캔버스는 애니메이션을 잘 처리하기 위한 목적으로 나온 태그이지만 현실은 다이나믹한 그래픽 처리에 어려움이 있습니다.

\n

자바스크립트 엔진과 렌더링 엔진 사이의 바인딩 오버헤드 발생
GPU 가속을 사용하더라도 Skia 내부의 오버헤드 발생
GPU 가속 쓰더라도 CPU를 써야하는 부분에서 페인팅 라이브러리 오버헤드 발생
위 프로세스 처리 후 DOM 렌더링을 처리하기에도 벅찬 메인 스레드

\n

$\"Example$

\n

프레임 드랍이 발생하지 않게 하기 위해서는 메인 스레드에서 1프레임(16.7ms) 안에 DOM, Javascript, Painting을 처리하고, 남는 시간에 캔버스 렌더링을 시도해야 합니다.\n하지만 메인 스레드는 위 그림처럼 이미 많은 일을 하고 있는 경우가 많습니다.

\n

기존의 문제점 개선 방법

\n

풀 스크린으로 캔버스 렌더링하기

\n

UI에 제약이 생기지만 캔버스를 풀 스크린으로 렌더링하면 핸들링할 Target DOM 이 없기 때문에 메인 스레드 자원을 더 사용할 수 있으며, GPU 가속까지 붙이면 성능을 개선할 수 있습니다.\n애니메이션을 전체 화면에서 처리할 경우는 고려해볼 수 있는 선택지입니다.

\n

백그라운드 캔버스

\n

프리젠테이션용, 백그라운드용 캔버스를 두개 만듭니다.\n백그라운드에서 여러 오브젝트를 다 그린 다음에 프레젠테이션 캔버스에 백그라운드 캔버스에서 그린 오브젝트를 가져와 한번에 한번에 엎어치기 하는 방식입니다. (현재 제니퍼 대시보드 차트에서도 사용되고 있는 방식)

\n

오프스크린 캔버스를 사용한 개선

\n

이미 사용되고 있는 WebWorker API를 통해 새로운 스레드 생성하여 렌더링 처리를 시도할 수 있으며, 캔버스를 DOM에서 분리할 수 있습니다.

\n

등장 배경

\n

자바스크립트 부하를 줄이기 위해 다른 스레드에서 실행할 수 있으면 좋겠음
크진 않지만 스키아의 부하를 줄이기 위해 다른 스레드에서 실행하면 좋겠음
DOM 렌더링과 분리되면 좋겠음

\n

제약 사항

\n

WebWorker에서는 직접적으로 DOM 엑세스가 불가능합니다.\n캔버스가 HTML(DOM)이기에 메인 스레드에서 분리가 불가능합니다.(HTML은 JS, CSS 등 다른 자원에서 DOM 트리 접근시 싱크가 맞아야 하는데, 다른 스레드에서 처리하게 되면 싱크 이슈가 발생함)\nReact, Vue와 같이 Shadow DOM을 사용하게 되면 Atomic 하게 처리할 수 있습니다.

\n

개발 방식

\n

OffscreenCanvas 객체에서 만들어진 프레임을 동기적으로 화면에 보여주는 방법

\n

새 프레임이 컨텍스트에 렌더링이 되고나면, 가장 최근에 렌더링 된 이미지를 저장하는 transferToImageBitmap 메소드를 호출할 수 있습니다. 이 메소드는 다른 수 많은 Web API에서 사용되고 있는 ImageBitmap 객체를 리턴합니다.
<canvas> 엘리먼트를 여러개 생성하여 더블버퍼링 구현을 할 필요가 없으며, 프레젠테이션 캔버스에 비트맵 복사가 일어나지 않기 때문에 성능상 이점이 있습니다.

\n

var one = document.getElementById(\"one\").getContext(\"bitmaprenderer\");
var two = document.getElementById(\"two\").getContext(\"bitmaprenderer\");

var offscreen = new OffscreenCanvas(256, 256);
var gl = offscreen.getContext('webgl');

// ... gl 컨텍스트를 이용해 첫 번째 캔버스에 무언가를 그립니다 ...

// 첫 번째 캔버스에 렌더링을 수행합니다.
var bitmapOne = offscreen.transferToImageBitmap();
one.transferFromImageBitmap(bitmapOne);

// ... gl 컨텍스트를 이용해 두 번째 캔버스에 무언가를 그립니다 ...

// 두 번째 캔버스에 렌더링을 수행합니다.
var bitmapTwo = offscreen.transferToImageBitmap();
two.transferFromImageBitmap(bitmapTwo);

\n

OffscreenCanvas 객체에서 만들어진 프레임을 비동기적으로 화면에 보여주는 방법

\n

worker 또는 메인 스레드 위에서 <canvas> 엘리먼트의 transferControlToOffscreen 메소드를 호출하여, OffscreenCanvas 객체를 얻고, 해당 컨텍스트는 worker에서 새 프레임을 렌더링 할 수 있습니다.

\n

// main.js (메인 스레드 코드)
var htmlCanvas = document.getElementById(\"canvas\");
var offscreen = htmlCanvas.transferControlToOffscreen();

var worker = new Worker(\"offscreencanvas.js\");
worker.postMessage({canvas: offscreen}, [offscreen]);

\n

// offscreencanvas.js (worker 코드)
onmessage = function(evt) {
  const canvas = evt.data.canvas;
  const gl = canvas.getContext(\"webgl\");

  function render(time) {
    // ... gl 컨텍스트를 이용해 무언가를 그립니다 ...
    requestAnimationFrame(render);
  }
  requestAnimationFrame(render);
};

\n

데모

\n

데모 화면은 다음과 같이 구성되어 있습니다.

\n

일반 캔버스 샘플
메인 스레드에서 동작하는 오프스크린 캔버스 샘플
worker에서 동작하는 오프스크린 캔버스 샘플

\n

$\"Example$

\n

결론

\n

기존의 캔버스 관련 코드는 고치지 않고, WebWorker로만 옮겨가서 그대로 사용할 수 있습니다. 다만, 이벤트 처리와 데이터 가져오는 방식에 대한 고민이 필요합니다.
메인 스레드와 worker 간의 데이터 전송을 위한 postMessage 함수 사용은 지양해야 합니다.
postMessage 함수 사용시 정책상의 이유로 데이터 복사본이 생성되는데, 이때 오버헤드가 발생합니다. (WebWorker API를 사용하지 않는 가장 큰 이유) 그래서 데이터 가져오는 코드를 worker 안에서 처리하면 좋습니다.
웹팩 같은 번들러의 도움으로 worker 안에서 미리 작성한 모듈 재사용이 가능합니다.
Zero-copy 백그라운드 렌더링을 오프스크린 캔버스로 구현할 수 있습니다.
크롬 69 버전과 파이어폭스 105 버전(지난 달인 9월 20일 릴리즈)부터 지원됩니다. 오프스크린 캔버스의 사용률은 공개된 이후부터 지속적으로 증가해서 현재는 25%가 넘었습니다. 많은 프론트엔드 개발자들이 캔버스의 문제점을 인식하고, 개선하기 위한 방법으로 오프스크린 캔버스를 선택한 것이라고 생각합니다.

\n

$\"Example$

\n

Three.js에서 오프스크린 캔버스를 사용할 수 있습니다.
WebGL 및 WebXR을 오프스크린 캔버스로 구현할 수 있습니다.

\n

참고

\n

", "url": "https://alvin.ing/blog/offscreen-canvas-api", "title": "OffscreenCanvas API 살펴보기", "summary": "캔버스 애니메이션의 문제점", "date_modified": "2022-11-15T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "Canvas", "OffscreenCanvas" ] }, { "id": "https://alvin.ing/blog/d3-scale", "content_html": "

개요

\n

D3 스케일(=척도)은 시각화의 기본 작업을 위한 편리한 추상화 모델입니다.\n추상 데이터의 차원을 시각적 표현으로 매핑합니다.\n예를 들어 산점도 차트에서 x축과 y축에 대한 값을 픽셀 단위로 변경하는 것처럼 정량적 데이터를 좌표 값으로 변경하는 데 가장 많이 사용됩니다.\n스케일은 색상, 선, 폭 또는 심볼 크기와 같은 거의 모든 시각적 인코딩을 나타낼 수 있습니다.\n또한 정의된 범주형 데이터 또는 구분이 필요한 개별 데이터와 같은 거의 모든 유형의 데이터와 함께 사용할 수 있습니다.

\n

scaleLinear (선형)

\n

가장 보편적으로 사용하는 스케일이며, 다른 스케일과 마찬가지로 domain(정의역)과 range(치역)만 기억하면 됩니다.\ndomain은 입력 값, range는 입력 값에 대응하는 출력 값입니다.\ninvert는 반대로 출력 값을 입력 값으로 넣으면 원래의 입력 값을 반환하는 역함수입니다.

\n

\n
y = mx + b
\n

\n

const func = scaleLinear().domain([0, 10]).range([0, 80]);
func(2); // return 16;
func(5); // return 40;
func(6); // return 48
func(15); // return 120

\n

clamp(true)

ticks(3)

0

5

10

invert

0

\n

scalePower (지수)

\n

결과 값을 보간하기 위해 제공되는 함수이며, 지수(exponent)에 따라 결과 값을 서서히 늘리거나 줄일 수 있습니다.

\n

\n
y = mx^k + b
\n

\n

거듭제곱을 하다보면 기하급수적으로 값이 커지기 때문에 D3 스케일에서는 domain 범위에 맞게 별도의 보정을 합니다.\n(Math.pow(입력값, exponent) / Math.pow(최대값, exponent - 1))

\n

const func = scaleLinear().domain([0, 100]).range([10, 50]);
func(0); // return 10;
func(25); // return 20;
func(50); // return 30
func(75); // return 40
func(100); // return 50

const func2 = scalePow().exponent(0.5).domain([0, 100]).range([10, 50]);
const func3 = scaleSqrt().domain([0, 100]).range([10, 50]);
const func4 = scalePow().exponent(2).domain([0, 100]).range([10, 50]);

\n

exponent(0.5)

sqrt

exponent(2)

linear colors

sqrt or exponent(0.5) colors

exponent(2) colors

\n

scaleLog, scaleSymlog (로그)

\n

최대값이 극단적으로 클 경우, 결과값의 분포를 비교적 완만하게 보정해주는 스케일입니다.\nSymlog 함수는 대칭 로그를 의미하며, 양수 및 음수 값을 허용합니다.

\n

\n
y = mlog(x) + b
\n

\n

const data = [ 10, 100, 10000, 1000000 ];

\n

linear

log

\n

scaleBand (밴드)

\n

Linear 스케일과 비슷하게 동작하지만 domain 사이에 여백(padding)을 비율로 설정할 수 있으며, 일반적으로 바나 컬럼 차트를 구현할 때, 사용하는 목적으로 만들어졌습니다.

\n

$\"Example$

\n

const DOMAIN = [0, 1, 2, 3];
const RANGE = [0, 400];

const func1 = scaleBand<number>().domain(DOMAIN).range(RANGE);
const func2 = scaleBand<number>().domain(DOMAIN).range(RANGE)
.paddingInner(0.6);
const func3 = scaleBand<number>().domain(DOMAIN).range(RANGE)
.paddingOuter(0.2).align(0.5); // 0이면 맨 왼쪽으로 당김

\n

no padding (step:100)

inner padding (step:117.64705882352942)

outer padding (step:90.9090909090909)

\n

scalePoint (점)

\n

Band 스케일과 달리 domain 개별로 여백이 적용되며, bandwidth 개념이 없고, (최대 range/domain 수)로 시작점을 정합니다.

\n

$\"Example$

\n

no padding (step:133.33333333333334)

padding (step:125)

\n

scaleTime (시간)

\n

Linear 스케일과 동일하지만 domain 범위를 Date 객체로 정할 수 있습니다.\n앞에서 설명한 ticks 함수를 사용하여 X축을 구현하고, 마우스 오버시 구해지는 실제 좌표값을 invert 함수로 넘겨서 현재 시간을 구합니다.

\n

const now = Date.now();
const start = new Date(now - 1000 * 60 * 60);
const end = new Date(now);

const func = scaleTime().domain([start, end]).range([0, 600]);

\n

7:44:10 AM

06:45

06:50

06:55

07:00

07:05

07:10

07:15

07:20

07:25

07:30

07:35

07:40

\n

scaleSequential (연속)

\n

보간기(Interpolator) 함수로 정의된 연속된 값에 매핑합니다.\n고유한 보간기 기능을 정의하거나 내장된 D3 보간기 기능을 사용할 수 있습니다.\n일반적으로 숫자값의 연속 간격을 일련의 색상으로 매핑하는데 유용합니다.

\n

\n
scaleSequential 함수는 선형적으로 매핑하는데, 앞에서 설명한 다른 스케일 방식으로 매핑하는 함수도 제공됩니다.\n(scaleSequentialLog, scaleSequentialSymlog, scaleSequentialPow, scaleSequentialSqrt, scaleSequentialQuantile)
\n

\n

import { interpolateRainbow } from 'd3-scale-chromatic';

const func = scaleSequential() .domain([0, 100])
.interpolator(interpolateRainbow);

\n

\n

scaleDiverging (양방향)

\n

양수와 음수, 위쪽과 아래쪽의 두가지 반대 방향으로 진행되는 현상을 시각화하는데 도움이 됩니다.

\n

import { interpolateRdBu } from 'd3-scale-chromatic';

const func = scaleDiverging<string>() .domain([-50, 0, 50])
.interpolator(interpolateRdBu);

\n

\n

scaleRadial (방사형)

\n

입력 값이 제곱된 출력 값에 선형적으로 대응하도록 범위가 내부적으로 제곱되는 Linear 스케일의 변형입니다.

\n

const innerRadius = 80;
const outerRadius = 220;

const x = scaleBand() .domain(data.map((row) => row.name))
.range([0, 2 * Math.PI]);

const y = scaleRadial().domain([0, 1000])
.range([innerRadius, outerRadius]);

const z = scaleSequential() .domain([0, 2 * Math.PI])
.interpolator(interpolateRainbow);

\n

\n

scaleOrdinal (서수)

\n

지정된 domain과 range를 갖는 순서를 나타내는 스케일을 생성하고 반환하는 데 사용됩니다.

\n

const func = scaleOrdinal<number, string>() .domain([0, 1])
.range(['white', 'pink', 'red']);

func(0); // white
func(1); // pink
func(2); // red
func(3); // white

\n

\n

scaleThreshold (임계점)

\n

결과 값을 구분하는 절단 값(=domain)을 직접 지정할 수 있습니다.

\n

const linear = scaleLinear<string>() .domain([0, 100000])
.range(['white', 'red']);

// 10000보다 작으면 white, 100000보다 크면 red, 나머지는 pink로 구분
const threshold = scaleThreshold<number, string>() .domain([10000, 100000])
.range(['white', 'pink', 'red']);

\n

linear

threshold

\n

scaleQuantile (분위수)

\n

domain을 동일한 절대 빈도의 간격으로 분할합니다. 분할 수는 range에 정의된 값들의 수와 같습니다.

\n

// 100개의 데이터를 균등하게 나눠서 값의 크기에 맞게 분류함

const sampleData: number[] = [ 11002, 29017, 21699, 47058, 24001, 6000, ... ];
const quantile = scaleQuantile<string>() .domain(sampleData)
.range(['white', 'pink', 'red']);

\n

linear

quantile

\n

scaleQuantize (양자화)

\n

domain 범위에서 임계값 선택을 처리하고, range에 정의된 값들의 수만큼 규칙적인 간격으로 세분화합니다.

\n

// 0~100192 white, 100193~200384 pink, 200385~300577 red

const quantize = scaleQuantize<string>() .domain([0, 300577])
.range(['white', 'pink', 'red']);

\n

linear

quantize

\n

결론

\n

제니퍼5 안에는 한정된 스케일 종류로 구현된 차트와 컴포넌트 등이 존재합니다.\n다만 그때그때 상황에 맞게 구현했으며, 어떤 스케일이다라고 정의하지 않았을 뿐입니다. 지난 모니터링 스터디 준비를 하면서 몇가지 모니터링 제품을 살펴보았는데, 분위수나 로그 스케일 등을 사용하는 것을 목격한 적이 있습니다.\n그동안 데이터를 표현하는데, 데이터를 왜곡하면 안된다는 이유로 여러가지 시도를 해보지 못한 것에 대해 아쉬움이 있었습니다.\n이번에 D3 스케일을 살펴보고, 이해하는 과정에서 데이터 시각화에 대한 본질적인 목적, 이유에 대해 다시 한번 생각해보는 계기가 되었습니다.

\n

참고

\n

대부분의 데이터는 본질적으로 계층 구조를 가지고 있습니다. D3는 이런 계층적 구조를 시각화하기 위한 다양한 기능을 제공합니다.\n해당 모듈이 제공하는 계층형 데이터 다이어그램의 종류는 3가지입니다. (노드-링크형, 인접형, 포함형)

\n

노드-링크 형은 제니퍼5의 콜-트리와 같은 Indented Tree나 Tiny Tree, Dendrogram이 있다. 아래는 인접형과 포함형 다이어그램입니다.

\n

$\"Example$

", "url": "https://alvin.ing/blog/d3-scale", "title": "데이터 시각화를 위한 D3 스케일에 대해 알아보자", "summary": "개요", "date_modified": "2022-06-28T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "D3.js" ] }, { "id": "https://alvin.ing/blog/vuejs-springboot-starter", "content_html": "

최근에 SVN에서 Git으로 형상 관리 시스템을 변경하면서 GitLab을 접하게 되었는데, 필자는 GitLab의 명성(?)만 들어봤지 직접 사용해본 것은 이번이 처음이었다. GitHub에서 오픈소스 프로젝트를 수년간 진행하고 있어서 GitLab이랑 얼마나 차이가 있겠어라는 생각을 했던 것이 사실이다. 하지만 GitLab CI 기능을 접하게 되면서 새로운 세계에 눈을 뜨게 되었다.

\n

GitLab vs GitHub

\n

진행 중인 프로젝트의 특성에 따라 선택하면 된다. 필자처럼 범용적인 프레임워크나 라이브러리를 개발한다면 아무거나 사용해도 상관없지만 아무래도 개발자 유입이 많고, 필자처럼 늘어나는 별을 보며 즐거움을 얻고자 한다면 GitHub를 추천한다. 다만 프로덕트나 서비스 개발을 해야한다면 GitLab을 선택하는 것이 좋다. 프라이빗 프로젝트를 기본적으로 생성할 수 있고, 몇년전부터 이슈가 되고 있는 DevOps를 실현하기 위해서 GitLab CI 기능을 사용하여 테스트 및 빌드, 배포를 자동화할 수 있다.

\n

\n
GitHub 프로젝트는 Travis CI를 통해 테스트 및 빌드, 배포를 자동화할 수 있다.
\n

\n

개발환경 설정

\n

본문에서는 “Webpack+SpringBoot 기반의 프론트엔드 개발환경 구축하기”에서 다루지 않는 몇가지 추가 설정에 대한 내용만 설명할 것이기 때문에 해당 글을 먼저 읽는 것을 권장한다.

\n

Babel 7

\n

먼저 babel 6버전을 7버전으로 업그레이드 했기 때문에 웹팩 설정 파일에 있는 babel-loader의 preset 설정을 babel.config.js로 이전해야 한다. 테스트를 위해 Jest 프레임워크를 사용하거나 polyfill을 사용할 때도 필요한 설정이니 기억해두자.

\n

\n
npm i -D @babel/core @babel/preset-env babel-core@7.0.0-bridge.0
\n

\n

module.exports = {
  \"presets\": [
    [
      \"@babel/preset-env\",
      {
        \"useBuiltIns\": \"entry\"
      }
    ]
  ],
  \"env\": {
    \"test\": {
      \"presets\": [
        [
          \"@babel/preset-env\",
          {
            \"targets\": {
              \"node\": true
            }
          }
        ]
      ]
    }
  }
}

\n

Polyfill

\n

서버에서 데이터를 비동기로 가져오기 위해 Promise 대신 async/await 키워드를 사용했기 때문에 polyfill을 로드해야 한다. 설정 방법은 여러가지가 있는데, 필자는 먼저 babel.config.js에서 useBuiltIns 값을 entry로 설정하고, 엔트리 js 파일에서 import ‘@babel/polifill’ 구문을 추가하는 방법을 택했다.

\n

\n
npm i @babel/polyfill
\n

\n

Jest

\n

Jest 프레임워크의 테스트는 노드 환경에서 동작하기 때문에 babel.config.js 파일에서 targets.node 값을 true로 설정해야 한다. 뷰 컴포넌트를 테스트하기 위해 다음 모듈을 추가로 설치하자.

\n

\n
npm i -D babel-jest jest jest-serializer-vue vue-jest vue-template-compiler vue-test-utils sinon
\n

\n

다음은 Jest 설정 파일이다. 여기서 중요한 부분은 transformIgnorePatterns 값을 빈 배열로 설정해야 한다. 기본값이 node_modules라서 NPM에 배포된 모듈을 사용한다면 테스트 실행시 에러가 발생한다.

\n

module.exports = {
    \"setupFiles\": [ \"./src/test/client/setup.js\" ],
    \"verbose\": true,
    \"moduleFileExtensions\": [
        \"js\",
        \"json\",
        \"vue\"
    ],
    \"moduleNameMapper\": {
        \"^@/(.*)$\": \"<rootDir>/src/main/client/$1\"
    },
    \"transform\": {
        \"^.+\\\\.js$\": \"<rootDir>/node_modules/babel-jest\",
        \".*\\\\.(vue)$\": \"<rootDir>/node_modules/vue-jest\"
    },
    \"snapshotSerializers\": [
        \"<rootDir>/node_modules/jest-serializer-vue\"
    ],
    \"transformIgnorePatterns\": []
}

\n

Jest 프레임워크는 브라우저가 아닌 노드 환경에서 실행되기 때문에 사용할 수 없는 객체에 대한 처리가 필요하다. 화면을 구성하기 위해 차트 모듈을 사용하였고, 차트 모듈 내부적으로 캔버스 객체를 생성하기 때문에 아래와 같이 처리하였다. 참고로 sinon은 테스트 스텁을 위한 프레임워크인데, 본문에서 관련 내용은 다루지 않을 것이다.

\n

import sinon from 'sinon';

const createElement = global.document.createElement;
const FAKECanvasElement = {
    getContext: jest.fn(() => {
        return {
            fillStyle: null,
            fillRect: jest.fn(),
            drawImage: jest.fn(),
            getImageData: jest.fn(),
        };
    }),
};

sinon.stub(global.document, 'createElement')
    .callsFake(createElement)
    .withArgs('canvas')
    .returns(FAKECanvasElement);

\n

Vue.js

\n

사실 Vue.js 관련 설정은 특별할 것이 없어서 본문에서 다루지 않을것이다. 다만 Jest 프레임워크와 vue-test-utils를 사용하여 뷰 컴포넌트 단위의 테스트 방법에 대해 간략하게 알아보자.

\n

import { shallow } from 'vue-test-utils'
import DetailMarketComp from '@/detailMarket'
import { data } from '../samples.js'

describe('detailMarket.vue', () => {
    let cmp ;

    beforeEach(() => {
        cmp = shallow(DetailMarketComp, {
            propsData: {
                title: 'Min Market Cap',
                data: data[2]
            }
        });
    });

    it('snapshot', () => {
        cmp.vm.$nextTick(() => {
            expect(cmp.vm.$el).toMatchSnapshot();
        });
    });

    it('computed', () => {
        expect(cmp.vm.maxYear).toEqual('2017');
        expect(cmp.vm.minYear).toEqual('2015');
    });
});

\n

detailMarket.spec.js는 기업의 시가총액이 최대인 연도와 최소인 연도를 테이블로 보여주는 뷰 컴포넌트에 대한 테스트 코드이다. 샘플 데이터에 대한 computed properties를 검증하고, 실제 마크업 코드로 출력될 텍스트를 스냅샷 한다.

\n

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`detailMarket.vue snapshot 1`] = `
<div>
  <h5>
    Min Market Cap
  </h5>

  <table>
    <thead>
      <tr>
        <th>
          Company
        </th>

        <th>
          Max Year
        </th>

        <th>
          Min Year
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          Facebook
        </td>

        <td>
          2017
        </td>

        <td>
          2015
        </td>
      </tr>
    </tbody>
  </table>
</div>
`;

\n

필자의 경험상 간단한 마크업 구조의 뷰 컴포넌트나 SVG 기반의 뷰 컴포넌트는 이미지 스냅샷 테스트를 하지 않는 것이 정신 건강에 좋다고 생각한다. 특히 SVG는 마크업과 달리 엘리먼트 속성에 대부분의 스타일이 들어가기 때문에 텍스트 스냅샷만으로도 충분히 검증할 수 있다.

\n

프로젝트 스펙

\n

본문을 잘 이해시키기 위해 샘플 프로젝트를 GitLab에 생성해두었으며, 프로젝트 스펙은 다음과 같다.

\n

기능 스펙

\n

서버는 글로벌 기업에 대한 마켓 데이터를 JSON 형태로 전달해주며, 클라이언트는 서버로부터 전달받은 데이터를 각각의 뷰 컴포넌트에 맞게 가공하여 화면을 구현한다. 좌측은 기업별 시가총액에 대한 비율을 차트로 보여주며, 우측은 최대/최소 기업에 대한 정보를 테이블로 보여준다.

\n

$\"Example$

\n

기술 스펙

\n

모듈 번들러 : Webpack 4
개발환경 서버 : Webpack Dev Server
JavaScript 컴파일러 : Babel 7
JavaScript 프레임워크 : Vue.js 2
Java 프레임워크 : Spring Boot 1.5
서버 사이드 템플릿 : Thymeleaf
CSS 컴파일러 : Sass
JavaScript 테스트 도구 : Jest, Sinon
Java 테스트 도구 : JUnit
프로젝트 빌드 도구 : Maven 3

\n

CI 프로세스 요약

\n

스프링부트는 간단하게 하나의 JAR 파일로 배포할 수 있다. 물론 프로젝트 규모에 따라 번들 파일이나 이미지 등은 JAR 파일에서 분리하여 별도의 CDN 서버에 배포할 수도 있다. 참고로 클라이언트 번들 파일들과 최종 프로젝트 아웃풋 파일은 버전 관리 대상에 포함되지 않는다. 해당 파일들은 CI 환경에서만 생성해야하며 최종 아웃풋 파일은 다른 레파지토리에 전달하는 형태로 진행해야 한다.

\n

클라이언트 테스트
클라이언트 빌드
서버 테스트
서버 빌드
JAR 파일 배포
Git 태그 생성

\n

CI 프로세스 상세

\n

먼저 GitLab에서 프로젝트를 생성하면 Set up CI/CD 버튼을 클릭하여 .gitlab-ci.yml 파일을 쉽게 생성할 수 있다. 본문에서는 샘플 프로젝트에 작성되어 있는 .gitlab-ci.yml의 내용을 앞에서 요약한 CI 프로세스의 단계 별로 자세히 알아볼 것이다. 참고로 각각의 단계를 잡(Job) 단위로 구성할 수 있는데, 실행 순서를 임의로 설정할 수 있다. 이를 스테이지(Stage)라고 말하며 모든 스테이지가 순차적으로 실행되는 일련의 과정을 파이프라인(Pipeline)이라 한다.

\n

\n
GitLab에서 개인 프로젝트는 그룹당 파이프라인 수행시간이 월 2000분(약 33시간)으로 제한되어 있다. 물론 돈으로 해결할 수 있다.
\n

\n

공통 설정 (variables)

\n

.gitlab-ci.yml에서 사용할 수 있는 변수들을 정의할 수 있다. 참고로 $ACCESS_TOKEN는 ‘GitLab 프로젝트 > Settings > CI / CD > Variables 설정’에서 추가한 변수인데, (6) Git 태그 생성에서 자세히 다룰 것이다.

\n

공통 설정 (cache)

\n

스테이지가 진행될 때, 생성되는 파일들은 다음 스테이지에서 사용할 수 없기 때문에 이미 설치된 모듈들을 다시 설치해야 하거나 생성된 파일들을 다음 스테이지에서 사용해야 하는 경우에 필요한 설정이다. 참고로 key에 설정된 $CI_COMMIT_REF_NAME은 GitLab CI 환경에서 미리 정의해둔 변수인데, 파이프라인이 동작할 때 대상이 되는 브랜치 이름이다.

\n

공통 설정 (stages)

\n

각각의 잡(Job)들의 실행 순서를 정할 수 있다.

\n

공통 설정 (only)

\n

파이프라인의 동작 조건을 설정할 수 있다. 특정 디렉토리나 파일이 변경될 때 동작되도록 설정하기 위해서는 changes 설정을 사용하면 되고, refs 설정을 통해 동작 조건의 기본 정책을 정할 수 있다. 필자는 머지 요청(MR)이 발생할 때만 동작하도록 설정했다.

\n

.Job_Only

\n

사용자가 임의로 만들 수 있는 일종의 클래스라고 볼 수 있으며, 잡(Job)들은 상속받을 수 있다. 중복 설정을 막을 수 있는 효과가 있기 때문에 설정 파일을 간결하게 작성할 수 있다.

\n

variables:
  MAVEN_CLI_OPTS: \"--batch-mode\"
  MAVEN_OPTS: \"-Dmaven.repo.local=.m2/repository\"
  CI_REPOSITORY_URL: https://alvin.h:$ACCESS_TOKEN@gitlab.com/$CI_PROJECT_PATH.git

cache:
  key: \"$CI_COMMIT_REF_NAME\"
  paths:
    - src/main/resources/static/
    - dist/
    - node_modules/
    - .m2/repository/

stages:
  - fetest
  - febuild
  - betest
  - bebuild
  - deploy
  - patch

.Job_Only:
  only:
    changes:
      - \"src/**/*\"
    refs:
      - merge_requests
...

\n

(1) 클라이언트 테스트

\n

npm install 명령어를 통해 테스트에 필요한 모듈들을 설치하고, Jest 테스트를 실행한다. 참고로 실행 결과 텍스트를 정규식으로 파싱해서 커버리지 값으로 사용할 수 있다.

\n

...
FE_Test:
  extends: .Job_Only
  image: node:10
  stage: fetest
  before_script:
    - npm install
  script:
    - npm test
  coverage: /All files\\s*\\|\\s*([\\d\\.]+)/
...

\n

커버리지 텍스트 중에서 All files 부분을 파싱하며, ‘GitLab 프로젝트 > Settings > CI / CD 설정’에서 Pipeline status와 Coverage report를 마크다운이나 HTML 코드로 가져올 수 있다.

\n

$\"Example$

\n

(2) 클라이언트 빌드

\n

fetest 스테이지에서 node_modules 디렉토리를 캐시해두었기 때문에 before_script 명령어는 조금 빨리 실행될 것이다. 웹팩 빌드를 하고 생성되는 번들 파일들은 공통 설정에서 캐시 처리를 해두었기 때문에 BE_Build 스테이지에서 메이븐 빌드시 최종 아웃풋 파일에 포함된다.

\n

...
FE_Build:
  extends: .Job_Only
  image: node:10
  stage: febuild
  before_script:
    - npm install
  script:
    - npm run dist
    - ls -all ./src/main/resources/static
...

\n

(3) 서버 테스트

\n

메이븐 테스트를 실행하며, 테스트에 필요한 모듈들은 알아서 설치된다.

\n

...
BE_Test:
  extends: .Job_Only
  image: maven:3.3.9
  stage: betest
  script:
    - mvn test $MAVEN_OPTS
...

\n

(4) 서버 빌드

\n

betest 스테이지에서 .m2/repository 디렉토리를 캐시해두었기 때문에 메이븐 빌드가 조금 빨리 실행될 것이다. 참고로 클라이언트는 테스트와 빌드를 분리했기 때문에 서버도 분리하기 위해 -DskipTests=true를 통해 메이븐 빌드만 실행되게 설정했다.

\n

...
BE_Build:
  extends: .Job_Only
  image: maven:3.3.9
  stage: bebuild
  script:
    - mvn install -DskipTests=true $MAVEN_OPTS $MAVEN_CLI_OPTS
...

\n

(5) JAR 파일 배포\nbebuild 스테이지에서 dist 디렉토리를 캐시해두었기 때문에 최종 아웃풋 파일을 가져와서 별도의 서버에 배포할 수 있다. 배포 방법은 자신의 환경에 맞게 정하면 되는데, 필자는 sshpass+scp 명령어를 사용하여 지인에게 대여(?) 받은 서버에 전송하는 형태로 구현하였다.

\n

\n
처음에는 expect를 사용하여 scp 명령어를 수행하였는데, GitLab CI 환경에서는 잘 동작하지 않는다.
\n

\n

deploy 스테이지에서는 $POM_VERSION과 $SSH_PASSWORD 변수를 사용하는데, 먼저 메이븐 명령어를 통해 프로젝트의 pom.xml에 명시된 버전을 가져와서 $POM_VERSION 변수에 값을 할당한다. 프로젝트의 버전이 변경되면 배포 서버에 전송할 파일의 이름도 변경되는 문제를 해결할 수 있다. 그리고 SSH 계정의 비밀번호를 .gitlab-ci.yml 파일에 공개할 수 없기 때문에 ‘GitLab 프로젝트 > Settings > CI / CD > Variables 설정'에 $SSH_PASSWORD 변수를 추가하였다.

\n

...
Deploy:
  extends: .Job_Only
  image: maven:3.3.9
  stage: deploy
  before_script:
    - POM_VERSION=$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec)
    - apt-get update -qq && apt-get install -y -qq sshpass
  script:
    - ls -all ./dist
    - sshpass -V
    - export SSHPASS=$SSH_PASSWORD
    - sshpass -e scp -r -oStrictHostKeyChecking=no -P51022 ./dist/vuejs-springboot-starter-$POM_VERSION.jar root@61.37.50.64:/opt/public
...

\n

(6) Git 태그 생성

\n

필자는 배포 서버에 최종 아웃풋 파일이 전송되면 프로젝트의 pom.xml에 명시된 버전을 Git 태그 이름으로 샘플 프로젝트에 생성하고 싶었다. 공통 설정에서 variables에 정의한 $CI_REPOSITORY_URL 변수를 풀어쓰면 다음과 같다.

\n

\n
https://아이디:패스워드@gitlab.com/alvin.h/vuejs-springboot-starter.git
\n

\n

샘플 프로젝트에서 필자의 아이디는 alvin.h이며, 패스워드는 우측 상단의 ‘프로필 메뉴 > Settings > Access Tokens > Personal Access Tokens 설정'에서 발급한 토큰을 ‘GitLab 프로젝트 > Settings > CI / CD > Variables 설정’에 $ACCESS_TOKEN 변수 값으로 추가한 것이다.

\n

...
Patch:
  image: maven:3.3.9
  only:
    changes:
      - \"pom.xml\"
    refs:
      - merge_requests
  stage: patch
  before_script:
    - POM_VERSION=$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec)
    - echo $POM_VERSION
    - git config --global user.name \"alvin.h\"
    - git config --global user.email \"seogi777@gmail.com\"
  script:
    - git checkout $CI_COMMIT_REF_NAME
    - git remote remove origin
    - git remote add origin $CI_REPOSITORY_URL
    - git tag -a $POM_VERSION -m \"Version created by gitlab-ci Build\"
    - git push origin --tags

\n

파이프라인 동작 화면

\n

스테이지 진행 상태와 현재 실행 중인 잡(Job)의 콘솔 화면을 볼 수 있다.

\n

$\"Example$

\n

아래는 배포 서버에 전송된 최종 아웃풋 파일 목록이다. 그리고 파이프라인 동작 실패시 필자가 사용하고 있는 슬랙 채널에 메시지가 전송되게 설정했다. 참고로 ‘GitLab 프로젝트 > Settings > Integrations 설정'에서는 슬랙 뿐만이 아니라 다른 서비스와도 연동할 수 있는 기능을 제공한다.

\n

$\"Example$

\n

글을 마치며…

\n

처음에는 프론트엔드 개발환경을 최신화하기 위해 알아본 내용들을 정리하기 위해 글을 썼다. 그러다보니 실제 업무에 적용해보고 싶어서 레거시 시스템에 적용하는 방법에 대해 연구하기 시작했다. 운이 좋게도 작년 연말에 기회가 생겨서 일을 진행하였고, 현재는 어느 정도 마무리가 된 상태이다.

\n

게다가 형상 관리 시스템을 SVN에서 Git으로 변경하면서 사내에 GitLab 서버를 구축해서 사용하기 시작했다. 사실 프론트엔드 개발환경을 최신화하면서 번들 파일을 버전 관리하기가 애매했었는데, GitLab CI 기능을 통해 해결되면서 필자가 그동안 진행했던 모든 일들이 하나의 연결고리로 이어졌다.

\n

사실 처음부터 GitLab CI에 관심을 가졌던 것은 아니었다. 최근에 참여하고 있는 스터디에서 교재로 사용하고 있는 테스트 주도 개발로 배우는 객체 지향 설계와 실천이라는 책에 이런 구절이 나온다.

\n

\n
우선 동작하는 골격을 대상으로 테스트하라
\n

\n

\n
‘동작하는 골격'이란 전 구간을 대상으로 자동 빌드, 배포, 테스트를 할 수 있는 실제 기능을 가장 얇게 구현한 조각을 말한다. 여기엔 첫 기능을 구현할 수 있을 정도의 자동화, 주요 컴포넌트, 통신 매커니즘이 포함될 것이다. 골격에 포함된 애플리케이션 기능을 단순하게 유지하면 골격은 신경 쓰지 않고도 기반 구조에만 마음껏 집중할 수 있다.
\n

\n

필자가 공개한 샘플 프로젝트는 책에서 말한 ‘동작하는 골격'과 동일하다고 보면 된다. 다만 요즘 시대에 맞게 트렌디함을 더했을 뿐이다. 이 글을 읽는 사람들에게 단순한 레퍼런스로써 도움이 되길 바랄 뿐이다.

\n

참고 링크

\n

아래 링크들은 본문에서 자세히 다루지 않는 특정 기술들에 대한 개발가이드와 샘플 프로젝트의 산출물이다.

\n

프로젝트 링크

\n

https://gitlab.com/alvin.h/vuejs-springboot-starter

", "url": "https://alvin.ing/blog/vuejs-springboot-starter", "title": "Vue.js+SpringBoot 개발환경에서 테스트/빌드/배포 자동화하기", "summary": "최근에 SVN에서 Git으로 형상 관리 시스템을 변경하면서 GitLab을 접하게 되었는데, 필자는 GitLab의 명성(?)만 들어봤지 직접 사용해본 것은 이번이 처음이었다. GitHub에서 오픈소스 프로젝트를 수년간 진행하고 있어서 GitLab이랑 얼마나 차이가 있겠어라는 생각을 했던 것이 사실이다. 하지만 GitLab CI 기능을 접하게 되면서 새로운 세계에 눈을 뜨게 되었다.", "date_modified": "2019-01-09T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "Vue.js", "Webpack", "Spring Boot" ] }, { "id": "https://alvin.ing/blog/applied-webpack-to-legacy", "content_html": "

필자의 올해 목표 중 하나는 오랜기간 조금씩 진행해왔던 제니퍼 뷰서버 플랫폼화를 마무리하는 것이었다. 기획했던 플랫폼 요소는 여러가지가 있지만 그 중에서도 제니퍼 화면을 독립적인 개발환경에서 구현할 수 있게 하는 기능이 제일 중요했다. 그래서 생각해낸 것이 서버 환경은 스프링부트로 심플하게 구성하고, 모던한 프론트엔드 개발을 위해 모듈 번들러로 웹팩을 선택했다. 관련해서는 필자가 쓴 “Webpack+SpringBoot 기반의 프론트엔드 개발 환경 구축하기”를 참고하자.

\n

새로 갖춰진 개발환경에서 기존의 제니퍼 뷰서버 플러그인 중 일부를 테스트 삼아 마이그레이션 해보니까 나름 신선하더라. 기존의 JSP 템플릿에 마크업과 공존하고 있던 자바스크립트 코드는 ES6 스펙에 맞춰서 수정하고, 모듈 별로 분리를 하고나니 필자가 사용하고 있는 IntelliJ IDEA의 정적 코드 분석이나 메소드 힌트 같은 기능들을 제대로 활용할 수 있게 되었다. 요즘 같은 세상에서는 너무 당연한 것이지만 수년간 쌓아온 레거시란 벽은 이미 넘을 수 없을만큼 높아진 상태였다.

\n

필자는 지난 8월에 “레거시(Legacy) 시스템에 웹팩 개발환경 적용하기”를 쓰면서 언젠가는 실무에 꼭 적용해보겠다는 다짐을 했었다. 그리고 얼마지나지 않아 여유 일정이 생겼고, 더 이상 미룰 수 없는 일이기에 바로 시작했다.

\n

(1) 마이그레이션 대상 선택하기

\n

제니퍼 화면은 크게 메인 대시보드와 사용자정의 대시보드, 리얼타임, 분석, 통계, 관리, 보고서 템플릿, 사용자 메뉴로 나눌 수 있다. 참고로 사용자정의 대시보드와 보고서 템플릿은 화면 단위가 아니라 컴포넌트 단위의 기능으로 복잡하게 얽혀있어서 마이그레이션 대상에서 제외했다. 다음은 제니퍼에서 제공하는 타입 별 화면 개수이다.

\n

\n
메인 대시보드 6종, 리얼타임 8종, 분석 21종, 통계 6종, 관리 44종
\n

\n

제니퍼는 한달에 최소 두번 이상의 마이너 버전이 릴리즈 되는 온-프레미스(On-premise) 제품이다보니 문제가 되는 버전이 고객사에 설치되면 되돌리기가 쉽지 않다. 서비스형 제품처럼 피드백이 즉각적으로 나타나진 않지만 수없이 많은 과거 버전들 속에서 다양한 문제에 직면하게 된다. 필자는 지난 수년간 수많은 고객사에 설치되어 어느 정도 안정성이 확보된 85종의 화면들을 마이그레이션 해야한다.

\n

(2) 목표 설정하기

\n

모든 일의 시작은 목표를 잘 정하는 것이다. 너무 당연한 말이지만 일의 규모가 크거나 앞에서 말한 것처럼 이미 검증된 일을 뒤엎고 새로운 것을 적용하는 일은 진행하는 사람이나 직책자 또는 구성원들에게 큰 부담을 안겨준다. 그래서 필자는 다음과 같은 목표를 정하고, 일의 당위성을 확보하기 위한 논리를 정리했다.

\n

유닛 테스트와 스냅샷 테스트가 가능해야 함
툴에서 디버깅이 가능한 코드를 개발할 수 있어야 함
화면 단위로 프레임워크나 라이브러리를 자유롭게 사용할 수 있어야 함
마이그레이션 된 화면과 기존의 화면이 모두 잘 동작해야 함

\n

4번에 대해 조금 더 설명을 하자면 한번에 모든 화면을 마이그레이션 할 수 있다면 정말 좋겠지만 현실적으로 불가능한 일이기 때문에 새로 갖춰진 개발환경에서는 기존의 화면과 마이그레이션 된 화면이 모두 잘 동작해야 한다.

\n

(3) 기술 스펙 정하기

\n

목표 설정이 끝났으니 이제는 새로 갖춰질 개발환경의 기술 스펙을 정해야 한다. 본문에서는 각각의 기술 스펙에 대한 설명은 생략하겠으며, 서론에서도 언급한 필자가 작성한 글을 참고하면 도움이 될 것이다.

\n

모듈 번들러 : webpack 4
개발환경 서버 : webpack-dev-server
JavaScript 컴파일러 : babel 6
JavaScript 프레임워크 : vuejs 2
CSS 컴파일러 : sass
테스트 도구 : jest
기타 : eslint, prettier

\n

(4) 레이어 기반의 화면 정리하기

\n

목표와 기술 스펙이 정해졌으니 현재 시점에서 바로 본론으로 넘어가야 하는데, 뜬금없이 레이어 기반의 화면에 대한 설명을 보게 되서 당혹스럽겠지만 제니퍼는 언제 어디서든 관리 화면을 띄울 수 있도록 레이어 기반으로 구현되었다.

\n

즉, 마이그레이션 대상 화면의 절반이 레이어 기반인 것이다. 필자의 계획은 화면 단위(URL 별)로 엔트리를 설정하고, 공통 모듈을 제외한 아웃풋 파일들을 화면 별 디렉토리 안에 생성해두려고 했었다. 하지만 관리 화면들이 레이어 기반이기 때문에 시작부터 큰 난관에 부딪치게 되었다.

\n

$\"Example$

\n

고민 끝에 필자는 모든 관리 화면을 iFrame 기반으로 변경하기로 했다. 물론 리소스 중복 로드에 따른 로딩 속도 문제나 컨텐츠에 따라 iFrame 크기를 유동적으로 변경해야 하는 등의 몇가지 문제점이 있었지만 어렵지 않게 해결할 수 있었다. 간단하게 정리하자면 다음과 같다.

\n

관리 화면 특성상 다른 종류의 화면에 비해 공통 모듈이나 라이브러리를 적게 사용하기 때문에 마이그레이션이 완료되면 로딩 속도 문제가 어느 정도 개선될 것이다.
“iFrame Resizer”라는 완성도가 높은 라이브러리를 사용했기 때문에 컨텐츠에 따른 iFrame 크기 조절을 자연스럽게 처리 할 수 있었다.

\n

참고로 페이지 기반으로 화면이 변경되면서 고정 크기의 윈도우 컴포넌트에서 벗어나 별도의 팝업이나 URL로 접근할 수 있게 되어 사용성이 많이 개선되었다.

\n

(5) 레이아웃 구조 살펴보기

\n

제니퍼 화면은 JSTL 커스텀 태그로 공통 레이아웃을 화면 별로 구성하는데, 화면 타입 별로 조금씩 다르게 처리되어 있다. 문제는 마크업 뿐만이 아니라 템플릿, 자바스크립트, 스타일까지 함께 포함되어 있기 때문에 우선 자바스크립트를 분리하면서 ES6 모듈로 마이그레이션을 진행해야 한다.

\n

일단 기존의 화면 타입 별 레이아웃에 대한 설명을 하자면 다음과 같다.

\n

화면_타입_header.jsp : default_css.jsp와 default_js.jsp를 로드함
화면_타입_body_start.jsp : toolbar.jsp를 로드함
화면_타입_body.end.jsp : 화면 타입 별로 공통으로 사용되는 마크업과 스크립트가 들어가고, footer.jsp를 로드함
common_ui.jsp : 제니퍼에서 사용되는 모든 컴포넌트들에 대한 템플릿과 스크립트가 포함되어 있음

\n

다음은 화면 타입 별 레이아웃 내부에서 로드하는 공통 레이아웃에 대한 설명이다.

\n

default_css.jsp : 제니퍼 화면 구성에 필요한 css 파일과 JUI 라이브러리의 css 파일들을 로드함
default_js.jsp : 제니퍼 캔버스 차트와 유틸리티 js 파일과 jQuery나 JUI 같은 라이브러리의 js 파일들을 로드함
toolbar.jsp : 제니퍼 화면 상단에 보이는 툴바 영역에 대한 마크업과 스크립트가 포함되어 있음

\n

예를 들어 EVENT 분석 화면은 /analysis/event으로 접근할 수 있는데, 해당 JSP 템플릿 파일은 /WEB-INF/jsp/analysis/event.jsp에 위치한다.

\n

$\"Example$

\n

(6) 레이아웃 구조 분리하기

\n

일단 default_css.jsp는 화면 별 스타일과 ES6로 마이그레이션 된 컴포넌트 스타일만 분리했기 때문에 생각보다 간단하게 끝났다. 하지만 문제는 default_js.jsp와 toolbar.jsp, analysis_body_end.jsp, common_ui.jsp였다.

\n

기존의 화면들은 잘 동작해야하므로 그대로 두고, 마이그레이션 대상 화면에 대해서만 레이아웃을 다르게 구성하기로 했다. 필자는 모듈 번들러로 웹팩을 선택했기 때문에 development 모드와 production 모드에 따라 output.path를 다르게 생성했다.

\n

development 모드 : $프로젝트_디렉토리/.webpack/bundles
production 모드 : $프로젝트_디렉토리/src/main/webapp/bundles

\n

JSP 템플릿에서는 pageConext 내장 객체를 사용할 수 있는데, 요청 헤더 정보 중에 request.getServletPath() 메소드를 사용하여, 화면 타입과 화면 이름을 분류했다. 제니퍼 뷰서버는 다음과 같이 단순한 URL 구조를 가진다.

\n

\n
URL : http://127.0.0.1:8080/analysis/event
\n(화면 타입은 analysis, 화면 이름은 event)
\n

\n

만약에 development 모드이고, EVENT 분석 화면이라면 $프로젝트_디렉토리/.webpack/bundles/analysis/event에 디렉토리가 생성된다. 사용자가 특정 화면에 접근했을 때, 앞에서 말한 pageContext 내장 객체를 사용하여 화면 타입과 화면 이름을 분류하고, output.path에 해당 디렉토리가 존재하는지 확인한다. 만약에 디렉토리가 존재한다면 마이그레이션 대상 화면이라고 간주하고, 다음과 같은 레이아웃 구조로 변경한다.

\n

$\"Example$

\n

기존에는 모든 화면에서 default_js.jsp에 정의된 js 파일들을 로드했었다. jquery나 moment, lodash 같은 유명한 라이브러리도 포함되어 있고, 제니퍼 캔버스 차트나 유틸리티, JUI 등 내부에서 사용되는 모듈들도 포함된다. 필자는 마이그레이션 대상 화면에서 의존성이 너무 높은 jquery를 제외하고, 번들 파일들만 로드할 수 있도록 제니퍼 뷰서버를 대대적으로 수정하였다.

\n

(7) 웹팩 기본 설정하기

\n

본문에서는 웹팩 설정 방법에 대해서 자세히 다루지는 않고, 중요하다고 생각하는 부분만 짚고 넘어가려고 한다. 먼저 모드에 따라 output.path를 다르게 설정해주고, 마이그레이션 대상 화면은 계속 늘어날 것이기 때문에 entry를 멀티로 설정해야 한다.

\n

const path = require('path');

module.exports = (env) => {
  const clientPath = path.resolve(__dirname, 'src/main/client');
  const outputPath = path.resolve(__dirname, (env == 'production') ?
                                  'src/main/webapp' : '.webpack');
  const publicPath = '/bundles';

  return {
        mode: env,
        entry: {
          'analysis/event/app': `${clientPath}/analysis/event/index.js`,
          'realtime/event/app': `${clientPath}/realtime/event/index.js`,
          ...
        },
        output: {
            path: outputPath + publicPath,
            publicPath: publicPath,
            filename: '[name].js'
        },
    ...
  }
}

\n

먼저 clientPath에는 JSP 템플릿 파일에서 분리한 자바스크립트 코드를 ES6 모듈로 마이그레이션 한 index.js 파일들이 위치한다. 화면 별 index.js 파일들은 entry가 되는데, 여기서 entry 키에 주목하자.

\n

output.filename이 [name].js로 설정되어 있는데, [name]은 entry 키로 치환되어 output.path 디렉토리에 생성된다. 만약에 analysis/event/index.js 파일을 production 모드에서 빌드를 하면 번들링 된 파일 경로는 다음과 같다.

\n

\n
$프로젝트_디렉토리/src/main/webapp/bundles/analysis/event/app.js
\n

\n

참고로 output.publicPath를 /bundles로 설정했기 때문에 웹에서는 다음과 같이 접근할 수 있다.

\n

\n
http://127.0.0.1:8080/bundles/analysis/event/app.js
\n

\n

이제 entry 모듈에서 화면 별로 필요한 라이브러리만 import해서 사용할 수 있게 되었다. 물론 jquery는 여전히 webpack_default_js.jsp에서 로드되고 있기 때문에 다음 설정을 통해서 번들 파일에 포함되지 않게 해야한다.

\n

...
return {
  ...
  externals: {
      jquery: 'jQuery'
  },
  ...
}

\n

(8) 웹팩 개발서버 설정하기

\n

필자는 development 모드일 때, webpack-dev-server를 사용하기로 결정했는데, 이유는 HMR(Hot Module Replacement)를 적용해보고 싶었기 때문이다. 하지만 몇가지 문제로 인해 현재는 Live-Reload만 적용한 상태이다.

\n

webpack-dev-server는 번들 파일을 메모리 상에서 제공하기 때문에 output.path로 설정한 .webpack 디렉토리가 필요없다. 하지만 특정 화면으로 접근했을 때, 제니퍼 뷰서버가 마이그레이션 대상 화면인지 판단하기 위해서는 실제 파일이 필요했고, JSP 템플릿에서 로드해야 하는 파일들은 화면 별로 조금씩 다르기 때문에 구분이 필요했다. 그래서 마음에 들진 않지만 webpack 명령어를 함께 사용했다.

\n

\n
webpack --watch --env=development & webpack-dev-server --env=development
\n

\n

실은 webpack-dev-server가 컴파일 할 때, 번들 파일 경로를 얻어오는 방법을 열심히 알아봤으나 아직까지도 답을 찾지 못했다. 하지만 Express는 webpack-dev-server를 미들웨어로 추가하면, 번들 파일 경로를 가지고 올 수 있어서 참 아쉬웠다. (제니퍼 뷰서버는 자바 스프링을 사용함 ㅜㅜ)

\n

...
return {
  ...
  devServer: {
      host: '127.0.0.1',
      port: 8081,
      progress: true,
      inline: true,
      hot: false,
      proxy: [{
          context: [ '**', '!/ws/**' ],
          target: 'http://127.0.0.1:8080'
      }, {
          context: [ '/ws/**' ],
          target: 'ws://127.0.0.1:8080',
          ws: true
      }]
  },
  ...
}

\n

webpack-dev-server 포트로 제니퍼 화면에 접근했을 때, 웹소켓으로 데이터를 가져오는 대시보드가 제대로 동작하지 않았다. 그래서 조금 헤맸었는데, http와 ws 프록시 컨텍스트만 겹치지 않게 설정하면 해결되는 문제였다.

\n

(9) 공통 모듈 청크하기

\n

앞에서 entry를 멀티로 설정하여 화면 별로 번들 파일을 생성하는 방법에 대해 알아봤다. 하지만 네비게이션 바나 사용자 메뉴, 알림 등 모든 화면에서 공통으로 사용되는 기능이나 유틸리티 모듈들은 어떻게 번들링 될까? 웹팩 기반으로 개발하는 사람은 누구나 알고 있는 splitChunks 옵션을 사용하면 되는데, 일단 다음 설정을 보자.

\n

module.exports = (env) => {
  const clientPath = path.resolve(__dirname, 'src/main/client');
  ...
  return {
    ...
    optimization: {
      splitChunks: {
          cacheGroups: {
              common: {
                  test: clientPath + '/common',
                  chunks: 'all',
                  name: 'base/common'
              },
              modules: {
                  test: clientPath + '/modules',
                  chunks: 'all',
                  name: 'base/modules'
              }
          }
      },
      ...
    }
  }
}

\n

여기서 중요한 부분은 cacheGroups 모듈의 name 설정 부분인데, 앞에서 설명한 output.filename의 [name]과 치환되어 output.path 디렉토리에 번들 파일이 생성되는 것이다. production 모드일 때, 번들링 된 파일 경로는 다음과 같다.

\n

\n
$프로젝트_디렉토리/src/main/webapp/bundles/base/common.js
\n$프로젝트_디렉토리/src/main/webapp/bundles/base/modules.js
\n

\n

(10) 이미지 파일 관리하기

\n

보통은 스프라이트 이미지를 사용하는데, 부득이하게 특정 스타일에 단일 이미지를 사용해야 하는 경우가 종종 발생한다. 그래서 필자는 웹팩으로 번들링 할 때, development 모드에서는 url-loader를 사용하고, production 모드에서는 file-loader를 사용했다.

\n

이미지가 base64로 인코딩되서 CSS 파일에 포함되기 때문에 개발할 때는 매우 편리하지만 용량이 많이 커지는 문제가 있다. 그래서 개발이 완료되면 file-loader를 사용하기로 했다. 다만 여기서 주의할 점은 이미지 파일들은 화면 별 디렉토리에 포함되어 있지만 배포 할때는 다른 화면의 이미지 파일과 함께 동일한 디렉토리에 복사된다.

\n

...
return {
  ...
  module: {
    rules: [].concat([ env == 'production' ?
        {
            test: /\\.(jpe?g|png|gif|svg)$/i,
            use: [{
                loader: 'file-loader',
                options: {
                    name: '[hash].[ext]',
                    outputPath: '/images',
                    publicPath: '/bundles/images'
                }
            }]
        } : {
            test: /\\.(jpe?g|png|gif|svg)$/i,
            use: [{
                loader: 'url-loader',
                options: {
                    limit: 1024 * 1024
                }
            }]
        }
    ])
  },
  ...
}

\n

이미지가 복사되는 디렉토리는 앞에서 설명한 output.path에 options.outputPath가 더해진 경로이므로 다소 헷갈릴 수도 있기 때문에 주의해서 설정해야 한다.

\n

\n
$프로젝트_디렉토리/src/main/webapp/bundles/images
\n

\n

모든 화면의 이미지 파일이 동일한 디렉토리에 복사되기 때문에 파일명이 겹치지 않도록 options.name을 [name] 대신 [hash]로 변경하였다. 그리고 options.publicPath를 /bundles/images로 설정했기 때문에 웹에서는 다음과 같이 접근할 수 있다.

\n

\n
http://127.0.0.1:8080/bundles/images/[hash].jpg
\n

\n

(11) JavaScript 프레임워크 선택하기

\n

Vue.js를 선택한 이유는 여러가지가 있는데, 일단 필자는 템플릿 방식을 선호한다. 2.x 버전부터 render 함수를 지원하지만 이건 개인 취향이니 그냥 넘어가고, 가장 큰 이유는 기존의 레거시 화면과 공존해야 하는 특수한 경우라서 경량 프레임워크를 선택하는 것이 옳은 판단이라고 생각했다.

\n

JSP 템플릿에 포함된 자바스크립트 코드는 ES6 모듈로 마이그레이션 했지만 여전히 마크업 코드는 남아있었다. 하지만 싱글 파일 컴포넌트에 거의 수정하지 않고 옮길 수 있었기 때문에 마이그레이션 속도가 많이 향상되었다. 참고로 제니퍼 화면은 서버에서 넘겨주는 필수 데이터들이 많아서 JSP 같은 서버 템플릿을 완전히 제거할 수는 없었다. 그래서 최소한의 마크업만 남겨두고, 최대한 뷰 컴포넌트 단위로 화면을 분리해서 개발했다.

\n

어차피 테스트가 가능한 코드를 만드는 것이 최종 목표이기 때문에 뷰 컴포넌트 단위로 테스트를 진행하기로 결정했다. 그리고 필자는 Vue.js 하위 프로젝트인 “vue-test-utils”를 아주 잘 사용하고 있다.

\n

(12) 뷰 컴포넌트로 마이그레이션 하기

\n

제니퍼 화면에서는 자체 개발한 수많은 컴포넌트들을 사용한다. 크게 대시보드와 리얼타임 화면에서 사용되는 캔버스 차트가 있고, 분석이나 통계, 보고서 템플릿 화면에서 사용되는 SVG 차트가 있다. 그리고 모든 화면에서 그리드, 달력, 콤보박스 등등 수많은 컴포넌트들을 두루 사용하고 있다. JUI 라이브러리는 그 중에서 일부를 공개한 것이다.

\n

막상 Vue.js로 화면 개발을 하다보니 ES6 모듈로 마이그레이션 된 기존의 컴포넌트들을 사용하기가 어려웠다. 아무래도 제니퍼 화면은 컴포넌트 비중이 높기 때문에 Vue.js가 제공하는 기능들을 제대로 활용하지 못했다. 그래서 먼저 JUI 라이브러리를 뷰 컴포넌트로 마이그레이션 하기로 결정했다. 불행(?) 중 다행으로 차트는 몇달 전부터 시작해서 어느 정도 마무리가 된 상태였다.

\n

JUI 라이브러리가 가지는 기존의 색은 모두 버리고, 최대한 Vue.js 특성에 맞게 마이그레이션 하려고 신경썼다. 쉽지 않은 일이었지만 결국 차트(23종), 그리드(2종), UI(13종)의 뷰 컴포넌트를 제공하게 되었고, GitHub에 프로젝트를 공개했다. 현재는 제니퍼 화면에 의존성이 높은 전용 컴포넌트들을 마이그레이션 하고 있다.

\n

$\"Example$

\n

(13) Jest 설정시 주의사항

\n

테스트 프레임워크는 요즘 많이 사용하고 있는 Jest를 선택했는데, 기본 설정을 하는 과정에서 몇일동안 삽질한 부분만 짧막하게 짚고 넘어가려고 한다. 만약에 테스트 대상 모듈에서 NPM으로 설치한 모듈을 사용하고 있다면 SyntaxError: Unexpected identifier 에러가 발생한다.

\n

필자가 공식 매뉴얼만 제대로 읽었다면 쉽게 해결할 수 있는 간단한 문제였다. 그것은 바로 transformIgnorePatterns 옵션의 기본값이 [“/node_modules/”]로 설정되어 있기 때문이다. 간단하게 빈 배열로 변경하거나 각자의 프로젝트에 맞는 패턴을 설정하면 된다.

\n

(14) 번들 파일 배포하기

\n

일반적인 서비스라면 CDN에 번들 파일들을 업로드하는 형태의 배포 방법을 선택할 수 있지만 제니퍼 뷰서버는 정적 리소스를 WAR 파일에 묶어서 배포한다. 참고로 제니퍼는 모든 프로젝트를 메이븐으로 관리하기 때문에 빌드시 NPM 명령어를 실행할 수 있는 frontend-maven-plugin을 사용하기로 결정했다.

\n

다음은 package.json에 명시된 모듈들을 먼저 설치하고, 웹팩을 production 모드로 빌드하게 하는 설정이다.

\n

<plugin>
    <groupId>com.github.eirslett</groupId>
    <artifactId>frontend-maven-plugin</artifactId>
    <version>1.6</version>
    <executions>
        <execution>
            <id>install node and npm</id>
            <goals>
                <goal>install-node-and-npm</goal>
            </goals>
            <phase>generate-resources</phase>
        </execution>
        <execution>
            <id>npm install</id>
            <goals>
                <goal>npm</goal>
            </goals>
            <configuration>
                <arguments>install</arguments>
            </configuration>
        </execution>
        <execution>
            <id>npm build</id>
            <goals>
                <goal>npm</goal>
            </goals>
            <configuration>
                <arguments>run dist</arguments>
            </configuration>
        </execution>
    </executions>
    <configuration>
        <nodeVersion>v10.10.0</nodeVersion>
        <npmVersion>6.4.1</npmVersion>
    </configuration>
</plugin>

\n

글을 마치며…

\n

결과는 만족스러웠지만 조금만 더 빨리 시작했으면 좋았을텐데, 후회도 아쉬움도 많이 남는 일이었다. 일을 진행하면서 문제가 생겨 몇번의 핫픽스 버전을 릴리즈 했었다. 그만큼 레거시 시스템을 엎는다는건 조심스럽고 예민한 일이다. 하지만 앞으로 몇년을 생각하면 언젠가는 해야만 하는 일이다. 늦으면 늦을수록 위험부담이 커지기 때문에 기회가 오면 바로 시작해야 한다.

", "url": "https://alvin.ing/blog/applied-webpack-to-legacy", "title": "레거시 시스템의 프론트엔드 개발환경 최신화 후기", "summary": "필자의 올해 목표 중 하나는 오랜기간 조금씩 진행해왔던 제니퍼 뷰서버 플랫폼화를 마무리하는 것이었다. 기획했던 플랫폼 요소는 여러가지가 있지만 그 중에서도 제니퍼 화면을 독립적인 개발환경에서 구현할 수 있게 하는 기능이 제일 중요했다. 그래서 생각해낸 것이 서버 환경은 스프링부트로 심플하게 구성하고, 모던한 프론트엔드 개발을 위해 모듈 번들러로 웹팩을 선택했다. 관련해서는 필자가 쓴 “Webpack+SpringBoot 기반의 프론트엔드 개발 환경 구축하기”를 참고하자.", "date_modified": "2018-11-25T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "Webpack", "Legacy" ] }, { "id": "https://alvin.ing/blog/applying-webpack-to-legacy", "content_html": "

“Webpack+SpringBoot 기반의 프론트엔드 개발 환경 구축하기” 편에서 스프링부트 프로젝트를 생성하고, 서버와 클라이언트 코드를 통합 빌드/배포할 수 있는 개발 환경을 구축해봤다. 모던한 개발 환경에서 코드를 구현한다는 것은 프로그래머에게 축복이나 다름없다. 바벨(Babel)의 등장으로 브라우저가 지원하지 않더라도 최신 자바스크립트 스펙을 적용한다는 것이 얼마나 행복한 일인지는 클라이언트 개발을 해본 사람이라면 누구나 공감할 것이다.

\n

하지만 현실은 우리의 앞을 가로막고 있는 레거시(Legacy)라는 커다란 벽이다. 개인 프로젝트가 아니라면 기존의 시스템을 새롭게 바꾼다는 것이 얼마나 어려운 일인지 다 알고 있으리라 생각된다. 그렇다면 왜 어려울까? 필자가 생각하는 가장 큰 이유는 공감을 얻기가 어렵기 때문이다. 이미 안정적으로 잘 돌아가고 있는 시스템을 괜히 건들여서 장애가 생긴다면 앞으로의 개발 일정에 차질이 생길 수 있는데, 과연 누가 이해해줄 수 있을까?

\n

앞에서 말한 문제만으로도 글 한편은 쓸 수 있을 것 같은데, 할 말은 많지만 일단 이 정도로 하겠다. 지난 글에 이어 이번에도 서론이 길었다. 그리고 지난 글과 달리 이번에는 확실한 솔루션이 아니라는 점을 참고하길 바란다. 무구한 역사와 전통이 담긴 레거시(?)는 쉽게 바꿀 수 있는 것이 아니다. 단지 필자는 조금이나마 도움이 될 수 있는 기법 몇가지를 본문에서 다룰 것이다.

\n

(1) 번들링 파일에서 모듈 제외하기

\n

기존의 웹 페이지에 내가 만든 새로운 기능이 번들링되서 배포되었다고 가정해보자. 해당 웹 페이지는 공통 기능 구현을 위한 라이브러리(jquery, moment)가 이미 로드되어 사용 중이었다. 하지만 내가 만든 새로운 기능에도 개발의 편의를 위해 jquery를 사용했다. 이런 상황이면 글로벌 모듈인 jquery가 로드되고, 새로운 기능의 번들링 파일에도 포함되어 있기 때문에 웹페이지는 jquery를 두번 로드하는게 된다.

\n

웹팩의 externals 옵션을 통해 개발 코드가 번들링 될 때, 특정 모듈을 제외시킬 수 있는데, 위와 같은 상황에서는 jquery를 제외하면 문제가 해결된다. 단지 번들링 되는 파일에서 제외하는 것이기 때문에 기존의 모듈 기반의 자바스크립트 코딩을 그대로 할 수 있게 된다.

\n

그럼, 먼저 이전 강좌에서 개발했던 프로젝트의 src/main/resources/templates/index.html에 CDN으로 배포된 jQuery 라이브러리를 로드하는 코드를 넣어보자.

\n

<script type=\"text/javascript\" src=\"https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.js\"></script>

\n

그리고 템플릿에서 jQuery 라이브러리를 로드하기 때문에 번들링 할 필요가 없기 때문에 웹팩 설정 파일에서 entry.vendors 옵션의 jquery 값을 제거하자. 마지막으로 번들링에서 제외하기 위해 externals 옵션에 key는 모듈명, value는 글로벌 변수 이름 형태로 추가할 수 있다. 글로벌 변수 이름은 문자열 뿐만이 아니라 정규식, 콜백 함수, 객체 형태로도 설정할 수 있으니 자세한 사항은 공식 문서를참고하자.

\n

...
        entry: {
            vendors: [ 'moment' ],
            index: clientPath + '/index.js'
        },
        externals: {
            jquery: \"jQuery\"
        },
        ...

\n

다음은 externals 옵션을 적용하고, 번들링 했을 때의 내부 구조이다. 이전 강좌에 봤던 트리맵에 jquery.js 노드가 빠진 것을 확인할 수 있다.

\n

$\"Example$

\n

프로젝트 다운로드

\n

이전 강좌에서 제공한 프로젝트에서 extenals 브랜치로 변경하여 체크아웃 받으면 된다.

\n

(2) 레거시 코드를 모듈로 로드하기

\n

레거시 시스템이 커지다보면 어쩔 수 없이 사용해야만 하는 자바스크립트 코드들이 존재한다. 필자의 경우, 다국어 처리를 위한 메시지를 가져오는 공통 함수를 클라이언트 개발시 사용한다.

\n

해당 자바스크립트 파일은 서버에서 특정 주기로 동기화하는 조금은 복잡한 과정을 거쳐 생성된다. 결국 레거시 코드를 모듈로 로드하여 사용해야만 하는데, externals-loader를 사용하면 이러한 문제를 해결할 수 있다.

\n

\n
npm install — save-dev exports-loader
\n

\n

다음 코드를 살펴보자. 오랜만에 ES5 코드를 보니 반갑기도 하다.

\n

var file = 'blah.txt';

var helpers = {
    test: function() {
        console.log('test something');
    },
    parse: function() {
        console.log('parse something');
    }
};

var math = {
    add: function(a, b) {
        return a + b;
    },
    subtract: function(a, b) {
        return a - b;
    }
};

\n

다음 설정을 통해 lib/utils.js 파일을 모듈로 임포트해서 사용해보자.

\n

...
            , {
                test: path.resolve(__dirname, 'lib', 'utils.js'),
                use: 'exports-loader?file,math,parse=helpers.parse'
            }]
        },
        ...
    }
}

\n

콤마(,)로 구분해서 글로벌 변수 이름을 넣어주면 되고, 만약에 객체라면 특정 프로퍼티나 메소드만 설정할 수 있다. 다음은 exports-loader 설정을 통해 생성된 모듈을 임포트하여 사용하는 코드이다.

\n

import Styles from './index.css'
import $ from 'jquery'
import mt from 'moment'
import {file, math, parse} from '../../../lib/utils.js'

$(function() {
    $(\"strong > div\").html(mt().format('MMMM Do YYYY, h:mm:ss a'));

    console.log(file)
    parse();

    alert(math.add(6, 4));
});

\n

프로젝트 다운로드

\n

이전 강좌에서 제공한 프로젝트에서 externals-loader 브랜치로 변경하여 체크아웃 받으면 된다.

\n

(3) 글로벌 변수로 모듈 사용하기

\n

웹팩은 모듈을 임포트(import) 하지 않아도, 글로벌 종속성을 가지는 객체(또는 변수)를 제공할 수 있는 기능을 제공한다. 웹팩에서 기본적으로 배포하는 ProvidePlugin을 사용하면 하는데, 동작 원리는 매우 심플하다. 코드 상단에 플러그인에 추가된 key 이름을 가지는 변수에 value 이름을 가지는 모듈을 require 해주기 때문에 jQuery를 임포트 하지 않아도 사용할 수 있다.

\n

const $ = require('jquery');
// 첫번째 라인은 ProvidePlugin에서 추가함
// 실제로는 존재하지 않음

$(function() {
  alert('onload');
}

\n

다음 코드는 순수 레거시 코드를 복사하여 붙여넣기 한 것이다. 참고로 mt는 moment 라이브러리인데, 레거시 코드에서 글로벌 변수 이름 중첩으로 인해 mt로 변경해서 사용하고 있다고 가정해보자. 그리고 math는 필자가 미리 구현해둔 커스텀 모듈이다.

\n

$(function() {
    $(\"strong > div\").html(mt().format('MMMM Do YYYY, h:mm:ss a'));

    alert(math.add(6, 4));
});

\n

export function add(a, b) {
    return a + b;
}

export function subtract(a, b) {
    return a - b;
}

\n

ProvidePlugin은 파일시스템 기반으로 동작하기 때문에 사용자가 만든 모듈의 경로만 넣어주면 얼마든지 글로벌 변수를 추가할 수 있다. 그리고 imports-loader를 사용하면 좀 더 세밀한 기능을 사용할 수 있다.

\n

plugins: [
            ...,
            new webpack.ProvidePlugin({
                $: 'jquery',
                mt: 'moment',
                math: path.resolve(__dirname, 'lib', 'math.js')
            })
        ]
    }
}

\n

\n
npm install — save-dev imports-loader
\n

\n

다음은 config.size 값을 imports-loader를 통해 설정하여, 기존의 레거시 코드에서 사용하는 코드이다.

\n

$(function() {
    $(\"strong > div\").html(mt().format('MMMM Do YYYY, h:mm:ss a'));

    alert(math.add(6, 4) + ', ' + config.size);
});

\n

imports-loader는 다양한 표현식을 사용할 수 있는데, 자세한 사항은 공식 문서를 참고하자.

\n

...
            , {
                test: clientPath + '/index.js',
                use: 'imports-loader?config=>{size:50}'
            }]
        },
        ...
    }
}

\n

다음은 ProvidePlugin과 imports-loader를 사용하고, 번들링 했을 때의 내부 구조이다. 작아서 잘 보이지 않지만 필자가 구현해둔 math.js도 포함되어 있다.

\n

$\"Example$

\n

프로젝트 다운로드

\n

이전 강좌에서 제공한 프로젝트에서 shimming 브랜치로 변경하여 체크아웃 받으면 된다.

\n

글을 마치며…

\n

그동안 프론트엔드 개발 환경은 많은 변화가 있었다. 하지만 하나의 제품을 수년간 개발하고 있는 필자는 변화의 중심에 서지 못하고, 멀찌감치 떨어져서 지켜보기만 했었다. 이제와서 고백하자면 이 글은 필자가 앞으로 해야할 일에 대한 이정표다.

\n

책 몇권 읽고, 샘플도 몇개 만들어보고, 단지 조금 안다고해서 실제 업무에 적용할 수 있는 것은 아니다. 그래서 필자는 생각을 정리하고, 누구에게나 공감을 이끌어낼 수 있는 논리를 완성하기 위해 다시 글을 썼다.

", "url": "https://alvin.ing/blog/applying-webpack-to-legacy", "title": "레거시(Legacy) 시스템에 웹팩 개발환경 적용하기", "summary": "“Webpack+SpringBoot 기반의 프론트엔드 개발 환경 구축하기” 편에서 스프링부트 프로젝트를 생성하고, 서버와 클라이언트 코드를 통합 빌드/배포할 수 있는 개발 환경을 구축해봤다. 모던한 개발 환경에서 코드를 구현한다는 것은 프로그래머에게 축복이나 다름없다. 바벨(Babel)의 등장으로 브라우저가 지원하지 않더라도 최신 자바스크립트 스펙을 적용한다는 것이 얼마나 행복한 일인지는 클라이언트 개발을 해본 사람이라면 누구나 공감할 것이다.", "date_modified": "2018-08-22T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "Webpack", "Legacy" ] }, { "id": "https://alvin.ing/blog/coding-the-matrix-1", "content_html": "

글을 시작하며…

\n

작년에 머신러닝에 대한 검색을 하다가 우연히 “수학을 포기한 직업 프로그래머가 기계학습을 시작하기 위한 최단경로”라는 번역 글을 보고, 처음으로 선형대수에 대해 관심을 가지고 공부를 시작했다.\n해당 글에서 프로그래머를 위한 수학책으로 “코딩 더 매트릭스”를 추천했는데, 실은 그 책 때문에 연재 글을 기획하게 되었다.\n필자는 수포자의 길을 30년 넘게 걸어온 사람으로서 “코딩 더 매트릭스”는 굉장히 이해하기가 어려운 책이었다.\n그래서 필자는 큰 흐름은 선형대수를 시각적으로 이해하는 형태로 글을 연재할 예정이며, 세부 내용은 “코딩 더 매트릭스”에서 많이 차용할 생각이다.

\n

코딩 더 매트릭스

\n

필자는 일주일에 한번 “코딩 더 매트릭스” 스터디 모임을 갖는다.\n벌써 스터디가 시작된지 1년이 넘었지만 이제 겨우 70% 정도 진행한 것 같다.\n원래 공부를 잘하는 사람이 아니지만 살면서 이렇게 난해한 책은 처음봤다.\n물론 번역서라서 원서의 의도가 제대로 전달되지 않은 것일 수도 있지만 저자가 무엇을 말하고 싶은지 어떤 의미를 말하는지 필자의 수준으로는 해석하기 어려운 부분이 너무 많았다.\n또한 “코딩 더 매트릭스” 본문에서 제공되는 각종 예제들이 제대로 동작하지 않을뿐더러 관련된 자료를 찾기가 매우 어려웠다.\n그래서 자료를 찾기 위해 열심히 검색해봤는데, 우리나라 뿐만이 아니라 외국에서도 “코딩 더 매트릭스”를 완독한 사람이 많지 않은 것으로 파악되어 1년이 넘도록 완독하지 못한 자괴감에서 조금이나마 벗어날 수 있었다.

\n

진행 방식

\n

본문에서는 주제와 관련된 수학 공식이나 개념에 대해 자세히 다루지 않을 것이다.\n그래서 글을 읽기 전에 최소한 주제에 해당하는 수학적 지식은 갖추고 있어야 한다.\n필자는 수포자가 되기 전에는 왜 수학을 공부해야 하는지 몰랐었고, 개발자로 일하면서 중요성은 알았지만 수학의 필요성에 대해 제대로 이해하지 못했었다.\n그래서 필자는 본문에서 다룰 주제에 대해 어떻게 응용될 수 있는지 필요성에 대한 근본적인 질문을 해볼 것이며, 최대한 시각적으로 표현하거나 실제로 응용해볼 수 있는 방법으로 답을 찾아볼 것이다.\n그리고 본문에서 소개되는 예제에서 기하학적 요소는 자바스크립트(jui)로 구현할 것이며, 행렬이나 복소수 연산을 위해 파이썬(numpy)을 사용할 것이다.

\n

선형연립방정식

\n

2개 이상의 미지수를 포함하는 2개 이상의 방정식의 쌍이 주어지고, 미지수가 주어진 모든 방정식을 동시에 만족할 것이 요구되어 있을때, 이 방정식의 쌍을 연립방정식이라고 한다.\n아래 인용구는 이상구 교수님의 선형대수 강의에서 발췌한 내용이다. (링크)

\n

\n
역사적으로 선형대수학의 가장 중요한 주제 중 하나가 선형연립방정식과 해법이다. 21세기 우리는 수천 개의 미지수를 갖는 연립방정식을 자연과학, 공학, 경제학, 교통의 흐름, 일기예보, 의사결정 등 수많은 분야에서 만난다. 컴퓨터의 계산능력(computing power)이 향상됨에 따라 응용학문에서 선형대수학의 중요성은 날로 커져 왔다. 컴퓨터는 병렬처리와 대규모 계산을 매개로 선형대수학과 긴밀하게 연결된다. 이로 인해 현재의 과학자, 공학자들은 이전에는 상상만 하던 매우 복잡한 문제를 다를 수 있게 되었다. 또 선형대수학의 지식은 어떤 과목보다 더 넓은 과학, 경영분야의 활용도를 지닌다.
\n

\n

예를 들어 직선의 방정식으로 그린 두 개의 직선이 있을 때, 두 직선의 교점을 선형연립방정식의 유일한 해(solution)라고 한다.\n만약에 두 직선이 평행하다면 교점이 존재하지 않으므로 해를 갖지 않는게 되며, 두 직선이 겹친다면 무수히 많은 해를 가지게 된다.\n즉, 선형연립방정식의 해집합은 앞에서 말한 세가지 가능성 중에 하나만 성립한다. 그럼, 먼저 간단하게 두 직선의 방정식의 해를 구해보도록 하자.

\n

$\"Example$

\n

아래 예제에서 빨간색 직선은 방정식 (1)이며, 파란색 직선은 방정식 (2)를 그린 것이다.\n두 직선이 교차하는 부분에 마우스를 올리면 나타나는 좌표가 바로 교점(3,2)이다.\n해당 좌표 값을 방정식 (1), (2)에 각각 대입해보면 방정식이 성립한다는 것을 확인할 수 있다.

\n

$\"Example$

\n

선형연립방정식 응용

\n

앞에서 직선의 방정식이 다수가 존재하고 유일한 해가 존재할 때, 교점을 구하는 방법에 대해 알아보았다.\n지금부터는 반대로 지나는 점들을 가지고 원의 방정식과 방데르몽드 다항식을 구하여 차트로 그려볼 것이다.\n원의 방정식의 일반형은 아래와 같다.

\n

$\"Example$

\n

지나는 점의 좌표값 (-2,2), (4,-6), (5, -5)를 알고 있다면 원의 방정식의 일반형에 각각 x와 y값을 대입한다.

\n

$\"Example$

\n

다소 복잡해졌지만 연립방정식을 풀면 각각 a=-2, b=4, c=-20가 구해지는데, 이 값들을 다시 원의 방정식에 대입한다.

\n

$\"Example$

\n

완성된 원의 방정식에 x값을 차트에서 지정된 모든 좌표를 대입하여 y값을 구하는 방식으로 그렸는데, 성능에 문제가 많고 최적의 방법은 아니라서 권장하지는 않는다.\n관련해서는 각자 기호에 맞게 구현해보는 것으로 하자.

\n

$\"Example$

\n

이제 어느 정도는 선형연립방정식을 어떻게 활용해야 하는지에 대한 감이 올 것 같은데, 추가로 다수의 점을 지나는 곡선을 그릴 수 있는 라그랑주(lagrange) 다항식을 구하여 차트로 그려보면 좀 더 확신이 생길것 같다.

\n

$\"Example$

\n

일단 네 점의 좌표값 (1,3), (2,-2), (3,-5), (4,0)를 라그랑주 다항식에 각각 x와 y 값을 대입한다.

\n

$\"Example$

\n

원의 방정식과 동일하게 연립방정식을 풀면 각각 a0=3, a1=3, a2=-5, a3=1이 구해는데, 이 값들을 다시 라그랑주 다항식에 대입한다.

\n

$\"Example$

\n

완성된 라그랑주 다항식에 원의 방정식과 동일한 방법으로 x값에 지정된 모든 좌표를 대입하여 y값을 구하는 방식으로 그리면 된다.

\n

$\"Example$

\n

결론

\n

웹에서 그래픽을 표현하기 위해 SVG나 캔버스에서 제공되는 API를 사용하면 매우 쉽게 선이나 도형 같은 그래픽 요소들을 그릴 수 있다.\n예를 들어 선을 그리기 위해서 두 점의 좌표만 입력하면 쉽게 그릴 수 있는데, 내부적으로는 두 점의 관계에 대한 직선의 방정식을 구하고, 최대한 자연스러운 형태로 그려질 수 있도록 별도의 알고리즘이 적용되어 있을 것이다. 이는 직선 뿐만이 아니라 원이나 타원 등의 다양한 방정식에 적용될 수 있다. 필자는 방정식의 원형을 일종의 템플릿으로 규정하고, 지나는 점들의 좌표를 템플릿에 적용되는 입력 값이라고 생각한다.\n값이 입력이 되고 생성된 템플릿의 집합을 연립방정식으로 다시 규정하고, 구해진 유일한 해(solution)를 방정식의 계수에 대입하여 최종의 방정식을 구한다.\n조금 복잡한 과정이라고 생각할 수 있지만 입력하는 부분과 해를 구하는 부분은 공통적인 사항이고, 그려지는 모양에 따라 방정식만 다르게 적용하면 되기 때문에 일종의 템플릿이라고 규정한 것이다.

\n

글을 마치며…

\n

선형대수를 공부하는 것 자체만으로도 필자에게는 매우 큰 도전이었다.\n그리고 이에 대한 글을 쓴다는 것은 상상조차 할 수 없는 일이었다.\n그래서 누군가에게 내가 알고 있는 것을 공유하겠다는 차원이 아닌 필자의 생각을 정리하고, 이게 정말 옳은 생각인지 스스로에게 묻기 위한 행동이라고 말하고 싶다.\n마지막으로 이상구 교수님의 선형대수 강의에서 소개된 응용 사례를 소개하고 글을 마치겠다.

\n

\n
한 천문학자가 어떤 소행성 궤도를 구하려고 한다. 이를 위해 그는 태양을 원점으로 갖는 좌표평면을 설정하였다. 축의 눈금 단위들은 천문학의 측정단위(천문학 단위 1은 지구에서 태양까지의 평균거리이며 약 149,637,000km)가 사용된다. 행성은 타원형 궤도를 따라 운행한다. (케플러의 제1법칙)
\n

\n

천문학자는 다섯 번에 걸쳐 행성의 위치를 나타내는 (8.025,8.310), (10.170,6.355), (11.202,3.212), (10.736,0.375), (9.092,2.267) 관측점을 구하고, 이를 본문에서 다룬 방법으로 타원의 방정식을 구해서 그리면 행성의 궤도를 알 수 있게 된다.

\n

$\"Example$

", "url": "https://alvin.ing/blog/coding-the-matrix-1", "title": "코딩 더 매트릭스 살펴보기 (연립 방정식)", "summary": "글을 시작하며…", "date_modified": "2017-11-27T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "선형대수", "Coding the Matrix" ] }, { "id": "https://alvin.ing/blog/webpack-springboot-starter", "content_html": "

필자가 회사에서 개발 중인 제니퍼5의 수요가 크게 늘어남에 따라 고객의 기호에 맞게 화면에 대한 커스터마이징을 요구하는 경우가 많아졌다. 하지만 기존의 프로젝트에 커스터마이징 코드를 넣는 것은 바람직하지 않기 때문에 외부에서 구현하고, 플러그인처럼 추가하고 삭제할 수 있는 구조를 고민해야만 했다.

\n

제니퍼5 뷰서버는 개발을 시작한지 7년이 넘은 꽤 오래된 코드로 구현되어 있다. 기반 프레임워크는 스프링3 버전이었는데, 플러그인 구조를 만들기 위해 큰 용기(?)를 내서 스프링4 버전으로 업그레이드 했다

\n

어떻게 구현할까 오랫동안 고민했었는데, 그냥 단순하게 스프링 컨텍스트에 같이 올리는 방법을 택했다. 회사의 서버 개발자 분의 도움을 받아 간단한 클래스 로더를 만들었고, 외부에서 개발한 플러그인 jar 파일을 제니퍼5 뷰서버가 시작할 때, 같이 올라가는 구조였다.

\n

이렇다보니 플러그인을 수정할 때마다 jar 파일을 생성하기 위해 빌드하고, 제니퍼5 뷰서버를 재시작 해야하는 번거로운 일을 반복하게 되었다. 그래서 독립적인 개발환경 구성을 위해 스프링부트(SpringBoot)와 웹팩(Webpack)을 고려하게 되었다.

\n

서론이 많이 길어져서 독립적인 개발환경 구성에 대한 내용은 이 정도로 하고, 바로 본론으로 넘어가도록 하겠다. 본문에서는 인텔리제이(IntelliJ)에서 스프링부트 프로젝트를 생성하고, 스프링부트 재시작 없이 클래스와 리소스를 동적으로 반영해주는 핫스왑(Hot-Swap)에 대해 알아볼 것이다. 또한 웹팩 기반으로 스프링부트 프로젝트와 연계하여 프론트엔드 개발환경을 직접 구성해볼 것이다.

\n

(1) 스프링부트 핫스왑 설정하기

\n

그럼, 먼저 스프링부트 프로젝트를 생성해보자.

\n

File > New > Project 클릭
Spring Initialzr > Project SDK 선택 (1.8) > Next 클릭
Project Metadata 입력 > Type 선택 (Maven Project) > Next 클릭
Dependencies 입력 > Spring Boot 버전 선택 (1.5.15) > 라이브러리 선택
본문에서는 화면 개발과 핫스왑을 위한 최소한의 라이브러리만 선택하지만 개발 환경에 맞게 알아서 추가로 선택하면 된다.

\n

$\"Example$

\n

템플릿 엔진은 기호에 맞게 다른걸 사용해도 상관없다. 이제 프로젝트가 생성되었으니 앞으로 두가지 설정만 하면 핫스왑 기능을 사용할 수 있게 된다.

\n

\n
다시 확인해보니 DevTools 라이브러리를 사용하지 않아도 된다. 핫스왑은 인텔리제이에서 제공해주는 아주 유용한 기능이다.
\n

\n

먼저 Preferences… 메뉴로 가서 Build, Execution, Deployment 탭의 Compiler 메뉴를 선택하고, Build project automatically를 체크해주면 된다.

\n

$\"Example$

\n

마지막으로 Registry 설정 화면을 열어서 compiler.automake.allow.when.app.running 옵션을 체크해주자.

\n

$\"Example$

\n

$\"Example$

\n

서버 개발환경은 이렇게 간단하게 구성하였지만 클라이언트 개발환경은 프로젝트 목적에 따라 차이가 있을 수 있다.

\n

\n
핫스왑 기능이 동작하기 위해서는 메인 클래스를 디버그 모드로 실행해야 하며, 코드를 수정하고나서 Build Project를 직접 실행해야만 반영이 빠르다.\n참고로 순수 자바 클래스만 변경되었을 때만 동작하며, 스프링 관련 설정이나 컨텍스트에 변화가 있으면 메인 클래스를 재시작해야 한다.
\n

\n

(2) 웹팩 설치하기

\n

본문에서는 React나 Vue.js와 같은 프레임워크는 다루지 않으며, 클라이언트 개발을 위한 최소한의 환경만 구성할 것이다.\n아주 당연한 얘기지만 Node.js와 NPM 패키지 관리자가 설치되어 있어야 하며, 모듈 번들링이 무엇인지에 대한 사전 이해가 필요하다.

\n

그럼, 먼저 package.json 파일을 생성해보자. 인텔리제이 하단에 있는 터미널 탭을 선택하여 콘솔에 npm init을 입력한다.

\n

$\"Example$

\n

명령어를 입력하고, 패키지 이름이나 버전 등을 입력할 수 있는데, 프로젝트 특성에 맞게 적당히 입력하거나 그냥 엔터키를 눌러서 기본값으로 설정할 수도 있다.

\n

웹팩은 버전마다 설정 방식이 많이 다르므로 본문에서 다루는 내용은 최신 버전인 4.16.5를 기준으로 한다.

\n

\n
npm install — save-dev webpack webpack-cli webpack-dev-server

\n+webpack-cli@3.1.0
\n+webpack-dev-server@3.1.5
\n+webpack@4.16.5
\n

\n

webpack-cli는 웹팩 명령어 수행을 위한 패키지이고, webpack-dev-server는 스프링부트로 실행한 서버와 연계하기 위한 프록시 서버로 사용된다. 관련된 설명은 잠시 후에 나오니 일단은 넘어가도록 하자.

\n

웹팩 설치가 완료되었으니 이제 모듈 번들링을 위한 로더들을 설치해야 한다. 로더의 종류는 매우 다양하지만 본문에서는 필자가 생각했을 때, 기본이 된다고 생각하는 것들만 다룰 것이다.

\n

babel-loader : 자바스크립트 모듈 번들링을 위한 로더이며, 보통 ES6 코드를 ES5로 변환하기 위해 사용한다.
css-loader : 모듈 번들링은 자바스크립트 기반으로 이뤄지기 때문에 CSS 파일을 자바스크립트로 변환하기 위해 사용한다.
style-loader : css-loader에 의해 모듈화 되고, 모듈화 된 스타일 코드를 HTML 문서의 STYLE 태그 안에 넣어주기 위해 사용된다.
url-loader : 스타일에 설정된 이미지나 글꼴 파일을 문자열 형태의 데이터(Base64)로 변환하여 해당 CSS 파일 안에 포함시켜버리기 때문에 정적 파일을 관리하기 쉬워진다. 하지만 실제 파일들보다 용량이 커지고, CSS 파일이 무거워지므로 적당히 사용하는 것을 권장한다.
file-loader : 정적 파일을 로드하는데 사용되며, 보통 프로젝트 환경에 맞게 특정 디렉토리에 파일을 복사하는 역할을 수행한다.

\n

참고로 바벨은 프리셋을 함께 설치해줘야 한다. 관련해서 설명할 내용이 많지만 본문의 주제에서 벗어나니 보편적으로 사용되는 것을 선택했다.

\n

\n
npm install — save-dev babel-core babel-loader babel-preset-env css-loader style-loader url-loader file-loader
\n

\n

마지막으로 웹팩 실행을 위한 NPM 스크립트를 추가해보자. package.json의 최종 모습은 다음과 같을 것이다. 특이한건 env 변수인데, 웹팩 설정 파일 내에서 개발/배포 모드를 구분하기 위함이다.

\n

{
  \"name\": \"frontend\",
  \"version\": \"1.0.0\",
  \"description\": \"\",
  \"main\": \"src/main/client/index.js\",
  \"scripts\": {
    \"prod\": \"webpack --env=production\",
    \"dev\": \"webpack-dev-server --env=development\",
    \"start\": \"npm run dev\"
  },
  \"author\": \"\",
  \"license\": \"ISC\",
  \"devDependencies\": {
    \"babel-core\": \"^6.26.3\",
    \"babel-loader\": \"^7.1.5\",
    \"babel-preset-env\": \"^1.7.0\",
    \"css-loader\": \"^1.0.0\",
    \"file-loader\": \"^1.1.11\",
    \"style-loader\": \"^0.22.1\",
    \"url-loader\": \"^1.0.1\",
    \"webpack\": \"^4.16.5\",
    \"webpack-cli\": \"^3.1.0\",
    \"webpack-dev-server\": \"^3.1.5\"
  }
}

\n

나중에 자세히 설명하겠지만, 일단 NPM 스크립트를 기억하고 있자.

\n

\n
개발할 때, npm run dev 또는 npm start
\n배포할 때, npm run prod
\n

\n

(3) 스프링부트 컨트롤러 만들기

\n

갑자기 스프링부트로 바뀌어서 당혹스럽겠지만 웹팩 설정을 하기에 앞서 간단하게 컨트롤러와 뷰를 만들어보자.

\n

package com.example.frontend;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
public class FrontendController {
    @RequestMapping(\"/hello\")
    public String home(Model model){
        model.addAttribute(\"message\", \"Hello, World!!!\");
        return \"index\";
    }
}

\n

다음은 홈 컨트롤러에서 받은 메시지 텍스트를 출력하는 템플릿 코드이다. 여기서 index.js를 로드하는데, 스프링부트는 src/main/resources/static 디렉토리를 정적 리소스 루트로 설정하기 때문에 index.js 파일은 여기에 두어야 한다.\n물론 해당 디렉토리는 개발자 임의로 변경할 수도 있다.

\n

<!DOCTYPE html>
<html xmlns:th=\"http://www.thymeleaf.org\">
<head>
    <meta charset=\"utf-8\" />
    <script type=\"text/javascript\" src=\"/index.js\" th:src=\"@{/index.js}\"></script>
</head>
<body>
<strong><div th:text=\"${message}\"></div></strong>
</body>
</html>

\n

스프링부트를 실행하고, http://127.0.0.1:8080/hello으로 이동하면 “Hello, World!!!” 메시지가 HTML 문서에 출력되고, 경고창에 “onload!!” 메시지가 보일 것이다.

\n

window.onload = function() {
    alert(\"onload!!\");
}

\n

(4) 웹팩 기본 설정하기

\n

웹팩은 진입점이라고 할 수 있는 엔트리 js 파일을 설정해야 한다. 엔트리 js 파일을 통해 각각의 모듈들을 로딩하고, 하나의 아웃풋 파일로 묶어(bundle)준다. 웹팩 개발 서버(webpack-dev-server)는 코드의 변경을 감지할 때마다 다시 번들링을 한다. 또한 아웃풋 파일이 적용된 화면을 실시간 리로딩(Live Reloading)하는 inline 옵션과 부분 모듈 리로딩(Hot Module Reloading)하는 hot 옵션을 제공한다.

\n

앞에서 개발한 스프링부트 뷰에서 사용하기 위해서는 아웃풋 파일이 최종적으로 src/main/resources/static 디렉토리에 위치해야 한다. 하지만 클라이언트 코드를 수정할 때마다 static 디렉토리에 아웃풋 파일이 반영되면 스프링부트 핫스왑 기능이 활성화 되어 불필요한 스프링 컨텍스트 리로드가 발생할 수 있다.

\n

그래서 필자는 클라이언트 아웃풋 파일을 별도의 디렉토리에 생성하게 하고, 해당 디렉토리를 웹팩 개발 서버의 루트(contentBase)로 설정할 것이다. 그렇다면 이미 실행 중인 스프링부트와 연계는 어떻게 할 수 있을까? 일단 웹팩 설정 파일부터 살펴보자.

\n

const path = require('path')

module.exports = (env) => {
    let clientPath = path.resolve(__dirname, 'src/main/client');
    let outputPath = path.resolve(__dirname, 'out');

    return {
        mode: !env ? 'development' : env,
        entry: {
            index: clientPath + '/index.js'
        },
        output: {
            path: outputPath,
            filename: '[name].js'
        }
    }
}

\n

일단 env 변수는 NPM 명령어 실행시 넘겨주는 값이다. 웹팩4부터는 mode에 development 또는 production을 명시해야 한다. 일단 배포 환경 구성은 현재 다루지 않으니 이 부분은 넘어가도록 하겠다.

\n

앞에서 생성한 스프링부트 프로젝트에서 클라이언트 개발 코드는 src/main/client 디렉토리에서 관리하기로 하고, 해당 디렉토리에 있는 index.js 파일을 엔트리 js 파일로 설정했다. 그리고 아웃풋 파일의 생성 디렉토리는 src/main/resources/static이 아닌 out으로 설정했다. 참고로 output.filename 옵션 값이 [name].js인데, 여기서 [name]은 entry 옵션의 key 이름으로 치환된다. 이 밖에도 [id], [hash] 같은 치환 문자열이 있다.

\n

다음은 웹팩 개발 서버 설정이다. 먼저 devServer.contentBase 옵션 값은 아웃풋 파일들이 생성되는 디렉토리와 맞춰야 하기 때문에 output.path와 동일하게 설정해야 한다. devServer.port는 스프링부트 포트와 다른 값을 설정하면 된다. 마지막으로 웹팩 개발 서버와 스프링부트를 연계하기 위해 devServer.proxy 옵션을 사용한다. key는 요청 URL이고, value는 프록시 대상이다.

\n

http://127.0.0.1:8081/hello로 접근하면 스프링부트 컨트롤러에서 넘긴 값으로 구현된 뷰에서 웹팩 개발 서버의 contentBase 옵션에 설정된 디렉토리 안에 있는 정적 파일들을 로드할 수 있게 된다.

\n

...,
        devServer: {
            contentBase: outputPath,
            publicPath: '/',
            host: '0.0.0.0',
            port: 8081,
            proxy: {
                '**': 'http://127.0.0.1:8080'
            },
            inline: true,
            hot: false
        }
    }
}

\n

간단하게 프록시 설정이 잘되어 있는지 확인하기 위해 src/main/client 디렉토리에 index.js 파일을 추가하자. 아까 만든 index.js와 차이를 두기 위해 메시지를 “proxy onload!!”로 변경했다.

\n

window.onload = function() {
    alert(\"proxy onload!!\");
}

\n

그럼, 스프링부트와 웹팩 개발 서버를 실행해보자.

\n

npm start
webpack-dev-server — env=development

ℹ ｢wds｣: Project is running at http://0.0.0.0:8081/
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: Content not from webpack is served from /Users/alvin/Documents/Workspace/springboot/frontend/out
ℹ ｢wdm｣: Hash: 5d0bf01db3a4b9a400bf
Version: webpack 4.16.5
Time: 395ms
Built at: 08/16/2018 7:25:02 PM
Asset Size Chunks Chunk Names
index.js 338 KiB index [emitted] index
Entrypoint index = index.js

\n

http://127.0.0.1:8080/hello로 접속하면 경고창에 “onload!!” 메시지가 보일 것이고, http://127.0.0.1:8081/hello로 접속해서 “proxy onload!!” 메시지가 보인다면 웹팩 기본 설정이 잘 완료된 것이다.

\n

(5) 웹팩 로더 설정하기

\n

앞에서 엔트리와 아웃풋을 설정했다. 현재 설정으로는 오직 js 파일만 번들링 할 수 있다. 하지만 클라이언트 개발은 css 파일이나 이미지 파일들도 필요하기 때문에 관련된 웹팩 로더를 추가해줘야 한다.

\n

참고로 css 파일은 로드하더라도 js 파일로 번들링 되기 때문에 관련 플러그인을 추가로 설치하여 css 파일만 따로 분리할 것이다.

\n

\n
npm install — save-dev mini-css-extract-plugin
\n

\n

앞에서 style-loader에 대한 설명을 했는데, 본문에서는 다루지 않을 것이다. 개발 뿐만이 아니라 배포까지 생각하면 STYLE 태그에 스타일 코드가 들어가는 것보단 하나의 css 파일로 번들링되는 것이 바람직하다고 생각한다.

\n

const path = require('path')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')

module.exports = (env) => {\tmodule.exports = (env) => {
    let clientPath = path.resolve(__dirname, 'src/main/client');
    let outputPath = path.resolve(__dirname, 'out');

    return {
        ...,
        module: {
            rules: [{
                test: /\\.js$/,
                use: [{
                    loader: 'babel-loader',
                    options: {
                        presets: 'env'
                    }
                }]
            }, {
                test: /\\.(css)$/,
                use: [{
                    loader: MiniCssExtractPlugin.loader
                }, {
                    loader: 'css-loader'
                }]
            }]
        },
        plugins: [
            new MiniCssExtractPlugin({
                path: outputPath,
                filename: '[name].css'
            })
        ]
    }
}

\n

웹팩 설정 파일에 추가된 module 옵션을 살펴보면 babel-loader를 통해 ES6 코드를 ES5로 변환할 수 있다. style-loader는 방금 설치한 MiniCssExtractPlugin.loader로 변경되었고, 엔트리 js 파일에서 css 파일을 로드하기 위해 css-loader도 함께 사용되었다.

\n

여기서 중요한 점은 plugins 옵션에 MiniCssExtractPlugin 객체가 추가되었다는 사실이다. 번들링 된 css 파일은 기존의 아웃풋 파일과 같은 디렉토리에 위치해야하므로 path 옵션 값은 output.path와 동일하다. 그리고 css 파일 이름은 entry 옵션에 설정된 key 이름으로 치환된다.

\n

이제 js 파일 뿐만이 아니라 css 파일까지 번들링 할 수 있게 되었는데, 뭔가 부족하다. 스타일에서 이미지를 사용하고 싶을 때는 어떻게 해야할까?

\n

이미지 파일 사용하기

\n

답은 바로 url-loader와 file-loader를 사용하는 것이다. 필자는 정적 파일 관리가 귀찮아서 url-loader를 선호하는 편인데, 아무래도 번들링 된 css 파일이 엄청 커질 수 있기 때문에 크기가 작은 이미지만 사용하는게 좋다.

\n

본문에서는 두가지 로더를 모두 테스트해보기 위해 svg 파일은 file-loader를 사용하고, 나머지 이미지 파일은 url-loader를 사용하였다. 단순히 테스트 용도이므로 취향에 맞게 알아서 고쳐서 사용하면 된다.

\n

...
        module: {
            rules: [..., {
                test: /\\.(jpe?g|png|gif)$/i,
                use: [{
                    loader: 'url-loader',
                    options: {
                        limit: 1024 * 10 // 10kb
                    }
                }]
            }, {
                test: /\\.(svg)$/i,
                use: [{
                    loader: 'file-loader',
                    options: {
                        name: '[name].[ext]',
                        outputPath: 'images/'
                    }
                }]
            }]
        },
        ...

\n

두개의 로더를 추가했다. 먼저 url-loader는 10KB 미만의 jpg, png, gif 파일을 문자열 형태의 데이터(Base64)로 변환한다. 그리고 svg 파일만 file-loader에서 가져오게 되는데, outputPath 옵션을 통해 가져온 svg 파일의 디렉토리를 설정한다. svg 파일 이름이 webpack.svg라면 http://127.0.0.1:8081/images/webpack.svg 경로로 화면에 로드된다.

\n

프로젝트 코드 수정하기

\n

이제 웹팩 로더 설정도 끝났겠다. 앞에서 말한 내용들을 테스트해보기 위해 index.css와 index.html 파일을 수정해보자.

\n

strong {
    color : red;
}

.pattern {
    width: 300px;
    height: 64px;
    display: inline-block;
    background-image: url(\"./images/globe.png\");
    background-repeat: repeat-x;
}

.image {
    width: 300px;
    height: 300px;
    display: inline-block;
    background-image: url(\"./images/webpack.svg\");
}

\n

<!DOCTYPE html>
<html xmlns:th=\"http://www.thymeleaf.org\">
<head>
    <meta charset=\"utf-8\" />
    <script type=\"text/javascript\" src=\"/index.js\" th:src=\"@{/index.js}\"></script>
    <link rel=\"stylesheet\" type=\"text/css\" media=\"all\" href=\"/index.css\" th:href=\"@{/index.css}\" />
</head>
<body>
    <h1>default</h1>
    <strong><div th:text=\"${message}\"></div></strong>
    <br/>

    <h1>url-loader</h1>
    <div class=\"pattern\"></div>
    <br/>

    <h1>file-loader</h1>
    <div class=\"image\"></div>
</body>
</html>

\n

(6) 청크(chunk) 관리하기

\n

클라이언트 개발을 하다보면 다양한 라이브러리들을 사용하게 된다. 현재 웹팩 설정으로 번들링하게 되면 아웃풋 파일의 크기가 엄청 커질 것이고, 초기 로딩 속도에도 악영향을 미칠 것이다. 그럼, 지금부터 아웃풋 파일을 현재 개발 중인 코드와 라이브러리로 분리해보자.

\n

\n
npm install — save jquery moment
\n

\n

테스트를 위해 jquery와 moment 라이브러리를 설치했다. 그리고 jquery와 moment를 사용하여 onload 시점에 현재 시간을 출력해주는 코드를 추가했다.

\n

import Styles from './index.css'
import $ from 'jquery'
import moment from 'moment'

$(function() {
    $(\"strong > div\").html(moment().format('MMMM Do YYYY, h:mm:ss a'));
});

\n

코드를 분리하지 않으면 다음과 같이 아웃풋 파일의 용량이 매우 커진다.

\n

$\"Example$

\n

그럼, 다시 웹팩 설정 파일을 수정해보자.

\n

...
        entry: {
            vendors: [ 'jquery', 'moment' ],
            index: clientPath + '/index.js'
        },
        output: {
            path: outputPath,
            filename: '[name].js'
        },
        optimization: {
            splitChunks: {
                chunks: 'all',
                cacheGroups: {
                    vendors: {
                        test: /[\\\\/]node_modules[\\\\/]/,
                        name: 'vendors'
                    }
                }
            }
        },
        ...

\n

entry 옵션에 vendors가 추가된 것을 확인할 수 있다. index와 달리 문자열 배열 값이 들어있는데, 실제로 사용한 라이브러리 이름을 명시하면 된다. 다음은 optimization.splitChunks 옵션이다. 여기서 중요한건 청크 대상을 node_modules 디렉토리 내로 제한한 것이다.

\n

청크 방법은 너무 다양해서 별도의 주제로 다루는 것이 좋을 것 같으니 본문에서는 이 정도로 설명을 마치겠다. 그리고 아웃풋 파일이 하나 더 생겼으니 index.html 파일도 변경하도록 하자.

\n

<head>
    <meta charset=\"utf-8\" />
    <script type=\"text/javascript\" src=\"/vendors.js\" th:src=\"@{/vendors.js}\"></script>
    <script type=\"text/javascript\" src=\"/index.js\" th:src=\"@{/index.js}\"></script>
    <link rel=\"stylesheet\" type=\"text/css\" media=\"all\" href=\"/index.css\" th:href=\"@{/index.css}\" />
</head>

\n

(7) 배포 환경 설정하기

\n

그동안 번들링 된 아웃풋 파일들을 웹팩 개발 서버의 contentBase 디렉토리에 두고 프록시를 통해 스프링부트 뷰에서 로드했었다. 배포 시점이 되면 아웃풋 파일들을 스프링부트의 정적 리소스 루트 디렉토리로 옮겨야 한다.

\n

배포를 위한 빌드 설정은 매우 간단하다. 웹팩 설정 파일에서 처음 정의한 outputPath 변수 값을 스프링부트의 정적 리소스 루트 디렉토리로 설정하면 된다.

\n

// Before
let outputPath = path.resolve(__dirname, 'out')

// After
let outputPath = path.resolve(__dirname, (env == 'production') ? 'src/main/resources/static' : 'out')

\n

수정이 완료되었으면 다음과 같이 NPM 스크립트를 실행한다.

\n

npm run prod

> frontend@1.0.0 prod /Users/alvin/Documents/Workspace/springboot/frontend
> webpack — env=production

Hash: 8d360cf3a938a8cf0cf7
Version: webpack 4.16.5
Time: 7262ms
Built at: 08/17/2018 1:39:52 AM

\n

이제는 스프링부트만 실행해도 클라이언트 코드가 잘 동작하는 것을 확인할 수 있을 것이다. 하지만 아직 뭔가 부족하다. 아무래도 배포되는 파일인데, 최적화를 해야할 것 같다.

\n

웹팩4에서 기본으로 배포되고 있는 uglify-webpack-plugin과 optimize-css-assets-webpack-plugin을 추가로 설치하여 배포 시점의 아웃풋 파일들을 최적화 해보자.

\n

\n
npm install — save-dev optimize-css-assets-webpack-plugin
\n

\n

드디어 마지막 단계이다. 배포 모드일 때, optimization.minimizer 옵션에 두 플러그인의 객체를 추가해주면 모든 웹팩 설정이 끝이난다.

\n

const path = require('path')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const UglifyJsPlugin = require('uglifyjs-webpack-plugin')
const OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin')

module.exports = (env) => {
    let clientPath = path.resolve(__dirname, 'src/main/client');
    let outputPath = path.resolve(__dirname, (env == 'production') ? 'src/main/resources/static' : 'out')

    return {
        mode: !env ? 'development' : env,
        entry: {
            vendors: [ 'jquery', 'moment' ],
            index: clientPath + '/index.js'
        },
        output: {
            path: outputPath,
            filename: '[name].js'
        },
        optimization: {
            splitChunks: {
                chunks: 'all',
                cacheGroups: {
                    vendors: {
                        test: /[\\\\/]node_modules[\\\\/]/,
                        name: 'vendors'
                    }
                }
            },
            minimizer: (env == 'production') ? [
                new UglifyJsPlugin(),
                new OptimizeCssAssetsPlugin()
            ] : []
        },
        devServer: {
            contentBase: outputPath,
            publicPath: '/',
            host: '0.0.0.0',
            port: 8081,
            proxy: {
                '**': 'http://127.0.0.1:8080'
            },
            inline: true,
            hot: false
        },
        module: {
            rules: [{
                test: /\\.js$/,
                use: [{
                    loader: 'babel-loader',
                    options: {
                        presets: 'env'
                    }
                }]
            }, {
                test: /\\.(css)$/,
                use: [{
                    loader: MiniCssExtractPlugin.loader
                }, {
                    loader: 'css-loader'
                }]
            }, {
                test: /\\.(jpe?g|png|gif)$/i,
                use: [{
                    loader: 'url-loader',
                    options: {
                        limit: 1024 * 10 // 10kb
                    }
                }]
            }, {
                test: /\\.(svg)$/i,
                use: [{
                    loader: 'file-loader',
                    options: {
                        name: '[name].[ext]',
                        outputPath: 'images/'
                    }
                }]
            }]
        },
        plugins: [
            new MiniCssExtractPlugin({
                path: outputPath,
                filename: '[name].css'
            })
        ]
    }
}

\n

(8) 보너스

\n

이렇게 강좌가 끝나면 아쉬워할것 같아서 개발할 때, 도움이 될 만한 플러그인을 추가로 소개할까한다. js 파일들이 하나의 아웃풋 파일로 번들링 될 때, 내부 구조가 궁금할 수 있다. 또한 청크 설정이 잘못되어 생각했던 것과 다르게 파일이 분리되는 경우도 있다.

\n

\n
npm install — save-dev webpack-bundle-analyzer
\n

\n

플러그인을 설치하고, 다음과 같이 웹팩 설정 파일을 수정하자.

\n

...
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin

module.exports = (env) => {
    ...

    return {
        plugins: [
            ...
            , new BundleAnalyzerPlugin()
        ]
    }
}

\n

웹팩 개발 서버가 실행되면 8888 포트로 웹 페이지가 하나 열리는데, 트리맵 형태로 js 파일들이 보여지며, 파일 용량이 클수록 트리 노드가 넓어진다.

\n

$\"Example$

\n

(9) 프로젝트 다운로드

\n

본문에서 다룬 내용은 모두 GitHub 저장소에 올려놨으니 바로 테스트 해볼 수 있다. 다음 강좌를 위해서 계속 업데이트할 프로젝트이니 Watch나 Star를 누르면 최신 상태를 업데이트 받을 수 있을 것이다. ㅎㅎ

\n

\n
https://github.com/seogi1004/webpack-springboot-starter
\n

", "url": "https://alvin.ing/blog/webpack-springboot-starter", "title": "Webpack+SpringBoot 기반의 프론트엔드 개발환경 구축하기", "summary": "필자가 회사에서 개발 중인 제니퍼5의 수요가 크게 늘어남에 따라 고객의 기호에 맞게 화면에 대한 커스터마이징을 요구하는 경우가 많아졌다. 하지만 기존의 프로젝트에 커스터마이징 코드를 넣는 것은 바람직하지 않기 때문에 외부에서 구현하고, 플러그인처럼 추가하고 삭제할 수 있는 구조를 고민해야만 했다.", "date_modified": "2017-08-17T00:00:00.000Z", "author": { "name": "Alvin Hong", "url": "/about" }, "tags": [ "개발", "Webpack", "Spring Boot" ] } ] }