LLM은 영상을 만들지 않습니다.
영상은 결정론 코드가 만들고,
LLM은 사람의 말을 코드로 번역할 뿐입니다.

 

우선 작업 결과부터 보고 가겠습니다.

프롬프트

우리 토리 소개 영상 만들자. 먼저 토리가 가만히 있는 장면 하나를 가지고 토리 얼굴을 천천히 클로즈업으로 5초 보여주고 아래에 텍스트로 우리 토리를 소개합니다를 띄워줘. 그 다음 애견카페에서 뛰어 노는 모습 10초 편집해서 아래에 똥꼬발랄한 우리 토리 띄워주고 산책하고 비오는 날 뛰고 밤에 달리는 신나게 뛰어노는 모습을 10초 보여주면서 산책도 좋아하는 우리 토리를 아래에 텍스트로 띄워줘. 그리고 마지막으로 하이파이브 하는 장면으로 우리 예쁜 토리입니다. 텍스트를 아래에 띄우면서 끝내줘.

"영상 편집 AI면, LLM한테 영상이랑 요청을 통째로 주면 되는 거 아냐?"

 

매번 같은 질문을 하게 됩니다. 요즘 멀티모달 모델은 영상도 보고 말도 알아듣습니다. 하지만 이 출발점에는 함정이 있습니다. 같은 요청을 두 번 돌리면 다른 결과가 나오고, 프레임 단위 타이밍은 어긋나고, 왜 그렇게 잘렸는지 아무도 설명할 수 없습니다. 그래서 역할을 분리했습니다.

 

LLM에게는 '의미'만 맡긴다.
픽셀, 프레임, 타이밍은 전부 결정론 함수가 만진다.

 

지난 편에서 강아지를 찾고(검출), 다시 알아보고(재식별), 움직임을 재는(모션) 첫 레이어를 세웠습니다. 이번 편은 그 위에 올라가는 나머지, 동작 판별(네번째 단계), 편집 실행(여섯번째 단계), 그리고 자연어 한 문단이 완성 숏폼이 되는 통합 테스트까지 다룹니다. 다섯번째 단계(내레이션)를 왜 건너뛰었는지도요. 결론부터 말하면 이번 구간에서 배운 가장 값진 교훈은 이것입니다. LLM은 못 하는 일에서 아주 자신있게 틀립니다.

---

4. 동작을 판별하다 - LLM에게 오지선다를

네번째 단계는 동작 판별입니다. 모션 곡선이 "움직인다"까지는 말해주지만, 그게 달리기인지 걷기인지 점프인지는 모릅니다. 여기서 처음으로 로컬 LLM(Gemma)이 등장합니다.

 

방식이 재미있었습니다. LLM에게 "이 강아지 뭐 하고 있어?"라고 서술형으로 묻지 않습니다. 오지선다 객관식(점프·달리기·걷기·앉기·엎드림)으로 묻고, 답의 첫 토큰 확률(logprob)을 읽습니다. 동적 동작들의 확률 합과 정적 동작들의 확률 합을 비교해 "동적인가 정적인가"부터 확정합니다. 서술형 답변은 파싱도 채점도 어렵지만, 객관식 확률은 숫자라서 파이프라인이 다룰 수 있습니다.

 

여기에 안전장치를 겹칩니다. LLM 판정이 모션 곡선과 일치하고 확신도 높을 때만 확정(commit), 아니면 모름(uncertain)으로 폴백. 네번째 단계는 혼자 다 맞혀야 하는 시험이 아니라, 애매하면 모르겠다고 말해도 되는 과정입니다. 모호함은 상위 레이어가 흡수합니다.

 

정답 라벨은 이번에도 사람이 만들었습니다. 모션 곡선으로 구간 후보를 자동으로 잘라 사람은 동작 이름만 채우게 해 품은 줄였지만 라벨 자체를 AI에게 맡기지는 않았습니다. 모델이 모델을 채점하는 자기참조가 되니까요.

 

결과는 확정된 구간의 동적/정적 정확도 1.00, 모름 비율 0.15(나쁜 footage 제외 시 0.07). 게이트(정확도 >= 0.90, 모름 <= 0.25) 통과입니다. 정직하게 적어두면 100%는 테스트 영상의 경계가 뚜렷했던 덕도 있습니다. 쉬운 건 확정하고 애매한 건 물러선다. 설계가 의도대로 작동했습니다.

---

5. 다섯번째 단계를 건너뛰다 - 완결된 경로부터

원래 설계에는 저작 모드가 두 개 있습니다.

• 모드 A (편집만) - "인트로 몇 초, 다음에 노는 장면…" 같은 편집 요청만으로 자막 숏폼을 만듭니다. TTS가 필요 없습니다.
• 모드 B (내레이션) - 대본을 쓰면 TTS 음성이 깔리고, 영상이 거기에 맞춰 편집됩니다. 다섯번째 단계(TTS)가 필요합니다.

그래서 일단 다섯번째 단계는 스킵하였습니다. 우선순위에서 뺐습니다. 이유는 단순합니다. 모드 A만으로도 처음부터 끝까지 완결된 제품 경로 하나가 성립하기 때문입니다. 부품을 하나 더 얹어 두 경로를 어설프게 구현하는 것보다 한 경로를 끝까지 뚫어 raw 폰 영상 -> 완성 숏폼을 증명하는 쪽이 먼저였습니다.

---

6. 자연어를 편집으로 - 번역가와 실행자

여섯번째 단계는 편집 실행입니다. 편집 요청 한 문단이 들어오면 LLM이 이를 블록 시퀀스로 번역합니다. "먼저 인트로, 그 다음 노는 장면 10초, 마지막에 하이파이브" — 블록마다 어떤 구간을(동적/정적), 몇 초로, 어떤 자막과 전환으로 쓸지가 담긴 편집 계획이 됩니다.

 

그리고 LLM의 일은 거기서 끝납니다. 계획을 받아 실제로 자르고 붙이고 줌하는 것은 전부 ffmpeg와 OpenCV, 즉 결정론 코드입니다. 같은 입력이면 같은 출력이 나옵니다.

 

실행 쪽에서 제일 고생한 건 줌이었습니다. 점차 확대되는 줌을 ffmpeg 내장 필터로 만들면 정수 반올림 때문에 화면이 부들부들 떨렸습니다. 세 번 갈아엎은 끝에 OpenCV로 float 보간 + 서브픽셀 렌더링을 직접 구현해 떨림을 잡았습니다. 한글 자막은 이 ffmpeg 빌드에 drawtext가 없어 PIL로 텍스트 이미지를 만들어 overlay로 태웠는데, 오히려 폰트와 스타일이 자유로워졌습니다. 출력은 분석용 저해상도가 아니라 원본 화질에서 다시 추출하고, 가로 / 세로가 섞인 폰 영상은 9:16 세로 + 블러 배경으로 통일했습니다.

 

편집 감각도 코드에 넣었습니다. 같은 장면을 잘게 쪼개 여기저기 흩뿌려진 영상이 나왔는데 어지러웠습니다. 소스당 한 컷, 길게. 이런 선호도 결정론 규칙이라 일관되게 지켜졌습니다.

---

7. 통합 테스트 - LLM의 자신감은 증거가 아니다

이제 전체를 처음부터 끝까지 돌립니다. 폰에서 갓 꺼낸 raw 영상 9개, 그리고 편집 요청 한 문단, "우리 토리를 소개합니다. 가만히 있는 인트로, 카페에서 노는 장면 10초, 산책, 비 오는 날, 밤에 달리기 합쳐서 10초, 하이파이브로 엔딩." 목표는 개발용 정답 라벨 없이 검출 결과만으로 도는 26.5초 세로 숏폼입니다.

 

당연히 한 번에 되지 않았습니다. 이 디버깅이 이번 편의 하이라이트입니다.

 

하이파이브가 사라졌습니다. 하이파이브는 앉아서 발을 드는 재주라, 오지선다(점프, 달리기, 걷기, 앉기, 엎드림)에는 자리가 없습니다. LLM은 가장 가까운 "앉기"로 분류했고, 동적 장면을 찾던 엔딩 블록은 빈손이 됐습니다. 수정은 라벨셋에 재주(묘기) 축을 추가하고, 편집 계획이 "묘기 장면"을 직접 고를 수 있게 했습니다. 이건 모델의 문제가 아니라 라벨셋 설계의 문제였습니다.

 

진짜 문제는 다음이었습니다. "가만히 있는 인트로"에 밤에 질주하는 영상이 들어왔습니다. 어둡고 흐릿한 밤 크롭을 LLM이 "정적"이라고 판단했습니다. 그것도 확신도 0.99로 판정한 겁니다. 처음엔 LLM과 모션 곡선의 판정을 확신도만큼 가중 투표시키는 절충안을 시도했다가 기각했습니다. LLM이 스스로 헷갈려할 때(확신 0.51)는 투표가 작동하지만, 확신하며 틀릴 때(0.99)는 투표가 오히려 오답에 힘을 실어줬습니다.

 

핵심 통찰은 이겁니다. LLM이 보는 건 정지된 크롭입니다. 흐릿하게 찍힌 강아지 사진 한 장으로는 뛰는 중인지 서 있는지 원리적으로 알 수 없습니다. 반면 모션 곡선(세번째 단계)은 카메라 움직임을 빼고 프레임 사이의 변화를 직접 잽니다. 그래서 절충 대신 역할을 완전히 분리했습니다.

축	담당	이유
동적/정적 (모션)	모션 곡선 전담	움직임의 직접 측정
동작 이름·재주 (의미)	LLM 전담	선명한 한 장의 의미 판정

LLM은 밤 크롭을 여전히 오판합니다. 하지만 이제 그 오판이 결과를 흔들지 못합니다. 못 하는 일을 아예 맡기지 않았으니까요. 재테스트 결과는 인트로, 카페 두 영상, 밤 질주 포함, 하이파이브 엔딩까지 전부 정상. 서로 물고 물리던 문제들이 역할 분리 하나로 동시에 풀렸습니다.

 

---

맺음말

여기까지로 자연어 한 문단에서 완성 숏폼으로 파이프라인이 생겼습니다.

• 동작 판별은 오지선다 확률로 묻되, 애매하면 물러서게 하고,
• 내레이션은 완결 경로를 먼저 증명하기 위해 뒤로 미루고,
• 편집 실행은 LLM이 번역한 계획을 결정론 코드가 재현 가능하게 렌더하고,
• 통합 테스트에서 LLM이 못 하는 축(모션)을 측정에게 완전히 넘겼습니다.

지난 편의 교훈이 눈보다 정답지였다면 이번 편은 그 연장입니다. LLM의 확신이 보는 것과 같이 증거가 아닙니다. 측정할 수 있는 것은 측정으로 판정하고, LLM에게는 의미의 번역만 맡긴다. 이러한 설계가 흐릿한 밤에 질주하는 영상 하나에서 실제로 값을 했습니다.

 

남은 것은 뒤로 미룬 다섯번째 단계(TTS 내레이션), 수동으로 적고 있는 장면 태그의 자동화, 그리고 이 파이프라인을 제품으로 감싸는 일입니다. 다음 편에서 이어가겠습니다.

---

이 글에서 다룬 고정 함수 분류층은 ProjectDavid의 일부입니다.

전체를 바닥부터 만드는 과정은 강의 3부작으로 정리하고 있고, 10월에 오픈 예정입니다.

→ 오픈 알림 받기

---

다음글

 

로컬 TTS(mlx-audio)로 영상 타임라인 컨트롤 - Narration First AI

GitHub - chessire/shelter-puppyContribute to chessire/shelter-puppy development by creating an account on GitHub.github.com목소리를 얹는 순간,화면이 음성에 맞춰 늘어나고,타임라인은 음성이 컨트롤합니다. 우선 작업 결과

chessire.tistory.com

이전글

 

YOLO11 해상도 함정: 골든셋으로 검증 - Measurement First AI

좋은 모델이 좋은 파이프라인을 만드는 게 아닙니다.좋은 채점 기준이,모델을 갈아끼울 수 있게 해줍니다. "AI 영상 분석이면 일단 모델부터 돌려보는 거 아냐?" 틀린 말은 아닙니다. YOLO를 붙이

chessire.tistory.com

관련글

좋은 모델이 좋은 파이프라인을 만드는 게 아닙니다.
좋은 채점 기준이,
모델을 갈아끼울 수 있게 해줍니다.

 

"AI 영상 분석이면 일단 모델부터 돌려보는 거 아냐?"

 

틀린 말은 아닙니다. YOLO를 붙이면 박스가 강아지를 따라다니고, 뭔가 되는 것처럼 보입니다. 하지만 이 출발점은 정작 중요한 질문을 가립니다. 모델을 바꿨을 때 정말 좋아진 건지, 그냥 좋아 보이는 건지, 눈으로 데모 몇 개를 비교하는 방식으로는 영영 답할 수 없습니다.

 

"모델을 채점할 '정답지'부터 만들고 그 다음에 모델을 붙인다."

 

지금 만들고 있는 것은 영상 속에서 강아지 한 마리를 찾아내고, 계속 따라가고, 언제 움직이고 언제 쉬는지 이해하는 파이프라인입니다. 이번 편은 그 첫 레이어(검출, 재식별, 모션)를 위 순서로 세운 과정만 다룹니다. 결론부터 말하면, 네 번의 큰 결정 중 두 번은 정답지가 제 직관을 기각했습니다.

 

---

0. 골든셋을 세우다 - 채점기 검증

골든셋(golden set)은 "정답이 확정된 표준 데이터셋"입니다. 한 번 만들어두면 어떤 모델을 넣든 어떤 파라미터를 바꾸든 항상 같은 표준으로 채점해 객관적으로 비교할 수 있습니다.

 

이 단계에서 만든 것이 정확히 이것입니다.

• fail-case가 서로 다른 영상 5개를 골라 CVAT로 라벨링한 정답(GT)
• 단계별 메트릭 라이브러리 (IDF1, MOTA, ID-switch, miss rate …)
• 언제든 한 줄로 재채점하는 eval / report CLI
• 그리고 채점기 자체를 검증하는 합성 단위테스트 30개

마지막 항목이 핵심입니다. 메트릭이 맞아야 모듈을 검증할 수 있습니다. 손으로 계산한 답과 채점기 출력이 일치하는지부터 확인했습니다. 자가 휘어 있으면, 그 뒤의 모든 측정이 무의미하니까요.

 

비유하면 골든셋은 운전면허 시험 코스입니다. 정답이 정해진 코스에서 합격하면 도로에서는 시험관 없이 달립니다. 골든셋은 "이 자동화를 믿어도 되는가?"를 증명하는 일회성 관문이지 운영 중에 반복하는 절차가 아닙니다.

---

1. 검출을 올리다 - 직관 검증

첫번째 단계는 YOLO + ByteTrack 기반의 검출, 추적입니다. 베이스라인(yolo11n)을 골든셋으로 채점해 보니 병목은 검출 누락이었습니다. 개선점은 두 군데 였습니다. 모델 체급을 올리거나(11n -> 11m), 입력 해상도를 올리거나(1536).

 

직관적으로는 둘 다 도움이 될 것 같습니다. 결과는 달랐습니다.

골든셋	채점	결과판정
체급 ↑ (11n→11m)	miss rate 0.40→0.27, ID-switch 48→23, IDF1 0.44→0.54	채택
해상도 ↑ (1536)	오히려 악화	기각

해상도를 올렸는데 왜 나빠질까요? 640으로 학습된 YOLO는 1536 입력에서 크고 가까운 물체를 오히려 놓쳤습니다. 학습 분포와 추론 분포가 어긋나기 때문입니다. "해상도가 높을수록 잘 보인다"는 사람이 보는 눈의 이야기일 뿐, 모델의 이야기가 아니었습니다.

 

골든셋이 없었다면 어땠을까요. 데모 영상 몇 개를 보고 "1536이 더 선명한데?"라며 역효과 나는 설정을 채택했을 가능성이 큽니다. 눈으로 하는 비교는 확증 편향일 뿐입니다.

 

또 하나의 발견은 역할 분리입니다. 검출 누락은 이 단계에서 잡되 같은 강아지를 계속 같은 강아지로 보는 정체성 문제는 다음 단계의 몫으로 넘겼습니다. 한 모듈에서 모든 걸 해결하려 하지 않았습니다.

---

2. 그 강아지를 다시 알아보다 - 애매하면 유저에게

두번째 단계는 re-ID입니다. 영상에 여러 마리가 나올 때, 그 중 주인공 강아지 한 마리를 화면에서 사라졌다 돌아와도 계속 같은 강아지로 인식해야 합니다.

 

구성은 세 가지입니다.

1. DINOv2 임베딩 - 강아지의 외형을 벡터로.
2. 시간 상호배제 - 같은 프레임에 동시에 등장하면 서로 다른 강아지라는 논리 제약. 임베딩이 헷갈려도 물리적으로 확정되는 정보입니다.
3. 유저 1탭 - 애매하면 유저에게 묻습니다.

세 번째가 설계의 갈림길입니다. 생김새가 비슷한 두 마리는 임베딩으로 완벽하게 구분할 수 없었습니다 (실측 오부착 1/12). 이걸 모델 개선으로 끝까지 밀어붙이는 대신, 애매한 케이스는 카드 한 장을 보여주고 탭 한 번으로 확정받는 구조를 택했습니다. 목표는 영상당 2탭 미만, 실측은 1.75탭이었고 통과였습니다.

 

"AI가 다 한다"보다, "AI가 90%를 하고 나머지는 유저가 탭 한 번으로 끝낸다"가 더 정직하고, 실제로 더 잘 작동했습니다.

 

이 단계에서도 골든셋이 직관을 한 번 더 기각했습니다. 레퍼런스 이미지를 여러 장 쓰는 멀티레퍼런스 매칭이 당연히 나을 거라 가정했는데 채점 결과 단순 평균 임베딩이 최고였습니다. 가설을 세우고, 채점하고, 데이터가 기각하면 접는다. 이 사이클이 두 단계 연속으로 "당연해 보이는 개선안"을 걸러냈습니다.

 

부수입도 있었습니다. 두번째 단계의 정답은 첫번째 단계의 골든셋에서 자동으로 도출됐습니다. 추가 라벨링 0. 정답지를 제대로 만들어두면 이렇게 재활용됩니다.

(추후에는 이미지 검증 프로세스도 추가해 유저의 탭도 제거하게 됩니다.)

---

3. 움직임을 숫자로 - 카메라 보정

세번째 단계는 모션 곡선입니다. 주인공 강아지의 박스 안에서 프레임 차이를 계산해, 동적/정적 구간을 나눕니다.

 

가장 재미있던 문제는 강아지가 아니라 카메라였습니다. 손으로 찍은 영상은 손떨림과 팬(pan)이 섞여 있어서, 가만히 앉아 있는 강아지도 화면상으로는 계속 움직인다고 판정했습니다. 해법은 배경 특징점으로 카메라의 움직임을 추정해 빼는 것. 카메라를 빼고 나면 강아지의 움직임만 남습니다.

 

검증 결과, 앉아 있는 강아지는 모션 값 0.8(정적), 노는 강아지는 13.8(동적), 앉아 있다가 화면 밖으로 나가는 전환도 잡았습니다.

 

다만 정직하게 적어두면, 세번째 단계는 정식 게이트가 아니라 눈검증으로 진행했습니다. 동적/정적 분리가 육안으로 명확해서 v1은 이 수준으로 갈음했습니다. 모든 단계에 같은 무게의 검증을 거는 건 오버엔지니어링입니다. 검증 강도는 리스크에 비례해서 정했습니다.

 

마지막으로 두번째 단계와 세번째 단계를 합쳤습니다. 모션을 전체 화면이 아니라 두번째 단계의 주인공으로 묶은 박스 기준으로 계산했습니다. 같은 영상이라도 주인공이 누구냐에 따라 답이 달라집니다. dog0을 주인공으로 잡으면 "정지", dog1로 잡으면 "화면 밖으로 나감." 박스가 그 강아지를 프레임 내내 따라간다는 증거입니다.

---

맺음말

여기까지가 첫 레이어입니다.

• 골든셋 하나로 이후 모든 결정을 채점하고,
• 검출에서 직관 대신 숫자로 레버를 고르고,
• 재식별은 애매한 나머지를 유저의 탭 한 번에 맡기고,
• 모션은 카메라를 빼고 강아지만 남겼습니다.

겉으로는 그저 모델 네 개의 나열처럼 보입니다. 하지만 이 배치에는 일관된 선택이 하나 깔려 있습니다. 모델은 갈아끼우는 부품이고, 골든셋은 그 부품을 채점하는 기준이라는 것. 부품은 계속 바뀝니다. 기준을 먼저 세운 쪽만 부품을 바꿀 수 있습니다.

 

다음 단계는 검출한 후, 추적된 강아지가 무엇을 하고 있는지(앉기, 뛰기, 놀기)를 판별하는 일입니다. 여기서부터 로컬 LLM이 등장합니다. 픽셀의 세계에서 의미의 세계로 넘어가는 경계인데, 그 경계선을 어디에 긋는지는 다음 편에서 풀어가겠습니다.

---

이 글에서 다룬 고정 함수 분류층은 ProjectDavid의 일부입니다.

전체를 바닥부터 만드는 과정은 강의 3부작으로 정리하고 있고, 10월에 오픈 예정입니다.

→ 오픈 알림 받기

---

다음글

이전글

관련글

1. 강아지를 입양했다

기술을 먼저 정하고 문제를 찾은 게 아닙니다.
한 마리를 데려오고 나서야
풀어야 할 문제가 보였습니다.

 AI로 무언가를 만들어보려던 참이었습니다. 도구는 손에 있는데 무엇을 풀지가 없던 흔한 상태였습니다.

 최근에 강아지를 입양해왔습니다. 5월 초부터 마음을 정해두고, 아내가 매일같이 보호 글을 들여다보며 인연을 찾았습니다. 그렇게 5월 24일, 강릉의 한 보호소와 연계된 임시보호자님에게 있던 아기 강아지를 데려왔습니다.

 이 아이의 사정은 이랬습니다. 떠돌이 어미가 낳은 새끼들 중 하나였고, 새끼들만 구조되었고 어미는 끝내 구조되지 못했다고 들었습니다. 세 마리 중 둘은 먼저 가족을 찾았고, 가장 오래 떠나지 못하고 남아 있던 아이가 우리에게 왔습니다.

 데려오는 과정에서 예상하지 못한 걸 봤습니다. 임시보호자와 입양 희망자 사이에서 오가는 소통, 정보, 그 사이의 불편함이 분명히 존재했습니다. 사람 손만으로는 메우기 버거운 자리였습니다.

 그 순간 두 가지가 겹쳤습니다. 풀 문제를 찾던 나, 그리고 눈앞에 보인 진짜 불편함. 마침 AI를 만들고 싶었던 저는 그 틈을 AI로 메울 수 있겠다 싶었습니다. 그래서 결심했습니다. 이 틈을 내 능력으로 메워보자고요.

 이 글은 그 결심에서 출발한 기록입니다. 그리고 다음 이야기들은 "왜 로컬인지", "왜 이렇게 도구를 쪼갰는지"를 다뤄보고자 합니다.

2. 영상 - 왜 전부 LLM에 맡기지 않을까?

"AI한테 영상 던지고 '이 강아지 뭐 해?' 물어보면 되잖아."
이 방법은 가장 비싸고 가장 느리게 도착하는 방법입니다.

 보호소 강아지의 영상들을 가지고 입양 공고 콘텐츠로 만든다고 해봅시다. 멀티모달 LLM에 영상을 통째로 밀어 넣으면 끝날 것 같습니다. 하지만 이 출발점은 비용도 속도도 가장 안 좋은 형태로 시작됩니다.

 여기서 짚어야 할 게 있습니다. "AI"는 한 덩어리가 아니라 파이프라인입니다. 영상 한 편을 처리하는 데에도 성격이 다른 셋이 섞입니다.

1. 고전 알고리즘 (OpenCV) - 학습이 없습니다. 수학과 규칙으로 돕니다. 빠르고, 싸고, 결과가 일정합니다.
2. 학습된 전용 신경망 (YOLO) - AI지만 "검출" 한 가지에 특화돼 있습니다. 프레임마다 강아지의 박스와 위치를 찾습니다.
3. 생성형 LLM (gemma) - 의미를 판단합니다. "이 강아지는 지금 사람을 반기는 중"이라는 해석. 강력하지만 느리고, 비싸고, 가끔 틀립니다.

 만약 강아지가 화면 어디 있는지 박스 좌표를 찾는 일까지 LLM에 시키면 어떻게 될까요? 느리고, 부정확하고, 비용만 듭니다. 그건 YOLO가 훨씬 잘하고 싸게 하는 일입니다.

 그래서 설계의 핵심은 이렇게 정리됩니다.

 잘 만든 설계는 무거운 생성형 LLM을 '꼭 필요한 한 스텝'에만 씁니다. 나머지는 싸고 빠른 도구로 분리합니다.

 실제 영상 한 편은 이렇게 흘러갑니다.

• 프레임 자르기·인코딩·자막 입히기 -> ffmpeg (그냥 도구)
• 강아지가 어디 있나(박스) -> YOLO (검출)
• 그 강아지를 영상 내내 같은 ID로 유지 -> ByteTrack (추적)
• 마지막에 딱 한 번, "이 장면을 입양 공고용으로 어떻게 설명할까"를 저작 -> gemma (의미·생성)
• 대본을 나레이션 음성으로 입힌다 -> mlx-audio (TTS)

 작은 비영리에서 이건 취향이 아닌 비용 절감입니다. LLM 호출 한 번이 곧 비용이고 솔로 운영에서 느린 파이프라인은 곧 굴리지 못하는 파이프라인이 됩니다. 무거운 도구를 아껴 쓰는 설계가 비영리 사업을 지속 가능하게 만드는 조건이 될 수 있습니다.

 이 "계층 분리"는 영상에만 해당하는 이야기가 아닙니다. 사실 이 프로젝트 전체를 관통하는 질문이고 다음 DB 이야기도 똑같은 자리에서 출발합니다.

3. DB - 왜 Postgres와 벡터DB를 같이 둘까?

하나는 "정확히 일치하는 것"을 찾고
다른 하나는 "비슷한 의미"를 찾습니다.

 DB를 두 개나 쓴다고 하면 과해 보입니다. "그냥 데이터베이스 하나면 되지 않나?" 하지만 이건 중복이 아니라 2번에서 본 것과 똑같은 역할 분리입니다. 두 DB는 애초에 답하는 질문이 다릅니다.

1. PostgreSQL
   "정확히 일치하는 것"을 찾는다. 회원, 강아지 공고, 입양 신청처럼 행과 열로 떨어지는 데이터입니다. "보호 중이고, 중성화 완료이고, 3살 이하인 강아지" — 조건이 명확하고, 답도 딱 떨어집니다. 이러한 과정은 관계형 DB가 최적입니다.
2. 벡터DB(chromadb)
   "비슷한 의미"를 찾는다. "사람을 잘 따르고 아파트에서도 키울 만한 순한 아이" 같은 질문은 다릅니다. 어느 칸에도 그렇게 적혀 있지 않습니다. 이건 의미가 가까운 데이터를 찾는 일이고 텍스트를 숫자 벡터로 바꿔(임베딩) 거리로 비교해야 됩니다. 관계형 DB의 WHERE 조건으로는 풀기 어려운 문제입니다.

 그래서 둘은 대체재가 아닙니다. 하나는 사실을 정확히 찾고, 하나는 의미를 비슷하게 찾습니다. 응대봇이 "이 조건에 맞는 강아지"(Postgres)와 "이 느낌의 강아지"(벡터DB)를 동시에 답하려면 둘 다 필요합니다.

 이게 2번의 영상 이야기와 똑같은 자리인 이유가 여기 있습니다. "만능 도구 하나로 다 해결한다"가 아니라 "질문의 성격에 맞는 도구를 선택한다". LLM에 전부 안 시키듯, DB도 한 종류에 전부 안 맡깁니다.

 다만 솔직히 둘 다 끌고 가는 건 비용입니다. 운영할 DB가 둘이 되니까요. 그래서 지금은 명확히 분리해 두되, 규모가 커지면 한쪽으로 합치는 길도 열어둡니다. PostgreSQL에 벡터 검색 확장(pgvector)을 얹어 한 DB에서 사실과 의미를 같이 다루는 선택지입니다. 초기에는 역할을 선명하게 분리하고, 규모가 커지면 운영 부담을 줄이는 쪽으로 통합하려 합니다.

4. 응대봇 - 왜 로컬이며, 왜 이 모델일까?

똑똑한 모델 하나를 고르는 문제가 아닙니다.
"무엇을 사용해야 하는가"와
"어떤 일에 어떤 모델을 쓰는가"입니다.

 입양 문의에 답하는 봇을 만든다고 해봅시다. 가장 쉬운 길은 외부 API(예: GPT)를 부르는 겁니다. 그런데 그 길을 택하는 순간, 1편 첫머리에서 던졌던 질문이 그대로 돌아옵니다. 무엇을 로컬에 두고 무엇을 밖에 맡길 것인가.

 왜 로컬(Ollama)인가. 세 가지 이유입니다.

• 데이터. 강아지 정보, 보호 기록, 입양 신청자 문의가 매 호출마다 외부 서버로 나갑니다. 명분 사업에서 보호 동물과 신청자의 데이터를 남의 서버에 흘리는 것은 가볍지 않습니다. 로컬은 그 정보들이 내 기기 밖으로 안 흘러나갑니다.
• 비용. 외부 API는 호출당 과금입니다. 응대봇은 많이 부를수록 가치가 큰데 많이 부를수록 그대로 토큰 값이 됩니다. 로컬 모델은 전기값 외에 호출당 비용이 0입니다.
• 통제. 모델이 갑자기 바뀌거나 가격이 오르거나 정책으로 막히는 일에서 자유롭습니다. 예측 가능함이 곧 안정성입니다.

왜 이 모델 조합인가. 여기서도 2번의 "계층 분리"가 그대로 반복됩니다. 응대봇은 모델 하나가 아니라 역할이 다른 둘로 작동합니다.

• bge-m3 (임베딩) — 대화하지 않습니다. 텍스트를 숫자 벡터로 바꾸는 일만 합니다. "이 강아지 설명"과 "사용자 질문"을 같은 좌표 공간에 올려 의미가 가까운지를 잴 수 있게 만듭니다. 한국어 성능이 좋아 강아지 데이터에 적합합니다.
• gemma (생성) — 답을 만듭니다. 검색해 온 데이터를 읽고, 영상을 해석하며, 사람에게 건넬 문장으로 풀어냅니다.

이 둘이 3번의 두 DB와 맞물려 하나의 흐름이 됩니다. 이게 RAG입니다.

1. 사용자가 묻습니다. "사람 잘 따르고 아파트에서도 키울 만한 아이 있어요?"
2. bge-m3가 질문을 벡터로 바꾸고 벡터DB에서 의미가 가까운 강아지를 꺼냅니다. (동시에 Postgres로 "보호중, 입양가능" 같은 사실 조건도 거릅니다.)
3. 그렇게 추려진 진짜 데이터를 gemma에게 건네며 답을 만들게 합니다.

 RAG의 핵심은 gemma가 아는 척 지어내지 않게 만드는 겁니다. 모델의 메모리가 아니라 우리 DB의 실제 강아지 데이터를 근거로 답하니까요. 있지도 않은 강아지를 추천하는 환각은 단순 오류가 아니라 신뢰 문제입니다. RAG는 그 위험을 구조로 막습니다.

모델 사양의 선택. gemma는 26B 규모지만 MoE 구조라 토큰당 약 4B만 활성화됩니다. 전체는 메모리에 올라가되 속도는 작은 모델처럼 나오는 절충입니다. 거기에 4비트 양자화(q4_K_M)를 더해 메모리를 줄여 워크스테이션이 아닌 한 대의 맥 안에 들어오게 맞췄습니다. "가장 큰 모델"이 아니라 "이 기기에서 굴러가는 충분히 똑똑한 모델"을 고른 겁니다.

 결국 이 섹션도 같은 자리로 돌아옵니다. 강력한 모델 하나로 다 하는 게 아니라 일을 쪼개 각자에게 맞는 도구를 붙이고, 그 전부를 로컬에 두는 것입니다.

5. 프론트엔드와 백엔드 - 왜 Django며 왜 Vite에서 Remix일까?

지금 필요한 것과 나중에 필요할 것은 다릅니다.
좋은 선택은 지금을 빠르게 해결하고
나중의 선택지도 닫지 않습니다.

 플랫폼엔 두 축이 있습니다. 데이터를 다루는 백엔드와 화면을 그리는 프론트엔드입니다. 둘 다 선택지가 넘치는데 기준은 하나였습니다. 지금 단계에서 가장 적은 공수로 가장 멀리 가는 길.

왜 FastAPI가 아니라 Django인가.

 파이썬 백엔드라면 가벼운 FastAPI도 강력한 후보입니다. 그런데 이 프로젝트는 CRUD가 많은 플랫폼으로 예상됩니다. 강아지 공고 등록과 수정, 임보자 관리, 입양 신청 처리에 데이터를 넣고 빼는 화면이 끝없이 필요합니다.

 Django는 여기서 결정적인 걸 공짜로 줍니다.

• Admin 패널 내장. 공고·신청·회원 관리 화면을 자동으로 생성해줍니다. 프론트를 한 줄도 안 짜도 데이터를 넣고 바로 운영·테스트할 수 있습니다. 솔로 운영에서 이건 몇 주를 아끼는 차이입니다.
• ORM과 마이그레이션, 인증 기본 제공. FastAPI라면 직접 골라 붙여야 할 조각들이 처음부터 한 묶음으로 옵니다.

 무엇보다 4번까지 만든 AI 코드(Ollama, RAG, YOLO)가 전부 파이썬입니다. Django도 파이썬이라 같은 백엔드 안에서 AI와 플랫폼 로직이 함께 돕니다. 언어가 갈리지 않는다는 것은 곧 개발 속도를 빠르게 합니다.

 FastAPI의 가벼움이 빛나는 자리도 분명 있습니다. 다만 CRUD가 많은 플랫폼, 1인 운영이라는 이 조건에선 덜어주는 일의 양이 Django 쪽이 압도적이었습니다.

왜 한 번에 안 가고 단계적으로 Vite에서 Remix인가.

프론트는 처음부터 정답을 고르지 않았습니다. 단계마다 필요가 다르기 때문입니다.

• MVP 단계 = Vite + React. 지금 필요한 건 빠른 출시입니다. Vite는 가볍고 빠른 개발 환경으로 React 화면을 즉시 띄웁니다. 단점도 분명합니다. 순수 SPA라 SSR이 없어 검색 노출(SEO)과 링크 미리보기가 약합니다. MVP에선 감수할 수 있는 약점입니다. 아직 공개 공고를 검색에 태울 단계가 아니니까요.
• 프로덕트 단계 = Remix(SSR). 공개 입양 공고가 검색에 잡히고, 카톡·인스타에 링크를 붙였을 때 미리보기가 떠야 하는 순간이 옵니다. 그때 SSR이 필요해지고, Remix로 넘어갑니다. Django API 백엔드와 역할이 겹치지 않아 조합도 깔끔합니다.

 그래서 핵심은 단계 전략입니다. 지금은 발견성(SEO)을 포기하고 출시 속도를 빠르게 합니다. 나중에 발견성이 필요해지면 그때 SSR로 갈아탑니다. 처음부터 Remix로 시작해 무겁게 가는 대신 지금의 문제를 가장 빨리 풀면서 나중의 선택지도 닫지 않습니다.

맺음말

 다섯 개의 질문은 사실 하나인 듯합니다. 영상도, DB도, 응대봇도, 프론트엔드도, 백엔드도 전부 같은 자리로 수렴했습니다. 강력한 도구 하나로 다 풀지 않는다. 일을 쪼개 각자에게 맞는 도구를 붙인다. 그리고 가능한 많은 것을 로컬에 둔다는 것입니다.

 이건 취향이 아니었습니다. 개인이 굴리는 작은 비영리에서 무거운 것을 아껴 쓰는 설계만이 지속 가능하니까요. 가장 비싼 도구를 가장 적게 쓰는 법을 아는 것, 그것이 노하우가 됩니다.

도구는 이렇게 깔았고(1편), 왜 그렇게 골랐는지도 풀었습니다(2편). 다음은 이걸로 실제로 무엇을 만드는가입니다.

다음글

이전글

관련글

AI는 한 덩어리가 아닙니다.
역할이 다른 도구들을,
한 대의 맥 위에 포개는 일입니다.

"유기견 입양에 AI를 붙인다"고 하면, 보통 이렇게 떠올립니다.
"그냥 ChatGPT API 부르면 되는 거 아냐?"

틀린 말은 아닙니다. 하지만 이 출발점은 정작 중요한 걸 가립니다. 강아지 정보와 영상 같은 데이터가 매 호출마다 외부로 나가고, 호출량만큼 비용이 붙고, 모델·데이터의 통제권은 내 손을 떠납니다. 작은 비영리 명분 사업에서 이 셋은 가볍지 않은 비용입니다.

그래서 질문을 바꿨습니다.

"무엇을 내 손 안(로컬)에 두고, 무엇만 밖에 맡길 것인가?"

이 글은 그 경계를, 노트북 한 대 위에 세우는 과정입니다. 선택의 이유는 다음 편으로 미루고, 이번 편은 "무엇을 어떻게 깔았는가"만 다룹니다.

1. AI 플랫폼을 설계하다 - 한 대의 맥에 무엇이 올라가나

세울 것은 세 개의 계층입니다.

1. Python 계층 — AI 코드(LLM·RAG·영상)와 백엔드(Django)가 같은 언어로 도는 곳.
2. 데이터 계층 — 표 형태 데이터를 담는 PostgreSQL.
3. Node 계층 — 화면(React)을 띄우는 프론트엔드 런타임.

핵심은, 이질적으로 보이는 이 조각들이 대부분 파이썬 하나로 묶인다는 점입니다. 강아지 공고 관리도, 응대봇도, 영상 분석도 전부 파이썬 위에서 돕니다. 그래서 환경설정의 무게중심도 자연히 파이썬에 실립니다.

2. Python 계층 - AI와 백엔드가 같은 언어로 돈다

맥 기본 파이썬은 버전이 낡아 개발용으로는 권장되지 않습니다. brew로 최신을 깔고, 프로젝트 전용 가상환경(venv)을 만듭니다.

brew install python
python3 --version          # 3.12 / 3.13 나오면 OK
which python3              # /opt/homebrew/bin/python3 이면 brew 거 잡힌 것

# 프로젝트 전용 가상환경
python3 -m venv ~/ai/venv
source ~/ai/venv/bin/activate   # 프롬프트에 (venv) 뜨면 활성
pip install -U pip

그 위에 세 묶음을 올립니다. LLM·RAG 스택, 영상 파이프라인, 그리고 백엔드(Django).

# LLM·RAG — 로컬 모델 클라이언트 + 벡터DB
pip install ollama chromadb

# 영상 파이프라인
brew install ffmpeg                            # 영상 자르기·인코딩·자막 입히기
pip install opencv-python                      # 프레임 추출
pip install ultralytics                        # YOLO(검출) + ByteTrack(추적)
pip install mlx-audio soundfile sounddevice    # TTS — 대본을 나레이션 음성으로 (애플 실리콘 최적)

# 백엔드 — Django + REST + DB 드라이버
pip install django djangorestframework django-cors-headers psycopg2-binary
django-admin startproject config .        # 현재 폴더에 프로젝트 생성
python manage.py runserver                # http://127.0.0.1:8000 뜨면 OK

로컬 LLM 본체인 Ollama는 코드 라이브러리가 아니라 독립 서버라 brew로 깝니다. 위에서 깐 ollama(pip)는 그 서버를 파이썬에서 부르는 리모컨이고, 지금 까는 본체가 TV입니다.

brew install ollama
brew services start ollama        # 재부팅해도 자동으로 뜨는 백그라운드 서비스

ollama pull bge-m3                 # 임베딩 모델 (작고 빠름, 첫 성공)
ollama pull gemma4:26b-a4b-it-q4_K_M   # 멀티모달 본체 (비전+텍스트)

ollama run gemma4:26b-a4b-it-q4_K_M "안녕, 한국어 돼?"   # 응답 나오면 /bye

이 한 덩어리만으로 "텍스트를 벡터로 바꾸고(bge-m3), 의미가 비슷한 데이터를 꺼내(chromadb), 그걸 보고 답하는(gemma)" 응대봇의 뼈대가 한 대의 맥 안에 들어옵니다.

3. PostgreSQL - 구조화 데이터의 자리

회원, 강아지 공고, 입양 신청처럼 행과 열로 떨어지는 데이터는 관계형 DB에 둡니다.

brew install postgresql
brew services start postgresql    # ollama처럼 백그라운드 서비스로

조금 전 깐 chromadb와는 역할이 다릅니다. postgres는 구조화 데이터, chromadb는 의미 검색용 벡터입니다. 대체재가 아니라 함께 씁니다. (왜 둘 다 필요한지는 다음 편에서.)

4. Node 계층 - 화면을 띄우다

프론트엔드(React)를 돌릴 런타임입니다.

brew install node          # node + npm 같이 들어옴
node --version             # 20 이상

npm create vite@latest     # React 선택 (MVP용 SPA)

MVP는 가볍고 빠른 Vite + React로 갑니다. 검색 노출(SEO)이 필요한 프로덕트 단계에서 SSR 프레임워크로 넘어갈 여지를 남겨두지만, 그 갈림길의 이야기도 다음 편 몫입니다. (참고로 create-react-app은 폐기되어 쓰지 않습니다.)

맺음말

여기까지가 골격입니다.

• Python 하나에 AI와 백엔드를 포개고,
• Postgres로 구조화 데이터를 받치고,
• Node로 화면을 띄운다.

겉으로는 그저 brew install과 pip install의 나열처럼 보입니다. 하지만 이 배치에는 일관된 선택이 하나 깔려 있습니다. 가능한 많은 것을 외부 API가 아니라 내 손 안에 두는 것. 왜 굳이 로컬인지, 왜 FastAPI가 아니라 Django인지, 그리고 영상 분석을 왜 전부 LLM에 맡기지 않는지 — 이 환경을 이렇게 세운 이유는 다음 편에서 풀어가겠습니다.

다음글

관련글

도구가 없어서 막히는 게 아닙니다.
넘기는 방식이 틀려서 막히는 겁니다.

이미 ChatGPT도 써봤고, Claude도 써봤고, 결과물도 몇 번 뽑아봤습니다.
그런데 이상하게 포트폴리오는 잘 안 나옵니다.

초안은 나옵니다.
문장도 그럴듯합니다.
근데 내 경험처럼 안 느껴지고, 다시 읽어보면 붕 떠 있고, 조금만 수정하려고 해도 처음부터 다시 손대게 됩니다.

그래서 결국 이런 상태가 됩니다.

만든 건 있는데 정리가 안 되고,
정리하려고 하면 문장이 내 것이 아니고,
AI를 썼는데도 작업 속도는 빨라진 것 같지 않은 상태.

이 글은 그 이유를 다룹니다.

이 글에서 다루는 것
브리핑 설계, 단위 쪼개기, 교차검증.
이 세 가지를 갖추면 같은 AI를 써도 결과물이 달라집니다.

처음 상태: 없는 게 아니라 흩어져 있었다

최근 함께 작업한 분도 비슷한 상태였습니다.

AI를 아예 안 써본 분은 아니었습니다.
이미 여러 툴을 써봤고, 결과물도 어느 정도 뽑아본 상태였습니다.
프로젝트 경험도 있었고, 정리해둔 노션도 있었고, 작업 중 남겨둔 기록도 있었습니다.

문제는 그게 보여줄 수 있는 구조가 아니었다는 점입니다.

어딘가에는 다 있었습니다.

프로젝트 설명도 있었고, 배운 점도 있었고, 작업 과정도 있었고, 생각한 흔적도 있었습니다.
그런데 그것들이 포트폴리오 문서가 아니라 작업 중인 사람의 메모 상태로 흩어져 있었습니다.

많은 사람들이 여기서 이렇게 말합니다.

“아직 보여줄 게 없어요.”

그런데 실제로는 없는 경우보다,
있는데 아직 보여줄 수 있는 형태가 아닌 경우가 더 많습니다.

포트폴리오에서 상대가 보고 싶은 건 결과물만이 아닙니다.
이 사람이 어떤 기준으로 판단했고, 어떤 맥락에서 만들었고, 무엇을 강점으로 가져가려는지가 읽히는 구조입니다.

그 구조가 없으면, 만든 게 많아도 포트폴리오가 없는 것처럼 느껴집니다.
그리고 그 상태로 AI에 넘기면 결과가 붕 뜹니다.
AI는 비어 있는 맥락을 자기 방식으로 메우기 때문입니다.

그 기본값은 대체로 비슷합니다.
어디서 본 것 같은 문장들, 평균적인 자기소개, 무난하지만 힘이 없는 포트폴리오.

브리핑이 빠져 있었다

세션에서 가장 먼저 한 일은 AI에게 문장을 시키는 게 아니었습니다.
그 전에 AI가 무엇을 기준으로 봐야 하는지부터 정리했습니다.

핵심은 브리핑입니다.

AI는 내가 어떤 사람인지 모릅니다.
이 문서를 누가 읽는지, 어떤 포지션을 목표로 하는지, 어디까지 강조해야 하는지, 무엇은 넣으면 안 되는지 알지 못합니다.

이 정보 없이 요청하면, AI는 빠진 맥락을 알아서 채웁니다.
문제는 그 채움이 내 상황에 맞지 않는다는 점입니다.

브리핑에 최소한 들어가야 하는 것은 네 가지입니다.

• 역할: AI가 어떤 시점에서 이 작업을 봐야 하는지
• 독자: 이 문서를 누가 읽는지
• 목적: 이 문서가 어떤 상황에서 쓰이는지
• 제약 조건: 길이, 형식, 제외해야 할 것 같은 경계선

이 차이는 생각보다 크게 납니다.

예를 들어 많은 사람이 실제로는 이런 식으로 요청합니다.

브리핑이 약한 요청

“커리어 전환용 포트폴리오 자기소개 문단 써줘. 이전 경력도 강점으로 녹이고 싶어.”

→ “다양한 경험을 바탕으로 문제 해결에 강점을 가진 지원자입니다. 이전 경력을 통해 쌓은 역량을 바탕으로…”

틀린 말은 아닙니다.
문제는 누구에게 어떻게 읽혀야 하는지가 빠져 있어서, 결과가 무난한 평균값으로 떨어진다는 점입니다.

같은 내용을 이렇게 바꾸면 결과가 달라집니다.

브리핑이 갖춰진 요청

“나는 7년 리테일 도메인 경력이 있는 커리어 전환 취준생이야.
지원 포지션은 백엔드고, 이전 경력이 ‘잡경험’이 아니라 도메인 이해로 읽혀야 해.
독자는 스타트업 개발팀장이고, 포트폴리오 첫 문단에 들어갈 소개 문장이라 두 줄 이내로 써줘.
추상적인 성실함보다, 왜 이 경력이 개발 판단에 연결되는지가 드러났으면 좋겠어.”

→ “리테일 현장에서 쌓은 7년의 도메인 이해가 API와 데이터 흐름을 설계할 때의 판단 기준이 됩니다. 현업 맥락을 놓치지 않는 백엔드 개발자로 전환하는 것이 제 포지션입니다.”

세션에서도 이 차이를 바로 확인했습니다.

브리핑 없이 뽑은 결과물은 문장 자체는 멀쩡했지만, 누구에게 어떤 강점으로 읽혀야 하는지가 흐렸습니다.
반대로 브리핑을 갖춘 뒤의 문장은 훨씬 선명했습니다.

반응도 명확했습니다.

“아, 이게 제가 하고 싶었던 말이에요.”

좋은 결과물은 보통 문장을 잘 써서 나오는 게 아닙니다.
앞에서 무엇을 분명하게 넘겼느냐에서 갈립니다.

단위를 쪼개지 않으면 AI도 흐려진다

브리핑이 정리되었다고 바로 문서 전체를 한 번에 만들지는 않았습니다.
그다음에 한 일은 작업 단위를 쪼개는 것이었습니다.

많은 사람들이 여기서 한 번 더 막힙니다.

자기소개, 프로젝트 설명, 문제 해결 사례, 협업 방식, 회고까지
전부 한 번에 넣고 “포트폴리오 정리해줘”라고 하면
AI는 겉보기에는 많이 만들어주는 것 같지만 실제로는 흐려집니다.

앞에서 강조한 강점이 뒤에서 사라지고,
프로젝트 설명은 따로 놀고,
문서 전체의 톤도 흔들립니다.

이건 AI가 멍청해서가 아닙니다.
처리해야 할 맥락이 너무 많아지면 우선순위가 흔들리기 때문입니다.

그래서 작업을 항목별로 나눴습니다.

자기소개는 자기소개대로,
프로젝트 설명은 프로젝트 설명대로,
강점 문장은 강점 문장대로,
각 항목마다 필요한 자료와 브리핑만 따로 붙였습니다.

이 방식의 장점은 분명합니다.

전체를 한 번에 던질 때보다,
AI가 지금 무엇에 집중해야 하는지가 선명해집니다.

문장의 밀도가 올라가고, 수정도 쉬워집니다.
무엇보다 왜 이 문장이 나왔는지 추적할 수 있게 됩니다.

세션 마지막에 나온 반응도 그 지점이었습니다.

“더 세부적으로 나눠서 정리해야겠다는 걸 느꼈어요.”
“이렇게 나눠서 하는 게 맞는 방향이라는 걸 알겠어요.”

중요한 건 AI가 많이 만들어주는 것이 아닙니다.
사람이 통제할 수 있는 단위로 작업이 분해되어 있느냐입니다.

한 세션이 만든 초안을 다른 세션으로 검증했다

초안이 나왔다고 끝이 아니었습니다.
오히려 그때부터가 중요했습니다.

많은 사람이 AI 결과물을 받으면 그걸 거의 완성본처럼 취급합니다.

하지만 실제로는 그 초안 안에도 구멍이 남아 있는 경우가 많습니다.

그래서 같은 내용을 다른 세션으로 다시 검토했습니다.

이 과정에서 꽤 자주 나오는 문제가 있습니다.

예를 들면 이런 식입니다.

자기소개 문단에서는 도메인 경험을 핵심 강점으로 세웠는데,
프로젝트 설명 파트로 가면 그 강점이 전혀 이어지지 않는 경우.

혹은 지원 포지션은 백엔드인데,
문서 전체 톤이 너무 기획자 서사처럼 정리되어 있는 경우.

앞에서는 협업과 맥락 이해를 장점으로 잡아놓고,
뒤에서는 성과를 개인 작업처럼만 서술해서 흐름이 끊기는 경우도 있습니다.

혼자 읽을 때는 잘 안 보입니다.
문장 단위로는 다 멀쩡해 보이기 때문입니다.

하지만 다른 세션으로 교차검증하면 이런 구조적 불일치가 드러납니다.
한 세션이 자연스럽게 넘긴 부분을, 다른 세션은 문제로 짚어냅니다.

이번에도 그랬습니다.
초안 자체는 꽤 잘 나와 있었지만, 전체 맥락을 이어 보면 앞에서 세운 포지션이 뒤에서 약해지는 부분이 있었습니다.
그 피드백을 반영해 다시 다듬자 문서가 훨씬 단단해졌습니다.

AI를 잘 쓰는 사람은 보통 한 세션의 첫 결과를 그대로 믿지 않습니다.

초안을 만들 세션과, 구멍을 찾을 세션을 분리합니다.

그 차이가 결과물의 밀도를 바꿉니다.

마지막에 가장 중요한 걸 확인했다

작업이 거의 마무리됐을 때, 마지막으로 한 가지를 분명히 짚었습니다.

이해하지 못한 문장은 포트폴리오에 넣지 않는 것.

이건 생각보다 중요합니다.

포트폴리오를 제출하면 결국 질문을 받게 됩니다.

왜 이렇게 구성했는지,
이 판단은 어떤 경험에서 나온 건지,
이 프로젝트에서 본인이 실제로 한 역할은 무엇인지.

그 질문에 자기 말로 답할 수 없다면,
그건 포트폴리오가 아니라 AI가 정리해준 문서에 가깝습니다.

AI는 구조를 제안할 수 있고,
문장을 다듬을 수 있고,
빠진 부분을 짚어줄 수 있습니다.

하지만 그 문장을 이해하고,
설명 가능하게 만들고,
내 경험으로 다시 소화하는 건 사람의 일입니다.

이 지점에서 잠깐 멈칫하는 반응이 나왔습니다.
AI가 정리해준 표현을 그대로 넣으려 했던 부분이 있었다고 했습니다.

그래서 다시 확인했습니다.

설명할 수 없는 건 넣지 않는다.
이해한 것만 넣는다.

이 원칙이 있어야, AI를 써도 결과물이 내 것이 됩니다.

세션이 끝난 뒤 남아야 하는 것

이 작업은 한 번의 문장 첨삭으로 끝나는 종류가 아닙니다.

브리핑 설계,
작업 단위 분해,
초안 생성,
교차검증,
최종 자산화.

이 과정을 한 번 경험하면 중요한 게 남습니다.

문서 하나가 완성되는 것보다,
다음 작업에도 반복해서 쓸 수 있는 방식이 남습니다.

브리핑 템플릿,
작업 단위를 나누는 기준,
세션 간 교차검증 프롬프트,
초안을 이해 가능한 문장으로 다시 바꾸는 기준.

이것들이 남아야 다음 포트폴리오도, 다음 프로젝트 정리도 혼자 돌릴 수 있습니다.

제가 만들고 싶은 건 결과물 한 장이 아닙니다.
결과물이 계속 나오게 하는 구조입니다.

포트폴리오가 없는 게 아니라, 아직 제대로 넘기지 않은 것이다

많은 사람들이 AI를 쓰고도 같은 자리에서 맴돕니다.

초안은 나왔는데 정리가 안 되고,
정리는 했는데 내 것 같지 않고,
다듬으려고 하면 처음부터 다시 시작하게 됩니다.

이때 필요한 건 더 새로운 툴이 아닙니다.

브리핑을 갖추는 것,
작업 단위를 쪼개는 것,
교차검증으로 구멍을 찾는 것,
그리고 이해한 것만 남기는 것.

이 순서를 아는 사람과 모르는 사람은
같은 AI를 써도 결과물에서 차이가 납니다.

포트폴리오가 없는 게 아닐 수 있습니다.
이미 해본 일은 있는데, 아직 제대로 넘기지 못한 상태일 수 있습니다.

관련글

막막한 사람에게 지도를 그려주는 건 전문가가 아닙니다.
막막함 자체를 구조화하는 과정이 지도를 만듭니다.

부트캠프를 듣고 있는데도,

막상 지원하려 하면 멈추는 사람들이 있습니다.

기술이 부족해서만은 아닙니다.

이전에 해온 일과 지금 배우는 기술이 하나의 이야기로 연결되지 않기 때문입니다.

몇 년을 일했는데도, 그 시간이 채용 시장에서는 쓸모없는 시간처럼 느껴질 때가 있습니다.

스스로도 그렇게 느끼기 시작하면, 포트폴리오를 만들기 전부터 이미 위축됩니다.

최근 그런 상태의 수강생과 1시간짜리 세션을 진행했습니다.

겉으로 보면 평범한 직무 전환 케이스였습니다. 수강 중, 결과물은 애매하고, 어떤 직무를 목표로 해야 할지도 불분명한 상태. 그런데 이 케이스의 핵심은 기술 수준이 아니었습니다. 문제는 이미 가진 경험이 채용 시장에서 읽히는 언어로 번역되지 않고 있다는 점이었습니다.

2시간 뒤, 이 수강생 앞에는 하나의 로드맵이 놓였습니다. 어떤 포지션이 유리한지, 어떤 회사군을 노려야 하는지, 기존 결과물을 살릴지 새로 만들지, 만든다면 어떤 주제로 어디까지 만들어야 하는지, 그리고 앞으로 몇 달 안에 뭘 해야 하는지가 한 페이지에 정리돼 있었습니다.

없던 경력이 생긴 게 아닙니다. 원래 있던 경험이, 이제야 지원 가능한 형태로 보이기 시작한 겁니다.

문제는 공부량이 아니라 구조 부재였다

이 수강생의 상태를 겉으로만 보면 흔히 이렇게 해석하기 쉽습니다.

"실력이 부족한가 보다. 더 공부해야겠네." 하지만 실제로는 그게 아니었습니다.

여러 해의 실무 경험이 있었습니다.

예산 처리, 비용 관리, 내부 프로세스 운영 같은 업무를 직접 다뤄본 경력.

겉으로 보면 지원하려는 직무와 거리가 있어 보이지만, 아무것도 없는 경력도 아닙니다.

문제는 그 경험이 지원 전략으로 연결되지 못하고 있었다는 점입니다.

이 경험이 어떤 도메인에서 강점이 되는지,

어떤 회사군에서 유리하게 작동하는지,

어떤 방향으로 번역해야 면접에서 살아나는지.

이 기준이 없으니 이미 가진 경험도 쓸모없는 것처럼 느껴졌던 겁니다.

구조가 없는 상태에서 지식을 더 쌓아도 방향은 더 흐려집니다.

이번 세션의 목표는 그래서 단순했습니다.

더 많이 배우게 하는 것이 아니라, 이미 가진 경험을 실행 가능한 방향으로 구조화하는 것.

AI를 써서 막막함을 실행 계획으로 바꿨다

세션 전 상태는 이랬습니다. 가고 싶은 방향조차 없었지습니다.

이 케이스는 직무 전환 사례였지만, 본질은 특정 직군의 문제가 아닙니다.

많은 사람이 비슷한 방식으로 자기 경험을 설명하지 못해 멈춥니다.

세션 후에는 달랐습니다.

실무 도메인 경험을 살려 어떤 회사군을 노릴지 정해졌고,

기존 결과물을 재정리할지 새로 만들지 A/B로 판단했으며,

만들 경우 어떤 주제로 어디까지 만들어야 하는지까지 내려왔습니다.

AI를 통해 막연한 "이쪽으로 가고 싶다"가 생겼고,
그 이후에는 지원 전략과 실행 계획까지 붙은 셈입니다.

이걸 만드는 데 쓴 방식은 단순했습니다.

먼저 경력 데이터를 AI에게 넣어 강점 영역과 지원 가능한 도메인을 분석했습니다.

수강생 본인도 처음 보는 자기 분석 결과였습니다.

오래 다뤄온 실무 경험이, 특정 회사군에서 오히려 유리한 포지션이 될 수 있다는 방향이 나왔습니다.

다음으로 그 결과를 지원 전략 문서로 정리했습니다.

가능한 포지션, 결과물 방향, 목표 시점까지의 타임라인.

대화로 끝나는 것이 아니라 다음에 꺼낼 수 있는 형태로 저장했습니다.

그리고 그 문서를 다른 AI에게 넘겨 현실성을 검증했습니다.

같은 내용을 서로 다른 AI에게 보여주면 보는 각도가 달라집니다.

이번에도 충돌이 일어났습니다.

"범위가 주어진 기간 대비 넓다"는 피드백이 나왔습니다.

처음 만들어진 계획이 다소 이상적이었던 겁니다.

이 피드백을 다시 반영해 범위를 줄이고 실행 계획으로 바꿨습니다.

최종적으로 A안과 B안, 두 가지 선택지가 나왔고, 수강생이 직접 하나를 골랐습니다.

AI가 해준 건 '결정'이 아니라 '번역'이었다

여기서 중요한 걸 짚어야 합니다.

이 과정에서 AI를 여러 번 사용했습니다.

하지만 핵심은 "AI를 몇 개 썼는가"가 아닙니다.

AI가 해준 것은 흩어진 경력을 정리하고,

가능한 방향을 좁히고,

실행 계획을 제안하고,

범위를 줄이고,

일정까지 구체화하는 것이었습니다.

즉 사람이 이미 갖고 있던 경험을, 채용 시장에서 읽히는 언어로 다시 정렬해준 것입니다.

경력은 있었지만 경력처럼 보이지 않았고,

강점은 있었지만 강점처럼 정리되지 않았습니다.

AI는 바로 그 중간 번역기를 해줬습니다.

커리어 컨설팅 시장에는 이런 작업을 수백만 원짜리 서비스로 파는 곳들이 있습니다.

그 비용의 상당 부분은 "경험을 언어로 번역하는 과정"에 들어갑니다.

그 과정을, 지금은 AI로 훨씬 빠르게 할 수 있습니다.

물론 AI가 모든 걸 대신해주진 않습니다.

다만 사람 혼자서는 흐릿하게 느끼던 것을 선명한 선택지로 바꿔주는 속도는 압도적으로 빠릅니다.

그리고 마지막 판단은 언제나 사람이 합니다.

AI를 잘 쓰는 사람은 AI에게 결정을 떠넘기는 사람이 아닙니다.
AI를 이용해 판단 가능한 상태를 만드는 사람입니다.

진짜 지표는 '열정'이 아니라 다음 행동이다

세션 마지막에 수강생이 이렇게 말했습니다.

"열정이 생겨요."

좋은 반응입니다.

하지만 저는 이런 말을 성공 지표로 보지 않습니다.

첫 세션에서는 누구나 조금 들뜰 수 있습니다.

중요한 건 그 다음입니다.

다음 주에 실제로 손을 움직였는지,

A안과 B안 중 무엇을 선택했는지,

기록을 남기기 시작했는지.

진짜 변화는 감정이 아니라 행동에서 확인됩니다.

그래도 분명한 건 있습니다.

"어디서부터 시작해야 할지 모르겠다"는 상태와,

"다음 주까지 뭘 해야 할지 알겠다"는 상태는 완전히 다릅니다.

취업 준비에서 가장 무서운 건 느리게 가는 것이 아닙니다.

아무 방향도 없는 채로 같은 자리를 계속 맴도는 것입니다.

방향이 생기면 속도는 나중 문제입니다.

방향이 없으면 속도는 아예 의미가 없습니다.

없는 경력을 만드는 게 아니라, 있는 경험을 다시 보이게 하는 것

많은 사람들이 정말로 경력이 없어서 막히는 게 아닙니다.

이미 가진 경험이 있는데,

그것이 시장 언어로 정리되지 않아서 막힙니다.

실무 경험은 도메인 이해가 되고,

반복한 업무는 요구사항 감각이 되고,

현업과의 소통 경험은 협업 역량이 됩니다.

경력의 가치가 갑자기 새로 생긴 게 아닙니다.

원래 있던 가치가 제대로 읽히기 시작한 것입니다.

이번 사례는 특정 직무 전환 케이스였지만,

이런 구조는 개발자에게만 필요한 것이 아닙니다.

직무 전환을 준비하는 사람,

실무 경험은 있는데 포지셔닝이 안 되는 사람,

이력서에는 적혀 있는데 강점으로 읽히지 않는 사람 모두에게 똑같이 필요합니다.

저는 이 과정이 결국 번역이라고 생각합니다.

없는 것을 만들어내는 게 아니라,

이미 있는 것을 지원 가능한 형태로 다시 쓰는 일.

그 번역이 되면,

사람의 표정이 달라집니다.

"나는 아무것도 없다"에서

"아, 내가 가진 걸 이렇게 쓸 수 있구나"로 넘어가기 때문입니다.

많은 사람들에게 필요한 건 더 많은 정보가 아니라,

이미 가진 경험을 다시 읽히게 만드는 구조일지도 모릅니다.

비슷한 글

기술 블로그를
AI로 운영한 3개월
그리고 솔직한 숫자

시간을 줄이면 퀄리티가 떨어진다고 생각했습니다.
아니었습니다.

마케터도 작가도 아닌데

 
AI 관련 영상이나 글을 보면 다들 쉽게 되는 것처럼 보입니다. 프롬프트 하나 넣으면 기획서가 나오고, 버튼 하나로 콘텐츠가 완성됩니다. 그런데 막상 내 업무에 대입해보면 뭔가 어긋납니다. 결과물이 어색하거나, 어디서부터 시작해야 할지 모르겠거나. 저도 그랬습니다. 마케터도 아니고 작가도 아닌데, 블로그를 제대로 운영할 수 있을까 싶었습니다.
 
개발자로 십수 년을 살았습니다. 글을 잘 쓴다는 말을 들어본 적도 없고, 콘텐츠 기획이라는 개념은 더더욱 낯설었습니다. 기술 블로그는 쓰는 사람이 좋아서 쓰는 거지, 운영이라는 단어를 붙이기엔 어딘가 거창한 느낌이었습니다. 그냥 알고 있는 걸 정리해서 올리는 공간 정도로 생각했습니다. 꾸준히 쓰는 것만으로도 충분하다고 스스로를 설득하면서요.
 
그런데 12월부터 방식을 바꿨고, 3개월이 지났습니다.

비수기에 나온 숫자

1월 374PV, 2월 694PV. 한 달 사이 86% 성장입니다.

 
숫자를 꺼내기 전에 맥락을 하나 짚겠습니다. 기술 블로그는 구조적으로 PV가 낮은 장르입니다. 타겟이 좁고, 검색 유입도 느리고, 바이럴이 거의 없습니다. 일반적인 라이프스타일 블로그나 재테크 블로그와 단순 비교하기 어려운 장르입니다. 게다가 이 기간은 블로그 비수기였습니다. 연초는 대부분의 기술 블로그가 조용해지는 시기거든요. 검색량도 줄고, 새로운 유입도 뜸해집니다. 그 타이밍에 이 숫자가 나올 줄은 저도 솔직히 몰랐습니다.
 

 
참여율 40%대도 마찬가지입니다. 기술 글은 훑고 나가는 독자가 많습니다. 제목 보고 들어왔다가 첫 문단에서 이탈하는 경우도 흔합니다. 40%면 끝까지 읽는 사람이 상당하다는 뜻입니다. 시간을 줄였는데 오히려 더 읽히는 글이 됐다는 게 스스로도 흥미로웠습니다. 퀄리티를 지키면서 속도를 올리는 게 가능하다는 걸, 숫자로 확인한 순간이었습니다.

방향을 잡는 쪽은 언제나

글을 쓰기 전에 AI와 먼저 이야기합니다. 주제 선정부터 같이 합니다. 이 글이 지금 나올 타이밍인지, 비슷한 글과 어떻게 달라야 하는지를 먼저 검토합니다. 단순히 "이런 글 써줘"가 아니라, 시장에서 이 글이 어떤 위치를 가질 수 있는지를 같이 따져봅니다.
 
실제 사례가 있습니다. GPU 역사 시리즈를 연재하던 중에 UE5 편을 쓸 시점이 됐을 때, AI와 함께 이 글이 링크드인에서 반응을 얻을 수 있는지 분석했습니다. 기술 직군 독자들이 어떤 맥락에서 이 주제에 관심을 가질지, 어떤 각도로 접근하면 공유가 일어날 수 있는지를 같이 정리했습니다. 그 예측이 정확히 통했습니다. 운이 아니라 기준이 있었습니다.
 
주제가 잡히면 저는 5분 안에 초안 구조를 씁니다. 완성된 글이 아니어도 됩니다. 흐름만 잡히면 됩니다. 그걸 AI에게 넘기고, 나온 결과물을 다시 다른 AI와 함께 교차검토합니다. 퇴고까지 끝내면 글 한 편에 30분 내외입니다. 이미지 생성, 태그, slug 추천까지 포함해서입니다. 예전에 글 한 편 쓰는 데 몇 시간씩 붙잡혀 있던 것과는 완전히 달라진 흐름입니다.
 
중요한 건 AI가 글을 쓴 게 아니라는 겁니다. 구조는 제가 잡았고, AI는 그 위에서 움직였습니다. 무엇을 쓸지, 왜 이 순서인지, 어떤 독자를 향한 글인지는 전부 제가 결정했습니다. AI는 그걸 실행하고 다듬는 역할이었습니다. 편집자 겸 마케터와 일하는 느낌이었는데, 방향을 잡는 쪽은 언제나 저였습니다. 그 차이가 결과물의 밀도를 갈랐다고 봅니다.

순서가 가지는 의미

ChatGPT로 초안을 잡는 건 객관적인 거리를 만들어주기 때문입니다. 제 생각에 너무 가깝게 붙어 있으면 글이 좁아지는데, ChatGPT가 그 거리를 잡아줬습니다. 지금은 Claude로 같은 역할을 가져왔고요.
 
Gemini는 다른 이유로 씁니다. 구글 검색 중심으로 학습된 모델이다 보니, 일반 독자가 어떻게 읽을지를 체크하는 데 쓸 만합니다. ChatGPT로 파고들고, Gemini로 대중성을 살짝 곁들이는 식입니다.
 
부수적으로는 Gemini, ChatGPT, 그리고 저 셋이서 돌아가며 교차검증을 하니까 할루시네이션이 걸러지기도 하고요.
 
도구를 많이 쓴 게 아니라, 각 도구가 잘 하는 걸 구분해서 배치한 겁니다.

십수 년이 남긴 감각

십수 년을 개발자로 일하면서 비개발 직군과 항상 같이 일했습니다. 기획자, PM, 마케터, 운영팀. 그분들의 언어로 기술을 설명하고, 업무 흐름에 맞춰 개발 결과물을 이어붙이는 게 일상이었습니다. 다양한 도메인을 거치면서 자연스럽게 생긴 감각이 있습니다. 개발을 모르는 현직자가 새로운 도구 앞에서 어디서 막히는지, 그리고 그 막히는 지점을 어떻게 돌아갈 수 있는지에 대한 감각입니다.
 
AI 앞에서도 비슷한 장면이 반복됩니다. 영상 보고 따라 해봤는데 내 업무엔 안 맞았던 경험, 결과물은 나왔는데 어딘가 어색해서 쓰질 못하는 경험. 막히는 지점이 도구가 아니라 구조에 있는 경우가 대부분입니다. 내 업무의 흐름을 먼저 잡고, 그 위에 AI를 얹는 순서가 필요한데, 그 순서를 잡는 방법을 가르쳐주는 곳이 많지 않습니다. 대부분의 AI 교육이 도구 사용법에서 멈추는 이유이기도 합니다.
이번에 블로그를 직접 운영하면서 다시 확인한 것들이었습니다. 코딩이 하나도 없는 워크플로우로, 기술 블로그 비수기에 86% 성장이 가능했습니다. 이게 블로그만의 이야기가 아니라는 걸, 기획서를 쓰고 보고서를 만들고 콘텐츠를 생산하는 현직자라면 아마 감이 오실 겁니다.

비슷한 글

빠르게 생성하고, 다시 검증한다.
프로세스가 만들어내는 리뷰 품질

 지난 포스팅인 [개발자의 종말, 구현자의 시작]에서 언급했던 AI 워크플로우를 기억하시나요? 단순히 코드를 짜는 단계를 넘어, 이제는 전체적인 시스템을 설계하고 AI를 적재적소에 배치해 효율을 극대화하는 구현자(Implementer)의 시대가 왔음을 말씀드렸습니다.
 오늘은 그 철학을 실천에 옮긴 사례를 공유하려 합니다. 바로 저에게 할당된 십수 명의 언리얼 엔진 수강생을 위한 'AI 코드 리뷰 시스템' 구축기입니다. 여러 프로젝트를 동시에 코드 리뷰하는 물리적 한계를 어떻게 Cursor와 프롬프트 엔지니어링으로 개선했는지, 제가 정의한 5단계 워크플로우에 맞춰 설명해 보겠습니다.

1. 요구사항 분석 (Requirement Analysis)

"물리적 한계와 품질 사이의 갈등"
 십수 명의 학생이 제출하는 코드를 매주 혼자 리뷰하면서 일관된 품질을 유지하는 것은 현실적으로 고부하입니다. 하지만 교육자로서 '대충' 할 수는 없죠. 제가 정의한 핵심 요구사항은 다음과 같았습니다.

• 일관성: 리뷰어의 컨디션에 상관없이 동일한 기준(심각도, 컨벤션 등) 유지.
• 근거 중심: "이게 더 좋아요" 식의 추상적 조언이 아닌, 정확한 파일 위치와 라인을 명시할 것.
• 성장 가이드: 단순 오타 수정을 넘어 다음 제출물에서 개선해야 할 '학습 방향성' 제시.

2. 설계 (Design)

"멀티 스테이지 검증 시스템"
 AI의 가장 큰 적은 '할루시네이션(환각)'입니다. 할루시네이션 가능성을 낮추기 위해 단일 프롬프트가 아닌 [리뷰 생성 => 리뷰 검증]이라는 2단계 구조를 설계했습니다. 또한, 이전 버전의 코드와 현재 버전을 비교 분석할 수 있는 '비교 모드'를 도입해 실력 향상 폭을 측정하도록 기획했습니다.

3. 프롬프트 작성 (Prompt Engineering)

"룰은 강제하되, 관찰에 기반할 것"
 설계한 내용을 바탕으로 Cursor에서 사용할 두 가지 핵심 프롬프트를 작성했습니다.

코드 리뷰 프롬프트

 이 프롬프트는 리뷰의 '뇌' 역할을 합니다. 추측성 표현을 철저히 금지하고, 모든 지적에 대해 (파일경로:라인범위) 근거를 요구합니다. 특히 Blocking(필수 수정)과 Non-blocking(권장)을 명확히 구분해 학생이 우선순위를 파악할 수 있게 했습니다.

코드 리뷰 검증 프롬프트

  AI가 작성한 리뷰를 다시 AI가 검사하는 '감시자' 프롬프트입니다. 1차 리뷰는 생산성을 위해 생성하고, 2차 검증은 형식 / 근거 / 금지 표현 위반을 줄여 결과물 편차를 낮추기 위해 분리했습니다. 룰 누락은 없는지, 섹션이 붕괴되거나 표현이 일탈되는 등, 리뷰의 룰 위반을 줄여 일관성을 확보합니다. code-review-tutoring.md가 변경 및 확장될 때, 리뷰 결과물이 룰을 계속 준수하는지 점검하는 장치로 사용합니다.

4. 튜닝 및 검증 (룰 준수)

"AI가 놓친 것은 없는가?"
 실제 수강생의 코드를 넣어보며 프롬프트를 튜닝했습니다. 처음에는 AI가 지나치게 관대한 피드백을 남기는 경향이 있어, 문장 톤은 단정하게 유지하되, 지적은 구체적 근거와 영향 중심으로 나오도록 규칙을 강화했습니다. 그래서 개인 평가 / 감정 표현 금지 룰을 강화해 철저히 "사실 => 근거 => 영향"의 구조로 출력되도록 교정했습니다.
 verify 프롬프트는 단순한 검사를 넘어, 시스템의 확장성을 담보하는 장치가 되었습니다. '학습 방향성'이나 '코드 퀄리티 분석' 같은 새로운 평가 기준을 추가할 때마다, 이 감시 장치가 결과물의 형식이 무너지지 않도록 파수꾼 역할을 해주었기 때문입니다.

5. 사용 (Usage)

# path1에 있는 코드들에 대해 코드 리뷰를 진행
/code-review-tutoring @path1

# path1에 대한 코드 리뷰를 진행하고 path2(이전 버전)와 비교하여 코드 퀄리티 변화도 출력
/code-review-tutoring @path1 @path2

# 직전 리뷰 텍스트에 대해 룰 위반 여부만 분석
/verify-code-review-tutoring

 
"튜터의 역할: 최종 큐레이터"
 이제 저는 여러 프로젝트의 코드를 처음부터 끝까지 읽는 대신, AI가 정리해 준 [강점/약점/학습 방향성] 보고서를 먼저 검토합니다.

1. Cursor가 프롬프트에 따라 1차 리뷰 생성.
2. 검증 프롬프트로 룰 위반 여부를 체크.
3. 최종적으로 제가 내용을 분석하고 정제하여 학생에게 전달.

  Agent 사용 이전에는 한명의 코드 리뷰를 진행하는데에 30분에서 1시간 이상이 소모되었습니다. 시간이 부족하면 근거(파일 / 라인)까지 정교하게 남기기 어려웠습니다. 하지만 이러한 리뷰 시스템을 도입한 후에는 Cursor가 언급한 코드와 그 근처 코드들만 읽으면 되었고, 해당 코드가 왜 좋은 코드인지에 대한 리뷰 근거(파일:라인 / 함수 / 클래스)와 영향 설명을 함께 제공했습니다. 핵심 구간을 우선 확인할 수 있게 된 것입니다. 그래서 저는 더 짧은 시간에 근거 기반으로 코드 리뷰를 진행할 수 있었습니다. 그렇게 학생들은 훨씬 더 구체적이고 일관된 피드백을 받을 수 있게 되었습니다.

마치며: 구현자로서의 첫걸음

 이 시스템은 단순히 업무를 자동화한 것이 아닙니다. 튜터라는 역할을 수행함에 있어 나의 전문성이라는 엔진을 AI라는 부스터에 달아 효율을 극대화한 결과물입니다.
 수강생 십수 명에 대한 코드 리뷰가 소모만 되는 작업이 되지 않도록 반복되는 분석, 정리 파트를 자동화하고 저는 판단이 필요한 지점(설계 의도, 트레이드오프, 학습 방향성)에 시간을 더 배분할 수 있게 되었습니다. 오히려 더 깊이 있는 가이드에 집중할 여력이 생겼죠. 여러분도 본인의 업무에서 반복되는 '분석과 정리'의 패턴을 찾아보세요. 그것이 바로 여러분이 '구현자'로서 첫발을 내디딜 지점입니다.

긴 글을 마무리하며, 이 워크플로우가 어떤 분들에게 특히 필요했는지 궁금합니다.
아래 중 어디에 해당하시나요? 번호로 댓글만 남겨주시면 큰 힘이 됩니다.

1. 현업 개발자: PR/코드리뷰가 병목이고, 근거 기반 리뷰 표준화가 필요하다.
2. 팀 리더 / 테크리드: 리뷰 품질을 개인 역량이 아니라 팀 프로세스로 만들고 싶다.
3. 1인 / 프리랜서 / 창업 준비: 반복되는 분석·정리를 줄이고 납기/품질을 안정화하고 싶다.
4. 관심 독자: AI 워크플로우/프롬프트 설계 사례를 계속 보고 싶다.

현재 진행 중인 업무에 AI를 접목시킬 때, 어디를 자동화하고, 어디서 사람이 판단해야 하는지 설계가 고민이라면

방명록(또는 이메일)로 편하게 남겨주세요.

방명록 바로가기

이메일 주소 : chessire@naver.com

이전글

완벽한 실행자와 불완전한 가설
—
사람의 실수가 사라지지 않는 이유

최근 공개되는 AI 데모들을 보면, 개발 업무의 상당 부분이 빠르게 자동화되는 흐름은 부정하기 어렵습니다.

설계 초안 작성부터 구현, 테스트 코드 생성, 문서화까지 그럴듯한 결과가 빠른 속도로 나오고 있습니다.

이 지점에서 자연스럽게 질문이 생깁니다.

AI가 설계부터 구현까지 수행하는 시대에, 사람의 ‘추론 능력’은 어디에서 가치를 가지는가?

이 글은 그 질문에 대해, 감정적 위로가 아니라 정의·구분·한계·실무적 함의 중심으로 정리한 글입니다.

1. 전제: AI의 강점은 생산과 재조합에 있다.

우선 AI의 성과를 축소해서 해석할 이유가 없습니다.

현재의 AI는 아래 영역에서 이미 실무적으로 유의미합니다.

• 요구사항이 비교적 명확할 때의 코드 생성 및 리팩터링 보조
• 기존 패턴/라이브러리 사용법의 빠른 검색 및 샘플 구성
• 문서/테스트/로그 템플릿화, 리뷰 초안 생성
• 유사한 문제를 빠르게 풀어내는 재조합 속도

이 강점은 기술적으로 보면 자연스럽습니다.

대규모 데이터에서 패턴을 압축하고, 그 패턴을 조건에 맞춰 재배열하는 방식은

특히 In-Distribution(학습 분포와 유사한 조건)에서 높은 성능을 보이기 때문입니다.

여기까지는 논쟁이 아닙니다.

실무자라면 체감하는 영역입니다.

2. 구분: 추론을 한 단어로 뭉치면 오해가 발생한다.

문제는 추론이라는 단어를 하나로 뭉칠 때 생깁니다.
실무에서 추론은 대략 두 층으로 나뉩니다.

1. 해결(Problem Solving): 주어진 문제를 푸는 능력
2. 정의(Problem Framing): 무엇이 문제인지 규정하고, 성공 조건과 제약을 설계하는 능력

AI는 1)에서 빠르게 강해지고 있습니다.
반면, 2)는 여전히 사람의 비중이 큽니다.

이유는 간단합니다.

• 목표가 다중(KPI 충돌)이고, 우선순위가 조직/비즈니스에 의해 결정됨
• 데이터가 부족하거나, 실험 비용이 커서 정답이 즉시 관측되지 않음
• 실패 원인이 코드 외부(운영/프로세스/사용자 행동/조직 구조)에 섞여 있음
• 요구사항 자체가 모순적이거나, 아직 합의되지 않은 상태가 흔함

이 상황에서 핵심은 정답을 맞히는 능력이 아니라, 판을 뒤집는 설계(새 논리 구조)입니다.

흔히 System 2(심사숙고)라고 부르는 영역이 여기에 해당합니다.

3. 핵심 주장: 사람의 ‘실수’는 결함이 아니라 기능.

여기서 반전으로 들어가겠습니다.
사람의 실수는 보통 부정확함으로 취급되지만, 특정 조건에서는 오히려 추론이 작동하고 있다는 신호가 됩니다.

이를 이해하려면, 두 개념을 구분해야 합니다.

• 환각(Hallucination): 근거가 부족한데도 그럴듯한 확정 답을 만들어내는 현상
• 가설(Hypothesis): 현재 증거가 부족하므로, 검증 가능하도록 후보 원인을 세우고 다음 관측/실험으로 이어지는 주장

AI도 가설을 제시할 수는 있습니다.

다만 실무에서 자주 발생하는 문제는, AI가 제시한 내용이 가설인지 확정인지 경계가 흐려질 때입니다.

말은 단정인데 근거는 빈약한 형태가 나오면, 현장에서는 리스크가 됩니다.

반면 인간의 실수는(정상적인 업무 프로세스 안에서는) 다음 형태로 나타날 때 가치가 있습니다.

1. 현재 데이터로는 결론이 나지 않음을 인정
2. 원인을 소수의 후보로 압축(가설화)
3. 검증 비용이 낮고 정보 이득이 큰 실험을 설계
4. 실패를 통해 시스템 모델을 업데이트

즉, 사람의 실수는 OOD(분포 외 상황)에서 세계 모델을 구성하려는 시도로 나타날 수 있습니다.
아이러니하지만, 데이터가 부족한 상황에서 사람이 하는 ‘틀림’은, 종종 검증 가능한 다음 행동을 낳습니다.

이 글에서 말하는 실수의 위대함은 단순한 감성적인 표현이 아니라 다음 의미입니다.

실수가 근거 없는 확신이 아니라 검증 가능한 가설의 형태를 띨 때, 그것은 추론의 결함이 아니라 추론의 작동 방식입니다.

4. 결론: 빌더(Builder)에서 아키텍트(Architect)로 이동해야 한다.

그렇다면 생존 전략은 명확해집니다.
AI가 강해질수록 사람에게 남는 영역은 “How”가 아니라 “What/Why” 쪽으로 이동합니다.

• What: 무엇을 만들 것인가(문제 정의, 성공 조건, 범위)
• Why: 왜 이것이 우선인가(가치, 리스크, 제약, 트레이드오프)
• 검증 설계: 무엇을 측정해야 실패를 빨리 알 수 있는가
• 경계 설정: 무엇을 고정하고 무엇을 가변으로 둘 것인가
• 책임: 그 판단을 그럴듯함이 아니라 증거로 정당화할 수 있는가

AI는 훌륭한 실행자이자 보조자입니다.
그러나 문제를 어떤 형태로 정의하고, 어떤 증거로 검증할지는 아직 사람이 주도해야 합니다.

그리고 이 영역이 자동화되기 어렵다는 이유는 기술 이전에 현실적입니다.

목표와 제약, 그리고 가치 판단은 결국 사람과 조직의 선택이기 때문입니다.

관련글

Know-how의 시대가 저물고
What & Why를 정의하는 시대가 온다.

개발자의 시대

 2015년부터 시작된 개발자 붐이 갑작스레 막을 내리고 있습니다. 그 당시 게임업계 대기업 3사(3N)의 연봉인상 릴레이부터 네카라쿠배까지 경험했던 저로서는 놀라울 따름입니다. 2년전 쯤 딥러닝을 통한 LLM의 등장을 단순한 가십거리로 치부했던 2년 전의 판단은 보기 좋게 빗나갔습니다. 기술의 발전 속도는 우리의 상상력을 항상 앞서갑니다.

 2025년, 바이브 코딩을 처음 접해봤습니다. 바이브코딩을 통해 백엔드, 프론트엔드 기능도 작성해보고 언리얼엔진 코드도 작성해보았습니다. 그리고 전체적으로 훑어봤죠. 프롬프트와 테스트케이스만 잘 꼬집어주면 흠잡을 구석이 없었습니다. 2026년을 시작하는 지금도 얼마나 빠른 속도로 발전하고 있을지 모르겠습니다.

 그것을 보면서 저는 시니어 개발자에서 개발 AI 시대의 새로운 아키텍트를 양성하는 교육자로 전향하게 되었습니다. 개발 교육으로 전향한 저로써 왜 이런 선택을 했는지, 그리고 제가 생각하는 앞으로의 미래를 말씀드려보겠습니다.

지식의 보편화와 상향 평준화

 과거에는 전문가가 안 된다고 하면 안되는 세상이었습니다. 개발자가 구현 안 된다고 하면 개발이 안되는 것이었고, 디자이너가 안어울린다고 하면 디자인되지 않았습니다. 하지만 AI가 디자인도 뽑아주고, 개발하는 세상이 도래했습니다. 심지어 사소한 의학지식이나 법률지식은 AI를 통해 찾아볼 수 있게 되었습니다. 간단한 레벨은 AI가 해줄 수 있고, AI가 발전함에 따라 그 레벨이 점점 올라갈 것이라는 점입니다.

 물론 인터넷이 등장하고, 유튜브 영상이 범람하면서 방구석 전문가라는 타이틀도 생겨났습니다. AI 또한 마찬가지로 할루시네이션이 있고, 할루시네이션을 극복한다고 하더라도 전문가를 통해 정보를 선별하거나 적어도 프롬프트를 작성 및 개선하는 노력이 필요할 것입니다.

 요약하자면 지식이 보편화되었고 그로 인해 사람들의 능력도 상향 평준화 된다는 것 입니다. 전문가가 되는 난이도는 낮아지고, AI 활용 능력은 중요해지죠. 제가 집중했던 포인트는 AI를 통한 업무 효율화는 마치 IT의 개발 Workflow와 비슷하다는 부분이었습니다. 이 것을 깨닫는데에 다양한 도메인(엔터테인먼트, 세무/회계, 자율주행)에서 개발해본 경험이 많은 도움을 주었습니다.

개발 Workflow
[요구사항 분석 => 설계 => 코드 구현 => 테스트/검증 => 배포]

AI를 통한 업무 효율화
[요구사항 분석 => 설계 => 프롬프트 작성 => 테스트/검증 => 사용]

 우리는 이것을 코딩의 종말이라 부르지만, 저는 이를 구현의 민주화(Democratization of Implementation)라고 정의하고 싶습니다. 이제 '만드는 기술'이 권력이던 시대는 끝났습니다.

어떻게(How)보다는 왜(What & Why)

 How(어떻게 구현하는가)를 아는 전문가의 시대는 저물고 있습니다. 이제 그 영역은 AI가 더 빠르고 정확하게 수행합니다. 앞으로 살아남는 개발자는 Why(왜 만들어야 하며, 무엇이 문제인가)를 정의할 수 있는 '설계자'뿐입니다. 그리고 우리에게는 전문가로 성장중인 AI가 주어졌습니다. AI는 시키는 대로만 합니다. 할루시네이션 또한 프롬프트에서 비롯하여 많이 발생하게 됩니다. 이것은 무엇을 의미할까요? AI에게 정확한 지시를 내리는 것이 중요하니 파이프라인에 대한 이해가 중요해질 것입니다. 각 파이프라인의 시작은 무엇을 만들지 정의하고 끝은 왜 그것을 만드는지 정의하는 것으로 정리될 것 입니다.

 그렇게 "현장 감독관"이 되실 많은 사람들을 교육하는 교육자가 되려고 마음 먹었습니다. 아무래도 한국은 90~00년대에 주입식 교육이 강했고 획일화 된 과정을 거쳤다보니 이런 부분에 약한 것 같습니다. 그래서 다양한 도메인에서 쌓은 파이프라인 설계 지식으로 이끌어갈 수 있지 않나 생각해봅니다.

끝으로

 AI가 매트릭스를 넘어서든 아니든 중요하지 않습니다. 중요한 건 '핸들'을 쥔 사람은 여전히 인간이어야 한다는 점입니다. 제가 왜 국비지원 과정에서 'Cursor'를 적극적으로 사용했는지, 그 구체적인 이야기를 다음 편에서 들려드리겠습니다.

다음글