
AI 코딩 도구가 일상이 되면서 개발자들 사이에서 '코드 작성'보다 '검증'이 중요하다는 얘기가 늘고 있어요. 혼자 서비스 여러 개를 운영하는 입장에서 이 흐름을 어떻게 보는지 정리했어요.
AI한테 기능 하나를 맡겼는데 빌드도 되고 화면도 잘 뜨는데, 그래도 이 코드를 그대로 배포해도 되는지 확신이 안 섰던 적 있으세요? 저는 요즘 거의 매주 그래요.
최근 해외 인디 개발자나 솔로프리너 쪽 글을 보다 보면 같은 얘기가 자주 보여요. AI가 코드를 대신 쓰게 되면서 개발자 일의 무게중심이 작성에서 검증으로 옮겨가고 있다는 거예요. 이 글에서는 그 얘기를 정리하고, 혼자 개발하는 입장에서 제 생각도 붙여볼게요.
요즘 이런 얘기가 많이 보여요
반응이 컸던 글들을 모아 보면 말하는 방식만 다를 뿐 내용은 비슷해요. 몇 년 뒤에도 개발자가 주로 코드를 직접 쓰거나 읽을 거라는 생각은 이제 잘 안 맞는다는 쪽이고, AI를 쓰는 코드베이스가 어느 정도 커지면 테스트는 있으면 좋은 게 아니라 꼭 있어야 하는 게 된다는 얘기도 있어요.
유닛, 통합, E2E 테스트에 정적 분석, 퍼징, 뮤테이션 테스트까지 언급돼요. 예전엔 큰 회사 QA 팀이 하는 일처럼 들리던 단어들이 혼자 개발하는 사람 피드에 올라오고 있어요.
그림 1.
AI는 왜 잘하는 사람을 더 잘하게 만들까요?
또 하나 자주 보이는 말이 있어요. AI는 원래 잘하던 사람은 더 잘하게 만들고, 경험이 적은 사람은 더 경험을 못 쌓게 만든다는 거예요. 처음엔 조금 과하다고 생각했는데, 써 볼수록 맞는 말 같아요.
차이는 결과물을 의심할 수 있느냐에서 나요. AI가 준 코드가 그럴듯하다는 건 누구나 알 수 있어요. 그런데 어디가 틀렸을지, 어떤 입력에서 깨질지 짐작하려면 그 영역을 직접 겪어봐야 해요. 이게 없으면 AI 결과를 그대로 받아들이게 되고, 직접 부딪혀 볼 기회도 같이 줄어들어요.
AI가 코드를 써 주는 건 맞아요. 그런데 그 코드가 맞는지는 여전히 사람이 정해야 해요.
그런데 테스트가 통과했다고 끝난 건 아니에요
저도 혼자 서비스 여러 개를 운영하면서 AI한테 구현을 꽤 맡기고 있어요. 돌려보니 제일 무서운 건 에러가 아니었어요. 에러는 시끄러워서 바로 보이거든요.
문제는 조용히 틀리는 쪽이에요. 테스트는 다 통과했는데 제가 테스트로 적지 않은 상황에서만 이상하게 동작하는 경우요. AI는 테스트를 통과시키는 데는 꽤 능숙한데, 테스트에 빠진 케이스가 있다는 걸 스스로 알려주지는 않아요. 그래서 요즘 제 시간은 코드를 쓰는 것보다 "뭘 확인해야 하지?"를 정하는 데 더 많이 들어가요.
| 예전에 시간을 많이 쓰던 곳 | 요즘 시간을 많이 쓰는 곳 |
|---|---|
| 기능 코드 직접 작성 | 어떤 케이스를 테스트할지 정하기 |
| 문법, API 사용법 찾기 | AI가 만든 코드에서 위험한 경계 읽기 |
| 디버깅하며 원인 찾기 | 배포 전에 실제 화면, 로그로 확인하기 |
테스트를 어디까지 해야 할까요?
그렇다고 테스트 종류를 전부 도입하자는 얘기는 아니에요. 혼자 개발할 때 그렇게 하면 테스트 관리만 하다가 하루가 끝나요. 제가 정한 기준은 단순해요. 틀렸을 때 피해가 큰 곳부터 촘촘하게 하는 거예요.
- 돈, 로그인, 개인정보가 오가는 곳은 테스트를 먼저 쓰고 AI에 구현을 맡겨요.
- 화면 문구나 레이아웃처럼 틀려도 금방 보이는 곳은 실제 화면을 확인하는 정도로 충분해요.
- 버그를 고칠 때는 그 버그를 재현하는 테스트를 먼저 하나 남겨요.
그리고 가끔 일부러 코드 한 줄을 망가뜨려 봐요. 테스트가 그걸 잡으면 다행이고, 그대로 통과하면 그 테스트는 사실 아무것도 확인하고 있지 않았던 거예요. 뮤테이션 테스트를 거창하게 도입하지 않아도 이 정도는 손으로 해 볼 수 있어요.
그림 2.
AI를 쓰냐 안 쓰냐보다 중요한 것
AI를 적극적으로 쓰는 개발자와 손으로 짜는 개발자 사이 결과 차이가 곧 눈에 띌 거라는 얘기도 있어요. 어느 쪽을 선택하든 그건 각자 몫이라고 봐요. 다만 AI를 쓴다면, 결과를 검증하는 능력은 따로 키워야 한다는 쪽에는 동의해요.
제가 느끼기에 AI 시대에 남는 개발자 일은 코드를 빨리 치는 게 아니라 무엇이 맞는 결과인지 정하고 그걸 확인할 장치를 만드는 것이에요. 이건 아직 AI한테 넘기기 어려운 영역이에요.
직접 해 보려면
- AI한테 기능을 맡기기 전에 "이게 되면 완료"인 조건을 체크리스트로 먼저 적어 보세요.
- 최근에 AI가 짠 함수 하나를 골라 조건문 하나를 일부러 뒤집어 보세요. 테스트가 실패하는지 확인해요.
- 배포 직전에 테스트 결과만 보지 말고 실제 화면이나 로그를 한 번 직접 열어 보세요.
이걸로도 안 되는 것
테스트를 아무리 꼼꼼하게 짜도 제가 생각하지 못한 상황은 여전히 빠져요. 테스트는 제가 아는 만큼만 지켜 줘요. 그래서 결국 실제 사용자가 쓰면서 나오는 문제는 모니터링과 피드백으로 잡을 수밖에 없어요.
그리고 이 글의 기준은 혼자 작은 서비스 몇 개를 운영하는 사람 입장이에요. 팀 규모가 크거나 코드베이스가 훨씬 큰 곳이라면 우선순위가 다를 수 있어요.
'개발일지(빌드로그)' 카테고리의 다른 글
| 정의되지 않은 동작 약 100개 중 45개, C 표준이 걷어낸다 (0) | 2026.10.11 |
|---|---|
| 연봉 넣으면 세후·대출·저축까지 이어지는 계산기, 플랜씨 (0) | 2026.10.10 |
| 자동화 감시를 켜는 순서: 등록 확인 먼저, 알림은 나중에 (0) | 2026.10.05 |
| 최근 21일, 자동화 감시를 켜며 확인한 것 (0) | 2026.09.29 |
| 이번 3주는 새 기능보다 감시 장치를 손봤어요 (0) | 2026.09.28 |