만약 당신이 현대적인 이미지 모델을 사용해 본 적이 있다면, 그것이 뒷마당 사진을 아주 멋진 모습으로 재설계할 수 있다는 사실을 이미 알고 있을 것입니다. 모델에 "이 마당을 현대적인 일본식 정원으로 만들어줘"라고 입력하면 몇 초 만에 설득력 있는 렌더링 (render) 결과물을 얻을 수 있습니다. 문제가 해결된 것 같나요?

전혀 그렇지 않습니다. 예쁜 사진은 문제의 쉬운 20%에 불과합니다. 나머지 어려운 80% — 즉, 결과물이 실제로 사용 가능한 제품이 될지 아니면 단순한 장난감이 될지를 결정하는 부분 — คือ 생성 모델 (generative model)이 알지 못하는 모든 것입니다. 예를 들어, 해당 식물들이 사용자의 기후에서 생존할 수 있는지, 비정형 사진을 어떻게 공간 지도 (spatial map)로 변환할 것인지, 그리고 시공업자가 실제로 건축할 수 있는 구조화된 사양 (structured spec)을 어떻게 생성할 것인지와 같은 문제입니다.

저는 실제 상용 AI 조경 도구 뒤에 숨겨진 진짜 엔지니어링 파이프라인 (engineering pipeline)을 살펴보고자 합니다. 이는 "생성하는 모델"과 "출시되는 시스템" 사이의 간극을 보여주는 좋은 사례 연구이기 때문입니다. 이 분야에서 가장 완성도 높은 구현체 중 하나인 Hadaa를 구체적인 예시로 사용하겠지만, 여기서 얻는 아키텍처 (architecture) 교훈은 여러분이 만들 수 있는 거의 모든 "생성형 + 현실 세계의 제약 조건"이 결합된 제품에 일반화될 수 있습니다.

엔지니어의 관점에서 정의한 문제

입력: 어질러진 실제 마당을 찍은 1~14장의 휴대폰 사진.
사용자가 실제로 필요로 하는 출력:

• 다양한 스타일과 각도의 실사 같은 렌더링 (photorealistic renders)
• 해당 위치에서 모든 식물이 생존할 수 있는 식재 목록 (planting list)
• 구역, 라벨, 경로 너비가 포함된 시공업자용 청사진 (contractor blueprint)
• 가격 책정이 가능한 물량 산출서 (bill of quantities: 식물 + 자재)

첫 번째 항목만이 생성형 비전 (generative-vision) 문제입니다. 나머지는 구조화된 데이터 (structured-data) 문제들이 겉모습만 바꾼 것에 불과합니다. 이것이 핵심 통찰입니다.

1단계 — 사진에서 구조적 이해로

공간적으로 이해하지 못하는 대상은 제약하거나 주석을 달 수 없습니다. 따라서 어떤 "예쁘게 만들기" 단계에 들어가기 전에, 시스템은 픽셀을 구조로 변환해야 합니다. 즉, 장면을 분할 (segment)하고 (잔디, 울타리, 테라스, 기존 나무, 구조물), 대략적인 기하학적 구조 (geometry)를 추정하며, 여러 장의 사진이 주어졌을 때 이를 일관된 부지 영역 지도 (area map)로 병합해야 합니다.

이것은 화려하지 않은 컴퓨터 비전 (computer-vision) 배관 작업입니다. 즉, 세그멘테이션 (segmentation), 깊이/일관성 추정 (depth/consistency estimation), 그리고 단일한 탑다운 (top-down) 이해를 위한 다중 이미지 합성 (multi-image synthesis) 과정입니다. 여기서 잘못되면 이후의 모든 단계가 그 오류를 물려받게 됩니다. 반대로 이를 제대로 수행하면, 모델이 프레임 전체에 대해 환각 (hallucinate)을 일으키도록 내버려 두는 대신, 의도적으로 보존, 편집 또는 교체할 수 있는 '알려진 영역 (known regions)'을 가진 캔버스를 얻게 됩니다.

이와 같은 것을 구축할 때 얻을 수 있는 실질적인 교훈은 다음과 같습니다: 마스킹 (masking)과 영역 보존 (region-preservation)은 사후 고려 사항이 아니라 핵심 기능입니다. 사용자들은 "화단은 재설계하되, 내 집과 수영장은 정확히 그 자리에 그대로 두어줘"라고 요구합니다. 이는 1단계 (Stage 1)에서 실제 영역을 생성해냈을 때만 가능합니다.

2단계 — 제약 조건이 있는 생성 (Constrained generation, "쉬운" 부분)

이제 생성 단계입니다. 구조화된 장면과 스타일 프롬프트 (style prompt)가 주어지면, 실사 같은 변형 결과물을 생성합니다. 현대의 확산 기반 이미지 투 이미지 (diffusion-based image-to-image) 기술은 이를 잘 처리하며, 2026년의 사실주의 (realism)는 기본적으로 해결된 상품과 같습니다.

여기서의 엔지니어링 노력은 "보기 좋게 만들 수 있는가"가 아니라 "제어 (control)"에 있습니다. 즉, 보존된 마스크 (masks)를 존중하고, 편집을 국소적으로 유지하며 (집을 다시 그리지 않고 대나무를 야자수로 교체), 8장의 무관한 이미지가 아닌 일관된 세트 (set) (8개의 카메라 각도와 계절/야간 변형에 걸쳐 동일한 디자인 유지)를 생성하는 것입니다. 세트 전체의 일관성을 유지하는 것이 실제 어려운 하위 문제이며, 이는 단발성 생성 (one-shot generation)과는 매우 다른 차원의 문제입니다.

3단계 — 생물학 계층 (The biology layer, "실제로 어려운" 부분)

대부분의 "AI 정원 디자인" 도구들이 조용히 실패하는 지점이자, 흥미로운 엔지니어링이 존재하는 곳입니다.

생성 모델은 무엇이 어디에서 자라는지 전혀 알지 못합니다. 모델은 "무성한 정원"이라는 키워드에 맞춰 그럴듯해 보이는 열대 야자수를 그릴 뿐이며, 모델은 생존 가능성이 아닌 그럴듯함 (plausibility)을 최적화합니다. 사용자는 9개월 뒤 모든 식물이 죽고 나서야 이 사실을 알게 됩니다.

이를 해결하는 것은 프롬프트 엔지니어링 (prompt-engineering) 문제가 아닙니다. 단순히 "적절한 식물을 사용해줘"라고 덧붙인다고 해서 신뢰할 수 있는 것이 아닙니다. 이것은 **생성 위에 계층화된 제약 조건 만족 문제 (constraint-satisfaction problem)**입니다.

1. 사용자의 위치를 내한성 구역 (hardiness zone), 강수량 및 서리 발생일 데이터로 변환합니다.
2. 이러한 환경적 내성 (environmental tolerances)을 기준으로 하는 식물 데이터베이스를 유지합니다.
3. 렌더링에서 "뒷모습 구석에 있는 키 큰 꽃이 피는 관목"을 요청할 때, 단순히 비슷해 보이는 식물이 아니라 해당 위치의 제약 조건을 충족하는 실제 종으로 그 _역할 (role)_을 해결합니다.
4. 최종 식재 목록이 사용자에게 전달되기 전에 제약 조건과 일치하는지 검증합니다.

Hadaa는 이를 "생물학적 엔진 (Biological Engine)"이라 부르며, 이는 경쟁사들이 복제하기 가장 어려워했던 부분입니다. 정확히 말하자면 이것은 모델의 미세 조정 (tweak)이 아니라, 생성형 핵심 (generative core)에 결합된 전체 데이터 및 규칙 서브시스템 (subsystem)이기 때문입니다. 이것은 전형적인 패턴입니다: 해자 (moat)는 모델이 아니라, 모델을 둘러싸고 있는 도메인 제약 조건 (domain constraints)입니다. (그들의 11가지 도구 분석은 어떤 도구가 이를 갖추고 있고 그렇지 않은지에 대한 괜찮은 지도 역할을 합니다.)

4단계 — 픽셀에서 구조화된 사양 (spec)으로

마지막 단계는 승인된 렌더링을 실제로 시공 가능한 무언가로 바꾸는 것입니다: 색상으로 구분된 청사진 (구역, 라벨, 경로 너비)과 물량 산출서 (bill of quantities, 각 식물의 수량 및 자재량)가 그것입니다. 이것은 본질적으로 2단계의 _역순 (reverse)_으로 실행되는 정보 추출 (information-extraction) 및 레이아웃 생성 (layout-generation) 문제로, 시각적 디자인에서 구조화되고 정량화된 데이터로 되돌아가는 과정입니다.

또한 이곳에 많은 비즈니스 가치가 숨어 있는데, 왜냐하면 이것이 전문가가 작업 팀에게 직접 전달할 수 있는 결과물이기 때문입니다. 개인 디자이너에게 "여기 멋진 사진이 있습니다"와 "여기 2분 만에 생성된 청사진, 구역 검증이 완료된 식재 가이드, 그리고 가격이 책정된 물량 산출서(BOQ)가 있습니다"의 차이는 영업 주기가 며칠 단위에서 몇 분 단위로 바뀌는 차이입니다. 이것이 Hadaa의 Pro Studio가 내세우는 핵심 가치이며, 전문가를 위한 기능 분석은 기본적으로 이 단계를 위한 사양서(spec sheet)라고 할 수 있습니다.

"왜 그냥 일반 이미지 모델을 사용하지 않나요?"

왜냐하면 가공되지 않은 확산 모델 (Raw diffusion model)은 2단계(Stage 2)만을 제공하며 그 외에는 아무것도 제공하지 않기 때문입니다. 실제 제품을 출시하려면 여전히 다음을 구축해야 합니다:

첫 번째 열의 모든 ❌는 프롬프트(Prompt)가 아니라 하위 시스템(Subsystem)입니다. 이것이 "API 키만 있으면 주말 사이에 이걸 다시 만들 수 있어"라는 말이 이 카테고리의 유명한 유언이 되는 이유입니다.

만약 당신이 (직접 만드는 것이 아니라) 제품을 평가하고 있다면

이런 글을 읽는 대부분의 사람들은 그저 자신의 마당을 재설계하고 싶거나 전문적으로 사용하고 싶어 할 뿐입니다. 하지만 공학적인 관점은 여전히 당신에게 구매 기준을 제시해 줍니다:

• 3단계(Stage 3)에서 어떤 일이 일어나는지 물어보세요. 식물이 실제 기후대(Climate zone)에 맞는지 검증하나요, 아니면 단순히 초록색 식물을 그리기만 하나요? 이것이 가장 핵심적인 신호를 주는 질문입니다.
• 4단계(Stage 4)에서 무엇이 나오는지 물어보세요. 렌더링만 있다면 그것은 벽지일 뿐입니다. 렌더링에 구역 검증이 완료된 식재 가이드(Planting guide)와 실행 가능한 청사진(Blueprint)이 더해져야 비로소 하나의 프로젝트가 됩니다.
• 사용 방식에 맞춰 가격 모델을 선택하세요. 프로젝트당 결제 방식(Hadaa는 렌더링당 약 9달러부터 시작하며 구독형이 아님)은 일회성 재설계에 적합합니다. 월간 구독 방식은 매주 디자인을 생산하는 경우에만 의미가 있습니다.

전체 파이프라인의 작동 구현체를 직접 확인해보고 싶다면, 가장 빠르게 직관을 얻는 방법은 마당 사진을 하나 실행해보고 식재 가이드와 청사진에 실제로 무엇이 포함되어 있는지 검사하는 것입니다. 거기서 당신은 도구가 어떤 단계를 실제로 구축했는지, 아니면 흉내만 냈는지를 느낄 수 있습니다.

요점 (Takeaway)

이 교훈은 정원을 넘어 광범위하게 적용됩니다. 2026년의 대부분의 "AI가 X를 한다"는 제품들에서 생성 모델 (Generative model)은 범용화된 상품 (Commodity)이며, 지속 가능한 엔지니어링 — 그리고 해자 (Moat) — 는 생성을 현실 세계의 진실에 맞게 제약하고 구조화된 실행 가능한 출력물을 내보내는 계층 (Layer)에 있습니다. 조경 디자인에서 그 계층은 공간 이해 (Spatial understanding), 기후를 고려한 제약 충족 (Climate-aware constraint satisfaction), 그리고 사양 생성 (Spec generation)입니다. 렌더링은 단지 시연하기 좋은 부분일 뿐입니다.

만약 이 분야의 도구들을 비교하고 있다면, 스크린샷으로 예쁘게 찍히지 않는 부분들을 기준으로 판단하십시오.

생성 모델 (Generative models) 위에 제약 조건 레이어 (Constraint layers)를 두는 것에 대해 의견이 있으신가요? 여러분이라면 생물학 엔진 (Biology engine)을 어떻게 다르게 설계할지 정말 궁금합니다 — 댓글을 남겨주세요.