따라가는 공부는 남지 않는다 — 실무 기획자가 AI를 통해 성장하는 방식

2026. 8. 5. 14:57·강의&프로젝트

프롤로그

따라가는 공부는 남지 않는다 — 실무 기획자가 AI를 통해 성장하는 방식 그림

어느 날 밤의 피로

퇴근길에 새 모델 소식을 훑다가 갑자기 피로해진 날이 있었다. 반년 전 며칠을 붙잡고 겨우 이해한 기법 아래 "이제 이 방식은 끝났다"는 문장이 달려 있었다.

그날 든 감정은 놀라움이 아니라 이거였다.

나는 계속 따라가기만 하는구나. 뭘 해도 흉내내는 것 같다. 하네스 엔지니어링, 루프 엔지니어링, Hermes Agent...이걸 또 공부해야 하나...

공부는 계속했다. 강의도 듣고 프로젝트도 굴려봤다. 그런데 양은 늘어나는데 밀도가 안 느껴졌다.

 

' 나는 계속 따라가기만 하고 있구나. 뭘 해도 흉내내는 것 같다.'

 

실무자로서 AI를 활용해서 무엇인가 시도하는 사람이라면 나와 같은 사람이 꽤나 될 것 같다.

 

1. AI 활용에 대한 프로젝트 경험의 축적이 필요하다

생각해보면 실력이 부족한 게 아니라, 축적 구조가 없었다.

학습과 배움을 크게 2가지로 구분할 필요가 있다. 

 

반년이면 낡는 것

  • 새 프레임워크 사용법
  • 최신 모델 따라잡기
  • 튜토리얼 따라 치기
  • 남의 코드 복붙

낡지 않는 것

  • 문제 유형별 해결 패턴
  • 지식을 구조화하는 방법론
  • 끝까지 만들어 남긴 결과물
  • 실패에서 얻은 판단 기준

내가 생각하는 AI학습은 시간의 대부분이 위쪽에 있었다. 그렇다면 흉내내는 느낌은 착각이 아니라 정확한 자기 인식이었다.

 

하네스 이야기와 같은 구조

 

얼마 전 하네스(harness)에 대해 쓴 글이 있다. 요지는 이렇다.

하네스에는 두 종류가 있다. 모델이 못해서 만든 것과 우리가 안 정해서 만든 것.

JSON을 안정적으로 받으려고 정규식으로 파싱하고 세 번까지 재시도하던 코드. 긴 문서를 못 다루니 청크로 쪼개 요약하고 다시 합치던 파이프라인.

만들 당시엔 반드시 필요했고, 지금은 상당수가 필요 없어졌다. 실행 하네스는 모델과 제로섬이다. 잘 만든 실행 하네스의 이상적인 미래는 "잘 유지되는 것"이 아니라 "삭제되는 것"이다.

 

반면 기획 하네스 — 문제 정의, 판단 기준, 무엇을 포기했는지의 기록 — 는 성능 곡선 위에 놓여 있지 않다.

  • 모델은 훌륭한 기획서를 쓸 수 있다. 하지만 그게 틀렸을 때 손해를 보는 건 모델이 아니다.
  • 모델은 인터넷의 거의 모든 것을 읽었지만, 우리 팀이 작년에 그 기능을 왜 접었는지는 모른다. 어디에도 쓰인 적이 없으니까.

검색의 문제가 아니라 기록의 문제고, 기록은 사람이 한다.

 

커리어도 똑같았다

 

프레임워크와 최신 모델은 내 실행 하네스다. 필요할 때 꺼내 쓰면 되고, 진입장벽은 계속 낮아진다. 여기에 불안의 에너지를 쏟으면 안 된다.

내가 붙들어야 할 기획 하네스는 두 가지였다.

1. 설계 판단
이 문제에 RAG가 맞나 그냥 검색이 맞나. 지식을 어떤 단위로 쪼갤 것인가. 품질을 무엇으로 평가할 것인가. 도구가 바뀌어도 살아남는 판단력이다.

2. 도메인
내가 다루는 영역의 정보가 실제로 어떤 구조를 갖는지, 실무자가 어떤 순서로 그걸 찾는지. 이건 AI가 아무리 좋아져도 데이터로 존재하지 않는다. 그 안에 있는 사람만 안다.

오래 붙들고 있던 생각이 하나 있었다. "내 주변 비전문가들과 AI활용 능력을 비교하는 건 의미가 없다"는 것. 지금은 반만 동의한다.

안주하면 위험한 건 맞다. 하지만 그 격차 자체가 시장에서의 나의 가치이다. 순수 기술로 붙으면 나는 전업 엔지니어에게 밀린다. 당연하다. 그런데 "이 도메인을 깊이 알면서 AI를 실무에 적용할 줄 아는 사람"의 시장에는 경쟁자가 거의 없다.

의미 없다고 치부하던 비교 우위가 사실 나의 유일한 해자(Moat)였던 셈이다.

 

2. 프로젝트 경험을 축적하기 위한 나의 방법론

따라 치기만 하는 공부는 거의 남는 게 없다.

강의를 켜놓고 코드를 그대로 옮겨 적고, 끝까지 완주하고, 수료증을 받는다. 그 순간엔 뭔가 한 것 같다. 두 달 뒤에 백지에서 시작하면 아무것도 못 만든다. 나는 이걸 여러 번 겪고 나서야 방법을 바꿨다.

1단계 — 최대한 빠르게 전체를 훑는다

코드를 복붙하면서 진도만 뺀다. 이해가 안 가도 넘어간다. 이 단계의 목적은 이해가 아니라 지도를 그리는 것이다.

처음부터 꼼꼼히 이해하려 들면 중간에서 멈춘다. 그리고 멈춘 사람은 그 강의의 전체 구조를 모른다. 반면 이해를 포기하고 끝까지 달리면, 최소한 "이 분야에 어떤 부품들이 있고 대략 어떤 순서로 붙는다" 는 감각이 남는다.

나중에 실제 문제를 만났을 때 "아, 그때 그 비슷한 게 있었지"라고 떠올릴 수 있으면 그걸로 충분하다. 검색은 그 다음에 하면 된다. 모르는 것을 검색할 수는 없지만, 존재를 아는 것은 검색할 수 있다.

2단계 — 강의 내용을 꼼꼼히 이해하고, 기존 코드를 변형시켜 본다

같은 강의를 다시 본다. 이번엔 저자의 코드를 최대한 이해하려고 한다. 그리고 여기가 핵심인데, 강의에 나온 코드를 조금씩 고쳐가며 테스트한다.

  • 이 파라미터를 반대로 주면 어떻게 되나
  • 이 단계를 빼면 정말 망가지나, 아니면 사실 없어도 되나
  • 데이터를 내 것으로 바꾸면 어디서 깨지나

이 과정이 중요한 이유는, 저자가 왜 그렇게 했는지는 망가뜨려 봐야만 알 수 있기 때문이다. 잘 돌아가는 코드를 읽으면 모든 줄이 다 필요해 보인다. 한 줄씩 빼보면 그중 상당수가 사실은 그 저자의 특정 상황에만 필요했던 것임을 알게 된다.

3단계 — 강의를 참고하면서 내 프로젝트를 한다

그리고 마지막 단계. 진짜 내 문제를 해결하는 프로젝트일수록 효과가 좋다.

이게 결정적이다. 튜토리얼용 예제 데이터로 만든 것은 아무리 잘 만들어도 남지 않는다. 반면 내가 실제로 매주 겪는 불편을 해결하려고 만들면, 강의에서 안 다룬 문제가 반드시 튀어나온다.

  • 실제 공공데이터는 예제 CSV처럼 깨끗하지 않다
  • 문서 구조가 연도마다 바뀌어 있다
  • 개인정보나 비공개 항목이 섞여 있어서 그대로 못 쓴다
  • 잘 돌아가는 것처럼 보여도 정작 실무자가 원하는 답이 안 나온다

이 문제들은 강의에 안 나온다. 그리고 강의에 안 나오는 문제를 푼 경험만이 내 것으로 남는다. 1단계와 2단계에서 얻은 것은 반년이면 낡는다. 3단계에서 얻은 판단 기준은 낡지 않는다.

단계 — 그래서 이렇게 안 할 강의는 사지 않는다

3단계까지 갈 생각이 없는 강의나 책은 아예 안 산다. 이게 내가 세운 유일한 구매 기준이다.

바꿔 말하면 강의를 고르는 순서가 거꾸로다. 유명한 강의를 고르고 나서 쓸 데를 찾는 게 아니라, 먼저 내 현실의 문제를 정하고, 그 문제를 풀어줄 강의를 고른다. 그리고 그 문제를 반드시 프로젝트로 만든다.

이 기준을 세우고 나서 사는 강의 수가 확 줄었고, 완주율은 오히려 올라갔다. 그리고 결과물이 남기 시작했다.

 

3. 기획자와 현직자에게 있는, 잘 안 보이는 강점

AI 분야는 너무 빨리 바뀐다. 이건 사실이다. 그래서 다들 조바심을 낸다. 그런데 빨리 바뀐다는 사실 자체가 어떤 사람들에게는 유리하게 작동한다.

빨리 바뀌는 건 1층이다. 1층의 진입장벽이 계속 낮아진다는 건, 상대적으로 2층과 3층의 값이 올라간다는 뜻이다. 예전엔 아이디어가 있어도 구현할 사람이 없어서 못 했는데, 지금은 구현이 점점 싸진다. 그러면 병목은 "무엇을 만들 것인가" 와 "이게 잘 된 건지 어떻게 아는가" 로 옮겨간다.

현직 기획자가 가진 것은 정확히 그 두 가지다.

  1. 문제를 문장으로 쓸 수 있다. "고객 응대를 자동화하고 싶다"는 소망이고, "담당자가 오후 피크 시간에 문의 유형 분류를 못 따라가서, 단순 문의를 먼저 처리하고 복잡한 문의를 다음 날로 넘긴다"는 문제 정의다. 누가, 언제, 뭘 못해서, 뭘 포기하는가. 이 네 개를 채울 수 있는 사람은 조직 안에 있는 사람뿐이다.
  2. 결과가 좋은지 나쁜지 판단할 수 있다. 검색 결과 열 개를 보고 "이건 실무에서 못 쓴다"고 말할 수 있는 능력. 이건 벤치마크 점수로 대체되지 않는다. 나는 이걸 조직 내에서 사람들이 실제로 뭘 어떻게 찾는지를 보면서 배웠다. 그 시간이 기술과 무관하다고 생각했는데, 지금 보면 그게 평가 기준의 원천이었다.

기술만 있는 사람은 잘 만든다. 도메인만 있는 사람은 뭘 만들지 안다. 둘이 겹치는 자리에 있는 사람은 잘못 만들었을 때 그걸 알아챈다. AI가 그럴듯한 결과를 점점 더 잘 만들어내는 시대에, 마지막 능력이 제일 비싸진다고 생각한다.

 

마무리

지금 막막한 건 방향을 몰라서가 아니라 완벽한 답을 찾으려 해서였다. AI 분야에서 5년 뒤를 정확히 예측하는 건 누구도 못 한다. 그러니 예측하려 하지 말고, 어떻게 변해도 가치 있는 것에 투자하기로 했다. 그게 도메인 × 설계 판단력이고, 다행히 나는 이미 그 자리에 서 있었다.

AI 모델은 '어떻게'를 점점 더 잘하게 된다. 하지만 '왜 하는가'와 '무엇을 포기할 것인가'는 처음부터 모델에게 물어본 질문이 아니었다.

그리고 하나만 덧붙이자면 — "흉내내는 느낌"은 성장하는 사람만 느낀다. 안 배우는 사람은 그 느낌조차 없다. 불편함이 있다는 건 아직 성장 중이라는 뜻이다.

'강의&프로젝트' 카테고리의 다른 글

하네스는 언젠가 짐이 된다 — 그런데 A4 한 장은 끝까지 남는다  (0) 2026.08.04
하이브리드 RAG 검색 시스템, 설계하면서 부딪힌 4가지 갈림길  (1) 2026.07.13
[데이터 기획 실무] RDB의 한계를 넘는 온톨로지(Ontology) 활용법과 아키텍처 설계  (0) 2026.05.01
DB는 알지만 온톨로지는 이해하는 것: 왜 우리에게 '시맨틱 레이어'가 필요할까? 평범한 직장인 검색전문가 되기(1탄)  (0) 2026.04.29
2026년, 최신 Claude를 제대로 쓰는 법: Anthropic 연구로 배우는 프롬프트·컨텍스트 설계  (0) 2026.03.06
'강의&프로젝트' 카테고리의 다른 글
  • 하네스는 언젠가 짐이 된다 — 그런데 A4 한 장은 끝까지 남는다
  • 하이브리드 RAG 검색 시스템, 설계하면서 부딪힌 4가지 갈림길
  • [데이터 기획 실무] RDB의 한계를 넘는 온톨로지(Ontology) 활용법과 아키텍처 설계
  • DB는 알지만 온톨로지는 이해하는 것: 왜 우리에게 '시맨틱 레이어'가 필요할까? 평범한 직장인 검색전문가 되기(1탄)
AI강선생
AI강선생
AI강선생의 블로그 입니다.
  • AI강선생
    나의 배움과 성장의 궤적
    AI강선생
  • 전체
    오늘
    어제
    • 분류 전체보기 (27)
      • 강의&프로젝트 (9)
      • 독서&지식 (9)
      • 생각과다짐 (9)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
    • 개인정보처리방침
  • 링크

  • 공지사항

    • 소개 (About)
    • 개인정보처리방침
  • 인기 글

  • 태그

    하네스엔지니어링
    국회
    오레일리
    길벗
    spring
    AI agent
    유리링
    챌린지
    PostgreSQL
    Claude
    docker
    claude code
    인프런
    한빛미디어
    Rag
    에이전트
    시멘틱검색
    java
    온톨로지
    cursor
    AI에이전트
    혼공바이브코딩
    랭체인
    게임기획
    이지스퍼블리싱
    멀티에이전트
    클로드코드
    rustfs
    지식그래프
    FastAPI
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
AI강선생
따라가는 공부는 남지 않는다 — 실무 기획자가 AI를 통해 성장하는 방식
상단으로

티스토리툴바