에이전틱 코딩(Agentic Coding), AI가 제안한 것을 내가 모를 때 / 내가 코딩하는 방법

 

AI와 함께 코딩을 하다 보면 이런 상황이 반복된다.

나 : 문서 검색 기능이 필요해
AI : BM25 알고리즘으로 구현하겠습니다.
나 : 그게뭔데?

AI가 제안한 기술을 내가 모른다. 이때는 어떻게 해야할까? 전부 이해하고 넘어가야 하는가, 아니면 모르는 채로 진행해도 되는가?

사내 문서 검색 시스템을 만들면서 이 질문을 반복적으로 마주쳤다. BM25, MCP, SSE, 청킹 전략... 처음 듣는 것들이 계속 나왔다. 그 과정에서 나름의 기준을 정리하고 사고한 과정을 서술하겠다.

 

1. 실제로 일어난 일

검색 기능을 만들어야 했다. 약 500개의 MDX 문서에서 원하는 정보를 찾는 기능이다. AI에게 검색 기능 구현을 요청했더니 BM25라는 알고리즘으로 구현된 코드가 나왔다. 나는 BM25가 뭔지 몰랐다. 하지만 "키워드 기반 검색이고, 외부 DB없이 JSON 파일 하나로 동작한다"는 설명을 듣고 우리 상황에 맞겠다고 판단했다. 그리고 그대로 진행했다.

시스템은 잘 동작했다. 그런데 나중에 코드를 뜯어보면서 의문이 생겼다. `build-index.ts`에서 `bm25.ts`를 import 하는 걸 보고 AI에게 물었다. 아래는 실제 대화 기록이다.

나: "build-index.ts에서 사용된 bm25 알고리즘은 라이브러리형태로 제공되는거야?"
AI: "라이브러리가 아니라 직접 구현한 코드입니다. 약 80줄 정도의 간결한 구현입니다."
나: "직접 구현하는게 보통일반적인가? bm25는 유명한 알고리즘 아냐? 라이브러리로 제공되는게 없나?"
AI: "네, lunr, minisearch 같은 라이브러리가 있습니다. 하지만 알고리즘 자체가 단순해서 직접 구현하는 것도 흔합니다. 커스터마이징이 필요하면 직접 짜는 게 더 깔끔합니다."
나: "지금은 따로 커스텀 되어있는가?"

이 대화는 시스템을 만든 뒤에 일어났다. 만들 때가 아니라, 만든 다음에 코드를 들여다보면서 배운 것이다.

솔직히 말하면, 만들 때 나는 BM25의 수식과 동작 원리를 몰랐다. "키워드 매칭이 우리 상황에 맞고, 외부 의존이 없다"는 판단만 내리고 진행했다. 그리고 시스템이 동작한 후 코드를 뜯어보고, 질문하고, 점수가 어떻게 계산되는지 이해하기 시작했다.

처음부터 완벽히 이해하고 시작한 게 아니라, 일단 진행하고 나중에 깊이를 키운 것이다.

 

---

 

2. 이해의 타이밍

돌이켜보면, 이해가 필요한 시점이 세 번 있었다.

- 시작할 때

이걸 쓸지 말지, 이게 뭐고 / 왜 이걸 쓰고 / 대안은 뭔가?

BM25 = 키워드 기반 검색. 외부 의존 없음. 의미 검색은 못함
-> 우리 상황에 맞는가? -> 맞다 -> 진행

이 시점에서 수식을 몰라도 된다. "이걸 쓸지 말지"를 판단하는 데 수식은 필요 없다. 나는 여기까지만 이해하고 진행했다.

 

- 동작한 뒤

왜 이 결과가 나왔는가?

시스템이 동작한 뒤에 검색 결과가 이상한 경우가 나온다. "주문 취소"를 검색했는데 엉뚱한 문서가 1등이다. 이때 원인을 찾으려면 점수가 어떻게 계산되는지 알아야 한다.

BM25 점수 = IDF(희귀도) x TF(빈도, 포화 + 길이 보정)
-> 이 문서가 높은 점수를 받은 이유 : "주문"이라는 흔한 단어(IDF 낮음)보다 
"취소"라는 희귀한 단어(IDF 높음)가 많이 매칭 되었기 때문

이 시점에서 공식이 뭘 하는지 직관적으로 이해해야한다. 각 항이 "흔한 단어면 점수를 깎는다", "문서가 길면 점수를 깎는다" 정도로만 읽히면 충분하다. 수식을 유도하거나 수학적으로 증명할 필요는 없다. 나는 코드를 뜯어보면서 여기까지 도달했다.

 

- 개선할 때 

한계가 뭐고, 다음에 무엇을 해야 하는가?

BM25의 한계 : "숙소 등록"으로 검색하면 "객실 생성 API"를 못 찾음 (동의어 문제)
-> 임베딩 기반 벡터 검색을 병행해야 하나?
-> 현재 규모(500문서)에서 그게 필요한가?
-> 아직은 아니다. 규모가 커지면 그때 도입하자.

이 시점에서 대안 기술에 대한 이해도 필요하다. 하지만 그것도 "쓸지 말지 판단" 수준이면 된다.

핵심은 세 시점 모두 "전부 이해"가 아니라 "지금 필요한 만큼만 이해"라는 점이다. 그리고 그 깊이가 시간이 지나면서 자연스럽게 쌓인다.

 

---

3. 항상 이래도 되는 걸까?

아니다. BM25에서는 이 방식이 통했다. 하지만 항상 이런 건 아닐거다.

BM25를 전혀 모르고 진행해도 괜찮았던 이유가 있다.

- 검증된 표준 알고리즘이다. 30년간 쓰여온 공식이라 "이게 맞나?"하고 걱정할 필요가 없다.
- 500문서 규모의 사내 도구이다. 잘못되어도 영향 범위가 작고, 고쳐서 다시 배포하면 된다.
- AI가 구현을 담당했고, 동작 여부는 바로 확인할 수 있었다.

반대로, 이런 상황이었다면 모르고 넘어가면 안된다.

- 고객 데이터를 다루는 시스템의 암호화 방식
- 결제 로직의 동시성 처리
- 운영 중인 서비스의 DB 마이그레이션

이런 건 "동작하니까 됐다"로 넘어갈 수 없다. 잘못되면 되돌릴 수 없고, 고객에게 직접 피해가 간다.

기준은 리스크이다.

리스크 낮음 (사내 도구, 검증된 알고리즘, 되돌릴 수 있음)
-> 일단 진행하고 나중에 뜯어본다.

리스크 높음 (고객 영향, 보안, 되돌리기 어려움)
-> 판단할 만큼 이해하고 진행한다.

나는 BM25에서는 전자를 택했고, 그게 통했다. 하지만 실제 사내 결제 웹뷰를 유지보수할 때는 AI가 제안한 수정사항을 그대로 적용하지 않고, 이니시스 결제 흐름을 직접 이해한 뒤에 진행했다. 같은 사람이 같은 프로젝트에서도, 상황에 따라 다른 선택을 한다.

 

---

4. 어디까지 알아야 하는가의 기준

정리하면 기준은 두 가지이다.

(1) 내가 판단을 내려야 하는 부분인가?

내가 하는 일	필요한 이해 수준	예시
기술 선택	뭐고, 왜, 대안	BM25 vs 벡터 검색
품질 판단	왜 이 결과인가	검색 결과 디버깅
개선 방향 설정	한계와 대안	하이브리드 검색 도입 여부
코드 구현 세부사항	불필요	IDF 공식의 +0.5가 왜 0.5인지
파라미터 튜닝	효과를 이해할 수준	K1, B 값 조정

"코드 구현 세부사항"에 "불필요"라고 적은 게 의아할 순 있다. 이건 알고리즘 내부의 수학적 선택(스무딩 상수가 왜 0.5인지, 파라미터 기본값이 왜 이 숫자인지)을 한 줄 한 줄 검증할 필요는 없다는 뜻이다. 그건 테스트로 검증한다. 코드를 읽고 흐름을 파악하는 것과, 구현의 세부 선택을 검증하는 것은 다르다.

반면 "기술 선택"은 AI에게 위임할 수 없다. "BM25가 적합합니다"라는 AI의 제안을 수용할지 거부할지는 내가 판단해야 한다.

 

(2) 리스크가 얼마나 큰가?

리스크가 낮으면 진행 후 학습, 리스크가 높으면 학습 후 진행. 이 순서가 바뀌는 것뿐이다. 이해해야 한다는 사실 자체는 변하지 않는다.

타이밍이 다를 뿐이다.

 

---

5. 반복되는 과정

BM25만 그런 게 아니다. 이 프로젝트에서 AI가 제안하거나 사용한 기술 중 내가 처음 접한 것들이다.

기술	AI가 제안한 맥락	내가 판단한 것	나중에 더 공부한 것
조건부 청킹	문서 분할 전략	endpoint는 쪼개면 안된다.	H2 분할의 장단점
SSE 스트리밍	챗봇 응답 방식	글자 단위로 보여줘야 UX가 좋다.	SSE 프로토콜 구조
멀티스테이지 Docker	배포 이미지 최적화	이미지가 작으면 좋다	빌드 스테이지 분리 원리

 

패턴이 보인다.

1. AI가 제안한다
2. 리스크를 판단한다 -> 낮으면 진행, 높으면 먼저 이해
3. 진행한다
4. 동작한 뒤에 필요한 만큼 더 깊이 판다

모든 걸 미리 공부하고 시작한 게 아니다. 리스크가 낮은 것들은 진행하면서 배웠고, 리스크가 높은 것들은 이해한 뒤에 진행했다.

 

---

6. 그러면 아무것도 모르고 시작해도 될까?

아니다. 최소한의 기반 지식이 있어야 판단이 가능하다.

나 같은 경우는 프론트엔드 개발 경험이 기반이었다. HTTP 요청이 뭔지, JSON이 뭔지, 서버 구조를 일부 알고 있었기 때문에 AI의 제안을 판단할 수 있었다. 만약 프로그래밍 자체를 모르는 상태였다면 "BM25가 키워드 기반입니다"라는 설명도 판단 근거가 되지 못했을 것이다.

기반 지식이 있다 -> AI의 제안을 맥락 안에서 이해할 수 있다 -> 판단이 가능하다.
기반 지식이 없다 -> AI의 제안이 맞는지 틀리는지 모른다 -> 판단이 불가능하다.

에이전틱 코딩에서 사람의 역할은 "판단"이다. AI가 코드를 짜고, 기술을 제안하고, 구현 세부사항을 처리하더라도, 그것을 수용할지 거부할지, 이 방향이 맞는지 틀리는지를 판단하는 건 사람이다. 그 판단을 내리려면 해당 분야의 기초 지식은 있어야 한다.

다만 그 기초에서 새로운 기술을 만날 때, 전부 알고 시작하는 게 아니라 리스크에 따라 타이밍을 조절하면 된다는 것이다.

 

---

7. 정리

AI와 함께 일할 때 모르는 기술을 만나는 건 매번 일어난다. 그떄의 원칙은 두 가지이다.

리스크가 낮으면 : 일단 진행하고, 나중에 필요할 때 뜯어본다.
리스크가 높으면 : 판단할 수 있을 만큼 이해하고, 그 다음에 진행한다.

전부 알고 시작하는게 아니다. 전부 모르고 넘어가는 것도 아니다. 리스크에 따라 타이밍을 조절하는 것이 기준이다.

에이전틱 코딩에서 사람은 모든 코드를 이해하는 사람이 아니다. 지금 어디에 리스크가 있는지 판단하고, 필요한 깊이를 필요한 시점에 확보할 수 있는 사람이다.