직접 해본 AI 실전 기록
- 사람이 판단하고 AI가 만들었다 — 감독과 스태프 (LLM 중계기 개발기)
LLM 중계기 개발기의 마지막 편입니다. 7월 13일부터 10월 1일까지 쌓인 저장 기록 394개를 주별로 펼치고, AI 코딩 도우미가 공동 작성자로 이름을 올린 기록이 얼마나 되는지, 시험과 릴리스 노트가 어떻게 늘었는지 세어 봤어요. AI는 코드·시험·릴리스 노트·저장 메모를 썼고, 사람은 무엇을 만들고 뺄지 정하고, AI의 '고쳤다'를 실제 환경에서 확인하고, 직접 재고, 지킬 규칙을 정했다는 것을 기록으로 정리합니다. 1편의 세 질문에 답하고, 아직 계획인 다음 단계와 연재 전체 목차로 마무리해요.
- 가짜는 진짜를 대신 못 한다 — 모의고사와 실전 (LLM 중계기 개발기)
LLM 중계기의 자동 시험은 대부분 진짜 AI 대신 흉내만 내는 가짜를 상대로 합니다. 빠르고, 늘 같은 결과가 나오고, 고장을 일부러 만들 수 있어서예요. 그런데 가짜는 내가 아는 만큼만 진짜를 닮습니다. 최신 Codex만 흉내 낸 가짜 탓에 옛 판 Codex의 거절을 몰랐던 날, 개발 폴더에서 띄운 중계기로만 시험해 배포판에서 빠진 변경 이력을 몰랐던 일주일, 그리고 그 뒤에 만든 윈도 실전 점검과 실제 AI 점검까지. '가짜는 매번, 진짜는 내놓기 전에 적어도 한 번'이라는 균형을 비개발자 눈높이로 정리했습니다.
- 검사는 지우지 않는다 — 사고 다발 교차로의 신호등 (LLM 중계기 개발기)
LLM 중계기는 고장 하나를 고칠 때마다 같은 고장을 다시 잡는 자동 검사를 하나씩 세웠습니다. 첫 버전이 나오고 이틀이 채 안 돼 시험을 돌릴 때마다 먼저 도는 검사·시험이 13개가 됐고, 한 번 돌리는 데 18초쯤 걸리자 기록은 '매번 18초를 물리면 시험을 안 돌리게 된다'고 적었어요. 하나도 지우지 않고 커밋 전의 빠른 핵심 검사 5종과 새 판 전의 전체 검사로 나눈 이야기, 코드가 옮겨 가면 검사도 옮겨 단 사례, 검사가 정말 무는지 일부러 고장을 넣어 확인하는 방법을 비개발자 눈높이로 정리했습니다.
- AI가 허락을 기다리다 멈췄다 — 결재 도장을 기다리는 서류 (LLM 중계기 개발기)
Claude Code와 Codex 같은 코딩 AI는 명령을 실행하거나 파일을 고치기 전에 사람에게 '해도 될까요?'라고 묻습니다. 제가 만든 LLM 중계기에 이 AI들이 내 폴더에서 일하게 하는 '작업 폴더 모드'를 붙였더니, 중계기가 그 질문을 아무에게도 전하지 않고 조용히 버리는 바람에 AI가 대답을 기다리며 멈췄어요. 5분 뒤 시간 초과로 끝난 증상, 원인, 어떤 질문에도 반드시 답하게 한 첫 고침, 사람 화면에 승인 벨을 울리는 두 번째 고침, 폴더마다 고르는 세 가지 규칙(물어보기·자동 허용·거절), 그리고 AI에게 파일을 맡길 때의 안전장치를 비개발자 눈높이로 정리했습니다.
- 생각하지 않고 고르기만 하는 창구 — 객관식에 서술형 답을 쓴 학생 (LLM 중계기 개발기)
제가 만든 LLM 중계기에는 답이 정해진 보기 안에서만 나오는 질문(분류, 갈림길, 다음 행동 고르기)만 받는 '판정 창구'가 있습니다. 고르기 전용 AI인 Jev가 없을 때는 글을 쓰는 보통 AI가 같은 답안 형식을 흉내 내는데, 첫 흉내는 AI에게 보기마다 확률을 하나씩 다 쓰게 했어요. 글 쓰는 AI는 한 글자씩 쓰니 쓸 게 많을수록 느리고, 그 확률은 애초에 '믿지 말라'고 표시해 둔 숫자였죠. AI는 고른 답과 확신도 하나만 쓰고 나머지 확률은 중계기가 채우게 바꾼 해결, 같은 AI라면 창구만 바꿔서는 빨라지지 않는 이유, 공정한 A/B 비교를 위해 데모를 고친 이야기를 비개발자 눈높이로 정리했습니다.
- 지식을 넣었더니 지적이 사라졌다 — 참고서를 줬더니 답안이 짧아졌다 (LLM 중계기 개발기)
AI 코드 리뷰어에게 프로젝트 지식을 더 넣어 주면 문제를 더 잘 찾아낼까요? 같은 코드 변경과 같은 AI로 넣어 주는 자료만 바꿔 재 보니 반대였습니다. 지식 카드를 넣은 구성은 심판이 인정한 지적이 3건에서 0건으로 줄었고, 틀린 지적이 늘어난 게 아니라 AI가 아예 입을 다물었어요. 주변 코드는 입력만 늘고 결과는 그대로였고, 지식이 가장 필요해 보이는 관점 하나에만 좁혀 넣어도 손해였습니다. 컨텍스트 주입, 정답셋, 심판 검증이 무엇인지와 '좋아진다는 걸 증명하기 전엔 넣지 않는다'는 규칙을 비개발자 눈높이로 정리했습니다.
- AI끼리 코드리뷰 대결 — 여러 심사위원의 교차 채점 (LLM 중계기 개발기)
노래 경연의 심사위원은 혼자 점수를 매기지 않죠. 여럿이 따로 채점한 뒤 채점표를 맞춰 봅니다. 제가 만든 LLM 중계기를 처음부터 써 온 '코드 리뷰 대결 도구'도 그렇게 일해요. 바뀐 코드를 조각으로 나누고, 사용자 치명 문제·실행 중 멈춤·호환성·동시성 같은 일곱 가지 관점을 여러 AI에게 나눠 맡긴 뒤, 같은 지적을 몇이 찾았는지와 다른 AI가 동의하는지로 믿을 만한 정도를 매겨 한 장의 보고서로 합칩니다. 보스·파이터·장비로 그린 게임 같은 화면 뒤의 구조, 걸러 내던 심판이 표시하는 심판으로 바뀐 이유, 그리고 중계기가 맡은 일 — 한 창구, 같은 출발선의 묶음 요청, 스펙 카드로 정하는 조각 크기 — 를 비개발자 눈높이로 정리했습니다.
- 한 질문, 여러 AI의 답 — 같은 문제를 여러 과외 선생님에게 (LLM 중계기 개발기)
제가 만든 LLM 중계기의 관리 화면에는 질문 하나를 여러 AI에게 동시에 보내고 답을 카드로 나란히 받아 보는 '병렬 채팅'이 있습니다. 답을 나란히 놓으면 비교가 쉽고, 엇갈리는 답이 다시 확인할 곳을 알려 주죠. 그런데 Codex 모델 네 개를 고르면, 중계기가 한가할 때도 '잠깐 붐빈다(429), 1초 뒤 다시'라는 거절만 돌아왔어요. 동시에 3개까지만 달리는 Codex에 '다 같이 아니면 아무도'인 묶음 요청을 보냈기 때문입니다. 모델마다 따로 보내 넷째는 줄을 서게 한 해결, 그리고 '잠깐 붐빔(429)'과 '이대로는 불가능(400)'을 나눠 알려야 끝없는 재시도를 막을 수 있는 이유를 비개발자 눈높이로 정리했습니다.
- 무거운 껍데기를 걷어내다 — 대형 SUV에서 경차로 (LLM 중계기 개발기)
화면 구석의 작은 앱이던 LLM 중계기는 앱 껍데기(Electron) 안에 웹 브라우저 한 벌을 통째로 싣고 다녔습니다. 재 보니 329MB 가운데 274MB가 껍데기 몫이었어요. 서버는 다시 짜지 않고 브라우저만 걷어내 이미 깔린 브라우저의 '앱 모드'를 빌려 쓰고(61MB), 이틀 뒤 작은 트레이 프로그램으로 바꿔 윈도용 압축 파일을 112MB에서 41.6MB로 줄인 이야기. 브라우저를 빌려 쓰는 값, 그리고 끄는 방식과 검사를 그대로 옮긴 이유까지 비개발자 눈높이로 정리했습니다.
- 조용한 업데이트는 멈춘 줄 안다 — 층 표시 없는 엘리베이터 (LLM 중계기 개발기)
LLM 중계기의 자동 업데이트는 트레이 아이콘이 사라진 뒤 설치 프로그램이 창 하나 없이 돌았습니다. 몇 초, 어떤 컴퓨터에서는 수십 초 동안 아무것도 보이지 않자 '중단된 줄 알았다'는 피드백이 돌아왔어요. 설치 프로그램을 '아주 조용히'에서 '조용히'로 바꿔 진행률 바 창 하나를 띄운 이야기, 알림은 숨겨질 수 있지만 창은 남는다는 점, 고친 효과가 다음 업데이트부터 나타나는 함정, 그 전에 연결 확인 카드·멈춘 스피너·트레이 아이콘에서 배운 같은 교훈까지 비개발자 눈높이로 정리했습니다.
- 자동 업데이트가 계속 되돌아간 이유 — 깨어나기도 전에 끝난 건강검진 (LLM 중계기 개발기)
LLM 중계기의 자동 업데이트가 어떤 컴퓨터에서는 하고 나도 버전이 그대로였습니다. 옛 판이 남긴 업데이트 도우미가 새 판이 30초 안에 대답하는지 지켜봤는데, 새 판은 처음 켜질 때 파일 5천8백여 개를 푸느라 몇 분이 걸렸고, 도우미는 이를 실패로 판정해 조용히 되돌렸거든요. 판정하는 쪽이 옛 판이라 고친 판조차 도착하지 못한 '부트스트랩' 함정, 판정 시간을 5분으로 늘리고 되돌림을 알리게 한 응급 처치, 파일을 다 펼쳐 까는 설치 프로그램으로 갈아탄 결말을 비개발자 눈높이로 정리했습니다.
- '준비 중'이 끝나지 않는 화면 — 영원히 '조리 중'인 주문 번호판 (LLM 중계기 개발기)
AI 연결도 끝났고 채팅도 잘 되는데, LLM 중계기 화면의 준비 표시는 '워밍업 중'에서 영영 넘어가지 않았습니다. 첫 번째는 준비에 실패한 모델이 갈 '끝'이 없어서, 두 번째는 아무도 데우지 않는 모델까지 '워밍업 중'이라고 보고해서였어요. 카페 주문 번호판에 빗대어 상태와 끝 상태가 무엇인지, 실패와 시간 초과도 끝으로 쳐야 하는 이유, 진행 중인 일이 없으면 '준비 전'이라고 정직하게 말해야 하는 이유, 같은 병이 업데이트 '적용 중'에서 다시 나타난 이야기까지 비개발자 눈높이로 정리했습니다.
- 끄는 것도 기술이다 — 퇴근했는데 사무실 불이 켜져 있다 (LLM 중계기 개발기)
LLM 중계기를 껐는데, 중계기가 띄워 둔 Codex 앱 서버가 뒤에 혼자 살아남아 문 번호(포트)를 붙들고 있었습니다. 다음 실행은 실패했고, 안내 창은 작업 관리자를 열라고 했어요. 부모·자식·고아 프로세스가 무엇인지, 첫날 밤 '고쳤다'던 기록이 다음 날 '틀렸다'로 바뀐 이유(창 X 닫기는 정리 코드를 부르지 않는 다른 길이었다), 그 뒤에 더한 안전망까지 비개발자 눈높이로 정리했습니다.
- 맥에서 되는데 윈도에서 안 되는 이유 — D:를 인터넷 주소로 착각한 날 (LLM 중계기 개발기)
맥에서 만들어 잘 돌던 LLM 중계기가 실제로 쓸 윈도 컴퓨터에서는 켜자마자 꺼졌습니다. 윈도 파일 위치 맨 앞의 'D:'를 'https:' 같은 인터넷 주소의 앞머리로 읽었기 때문이에요. 파일 위치와 주소가 어떻게 다른지, 왜 맥에서는 몰랐는지, 같은 날 이어진 '같은 코드, 다른 컴퓨터' 고장 세 가지(부품 목록 다툼·'미설치' 오판·맥에서 싼 윈도용 짐)와 그때 붙인 검사, 그리고 '쓸 컴퓨터에서 시험한다'는 교훈을 비개발자 눈높이로 정리했습니다.
- 한국어는 토큰을 더 먹는다 — 같은 짐도 포장 단위가 다르다 (LLM 중계기 개발기)
AI는 글을 글자가 아니라 토큰이라는 상자로 셉니다. 제가 만든 LLM 중계기의 설명서에 적어 둔 어림값으로 영어는 약 3.0자에 1토큰, 한국어와 기호는 약 1.1자에 1토큰이라, 같은 3,000자라도 한국어는 영어의 2.7배쯤 되는 토큰을 씁니다. 글자 수로 잡은 '안전해 보이던' 분량이 실제로는 두 배가 넘는 토큰이어서 번번이 넘쳤던 일, 그 일로 중계기 첫날 설명서에 남은 '여기서 크게 데였다'는 절, 중계기 안에서도 용도마다 다르게 쓰는 세 가지 자, 그리고 긴 한국어 문서를 AI에 나눠 줄 때의 계산법을 비개발자 눈높이로 정리했습니다.
- 에러 메시지를 자르지 마라 — 블랙박스 영상의 앞부분만 남겼을 때 (LLM 중계기 개발기)
AI가 요청을 거절하면 이유를 글로 적어 보냅니다. 그런데 제가 만든 LLM 중계기는 개발 첫 이틀 동안 그 이유를 세 번이나 잃어버렸어요. 화면에 200자만 보여 준 날, 양식이 아니라며 원문을 통째로 버리고 'HTTP 400'만 남긴 날, 기록에 160자만 남겨 '더 새 버전이 필요하다'는 안내가 잘린 날. 세 번의 경위와 그 뒤 정한 '오류 원문은 자르지 않는다'는 규칙, 자르는 코드가 다시 들어오면 실패하는 자동 검사를 비개발자 눈높이로 정리했습니다.
- 성공 응답 속에 숨은 실패 — 합격 봉투 안에 든 불합격 통지 (LLM 중계기 개발기)
Claude가 로그인 만료와 사용 한도 소진을 '성공' 결과에 담아 보낸 날이 두 번 있었습니다. 제가 만든 LLM 중계기는 그 안내문을 진짜 답처럼 넘겼고, 중계기를 쓰던 도구는 엉뚱하게 '답 형식이 틀렸다'며 실패했어요. 중계기가 성공 답을 넘기기 전에 열어 보고 로그인 만료는 인증 실패(401) 갈래로, 한도 소진은 429와 '10분 뒤 다시'로 바꿔 돌려주게 된 경위, 글자를 읽어 판단하는 검사의 약점과 그 울타리(Claude에게만, 성공 답에만, 한도 문구는 600자 이하에만)를 비개발자 눈높이로 정리했습니다.
- '다 했어요'라더니 잘린 답 — 영수증엔 완납, 물건은 반만 (LLM 중계기 개발기)
AI의 답장 끝에는 왜 멈췄는지를 적는 '끝난 이유' 칸이 있습니다. 여기에 '다 했음'이 찍히면 프로그램은 잘린 답도 완성본으로 저장해요. 제가 만든 LLM 중계기가 이 칸을 바로잡기까지의 경위 — 둘째 날의 첫 수정, 34분 뒤의 두 번째 수정, 일주일 뒤에야 드러난 '말 없는 AI' 문제 — 와 AI마다 다른 '끝'의 말투, 직접 재서 추정하는 방법, 스펙 카드의 '믿어도 되는지' 표시, 쓰는 쪽 프로그램의 점검표를 비개발자 눈높이로 정리했습니다.
- 생각만 하다 답을 못 한 AI — 연료를 예열에 다 써 버린 자동차 (LLM 중계기 개발기)
답하기 전에 속으로 생각하는 AI는 그 생각도 '답에 쓸 수 있는 글자 예산'에서 꺼내 씁니다. 제가 만든 LLM 중계기에서 생각형 AI 하나가 답 예산 8,192토큰을 생각에 전부 써 버려, 생각 33,748자에 답 0자로 돌아온 날이 있었어요. 원인을 따라가 보니 예산은 조심스럽게 작게 잡혀 있었고, 생각이 얼마나 길어질지는 미리 적어 둔 표로 알 수 없었습니다. 실제 생각 분량을 배우고, 답 몫 위에 생각 여유분을 얹고, 그래도 비면 예산을 두 배로 늘려 한 번 더 시도하고, 답에 섞여 오는 생각 꼬리표를 떼어 내는 4겹 방어를 비개발자 눈높이로 정리했습니다.
- '저는 Claude예요'라고 말한 다른 AI — 공용 메모장을 같이 쓴 두 팀 (LLM 중계기 개발기)
켜 둔 AI 세션 하나를 서로 다른 두 프로그램이 같이 쓰면, 한 프로그램의 대화가 다른 프로그램 요청을 받는 AI의 기억에 남을 수 있습니다. 게다가 대화를 한 덩어리로 합칠 때 '누가 한 말인지' 이름표를 빼 버리자, AI가 다른 AI의 답('저는 Claude입니다')을 자기 말로 받아들이기도 했어요. 공용 메모장을 같이 쓴 두 팀에 빗대어, 두 증상이 모두 '누가'를 잃어버린 데서 왔다는 원인, 프로그램 이름표·프로그램별 세션·요청마다 새 대화방·말마다 이름표라는 해결, '세션은 속도를 위한 준비물'이라는 원칙을 비개발자 눈높이로 정리했습니다.
- 설정 한 줄 빠졌을 뿐인데 전멸 — 이름표 없는 손님은 맨 뒤로 (LLM 중계기 개발기)
새로 붙인 명령어 도구 AI 하나가 '연결 성공'으로 떴는데, 그 뒤 호출은 전부 실패했습니다. AI는 멀쩡했어요. 원인은 중계기의 교통정리 칸에 이 AI의 차선 설정 한 줄이 빠져, 오류 없이 전체 기본값(차선 1개·줄에서 60초)으로 떨어진 것이었습니다. 한 번 부르는 데 1분 가까이 걸리는 AI에게 60초 줄은 너무 짧았고, '연결 확인을 다시 하라'는 실패 안내가 줄을 더 막는 고리까지 만들었어요. 조용한 기본값의 함정, 스스로 불어나는 대기 고리, 부품 시험은 통과했는데 조립품에서 터진 이유, 그리고 '새 AI는 등록 한 줄'이라는 규칙에 붙은 두 번째 줄을 비개발자 눈높이로 정리했습니다.
- 1분에 몇 번까지 부를 수 있나 — 은행 창구 번호표처럼 간격을 두는 페이서 (LLM 중계기 개발기)
AI 서비스에는 '동시에 몇 건' 말고도 '1분에 몇 번(RPM)', '1분에 토큰 몇 개(TPM)'라는 한도가 있습니다. 넘으면 429라는 거절 번호와 함께 '이만큼 뒤에 다시 오라(Retry-After)'는 안내가 오죠. 제가 만든 LLM 중계기에는 거절당하고 다시 보내는 대신 처음부터 간격을 두고 보내는 '페이서'가 있어요. 최근 1분의 기록을 보며 요청 시작 시각을 고르게 띄우는 방법, 토큰을 미리 잡아 두고 끝나면 고쳐 적는 장부, NVIDIA에는 페이서를 붙이지 않은 이유, 그리고 Gemini API로 본 '잠깐 붐빔'과 '오늘 몫을 다 씀'의 차이를 비개발자 눈높이로 정리했습니다.
- 전화를 끊었는데 상담원은 계속 대기 중 — 취소 신호를 끝까지 전하는 법 (LLM 중계기 개발기)
고객은 전화를 끊었는데 상담원의 수화기에는 그 소식이 오지 않으면, 상담원은 빈 수화기를 든 채 '통화 중'으로 남고 다음 고객은 연결되지 못합니다. 제가 만든 LLM 중계기에도 같은 함정이 있어요. 프로그램이 연결을 끊었을 때 '그만' 신호를 창구 → 줄 → 어댑터 → AI까지 끝까지 전해야 하는 이유, 신호가 한 곳에서 끊기면 AI 차선이 영원히 막히는 구조, 내 컴퓨터에서 돌리는 AI(LM Studio)의 '유령 줄', 15초 안부 신호와 느린 받는 쪽 처리, 그리고 '그만두는 법'을 먼저 설계하라는 교훈을 비개발자 눈높이로 정리했습니다.
- 중계기에 톨게이트가 필요한 이유 — 차선 수가 다른 고속도로 요금소 (LLM 중계기 개발기)
AI마다 한꺼번에 받을 수 있는 질문 수가 정해져 있어서, 들어오는 대로 넘기기만 하는 중계기는 금방 막히거나 '너무 많다(429)'는 거절을 받습니다. 제가 만든 LLM 중계기 한가운데에는 그래서 요금소 같은 교통정리 칸이 있어요. AI별·모델별 차선(Codex 3, Claude 3, NVIDIA 4, LM Studio 1), 길이와 시간이 정해진 대기 줄, 전체 상한(동시 10건·줄 포함 16건), 꽉 찼을 때 매달아 두지 않고 이유와 다시 올 시간을 알려 주는 방식, 사람이 기다리는 요청을 먼저 들여보내는 순서까지 비개발자 눈높이로 정리했습니다.
- 모델마다 다른 스펙을 카드로 — 가전제품 에너지 라벨처럼 고르기 (LLM 중계기 개발기)
냉장고를 고를 때는 옆면의 라벨을 나란히 놓고 비교하죠. 제가 만든 LLM 중계기의 메뉴판에는 처음에 모델 이름만 있어서, 쓰는 쪽 프로그램은 모델마다 한 번에 얼마나 읽는지, '끝났다'는 표시를 믿어도 되는지, 생각하느라 답 분량을 얼마나 쓰는지 알 수 없었어요. 이걸 프로그램이 읽는 스펙 카드로 내놓은 이야기입니다. 글을 잘게만 쪼개 보내던 도구 때문에 카드가 생긴 날, 양식이 어긋나 빈칸만 보이던 카드를 같은 날 아침에 고친 일, 그리고 '모르면 비워 둔다'는 규칙까지 비개발자 눈높이로 정리했습니다.
- 로그인했는데 401 — 서랍 속 옛 열쇠가 문을 막다 (LLM 중계기 개발기)
Claude 명령어 도구에 로그인해 둔 컴퓨터에서, 중계기가 Claude를 부르면 401(인증 실패)이 돌아왔습니다. 원인은 컴퓨터 전체에 붙어 있는 설정인 환경 변수에 남아 있던 API 키였어요. Claude가 로그인보다 그 키를 먼저 썼거든요. 환경 변수가 무엇인지, 중계기가 Claude에게 건네는 설정 사본에서 그 키만 지워 로그인을 쓰게 한 방법, 어떤 열쇠를 썼는지 알려 주는 안내와 401·403·429의 차이를 비개발자 눈높이로 정리했습니다.
- AI가 엉뚱한 메모를 읽고 왔다 — 빈 책상이 필요했던 이유 (LLM 중계기 개발기)
Codex와 Claude의 명령어 도구는 켜진 폴더의 안내문과 기억을 먼저 읽고 일을 시작합니다. 코딩할 때는 고마운 기능인데, 제가 만든 중계기가 이 AI들을 자기 폴더에서 켜는 바람에 평범한 채팅 질문에도 중계기 개발 메모가 덤으로 실렸어요. 같은 질문인데 켠 폴더에 따라 답이 달라진 증상, 원인, 아무것도 없는 전용 폴더로 자리를 옮긴 해결, 그리고 '채팅은 빈 책상, 일은 내가 고른 폴더'라는 규칙을 비개발자 눈높이로 정리했습니다.
- OpenAI dots(닷츠) 발표 — 내 대신 쉬지 않고 일하는 AI 'dot', 무엇을 혼자 하고 무엇을 물어보나
2026년 9월 29일 OpenAI가 DevDay에서 'dots'를 발표했다. GPT-6 Astra로 움직이는 상시 작동 에이전트로, 각자 클라우드 컴퓨터를 갖고 사용자가 연결한 앱에서 24시간 일한다. 대화가 끝나도 일을 이어 가고, 계정에 영향을 주는 행동은 자동 검토를 거쳐 바로 하거나 승인을 받거나 사용자에게 넘긴다. 무엇이 새로운지, 실제로 무슨 일을 맡길 수 있는지, 안전장치와 학습 데이터 정책, 누가 언제부터 쓸 수 있는지까지 OpenAI 공식 발표 기준으로 정리했다.
- 부를 때마다 새로 켤까, 켜 둔 채 쓸까 — 콜택시와 정류장에서 기다리는 셔틀버스 (LLM 중계기 개발기)
Codex와 Claude의 명령어 도구는 내 컴퓨터에서 켜야 대답하는 프로그램이라, 중계기는 요청마다 새로 켤지 켜 둔 채 다시 쓸지를 정해야 했습니다. 콜택시와 셔틀버스에 빗대어 두 방식의 속도·기억 섞임·메모리·정리 부담을 비교하고, 중계기가 Codex(앱 서버 하나에 요청마다 새 대화방)와 Claude(프로그램별 세션 최대 6개, 5분 쉬면 정리)를 어떻게 다루는지 비개발자 눈높이로 정리했습니다.
- AI마다 다른 플러그를 같은 어댑터로 — 서랍 속 충전기 젠더 이야기 (LLM 중계기 개발기)
어떤 AI는 웹 주소로, 어떤 AI는 내 컴퓨터의 명령어 도구로, 또 어떤 AI는 로컬 서버로 불러야 합니다. 플러그 모양이 다 다른 셈이에요. 제가 만든 LLM 중계기는 AI마다 작은 어댑터를 하나씩 끼우고, 모든 어댑터가 확인·목록·특성·대화라는 네 가지 약속을 같은 모양으로 지키게 했습니다. 그 덕분에 바깥 프로그램은 메뉴판 한 장만 보면 되고, 새 AI는 어댑터 파일 하나와 등록 한 줄로 들어옵니다. 첫 버전 닷새 뒤 NVIDIA를 붙인 날의 기록까지 비개발자 눈높이로 정리했습니다.
- AI와 함께 하루 만에 만든 첫 버전 — 짐 풀고, 고치고, 밤에야 눕는 이삿날 (LLM 중계기 개발기)
LLM 중계기의 첫날은 이삿날 같았습니다. 아침 8시에 여러 AI를 'OpenAI 호환' 창구 하나 뒤에 세운 첫 버전이 나왔고, 윈도에서 처음 켜 보자 고장이 줄줄이 나왔고, 밤 10시가 넘어서야 v0.1.16으로 하루를 마감했어요. 그날 쌓인 저장 기록을 시간 순서로 펼쳐, AI 코딩 도우미와 짝을 이뤄 작은 판을 여러 번 올린 방법과 '고장 하나에 검사 하나'라는 습관이 생긴 과정을 비개발자 눈높이로 정리했습니다.
- 'OpenAI 호환'은 왜 표준 콘센트가 됐나 — 모양은 같은데 전압이 살짝 다를 때 (LLM 중계기 개발기)
AI 도구 설명에 자주 보이는 'OpenAI 호환'은 OpenAI의 AI를 쓴다는 뜻이 아니라, OpenAI가 정한 대화 요청의 모양을 따른다는 뜻입니다. 이 모양이 널리 쓰이면서 LM Studio 같은 프로그램도 같은 모양으로 창구를 열고, 제가 만든 LLM 중계기도 이 모양 덕분에 주소 한 줄로 어떤 프로그램이든 받게 됐어요. 그런데 '호환'인데도 끝난 이유, 생각 과정, 빈 도구 목록, 거절 이유에서 AI마다 조금씩 달라 하나씩 맞춰야 했습니다. 그 이득과 한계를 비개발자 눈높이로 정리했습니다.
- 중계기란 무엇인가 — 콘센트 모양이 다른 나라에서 쓰는 만능 어댑터 (LLM 중계기 개발기)
여행용 멀티 어댑터를 열어 보면 꽂는 구멍, 모양을 바꾸는 부품, 과부하를 막는 장치가 따로 있습니다. 제가 만든 LLM 중계기도 안을 열어 보면 칸이 나뉘어 있어요. 프로그램이 보낸 질문 하나가 창구 → 교통정리 → 어댑터를 지나 AI에 닿고 답이 조금씩 흘러 돌아오는 길, 사람용 관리 화면과 프로그램용 API라는 두 창구, 요청마다 남는 기록(토큰·첫 글자까지 걸린 시간·끝난 이유), 그리고 처음부터 지키는 세 가지 안전 기본값을 비개발자 눈높이로 정리했습니다.
- GPT-6.1 Sol 발표 — Astra에 가까운 성능을 5분의 1 값에. 무엇이 달라졌고 누구에게 맞나
2026년 9월 29일 OpenAI가 DevDay에서 GPT-6.1 Sol을 발표했다. GPT-6 Sol을 크게 업그레이드한 모델로, 회사 설명으로는 최상위 모델 GPT-6 Astra에 가까운 성능을 Astra 토큰 가격의 5분의 1에 낸다. API 가격은 100만 토큰당 입력 2달러·출력 10달러로 Claude Sonnet 5.5와 같고, 캐시된 입력은 0.1달러다. 공식 발표문의 코딩·문서·업무 자동화·컴퓨터 사용·과학 연구·사실 정확성 결과와 안전 평가, Ultrafast와 새 Pro 요금제, 그리고 하루 먼저 나온 Claude Sonnet 5.5와 나란히 놓고 볼 점까지 정리했다.
- Claude Sonnet 5.5 출시 — 가격은 그대로, 30% 빨라졌다. Sonnet 5·Opus 5.5와 벤치마크로 비교
2026년 9월 28일 앤트로픽이 Claude Sonnet 5.5를 내놨다. Claude 5.5 계열의 두 번째 모델로, 가격은 Sonnet 5와 같은 100만 토큰당 입력 2달러·출력 10달러인데 답을 내는 속도는 30% 이상 빨라졌다는 게 회사 설명이다. 공식 발표 표의 벤치마크 8개를 그대로 옮겨 이전 버전 Sonnet 5, 윗급 Opus 5.5, 경쟁 모델 GPT-6 Sol과 비교하고, 가격·스펙·안전 조치, 그리고 회사 스스로 밝힌 'Opus 5.5가 여전히 나은 일'까지 정리했다.
- 퇴근하면 노는 AI 구독, 일하게 할 수 없을까 — LLM 중계기 개발기를 시작하며
매달 결제하는 Codex와 Claude는 내가 채팅창 앞에 앉아 있을 때만 일합니다. 웹·앱·터미널·편집기 플러그인이라는 서로 다른 껍데기에 갇혀 있기 때문이에요. 여러 AI를 주소 하나 뒤에 세워 내 프로그램 어디서든 골라 쓰거나 동시에 쓰게 해 주는 'LLM 중계기'를 직접 만든 이야기의 첫 편. 왜 만들었는지, 처음에 던진 세 가지 질문, 중계기 전과 후에 연결선이 어떻게 달라지는지를 비개발자 눈높이로 정리했습니다.
- Claude Opus 5.5 실사용 후기 — 블로그 공장에 '현장 반장'으로 나흘을 맡겨 보니
9월 28일부터 10월 1일까지, 제 블로그 공장(글 작성·사이트 배포·네이버 발행 큐)을 Claude Opus 5.5에게 한 대화창으로 맡겼습니다. 사진 몇 장으로 카페 글 쓰기, 물결·별표 서식 사고 두 건을 사이트 전체에서 한 번에 고치기, 이틀 멈춘 네이버 발행의 원인 찾기, 블로그 카테고리 추가까지 — 무엇을 맡겼고 어떻게 처리했는지, 먼저 묻는 습관과 아쉬웠던 점, 맡길 때 정해 둔 규칙을 작업 기록 그대로 정리했습니다.
- 오픈클로·헤르메스·그록봇·메타 뮤즈 — '일을 대신 해주는 AI' 네 갈래의 히스토리와 기술 차이, 그리고 뮤즈가 다른 점
10개월 사이에 '대화만 하는 AI'가 아니라 '일을 끝내주는 AI 에이전트'가 네 갈래로 쏟아졌다. 개인 개발자가 만든 오픈소스 오픈클로, 쓸수록 스스로 배우는 헤르메스 에이전트, 봇마다 클라우드 컴퓨터를 주는 xAI의 그록봇, 그리고 9월 8일 나온 메타 뮤즈. 비서를 두는 네 가지 방법에 빗대 히스토리와 기술 차이를 표로 정리하고, 뮤즈가 앞의 셋과 무엇이 다른지 — 설치 없는 일반인용, 모델부터 컴퓨터까지 메타가 소유, 안전장치를 전면에, 거래 수수료로 버는 구조 — 를 공식 자료 기준으로 짚었다.
- Claude Opus 5.5 출시 — Fable 5.1급 성능을 60% 싼 값에? 벤치마크로 본 이전 버전·경쟁 모델과의 차이
2026년 9월 22일 앤트로픽이 Claude Opus 5.5를 내놨다. '대부분의 작업에서 Fable 5.1 수준, 운영 비용은 Opus 5보다 40% 적다'는 게 회사 설명이다. 공식 발표 표의 벤치마크 9개를 그대로 옮겨 이전 버전 Opus 5, 상위 모델 Fable 5.1, 경쟁 모델 GPT-6 Astra·GPT-5.6 Sol과 비교하고, 가격·속도·안전성 평가까지 정리했다. Opus 5.5가 지는 항목과 회사 스스로 밝힌 한계도 함께.
- LLM 게이트웨이에 판정 창구 하나를 더 냈다 — Jev의 계약을 사내 AI 창구에 옮긴 기록 (실물 기준)
회사 앱들이 AI를 쓰는 단일 창구(LLM 게이트웨이)에 '빠른 판정' 창구 POST /v1/decisions를 새로 냈다. TypeSafe AI Jev의 계약 — 상태와 타입 질문을 보내면 타입 안전한 확률적 결정이 돌아온다 — 을 게이트웨이의 계약으로 그대로 채택한 것. 개인 PC에서는 진짜 Jev가, 클라우드에 닿지 않는 회사망에서는 챗 모델이 같은 형식을 흉내 낸다. 왜 두 경로가 필요했는지, 속도 이득의 실체가 무엇인지(생성은 안 빨라진다), 키와 데이터를 어떻게 다뤘는지 릴리스 노트와 코드 기준으로 적었다. Jev 3부작의 3편.
- Jev 사용법 — 상태와 질문표를 보내면 확신도가 돌아온다, 확신도로 세 갈래 나누기 (공식 문서 기준)
TypeSafe AI의 Jev를 실제로 어떻게 부르는지 공식 문서의 예제 그대로 따라간다. 고객 문의 한 통을 보내 '어느 팀·얼마나 화났나·급한가'를 한 번에 받고, 돌아온 확신도로 자동 처리·확인 후 진행·사람에게 넘기기 세 갈래를 만드는 법. 확신도가 어떻게 계산되는지, 문서가 권하는 문턱값, 네 가지 설계 패턴, 한도와 오류 코드, 그리고 질문을 잘못 쓰는 흔한 실수까지. Jev 3부작의 2편.
- System One 모델 Jev란 — 생각하지 않고 고르기만 하는 AI, 왜 0.5초면 되나 (5분 설명)
2026년 9월 15일 TypeSafe AI가 발표한 Jev는 글을 쓰지 않는 AI다. 상태(state)와 미리 정한 질문표를 보내면 '어느 것', '몇 단계', '예/아니오'를 확률과 함께 0.07~0.5초에 돌려준다. 카너먼의 '빠른 생각(System 1)'에서 이름을 딴 System One 모델이 뭔지, 챗봇형 LLM과 무엇이 다른지, 세 가지 질문 유형과 '보정된 확률'이 왜 핵심인지, 그리고 못 하는 것은 무엇인지 공식 발표문과 문서 기준으로 비개발자 눈높이에 맞춰 정리했다. Jev 3부작의 1편.
- MCP vs API vs CLI 차이 — 도구함, 리모컨 다발, 통합 리모컨 (셋은 경쟁이 아니라 층이 다르다)
AI 글에 늘 같이 나오는 세 단어 MCP·API·CLI를 비개발자 눈높이로 가른다. CLI는 기계에 달린 버튼(사람이나 AI가 터미널에서 직접 누름), API는 기기별 리모컨(프로그램이 정해진 양식으로 요청, 서비스마다 양식이 다름), MCP는 통합 리모컨 규격(AI가 도구 목록을 받아 스스로 고름). 같은 일 하나를 세 방식으로 해 보고, 제 블로그 공장이 셋을 어디에 쓰는지, 언제 뭘 고르는지 표로 정리했다.
- 자동화 건강검진이란 — 매일 초록불이던 공장에서 멈춘 소포 넷을 찾은 이야기 (실물 기준)
제 블로그의 자동 발행 큐는 12일 내내 '정상 종료'였다. 그 아래에서 글 넷이 멈춰 있었다 — 예약일이 비어서, 대본 파일이 옛 형식이라서, 올라갔는데 기록이 없어서, 브라우저에 엉뚱한 계정이 로그인돼 있어서. 넷 다 실패 로그가 없었고 사람이 우연히 찾았다. 자동화가 '오류'가 아니라 '해당 없음'으로 멈추는 이유와, 그래서 매일 릴리스 직후 돌리게 된 여섯 가지 건강검진을 그대로 적었다.
- n8n vs Zapier 비교 — 소포마다 돈을 내느냐, 트럭 한 번에 내느냐 (요금표보다 셈법이 먼저)
n8n과 Zapier의 차이는 요금표 숫자보다 '무엇을 세는가'에 있다. Zapier는 성공한 액션 단계마다 태스크 하나, n8n은 워크플로가 한 번 돌면 단계가 몇 개든 실행 하나. 2026년 9월 21일 공식 요금표를 확인해 표로 정리하고, 제 블로그 자동화(하루 1번, 4단계)를 두 도구로 옮기면 한 달에 얼마가 되는지 계산했다. 직접 설치(셀프호스팅)의 조건과 라이선스, 그리고 누구에게 뭐가 맞는지까지.
- Claude Code 서브에이전트 실전 — 잡지사처럼 작가 열한 명에게 글 32편을 하루에 청탁한 방법
리뷰와 사진만 있는 소재 32개를 하루 만에 글 32편으로 만들었다. 비결은 AI가 빨라서가 아니라 잡지사의 방식을 그대로 옮긴 것 — 편집장(메인 세션)이 브리프 한 장과 취재 노트(패킷) 32개를 만들고, 작가(서브에이전트) 열한 명이 동시에 쓰고, 검수원(스크립트)이 형식을 거른다. 실제 브리프·패킷·검수 코드와, 작가가 패킷의 오류를 되잡은 네 장면을 그대로 적었다.
- Windows에 Claude Code 설치하기 — 실제 쓰는 머신 기준 5분 가이드
Windows 11에서 Claude Code를 설치하는 4가지 방법과 권장 선택, 첫 로그인, 흔한 오류 해결까지. 공식 문서 교차 확인 + 실사용 머신 기준으로 정리했다.
- 바이브 코딩의 한계 — AI가 짠 자동화가 실전에서 깨진 다섯 장면, 전부 '성공'이라고 말하고 있었다
AI에게 짜게 한 자동화가 일주일 사이 다섯 번 깨졌다. 공통점은 하나 — 코드는 매번 '됐다'고 보고했고, 결과물은 없었다. 이 블로그의 발행 시스템에서 실제로 일어난 사건 다섯 개를 날짜·원인·고친 코드와 함께 적고, 바이브 코딩이 잘 못 하는 것과 그걸 메우는 원칙 세 가지를 정리했다.
- AI 에이전트를 24시간 돌릴 기계 — 맥미니 M4를 자동화 전용으로 뒀습니다
AI 에이전트는 내가 노트북을 닫으면 멈춥니다. 그래서 자동화 전용 기계를 따로 뒀습니다. 맥미니 M4를 오픈클로 전용으로 구축해 한 달 굴려본 기록 — 역할을 분리하는 이유, 애플 공식 수치로 따져본 24시간 전기값, 그리고 세팅에 드는 품까지.
- ChatGPT 엑셀 자동화 프롬프트 — 수식을 검색하지 않고 말로 시키는 법
엑셀 수식을 검색해서 복붙하는 대신 ChatGPT에게 말로 시키는 방법. 결과를 가르는 프롬프트 4요소, 바로 복붙해 쓰는 프롬프트 5종(수식 작성·오류 수정·데이터 정리·집계·매크로), 그리고 버전 함정(XLOOKUP·TEXTSPLIT)과 회사 데이터 보안까지.
- Playwright 뜻 — 브라우저에 손을 달아주는 도구, AI가 내 대신 클릭하게 만드는 법 (5분 설명)
브라우저 자동화 도구 Playwright를 비개발자 눈높이로 설명한다. 극작가와 배우 비유로 푸는 작동 원리, 테스트 도구가 AI 에이전트의 '손'이 된 흐름, 이 블로그가 네이버 글을 실제로 올리는 방식, 그리고 '로그인은 사람이, 조종은 코드가'라는 원칙까지.
- LLM 위키 뜻 — AI에게 메모장 대신 백과사전을 맡기면 생기는 일 (5분 설명)
2026년 4월 카파시가 제안한 'LLM 위키'를 비개발자 눈높이로 설명한다. 매번 처음부터 찾는 사서(RAG)와 읽은 걸 정리해 자기 백과사전을 키우는 사서(LLM 위키)의 차이, 3층 구조와 세 가지 동작, 그리고 제 블로그 공장이 이미 이걸 돌리고 있다는 실물 증거까지.
- yml 파일이란 — AI가 유독 이 형식을 좋아하는 이유 (실사용 51개로 설명)
.yml이 뭔지, AI 도구를 쓰면 왜 계속 마주치는지. 블로그 자동화에 실제로 쓰는 yml 파일 51개를 기준으로 역할·문법·함정 4가지를 정리했다.
- HTML 파일 하나로 앱 만들기 — 설치도 서버도 없이 내가 쓸 앱을 갖는 가장 빠른 방법 (실물 3개 기준)
앱스토어·서버·개발자 없이 HTML 파일 하나로 실제로 쓰는 앱을 만드는 법. 직접 만들어 쓰고 있는 앱 3개(여행 앱·비용 계산기·관제판)의 크기와 구조, 되는 것과 안 되는 것, 40줄짜리 복붙 템플릿과 AI에게 시키는 프롬프트까지 정리했다.
- AI 3사가 같은 주에 '해킹 능력' 모델을 내놓고, 동시에 문을 잠갔다 — 왜 그런지, 무슨 뜻인지부터
2026년 9월 첫 주, 앤트로픽·구글·OpenAI가 나란히 사이버보안 특화 모델을 공개하면서 접근을 신원 확인된 기관으로 제한했다. 제로데이·익스플로잇·이중용도·게이티드 액세스 같은 용어를 쉽게 풀고, 왜 논쟁인지까지 균형 있게 짚었다.
- AI 에이전트 만들기 입문 — 폰에서 이슈 하나 올리면 11분 뒤 블로그 3채널에 발행되는 구조 (실물 기준)
AI 에이전트가 챗봇과 뭐가 다른지, 실제로 굴리는 에이전트 하나(GitHub 이슈 → 사진 수집 → 글 작성 → 사이트·네이버·인스타 발행 → 이슈 댓글)를 뜯어서 설명한다. 재료는 지시서·도구·규칙 세 가지, 오늘 실측 11분, 그리고 입문 로드맵 4단계.
- GPT-6 '아스트라', OpenAI가 'AGI 시대' 선언 — 진짜 AGI일까, 무슨 뜻인지부터
2026년 9월 OpenAI가 공개한 GPT-6 아스트라(Astra)와 'AGI 도래' 주장 정리. AGI·프런티어 모델·컴퓨터 유즈·정렬 같은 핵심 용어를 쉽게 풀고, 왜 논쟁적인지까지 균형 있게 짚었다.
- 코딩 에이전트 추천 2026 — 실사용 2개 + 조사 3개, 유형별 정리
Claude Code와 Codex는 직접 쓰고, Cursor·Copilot·Gemini CLI는 조사했다. 실사용과 조사를 구분해서, 사람 유형별로 어떤 코딩 에이전트가 맞는지 정리한 가이드.
- Claude Code 서브에이전트 사용법 — 큰 일은 혼자 하지 말고 나눠 시키세요
Claude Code 서브에이전트가 뭔지, 언제 쓰는지, 어떻게 만드는지. 컨텍스트 격리·병렬 처리·역할 전문화라는 세 가지 쓸모를 실사용 기준으로 정리했다.
- Claude Code에 MCP 연결하기 — 개념부터 첫 연결까지 (실사용 기준)
Claude Code에 MCP 서버를 연결하는 방법. 연결 방식 세 가지, 첫 연결로 뭘 고를지, 연결 후 확인하는 법까지 — 커넥터를 매일 쓰는 실사용 기준으로 정리했다.
- Claude Code 요금과 한도 — 실사용자가 정리한 구조와 한도 안 걸리는 사용법
Claude Code의 요금제(Pro/Max), 5시간 롤링 윈도우와 주간 상한이라는 한도 구조, 그리고 매일 쓰면서 익힌 한도 관리 요령을 정리했다.
- Claude Code 훅(hooks) 활용법 — AI에게 부탁하지 말고 규칙으로 거세요
Claude Code 훅 설정 방법과 실전 레시피 3가지. 파일 수정 후 자동 포맷, 위험 명령 차단, 작업 완료 알림까지 — 매번 부탁하는 대신 무조건 실행되는 규칙을 만드는 법.
- 회사에서 ChatGPT 써도 되나 — 직장인이 지켜야 할 선 4가지
회사 업무에 AI를 쓸 때의 진짜 리스크와 판단 기준. 학습 사용 여부, 개인 계정 vs 기업 플랜, 넣으면 안 되는 데이터, 실무 수칙 4가지를 직장인 관점으로 정리했다.
- AI 검증 자동화 — 사고 한 번 나고 배운 것 (코드리뷰부터 산출물 검증까지)
AI 코드리뷰 도구 소개에서 한 걸음 더. AI에게 일을 맡길 때 진짜 필요한 건 '검증 루프'라는 것을, 실제로 겪은 사고 하나로 설명한다.
- AI 업무 자동화 시작하는 법 — 도구 말고 순서부터 (실전 로드맵)
AI 자동화는 도구 선택이 아니라 순서의 문제다. 반복 작업 하나 고르기부터 검증 루프, 규칙화까지 — 블로그 운영을 통째로 자동화하며 검증한 5단계 로드맵.
- OpenAI API 비용, 직접 계산해보면 감이 옵니다 — 한국어 계산기 포함
토큰 단가표만 봐서는 감이 안 오는 OpenAI API 비용. 실제로 API를 매주 쓰는 입장에서 비용 구조를 해설하고, 단가를 직접 수정할 수 있는 한국어 계산기를 만들었다.
- MCP 서버 추천 — 매일 쓰는 6개와 연결 전 확인할 것
MCP 개념을 알았다면 다음은 '뭘 연결하나'다. 실제로 매일 쓰는 커넥터 6개를 용도별로 추천하고, 아무 서버나 연결하면 안 되는 이유와 안전 기준을 정리했다.
- MCP 뜻 — AI에게 손발을 달아주는 표준, 5분 설명
MCP(Model Context Protocol)가 무엇인지 비유로 설명한다. 왜 나왔는지, 어떤 구조인지, 실제로 뭐가 달라지는지 — 개발 지식 없이 읽을 수 있게 정리했다.
- Claude Code vs Cursor — 구조가 다르면 쓰임새가 다릅니다 (실사용자의 정직한 비교)
Claude Code를 매일 쓰는 입장에서 Cursor와의 구조적 차이를 정리했다. 에디터형과 에이전트형은 경쟁 관계가 아니라 쓰임새가 다른 도구다.
- Claude Code vs Codex — 둘 다 돈 내고 써본 사람의 실전 비교
여행 앱은 Codex로 만들고 블로그 운영 시스템은 Claude Code로 굴린다. 두 코딩 AI를 실제 프로젝트에 각각 써본 경험으로, 어떤 사람에게 뭐가 맞는지 정리했다.
- Claude Code 사용법 — 설치 다음에 알아야 할 것 전부 (실사용 머신 기준)
Claude Code로 실제 일을 시키는 방법. 기본 사용 흐름, CLAUDE.md, 계획 모드, 권한 관리, 자주 쓰는 슬래시 명령까지 — 블로그 운영 시스템을 통째로 맡기고 있는 머신 기준으로 정리했다.
- 바이브 코딩이 뭐길래 — 뜻부터 도구 선택까지, 직접 만든 실물 2개로 설명
바이브 코딩의 뜻과 시작 방법. 대화만으로 여행 앱을 만든 경험과 AI 에이전트로 시스템을 구축한 경험, 실물 2개로 도구 유형별 차이를 설명한다.
- ChatGPT Plus vs Claude Pro — 둘 다 돈 내고 쓰는 사람의 결론
월 $20 AI 구독, 뭘 골라야 할까. 같은 프로젝트에서 두 서비스를 실제로 역할 분담해 써본 경험으로 상황별 답을 정리했다.
- 19명 대가족 여행, Codex로 일정 짜고 앱까지 만들어서 다녀왔다
5가족 19명 삼척 갈남항 여행. ChatGPT(Codex)로 일정을 짜고 여행 앱까지 만들어 실제로 썼다. 첫 앱은 폐기, 두 번째 앱이 성공한 이유까지 — 전 과정 실전 기록.
