[① 어떤 상황에서 AI를 활용했나요?]
아내는 계단을 오르내리기 어렵다. 휠체어를 쓰지는 않지만, 계단이 끼면 그날 외출이 힘들어진다.
그래서 우리 부부의 외식은 늘 가 본 곳 몇 군데를 돌았다. 새로운 데를 가려면
전화를 걸어 "혹시 계단 있나요"를 묻거나, 가서 확인하고 돌아 나와야 했기 때문이다.

지도 앱은 이 질문에 답해 주지 않는다.

· 검색은 맛과 인기로 줄을 세운다. 계단은 항목에 없다.
· "휠체어 가능" 표기가 있긴 한데, 있는 곳이 드물고 없다고 계단이 있는 것도 아니다.
· 블로그 후기는 사진으로 보여 주지만, 그걸 사람이 수십 곳씩 열어 볼 수는 없다.

그래서 문제를 다시 정의했다. 우리 부부에게 이 일은 맛집 고르기이기 전에 동선 문제다.
1층인가, 엘리베이터가 있는가, 주차장에서 입구까지 평지인가, 화장실이 2층은 아닌가,
반 층 단차가 끼지는 않는가. 이걸 후보마다 확인해야 한다.

[② 어떤 AI를 어떻게 활용했나요?]
가. 판정 기준을 먼저 글로 못 박는다

AI에게 "좋은 데 추천해 줘"라고 하지 않는다. 무엇이 좋은 것인지를 내가 먼저 정의한다.

· 판정 기준은 "계단 없는 동선"이다. 1층·엘리베이터·평지 진입·가까운 주차를 우선하고,
2층 화장실, 지하 입구, 반 층 단차가 끼는 경로는 감점한다.
· "휠체어 가능" 표기는 보조 신호로만 쓴다. 계단이 없다는 뜻으로 단정하지 않고
필수 조건으로도 삼지 않는다. 표기가 없는 좋은 곳을 놓치기 때문이다.
· 기본 범위는 집에서 30km. 실내·좌식·느린 관람을 선호한다.

이 기준을 파일로 적어 두고 매번 같이 읽힌다. 대화창에만 말하면 다음에 또 설명해야 한다.

나. 후기를 그대로 믿지 않는 규칙 넷

여기가 이 일의 본체다. AI가 후기를 세게 두면 반드시 틀린다.

1. 출처를 층으로 나눈다. 블로그·카페 검색 결과와 실제 방문자 리뷰를 절대 합산하지 않는다.
결과에 어느 층에서 나온 것인지를 함께 남긴다.
2. 단어가 있다고 세지 않는다. "퍽퍽하다"가 들어간 글이 늘 부정은 아니다.
"퍽퍽함 전혀 없고", "퍽퍽해서 싫어하는 안심마저 촉촉" 같은 문장이 실제로 있었다.
부정 신호에는 원문 링크·게시일·어느 메뉴 이야기인지를 반드시 붙인다.
3. 확인 전 부정은 점수를 깎지 않는다. 검색에서 걸린 부정 신호는 "미확인"으로만 쌓아 두고,
원문을 열어 확인한 뒤에야 "확인됨"으로 올린다.
4. 인기 판단은 최근 3개월 안에서만 한다. 누적 블로그 수는 매장 수와 업력이 만든 숫자여서
지금 사람이 가는지를 말해 주지 않는다. 90일 창을 잡고 그 안에서 새 글이 쌓이는 속도를 본다.
브랜드를 미리 정해 놓고 세지 않고, 그 창에서 실제로 튀어나오는 이름을 먼저 뽑은 뒤 검증한다.

그리고 API로 찾은 것은 후보일 뿐이라고 못 박았고, 영업시간·휴무·접근성·최근 상태는
출발 전에 다시 확인하도록 했다. 검색 API가 확정 영업시간을 주지 않는다.

다. 같은 곳만 다시 권하지 않게 한다

조건에 맞는 곳을 찾아 놔도 추천이 겹치면 결국 가던 데로 돌아간다.
그래서 먹은 것을 날짜와 함께 적어 두고 한동안 후보에서 뺀다(주메뉴 21일·디저트 7일).
집에서 해 먹은 것도 센다. 「먹고 싶다」는 말과 「먹었다」는 사실은 구분해 적는다.

라. 결과를 내기 전에 스스로 실패하게 만든다

기준을 아무리 적어 놔도 다음번엔 또 어기기 때문에, 검사 스크립트를 만들어
결과를 내기 전에 돌린다. 세 가지를 잡는다.

· 근거 없는 부정 카운트가 있는가
· 블로그 글을 방문자 리뷰로 잘못 센 것이 있는가
· 취향 규칙을 너무 넓게 적용한 것이 있는가

하나라도 걸리면 실패로 처리하고 결과를 안 낸다.

위 규칙 가운데 취향을 넓혀 적지 않는다는 것이 특히 중요했다.
아내가 어느 가게의 파블로바가 너무 단단하고 달다고 했는데, 그걸 "단 디저트 전부 감점"으로
넓히면 좋아하는 것까지 사라진다. 규칙은 "단단한 파블로바만 후순위"로 좁혀 적었다.

자료의 출처를 밝힌다

후보와 후기는 네이버 검색 API(NAVER Open API) 로 모았다.
본문에 옮긴 후기 문장은 공개된 블로그 글에서 그대로 따온 것이고,
원자료에는 원문 링크·게시일·어느 메뉴 이야기인지를 건마다 함께 저장해 두었다.
가게 이름은 이 글에서 전부 뺐다 — 부정적인 평가가 실명과 함께 나가면 안 되기 때문이다.

[③ 활용 결과 어떤 변화가 있었나요?]
· 가던 데만 가는 상태에서 벗어났다. 계단 조건을 만족하는 후보를 미리 추려 두니
"가 보고 안 되면 돌아 나오는" 일이 없어졌다.
· 취향이 가게 단위에서 메뉴 단위로 옮겨 갔다. 어느 카페는 쿠키는 맛있는데 커피는 별로였다.
예전 같으면 "그 집은 별로"로 끝났을 것이 지금은 쿠키는 긍정, 커피는 감점으로 나뉘어 남는다.
· 못 먹어 본 이유를 구분하게 됐다. 한우 꽃갈비를 안 먹은 것은 싫어서가 아니다. 값 때문이다.
이걸 "불호"로 적어 두면 영영 후보에서 빠진다. "가격 때문에 미경험"으로 따로 적는다.

[④ 나만의 방식 / 개선 포인트]
하나. 「골라 줘」 대신 「모아 줘」라고 한다.
고르는 기준은 사람이 알고, AI가 잘하는 것은 흩어진 것을 모아 오는 일이다.
광고와 후기가 섞인 곳에서는 이 한 마디가 결과를 완전히 갈라놓는다.

둘. 판정 기준을 먼저 글로 적는다.
"좋은 곳"은 사람마다 달라서, 우리 집에서 좋은 곳은 계단이 없는 곳이 된다.
그걸 파일에 적어 두면 다음에도, 다른 도구에서도 같은 기준으로 찾는다.

셋. 숫자를 셀 때 그 숫자가 무엇으로 만들어졌는지 본다.
누적 리뷰 수가 말해 주는 것은 인기보다 업력에 가깝고, 검색 건수는 품질보다 글쓴이 수에 가깝다.
그래서 창을 좁히고(3개월), 층을 나누고(블로그와 방문자 리뷰), 문맥을 본다.

넷. 규칙을 넓게 적지 않는다.
한 번의 실망을 카테고리 전체로 넓히면 취향이 망가진다.
"파블로바가 단단해서 별로였다"를 "단 디저트 전부 제외"로 바꾸지 않는다.

다섯. 끝나지 않은 일은 끝났다고 쓰지 않는다.
프로젝트 규칙에 아예 한 줄로 박아 두었다 — "진행 중인 조사를 완료된 것처럼 쓰지 않는다."
AI로 정리하면 표가 깔끔해서 결론이 난 것처럼 보이는데, 그 착각이 가장 위험하다.

여섯. 기준을 지키는 일을 사람 기억에 맡기지 않는다.
검사 스크립트가 대신 잡는다. 사람은 반드시 잊는다.

[⑤ 다른 사람도 따라 할 수 있나요?]
가족 중에 거동이 불편한 사람이 있다면 그대로 쓸 수 있다. 코딩을 몰라도 된다.

여기서 코드가 필요한 것은 마지막 검사 한 가지뿐이다. 앞의 것들은 파일 한 장과 날짜 적기로 다 된다.
검사까지 자동으로 하고 싶어지면 AI에게 "이 세 가지를 어겼는지 검사하는 프로그램을 만들어 줘"라고
하면 된다 — 그 프로그램도 내가 짠 게 아니라 AI가 짰다.

1. 판정 기준을 한 문단으로 적는다. "계단 없는 동선", "소리가 크지 않은 곳",
"유아용 의자가 있는 곳" 처럼 우리 집에서 중요한 것을 그대로 쓰면 된다.
그리고 그 문단을 매번 AI에게 같이 준다.
2. AI에게 "추천해 줘" 대신 "이 기준에 맞는 후보를 모아 줘"라고 한다.
3. 후기를 볼 때 세 가지를 나눈다. 어디서 나온 글인가, 어느 메뉴 이야기인가, 언제 글인가.
특히 오래된 글과 새 글을 섞지 않는다.
4. 먹은 날짜를 적는다. 그것만으로 같은 추천이 반복되지 않는다.
5. 확인 못 한 것은 빈칸으로 둔다. AI에게 추측을 시키면 그럴듯하게 채워 넣는다.

이 일은 시간을 아끼려고 시작한 게 아니었다.
아내와 갈 수 있는 곳이 늘어나기를 바랐고, 그러려면 "계단이 있느냐"를 수십 곳에 대해
미리 알아야 했다. 사람이 할 수 없는 양이라 AI에게 맡겼고,
틀리면 안 되는 일이라 믿지 않는 규칙을 함께 붙였다.

다만 여기 쓴 판정은 우리 부부의 취향과 몸 상태에 맞춘 것이라 남에게 그대로 옳지 않다.
접근성 정보는 출발 전에 매장에 다시 확인하는 것을 전제로 쓴다.