DevPilot

Devin에 API와 화면 수정을 함께 맡기면서 “PR은 백엔드와 프론트엔드로 나눠줘”라고 요청할 수 있습니다. 그런데 폴더가 다르다는 이유만으로 나누면, 먼저 배포된 쪽이 기존 화면을 깨뜨릴 수 있어요. 나눌 때 확인할 것은 각 PR이 끝난 시점의 동작입니다.PR마다 이 질문을 붙여보세요. “이 변경만 먼저 들어가도 지금 사용 중인 버전이 동작하는가?” 안 된다면 선행 변경과 적용 순서를 명시하거나, 호환되는 중간 단계를 먼저 만들어야 합니다.2026-10-01 작성. 아래 코드는 API 응답과 화면의 읽기 동작을 단순화한 설명용 예제입니다. 실제 Devin의 작업 결과나 운영 장애를 재현한 후기가 아닙니다.이름 하나를 바꿔도 서버와 화면의 순서가 생깁니다사용자 정보의 name을 displayName으..

“검색에 실패한 걸 결과가 없는 것으로 처리하면 안 돼.” 이런 설명을 작업마다 다시 적고 있다면, 다음 요청에도 필요한 기준인지부터 보세요. 프로젝트에서 계속 지킬 동작이라면 AGENTS.md에 남길 후보입니다. 이번 버그를 재현하는 입력이나 임시 우회 방법은 따로 두고요.옮길 것은 대화 전체가 아니라, 다음 작업에도 유효한 기준입니다. 짧은 프로젝트 규칙은 AGENTS.md에, 이번 작업의 입력과 완료 조건은 요청문에, 반복하는 긴 절차는 Skills나 별도 문서에 두는 구성을 권합니다.2026-09-28 공식 문서 확인 기준입니다. 아래 파일은 글을 위해 만든 설명용 예제이며, 실제 Devin 세션에서 규칙 적용률을 측정한 사용 후기는 아닙니다.“다음에도 같은 답인가?”로 남길 문장을 고릅니다지난 ..

Devin이 같은 오류를 다시 보고했을 때, 바로 “다시 고쳐줘”라고 보내기 전에 볼 것이 있습니다. 이번 시도에서 달라진 조건이 무엇인지입니다. 코드만 달라졌는지, 실행 환경도 달라졌는지, 아니면 같은 명령을 다시 돌렸는지부터 구분해야 해요.다시 시키기 전 확인할 것: 실패한 명령과 오류를 남기고, 실행 환경·요구사항·수정 방향 중 어디를 더 확인할지 정합니다. 다음 시도에는 가설과 확인 방법을 하나씩 붙입니다. 아래 실습에서는 설정이 빠진 실행이 세 번 모두 실패했고, 설정을 전달한 뒤 같은 소스로 정상 종료했습니다.2026-09-25 작성. Node.js v22.12.0에서 실행한 설명용 예제와 공식 문서를 바탕으로 정리했습니다. 세 번의 재실행은 직접 구성한 실습이며, 실제 Devin이 반복 실패..

같은 함수가 테스트 두 개는 모두 통과했습니다. 그런데 로딩 중과 네트워크 오류를 넣자 둘 다 “검색 결과 없음”으로 판정했어요. 테스트는 거짓말하지 않았습니다. 그 두 상황을 묻지 않았을 뿐입니다.Devin의 PR을 합치기 전에는 요청한 범위, 실제 변경, 검증한 조건을 대조합니다. 이번 설명용 예제에서 결함 함수는 정상 응답만 검사하면 2/2 통과했지만, 로딩·오류를 더하면 2/4만 통과했습니다. 발견한 문제를 어떤 수정 요청으로 돌려보낼지도 이어서 적었습니다.Devin이란? 요금과 한계 정리에서는 검색 화면 한 부분을 맡기는 요청서를 만들었습니다. 이번에는 그 요청의 결과를 검토하는 쪽으로 넘어갑니다.2026-09-24 작성. Node.js v22.12.0에서 실행한 독립 JavaScript 실습입..

내 컴퓨터에서는 배송비 3,000원이 잘 나오는데, 저장소를 새로 받으면 파일이 없다고 멈춥니다. 코드를 더 고치기 전에 확인할 것이 있어요. 실행에 필요한 파일이 커밋에도 들어 있는지입니다.오늘 확인한 함정: git status가 깨끗해도 필요한 파일이 .gitignore에 가려져 있을 수 있습니다. 로컬 실행, Git 추적, 커밋 포함, 새 복제본 실행을 차례로 확인해 봅니다.AI에게 기능을 맡길 때도 이 구분이 필요합니다. 에이전트가 실행한 폴더에는 생성한 파일이 남아 있으니까요. 그 자리에서 정상 동작했다는 결과만으로, 커밋을 받은 사람도 같은 상태에서 시작한다고 볼 수는 없습니다.2026-09-22 작성. 아래는 파일 누락을 의도적으로 만든 독립 실습입니다. 특정 AI 도구의 실제 출력이나 운영..

AI가 고친 배송비 계산은 버리고, 내가 바꾼 화면 제목은 남기고 싶습니다. 그런데 둘 다 같은 파일 안에 있다면요. 파일 전체를 되돌리는 버튼을 누르기 전에, 무엇을 기준으로 복원하는지부터 확인해야 합니다.먼저 답부터: 이미 섞인 변경은 diff를 읽고 골라 되돌려야 합니다. 다음 작업부터는 내 변경을 커밋해 기준점을 남기세요. Git이 미커밋 변경을 보고 “이 줄은 사람, 저 줄은 AI”라고 구분해 주지는 않습니다.2026-09-21 작성. 별도 임시 Git 저장소에서 실행한 실습입니다. 사람의 수정과 AI의 수정을 코드로 만들어 비교했으며, 특정 AI 도구의 실제 출력이나 운영 프로젝트의 사고 기록은 아닙니다. 실행 환경: macOS, Git 2.50.1(Apple Git-155), Python 3..

삽질 부검 1편의 첫 실패는 성능을 개선해 달라는 지시에서 시작했습니다. 어디가 느린지 확인하기 전에 수정부터 맡겼죠. 이어서 없는 함수를 가져다 쓴 일, 예외를 숨긴 채 수정을 끝낸 일도 다뤘고요.이번 편의 답: 원인을 모르면 조사부터 맡기고, 새 작업에는 현재 사실을, 수정할 때는 완료 조건을 알려주세요. 1편의 세 실패에 대응하는 요청문과 직접 실행할 예제를 담았습니다.작업 명세의 기본 항목은 이전 글에서 정리했습니다. 이번에는 일이 이미 꼬이기 시작한 순간에 어떤 말을 덧붙일지 다뤄볼게요. 지시문에 중간 정류장을 두는 셈입니다. 원인도 모른 채 수정 완료까지 곧장 달리지 않도록요.원인을 모르면 첫 요청은 조사에서 끝낸다느리다는 증상만 보고 “캐시를 넣어줘”라고 하면 해결 방법을 먼저 골라준 꼴입니..

핵심 요약: 지난 2주간 AI 에이전트에게 시켰다가 크게 세 번 날렸습니다. ① "성능 개선해줘"라는 모호한 지시가 부른 2시간 삽질(엉뚱한 계층을 뜯어고침), ② 하루 종일 한 세션을 끌고 간 대가로 컨텍스트가 방전돼 없는 함수를 지어낸 사건, ③ 버그를 "고쳤다"길래 봤더니 증상만 삼켜버린(try/except로 에러를 숨긴) 자신만만한 오답. 공통 원인은 하나였어요 — 에이전트는 지치지 않는 인턴이라, 길을 잘못 들어도 지치지 않고 계속 팝니다. 속도가 빠른 만큼 잘못된 방향으로도 빠르게 가요. 이 글은 각 사건의 실제 로그·날린 시간·토큰과, 재발을 막으려고 제가 세운 규칙 3개입니다.오늘은 자랑이 아니라 반성문입니다. AI 코딩 글은 대부분 "이렇게 잘 됐다"인데, 실제로 매일 쓰다 보면 안 되는..

핵심 요약: 8월 24일부로 Cursor가 Auto 모드의 정액요율($1.25/$6)을 없앴습니다. 이제 Auto는 "그때그때 라우팅된 모델의 정가"로 과금돼요 — Cursor 공식 안내도 "대부분의 요청은 요율이 올라간다"고 못 박았습니다. 대신 자사 모델(Composer 2.5·Grok) 포함량은 늘려줬고요. 실제로 제 사용량 그래프는 8/24 이후 같은 작업인데 더 빨리 닳기 시작했는데, 원인은 프론티어 모델(Claude·GPT)을 물린 Auto 요청이었습니다. 결론부터: 가격표(월 $20)는 그대로, 바뀐 건 "Auto 한 번의 원가"예요. 대응은 셋 — ① 일상은 Composer 2.5로 라우팅되게 두기 ② 프론티어는 난제에만 명시 지정 ③ 지출 한도 재점검. Enterprise 정액 유예도 9..

핵심 요약: "셋 중 뭐가 최고냐"는 틀린 질문입니다. 제가 같은 작업을 커서·클로드코드·코덱스에 똑같이 시켜본 실측 5편(디버깅·만들기·리팩토링·테스트·코드리뷰)의 결론은 하나로 모입니다 — 승자는 없고, 작업마다 잘하는 놈이 다르다. 요약하면: 맨바닥·빠른 초안·재현 쉬운 버그 = 코덱스(자율 실행 속도), 기존 코드에 얹기·앵커 주고 손보기 = 커서(IDE·@멘션), 원인 모를 버그·광범위 리팩토링·보안·심층 리뷰 = 클로드코드(맥락·깊이). 그래서 실전은 "하나 고르기"가 아니라 작업별로 나눠 쓰는 스택이고, 무엇을 쓰든 마지막 공통 결론은 같습니다 — 빨라질수록 검수가 실력.이 글에서 다루는 내용: 왜 "하나의 승자"가 없는지, 작업별 결정 매트릭스, 5개 실측의 한 줄 결론, 내 실제 조합, ..