Team Spacewalk

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

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

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









LLM-based Design AI

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

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









Land Optimization Engine

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

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









Recent Posts

From Drafting Tools to Spatial Generation Systems

From Drafting Tools to Spatial Generation Systems

The Integration of LLM-based Bubble Diagrams and Multi-Agent Design Systems 디지털 기술의 비약적인 발전은 건축 설계 도구를 단순히 ‘그리는 도구’에서 ‘공간을 생성하고 판단하는 도구’로 변화시키고 있다.

특히 LLM(Large Language Model) 기반의 설계 도구는 설계자의 입력을 바탕으로 공간 간 관계를 자동 생성하고, 최적화된 배치를 제안하는 시스템으로 진화 중이다. 이 글은 이러한 변화의 흐름 속에서, 전통적인 버블 다이어그램이 어떻게 현대적 설계 자동화 시스템과 결합하며 재해석되고 있는지를 고찰한다. Bubble Diagrams: Concept and History 버블 다이어그램(Bubble Diagram)은 공간 간 관계를 시각적으로 추상화하는 도구로, 건축 및 인테리어 디자인의 초기 기획 단계에서 널리 활용되어 왔다. 각 공간을 원형(버블)으로 나타내고, 연결선으로 기능적 인접성과 동선을 표현함으로써, 전체 공간의 구조를 직관적으로 파악할 수 있게 해준다. Origins and Development 1929년 르 코르뷔지에(Le Corbusier)는 부에노스아이레스 강연에서 간결한 원과 선으로 구성된 스케치를 남겼고, 이는 공간 간 기능 흐름을 도식화한 초기 사례 중 하나로 간주된다. 퍼시 놉스(Percy Nobbs)는 『Design: A Treatise on the Discovery of Form』(1937)에서 이 개념을 체계화했고, 발터 그로피우스(Walter Gropius)는 1940년대 하버드 GSD 수업에서 이를 교육 도구로 정착시켰다. 이후 1950~60년대 병원 및 대형 오피스 매뉴얼에서 공간 구성 기법의 일환으로 폭넓게 활용되었다. Limitations 하지만 전통적 버블 다이어그램은 설계자의 직관에 크게 의존하며, 다음과 같은 한계를 가진다: 모호성: 실제 물리적 거리와 기능적 거리의 불일치 발생 가능 정량적 분석의 부족: 면적, 인원수, 방향 제약 등의 변수 반영이 제한됨 검증의 어려움: 다중 시나리오의 비교·검증에 시간과 노력이 소모됨 Digital Transformation and Automation CAD 기반 도구의 도입은 버블 다이어그램을 디지털화했으나, 그것은 여전히 수동적이었다. 최근에는 사용자 요구를 입력하면 인접 관계, 면적 배분, 배치 제약을 자동 계산하는 버블 다이어그램 자동 생성 시스템이 등장하고 있다. 이러한 전환의 핵심은, 설계 도구가 더 이상 ‘결과를 기록하는 드래프트 도구’가 아니라, 설계 과정에 개입하는 파트너로 작동한다는 점이다. LLM-based Spatial Relationship Generation Systems LLM 기반 Adjacency Graph 생성 시스템은 자연어로 입력된 공간 요구 사항을 분석하고, 이를 토대로 공간 간 관계도를 자동 생성한다. Key Features 🧩 자동 템플릿 생성: 인원수 및 공간 종류에 따른 표준 템플릿 자동 제공 🧭 방향 제약 반영: ‘남향 회의실’, ‘북측 출입구’ 등 조건 해석 📐 면적 기반 배분: 각 기능에 적절한 면적 산출 및 조정 📋 가이드라인 적용: 건축 기준 및 업계 매뉴얼을 내장된 규칙으로 준수 📊 시각화 및 결과 문서화: JSON, HTML, SVG 등 다양한 출력 형식 제공 예시 시나리오: 사용자가 "20인 규모의 스타트업 사무실에서 리셉션은 입구에, 라운지는 남향, 회의실은 CEO실 옆에 위치해야 한다"고 입력하면, 시스템은 이를 파싱하고 적절한 공간 관계를 그래프로 생성한 후, 공간 배치를 제안한다. Multi-Agent System: Structure and Role 복잡한 공간 설계 문제는 단일 모델보다 역할이 분화된 멀티 에이전트(Multi-Agent) 시스템에서 더욱 정교하게 처리된다. 본 시스템에서는 각 작업을 전문화된 에이전트들이 분산 수행하며, GPT-4o와 상호작용한다. Roles of Agents 에이전트 1: 공간 배치 분석 기능 간 관계와 사용 시나리오를 기반으로 1차 배치안 생성 에이전트 2: 방향 제약 적용 ‘남향 라운지’ 등의 조건을 해석하고 반영 에이전트 3: 인원수 최적화 조직 규모에 따른 공간 수요 및 밀도 계산 에이전트 4: 가이드라인 준수 업계 표준, 방화·채광 규제 등 적용 여부 평가 에이전트 5: 면적 기반 최적화 과소·과대 공간 방지 및 잔여 면적 활용 전략 제안 Conclusion: Reinterpreting Bubble Diagrams 버블 다이어그램은 단순한 손 그림에서 시작했지만, 이제는 LLM과 멀티 에이전트 시스템을 통해 ‘계획 생성 도구’로 재해석되고 있다. 이 변화는 단순한 디지털화가 아니라, 설계자의 사고 방식 자체를 재구성하는 진화이며, 다음과 같은 함의를 지닌다: 설계는 더 이상 도면의 결과물이 아니라, 대화형 설계 프로세스가 된다. 설계자는 창의적 사고에 집중하고, 반복적 계산과 조건 검토는 에이전트에 위임할 수 있다. 결과적으로, 정확도와 속도, 창의성과 기능을 동시에 확보할 수 있다. . .


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 등 필수 정보를 모두 저장해야 완전한 복원이 가능합니다. . .


Finding Differentiable Environments

Finding Differentiable Environments

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이 협력해 설계안을 평가하고 선택하는 방식은 앞으로 점차 확산될 것으로 본다. . .