Team Spacewalk

스페이스워크는 AI 기반 건축 설계 기술을 활용하여 정보 불균형을 해소하고 인류의 유한한 자원인 토지의 활용을 극대화합니다. 우리는 사람들이 정보에 기반한 결정과 합리적인 판단을 내릴 수 있도록 지원하며, 건축 설계의 혁신을 주도하고 부동산 개발의 미래를 변화시킵니다.

AI 기술을 통해 전문적인 지식과 지원에서 소외되었던 수많은 소규모 부동산에 최적의 솔루션을 제공하여 향상된 가치를 창출합니다. 건축 데이터의 민주화를 통해 모든 부동산 소유자가 자신의 토지가 가진 잠재력을 실현할 수 있도록 합니다.

토지 개발 초보자부터 전문가, 주요 공공기관의 부동산 정책에 이르기까지, 스페이스워크의 기술은 모든 사람이 더 나은 토지 가치를 창출할 수 있도록 계속해서 진화하고 있습니다.









SaaS Products

Software as a Service를 기반으로, 우리는 를 개발 및 제공하여 토지 활용 방식을 혁신하고, 건축 인사이트를 모두가 접근할 수 있도록 만듭니다.

우리는 부동산 소유자와 조직의 다양한 요구를 충족시키는 확장 가능하고 맞춤화된 솔루션을 만들어 미활용된 잠재력을 기회로 전환하는 데 집중하고 있습니다.









Recent Posts

미분가능한 환경을 찾아서

미분가능한 환경을 찾아서

Abstract 건축 알고리즘, 혹은 패러메트릭 디자인을 수행한다는 것은 파라미터에 따른 결과를 만들어내는 알고리즘이라 생각을 고정하기 쉽습니다. 하지만 ga 나 es 같은 heuristic optimizer 에서는 그 알고리즘 자체가 파라미터를 변경하고자 하는 환경으로, 더욱이 모델이 학습의 기준으로 사용하기 위한 환경으로 사용되며, 강화 학습이 될 경우, 환경은 모델의 방향성을 판단하는 기준 그 자체가 됩니다.

이 때, 환경은 어떤 특성을 지녀야 하는가에 대한 탐구의 일환으로, 미분가능한 환경의 의의를 찾고 결과를 테스트해봤습니다. gradient 단절이 확실한 환경과 그렇지 않은 환경 두 환경을 설정하고 실제로 미분 가능한 환경일 때 사용이 가능한 gradient descent 및 AdamW 방법을 포함해, ga 를 비교해 미분 가능한 환경의 의의를 확인할 수 있었습니다. Problem 건축 알고리즘 관련 환경을 작성한다 - 혹은 패러메트릭 디자인 환경을 작성한다 - 는 것은 직관적으로는 다음과 같은 형식을 가지고 있습니다. 원의 위치와 반지름을 파라미터로 원을 생성한다. loss 는 원의 넓이와 반지름 5인 경우의 원의 넓이(25)와의 차이의 10분의 1로 정의한다. 위처럼 로직이 단순할 떄는 파라미터와 결과 사이의 직관성이 크게 떨어지는 일은 많지 않을 것입니다. 그 때의 radius - loss 그래프와 같이 표현하면 다음과 같습니다. (x >= 0 인 경우) 하지만 알고리즘이 점점 복잡해질수록 이 환경은 블랙박스가 되어가고, 사용자는 물론 이를 개발한 사람 조차도 파라미터에 따른 결과의 경향성 조차 파악하기 어려워집니다. 이 때 문제가 발생합니다. 강화학습의 모델까지 생각할 것도 없이, ga와 같은 최적화 과정에서도 파라미터 변경에 따른 결과의 “측정”은 필요합니다. 하지만 파라미터의 차이가 환경에 미칠 영향의 랜덤성이 너무 커 파라미터 변경에 따른 결과 역시 지나치게 랜덤해집니다. 위의 그림은 파라미터 하나의 경우에만의 예시인데도 문제가 바로 보입니다. 하지만 건축 알고리즘 관련 엔진에서는 당연히 파라미터를 한두개 사용하는 것으로 끝낼 수 있는 경우는 존재하지 않습니다. 그러면 다음과 같은 경향을 확인할 수 있는 부드러운 곡면은 물론이고, 최적화 모듈은 경향성을 파악하는 것이 사실상 불가능에 가깝다는 것입니다. continuous 한 [parameter - loss] 없이 continuous 한 엔진은 없습니다. 따라서, 어떠한 환경의 기능 및 파라미터를 추가할 때, 그 파라미터와 파라미터에 대응하는 환경이 만드는 score (혹은 loss 의 음수) 가 미분 가능한 관계가 될 수 있도록 의식적으로 추가해보는 것으로 시작해보았습니다. Premises 패러메트릭 디자인 알고리즘을 포함해, 이 포스트에서 말하는 환경은 파라미터를 입력해 결과 geometry 관련 데이터 및 loss까지 계산할 수 있는 모듈을 의미한다. 미분 가능함 혹은 파라미터의 연결성을 명시적으로 보장하기 위해, starting parameter 에서 loss 계산까지의 모든 과정은 torch 의 tensor 연산으로만 이루어진다. Environment Details 1. 사용할 파라미터와 및 loss 등 환경 정의 파라미터 정의 - 총 16개 환경 1 - 4개의 사각형의 x, y position ratio (x_ratio, y_ratio) 는 각 사각형의 width 와 height 를 기준으로 하며, (x, y) 위치와 일대일 대응하는 것을 위함입니다. 환경 2 - 4개의 사각형의 interpolation, offset ratio offset은 해당하는 width 혹은 height 의 0. 5를 기준으로 작동해, (interpolation, offset ratio)는 이를 통해 생성한 (x, y) 위치와 일대일 대응하는 것을 위함입니다. 즉, gradient 단절이 확실히 존재합니다. Environment 2 의 4개 사분면 분리를 위한 0. 5 사용 - 공통 - 4개의 사각형의 x, y size ratio - position 이 정해진 후 남은 가능 거리 중에서 비율을 통해 x_size 와 y_size 를 결정합니다. - 즉, 두 환경 모두 동일한 2D 평면의 모든 점 (x, y) ∈ ℝ² 에 대해, 이를 생성할 수 있는 파라미터가 일대일 대응으로 존재해, 두 환경은 동일한 탐색 영역을 바라보고 있습니다. loss 정의 (각 loss 는 추가로 계수가 곱해져 최종 loss에 더해진다. ) L1: 각 사각형의 넓이의 분산 (각 사각형이 서로 비슷한 면적을 가지도록) $$ \displaystyle L1 = \frac{1}{n} \sum_{i=1}^{n} (Area(Rectangle_i) - \mu)^2 $$ L2: 각 사각형의 서로 겹치는 넓이의 합 (각 사각형이 서로 겹치지 않도록) $$ \displaystyle L2 = \sum_{i=1}^{n} \sum_{j=i+1}^{n} Area(Rectangle_i \cap Rectangle_j) $$ L3: 각 사각형의 aspect ratio (1. 5에서 벗어나는 정도) $$ \displaystyle L3 = \sum_{i=1}^{n} \left| \frac{\max(w_i, h_i)}{\min(w_i, h_i)} - 1. 5 \right| $$ L4: 각 사각형의 면적의 합 (면적이 커져야 한다. ) $$ \displaystyle L4 = \sum_{i=1}^{n} Area(Rectangle_i) $$ 원시적인 Gradient Descent 사용을 통한 미분 가능 정도 확인 # 학습 모델의 가중치를 변경하는 optimizer 가 아니라, # 결과 생성에 사용하고자 하는 parameter 를 직접 update하는 differentialbe programming 입니다. optimizer = torch. optim. SGD([parameters], lr=learning_rate) parameter 는 0 ~ 1 범위를 사용하도록 sigmoid 가 사용되었습니다. back propagation 된 grad 를 parameter 에 단순 반영하는 방법으로, 양쪽의 환경에서 간단하게 테스트해보았습니다. 환경 1이 더 상대적으로 더 일관적인 경향성을 보이고, 최종 loss 값도 더 작으며, 실제 도형 배치 역시 의도에 가까운 결과를 보여주었습니다. (다만, Loss 는 현재 완전하다기보다 테스트의 경향을 파악하기 위함으로, 실제 도형 배치 이미지 자체보다 Loss 숫자 자체에 더 중점을 두겠습니다. ) 즉, 두 환경 모두 바라보고 있는 탐색 영역은 동일하지만 환경 1이 더 미분가능한 환경에 가깝다고 볼 수 있습니다. - 환경 1 Loss 1 Loss 2 Loss 3 Loss 4 - 환경 2 Loss 1 Loss 2 Loss 3 Loss 4 이제 이 두 환경을 이용해 ga 모듈 및 AdamW optimizer 를 이용한 최적화를 진행해보겠습니다. 1. AdamW Optimizer 를 이용한 최적화 Test results optimizer = torch. optim. AdamW([parameters], lr=learning_rate) - 환경 1 Loss 1 Loss 2 Loss 3 Loss 4 - 환경 2 Loss 1 Loss 2 Loss 3 Loss 4 2. Genetic Algorithm 를 이용한 최적화 Test results ga 에서는 최종적인 결과는 유사하게 나오고 있습니다. 충분한 양의 연산이 주어지면, 탐색 영역 자체는 동일하기 때문에 거의 동일한 점수로 수렴하는 것을 확인할 수 있습니다. 하지만 연산을 매번 충분히 주어지는 것은 불가능 하는 경우가 많습니다. 최대한 답을 향해 빨리 나아가는 것 역시 중요합니다. 환경 1이 확실히 초기 안정성이 더 좋은 것 역시 확인이 가능합니다. 두 환경의 초기 그래프 차이 더욱이 ga 에서는 generation 당 100개의 Population 을 사용했습니다. 즉, 200 번의 연산만 수행했던 위 두 케이스와 다르게 20000번의 연산을 수행한 결과입니다. ga 를 사용하는 것이 최종적인 성능을 보장하는 방법 중에 하나일 수는 있지만, 적어도 이 셋중에는 효율적인 방식이라 보기 어렵습니다. (단 2 generation 만에 200번의 연산) - 환경 1 Loss 1 Loss 2 Loss 3 Loss 4 - 환경 2 Loss 1 Loss 2 Loss 3 Loss 4 Conclusion 미분 가능한 환경, 즉 파라미터의 변화에 따른 환경이나 결과의 변화가 연속적일 수록 최적화 과정에서 더 좋은 결과를 얻을 수 있음을 확인할 수 있었습니다. 이는 단순한 경사하강이나 AdamW 뿐만 아니라, 심지어 ga 와 같은 최적화 알고리즘에서도 같은 경향을 보였습니다. 모든 파라미터에 적용하는 것이 불가능할 때도 있지만, 이를 의식해 개발할 때 추가하고자 하는 파라미터에 가능하다면 최대한 환경이 미분 가능한 형태로 추가하는 것이 의미가 있음을 재확인할 수 있었습니다. 비슷한 점수를 얻기 위해 ga 에서는 훨씬 많은 수의 실행 횟수가 필요했습니다. ga 보다 효율적인 방법이 더 많을 수 있다는 것을 시사합니다. 미분 가능한 환경과 방법 혹은 또 다른 방법으로 전체 연산 횟수 또한 줄일 수 있을 것으로 기대합니다. Let’s Use Differentiable Environment! . .


Quantifying Architectural Design

Quantifying Architectural Design

1.

Measurement: Why It Matters 공간이나 건축에서 ‘측정하고 계산한다’는 말은 단순히 도면 위에 치수를 적어두는 수준을 넘어선다. 예를 들어, 건축가는 건물 벽의 두께나 층고를 재는 일뿐 아니라, 사람들이 그 공간에서 얼마나 오래 머무는지, 어떤 방향으로 주로 이동하는지까지도 살핀다. 결국 측정이라는 과정은, 디자인 문제를 종합적으로 이해하기 위한 중요한 단서가 된다. 물론 디자인의 모든 것을 숫자로만 파악할 수 있는 것은 아니다. 하지만 제임스 빈센트가 강조했듯이, 측정이라는 행위 자체가 우리가 놓치던 세부를 더 깊이 들여다보게 만든다. 예컨대 “도시가 커질수록 혁신성이 올라간다”는 말이, 정량적 통계로 확인될 때 그 의미가 더욱 명확해진다는 뜻이다. 다시 말해, 디자인에서의 측정이란 감에 의존하던 의사 결정을 좀 더 분명한 근거 위에 올려놓는 데 기여한다. 2. The History of Measurement Leonardo da Vinci’s Vitruvian Man 옛 시절을 떠올려 보자. 고대 이집트에서는 팔꿈치 끝부터 손가락 끝까지의 길이를 기준으로 건물을 지었고, 중국은 ‘척’이라는 단위를 도입해 만리장성 같은 대규모 공사를 보다 정확히 진행할 수 있었다. 르네상스 시대로 건너가면, 레오나르도 다빈치의 비트루비안 인간을 통해 예술과 수학의 결합이 두드러졌고, 갈릴레오 갈릴레이가 “측정할 수 없는 것은 측정 가능하게 하라”고 말했던 일화에서 보듯, 자연 현상을 수치로 정밀하게 규정하는 시도가 자리 잡았다. 그리고 지금의 디지털 시대에 이르면, 나노미터 단위의 계측이 가능해지고, 컴퓨터와 AI 기술이 방대한 데이터를 순식간에 분석해 준다. 옛 시절 예술가들이 감에 의존해 섬세한 작업을 했다면, 이제는 3D 프린터로 1mm 오차도 없는 구조물을 만드는 시대가 됐다. 도시나 건축에서 측정과 계산이 얼마나 중요한지를 보여주는 예라고 할 수 있다. 3. The Meaning of Measurement 영국 물리학자인 윌리엄 톰슨(케빈 경)은 “무언가를 숫자로 표현할 수 있다면, 어느 정도 이해했다는 의미이고, 그렇지 못하면 아직 미흡한 것”이라고 지적했다. 이런 맥락에서 보면, 측정은 곧 이해의 폭과 깊이를 넓혀주는 도구이자, 우리가 얻은 지식에 신뢰도를 부여하는 근거가 된다. 건축만 보더라도, 구조적 안전을 위해 하중을 계산하고, 재료 물성을 파악하는 일이 우선시된다. 에너지 절감을 목표로 일조량을 예측하거나 소음을 수치화하는 등의 과정은 설계 단계에서 최적의 해법을 찾는 데 도움이 된다. 도시에 관한 연구에서도, 물리학자 제프리 웨스트가 저서 스케일에서 지적했듯이, 인구가 늘어남에 따라 특허나 혁신이 증가하는 비율이 단순한 추세가 아니라 실제 통계로 확인될 때, 도시 디자인은 더 뚜렷한 방향성을 갖게 된다. 하지만 무엇을 측정하고 어떤 지표를 믿느냐에 따라 결과 해석이 크게 달라진다. 맥나마라의 오류처럼, 엉뚱한 지표를 맹신하면 본래 달성해야 할 목표가 흐려지게 된다. 특히 도시나 건축은 인간의 삶과 맞닿아 있는 영역인 만큼, 숫자로 환원하기 어려운 가치—이를테면 공간이 주는 정서적 만족감이나 장소성—도 다뤄야 한다. 바츠라프 스밀이 “숫자가 실제로 말해주는 바를 알아야 한다”고 경고한 것도 같은 이유다. 숫자만 보지 말고, 그 뒤에 깔린 맥락을 함께 들여다보라는 의미다. 4. The “Unmeasurable” 디자인에서 수치화하기 어려운 부분의 대표적인 예로는 미적 감각이 있다. 아름다움, 분위기, 사용자 만족, 사회적 연결감 등은 한계가 뚜렷하다. 다만, Birkhoff의 미적 척도미적 값 M = 질서도(O) / 복잡도(C)처럼 질서와 복잡도의 비율을 통해 시도해보려는 연구가 있기는 하다. 또, 설문 조사나 피드백 데이터를 토대로 만족도를 수치화하려는 방법도 나오지만, 여전히 질적 맥락과 현장 경험은 온전히 숫자로 담기 힘들다. Informational Aesthetics Measures 디자인 칼럼니스트 질리언 테드가 “숫자에만 의존하면 정작 주변 맥락을 놓칠 수 있다”는 경고를 남긴 것도 같은 맥락이다. 결국 ‘숫자와 인간’을 잇는 통찰이 필요하다는 뜻이다. 한편, 건축이론가 K. Michael Hays는 고대 피타고라스·플라톤 철학의 비례 개념에서 비롯된 건축이 이후 디지털·알고리즘 설계까지 이어져 왔음을 지적하면서도, 건축적 경험을 완전히 수치로 표현하는 것은 불가능하다고 본다. 면적이나 비용 등은 환산되더라도, “왜 이 공간이 이렇게 배치돼야 하느냐”에 대한 답은 단순 숫자만으로는 충분치 않다는 것이다. 결국 디자이너가 숫자와 함께 ‘숫자로 묘사되지 않는 요소’를 고민해야 비로소 의미 있는 공간이 나온다. 5. Algorithmic Methods to Measure, Analyze, and Compute Space 최근에는 건축·도시 설계에 그래프 이론과 시뮬레이션, 최적화 기법을 접목해 공간 분석을 정교화하는 사례가 증가했다. 예컨대 건축 평면을 노드와 엣지로 구성해 방과 방 사이의 깊이나 접근성을 계산하거나, 유전 알고리즘으로 병원 평면이나 사무실 배치를 자동화하려는 시도도 있다. 또, 도시 차원의 교통 흐름이나 보행자 동선을 시뮬레이션해 최적 해법을 찾는 연구가 활발하다. 이처럼 알고리즘과 계산을 통해 공간 성능을 수치화하면, 디자이너는 그 수치를 바탕으로 더 합리적이고 창의적인 결정을 내릴 수 있다. Spatial Networks 건축 평면이나 도시 거리망을 노드와 엣지로 표현하여, 각 공간(또는 교차로) 간의 연결성을 평가한다. 예를 들어, 방과 방을 연결하는 문을 엣지로 삼으면 방들의 접근성을 최단경로 알고리즘(Dijkstra, A* 등)으로 계산할 수 있다. Spatial networks Justified Permeability Graph (JPG) 건축물 내부 공간의 깊이(depth)를 측정할 때, 주 출입구 등 특정 공간을 루트로 하여 층위적으로 배치한 정당화 그래프를 만든다. 루트로부터 얼마나 많은 단계를 거쳐야 도달하는지(=방의 깊이)를 보면 개방적·중심적 공간과 고립된 공간을 파악할 수 있다. Justified Permeability Graph (JPG) Visibility Graph Analysis (VGA) 공간을 촘촘히 분할하고, 서로 가시한 점들끼리 연결하여 시야적 연결망을 만든다. 이를 통해 어디가 가장 시야적으로 개방된 지점인지, 사람들이 많이 머무를 가능성이 높은 구역은 어디인지 예측 가능하다. Axial Line Analysis 실내나 도시를 사람이 실제로 이동할 수 있는 가장 긴 직선(축선)들로 나눈 뒤, 축선끼리 만나는 교차점을 엣지로 연결한 그래프를 만든다. 이때 통합도(Integration), 평균 심도(Mean Depth) 등의 지표를 산출해, 동선의 중심성이나 사적 공간 여부를 추정할 수 있다. Genetic Algorithm (GA) 건축 평면 배치나 도시 용도 배분 등에서, 여러 요구조건(면적, 인접성, 일조 등)을 적합도 함수로 설정하여 무작위 해를 진화시키는 방식이다. 세대를 거듭하며 최적 평면 혹은 배치안에 가까워진다. Reinforcement Learning (RL) 보행자나 차량을 에이전트로 삼고, 원하는 목표(빠른 이동, 충돌 최소화 등)에 대한 보상 함수를 두어 스스로 최적 경로를 학습하게 한다. 대형 건물이나 도시 교차로에서 군중 흐름이나 교통 흐름을 시뮬레이션하는 데 유용하다. 6. Using LLM Multimodality for Quantification 인공지능이 발전하면서, LLM(대형 언어 모델)이 건축 도면이나 디자인 이미지를 분석해 정성적 요소까지 어느 정도 수치화하려는 노력도 보인다. 예컨대 건축 디자인 이미지를 입력하고, 텍스트로 된 요구사항을 대조한 뒤 ‘디자인 적합성’을 점수로 제시하는 식이다. 건축 도면끼리 비교해 건축법 준수 여부나 창문 활용 비율을 자동으로 파악해주는 프로그램도 시범 운영되고 있다. 이 과정을 통해 동선 길이, 채광 면적, 시설 접근성 등을 정리한 후, 디자이너가 “이 디자인이 제일 적절해 보인다”는 판단을 내릴 수 있게 도와주는 것이다. 7. A Real-World Example: Automating Office Layout Automating Office Layout 사무실 평면 설계를 자동화하는 과정은 크게 세 단계로 나눌 수 있다. 먼저, LLM(Large Language Model)이 사용자 요구사항을 분석하고, 이를 컴퓨터가 이해할 수 있는 형식으로 바꿔준다. 다음으로, 파라메트릭 모델과 최적화 알고리즘이 수십·수백 가지 평면 시안을 만들어 각종 지표(접근성·에너지 효율·동선 길이 등)로 평가한다. 마지막으로, LLM이 그 결과를 자연어로 요약·해석해 제안한다. 이때 LLM은 GPT-4 등과 같이 대규모 텍스트 데이터로 학습된 모델을 뜻하며, 사용자의 “50인 규모 사무실에 회의실 2개, 로비 조망은 충분해야 함” 같은 지시를 받아 건축 알고리즘 툴이 이해할 수 있는 스크립트를 자동 생성하거나, 코드 수정 방안을 안내하기도 한다. Zoning diagram for office layout by architect 이 과정을 예로 들어 보자. 과거였다면, 건축가는 일일이 버블 다이어그램을 그리며 “부서를 어디에 둘지, 창문은 누가 우선 사용하게 할지”를 반복적으로 조정했다. 하지만 LLM으로 “로비에 조망을 최대한 확보하고, 협업이 잦은 부서는 서로 5m 이내로 붙여달라”라는 식의 요구사항을 파라메트릭 모델로 직결할 수 있다. 파라메트릭 모델은 기둥이나 벽, 창문 위치 같은 기본 정보를 토대로 rectangle decomposition, bin-packing 알고리즘 등을 활용해 다양한 평면 설계안을 만들어 낸다. 그 안들이 각종 지표(인접성, 협업 부서 간 거리, 창문 활용 비율 등)로 자동 평가되면, 최적화 알고리즘은 점수가 높은 상위안을 추려낸다. LLM-based office layout generation 이때 사람이 일일이 숫자 지표를 들여다보려 하면, ‘협업 부서 간 거리 평균 5m vs. 목표치 3~4m’ 같은 상세 데이터가 쏟아져 복잡해지기 쉽다. 여기서 LLM이 다시 등장한다. 최적화 결과를 받아 “이 설계안은 협업 공간 비율이 25%를 잘 충족하지만, 창문 활용도가 예정보다 높으니 에너지 효율이 조금 떨어질 수 있다” 같은 식으로, 전문가가 아닌 이도 이해하기 쉬운 문장으로 요약해준다. 예컨대 아래와 같이 브리핑할 수도 있다. “협업이 중요한 부서 간 거리는 평균 5m로, 사용자가 희망했던 3~4m 범위보다 다소 큰 편입니다. ” “에너지 사용량은 이 규모 표준 사무실 대비 10% 가량 낮게 추정됩니다. ” 만약 새로운 자료가 추가되면 LLM이 RAG(Retrieval Augmented Generation)을 이용해 문서를 재확인하고, 파라메트릭 모델에 “긴급 비상계단을 추가해야 한다”거나 “방음 성능을 더 강화해야 한다” 같은 추가 제약을 반영하라고 지시할 수도 있다. 이렇게 사람과 AI가 끊임없이 상호작용하면서, 설계자는 훨씬 짧은 시간에 다양한 대안을 탐색하고, ‘데이터에 근거한 직관’을 살려 최종 결정을 내릴 수 있게 된다. results of office layout generation 본질적으로, 측정이란 “공간을 어떻게 바라볼지”를 결정하는 도구다. 오피스라는 한정된 공간에서, 누가 어떤 우선순위를 갖고 그 공간을 점유할지를 정하는 일은 복잡한 문제이지만, LLM과 파라메트릭 모델, 최적화 알고리즘이 결합하면 그 복잡성이 한결 가벼워진다. 최종적으로 디자이너나 의사결정자가 가지는 자유도는 줄어드는 게 아니라, 오히려 “잡다한 반복 업무”에서 벗어나 프로젝트 전반의 창의적·감성적 부분에 더 집중할 수 있게 된다. 이것이 바로, ‘측정과 계산’을 바탕으로 한 사무실 레이아웃 추천 시스템이 가져다주는 효과다. 8. Conclusion 결국 측정은 “보이지 않던 것을 드러내는” 강력한 도구다. 정확한 숫자를 통해 문제를 분명히 인식하면, 직관과 감각에만 의존할 때보다 더 객관적으로 해법을 찾을 수 있다. 인공지능 시대에는 LLM과 알고리즘이 이런 측정·계산 과정을 한층 확장해, 평소 수치화하기 어려웠던 영역을 어느 정도 정량화할 수 있게 되었다. 오피스 배치 자동화 사례에서 보듯, 추상적 요구조차 LLM 덕분에 정량 파라미터가 되고, 파라메트릭 모델과 최적화 알고리즘이 수많은 대안을 생성·평가해 합리적이면서도 창의적인 결과를 제안한다. . .


AI and Architectural Design: Present and Future

AI and Architectural Design: Present and Future

Introduction 인공지능은 반복 업무부터 창의적 해결까지 폭넓게 적용되고 있다. 건축 분야도 예외가 아니다. 한때 CAD로 도면을 그리는 정도였던 전산화가, 이제 생성적 디자인과 최적화 알고리즘을 통해 건축가·엔지니어 업무 전반을 바꾸고 있다.

이 글은 인공지능이 건축 설계에 어떻게 혁신을 가져오는지, 그리고 전문가들이 어떤 기회와 과제에 직면하는지 살펴보려 한다. Background of AI in Architectural Design Rule-Based Approaches and Shape Grammar 처음에는 사람이 만든 규칙에 따라 설계안을 자동 생성하는 연구가 있었다. 형태 문법(Shape Grammar)은 1970년대 이후 발전해, 적은 규칙으로도 특정 건축가의 양식을 재현할 수 있음을 보여줬다. 예를 들어 르네상스 건축가 팔라디오의 빌라 평면을 간단한 기하학 규칙으로 구현한 사례가 있다. 다만 사람이 정의한 범위 안에서만 작동하기 때문에 복잡한 건축 문제 모두를 해결하기는 어려웠다. Koning's and Eisenberg's compositional forms for Wright's prairie-style houses. Genetic Algorithms and Deep Reinforcement Learning 자연계 진화를 모델링한 유전 알고리즘은 무작위 해답을 평가하고, 우수 해법을 교배·돌연변이해 점진적으로 개선한다. 복잡한 문제를 탐색하는 데 유리하지만, 변수가 많으면 계산 시간이 길어진다. 심층 강화 학습은 바둑 AI 알파고로 유명해진 기법이다. 시행착오로부터 보상을 최대화하는 정책을 스스로 학습한다. 건축 설계에서도 대지 형상, 법규, 형태 등 맥락 정보를 바탕으로 의사결정 규칙을 만들어갈 수 있다. Generative Design and the Design Process Automating Repetitive Tasks and Proposing Alternatives 생성적 디자인은 반복 업무를 자동화하고, 다양한 설계 대안을 동시에 만들어낸다. 기존에는 시간이 부족해 몇 가지 아이디어만 검토했지만, 인공지능을 쓰면 수십~수백 가지 안을 실험할 수 있다. 일조량·공사비·편의성. 용적률 등 여러 요소를 복합 평가하는 것도 가능하다. The Changing Role of the Architect 건축가는 인공지능 설계를 위한 목표·제약 조건을 정하고, 그 결과물을 큐레이션한다. 단순 도면이나 계산 업무에서 벗어나, 어떻게 AI가 작동할지 환경을 세팅하고, 상위안을 골라 미학적 감각을 더하는 쪽에 집중하게 된다. The Role of Architects in the AI Era 1966년 영국 건축가 세드릭 프라이스가 던진 말이 있다. “Technology is the answer… but what was the question?” 이 말은 오늘날 더 중요한 화두가 되었다. 문제를 ‘어떻게 풀까’보다는 ‘어떤 문제를 풀지’가 핵심이라는 뜻이다. 디자인 프로세스에는 문제 정의 단계와 해결 단계가 있는데, 인공지능 발전으로 해결 단계는 많이 주목받았다. 그러나 건축 설계에서 중요한 일은 무엇을 문제로 삼을지, 그 문제를 어떻게 정의할지에 달려 있다. Defining the Problem and Constructing a State Space 도메인 지식과 컴퓨터적 사고를 모두 이해하는 사람이 문제를 잘 정의한다. 문제 설정이 적확하면 복잡한 AI 없이도 간단한 알고리즘으로도 충분한 결과를 낼 수 있다. 여기서 건축가는 하나의 독창적 결과물을 직접 만들기보다, 요소 간 상호작용을 설계해 상태공간을 구성하는 역할을 한다. 반면 인공지능은 이미 존재하는 무수한 가능성 중 최적의 조합을 발견한다. Palladio’s Villas and Shape Grammar 이런 관점을 뒷받침하는 대표적 사례로, 루돌프 비트코버(Rudolf Wittkower)가 르네상스 건축가 안드레아 팔라디오(Palladio)의 빌라 평면에서 찾아낸 규칙과 패턴을 들 수 있다. 비트코버는 팔라디오 빌라에 일관되게 나타나는 기하학적 원리를 분석했는데, 그중 두드러진 것이 “나인 스퀘어 그리드(nine square grid)”로 대표되는 기본 틀이었다. 팔라디오의 빌라는 겉보기에는 모두 독창적이지만, 중앙에 홀을 두고 좌우대칭으로 방을 배치하고, 방의 가로세로 비율을 3:4나 2:3 같은 음악적 음정비로 맞추는 등 특정 규칙을 공유했다. 팔라디오가 자주 썼던 방의 비례나 치수 목록은 모두 다분히 의도적이었고, 이를 통해 건축가가 조화로운 형태를 체계적으로 구현했음을 알 수 있다. Landbook and LBDeveloper 스페이스워크(Spacewalk)는 인공지능 기반 건축 설계 기술을 개발하고 있다. 2018년 공개된 랜드북은 AI 부동산 개발 플랫폼이다. 지번만 입력하면 해당 토지의 시세, 법적 개발 한계, 개발 후 예상 수익률을 바로 보여준다. LBDeveloper는 가로주택정비사업용 전문 솔루션이다. 노후 주택지의 개발 요건 검토와 사업성 분석을 자동화한다. 주소 입력만으로 개발 가능 여부와 기대 수익을 확인할 수 있다. AI-Based Design Workflow LBDeveloper는 법규로부터 허용 영역을 계산하고, 평수 조합을 바탕으로 건물 블록을 생성한다. 그리드와 축을 다양하게 적용해 블록을 배치한 다음, 블록 사이 간격을 최적화해 충돌을 피한다. 마지막으로 건물 바닥 면적 비율(BCR)과 용적률(FAR) 같은 지표로 배치 효율을 평가해 최적안을 고른다. 전체 조합 수는 (축 옵션 수) × (그리드 옵션 수) × (층수 옵션 수) × (열 shift 옵션 수 × 행 shift 옵션 수) × (회전 옵션 수) × (추가 블록 옵션 수) 로 계산한다. 예를 들어, 4 × 100 × 31 × (10×10) × 37 × (추가 옵션은 활성 블록 개수에 따라 다름) 정도로 평가할 수 있다. 실제로는 각 단계에서 전수 조사하여 최적의 값을 선택하는 방식이므로, 모든 조합을 동시에 탐색하지 않고 각 요소별로 최적화를 진행한다. Future Prospects 디자인에는 무수히 많은 대안이 있다. 여러 제약으로 인해 완벽한 최적 해를 찾기 어렵다. 최적화 알고리즘도 탐색 범위나 규정 한계로 인해 늘 만족스러운 결과를 보장하지 못한다. 이 한계를 보완하는 도구가 LLM이다. LLM은 방대한 데이터를 학습해 새로운 아이디어를 제안하고, 수많은 대안 중 좋은 해답을 골라준다. 복잡한 규칙이 얽힌 건축 분야에서는 더 효과적이다. LLMs for Design Evaluation and Decision LLM은 미리 생성된 설계안을 다각도로 평가하고, 사용자 요구사항이나 법규에 맞춰 어느 정도로 합리적인지를 판단한다. 단순한 법적 준수 여부뿐 아니라, 건물 배치나 조형 요소가 미적으로 균형 잡혀 있는지, 공간적 편의성이 충족되는지도 같이 살핀다. 설계 후보가 많을수록 이런 지원이 중요해진다. 디자이너는 그동안 무수히 많은 안을 직접 검토해야 했지만, LLM의 조언을 통해 빠르게 적합한 안을 좁혀갈 수 있다. 무엇보다 LLM은 “텍스트” 형태의 질의를 기반으로 작동하기 때문에, 특정 평가 기준이나 미적 감각을 언어로 풀어내기만 하면 된다. 예를 들어 “인접 대지의 건물 사이에 충분한 간격이 있는지 확인해줘” 같은 문장을 넣으면, LLM은 해당 조건을 재차 분석하고 결과를 요약한다. 이 과정에서 LLM은 공간적 아이디어와 기능적 요구 사항을 동시에 고려한다. 설계자가 제시한 목표치와 실제 배치 간 격차를 파악하고, 필요한 개선 방향을 추천해주기도 한다. 결국 LLM은 디자이너가 더 깊이 있는 고민을 할 수 있도록 돕는다. 건축가는 무수한 설계안 중 어느 것이 “실제 실행 가능한지, 또 법·규정상 허점이 없는지, 미적·기능적 균형이 적절한지”를 빠르게 확인하며, 창의적인 과정에 에너지를 쏟게 된다. 이는 사람이 놓칠 수 있는 사소한 실수를 줄이고, 아이디어를 폭넓게 탐색하도록 독려한다. 이렇게 인간 전문가와 LLM이 협력해 설계안을 평가하고 선택하는 방식은 앞으로 점차 확산될 것으로 본다. . .


Rendering Multiple Geometries

Rendering Multiple Geometries

Introduction 이 글에서는 여러 개의 geometry 를 렌더링하고자 할 때 최적화 및 렌더링 부하를 줄이는 방법을 소개하고자 합니다. Abstract 1. three js 에서 도형에 해당하는 객체를 만드는 가장 기본적인 방법은 mesh 에 해당하는 geometry 와 material 을 통해 하나의 mesh 를 생성하는 것입니다.

2. 이때 지나친 drawcall 의 개수 때문에 너무 느려서, geometry 들을 material 단위로 merge 해 mesh 개수를 줄이는 과정을 통해 1차 최적화 시도를 행했습니다. 3. 추가적으로, 기준 geometry에서 move or rotate 및 scale 등의 변환을 통해 생성 가능한 geometry 는 group 이 아닌 instancedMesh 를 통해 메모리 사용량 개선과 geometry 생성시의 부하 감소를 시도했습니다. 1. Basic Mesh Creation 먼저 아파트 하나를 렌더링한다고 가정해보겠습니다. 아파트를 형성하는 도형에는 많은 종류가 있지만, 여기서는 덩어리 블록을 예시로 들어보겠습니다. 아래처럼 하나의 블록을 렌더링하는 경우, 큰 고민이 필요하지 않습니다. . . . const [geometry, material] = [new THREE. BoxGeometry(20, 10, 3), new THREE. MeshBasicMaterial({ color: 0x808080, transparent: true, opacity: 0. 2 })]; const cube = new THREE. Mesh(geometry, material); scene. add(cube); . . . Draw Calls: 0 Mesh Creation Time: 0 하지만 아파트 전체를 렌더링하고자 할 때, 창문과 벽 등 한 세대의 geometry 는 100개가 넘는 경우가 적지 않고, 이는 즉 100세대를 렌더하고자 할 경우 geometry 의 개수는 다섯자리 수를 쉽게 넘을 수 있다는 의미입니다. 이 때 각 geometry 하나 당 mesh 한개를 생성해 렌더링하는 경우입니다. 아래는 10,000개의 도형을 렌더링한 결과입니다. 각 geometry는 베이스 도형을 clone 및 translate 하여 생성했습니다. // 아래의 코드가 5,000번 실행됩니다. scene 에 add되는 mesh 의 개수는 10,000개입니다. . . . const geometry_1 = base_geometry_1. clone(). translate(i * x_interval, j * y_interval, k * z_interval); const geometry_2 = base_geometry_2. clone(). translate(i * x_interval, j * y_interval, k * z_interval + 3); const cube_1 = new THREE. Mesh(geometry_1, material_1) ; const cube_2 = new THREE. Mesh(geometry_2, material_2); scene. add(cube_1); scene. add(cube_2); . . . Draw Calls: 0 Mesh Creation Time: 0 2. Merge Geometries 이제 렌더링 최적화를 위해 대표적으로 사용되는 방법 중 하나인 mesh 개수 감소 방법을 말씀드리겠습니다. 그래픽스 쪽에는 drawcall 이라는 개념이 있다고 합니다. CPU는 장면에서 렌더링해야 할 도형을 찾아내고, 이를 GPU에 렌더링하도록 요청하는데, 이 요청 횟수를 draw call이라고 합니다. 이 때의 기준은 기본적으로 렌더링해야하는 서로다른 material 을 가진 서로 다른 mesh 의 렌더링을 요청하는 횟수로 이해할 수 있습니다. 여기서 다중 작업에 특화되어 있지 않은 CPU가 지속적으로 동시에 많은 호출을 처리해야 하면서 병목 현상이 발생할 수 있습니다. 이미지 출처: https://joong-sunny. github. io/graphics/graphics/#%EF%B8%8Fdrawcall 마우스로 scene 을 조작해보시면서 이 케이스와 직전 케이스의 drawcall의 차이를 확인해보실 수 있습니다. 위의 케이스에서는 설정되어있는 카메라의 max distance나 화면 밖으로 도형이 나가는 경우 등의 이유로 항상 10,000번이 call 되지는 않지만 대부분의 경우 상당한 양의 call 이 발생하는 것을 확인할 수 있습니다. 여기에서는 material 을 두개 사용했기 때문에, 서로 다른 material 을 가진 geometry 들을 merge 하는 방법을 사용했습니다. 따라서 확인하실 수 있는 것 처럼 여기에서의 draw call 은 최대 2로 고정되는 것을 확인하실 수 있습니다. // 아래의 코드가 1번 실행됩니다. scene 에 add되는 mesh 의 개수는 2개입니다. . . . const mesh_1 = new THREE. Mesh(BufferGeometryUtils. mergeBufferGeometries(all_geometries_1), material); const mesh_2 = new THREE. Mesh(BufferGeometryUtils. mergeBufferGeometries(all_geometries_2), material_2); scene. add(mesh_1); scene. add(mesh_2); . . . Draw Calls: 0 Mesh Creation Time: 0 렌더링 부하가 개선되었음을 직접적으로 확인할 수 있습니다. 3. InstancedMesh 위에서 geometry 들을 merge 하는 것으로 draw call 관점에서의 부하를 감소시킬 수 있는 방법을 확인했습니다. 이 도형들은 clone 및 translate 만 사용된 도형들로 이루여져 있어 모태가되는 형태가 동일합니다. 이는 건물이나 나무와 같은 객체를 렌더링 할 떄에도 유사한 경우가 발생합니다. 층별로 형태가 다를 필요가 없다거나, 파츠들을 복사해 층의 벽들로 이루는 등의 경우, 나무 종류를 많이 사용하지 않고 하나의 나무를 크기나 방향만 바꿔 사용하는 경우 등 입니다. 같은 형태의 평면이 여러개의 동으로 생성된 경우 또한 물론 적용 가능합니다. 이 경우에는 geometry 객체 생성 횟수도 줄일 수 있고 메모리 및 시간에 효율적인 instancedMesh 를 사용하여 추가적으로 최적화를 시도할 수 있습니다. 그래픽스에 Instancing 이라는 개념이 있습니다. Instancing은 유사한 geometry를 여러 번 렌더링할 때, 데이터를 한 번만 GPU로 보내고 각 인스턴스의 변환 정보를 GPU에 추가적으로 전달하는 것으로 geometry 생성 또한 한번만 하면 되는 장점이 있습니다. Unity와 같은 게임 엔진에서도 이 개념을 활용하여 GPU instancing 이라는 기능을 통해 성능 최적화를 이루고 있습니다. 유사한 형태의 도형을 여러개 렌더링하는 경우 (유니티 GPU Instancing) 이미지 출처: https://unity3d. college/2017/04/25/unity-gpu-instancing/ three js 에도 이에 해당하는 InstancedMesh라는 기능이 있습니다. draw call은 위에서 말씀드린 geomtries merge 케이스와 동일하지만, 모든 geometry 를 각각 생성해야 할 필요가 없기에 메모리 및 렌더링 시간 면에서 큰 이점이 있습니다. 아래의 다이어그램은 1, 2, 3번 과정에서 gpu 에 전달되는 mesh 를 간략화 한 그림입니다. 아래의 예시는 translation 만 사용되었지만, 이 외에도 rotate, scale 등의 변환 역시 사용할 수 있습니다. mesh 를 따로 생성하는 것을 줄였던 것에 더해 geometry 까지 따로 생성하는 것을 줄이며, creation time 차이가 상당한 것을 확인할 수 있습니다. // instancedMesh 의 마지막 arguement에는 사용할 도형의 개수를 추가해줘야 합니다. const mesh_1 = new THREE. InstancedMesh(base_geometry_1, material_1, x_range * y_range * z_range); const mesh_2 = new THREE. InstancedMesh(base_geometry_2, material_2, x_range * y_range * z_range); let current_total_index = 0; for (let i = 0; i Draw Calls: 0 Mesh Creation Time: 0 물론 translate(이동), rotate(회전), scale(크기변환) 변환만으로는 모든 경우의 수를 커버할 수 없기에, 그럴 경우 merged geometry 방법도 혼용해야 하는 경우가 많고, 적용하고 있습니다. 마치며 three js 렌더링을 최적화하는 데는 이 밖에도 다양한 방법이 있지만, 이번 글에서는 우선 geometry 개수에 따른 렌더링 부담을 줄이는 방법에 대해 말씀드렸습니다. 이 밖에도 겪었던 메모리 누수나 다른 원인에서 있었던 부하 문제 등을 수정했던 경험을 추후 공유드리겠습니다. 감사합니다. . .


Zone Subdivision With LLM - Expanded Self Feedback Cycle

Zone Subdivision With LLM - Expanded Self Feedback Cycle

Introduction 이 글에서는 반복적인 사이클을 통해 결과의 품질을 향상시키기 위해 대규모 언어 모델(LLM)을 피드백 루프에서 활용하는 방법을 살펴봅니다. LLM이 제공하는 초기 직관적 결과를 개선하는 것이 목표이며, 이는 LLM 내부의 피드백 메커니즘을 넘어서 LLM 외부의 최적화를 포함한 피드백 사이클을 통해 이루어집니다.

Concept LLM은 자체적으로도 피드백을 통해 결과를 개선할 수 있으며, 이는 널리 활용되고 있습니다. 그러나 사용자의 단일 요청만으로 LLM이 제공하는 직관적인 결과가 항상 완전하다고 기대하기는 어렵습니다. 따라서, LLM이 제공한 초기 결과를 다시 요청하여 피드백을 주고받음으로써 답변의 질을 향상시키는 것을 목표로 합니다. 이는 LLM 내부의 피드백에만 의존하는 것을 넘어, LLM과 알고리즘을 포함한 더 큰 사이클에서의 피드백을 통해 결과를 지속적으로 개선할 수 있는지를 확인하는 과정입니다. Self-feedback outside LLM API In This Work: Self-feedback inside LLM API examples: LLM을 사용하는 의의 사용자의 모호한 니즈와 알고리즘의 구체적 기준 사이의 연결 매개체 사이클의 결과를 이해하고, 다음 사이클에 그 결과를 반영해 답변을 개선해가는 과정 Premises Two Main Components: LLM: 직관적 선택에 사용 사용자의 비교적 모호한 의사를 LLM 은 직관적이고 개략적인 결정들을 만들 수 있습니다. 사용자 - LLM - optimizer 순으로의 구체화 순서 과정에서, 사용자 - optimizer 사이의 갭을 매꿔주는 존재로 사용됩니다. Heuristic Optimizer (GA): - 상대적으로 구체적인 최적화에 사용 Use Cycles: 사이클의 실행을 반복함으로, 의도에 가까운 결과에 스스로 접근하고자 하는 구조를 만들고자 합니다. Details Parameter Conversion: LLM 과 structured out 을 사용하면, 직관적으로 선택할 내용들을 명확한 파라미터 입력으로 변환해 알고리즘 입력의 input 으로 사용할 수 있습니다. Zone grid 및 grid size 에 따른 각 patch 사이즈를 조절하기 위해, 추가적인 subdivision 개수를 얼마나 받아야 할지 재 요청하며 조정 number_additional_subdivision_x: int number_additional_subdivision_y: int 각 용도에 대해 boundary 에 가깝게 위치하는 것을 우선할지 prompt 를 바탕으로 답변을 요구합니다. place_rest_close_to_boundary: bool place_office_close_to_boundary: bool place_lobby_close_to_boundary: bool place_coworking_close_to_boundary: bool 각 용도가 서로 옆 patch 와 다른 용도이길 원하는 비율에 대해 물어봅니다. percentage_of_mixture: number 각 용도가 몇퍼센트 정도 차지해야 할 지 물어봅니다. office: number coworking: number lobby: number rest: number Optimization Based on LLM Responses: llm 에게서 돌아온 답변을 토대로 이를 최적화 기준으로 사용하고, 이는 사용자가 가지고 있던 생각들을 구체적인 기준으로 변환하는 과정입니다. Incorporate Optimization Results into Next Cycle: 최적화를 통해 나온 결과는 다시 llm 에게 다음 사이클의 질문을 할 때 참고사항으로 삽입해줍니다. 이를 통해 [llm answer - optimize results with the answer] 사이클을 복수 횟수 돌리는 것의 의의를 강화하고 결과를 개선시킵니다. Cycle Structure: 한 사이클 1차 [llm answer - optimize results with the answer] zone 용도를 Optimizer 하기 전, 입력받은 prompt를 기준으로 subdivision 기준을 LLM에게 물어봅니다. LLM 은 subdivision 의 개략적인 결정을 해주고, optimize 는 구체적인 결과를 생성합니다. 2차 [llm answer - optimize results with the answer] 입력받은 prompt 를 기준으로, zone 들의 config 관련 직관적인 대답을 LLM에게 요구합니다. LLM 은 zone placement 관련된 직관적인 결정을 해주고, optimize 는 이를 구체적인 결과로 생성합니다. 두번째 사이클 이후 두번째 사이클 이후에서는, 직전의 LLM 이 돌려줬던 답변과 함께 실제 optimize 결과를 알려주며 답변의 개선을 직접적으로 요구합니다. 사이클을 반복하며 LLM 결과는 업데이트 되고, 이에 따른 optimize 결과도 개선되어갑니다. Test results case 1 Prompt: 대공간에서 다같이 한 목표를 위해 가운데 쪽에 office 공간들이 모여있어. 그밖의 공간들은 boundary 에 가까운 곳에 배치하고싶어. GIFs: case 2 Prompt: 한 팀에는 약 5명 내외로 사일로 한 팀들을 목표로 하고있어. 때문에 허느 한 용도가 몰려있지 않은 섞인 공간들을 원해. GIFs: case 3 Prompt: office 가 채광을 받기 쉽도록 boundary 에 가까운 곳에 배치를 우선하고, 다른 공간들은 안쪽에 배치하고싶어. GIFs: Conclusion llm의 response raw data 만으로 사용자에게 전달할 데이터가 완성되기 어려운 api에 대해, Self Feedback 을 llm 이 아닌 llm 요청 및 최적화와 후처리까지 합친 범위로 확장함으로 최종 결과의 개선을 도모하고자 하는 작업입니다. cycle 이 반복될수록 의도된 결과에 가까워지는 것을 확인할 수 있었으며, 직관적인 초기값을 llm 에게 의지하는 작업에서 초기값의 불완전할 수 있는 가능성을 감소시킬 수 있습니다. . .