모바일 개발을 위한 LLM 선택 프레임워크: Test-Driven Prompt Engineering의 Android/iOS 적용 | AI Paper Digest

TL;DR Highlight

LLM 코드 생성 모델의 Python 편향을 Android(Java)/iOS(Swift)로 확장하여 각 플랫폼별 최적 모델 선택 기준을 결정 트리로 정리했다.

Who Should Read

모바일 앱 개발에 AI 코드 생성을 도입하려는 Android/iOS 개발자나 팀. GPT-4o vs 오픈소스 모델 선택 기준이 필요한 상황에 특히 유용하다.

Core Mechanics

HumanEval·MBPP 기준 8,704회 평가 — GPT-4o, GPT-4o-mini, Qwen 14B, Qwen 32B 4개 모델을 Android(Java)·iOS(Swift)에서 직접 비교
TDP(Test-Driven Prompting, 테스트 케이스를 프롬프트에 넣어 정답을 유도하는 기법)가 기본 프롬프트 대비 평균 +2.22 pp 정확도 향상
모바일 플랫폼 정확도는 66.85%~88.87%로, Python 코드 생성(86.90%~91.30%)보다 일관되게 낮음 — 모델 크기와 무관
첫 시도 정확도, 예산 제약, 자체 호스팅 여부를 기준으로 모델을 고르는 결정 트리 제공
Remediation Accuracy(틀린 코드를 재시도로 고치는 비율)도 함께 측정해, 실무 워크플로우에 가까운 평가

Evidence

TDP vs 기본 프롬프트: 평균 +2.22 pp (95% CI [1.22–3.23 pp], p < 0.001, Cohen's d = 0.3974)
모바일 최고 정확도 88.87% — Python 최저(86.90%)와 비슷하거나 낮은 수준
544개 프로그래밍 태스크 × 4개 모델 × 2개 플랫폼 × 2개 전략 = 8,704회 평가

How to Apply

코드 생성 프롬프트에 함수 시그니처와 함께 예상 입출력 테스트 케이스를 포함시키면(TDP), 약 2 pp 정확도 향상을 기대할 수 있다.
비용이 중요하다면 GPT-4o 대신 Qwen 32B 자체 호스팅을 검토하고, 첫 시도 정확도가 낮은 태스크에는 Remediation(재시도) 루프를 붙여라.
모바일 코드 생성은 Python보다 품질이 떨어지므로, CI에 유닛 테스트 자동 실행을 연결해 LLM 출력을 무조건 검증하는 파이프라인을 구성하라.

Code Example

snippet

# Test-Driven Prompting 예시 (Swift 함수 생성)
prompt = """
Write a Swift function that reverses a string.

Requirements:
- Function signature: func reverseString(_ s: String) -> String

Test cases (your output must pass all of these):
- reverseString("hello") == "olleh"
- reverseString("") == ""
- reverseString("a") == "a"
- reverseString("Swift") == "tfiwS"

Return only the function implementation.
"""

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": prompt}]
)

Terminology

TDPTest-Driven Prompting. 프롬프트에 '이 입력이면 이 출력이 나와야 해'라는 테스트 케이스를 미리 적어주는 기법. 시험 문제에 예시 답안을 함께 주는 것과 비슷하다.

HumanEvalOpenAI가 만든 코드 생성 벤치마크. 164개의 함수 작성 문제로 구성되며, 생성된 코드가 숨겨진 테스트를 통과하는지로 평가한다.

MBPPGoogle이 만든 코드 생성 벤치마크(Mostly Basic Python Problems). 비전공자가 낸 초급~중급 파이썬 문제 500개로 구성된다.

Remediation Accuracy첫 시도에 실패했을 때 재시도(또는 오류 피드백을 주고 다시 생성)해서 맞힌 비율. 실무에서 LLM을 반복 호출하는 워크플로우와 유사하다.

Cohen's d두 그룹 차이의 실질적 크기를 나타내는 효과 크기(effect size). 0.2는 작은 차이, 0.5는 중간, 0.8 이상은 큰 차이로 본다.

ppPercentage Point(퍼센트 포인트). 85%→87%는 2 pp 상승이지만 약 2.4% 향상이다. 정확도 비교 시 % 와 pp를 혼동하면 안 된다.

관련 논문

Original Abstract (Expand)

Large language model (LLM) code generation research predominantly focuses on Python, with test-driven prompt engineering exclusively targeting this language. This study presents a comprehensive LLM selection framework for mobile development through rigorous empirical analysis. We conducted 8,704 evaluations across 544 programming tasks (HumanEval and MBPP datasets) on Android (Java) and iOS (Swift) platforms using four state-of-the-art LLMs (GPT-4o, GPT-4o-mini, Qwen 14B, and Qwen 32B), two prompting strategies (base and test-driven), and two metrics (accuracy and remediation accuracy). Systematic analysis of platform-specific patterns yielded a decision tree incorporating first-attempt correctness, budget constraints, and self-hosting requirements, validated through three industry-relevant use cases. Results show test-driven prompting (TDP) achieves a +2.22 pp average accuracy improvement over baseline (95% CI [1.22–3.23 pp], p < 0.001, d = 0.3974). However, LLMs consistently underperform in mobile development (66.85%–88.87%) compared to Pythonbased code generation (86.90%–91.30%) regardless of model size or type. This framework establishes groundwork for platform-specific optimizations while providing practitioners with actionable guidance for model selection in mobile development contexts.