AI에게 정답 대신 논리적 허점을 묻는 법 (AI 플레이그라운드 인 서울 회고)

AI 플레이그라운드 인 서울: MacBook으로 생산성 높이기, 4일짜리 AI 앱 프로토타이핑 워크숍에 다녀왔다. 닉네임은 라이너로 참가했고, 국궁장의 실시간 날씨와 혼잡도를 공유하는 앱을 주제로 잡았다.

4일 만에 앱 하나가 나온 것보다, 그 4일 동안 손에 익은 도구들이 계속 남았다. 이 글은 회고라기보다 그 도구들을 다시 꺼내 쓰기 위한 정리다. 나중에 다른 주제로 무언가를 시작할 때 이 문서만 다시 열면 되도록 적어둔다.

#4일 중 코드를 만진 건 절반도 안 된다

먼저 오해를 걷어내고 시작해야겠다. "4일 만에 앱을 만들었다"고 하면 나흘 내내 코드를 짠 것처럼 들리지만, 실제로는 반대였다.

첫날과 둘째날은 코드를 한 줄도 쓰지 않았다. 대신 이런 걸 했다.

• Day 1 — 도전 과제 선정: 빅 아이디어에서 마인드맵을 펼치고, 내 고민 목록에서 주제를 골랐다. 팀을 짜고 Team Agreement를 쓴 뒤 러프한 도전 문장을 만들었다. 내 메모에는 네 개의 후보가 적혀 있다. 논문 참조 자동화, 국궁 기록·날씨 공유, 방학 자격증 커뮤니티, 수면 시간 교정. 그 옆에 이렇게 적어뒀다. "굳이 앱으로?"
• Day 2 — 리파이닝과 유저 리서치: AI를 비판적 코치로 세워 도전 문장의 논리적 허점을 찾고, 문장을 다시 썼다. 그다음 The Mom Test 원칙으로 질문을 설계해 실제 궁사들에게 설문과 인터뷰를 돌렸다.
• Day 3 — UX 원칙과 설계: 시지각 원칙과 HIG를 배우고, 손으로 화면을 그리고, 솔루션 컨셉을 한 문장으로 압축한 뒤 SPEC.md를 쓰기 시작했다.
• Day 4 — 프로토타이핑: 그제야 Xcode를 열었다.

즉 실제로 만든 시간은 이틀이 채 안 된다. 만드는 일이 빨라질수록, 무엇을 만들지 정하는 시간의 비중이 커진다는 걸 일정표가 그대로 보여준다. 그래서 이 글도 순서를 그때 그대로 따라간다.

#1. 도전 과제는 고쳐달라 하지 말고 "논리적 허점"을 물어라

첫날 오후부터 둘째날까지 매달린 일이다. 기획 단계의 프레임워크로는 CBL(Challenge Based Learning) 을 썼다. 정답이 없는 문제에 도전하면서 논리적 허점을 스스로 메워가는 방식이다.

핵심은 한 사이클을 도는 구조다.

여기서 AI를 쓰는 방식이 갈린다. 초안 도전 과제는 대개 '답정너' 다. 내가 이미 답을 정해놓고 문장만 다듬는 것이다. 그래서 AI에게 문장을 고쳐달라고 하면 안 된다.

너는 전문 코치야. 우리 문장을 고쳐주지 말고,
우리가 놓친 논리적 허점이나 모순을
한 번에 하나씩만 질문해 줘.

⚠ "한 번에 하나씩" 이 중요하다. 질문을 몰아서 받으면 답을 정리하다가 사고의 주도권을 넘기게 된다. 하나씩 받아 답하는 동안 내가 직접 허점을 메우게 된다.

실제 사례가 인상적이었다. "점심 메뉴 결정의 번거로움을 줄이자"라는 초안에 AI가 이렇게 되물었다.

메뉴 결정 과정이 매끄러워져도 여전히 참여하지 않는 사람이 있다면, 그건 '메뉴'의 문제일까요, '관계'의 문제일까요?

이 질문 하나로 문제가 '음식 취향 중심 모임'과 '관계 유지 중심 모임'의 분리로 재정의됐다. 보편적인 문제에서 날카로운 문제로 내려온 것이다.

도전 과제를 다듬을 때 쓰는 평가 기준도 네 가지로 정리해뒀다.

• 접근성 — 실제로 인터뷰하고 관찰할 수 있는 대상인가
• 반복성 — 일회성이 아니라 계속 발생하는 경험인가
• 디지털 효용 — 앱이 개입했을 때 가치가 큰가
• 내적 열망 — 10년을 붙잡고 있어도 좋을 만큼 매력적인가

내 주제로 따지면, 국궁은 '취미가 국궁'이라서 고른 게 아니다. 바람과 날씨를 모르고 활터에 갔다가 허탕치고 돌아온 개인적인 짜증이 출발점이었다. 대기업은 거들떠보지 않지만 누군가에게는 반복되는 불편, 그 지점에서 시작해야 한다.

#2. 유저에게는 미래가 아니라 과거를 묻는다

도전 문장을 다듬은 그날 오후에 바로 리서치로 넘어갔다. The Mom Test 원칙을 따랐다. "이런 앱 나오면 쓰실 건가요?"는 최악의 질문이다. 사람들은 예의상 그렇다고 답한다. 물어야 할 것은 의견이 아니라 과거의 구체적 행동이다.

정리해둔 질문 8개와 각각이 알아내려는 것이다.

이 원칙으로 설문을 돌렸더니 숫자가 나왔다. 응답자 32명 기준으로 혼잡도 정보가 방문 계획에 도움이 된다는 항목이 4점 만점에 평균 3.72점, 다른 궁사의 실시간 상태 정보에 관심이 있다는 항목이 3.56점이었다.

숫자보다 유용했던 건 자유 응답이었다. 방문을 접거나 미룬 이유가 반복해서 겹쳤다.

• 갑작스러운 눈·소나기·돌풍
• 사대 만원 여부
• 예상치 못한 타 단체 대관, 인근 활터 행사
• 우천 시 각궁 습사 불가

대처 방식도 구체적이었다. 네이버 날씨를 미리 확인하고, 도로 CCTV로 활터 침수 여부를 직접 확인하고, 밴드 공지를 뒤지고, 개인 기록은 메모장이나 인스타그램 스토리에 남긴다는 응답이 나왔다. 이건 "있으면 좋겠다"가 아니라 이미 하고 있는 행동이다. 만들 것이 뭔지가 여기서 정해졌다.

#3. 사실과 해석을 구분한다

데이터를 모았다고 기획이 되는 건 아니다. 사실(Fact) 과 해석(Insight) 은 다르다.

워크숍에서 든 예시가 오래 기억에 남는다.

• 사실: "엘리베이터가 너무 느리다"는 불평
• 잘못된 대응: 큰돈을 들여 모터를 교체한다
• 해석: 사람들이 괴로워한 건 속도가 아니라 기다리는 시간의 지루함이었다
• 해결: 엘리베이터 앞에 거울을 단다

또 하나. "사용자가 공지를 읽지 않는 것은 정보가 부족해서가 아니라, 그것이 '나에게 온 것'이라는 인지가 없기 때문"이라는 해석. 여기서 문제와 기회가 갈린다.

• 문제: 전체 공지는 누구에게도 보낸 것이 아니라 아무도 반응하지 않는다
• 기회: 이름을 콕 집어 개인화하면 즉각 반응이 온다

파편화된 인터뷰 결과는 어피니티 다이어그램으로 비슷한 것끼리 묶어 상위 개념을 뽑는다. AI에게 요약을 시킬 때도 그냥 "정리해줘"가 아니라 분석 기준(행동 패턴, 심리적 동기)을 지정해야 쓸 만한 게 나온다.

마지막으로 기능과 컨셉의 구분.

내 목표 문장은 이렇게 정리됐다. "국궁장별 실시간 날씨와 혼잡도 정보를 공유하여, 궁사들이 활터로 가기 전 허탕을 방지하고 쾌적한 활쏘기 경험을 누리도록 돕는다." 기능 목록이 아니라 한 문장이다. 이후 모든 결정을 이 문장에 비춰 판단했다.

#4. UI는 예쁨이 아니라 인지 부하 관리다

디자인 세션의 전제가 명쾌했다. 좋은 디자인은 예쁜 게 아니라 뇌의 인지 부하를 줄이는 것이다. 불규칙하게 흩어진 요소는 뇌가 개별 좌표를 일일이 연산해야 해서 비용이 크고, 그룹으로 묶인 구조는 한 덩어리로 인식돼 비용이 싸다.

모바일에서 바로 쓸 체크리스트 네 가지다.

대조의 사례로 든 것이 좋았다. 웹툰 앱에서 읽은 회차는 투명도를 낮추고 안 읽은 회차는 선명하게 두는 처리. 사용자는 아무 설명 없이도 다음에 볼 것을 안다.

그리고 HIG(Human Interface Guidelines)를 AI와 쓰는 법. ⚠ "HIG에 맞게 고쳐줘"는 대체로 실패한다. 추상적인 지시라 AI가 스스로 적용하지 못한다. 대신 이렇게 한다.

1. Apple Developer 문서에서 해당 규칙 페이지를 찾아 링크나 텍스트로 직접 제공한다
2. "내 스케치가 이 기준에 맞는지 분석해줘"처럼 판단 대상을 특정한다
3. 평소 좋다고 느낀 앱을 캡처해 같은 기준으로 분석시켜 기준 자체를 학습한다

규칙을 아는 사람이 규칙을 떠먹여줄 때 AI가 제 역할을 한다. 나는 SPEC에도 "UI 하나당 HIG 조건을 최소 하나 이상 만족" 이라는 문장을 못박아 뒀다.

#5. 손그림이 프롬프트보다 정확하다

셋째 날이 되어서야 처음으로 화면을 그렸다. 여기서 몸으로 익힌 것이 로우파이(low-fidelity) 스케치의 효용이다.

말로 화면을 설명하면 듣는 쪽이 다른 그림을 떠올린다. 사람도 그렇고 AI는 더하다. 거친 스케치라도 시각적 실체가 있으면 소통 정확도가 확 올라간다. 워크숍에서는 이걸 "토큰의 효용" 이라고 표현했는데, 실제로 그렇다. 문장 열 줄로 설명할 레이아웃을 이미지 한 장이 대신한다.

로우파이에는 두 가지 워밍업이 따라온다.

• 꼬부랑 새 그리기 — 아무 의미 없는 구불구불한 선을 먼저 긋고, 거기에 부리와 다리를 붙여 새를 만든다. "그림 못 그린다"는 심리적 장벽을 깨는 용도다. 제한된 형태 안에서 목적을 향해 가는 과정이라, 모바일 화면이라는 제약 안에서 UI를 짜는 일과 구조가 같다.
• 4-up 스케치 — 화면 하나당 1분. 시간 제한이 핵심이다. 논리적 검열이 작동할 틈을 주지 않아야 발산이 된다.

📌 실전에서 중요한 건 스케치를 어디에 쓰느냐다. 나는 그림을 그대로 SPEC 문서에 첨부하고, 이런 규칙을 함께 적었다.

- [UI이미지1: IMG_3167.jpeg] 홈/국궁장 탐색 화면
  — 포함 요소: 현재 위치 중심 지도, 국궁장 마커, 검색,
    선택한 국궁장 요약 카드, 홈·제보/기록·MY 하단 탭

각 화면의 UI 이미지를 첨부할 거야.
이미지가 없거나 설명과 다르면 아래 텍스트 설명을 우선해줘.

"이미지와 설명이 다르면 텍스트를 우선" 이 한 줄이 생각보다 많이 쓰인다. 스케치는 부정확할 수밖에 없고, AI는 그 부정확함까지 충실히 구현하려 든다. 우선순위를 미리 정해두면 그 혼선이 사라진다.

#6. SPEC.md — 코딩 전에 채우는 7개 칸

가장 오래 남은 자산은 이것이다. 코딩 전에 문서를 하나 쓰는데, 이 문서가 AI의 가이드레일 역할을 한다. 환각을 줄이고 프로젝트 전체의 일관성을 유지한다.

내가 실제로 쓴 템플릿이다. 빈칸을 채우면서 기획이 정리되는 구조라 그대로 옮겨둔다.

"___" 앱 **___(앱 이름)**의 SPEC 문서를 만들 거야.

## 진행 방식
- 너랑 논의하면서 1~3번을 보완하고 4~7번을 채워 넣을 거야.
- 한 번에 한 섹션씩만 논의해줘. 질문은 몰아서 하지 말고 하나씩 해줘.
- 이미 작성된 내용도 확정된 것으로 간주하지 말고 필요한 부분을 질문해줘.
- 4(사용 기술), 6(확인 시나리오), 7(완성 기준)은 네가 먼저 제안하고,
  내가 승인하거나 수정하는 방식으로 진행하자.

## 내 개발 환경 / 사전 지식
- Xcode 최신 버전, SwiftUI 사용
- 실기기 테스트: 가능 / 불가능
- Swift 경험: 처음 / 기초 문법만 앎

## SPEC 초안

### 1. 앱 설명
- 개요: ___ (누가, 어떤 상황에서, 무엇을 하는 앱인지 한두 문장)
- 타겟 사용자: ___
- 핵심 기능: ___ (○○하고 → ○○한 뒤 → ○○한다)

### 2. 화면 구성
- [UI이미지1] ___ 화면 — 포함 요소: ___
- [UI이미지2] ___ 화면 — 포함 요소: ___
화면 흐름: ___ → ___ → ___ (마지막 화면 이후 어디로 돌아가는지도)

### 3. 기능 목록
- ___ (사용자 행동과 앱의 반응을 한 줄씩)
- ___ (중간에 취소·포기하면 어떻게 되는지)
- ___ (권한 거부나 오류가 나면 어떻게 되는지)

### 4. 사용 기술        (함께 논의하며 채우기)
### 5. 개발 계획        (함께 논의하며 채우기)
### 6. 확인 시나리오    (AI 제안 → 내가 확정)
### 7. 완성 기준        (AI 제안 → 내가 확정)

이 템플릿에서 실제로 효과가 컸던 부분을 꼽으면 세 가지다.

1) 취소와 오류를 기능 목록에 강제로 넣는다. 정상 흐름만 적으면 AI도 정상 흐름만 만든다. "제보 도중 취소하면 저장하지 않고 이전 화면으로 돌아간다", "위치 권한을 거부해도 기본 지역 지도를 보여준다" 같은 줄이 처음부터 있어야 한다.

2) 내 실력을 먼저 밝힌다. "Swift 기초 문법만 앎"을 적어두면 설명의 밀도가 달라진다. 코드만 던지지 않고 단계마다 개념을 짚어준다.

3) 4·6·7은 AI가 먼저 제안하게 한다. 기술 선택, 확인 시나리오, 완성 기준은 내가 잘 모르는 영역이다. 대신 제안을 받고 승인권은 내가 쥔다. 이게 워크숍에서 말한 '핸들을 잡는 개발'이다. 매 단계 결과를 확인하고 오케이를 줘야 다음으로 넘어간다.

여기에 프로젝트 최상위의 에이전트 규칙 파일(CLAUDE.md 같은)을 더하면 통제가 완성된다. UI 프레임워크 강제, 코드 생성 전 로직 설명 의무화 같은 것들이다. 이 방식은 Claude Code 하네스로 개인 프로젝트 운영하기에 더 자세히 적었다.

#7. 4일 뒤

회고는 짧게 적는다.

마지막 날에는 Apple Developer Academy — AI Literacy 과정 수료증을 받았다. 나흘 내내 붙어 있던 팀들이 각자 만든 걸 들고 나와 시연하고, 그 자리에서 받아 든 종이다.

워크숍의 SPEC에는 "2일 8시간, 단계당 5분 제한" 같은 조건이 있었다. 지금은 그 제한을 지웠다. 기능 하나를 충분히 구현하고 자동화 테스트와 실행 확인까지 끝낸 뒤 다음으로 넘어가는 방식으로 바꿨다.

그렇게 계속 붙잡고 있으니 범위가 이렇게 늘었다.

• iOS: SwiftUI, iOS 17 이상, 지도·상세·제보·기록·MY
• 서버: 로컬 Docker Compose에서 실제로 구동
• 관리자 웹: 국궁장 정보와 공지 관리
• 계약: OpenAPI 3.0으로 서버·iOS·웹 타입을 함께 생성 — 이 구조는 OpenAPI-first 모노레포의 서브모듈 워크플로우에 정리해뒀다
• 배포: TestFlight 내부 테스트까지

손그림 6장 중 습사 기록 화면들은 MVP에서 뺐다. 대신 "나중에 구현할 후보" 목록으로 SPEC에 남겨뒀다. 개인 습사 기록, 디지털 등정부, 활터 행사 일정 같은 것들이다. 잘라낸 걸 어디에 적어두느냐도 문서의 일이다.

4일 동안 가장 많이 들은 말은 이거였다.

AI로 만들 수 있으면 다른 사람도 만들 수 있다. 차별점은 결국 경험과 취향이다.

맞는 말이라고 생각한다. 활터에서 허탕치고 돌아온 경험은 검색으로 나오지 않는다.

#정리 — 다음에 다시 시작할 때 볼 체크리스트

• 주제는 내가 실제로 겪은 반복되는 불편에서 고른다. 접근성·반복성·디지털 효용·내적 열망으로 걸러낸다.
• AI에게 문장을 고쳐달라 하지 말고 논리적 허점을 한 번에 하나씩 물어보게 한다.
• 유저에게는 미래 의향이 아니라 과거의 구체적 행동을 묻는다.
• 데이터를 모았으면 사실과 해석을 분리하고, 기능이 아니라 한 문장짜리 컨셉으로 압축한다.
• 화면은 1분짜리 스케치로 먼저 그린다. 그림은 결과물이 아니라 넘길 맥락이다.
• 코딩 전에 SPEC 7칸을 채운다. 취소·오류를 반드시 포함하고, 기술·시나리오·완성 기준은 제안받되 승인은 내가 한다.

#참고링크

• The Mom Test — 공식 사이트
• Apple Human Interface Guidelines
• Challenge Based Learning 프레임워크