바이브팜

기능을 줄였고 , 데이터가 쌓였고 , 기본 자동화로 반복을 줄였습니다. 그런데 어느 순간 이런 생각이 들었습니다. “이제는 내가 매번 확인하지 않아도, 도구가 먼저 알려주면 좋지 않을까?” 입력과 저장까지는 이미 자동화했습니다. 이번에는 한 단계 더 나아가 보기로 했습니다. 조건을 걸어두면 도구가 스스로 반응하는 구조. 즉, ‘생각하는 것처럼 보이는 도구’를 만들어본 경험을 정리해보겠습니다. 평균을 매번 확인하는 게 번거로웠습니다 기존 지출 도구는 평균과 합계를 계산해주었습니다. 하지만 저는 매번 직접 열어보고 숫자를 확인해야 했습니다. 어느 달은 평균을 확인해보니 이미 목표했던 45,000원을 넘어 47,200원이 되어 있었습니다. 문제는 “이미”였습니다. 그때 깨달았습니다. 확인하는 구조가 아니라, 알려주는 구조가 필요하다는 것을 말입니다. 그래서 아주 단순한 조건을 추가해보기로 했습니다. 조건 하나 추가했을 뿐인데 분위기가 달라졌습니다 제가 시도한 조건은 이것이었습니다. 평균이 45,000원 이하이면 “안정 구간입니다” 표시 평균이 45,000원을 초과하면 “지출 조정이 필요합니다” 표시 기능은 단순했습니다. 하지만 체감은 전혀 단순하지 않았습니다. 숫자를 직접 보는 것과 도구가 먼저 문장으로 말해주는 것은 다릅니다. 어느 날 도구를 열었는데 “지출 조정이 필요합니다”라는 문구가 떠 있었습니다. 숫자 하나보다 문장 하나가 더 강하게 와닿았습니다. 초보자도 따라 할 수 있는 조건 자동화 프롬프트 예제 복잡한 코딩은 필요하지 않습니다. 아래 예제를 그대로 입력해도 충분합니다. 1단계 – 평균 계산 기능 포함 요청 하루 지출을 입력하면 누적 합계와 평균을 계산해주는 간단한 웹 화면을 만들어줘. 날짜, 금액 입력창이 있고, 저장 버튼을 누르면 데이터가 누적되도록 해줘. 2단계 – 기준 초과 시 문구 변경 요청 평균 금액이 45000 원을 초과하면 화면 상단에 "지출 조정이 ...

 기록을 계속하다 보니 어느 순간 이런 생각이 들었습니다. “이제는 내가 숫자를 보는 것이 아니라, 숫자가 나를 보고 있는 것 같다.” 처음에는 단순히 계산을 편하게 하려고 만든 작은 도구였습니다. 하지만 기본값을 넣고, 저장 기능을 추가하고, 반복 작업을 줄이는 자동화를 더하다 보니 도구가 제 소비 습관을 먼저 읽어내기 시작했습니다. 이번 글에서는 제가 직접 겪은 작은 자동화의 시작, 기본값 자동 입력과 간단한 저장 기능을 붙이면서 생긴 변화, 그리고 초보자도 바로 따라 할 수 있는 실습 예제를 정리해보겠습니다. 자동화를 시작한 이유 – 귀찮음이 출발점이었습니다 처음에는 하루 지출을 직접 입력했습니다. 날짜를 쓰고 금액을 적고 항목을 선택했습니다. 이 과정이 매일 반복되니 점점 번거로워졌습니다. 특히 날짜는 매번 같은 형식으로 입력해야 했고, 자주 쓰는 항목도 계속 반복해서 선택해야 했습니다. 어느 날은 날짜를 잘못 입력해서 평균 계산이 틀어진 적도 있었습니다. 그때 깨달았습니다. 사람은 반복 작업에서 반드시 실수한다는 사실을 말입니다.( 참고: 입력값 하나로 도구가 망가지는 경험은 [이전글: 입력값 하나로 도구가 망가질 수 있다 ]에서 뼈아프게 배운 바 있습니다.) 그래서 아주 작은 자동화를 시도했습니다. ‘기본값 자동 입력’이었습니다. 기본값 자동 입력이 만든 변화 제가 처음 추가한 기능은 이것이었습니다. 오늘 날짜 자동 입력 가장 많이 쓰는 항목 기본 선택 최근 입력 금액 기억하기 예를 들어 매일 점심값이 비슷하다면, 마지막에 입력한 금액을 기본값으로 띄워주는 방식입니다. 처음에는 “이게 얼마나 도움이 되겠나” 싶었습니다. 하지만 막상 적용해보니 입력 시간이 절반 이하로 줄었습니다. 무엇보다 실수가 줄었습니다. 날짜 오타가 사라졌고, 항목 선택을 깜빡하는 일이 없어졌습니다. 자동 입력은 편리함보다 안정성을 가져다주었습니다. 그리고 여기서 예상 못 한 일이 생겼습니다. 도구가 저의...

처음에는 단순히 계산이 필요했습니다. 하루에 얼마를 쓰는지 알고 싶었고, 그래서 지출 기록을 시작했습니다. 한 번 합계를 내보면 대략적인 감이 잡힐 것이라 생각했습니다. 하지만 매일 기록을 이어가면서 예상과 다른 변화가 나타났습니다. 숫자가 쌓이자 단순 계산표가 아니라, 제 생활을 비추는 도구가 되기 시작했습니다. 이 글에서는 기록이 누적되면서 실제로 어떤 변화가 있었는지, 평균 계산을 추가한 뒤 무엇이 달라졌는지 구체적인 경험을 중심으로 정리해보겠습니다. 기록 초기에는 의미가 보이지 않았습니다 처음 기록한 항목은 단순했습니다. 날짜 사용 금액 간단한 메모 이 지루한 초기 단계를 버티게 해준 방법은 [이전글: 5분 만에 만드는 하루 지출 자동 정리 도구 ]에서 시도했던 단순함 덕분이었습니다. 일주일 동안의 총지출은 312,400원이었습니다. 숫자만 보면 많지도 적지도 않은 금액처럼 느껴졌습니다. 그저 “생각보다 조금 쓰긴 했네” 정도의 인상이었습니다. 솔직히 말하면 며칠 동안은 큰 의미를 느끼지 못했습니다. 기록 자체가 습관이 되지 않아 번거롭게 느껴지기도 했습니다. 하지만 8일째 되는 날, 처음으로 평균을 계산해 보았습니다. 평균을 계산하자 현실이 보였습니다 312,400원을 7일로 나누자 하루 평균 44,628원이 나왔습니다. 막연히 하루 3만 원대라고 생각하고 있었는데 실제 평균은 4만 원을 훌쩍 넘고 있었습니다. 숫자로 확인하니 체감이 달랐습니다. 이후 2주 차가 되었을 때는 평균이 46,200원으로 더 올라가 있었습니다. 그때부터 조금 더 자세히 들여다보기 시작했습니다. 주말 평균은 58,000원이었고, 평일 평균은 34,000원이었습니다. 주말 소비가 평일보다 약 1.7배 높다는 사실을 처음으로 확인했습니다. 이전에는 “주말에 조금 더 쓰는 편”이라고만 생각했습니다. 하지만 실제 수치는 생각보다 차이가 컸습니다. 반복되는 금액이 눈에 들어왔습니다 기록을 한 달 가까이 이어가자 또 다른 패턴이 보였습니다. ...

도구를 만들다 보면 이상한 욕심이 생깁니다. “이왕 만드는 거 제대로 만들자.” “이 기능도 넣으면 더 좋아 보이지 않을까?” 저도 그랬습니다. 처음에는 단순한 계산 도구 하나로 시작했습니다. 그런데 점점 버튼이 늘어나고, 옵션이 늘어나고, 화면이 복잡해졌습니다. 결과는 의외였습니다. 더 좋아진 게 아니라, 더 불편해졌습니다. 이번 글에서는 제가 직접 겪은 시행착오와, 기능을 덜어냈더니 오히려 더 좋아졌던 경험을 정리해보겠습니다. 초보자도 바로 적용할 수 있는 간단한 실험 예제도 함께 소개하겠습니다. 기능을 더할수록 좋아질 거라 믿었습니다 "이왕 만드는 거 제대로 만들자"는 욕심은 사실 지난번 이야기했던 [ 완벽해질 때까지 공개하지 않겠다는 생각의 함정 ]과도 연결되는 문제였습니다. 그 욕심이 어떤 결과를 초래했는지 구체적으로 적어보겠습니다. 처음 만든 도구는 아주 단순했습니다. 숫자 입력 버튼 클릭 결과 출력 끝이었습니다. 예를 들어, 월 생활비를 계산하는 간단한 도구를 만들었습니다. 월 고정비와 변동비를 입력하면 합계를 보여주는 구조였습니다. 그런데 사용하다 보니 이런 생각이 들었습니다. “그래프도 있으면 좋지 않을까?” “연간 비교 기능도 넣어볼까?” “카테고리별 통계도 있으면 더 전문적이지 않을까?” 그래서 하나씩 추가했습니다. 차트 영역을 만들고, 설정 옵션을 늘리고, 세부 선택 버튼을 붙였습니다. 화면은 점점 화려해졌습니다. 처음에는 뿌듯했습니다. “이제 진짜 서비스 같다”는 느낌이 들었습니다. 하지만 며칠 지나자 문제가 보이기 시작했습니다. 입력하는 데 시간이 오래 걸렸습니다. 어디를 눌러야 할지 잠깐 멈추는 순간이 생겼습니다. 결국 사용 빈도가 줄었습니다. 기능은 늘었는데, 사용성은 떨어졌습니다. 복잡함은 조용히 사용을 멈추게 합니다 복잡함은 에러처럼 바로 드러나지 않습니다. 대신 이런 식으로 나타납니다. 기록을 미루게 됩니다. “나중에 정리해...

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

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

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

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

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

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