완벽해질 때까지 공개하지 않겠다는 생각의 함정

이미지
공개를 미루던 나의 이유 도구를 하나 만들고 나면 항상 같은 생각이 들었습니다. “조금만 더 다듬고 공개하자.” 버튼 색이 마음에 걸렸고, 안내 문구가 어색해 보였고, 계산 결과 표시 방식이 썩 만족스럽지 않았습니다. 그래서 수정했습니다. 그리고 또 수정했습니다. 하지만 공개 버튼을 누르는 날은 오지 않았습니다. 처음에는 완성도를 높이기 위한 과정이라고 믿었습니다. 그러나 어느 순간 깨달았습니다. 저는 완벽을 준비한 것이 아니라 공개를 미루고 있었다는 사실을 말입니다. 완벽주의가 만들어낸 정체 상태 기능은 이미 충분했습니다. 입력값은 정상적으로 작동했고, 결과도 정확하게 계산되었습니다. 그럼에도 불구하고 저는 늘 부족한 부분만 바라봤습니다. ‘이 정도로는 아직 아니다’라는 생각이 습관처럼 자리 잡고 있었습니다. 아이러니하게도 그 시간 동안 저는 아무 반응도 받지 못했습니다. 누가 쓰는지도 모르고, 어디가 불편한지도 모른 채 혼자 상상 속 사용자와 씨름하고 있었습니다. 완벽주의는 겉으로는 책임감처럼 보이지만 실제로는 실행을 미루는 가장 그럴듯한 핑계였습니다. 작은 결함을 안고 공개해본 경험 결국 마음을 정했습니다. “지금 상태로 한 번 내보내 보자.” 계산기 하나를 그대로 공개했습니다. 디자인은 단순했고, 설명은 길었으며, 구성도 세련되다고 말하기는 어려웠습니다. 그런데 공개 이후 예상과 다른 일이 벌어졌습니다. 제가 계속 고민하던 버튼 색상은 아무도 언급하지 않았습니다. 대신 입력 단위가 헷갈린다는 피드백이 나왔습니다. 저는 단위를 당연하게 생각했지만 사용자 입장에서는 명확하지 않았던 것입니다. 그 피드백 하나로 입력창 옆에 작은 안내 문구를 추가했습니다. 그 결과 문의가 줄었고 사용 흐름이 훨씬 자연스러워졌습니다. 그때 처음 알았습니다. 완성도는 혼자 판단하는 것이 아니라 사용 과정에서 만들어진다는 사실을 말입니다. 초보자가 공개를 망설이는 진짜 이유 공개를 미루는 이유는...

나 혼자 만든 서비스의 한계 – 기록이 없으면 성장도 없다

이미지
수정은 했는데, 무엇을 바꿨는지 기억이 나지 않았다 공개를 하고 나니 이상한 습관이 하나 생겼습니다. 화면을 볼 때마다 어딘가를 고치고 싶어졌습니다. 문구를 조금 다듬고, 버튼 위치를 살짝 옮기고, 안내 문장을 한 줄 추가했습니다. 그때는 분명히 “이게 훨씬 낫다”고 생각했습니다. 그런데 며칠 뒤 다시 열어보니 이런 생각이 들었습니다. 예전이 더 깔끔했던 것 같은데? 문제는 여기서 시작됐습니다. 무엇을 어떻게 바꿨는지 기억이 나지 않았습니다. 코드는 남아 있는데 ‘의도’가 사라진 느낌이었습니다. 혼자 만드는 서비스의 가장 큰 약점 회사라면 기록이 남습니다. 누가 무엇을 수정했는지, 왜 바꿨는지 문서가 존재합니다. 하지만 혼자 만드는 작은 서비스는 그 모든 판단이 머릿속에서만 이루어집니다. 그 순간에는 분명 이유가 있었습니다. 하지만 기록하지 않으면 그 이유는 금방 사라집니다. 저는 실제로 이런 경험을 했습니다. 오류 메시지를 더 친절하게 바꿨다고 생각했는데, 며칠 뒤 보니 오히려 길어져서 가독성이 떨어졌습니다. 되돌리고 싶었습니다. 그런데 예전 문장이 정확히 기억나지 않았습니다. 이때 깨달았습니다. 기능보다 먼저 필요한 것은 ‘기록 습관’이라는 사실을 말입니다. 버전 관리라는 말을 처음 이해하다 처음에는 ‘버전 관리’라는 단어가 굉장히 전문적으로 들렸습니다. 개발자들이 쓰는 어려운 개념이라고 생각했습니다. 하지만 직접 겪어보니 의외로 단순했습니다. 지금 상태를 남겨두는 것. 그리고 변경 이유를 적어두는 것. 그게 전부였습니다. 저는 거창한 도구를 쓰지 않았습니다. 일단 가장 쉬운 방법부터 시작했습니다. 파일 이름에 날짜를 붙였습니다. calculator_0210.html calculator_0212.html 아주 단순한 방식이었지만 이전 상태로 돌아갈 수 있다는 것만으로도 마음이 훨씬 편해졌습니다. 초보자도 바로 시작할 수 있는 변경 로그 작성법 기록은 복잡할 필요가 없...

공개를 전제로 했더니 처음 생긴 문제들

이미지
  링크를 열어보는 순간부터 달라진 감각 이전글에서 계산기를 배포 가능한 상태로 만들고 나니 묘한 긴장감이 따라왔습니다. 기능은 이미 완성됐습니다. 숫자를 입력하면 결과가 나오고, 잘못 입력하면 안내 문구도 표시됩니다. 혼자 테스트할 때는 분명히 문제없었습니다. 그런데 막상 “한번 써보세요”라고 말하려니 손이 잠깐 멈췄습니다. 혹시 안 열리지는 않을까. 모바일에서는 깨지지 않을까. 내가 당연하다고 생각한 부분이 다른 사람에게는 불친절하지 않을까. 그전까지는 코드가 돌아가는지만 확인하면 됐습니다. 하지만 공개를 전제로 하자 생각의 방향이 완전히 달라졌습니다. 완성의 기준이 ‘작동 여부’에서 ‘신뢰 가능 여부’로 이동한 것입니다. 혼자 쓰는 기준은 서비스 기준이 아니었다 저는 그동안 ‘내가 이해하면 충분하다’는 기준으로 만들고 있었습니다. 계산 공식이 맞고 버튼이 눌리고 결과가 나오면 끝이라고 생각했습니다. 하지만 링크를 공유한 뒤 비로소 깨달았습니다. 사용자는 제 머릿속 설명을 모릅니다. 어떤 값을 먼저 넣어야 하는지도 모릅니다. 이 도구가 무엇을 계산하는지도 처음엔 알지 못할 수 있습니다. 예를 들어 저는 자연스럽게 숫자 두 개를 입력하고 계산 버튼을 눌렀습니다. 그런데 지인은 이렇게 물었습니다. “아무것도 안 넣고 누르면 왜 이렇게 나오나요?” 그 질문을 듣고 화면을 다시 바라봤습니다. 아무 입력 없이 계산 버튼을 누르면 0 이 출력되고 있었습니다. 저는 그 상황을 단 한 번도 상상해보지 않았던 것입니다. 문제는 코드가 아니었습니다. 사용자를 상상하지 못한 제 시야였습니다. 공개 후 처음 발견한 실제 문제들 공개를 전제로 점검을 시작하자 사소하지만 중요한 문제들이 하나씩 눈에 들어오기 시작했습니다. 첫째, 입력 전 안내가 부족했습니다. 처음 열면 무엇을 해야 할지 약간 애매했습니다. 둘째, 오류 메시지가 추상적이었습니다. “잘못된 값입니다”라는 문장은...

처음으로 “이건 내가 만든 서비스다”라고 느낀 순간 – 배포·공유 입문

기능은 완성됐는데, 어딘가 허전했던 이유 계산기는 이미 정상적으로 동작하고 있었습니다. 입력창에 숫자를 넣고 버튼을 누르면 결과가 나오고, 잘못된 값을 넣으면 안내 문구도 표시됩니다. 이전 회차에서 다뤘던 입력값 검증, 실행 트리거, 기본 UX 요소들도 빠짐없이 반영된 상태였습니다. 기능만 놓고 보면 더 이상 손볼 곳이 없어 보였습니다. 그런데도 이상하게 “이제 끝났다”는 느낌이 들지 않았습니다. 브라우저를 닫으면 이 계산기는 그대로 사라지는 느낌이었고, 다음 날 다시 열어볼 이유도 떠오르지 않았습니다. 그 순간 깨달았습니다. 이 도구는 아직 ‘완성된 결과물’이라기보다는 작업 화면 속 산출물 에 가깝다는 것을요. ‘완성’과 ‘전달 가능함’은 전혀 다른 이야기였다 곰곰이 생각해보니 이 계산기는 나 혼자만 사용할 수 있는 상태였습니다. 다른 사람이 이 도구를 쓰려면 같은 환경을 다시 설명해야 하고, 같은 과정을 그대로 반복해야 했습니다. 즉, 이 도구는 아직 ‘전달’이라는 단계를 전혀 고려하지 않은 상태였습니다. 여기서 기준이 하나 생겼습니다. 내가 설명하지 않아도 누군가가 바로 열어볼 수 있는가 이 질문에 선뜻 “그렇다”고 답할 수 없다면, 그건 아직 연습 단계에 머물러 있다는 생각이 들었습니다. 배포를 너무 멀리 있는 개념으로 생각하고 있었다 그동안 ‘배포’라는 단어를 너무 무겁게 받아들이고 있었습니다. 서버, 도메인, 비용, 유지 관리. 이런 단어들이 먼저 떠올랐고, 그래서 자연스럽게 “아직 내 단계는 아니다”라고 선을 그어왔습니다. 하지만 이번에는 배포의 기준을 아주 낮춰보기로 했습니다. 설치하지 않아도 되고 회원가입이 필요 없고 링크 하나로 열리는 상태 이 조건만 충족돼도 그건 이미 배포의 시작이라는 기준이었습니다. 이렇게 기준을 바꾸자 배포는 부담이 아니라 다음으로 자연스럽게 넘어가는 단계 처럼 느껴지기 시작했습니다. 공유를 전제로 생각하자 시...

하나의 도구를 두 가지 버전으로 만들어봤다 – 목적에 따라 프롬프트가 달라지는 경험

이미지
같은 계산기인데, 쓰는 느낌이 완전히 달라졌다 바이브코딩으로 도구를 만들다 보면 이런 생각이 듭니다. “기능은 똑같은데, 왜 이건 내가 쓰기엔 편한데 남이 쓰기엔 불편하지?” 이번 회차에서는 ‘계산기’라는 동일한 기능을 가진 도구를 개인용 / 공유용 두 가지 버전으로 실제로 만들어본 경험 을 다룹니다. 중요한 점은 코드를 바꾼 것도, 기능을 추가한 것도 아니라는 점입니다. 오직 프롬프트만 달리 썼을 뿐인데 결과물의 성격이 완전히 달라졌습니다. 개인용 계산기: “나는 이미 알고 있다”는 전제 먼저 개인용 계산기부터 만들어봅니다. 이 계산기는 오직 제가 매일 쓰기 위한 용도 입니다. 개인용 계산기 프롬프트 숫자를 입력할 수 있는 입력창 하나와 계산 버튼 하나를 가진 간단한 계산기 화면을 만들어주세요. 입력창에 숫자를 입력한 뒤 버튼을 누르면 해당 숫자를 그대로 결과 영역에 표시합니다. 디자인은 단순하게, 입력창 위, 버튼 아래, 결과는 숫자로만 표시되면 됩니다. 이 프롬프트의 특징은 명확합니다. 입력 규칙 설명이 없습니다 잘못된 입력에 대한 처리도 없습니다 “어떻게 써야 하는지”에 대한 안내가 없습니다 하지만 저는 이 도구를 문제없이 씁니다. 왜냐하면 이미 사용 방법을 알고 있기 때문 입니다. 개인용 도구는 👉 기억과 맥락을 전제로 만들어도 괜찮은 도구 입니다. 공유용 계산기: “아무것도 모른다”는 가정에서 시작 이제 같은 계산기를 다른 사람이 쓴다는 가정 으로 다시 만들어봅니다. 기능은 동일합니다. 입력 → 버튼 클릭 → 결과 출력 하지만 프롬프트는 완전히 달라집니다. 공유용 계산기 프롬프트 웹 브라우저에서 바로 실행할 수 있는 간단한 계산기 웹 페이지를 만들어주세요. 조건은 다음과 같습니다. 1. 이 계산기는 별도의 설치 없이 링크를 클릭하면 새 브라우저 창(또는 새 탭)에서 바로 실행되어야 합니다. 2. 화면 구성 - 숫자를 입력할 수 있는 입력창 1개 - 입력...

내가 만든 도구를 매일 쓰게 만드는 작은 차이 – 반복 사용성을 만드는 UX 요소

이미지
왜 어떤 도구는 한 번 쓰고 끝나고, 어떤 도구는 매일 쓰게 될까 바이브코딩으로 도구를 처음 만들었을 때의 만족감은 큽니다. “내가 직접 만들었다”는 성취감도 있고, 실제로 문제도 해결됩니다. 하지만 며칠이 지나면 이상한 일이 생깁니다. 도구는 분명 쓸모 있는데, 점점 안 쓰게 됩니다. 이 지점에서 많은 초보자는 이렇게 생각합니다. “기능이 부족한가?” “더 대단한 기능을 추가해야 하나?” 하지만 실제 원인은 대부분 기능이 아닙니다. 매일 쓰기엔 살짝 귀찮은 구조 , 이 아주 작은 불편이 반복 사용을 가로막습니다. 사람은 불편을 분석하지 않고, 그냥 피합니다. 이번 글에서는 처음으로 ‘잘 작동하는 도구’가 아니라 ‘계속 쓰게 되는 도구’를 다룹니다. 철학적인 이야기 대신, 지금 당장 수정하면 체감이 달라지는 UX 요소에 집중합니다. 반복 사용성을 만드는 핵심은 ‘생각하지 않게 만드는 것’ "기술이 부족해서 안 쓰는 게 아니라, 0.5초의 망설임 때문에 안 쓰는 것입니다."   사람은 매번 생각해야 하는 도구를 싫어합니다. 입력값을 다시 고민해야 하고, 커서를 어디에 두어야 할지 망설여야 하고, 무엇을 눌러야 하는지 한 번 더 읽어야 한다면 그 도구는 점점 멀어집니다. 반대로 매일 쓰는 도구는 특징이 분명합니다. 열자마자 바로 입력할 수 있고 기본값이 이미 채워져 있으며 다음 행동이 자연스럽게 보입니다 이 차이를 만드는 것이 UX입니다. 그리고 이건 초보자도 충분히 구현할 수 있습니다. 복잡한 설계보다 사람의 행동 흐름을 한 박자 앞서 생각하는 것 이 중요합니다. 기본값 하나가 사용 빈도를 바꾼다 왜 매번 같은 값을 다시 입력하게 만들까 실습용으로 만든 도구를 보면 이런 구조가 많습니다. 입력창이 항상 비어 있음 날짜, 금액, 수량을 매번 다시 입력 “예시”는 있지만 자동으로 채워지지 않음 기능적으로는 아무 문제가 없습니다. 하지만 사용자는 매번 같은 ...

같은 기능인데 프롬프트 길이가 3배 차이 나는 이유

이미지
프롬프트가 길어질수록 잘 되는 걸까 바이브코딩을 하다 보면 이상한 장면을 자주 마주합니다. 같은 기능을 만들었는데 어떤 프롬프트는 세 줄, 어떤 프롬프트는 한 화면을 가득 채웁니다. 처음에는 이렇게 생각하기 쉽습니다. “자세하게 써야 잘 되는 거 아닐까?” “길면 길수록 친절한 설명이니까 결과도 좋겠지.” 하지만 실제로 여러 번 비교해보면 정반대의 결과를 만나는 경우가 많습니다. 길게 쓴 프롬프트일수록 결과가 흔들리고, 짧지만 구조가 잡힌 프롬프트가 오히려 더 안정적으로 동작합니다. 이 차이는 실력의 문제가 아니라 정리 방식의 차이 에서 나옵니다. 이전글 프롬프트 가이드와 무엇이 다른가 이전글[ 바이브코딩 초보자를 위한 프롬프트 작성 기본 가이드 ] 에서는  프롬프트를 처음 쓰는 사람을 위해  “어떻게 요청해야 하는가”에 집중했다면, 이번 회차는 한 단계 더 나아가 “이미 잘 되는 기능을 왜 다시 정리해야 하는가”를 다룹니다. 즉, 이번 글의 핵심은 프롬프트를 더 많이 쓰는 법 이 아니라 덜 쓰는데도 흔들리지 않게 만드는 법 입니다. 잘 되는 프롬프트와 안 되는 프롬프트의 결정적 차이 초보자가 자주 만드는 프롬프트는 이런 특징을 가집니다. 안 되는 프롬프트의 공통점 생각나는 순서대로 적는다 같은 말을 여러 번 반복한다 동작 설명과 조건 설명이 섞여 있다 “알아서 잘” 처리해주길 기대한다 이런 프롬프트는 길어질수록 AI에게 선택지를 더 많이 주게 됩니다. 그 결과, 실행 경로가 매번 달라지며 결과가 흔들립니다. 반면 잘 되는 프롬프트는 다릅니다. 잘 되는 프롬프트의 공통점 역할이 분리되어 있다 한 문장은 하나의 의미만 가진다 실행 순서가 보인다 불필요한 설명이 없다 길이가 짧아도 AI가 추측할 필요가 없도록 설계되어 있습니다. 실습 1. 지저분한 프롬프트 그대로 써보기 예를 들어 이런 프롬프트가 있다고 가정해봅시다. “지출을 입력하면 합계가 나오...

버튼은 눌리는데 왜 아무 일도 안 일어날까

이미지
동작 트리거 이해하기 – 실행은 ‘언제’ 시작되는가 바이브코딩으로 도구를 만들다 보면 이상하게 가장 당황스러운 순간이 찾아옵니다. 버튼은 분명히 눌립니다. 화면도 멀쩡합니다. 에러 메시지도 없습니다. 그런데 아무 일도 일어나지 않습니다. 처음 이 상황을 겪었을 때는 도구가 고장 난 줄 알았습니다. 프롬프트를 다시 쓰고, AI에게 “왜 동작을 안 하냐”고 묻기도 했습니다. 하지만 문제는 기능이 아니라 실행 시점 , 즉 동작 트리거 에 있었습니다. 초보자가 가장 자주 빠지는 오해 바이브코딩을 처음 배우면 이런 식으로 생각하기 쉽습니다. “이 기능을 만들어달라고 했으니 버튼을 누르면 당연히 실행되겠지.” 하지만 AI는 ‘당연히’를 이해하지 않습니다. AI에게 중요한 것은 이 코드가 언제 실행되어야 하는지 입니다. 이 지점을 명확히 하지 않으면 버튼은 만들어지지만 버튼과 동작은 서로 연결되지 않은 상태로 남게 됩니다. 동작 트리거란 무엇인가 동작 트리거는 간단히 말해 실행이 시작되는 계기 입니다. 대표적인 트리거는 다음과 같습니다. 화면이 열리자마자 자동 실행 버튼을 눌렀을 때 실행 특정 조건이 만족되었을 때 실행 문제는 초보자가 이 차이를 인식하지 못한 채 “기능”만 설명한다는 점입니다. 그 결과 AI는 실행 시점을 추측하게 되고, 그 추측은 매번 동일하지 않습니다. 실습 ① 자동 실행 vs 버튼 실행의 차이 먼저 가장 기본적인 비교부터 해보겠습니다. 자동 실행 예시 프롬프트에 이렇게 요청했다고 가정합니다. “숫자를 입력하면 합계를 계산해서 보여주는 화면을 만들어주세요.” 이 경우 AI는 입력값이 바뀔 때마다 자동으로 계산이 실행되도록 만들 가능성이 큽니다. 즉, 화면 변화 = 즉시 실행 구조입니다. 간단한 예제에서는 편하지만, 입력이 많아지면 의도하지 않은 계산이 계속 발생할 수 있습니다. 버튼 실행 예시 이번에는 실행 조건을 명확히 합니다. “계...

입력값 하나로 도구가 망가질 수 있다 (초보자가 처음 배우는 입력값 검증, 그리고 ‘안 깨지는 도구’)

이미지
 바이브코딩으로 계산기나 간단한 도구를 몇 개 만들어보면, 어느 순간 이상한 경험을 하게 됩니다. 분명 어제까지 잘 되던 도구가 오늘은 값 하나 잘못 넣었을 뿐인데 멈추거나, 엉뚱한 숫자를 뱉어내거나, 아예 아무 반응도 하지 않는 상황입니다. 처음 이 상황을 겪었을 때 저 역시 코드가 망가졌다고 생각했습니다. 프롬프트를 다시 쓰고, AI를 바꿔보고, 처음부터 다시 만들어보기도 했습니다. 하지만 시간이 지나며 알게 된 사실은 의외로 단순했습니다. 도구가 고장 난 것이 아니라, 깨질 수밖에 없는 상태로 설계되어 있었다 는 점이었습니다. ‘안 깨지는 도구’ 개념의 첫 등장 이전 회차까지 만든 도구들의 공통점은 분명합니다. “잘 입력했을 때만 잘 작동하는 도구”였습니다. 연습 단계에서는 큰 문제가 없어 보이지만, 실제로 사용하려는 순간 이 한계가 바로 드러납니다. 값을 하나라도 잘못 넣으면 결과가 틀어지고, 초보자는 다시 좌절하게 됩니다. 이번글에서 처음 등장하는 개념은 바로 ‘안 깨지는 도구’입니다. 사용자가 실수해도, 엉뚱한 값을 넣어도, 도구 자체는 멈추지 않는 상태를 의미합니다. 이 개념을 이해하는 순간 바이브코딩 결과물은 연습용 예제에서 실제 생활에서 쓸 수 있는 도구 로 성격이 바뀌기 시작합니다. 입력값 하나로 도구가 망가지는 이유 초보자가 만드는 대부분의 도구에는 보이지 않는 전제가 숨어 있습니다. 사용자는 반드시 값을 입력할 것이다 숫자 입력칸에는 숫자만 들어올 것이다 사용자는 설명서를 읽고 행동할 것이다 하지만 현실의 사용자는 그렇지 않습니다. 심지어 그 사용자가 바로 ‘나 자신’인 경우도 많습니다. 입력값 검증이 없는 도구는 한 번의 실수에도 쉽게 무너집니다. 그리고 그 책임을 AI나 도구 탓으로 돌리게 됩니다. 실습으로 배우는 입력값 검증의 기본 ✅ 프롬프트, 이렇게 한 줄만 더해보세요! 기존 요청: "지출 금액을 입력하면 합산해줘....

같은 프롬프트를 썼는데 결과가 다른 이유 (AI가 내 말을 다르게 이해하는 순간들)

이미지
바이브코딩이 잘되다가 갑자기 막히는 순간 바이브코딩을 어느 정도 익히고 나면 묘한 순간을 마주하게 됩니다. 분명 어제 잘 작동하던 프롬프트를 그대로 썼는데, 오늘은 전혀 다른 결과가 나오는 경험입니다. 버튼 위치가 바뀌거나, 계산 결과가 나오지 않거나, 아예 의도와 다른 화면이 생성되기도 합니다. 처음에는 시스템 오류나 AI 성능 문제라고 생각했습니다. “오늘은 컨디션이 안 좋은가 보다”라고 넘긴 적도 많았습니다. 하지만 이런 일이 반복되면서 단순한 우연이나 오류라고 보기에는 빈도가 너무 잦다는 생각이 들었습니다. 여러 번 결과를 비교해본 끝에 알게 된 점은, 문제의 원인이 AI가 아니라 프롬프트 안에 담긴 제 의도가 충분히 고정되어 있지 않았다는 점 이었습니다. AI는 문장을 읽지 않고 구조를 해석합니다 사람은 문장을 읽을 때 앞뒤 맥락과 경험을 바탕으로 의미를 보완합니다. 조금 모호해도 “아마 이런 뜻이겠지”라고 이해합니다. 하지만 AI는 그렇게 해석하지 않습니다. 입력된 문장을 하나의 설계도로 보고 구성 요소와 관계를 나누어 해석합니다. 예를 들어 “지출을 입력하면 합계가 나오는 화면을 만들어주세요.” 라는 문장은 사람에게는 충분히 명확해 보입니다. 그러나 AI 입장에서는 언제 합계를 계산해야 하는지 입력값이 하나인지 여러 개인지 결과를 어디에 표시해야 하는지 이 정보가 빠져 있습니다. 사람에게는 당연한 흐름이 AI에게는 선택지로 남아버리는 순간입니다. 이 지점에서 결과의 방향이 갈리기 시작했습니다. 같은 프롬프트, 다른 결과가 나오는 이유 제가 실제로 겪었던 사례를 하나 소개하겠습니다. 어느 날은 입력창, 버튼, 결과 영역이 모두 갖춰진 화면이 생성되었고, 다른 날은 입력창만 덩그러니 놓인 화면이 나왔습니다. 프롬프트는 단 한 글자도 바꾸지 않았습니다. 그래서 처음에는 더 혼란스러웠습니다. “똑같이 말했는데 왜 다르지?”라는 생각이 들었기 때문입니다. 이때 알게 ...