할 일은 추가되는데 새로고침하면 목록이 사라집니다. AI에게 앱 수정을 맡기다 이런 상황을 만나면, 다음 요청에 원하는 동작과 그 동작을 확인할 방법을 함께 넣어 보세요. AI가 코드를 수정한 뒤 같은 조건으로 다시 확인할 수 있게 만드는 것이 핵심입니다.

클로드 코드 창시자의 조언에서 가져올 것은 무엇인가요?

마일드코드의 「클로드 코드 창시자가 직접 알려주는 ‘진짜’ 바이브코딩」 영상 설명은 성공 기준과 확인 수단을 작업 환경에 갖추는 일을 강조합니다. 이 주제를 실제 요청에 옮길 때 참고할 만한 원문은 Claude Code를 만든 보리스 체르니(Boris Cherny)의 공개 글과 공식 실전 문서입니다.

보리스는 2026년 2월 1일 팀의 사용 팁에서 복잡한 과제는 계획 모드로 시작한다고 설명합니다. 여러 작업을 별도 작업 공간에서 병렬로 진행하고, 반복되는 교정을 프로젝트 지침에 반영하는 방법도 소개합니다. 앞선 1월 3일 개인 사용법에서는 Claude Code를 쓰는 방법에 하나의 정답이 없다고 밝혔습니다.

여기서 가져올 것은 터미널 개수나 당시 모델 이름을 그대로 따라 하는 습관보다, 내 작업에 맞는 계획·확인·수정 흐름을 만드는 방법입니다. 아래 예시는 그 조언을 작은 앱 수정에 적용한 요청입니다.

지금 AI 코딩은 어디까지 맡길 수 있나요?

Claude Code 같은 코딩 에이전트는 저장소를 읽고, 여러 파일을 고치고, 명령을 실행해 오류를 확인하는 작업을 이어갈 수 있습니다. 사람이 코드 조각을 복사해 붙이는 단계에서, 도구가 있는 작업 환경 안에서 구현과 검사를 반복하는 방식으로 범위가 넓어졌습니다.

그만큼 요청에 담을 내용도 달라집니다. “예쁜 앱을 만들어 줘”에 이어 누구의 어떤 행동을 완성할지, 기존 기능 중 무엇을 지킬지, 결과를 어떻게 확인할지를 정해 주면 다음 수정의 방향이 뚜렷해집니다. Claude Code 공식 실전 지침은 에이전트가 실행할 수 있는 테스트·빌드·화면 비교 같은 확인 수단을 주라고 권합니다.

작은 문구 수정은 바로 고치고 화면을 보면 충분할 수 있습니다. 여러 파일의 연결이나 저장 방식이 바뀌는 작업이라면, 관련 코드를 살펴본 뒤 계획을 먼저 받는 편이 도움이 됩니다. 모든 요청을 긴 기획 문서로 만들 필요는 없습니다.

“할 일 앱 만들어 줘”를 이렇게 바꿉니다

처음부터 기능을 많이 붙이기보다, 사용자가 한 번에 끝낼 행동을 골라 봅니다. 다음은 이미 있는 할 일 앱의 저장 문제를 고치는 요청 예시입니다.

할 일을 추가하고 새로고침해도 목록이 남도록 고쳐 줘.

먼저 항목 추가와 저장을 담당하는 코드를 찾아서
현재 목록이 사라지는 이유와 수정할 파일을 설명해 줘.

성공 조건:
- 공백만 입력하면 항목이 추가되지 않는다.
- 정상 항목을 추가하면 목록에 표시된다.
- 같은 브라우저에서 새로고침해도 항목이 남는다.

기존 삭제 기능을 유지하고, 로그인·서버·새 패키지는 추가하지 마.
이 프로젝트의 기존 검사 방법을 찾아 수정 후 실행해 줘.
화면에서도 위 순서와 삭제 동작을 확인해 줘.
끝나면 바꾼 내용, 실행한 검사 결과, 남은 문제를 알려 줘.

“새로고침해도 남는다”는 사용자가 원하는 결과입니다. 저장 수단은 기존 코드와 환경을 보고 선택하게 합니다. 브라우저 저장을 쓰는 예제라면 다른 기기와의 동기화, 브라우저 데이터 삭제 뒤 복구는 별도 요구사항으로 다뤄야 합니다.

이렇게 요청하면 결과를 받았을 때도 확인할 일이 분명해집니다. 공백을 넣고, 항목을 추가하고, 새로고침하고, 삭제해 봅니다. 화면에 새 항목이 한 번 나타나는 것만 보고 작업을 닫는 실수를 줄일 수 있습니다.

계획에서는 어떤 답을 받아야 하나요?

계획을 받았다면 세 가지를 읽어 봅니다. 문제와 관계있는 코드를 찾았는지, 수정 범위가 요구에 맞는지, 완료를 확인할 방법이 있는지입니다. 공식 작업 흐름 문서에도 코드베이스 탐색, 버그 수정, 테스트, 수정 전 계획의 예시가 있습니다.

예를 들어 저장 문제 하나를 고치는데 새로운 데이터베이스와 로그인 체계를 만들겠다면, 기존 저장 수단으로 해결할 수 있는지 먼저 물어볼 수 있습니다. 반대로 여러 사람이 공유하는 목록이 목표라면 브라우저 하나에만 저장하는 설계로 충분한지 확인해야 합니다. 계획의 길이보다 내가 원하는 사용 상황과 맞는지가 중요합니다.

계획을 납득하기 어렵다면 “이 방식을 고른 이유를 기존 방식과 비교하고, 추가되는 의존성과 데이터 변화를 설명해 줘”라고 요청해 보세요. 결제·운영 데이터 변경·외부 공개처럼 영향이 큰 행동은 실행 전에 직접 판단할 지점을 정합니다.

자동 검사와 화면 확인은 무엇이 다른가요?

자동 검사는 같은 조건을 반복해서 확인하는 데 유용합니다. 공백 입력을 거르는 함수, 저장한 목록을 다시 읽는 처리, 기존 항목 삭제 같은 동작을 검사할 수 있습니다. 이미 테스트가 있는 프로젝트라면 관련 테스트부터 실행하고, 고친 부분이 주변 기능을 깨뜨리지 않았는지도 확인합니다.

화면에서는 자동 검사로 놓치기 쉬운 연결을 봅니다. 버튼을 눌렀을 때 실제로 항목이 나타나는지, 좁은 화면에서 입력창이 가려지지 않는지, 새로고침한 뒤 같은 목록을 보여 주는지 확인합니다. UI가 있는 작업은 동작을 만드는 코드와 사용자가 밟는 동선을 함께 봐야 합니다.

에이전트에게는 “테스트했어?”보다 “어떤 명령을 실행했고, 무엇이 통과하거나 실패했는지 보여 줘”라고 물어보면 좋습니다. 브라우저 도구를 쓸 수 있다면 직접 동선을 확인하게 하고, 도구가 없다면 내가 따라 할 조작 순서를 받습니다. 실행하지 않은 검사는 다음 행동으로 남겨 두면 됩니다.

“아직 안 돼” 대신 실패한 장면을 보냅니다

‘우유 사기’를 추가한 뒤 새로고침하면 목록이 비어 있어.
기대 결과는 같은 항목이 남는 것이야.
오류 메시지는 없고, 삭제 버튼은 새로고침 전에는 동작해.

현재 저장과 불러오기 흐름을 확인해 원인을 설명해 줘.
이 문제를 다시 확인할 검사를 보완하고,
수정 뒤 같은 입력·새로고침 순서로 다시 확인해 줘.

입력, 실제 결과, 기대 결과를 주면 AI가 같은 장면을 재현할 실마리를 얻습니다. 에러가 있다면 오류 문구와 발생 시점도 보냅니다. 화면을 공유할 때는 이름·주소·토큰 등 불필요한 개인정보와 비밀값을 가립니다.

수정이 계속 엉뚱한 곳으로 번지면 더 많은 지시를 덧붙이기 전에 현재 변경을 살펴봅니다. 마지막으로 정상 동작한 상태와 비교하고, 한 문제를 해결하는 범위로 줄여 다시 시작할 수 있습니다. 작업 도중 정상 상태를 커밋해 두면 비교와 복구의 기준이 됩니다.

지침 파일과 여러 에이전트는 언제 도움이 되나요?

프로젝트에서 반복해서 필요한 실행 명령, 코드 배치, 주의할 데이터 경계는 도구가 읽는 저장소 지침에 적어 둘 수 있습니다. Claude Code의 CLAUDE.md처럼 다음 작업에서도 필요한 맥락을 전달하는 용도입니다. 특정 오류를 한 번 겪었다는 이유로 모든 작업에 새 절차를 덧붙이기보다, 반복되는 문제와 관련있는 짧은 지침을 유지합니다.

독립된 자료 조사나 별개 파일의 검토는 다른 에이전트에 맡길 수 있습니다. 동시에 같은 파일을 고치는 작업은 충돌하기 쉬우므로 담당 범위를 나누고 결과를 합칠 사람이 필요합니다. 맡긴 뒤에는 나온 설명만 받지 말고 실제 변경과 검사 결과를 확인합니다. 하위 에이전트도 같은 사용 한도를 쓰므로 독립적으로 나눌 일이 있을 때 활용합니다.

접근 경계는 짧은 지침과 함께 실제 도구 권한 설정으로 확인합니다. 공개·데이터 변경처럼 영향이 큰 행동에 어떤 허용과 확인이 적용되는지 알고 맡기면 작업 중 판단할 지점도 분명해집니다.

지침, 테스트 명령, 브라우저 같은 실행 도구, 권한 경계가 함께 에이전트의 작업 환경을 이룹니다. 이런 바깥 구성을 흔히 **하네스(harness)**라고 부릅니다. 내 프로젝트에서는 우선 “무엇이 성공인지”와 “어떻게 확인하는지”부터 연결해 보면 됩니다. 새 프레임워크를 설치하기 전에도 시작할 수 있습니다.

다음 작업에서 바로 써볼 한 문장

관련 코드를 먼저 읽고 수정 범위와 확인 방법을 정해 줘. 구현 뒤에는 그 검사를 실행하고, 화면에서 내가 할 행동까지 확인해 줘.

여기에 내 기능의 성공 조건을 붙여 보세요. AI가 낸 코드를 받아 보는 데서 한 걸음 더 나아가, 원하는 동작이 확인될 때까지 작업을 이어갈 출발점이 됩니다.

참고한 자료

문서 확인일: 2026년 10월 15일.