AI에게 “이 코드 참고해서 기능 추가해줘”라고 했을 때, AI는 단순히 코드를 위에서 아래로 읽지 않는다. A를 이해하려면 B를 봐야 하고, B를 이해하려면 C를 봐야 하고, C를 이해하려면 다시 A로 돌아와야 한다. 이 과정이 재귀적 분석이다.
이 글에서는 재귀적 분석이 무엇인지, AI가 코드를 받았을 때 이 분석이 실제로 어떤 방식으로 작동하는지, 그리고 그것을 알면 AI에게 코드를 줄 때 무엇이 달라지는지를 다룬다.
재귀적 분석이란 무엇인가
재귀적 분석은 문제를 분석할 때 자기 자신과 같은 구조로 반복적으로 파고드는 방식이다. 큰 문제를 같은 형태의 작은 문제로 쪼개고, 그 작은 문제도 다시 같은 방식으로 쪼갠다.
구조는 항상 두 가지 요소로 이루어진다.
| 요소 | 역할 |
|---|---|
| 기저 조건(Base Case) | 더 이상 쪼갤 수 없는 최소 단위 — 여기서 분석이 멈춘다 |
| 재귀 단계(Recursive Step) | 문제를 같은 형태의 더 작은 문제로 분해하고 다시 파고드는 과정 |
폴더 안의 파일 개수를 센다고 생각해보면 직관적으로 이해된다. “이 폴더의 파일 수”를 알려면 직접 파일 수에 각 하위 폴더의 파일 수를 더해야 한다. 그런데 하위 폴더의 파일 수를 알려면 또 같은 질문을 반복해야 한다. 하위 폴더 안에 다시 하위 폴더가 있으면 또 파고든다. 이 과정이 재귀적 분석의 본질이다.
코드는 이 구조와 정확히 같다. 파일들이 서로를 참조하고, 함수가 다른 함수를 호출하고, 모델이 뷰를 바꾸면 URL이 영향을 받는다. 재귀적 분석 없이는 이 연결 구조를 제대로 따라갈 수 없다.
AI가 코드를 받았을 때 실제로 하는 일
“이 Django 모델 코드 보고, 검색 기능 추가해줘”라는 요청을 AI가 받았을 때 내부에서 어떤 일이 벌어지는지 구체적으로 따라가보자.
1단계 — 전체 구조 파악
AI는 먼저 코드 전체를 훑으며 어떤 종류의 코드인지 파악한다.
"이 코드는 뭘 하는 코드인가?"
→ Django 앱이다
→ 모델, 뷰, URL이 있다
2단계 — 구성요소 분해
전체 맥락을 잡은 뒤, 각 파일의 역할을 분리해서 읽는다.
"모델은 어떤 필드를 갖고 있나?"
→ name, status, last_inspection_date
→ 검색은 어느 필드 기준으로 해야 하나?
3단계 — 의존성 추적 (재귀가 시작되는 지점)
여기서부터 재귀적 분석이 본격적으로 작동한다.
"뷰에서 모델을 어떻게 쓰고 있나?"
→ ListView를 상속받고 있다
→ get_queryset()을 오버라이드하면 검색 가능하다
→ request.GET에서 파라미터를 받아야 한다
→ URL에 query string이 붙어야 한다
→ URL 패턴은 지금 어떻게 되어 있나? ← 다시 처음으로 돌아감
4단계 — 영향 범위 확인
"검색 기능을 추가하면 기존 코드 어디에 영향이 가나?"
→ 템플릿에서 form 태그가 필요하다
→ 템플릿은 지금 어떻게 생겼나? ← 또 다시 파고듦
AI가 코드를 분석할 때는 한 지점에서 시작해서 연결된 모든 곳을 타고 들어갔다가 돌아오는 과정이 반복된다. 이것이 재귀적 분석의 실제 모습이다.
패턴이 고정된 코드에서 재귀적 분석이 작동하는 방식
재귀적 분석의 가치가 더 두드러지는 상황이 있다. MongoDB 연결 코드, models.py, DB 설정처럼 패턴이 고정된 코드를 다룰 때다.
이런 코드는 새로운 창작이 필요한 코드가 아니다. 구조는 똑같고 값(변수)만 교체되는 코드다.
# 동작하는 코드
DATABASES = {
'default': {
'ENGINE': 'djongo',
'NAME': 'mydb', ← 이것만 바뀐다
'HOST': 'localhost',
}
}
AI는 이 상황에서 재귀적 분석을 통해 세 가지를 처리한다.
| 단계 | AI가 하는 일 |
|---|---|
| 패턴 인식 | 동작하는 코드의 구조를 파악한다 |
| 고정값 / 가변값 분리 | 바뀌면 안 되는 부분과 교체해야 할 부분을 구분한다 |
| 요구사항에 맞는 값 치환 | 요청에 맞는 값으로 교체해서 출력한다 |
모델명이나 필드명이 바뀌는 경우라면, AI의 재귀적 분석은 한 파일에서 끝나지 않는다. models.py에서 모델명이 바뀌면 views.py에서 참조하는 모델명도 바뀌어야 하고, admin.py에서 등록된 모델명도 맞춰야 하고, urls.py의 연결 구조도 확인해야 한다. 하나를 바꾸면 연결된 모든 곳을 추적해야 한다는 점에서 이것도 재귀적 분석의 연장이다.
그래서 AI에게 코드를 줄 때 뭐가 달라지나
재귀적 분석의 구조를 이해하면, AI에게 코드를 줄 때 어떻게 해야 결과가 달라지는지가 보인다.
AI의 재귀적 분석은 참조 관계를 따라가는 과정이다. 그런데 연결된 파일이 없으면 분석이 중간에 끊긴다. 중간에 끊긴 분석은 불완전한 코드로 이어진다.
| 요청 방식 | AI의 분석 결과 |
|---|---|
| “MongoDB 연결 코드 짜줘” | 범용 예시 코드 생성 — 내 환경과 맞지 않을 수 있다 |
| “이 코드 참고해서, DB 이름만 equipment_db로 바꿔줘” | 패턴 유지 + 값만 교체 |
| “이 코드 기준으로, 모델명은 Equipment, 필드는 name/status/date로 바꿔줘” + 연관 파일 함께 제공 | 재귀적 분석이 끊기지 않고 연관 파일까지 일관되게 수정 |
동작하는 코드 한 줄이 설명 열 줄보다 AI에게 훨씬 정확한 지시다. 이유는 간단하다. 설명은 AI가 재귀적 분석을 처음부터 새로 해야 하지만, 동작하는 코드는 재귀적 분석의 출발점을 바로 잡아주기 때문이다.
AI에게 코드를 줄 때 참조 관계에 있는 파일들을 함께 제공하는 것, 그리고 수정 범위를 명확하게 지정하는 것이 결과 품질을 가르는 핵심이다.
핵심 요약
재귀적 분석은 연결된 구조를 타고 들어갔다가 돌아오는 과정의 반복이다. AI가 코드를 참고해서 새 코드를 작성할 때 이 분석이 내부에서 작동하고 있다.
패턴이 고정된 코드(DB 연결, models.py 등)에서 AI는 창작자가 아니라 번역기로 작동한다. 구조를 인식하고, 고정값과 가변값을 분리하고, 요청에 맞는 값으로 치환한다.
재귀적 분석이 끊기지 않으려면, 동작하는 코드와 연관 파일을 함께 제공해야 한다. AI에게 맥락을 주는 것이 곧 재귀적 분석의 출발점을 잡아주는 일이다.
[링크 제안]
재귀적 분석이 실제 Django 코드에서 어떻게 작동하는지 바로 따라가보고 싶다면 이 글이 출발점이다.
재귀적 분석을 끊기지 않게 만들려면, AI에게 코드를 넘기기 전 설계 단계가 먼저다.
AI 프롬프트 설계 전반의 공식 참고 자료는 → OpenAI Prompt Engineering Guide에서 확인할 수 있다.
