VIBECODING / WORKING METHOD 2026

말로 시작해서,
쓸 수 있는 결과까지.

이 작업장에서 바이브코딩은 말로 요청하고 AI와 코드를 고쳐 가는 개발 방식입니다. 사람은 만들 이유와 완료 기준을 정하고, AI는 구현과 확인을 돕습니다. 마지막에는 사용자가 실제로 보는 결과까지 확인합니다.

작은 작업 하나 시작하기 실전 노하우 99건
1
한 번에 해결할 문제
5
요청부터 확인까지 단계
2
근거가 있는 실제 사례
09.23
내용 확인일

START SMALL

첫 요청은 작고 구체적으로.

버튼 하나, 입력창 하나처럼 직접 결과를 확인할 수 있는 문제부터 시작합니다. 아래는 실제 의뢰가 아닌 따라 써볼 수 있는 예시입니다.

이렇게만 말하면

“할 일 앱 좀 좋게 만들어줘.”

누가 쓰는지, 어느 화면이 불편한지, 무엇이 되면 끝인지 알 수 없어 결과가 엇갈리기 쉽습니다.

확인할 수 있게 바꾸면

“휴대폰에서 할 일을 추가할 때 키보드가 등록 버튼을 가립니다. 입력한 글을 유지하면서 등록할 수 있게 고쳐주세요. 작은 화면과 긴 한글 제목으로 확인하고, 로그인·저장 방식은 바꾸지 마세요.”

대상·문제·원하는 동작·확인 조건·제외 범위가 생겼습니다. AI가 만든 결과도 같은 조건으로 검토할 수 있습니다.

내 작업에 맞춰 쓸 요청 틀
누가, 어디에서 쓰나요:
지금 불편한 동작:
바라는 결과:
끝났다고 판단할 확인 방법:
바꾸지 않을 것:
공개 반영이 필요한지:

모르는 항목은 “현재 상태를 먼저 확인해 주세요”라고 적어도 됩니다. 불확실한 내용을 사실처럼 채울 필요는 없습니다.

01 / OPERATING PRINCIPLES

지금 지키는 네 가지 원칙.

도구 이름은 자주 바뀌지만, 작업을 안전하게 끝내는 기준은 오래 남습니다.

01

프롬프트보다 완료 조건

만들 결과와 끝났다고 판단할 조건을 함께 적는다. 코드 수정·동작 확인·공개 반영을 서로 다른 단계로 본다.

02

한 작업에는 한 책임자

여러 도구를 쓸 수 있어도 같은 일을 동시에 선점하지 않는다. 하나의 리드가 판단과 결과 회수를 끝까지 책임진다.

03

자신감보다 관측값

파일을 바꿨다는 말보다 실행 중인 프로세스, 테스트 결과, 실제 기기와 공개 URL에서 읽은 값을 믿는다.

04

되돌리기 어려운 일은 마지막에

삭제·결제·발송·스토어 제출·공개 머지는 준비와 검증을 마친 뒤 승인 범위 안에서 실행한다.

02 / CURRENT LOOP

요청에서 실제 출시까지.

각 단계는 다음 단계로 넘어가기 위한 산출물을 남깁니다. 그래서 세션이 바뀌거나 도구가 달라져도 작업을 처음부터 다시 추측하지 않습니다.

  1. 01

    REQUEST

    목표와 끝을 정한다

    사용자 요청에서 결과물, 완료 조건, 제외 범위를 분리한다. 모호함이 결과를 바꿀 때만 질문한다.

    goal · scope · done
  2. 02

    GROUND

    현재 상태를 먼저 읽는다

    기억보다 코드, 실행 중인 환경, 최신 정책과 외부 상태를 확인한다. 오래된 전제를 작업에 들이지 않는다.

    code · runtime · policy
  3. 03

    BUILD

    작은 변경으로 만든다

    작업 공간을 분리하고 직접 코드에서 반복한다. 병렬화는 독립적인 부분에만 쓰고 같은 파일 경합을 피한다.

    branch · diff · artifact
  4. 04

    VERIFY

    문제가 생길 조건을 확인한다

    빌드만 보지 않는다. 회귀 테스트, 모바일 화면, 링크, 비밀정보, 런타임 값을 변경 위험에 맞게 검증한다.

    test · visual · runtime
  5. 05

    SHIP

    실제로 사용하는 곳에서 확인한다

    코드 검토와 배포가 끝나면 실제 주소나 기기에서 바뀐 동작을 확인한다. 준비된 파일과 사용자가 받는 결과를 구분한다.

    merge · deploy · live

최근 작업에서 달라진 두 가지 판단

2026-09-21 비교 실험과 9월 23일 공개 변경을 연결했습니다. 원래 측정일과 한계를 유지하며, 이번 페이지 갱신에서 새 실험을 한 것은 아닙니다.

· 공개 변경 사례

휠을 올렸는데 분자가 작아졌을 때

요청
분자 화면에서 휠을 올리면 확대되기를 기대했는데 반대로 움직인다는 사용 피드백이 들어왔습니다.
문제
이미지 확대 화면과 3D 분자의 휠 방향이 달라 같은 사이트 안에서 조작을 다시 익혀야 했습니다.
변경
3D 분자의 휠 위 확대·아래 축소 방향을 통일했습니다. 회사 공통 구성과 단백질 사이트의 사본을 함께 반영했습니다.
검증
공개 PR에는 빌드 검사와 브라우저에서 휠 방향을 확인한 기록을 남겼습니다. 코드 변경과 배포 후 화면 확인을 나누어 검증했습니다.
배운 점
완료 기준은 코드의 부호 변경이 아니라 사용자가 같은 동작으로 같은 결과를 얻는 것입니다. 처리 시간이나 비용 절감은 측정하지 않았습니다.
근거 기록 읽기 ↗

· 무료 규칙 채택

파일 선별에도 AI 호출이 필요할까?

질문
큰 모델에 보낼 파일·로그를 줄일 때 AI 선별이 단순 규칙보다 나을까?
방법
전체 자료·무료 규칙·Jev 선별을 세 표본에서 비교했습니다. 규칙과 Jev의 선별 결과가 같아 규칙부터 적용했습니다.
결과
별도의 실제 파일 표본에서 원문 조회 정보를 포함한 입력량이 11,633→4,478토큰으로 61.5% 줄었습니다. 이 수치는 무료 규칙의 효과입니다.
보존
원문 사본·해시·줄 위치를 남기고 경고와 오류 주변, 알 수 없는 줄은 보존합니다. 선별로 입력이 커지면 원문을 전달합니다.
한계
한 표본의 입력량 감소입니다. 월 청구액 감소나 답변 품질 유지까지 검증한 수치는 아닙니다.
근거 기록 읽기 ↗
작업장 구조와 변천사 읽기

03 / FOUR ERAS

늘렸다가, 줄이고, 기준을 남겼습니다.

4~8월은 당시의 변화 기록입니다. 마지막 9월 항목에만 이번에 확인한 작업 방식을 반영했습니다.

  1. 01

    명령을 만들던 시기

    todo와 worklog 같은 반복 기록을 슬래시 커맨드로 줄였다. 자동화의 출발점은 거대한 에이전트가 아니라 귀찮은 한 단계를 없애는 일이었다.

    single session → reusable commands
  2. 02

    기기를 늘리던 시기

    Mac과 WSL, 여러 실행 엔진을 연결하며 최대 5대까지 확장했다. 속도는 올랐지만 중복 배정, 환경 차이, 결과 회수 문제가 함께 커졌다.

    more nodes → more coordination
  3. 03

    복잡성을 되돌리던 시기

    팀 분할과 다중 오케스트레이션을 실험한 뒤 효과가 없는 구조는 접었다. 정책 문장보다 claim, 체크포인트, 검증 게이트 같은 강제 장치를 남겼다.

    experiment → measure → rollback
  4. 04

    작게 연결해 끝내는 시기

    3대의 Mac과 5종 브릿지를 연결하되 작업마다 한 책임 리드가 필요한 도구만 쓴다. 9월에는 AI 판단과 무료 규칙을 비교하고, 실제 사용 피드백을 공개 변경과 검증으로 연결하는 기준을 보강했다.

    one lead → verified delivery

04 / CONNECTED LAYERS

도구가 아니라 흐름으로 봅니다.

엔진 하나가 모든 일을 하는 구조가 아닙니다. 요청·코드·도구·증거·기록이 느슨하게 연결되고, 작업마다 필요한 층만 사용합니다.

INPUT
01

요청

직접 대화와 Telegram은 서로 다른 입력 경로다. 누가 요청했는지, 어떤 프로그램이 전달했는지, 어디서 실행하는지를 구분해 같은 작업 기록으로 연결한다.

WORKSPACE
02

코드

제품 저장소와 분리된 브랜치에서 변경을 만든다.

ENGINE
03

도구

Codex·Cursor·Grok은 작업별 리드 또는 워커 후보이며 고정 직급이 아니다. Claude·Local을 포함한 브릿지 종류와 현재 작업에 배정된 엔진도 구분한다.

EVIDENCE
04

검증

테스트·스크린샷·런타임 관측·라이브 URL이 완료의 근거가 된다.

MEMORY
05

기록

작업 장부·체크포인트·작업일지·노하우가 다음 작업의 시작점을 만든다.

CHECK THE RESULT

“완료”라는 답을 받았을 때.

내가 요청한 결과를 직접 확인하는 네 가지 질문입니다. 체크 상태는 저장하거나 전송하지 않습니다.

원하는 결과가 아니면 이렇게 돌려주세요

“요청한 동작 / 실제로 보인 동작 / 재현한 순서”를 나눠 알려주세요. 예: “버튼은 보이지만 등록 후 제목이 사라집니다. 긴 제목 입력 → 등록 → 목록으로 돌아가기 순서에서 재현됩니다.”

AI가 코드를 만들면 개발 지식은 필요 없나요?

시작할 때 모든 문법을 알 필요는 없지만, 무엇을 만들고 어떻게 확인할지는 알아야 합니다. 결과를 설명하거나 검증할 수 없는 변경은 범위를 줄여 이해 가능한 단계로 나눕니다. 로그인·결제·사용자 데이터처럼 영향이 큰 부분은 추가 검토가 필요합니다.

이 작업장에서 바뀐 확인 기준
  • 많이 켜면 더 빠르다 → 필요한 한 곳만 책임진다
  • 설정 파일이 맞으면 적용됐다 → 실행 환경과 새 PID까지 본다
  • CI가 초록이면 배포됐다 → 사용자가 받는 페이지를 확인한다
  • 완료 보고를 기억하면 된다 → 관측값과 체크포인트를 남긴다

06 / FRESH FIELD NOTES

공개 기록에서 이어 읽기.

공개 노하우 목록의 최신 네 편입니다. 각 날짜는 원래 기록일이며, 사이트를 빌드할 때 목록 순서를 다시 계산합니다.

01

베리와 사람의 3분 통화 — 듣기·침묵·종료·전달에서 배운 것

약 3분 7초 녹음이 남은 사람 통화에서 말 끊기, 5초 침묵 요청, 종료 의사 처리가 문제로 드러났다. 익명화한 대화 흐름과 3.474~19.763초의 로컬 응답 지연, 통화 기록 전달 누락 원인, 적용한 재발 방지와 아직 확인하지 못한 결과를 구분해 남긴다.

원문 보기
02

회원정보 저장이 「닉네임 중복 확인」에 막힐 때 — 고장 난 검사를 건너뛰면 빠진 항목이 지워진다

한 통신사 사이트 회원정보 변경에서 마케팅 동의만 바꿔도 「닉네임 중복 확인」 경고로 저장이 막혔다. 페이지 코드를 읽어 보니 저장 함수가 화면에 없는 칸을 비교했고, 중복확인 버튼이 부르는 함수도 페이지에 없었다. 확인 표시를 켜고 저장 함수를 다시 불러 해결했지만, 저장 양식에 닉네임이 빠져 있어 닉네임이 빈 값으로 덮였다. 저장 직후 안 바꾼 항목까지 확인하고 원래 값을 넣어 다시 저장해 복구했다.

원문 보기
03

네 번 고쳐도 안 되던 버그가 다섯 번째에 한 줄로 끝난 이유 — 테스트는 초록인데 운영은 빨간 날

텔레그램 /clear 브릿지가 하루 동안 네 번 수정되고도 운영에서 계속 실패했다. 네 번 모두 실제 결함을 고쳤지만 시험용 Codex를 읽기 전용으로 띄워 운영 머리글의 permissions 줄이 보이지 않았다. 다섯 번째는 운영 로그의 단계 코드와 화면 캡처에서 출발해 한 줄을 허용했고, 운영과 같은 설정으로 실패를 먼저 재현한 뒤 36분 만에 사용자의 /clear가 두 기기에서 완료됐다. 테스트 초록·운영 빨강일 때 환경 차이부터 찾는 규칙 일곱 가지.

원문 보기
04

전화 AI 베리, 처음으로 상대와 말을 주고받다 — 이틀의 무음을 하루 만에 뚫은 기록

맥에 붙인 아이폰 회선으로 AI 비서가 전화를 걸어 상대 봇과 질문·답변을 주고받은 첫 통화. 화면 조작 손을 컴퓨터 사용 도구에서 접근성 API 헬퍼로 바꿔 1.2초를 0.1초로, 통화 중 답변 모델을 Haiku로, 단일 턴을 턴 루프로 바꿨다. 알림 센터 통화창·전화 앱·권한 컨텍스트의 함정과 상대 말끝 기준 실측 숫자를 남겼다.

원문 보기
9월 14일에 정리했던 현장 원칙 4건

기존에 소개했던 기록도 원래 날짜와 출처를 유지합니다.

작업장 전체 페이지 목적에 맞는 페이지 찾기