삽질을 안 하려면 삽을 잘 써야 하듯, AI도 어디에 쓸지를 알아야 제대로 써먹을 수 있다. 몇 달 간 써보면서 나름의 원칙이 생겼다.
Reading 능력을 활용하자
AI의 가장 강력한 능력은 코드를 생성하는 게 아니라 읽는 것이다. 방대한 코드베이스를 던져주고 “이 로직 흐름 설명해줘”, “이 버그 원인 뭐야” 같은 질문을 하면 사람보다 빠르게 핵심을 짚어준다. 직접 코드를 짜기 전에 기존 코드를 읽히고 분석시키는 데 먼저 쓰는 게 훨씬 효율적이다.
간단한 프론트 작업은 매우 쉬워졌다
간단한 UI 작업, 레이아웃 수정, 스타일링 같은 건 이제 거의 AI에 맡겨도 된다. 설명만 잘 하면 한번에 나온다.
단, 인증 과정이나 API 핑퐁이 필요한 부분은 여전히 잘 안 된다. 여러 서비스 간의 상태를 추적하면서 순서대로 요청을 주고받아야 하는 흐름은 컨텍스트가 너무 길어지고, 중간에 엇나가면 디버깅이 오히려 더 힘들어진다. 이런 건 직접 짜는 게 낫다.
Test-Driven이 매우 중요해졌다
AI가 코드를 짜주니까 테스트의 중요성이 역설적으로 더 올라갔다. 사람이 짠 코드는 짜면서 의도를 이해하니까 어디가 위험한지 감이 오는데, AI가 짠 코드는 돌려보기 전까진 모른다. 테스트 없이 AI 코드를 머지하는 건 눈 감고 건너는 거나 마찬가지다.
AI한테 코드를 시키기 전에 테스트부터 작성하고, 생성된 코드가 테스트를 통과하는지 확인하는 흐름이 가장 안전하다.
AI 활용은 선택이 아닌 필수다
It’s not optional anymore. 이건 이제 논쟁할 단계가 아니다. 문제는 잘 쓸 수 있는가에 있다.
처음엔 개발 전체를 맡기려고 했다. 결과는 참담했다. AI가 만들어 낸 코드가 동작은 하는데 의도와 다르거나, 불필요하게 복잡하거나, 엣지 케이스를 놓치거나. 결국 다시 짜는 시간이 더 걸렸다.
그래서 원칙을 세웠다:
- Planning을 시킨다 — 코드를 바로 짜게 하지 말고, 먼저 구조와 접근 방식을 설계하게 한다.
- 간단한 태스크만 맡긴다 — 반복적이고 명확한 작업은 AI로 scan out한다. 복잡한 비즈니스 로직은 직접 한다.
- 반드시 테스트한다 — AI가 만든 코드는 무조건 검증한다.
핵심 정리
- Reading, and Planning — AI의 읽기 능력을 최대한 활용하고, 코딩 전에 계획을 세우게 한다.
- Use for simple tasks only — 전부 맡기지 않는다. 명확하고 단순한 작업에만 쓴다.
- Testing — AI 코드는 테스트가 보증서다. 테스트 없으면 안 쓰는 게 낫다.
도구를 잘 쓰려면 도구의 한계를 알아야 한다. AI도 마찬가지다.