AI와 일할 때, 제가 지키려는 7가지 규칙

코드의 크기부터 조사, 데이터베이스, UI, 대화와 할 일 관리까지. AI가 빠르게 만든 결과를 실제로 유지할 수 있게 만드는 개인 작업 규칙.

2026년 7월 28일

AI를 쓰면 만들 수 있는 속도는 정말 빨라집니다. 문제는 빨라진 만큼 생각도 빨리 끝내 버리기 쉽다는 점입니다. 파일은 커지고, 화면은 처음부터 과해지고, 지금 필요한 답보다 훨씬 많은 설명이 쌓입니다.

AI와 일할 때 쓰는 방식은 이 밖에도 더 많습니다. 그중에서도 아래 일곱 가지는 작업이 커지거나 막혔을 때, 복잡도를 줄이고 다시 앞으로 나아가는 데 가장 큰 효과가 있었습니다. 완벽한 규칙이라기보다, 작업하다가 자주 흔들리는 지점을 다시 잡아 주는 기준에 가깝습니다.

1. 한 파일은 가능하면 200줄 안에서 끝낸다

코드를 200줄 이하로 만들자는 건 숫자 자체가 목적은 아닙니다. 한 파일이 너무 길어지면 AI에게 아무리 클린 아키텍처를 요청해도, 결국 상태·표현·통신·예외 처리가 한곳에 뭉치는 경우가 많았습니다.

200줄을 넘는다고 바로 잘못된 코드는 아닙니다. 다만 그때는 한 번 멈춥니다.

이 파일이 정말 한 가지 책임만 갖고 있나?

예를 들어 화면 컴포넌트가 길어졌다면 화면을 무작정 조각내기보다, 화면 상태를 다루는 훅, API 요청, 재사용 가능한 표시 컴포넌트 중 무엇이 섞였는지 먼저 봅니다. 줄 수 제한은 분리해야 할 책임을 발견하는 경보입니다.

AI에게도 처음부터 “기능을 구현하되, 파일 하나가 200줄을 크게 넘길 것 같으면 먼저 역할 분리를 제안해 줘”라고 말해 두는 편입니다. 나중에 큰 파일을 뜯어내는 것보다 처음 구조를 잡을 때 훨씬 덜 아픕니다.

2. 구현 전에, 이미 겪어 본 사람들의 기록을 먼저 찾는다

AI가 코드를 잘 만드는 것과, 그 코드가 현실에서 자주 부딪히는 문제를 이미 알고 있는 것은 다른 일입니다.

예를 들어 인증을 붙이거나 파일 업로드를 만들 때는 곧바로 코드를 쓰게 하지 않습니다. 먼저 공식 문서와 신뢰할 수 있는 기술 문서에서 다음을 찾아 보게 합니다.

이 기능에서 자주 놓치는 보안·성능·운영 문제는 무엇인지
사용하는 프레임워크가 권장하는 방식은 무엇인지
이미 실패한 사례에서 어떤 제약이 나왔는지

그다음에야 “찾은 근거를 기준으로 우리 구조에 맞는 선택지를 세 개만 정리해 줘”라고 합니다. 검색 결과를 그대로 따르는 것이 아니라, 다른 사람들이 오류를 해결하면서 쌓아 둔 경험을 설계의 재료로 가져오는 겁니다.

특히 라이브러리나 플랫폼처럼 계속 바뀌는 분야는 AI의 기억보다 현재 공식 문서를 우선합니다. 답을 먼저 받는 것보다, 답의 출발점을 확인하는 편이 결국 빠릅니다.

3. DB를 건드리면 인덱스도 같이 검토한다

테이블이나 쿼리를 추가할 때 AI는 동작하는 모델을 먼저 만들고, 인덱스는 빠뜨리는 경우가 있습니다. 개발 환경의 작은 데이터에서는 티가 안 나서 더 위험합니다.

그래서 DB를 추가하거나 수정하는 작업에는 항상 이 질문을 붙입니다.

이 화면과 API에서 어떤 조건으로 찾고, 어떤 순서로 정렬하며, 어떤 관계를 함께 조회하는가? 그 흐름에 맞는 인덱스가 있는가?

예를 들어 user_id로 목록을 찾고 created_at 최신순으로 보여 준다면, 단순히 두 컬럼에 각각 인덱스를 만드는 것으로 충분한지, (user_id, created_at)처럼 실제 조회 순서에 맞춘 복합 인덱스가 필요한지 확인합니다. 목록 페이지, 관리자 검색, 배치 작업처럼 서로 다른 조회 흐름도 같이 적어 둡니다.

이건 프롬프트 한 줄로만 남기지 않는 편이 좋습니다. 프로젝트 문서의 DB 변경 규칙에 스키마·쿼리 변경 시 인덱스 영향과 실행 계획을 검토한다는 기준을 넣어 두면, 다음 작업에서도 같은 확인을 반복할 수 있습니다.

4. UI는 처음부터 예쁘게 완성하려 하지 않는다

처음부터 “세련되고 화려하고 야무지게” 만들어 달라고 하면, AI는 그 요청을 성실하게 수행합니다. 문제는 그 결과가 정보보다 장식을 먼저 갖게 된다는 겁니다. 화면의 위계가 아직 없는 상태에서 카드, 그라데이션, 애니메이션이 쌓이면 이후 수정도 훨씬 어려워집니다.

처음에는 최대한 단순하게 만듭니다.

무엇을 보여 주는 화면인지
사용자가 어디를 눌러야 하는지
상태가 바뀌면 무엇이 달라지는지

이 세 가지가 분명해진 뒤에만 여백, 타이포그래피, 색, 움직임을 붙입니다. 디자인을 뒤로 미루는 것이 아니라, 정보의 순서가 먼저 보이게 하는 것입니다. 구조가 맞으면 예쁘게 만드는 작업도 훨씬 정확해집니다.

5. 핵심만 말해 달라고 한다

AI는 친절하게 주변 맥락과 대안까지 함께 설명합니다. 도움이 될 때도 있지만, 지금 하나를 결정해야 하는 순간에는 오히려 논점이 흐려집니다.

그래서 저는 필요한 답의 범위를 먼저 정합니다.

지금은 구현하지 말고, 이 선택의 장단점과 추천 하나만 말해 줘.

원인 후보를 세 개 이내로 좁히고, 먼저 확인할 것만 알려 줘.

짧은 답을 요구한다고 사고가 얕아지는 것은 아닙니다. 지금 필요한 판단을 먼저 끝내고, 더 깊은 설명은 필요해졌을 때 꺼내면 됩니다. 말의 양과 컨텍스트를 줄여 주는 Caveman 같은 도구를 참고하는 것도 이 원칙과 닿아 있습니다. 다만 도구가 판단을 대신해 주는 것은 아닙니다. 핵심을 고르는 일은 여전히 제가 해야 합니다.

6. 애매한 것은 하나씩 정리하고, `task.md`로 이어 간다

설계에서 가장 위험한 순간은 애매한 것이 여러 개인데, 한 번에 전부 결론 내리려 할 때입니다. 대화는 길어지는데 각 결정의 근거는 얕아집니다.

예를 들어 새 기능의 권한, 데이터 구조, 화면 흐름, 운영 정책이 모두 불분명하다면 “전체 설계를 만들어 줘”부터 말하지 않습니다. 먼저 하나만 잡습니다.

지금은 누가 이 기능을 사용할 수 있는지부터 정리하자. 데이터 구조나 화면은 그다음에 보자.

한 질문에 합의하고, 그 결정이 다음 질문의 전제가 되게 합니다. AI가 제안한 답도 “이 결정을 위해 우리가 아직 모르는 사실이 있나?”라고 다시 확인합니다. 이렇게 하면 대화가 길어져도 모호함이 쌓이지 않고 하나씩 사라집니다.

합의한 질문은 다음 작업으로 바로 이어지게 task.md에 남깁니다.

## 지금 할 일

- [ ] 예약 취소의 권한 기준 확정
- [ ] 취소 상태 전이 문서화
- [ ] 환불 쿼리와 인덱스 검토
- [ ] 관리자 화면의 최소 흐름 구현
- [ ] 실제 기기에서 검수

중요한 것은 할 일을 많이 적는 게 아닙니다. 지금 막힌 것이 무엇인지, 다음으로 무엇을 확인할지, 끝났다고 볼 기준이 무엇인지를 보이게 하는 겁니다. AI에게도 이 목록을 기준으로 “완료하지 않은 첫 항목만 다루고, 끝나면 결과와 다음 질문을 남겨 줘”라고 요청할 수 있습니다.

task.md는 거창한 프로젝트 관리 도구를 대신하지 않습니다. 대화에서 합의한 내용을 코드 작업으로 옮기고, 대화·문서·코드 사이에서 지금의 초점을 잃지 않게 해 줍니다.

7. 새 코드를 쓰기 전에, 이미 있는 것을 먼저 이해한다

AI에게 기능을 바로 만들어 달라고 하면, 비슷한 로직이 이미 있어도 새 함수와 새 컴포넌트를 만드는 일이 생깁니다. 동작은 해도 사용자 조회 방식이 둘이 되고, 에러 처리와 권한 기준도 조금씩 달라집니다. 시간이 갈수록 “어느 것을 써야 하는지”가 더 어려워집니다.

그래서 코드를 쓰기 전에 제가 먼저 어느 정도 현재 구조를 파악하고, AI에게도 기존 구현을 찾는 일을 먼저 시킵니다. 사용자 정보를 화면에 보여 주는 기능이 필요하다고 가정해 보겠습니다.

바로 “사용자 프로필을 만들어 줘”라고 하지 않고, 이렇게 요청합니다.

구현 전에 프로젝트에서 user, profile, userId와 관련된 API, 훅, 타입, 컴포넌트를 먼저 찾아 줘. 각각 어디서 쓰이는지 짧게 정리하고, 재사용할 수 있는 것이 있으면 그것을 기준으로 구현 계획을 제안해 줘. 새 로직이 꼭 필요할 때만 이유와 함께 추가해 줘.

그러면 AI는 예를 들어 기존 useUser 훅, 사용자 조회 함수, 공통 UserSummary 컴포넌트가 있는지 먼저 확인합니다. 이미 있다면 그 흐름에 맞춰 확장하고, 없다면 왜 새 경계가 필요한지 설명한 뒤 만듭니다.

핵심은 기존 코드를 무조건 재사용하는 것이 아닙니다. 지금 구조가 왜 그렇게 되어 있는지 이해한 뒤, 재사용할지 바꿀지를 의식적으로 선택하는 일입니다. 이 과정이 있어야 저도 구현을 따라갈 수 있고, AI가 만든 코드도 프로젝트 안에서 같은 언어를 쓰게 됩니다.

규칙은 AI를 통제하려는 장치가 아니다

이 규칙들은 AI의 답을 의심하기 위해 만든 것이 아닙니다. 빠른 답을 그대로 받아들이느라 제가 해야 할 판단을 놓치지 않기 위해 만들었습니다.

작은 파일로 책임을 확인하고, 경험을 찾아 출발점을 검증하고, DB의 다음 병목을 미리 살피고, UI의 구조를 먼저 잡습니다. 그리고 애매한 질문과 할 일을 한 번에 몰아넣지 않고, 새 코드를 쓰기 전에는 이미 있는 구조부터 확인합니다.

AI는 일을 엄청 빠르게 앞으로 보낼 수 있습니다. 저는 그 속도가 복잡함으로 바뀌지 않도록, 이 규칙들로 방향을 다시 확인하면서 같이 일하려고 합니다.