Askitect, 그리고 프롬프트 엔지니어링의 진화

‘Askitect’라는 용어는 2024년 2월, 뉴질랜드의 건축 디자인 회사인 Formance의 블로그 포스트를 통해 처음 소개되었습니다 ¹. 본래 이는 “질문을 통해 고객의 진정한 니즈를 파악하는 건축가(Architect who asks)”를 뜻하는 말로, 단순히 고객의 요구를 수행하는 것을 넘어, 본질적인 문제를 진단하고 더 나은 삶의 방식을 제안하는 전문가상을 정의하기 위해 만들어졌습니다.

이 개념은 최근 인공지능(AI) 분야로 넘어오면서 복잡해지는 인간과 AI의 상호작용을 해결하기 위한 새로운 전문가의 필요성과 맞물려 그 의미가 확장되었습니다.

여기서 왜 하필 ‘Design(설계)’이나 ‘Architecture(건축)’가 아닌 ‘Ask(질문)’가 강조되는지 주목할 필요가 있습니다. 단순히 구조를 구축하는 행위(Architecture) 이전에, “무엇을 지을 것인가?”를 정의하는 과정이 선행되어야 하기 때문입니다.

Askitect는 단순히 이미 정의된 요구사항을 설계하는 존재가 아닙니다. 표면적인 요구사항 이면에 숨겨진 진짜 의도와 맥락을 ‘질문’을 통해 발굴(Elicitation)해내는 것이 이들의 핵심 역량입니다. 고도화된 AI 작업 환경에서 모호한 인간의 의도를 기계가 이해할 수 있는 명확한 구조로 변환하려면, 먼저 끊임없는 ‘질문’을 통해 그 본질을 파헤치는 탐구적 접근이 필수적이기 때문입니다. 즉, 올바른 설계(Architecture)는 올바른 질문(Ask)에서 시작됩니다.

1. Askitect와 Prompt Engineering: 유사하지만 다른 접근

Askitect와 프롬프트 엔지니어링은 모두 AI로부터 최상의 결과를 이끌어내려 한다는 점에서 유사한 목표를 공유하지만, 그 접근 방식과 철학에서는 뚜렷한 차이가 있습니다. 프롬프트 엔지니어링이 단일 입력값(Input)을 최적화하는 ‘입력의 기술’이라면, Askitect는 질문과 응답이 오가는 전체 과정, 즉 ‘상호작용의 프레임워크(Interaction Framework)’를 설계하는 것에 가깝습니다.

Askitect는 단순히 명령어를 입력하는 단계를 넘어, 인간과 기계 사이를 통역하고 번역하는 작업 그 자체를 설계합니다. 인간의 모호한 의도를 기계가 이해할 수 있는 명확한 지시로 변환하고, 기계의 논리적 연산 결과를 다시 인간의 맥락에 맞게 해석해내는 ‘상호 이해의 프로토콜’을 구축하는 것입니다.

2. 예시로 보는 차이: “여행 계획”의 경우

Prompt Engineering의 접근 (입력 최적화) 사용자가 원하는 완벽한 답을 얻기 위해 프롬프트를 정교하게 다듬는 것에 집중합니다.

User: “도쿄 3박 4일 여행 코스 추천해줘.”
User (Revised): “20대 남성 2명이 가는 도쿄 3박 4일 여행 코스 추천해줘. 신주쿠 근처 숙소이고, 예산은 인당 100만원이야. 맛집 탐방이 주 목적이고 너무 빡빡하지 않게 구성해줘.”

Askitect의 접근 (상호작용 설계) AI가 먼저 질문을 던져 사용자의 숨겨진 니즈를 파악하도록 대화의 구조를 설계합니다.

System (Askitect Designed): “여행 계획을 도와드릴게요. 먼저 몇 가지를 알려주세요.”

1. 여행의 테마는 무엇인가요? (예: 휴식, 미식, 쇼핑, 관광)
2. 동행인은 누구인가요? (예: 혼자, 연인, 가족, 친구)
3. 가장 중요하게 생각하는 예산 항목은? (예: 숙소, 식사, 쇼핑)

User: “친구랑 가고, 맛집이 중요해. 예산은 식사에 많이 쓰고 싶어.”
AI: “알겠습니다. 미식에 집중한 여유로운 동선을 제안할게요…”

이 예시에서 볼 수 있듯이, 프롬프트 엔지니어링은 사용자가 사전에 모든 요구사항을 명확히 인지하고 이를 한 번에 압축적으로 전달하는 능력(Context Compression)을 요구합니다. 반면 Askitect는 사용자가 스스로 무엇을 원하는지 모를 수 있다는 전제 하에, 단계적인 질문을 통해 잠재된 의도를 함께 발굴해가는 과정(Context Discovery)을 설계합니다. 전자가 ‘숙련된 사용자’를 위한 효율성의 도구라면, 후자는 ‘모든 사용자’를 위한 친절한 안내자인 셈입니다.

3. 질적 연구 설계와 연결 (Qualitative Research Design)

이러한 설계적 접근은 Joseph A. Maxwell의 저서 “Qualitative Research Design: An Interactive Approach”에서 강조하는 질적 연구의 본질과 깊이 맞닿아 있습니다.

“A design for a study always exists, explicitly or implicitly. It is important to make your design explicit, to get it out in the open, where its strengths, limitations, and implications can be clearly understood.”

“연구 설계는 명시적이든 암묵적이든 항상 존재합니다. 중요한 것은 그 설계를 명시적으로 드러내어, 그것의 강점과 한계, 그리고 함의가 명확히 이해될 수 있도록 하는 것입니다.”

연구 설계를 고정된 청사진이 아닌 상호작용하는 요소들의 조율 과정으로 보았듯, Askitect는 AI와의 대화를 피드백과 조정을 통해 완성도를 높여가는 순환적이고 상호작용적인 과정으로 파악합니다. 그래서 Askitect는 인간에게 내재되어 있는 모호한 의도를 ‘명시적인 설계’로 끌어올리게 됩니다.

4. 기계가 이해하는 언어

결국 Askitect가 추구하는 상호작용의 내부를 들여다 보자면, 기계가 인간의 의도를 이해할 수 있는 명확한 기준을 필요로 합니다.

이 상호작용은 Human-in-the-loop (인간 참여형 루프) 모델을 기반으로 하며, 더 나아가 기계(Agent)와 기계(Agent) 간의 자율적인 소통까지 확장됩니다. 이 복잡한 다자간의 소통(Human-Agent, Agent-Agent)이 원활하게 이루어지기 위해서는 서로의 의도와 맥락을 정확히 일치시키는 약속이 필수적입니다.

이러한 약속을 정의하는 방법에는 여러 가지가 있지만, 대표적인 예로 온톨로지(Ontology)를 들 수 있습니다. 온톨로지는 단순한 단어의 사전적 정의를 넘어, 개념과 개념 사이의 관계를 규명하여 기계가 인간의 의도를 문맥적으로 이해하고 추론할 수 있게 하는 기반이 됩니다. Askitect는 바로 이 온톨로지적인 구조 위에서 질문을 설계함으로써, 인간과 AI, 그리고 에이전트 간의 오해 없는 소통을 가능하게 하는 역할을 수행합니다.

5. 온톨로지로 보는 상호작용 구조 (RDF 예시)

Askitect가 설계하는 상호작용 구조를 지식 그래프의 표준인 RDF(Resource Description Framework) 형태로 표현하면 다음과 같습니다. 이는 기계가 사용자의 ‘숨겨진 제약 조건’을 명시적인 데이터로 처리하는 방식을 보여줍니다.

@prefix ex: <http://example.org/askitect/> .
@prefix user: <http://example.org/user/> .

# 사용자의 숨겨진 의도 (Hidden Context)
user:Request_001 a ex:TravelRequest ;
    ex:hasIntent ex:PlanTrip ;
    ex:hasImplicitConstraint [
        ex:companion "Friend" ;
        ex:theme "Gastronomy" ;
        ex:priority "Budget for Food"
    ] .

# Askitect가 설계한 질문 구조 (Interaction Design)
ex:System_Askitect a ex:Agent ;
    ex:elicits user:Request_001 ;
    ex:asks [
        a ex:Question ;
        ex:target "Theme" ;
        ex:content "여행의 테마는 무엇인가요?"
    ], [
        a ex:Question ;
        ex:target "Companion" ;
        ex:content "동행인은 누구인가요?"
    ] .

이 데이터를 시각화하면 다음과 같은 그래프가 됩니다.

graph TD
    %% Nodes
    subgraph User_Context [User Context]
        Req(user:Request_001<br>ex:TravelRequest)
        Intent[ex:PlanTrip]
        Const[Implicit Constraints]
        V1[Friend]
        V2[Gastronomy]
        V3[Budget for Food]
    end

    subgraph System_Design [Askitect Interaction]
        Agent(ex:System_Askitect<br>ex:Agent)
        Q1[Question: Theme?]
        Q2[Question: Companion?]
    end

    %% Relationships
    Req -- hasIntent --> Intent
    Req -- hasImplicitConstraint --> Const
    Const -- companion --> V1
    Const -- theme --> V2
    Const -- priority --> V3

    Agent -- elicits --> Req
    Agent -- asks --> Q1
    Agent -- asks --> Q2
    
    style User_Context fill:#f9f9f9,stroke:#333,stroke-width:1px
    style System_Design fill:#e6f3ff,stroke:#0066cc,stroke-width:1px

이처럼 Askitect가 설계하는 상호작용 구조를 통해 모호한 자연어를 구조화된 데이터(Triple)로 변환할 수 있는 경로를 구성하게 되면, 암묵적인 의도는 기계가 활용할 수 있는 지식이 됩니다.