TL;DR
📋 핵심 발견
ATHENA로 만든 앱은 기존 챗봇 방식 대비 평균 뷰 수 2배(6.0 vs 3.1), 코드량 3배(353.9 vs 117.8 LoC) — 중간 표현(IR)이 LLM의 구조적 코드 생성을 가능하게 한다는 것을 입증했습니다
사용자 연구 참가자의 75%가 일반 챗봇보다 ATHENA를 선호했으며, 25분 내에 모든 참가자가 다중 화면 앱 프로토타입을 생성 완료 — 비개발자도 네이티브 앱 프로토타이핑이 가능함을 보여줍니다
세 가지 IR(Storyboard, Data Model, GUI Skeleton)의 계층적 의존성이 LLM의 컨텍스트 부담을 줄이고, 수정 시 '폭포수식 전파'로 일관성을 유지합니다
컴파일 오류는 ATHENA가 더 많았으나(10.4 vs 1.25), 이는 코드 복잡도 증가의 자연스러운 결과이며 대부분 경미한 오류(hallucinated property, 잘못된 인자 타입)로 숙련 개발자가 쉽게 수정 가능한 수준이었습니다
Athena: Intermediate Representations for Iterative Scaffolded App Generation with an LLM
arXiv: 2508.20263
💡이 논문이 등장한 배경
"채팅창에 '할 일 관리 앱 만들어줘'라고 치면 바로 앱이 나올까?" 2024~2025년, LLM을 활용한 코드 생성은 단일 함수나 짧은 스크립트 수준에서는 놀라운 성능을 보여주고 있었습니다. 하지만 다중 화면으로 구성된 모바일 앱을 만들어달라고 하면 이야기가 달라집니다. 화면 간 내비게이션, 데이터 모델의 일관성, 여러 파일에 걸친 코드 구조 — 이 모든 것을 하나의 프롬프트로 처리하기엔 LLM의 컨텍스트 윈도우가 감당하기 어려웠습니다.
기존 접근법은 대부분 '챗봇 스타일'이었습니다. 사용자가 원하는 것을 설명하면 LLM이 코드를 통째로 생성하는 방식입니다. 이것은 마치 건축가 없이 시공사에게 "3층짜리 집 지어줘"라고 말하는 것과 비슷합니다. 결과물이 나오긴 하지만, 벽이 어디로 통하는지도 모르고, 배관이 어디로 가는지도 불분명한 집이 만들어지곤 했습니다. 특히 SwiftUI처럼 LLM의 학습 데이터에 상대적으로 적게 포함된 프레임워크에서는 이 문제가 더 심각했습니다.
Apple의 연구팀은 이 문제를 '분해'로 접근했습니다. 복잡한 앱을 한 번에 생성하려 하지 말고, 소프트웨어 엔지니어가 실제로 앱을 설계하는 과정 — 먼저 화면 구조를 잡고, 데이터를 정의하고, 각 화면의 UI를 설계한 후에야 코드를 작성하는 — 을 LLM에게도 밟게 하면 어떨까? 이것이 ATHENA의 출발점입니다.
🔍 핵심 아이디어
ATHENA의 핵심 아이디어는 놀랍도록 직관적입니다. 앱 코드를 바로 생성하지 말고, '중간 설계도(Intermediate Representation)'를 먼저 만들어라. 이것은 건축에서 청사진 없이 집을 짓지 않는 것과 같은 원리입니다.
ATHENA는 세 종류의 설계도를 사용합니다. 첫째, Storyboard — 앱의 전체 화면 구조를 나타내는 유향 그래프(directed graph)입니다. 각 화면이 노드이고, 화면 간 이동 경로가 엣지입니다. 지하철 노선도처럼 '여기서 저기로 어떻게 가는지'를 한눈에 보여줍니다. 둘째, Data Model — Swift 구조체(struct) 형태로, 앱이 다루는 데이터의 뼈대를 정의합니다. 셋째, GUI Skeleton — 각 화면의 레이아웃과 상호작용을 SwiftUI 의사코드(pseudocode)로 표현합니다.
이 세 가지 IR 사이에는 명확한 의존성이 존재합니다. Storyboard가 전체 화면 목록을 정의하면, 각 화면의 GUI Skeleton은 그 목록 위에 작성됩니다. Data Model이 데이터 필드를 정의하면, GUI Skeleton은 그 필드를 참조하여 UI 요소를 배치합니다. 이 계층 구조 덕분에 한 부분을 수정하면 변경 사항이 자연스럽게 아래로 전파됩니다.
기존 챗봇 방식과의 결정적 차이는 사용자가 이 설계도를 직접 보고 수정할 수 있다는 점입니다. 코드를 이해하지 못해도 "이 화면에서 저 화면으로 가는 경로를 추가해줘"라거나 "이 데이터에 날짜 필드를 넣어줘"라고 자연어로 요청하거나, 에디터에서 직접 텍스트를 편집할 수 있습니다. 이것은 사용자에게 '블랙박스' 대신 '투명한 설계 과정'을 제공합니다.
최종적으로 사용자가 설계도에 만족하면, ATHENA는 세 가지 IR을 모두 LLM에 입력하여 실행 가능한 SwiftUI 코드를 생성합니다. 이때 LLM은 '무에서 유를 창조'하는 것이 아니라, 잘 정의된 설계도를 '번역'하는 훨씬 쉬운 작업을 수행하게 됩니다.
🤔 어떻게 작동하는가
Step 1: 자연어로 앱 아이디어 입력
사용자가 챗 인터페이스에 "반려동물 건강 관리 앱"처럼 원하는 앱을 설명합니다. 마치 건축주가 건축가에게 "3층짜리 카페 겸 주거 공간"이라고 말하는 것과 같습니다. 이 단계에서 코드는 전혀 생성되지 않습니다.
Step 2: IR Planner — 무엇을 그릴지 결정
사용자의 요청을 받은 IR Planner가 어떤 설계도(IR)를 생성하거나 수정해야 하는지 결정합니다. 새로운 앱이면 세 가지 IR을 모두 생성하고, 수정 요청이면 영향받는 IR만 업데이트합니다. Planner는 사용자의 요청을 '생성(create)', '업데이트(update)', '삭제(delete)' 같은 원자적 작업으로 분해합니다.
Step 3: 폭포수식 IR 생성 — 위에서 아래로
설계도는 반드시 Storyboard → Data Model → GUI Skeleton 순서로 생성됩니다. 건물의 기둥을 먼저 세우고, 배관을 설치한 뒤, 인테리어를 하는 것과 같습니다. 이 순서가 중요한 이유는 각 IR이 상위 IR에 의존하기 때문입니다. GUI Skeleton은 Storyboard에 정의된 화면만 참조할 수 있고, Data Model에 정의된 필드만 사용할 수 있습니다.
Step 4: 사용자 검토 및 반복 수정
생성된 IR은 ATHENA의 통합 에디터에 시각적으로 표시됩니다. 사용자는 스토리보드 그래프를 보며 화면 흐름을 확인하고, 데이터 모델의 필드를 점검하고, 각 화면의 레이아웃 스켈레톤을 검토합니다. 마음에 들지 않는 부분은 자연어 채팅으로 수정을 요청하거나 에디터에서 직접 편집할 수 있습니다. 이 피드백 루프가 ATHENA의 핵심 가치입니다.
Step 5: 병렬 GUI Skeleton 수정 — 속도를 위한 설계
여러 화면의 GUI Skeleton을 동시에 수정해야 할 때, ATHENA는 각 화면을 독립적인 LLM 호출로 처리합니다. 각 GUI Skeleton은 다른 화면과 독립적이기에 병렬 처리가 가능합니다. 마치 아파트 각 세대의 인테리어를 동시에 진행하는 것처럼, 이 설계 덕분에 수정 응답 시간이 크게 단축됩니다.
Step 6: 코드 생성 — 설계도를 코드로 번역
사용자가 설계도에 만족하면, 세 가지 IR 전체가 하나의 LLM 호출에 입력됩니다. LLM은 이 구조화된 설계도를 읽고 SwiftUI 코드를 JSON 형식으로 출력하며, 이는 자동으로 파싱되어 표준 SwiftUI 파일 구조로 배치됩니다. 최종 결과물은 Xcode에서 바로 열어 빌드할 수 있는 네이티브 iOS 앱 프로젝트입니다.
🛠️ 실험이 말해주는 것
ATHENA의 평가는 두 가지 축으로 진행되었습니다. 먼저 기술 평가(Technical Evaluation)에서 10개의 샘플 앱을 생성한 결과, 평균 뷰 6.4개, 코드 514.8줄의 앱이 만들어졌습니다. 평균 컴파일 오류 7.3건, 내비게이션 오류 4.0건이 발생했지만, 대부분은 LLM이 존재하지 않는 SwiftUI 프로퍼티를 '환각(hallucinate)'하거나 인자 타입을 잘못 사용하는 경미한 오류였습니다.
더 흥미로운 것은 사용자 연구(User Study) 결과입니다. 참가자들에게 ATHENA와 일반 챗봇 방식(Baseline)으로 각각 앱을 만들게 했을 때, ATHENA로 만든 앱은 평균 6.0개의 뷰와 353.9줄의 코드를 포함한 반면, Baseline은 3.1개의 뷰와 117.8줄에 그쳤습니다. 즉, 중간 표현을 통한 구조적 접근이 LLM이 생성하는 앱의 규모와 복잡도를 2~3배 끌어올린 것입니다.
물론 복잡도가 높아진 만큼 컴파일 오류도 증가했습니다(10.4건 vs 1.25건). 하지만 참가자 75%가 초기 아이디어 구현 시 ATHENA를 선호했으며, 25분이라는 제한 시간 내에 모든 참가자가 다중 화면 프로토타입을 완성했습니다. 이는 IR이 사용자에게 '어디를 고쳐야 하는지'에 대한 가시성을 제공함으로써, 코드를 모르는 사용자도 의미 있는 수준의 앱 프로토타이핑이 가능하다는 것을 보여줍니다.
⚡️ 현실 세계의 임팩트
ATHENA는 Apple Machine Learning Research에서 발표한 논문으로, Apple이 SwiftUI 생태계에서 LLM 기반 앱 생성을 어떻게 구상하는지를 보여주는 연구입니다. 이 논문의 '중간 표현을 통한 구조화된 코드 생성' 패턴은 Apple의 개발 도구 방향성을 시사합니다
2025~2026년 현재, v0(Vercel), Cursor, Bolt.new, Lovable, Replit 등 다양한 AI 코드 생성 도구가 경쟁하고 있습니다. 이들 대부분이 웹(React, Next.js) 중심인 반면, ATHENA는 네이티브 iOS 앱(SwiftUI) 생성에 특화되어 있어 모바일 네이티브 영역의 AI 코드 생성 가능성을 탐색한 초기 연구로 의미가 있습니다
ATHENA의 핵심 아이디어 — '코드 생성 전에 구조화된 중간 표현을 먼저 만들고 사용자와 함께 반복 수정한다' — 는 이미 유사한 형태로 상용 도구에 반영되고 있습니다. 예를 들어 v0의 컴포넌트 단위 생성, Cursor의 맥락 인식 편집은 모두 LLM의 '한 번에 모든 것' 방식의 한계를 구조적으로 우회하려는 같은 방향의 시도입니다
이 연구는 비개발자의 앱 프로토타이핑 접근성을 높이는 HCI(Human-Computer Interaction) 관점에서도 중요합니다. 코드를 직접 보지 않고도 스토리보드와 데이터 모델 수준에서 앱 설계에 참여할 수 있다는 것은, 디자이너-개발자 협업 방식에 대한 새로운 가능성을 제시합니다
☝️ 연구의 계보
ATHENA는 LLM 기반 코드 생성 연구(Codex, AlphaCode 등)와 엔드유저 프로그래밍(end-user programming)/자연어 인터페이스 연구의 교차점에 위치합니다. 특히 '복잡한 생성 작업을 중간 표현으로 분해한다'는 아이디어는 컴파일러 설계의 IR 개념을 차용한 것입니다. 이 논문 이후, 구조화된 중간 표현을 활용한 멀티 에이전트 코드 생성, 도메인 특화 IR을 통한 앱 생성(예: 특정 프레임워크에 맞춘 AST 기반 코드 생성) 등의 후속 연구 방향이 열려 있습니다.
🫸 강점과 한계
[강점] 세 가지 IR의 계층적 설계가 직관적이고 실용적입니다. Storyboard → Data Model → GUI Skeleton의 의존성 구조는 실제 소프트웨어 설계 프로세스를 잘 반영하며, 사용자에게 자연스러운 편집 경험을 제공합니다
[강점] 코드를 모르는 사용자도 IR 수준에서 앱 설계에 참여할 수 있다는 점은 HCI 관점에서 의미 있는 기여이며, 참가자 75%의 선호도가 이를 뒷받침합니다
[강점] GUI Skeleton의 병렬 LLM 호출 설계가 실용적입니다. 각 화면이 독립적이라는 특성을 활용하여 수정 속도를 높인 것은 시스템 설계 측면에서 깔끔한 선택입니다
[한계] 컴파일 오류가 Baseline 대비 약 8배 많다는 점(10.4 vs 1.25)은 생성된 코드의 바로 실행 가능성(out-of-the-box usability)에 제약을 줍니다. 논문은 이를 코드 복잡도 증가의 자연스러운 결과로 해석하지만, 실사용 관점에서는 중요한 병목입니다
[한계] SwiftUI라는 특정 프레임워크에 한정된 평가로, 다른 플랫폼(Android/Kotlin, Flutter, React Native)으로의 일반화 가능성은 논문에서 다루지 않습니다
[한계] 사용자 연구 규모가 제한적이며, '25분 내 프로토타입 생성'이라는 설정은 실제 앱 개발의 복잡도를 충분히 반영하지 못할 수 있습니다
[시사점] '중간 표현으로 LLM의 생성 범위를 좁힌다'는 전략은 코드 생성을 넘어, 문서 작성·디자인 생성 등 다른 복잡한 LLM 작업에도 적용 가능한 범용 패턴을 제시합니다
ATHENA 평균 뷰 6.0개, 코드 353.9줄 (사용자 연구) — User Study 결과, Baseline과의 비교 수치
Baseline 평균 뷰 3.1개, 코드 117.8줄 — User Study, Baseline 조건 결과
기술 평가 평균: 뷰 6.4개, LoC 514.8줄, 컴파일 오류 7.3건 — Technical Evaluation, Table 1
참가자 75% ATHENA 선호 — User Study, 초기 아이디어 구현 태스크 선호도 조사
25분 내 모든 참가자 다중 화면 프로토타입 완성 — User Study, 시간 제한 조건 내 완료율
내비게이션 오류 평균 4.0건 — Technical Evaluation, Table 1
안녕하세요 제이슨입니다!🤗 오늘 다이제스트 어땠나요?
코멘트가 있으시면 저에게 LinkedIn DM으로 알려주세요.
피드백은 향후 양질의 뉴스래터 컨텐츠 퀄리티 향상에 큰 도움이 됩니다! 🙌
최신 논문을 씹고 뜯고 소화하는 PaperGOAT — 🗞️🐐
Greatest of All Time — It’s You🫵
AI 엔지니어 3,000명이 아침마다 여는 논문 브리핑⚡️
유료급 퀄리티, 하지만 무료❗️
최신 AI 논문 요약 뉴스래터를 매일 받아보세요📩