Team Spacewalk

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

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

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









LLM-based Design AI

우리의 LLM 기반의 설계 AI인 는 사용자가 자연어로 자신의 요구사항을 설명하면 즉시 맞춤형 레이아웃을 생성할 수 있게 합니다. 직관적인 API를 통해 제공되며, 사무 공간 계획과 주거용 가구 배치에 특화되어 있습니다.

건축적 추론 능력을 활용하여 AI는 공간적 맥락에 쉽게 적응하고, 건축 전문 지식이 없는 사람도 자신만의 공간을 설계할 수 있도록 돕습니다.









Land Optimization Engine

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

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









Recent Posts

Checkpointing for Kubernetes Pods

Checkpointing for Kubernetes Pods

Abstract Kubernetes 워크플로우 시스템(Argo, Kubeflow 등)은 단계별 input/output 아티팩트 저장을 통한 checkpoint를 기본 제공하지만, 이는 주로 pod 간 데이터 전달에 초점이 맞춰져 있음 pod 내부에서 장시간 실행되는 작업의 “중간 상태”는 별도의 checkpointing 없이는 보존되지 않아, pod 실패/재시작 시 전체 작업을 처음부터 반복해야 하는 비효율 발생 Amazon S3 등 외부 스토리지를 활용한 pod 내부 중간 상태의 checkpointing 전략이 필요함 본 글에서는 S3 기반 checkpointing을 통해 pod 실패 시 마지막 저장 지점부터 작업을 재개하는 방법과, 유전 알고리즘(GA) 등 반복적 실험에서의 시간·리소스 절약 및 성공률 향상 효과를 예시와 함께 설명함 Kubernetes 작업에서 Checkpoint의 필요성 Kubernetes 환경에서 시간이 오래 걸리는 작업(예: 대규모 데이터 처리, 머신러닝 학습, 고성능 도형 시뮬레이션 등)을 수행할 때, spot instance에서의 경쟁 상황, 메모리 부족 등으로 인해 pod가 중간에 실패하거나 재시작되는 경우가 종종 발생합니다.

Kubernetes 기반의 워크플로우 시스템(예: Argo Workflows, Kubeflow Pipelines 등)에서는 input/output artifacts를 통해 각 단계의 결과물을 저장하고, 다음 단계로 전달하는 기능이 이미 잘 지원되고 있습니다. 하지만 이러한 아티팩트 기반 저장 방식은 주로 워크플로우의 각 단계(=pod 단위) 간의 데이터 전달에 초점이 맞춰져 있습니다. 즉, pod 내부에서 오랜 시간 동안 실행되는 작업의 “중간 상태”(예: 메모리 상의 반복 연산, 실험의 진행 상황 등)는 별도의 조치 없이는 보존되지 않습니다. 만약 pod가 중간에 실패하거나 재시작된다면, 해당 pod 내에서 진행 중이던 작업은 처음부터 다시 시작될 수밖에 없습니다. 이때 아무런 조치가 없다면, 작업은 처음부터 다시 시작되어 많은 리소스와 시간을 낭비하게 됩니다. 특히 retry(재시도) 상황에서 checkpointing은 매우 유용합니다. 작업이 실패하거나 예기치 않게 중단된 후, checkpoint가 없다면 전체 과정을 처음부터 다시 반복해야 하지만, checkpoint가 있다면 마지막 저장 지점부터 빠르게 복구할 수 있습니다. 따라서, pod 내부에서의 세밀한 checkpointing이 별도로 필요합니다. 이 글에서는 pod 내부에서 checkpoint를 저장하고 복구하는 방법, 그리고 그 효과에 대해 다룹니다. S3를 활용한 Checkpoint 저장 Checkpoint 데이터를 저장하는 방법은 여러 가지가 있지만, 클라우드 환경에서는 Amazon S3와 같은 오브젝트 스토리지를 활용하는 것이 가장 간편하고 확장성도 뛰어납니다. 작업이 일정 단계(예: epoch, generation 등)에 도달할 때마다 중간 결과를 S3에 저장합니다. pod가 재시작되면, S3에서 가장 최근의 checkpoint를 불러와 이어서 작업을 진행합니다. 이 방식은 다음과 같은 장점이 있습니다. pod가 어떤 노드에서 실행되든, S3를 통해 항상 동일한 checkpoint에 접근 가능 여러 번의 재시작, retry(재시도) 상황에도 불구하고 동일한 결과를 보장 작업의 신뢰성과 효율성 향상 GA(Genetic Algorithm)에서의 Checkpoint 활용 특히 유전 알고리즘(Genetic Algorithm, GA)과 같이 여러 세대(generation)에 걸쳐 반복적으로 계산이 이루어지는 작업에서는, 각 세대가 끝날 때마다 checkpoint를 저장하는 것이 매우 효과적입니다. retry가 필요한 상황(예: pod가 죽거나, 네트워크 장애 등)에서도, checkpoint가 있다면 마지막 저장된 세대부터 바로 이어서 실험을 재개할 수 있습니다. 이는 실험의 시간과 리소스 낭비를 크게 줄여줍니다. GA에서 반드시 checkpoint에 포함해야 할 정보 현재 세대 번호 (generation) population (다음 세대에 전달할 parameter set들의 list 혹은 array) best solution (지금까지 발견된 최적의 parameter set) best fitness (best solution의 fitness 값) (선택) random seed, 환경 정보 등 실험 재현성에 필요한 값 이 정보들이 모두 저장되어야, pod가 중간에 죽더라도 정확히 같은 상태에서 실험을 이어갈 수 있습니다. 예시 코드 (Python) 아래는 GA에서 S3를 활용해 checkpoint를 저장/불러오는 예시 코드입니다. 필수 정보가 모두 포함되어 있습니다. import boto3 import pickle s3 = boto3. client('s3') bucket = 'your-s3-bucket' checkpoint_key = 'checkpoints/ga_generation. pkl' def save_checkpoint(data, key=checkpoint_key): s3. put_object(Bucket=bucket, Key=key, Body=pickle. dumps(data)) def load_checkpoint(key=checkpoint_key): try: obj = s3. get_object(Bucket=bucket, Key=key) return pickle. loads(obj['Body']. read()) except s3. exceptions. NoSuchKey: return None # 사용 예시 generation_to_run = 0 # 이번에 실행할 generation 번호 population = None best_solution = None best_fitness = None random_seed = 42 # 예시: 실험 재현성을 위해 seed도 저장 # checkpoint 불러오기 checkpoint = load_checkpoint() if checkpoint: # 마지막으로 성공한 generation 다음 번호부터 시작 generation_to_run = checkpoint['generation'] + 1 population = checkpoint['population'] best_solution = checkpoint['best_solution'] best_fitness = checkpoint['best_fitness'] random_seed = checkpoint. get('random_seed', 42) while generation_to_run < MAX_GENERATION: # . . . GA 연산 (현재 generation_to_run에 대한) . . . # population, best_solution, best_fitness 업데이트 # 현재 generation 작업이 성공적으로 끝났으므로 checkpoint 저장 save_checkpoint({ 'generation': generation_to_run, # 성공적으로 완료된 generation 번호 'population': population, # 다음 세대에 전달할 parameter set 'best_solution': best_solution, 'best_fitness': best_fitness, 'random_seed': random_seed }) generation_to_run += 1 참고: 실험의 완전한 재현성을 위해서는 random seed, 환경 정보도 함께 저장하는 것이 좋습니다. (동일한 docker image 내에서 실행되는 경우에는 대부분 필요하지 않습니다. ) 필요에 따라 checkpoint에 추가하세요. Checkpoint 적용 전후의 시간 및 성공률 비교 실제 예시로, 한 generation에 약 10초가 걸리는 GA 작업을 50 generation 동안 수행한다고 가정해보겠습니다. 중간에 pod가 실패하여 작업이 중단되는 상황을 비교해보면 다음과 같습니다. 시간 비교 case 1 - no checkpoint 1 ~ 30 (30 generation 동안 정상 진행, 이후 실패) 1 ~ 25 (25 generation 동안 정상 진행, 이후 실패) 1 ~ 50 (50 generation 동안 정상 진행, 최종 성공) 총 수행한 generation 수: 30 + 25 + 50 = 105회 총 소요 시간: 105 × 10초 = 1,050초 (약 17. 5분) case 2 - checkpoint 1 ~ 30 (30 generation 동안 정상 진행, 이후 실패) 30 ~ 50 (21 generation 동안 정상 진행, 최종 성공) 총 수행한 generation 수: 30 + 21 = 51회 총 소요 시간: 51 × 10초 = 510초 (약 8. 5분) 비교 및 효과 checkpoint 없이 재시작: 1,050초 checkpoint로 이어서 재시작: 510초 절반 이상의 시간과 리소스를 절약할 수 있습니다. 최종 성공 가능성 향상 checkpoint를 활용하면, pod가 여러 번 실패하더라도 항상 마지막 저장 지점부터 이어서 작업을 재개할 수 있습니다. 이는 단순히 시간을 아끼는 것뿐만 아니라, 실험의 최종 성공 가능성도 크게 높여줍니다. 반복적인 실패에도 불구하고, 전체 실험을 완주할 수 있는 확률이 높아집니다. 예를 들어, 각 generation이 98% 확률로 성공한다고 가정하고, 총 50개의 generation을 최대 3번의 pod retry 안에 모두 성공시켜야 하는 상황을 비교해보겠습니다. case 1 - no checkpoint # 각 try 의 실패 확률 = 1 - 0. 98 ** 50 >>> 1 - 0. 98 ** 50 0. 6358303199128832 # 세번 모두 실패할 확률 >>> 0. 6358303199128832 ** 3 0. 2543740234375 # 세번 중 최소 한번 성공할 확률 >>> 1 - 0. 2543740234375 0. 7456259765625 즉, 약 75% 확률로 최종 성공할 수 있습니다. case 2 - checkpoint # 개별 generation 하나가 세 번 모두 실패할 확률 >>> 0. 02 ** 3 8e-06 # 이 값은 "하나의 generation이 pod 1, 2, 3 모두에서 실패할 확률"을 의미합니다. # 실제로 generation 단위로 retry가 되는 것은 아니지만, # pod-level retry + checkpoint resume 구조에서 어떤 generation은 최대 3번까지 시도될 수 있습니다. # 50개의 generation이 모두 3번 이내에 성공할 확률 >>> (1 - 8e-06) ** 50 0. 9996000399986667 즉, 약 99. 96% 확률로 최종 성공할 수 있습니다. 요약: checkpoint는 retry 상황에서 시간과 리소스를 절약할 뿐만 아니라, 실험의 성공률까지 높여주는 중요한 전략입니다. 결론 Kubernetes 환경에서 S3를 활용한 checkpointing은, 특히 반복적이고 시간이 오래 걸리는 작업(예: GA)에서 pod 재시작이나 retry(재시도) 상황에 따른 리소스 낭비를 크게 줄여줍니다. 각 세대(generation)마다 checkpoint를 저장하면, 언제든지 중단된 지점부터 효율적으로 작업을 이어갈 수 있습니다. GA의 경우 population, best solution, best fitness, random seed 등 필수 정보를 모두 저장해야 완전한 복원이 가능합니다. . .


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 에게 의지하는 작업에서 초기값의 불완전할 수 있는 가능성을 감소시킬 수 있습니다. . .