LLM을 도구로 다루기 시작한 지 꽤 되었습니다. 이제는 하루 중 가장 오래 붙어 있는 인터페이스가 되었고, 그만큼 보이는 것도 생기고, 당황한 것도 생기고, 확신이 생긴 것도 있습니다. 이 글은 그 첫 번째 챕터입니다. ‘이론’이 아니라 ‘손으로 굴려보면서 알게 된 것’들을 정리했습니다.
최근에 무엇을 해봤나
요즘은 Claude를 주로 사용하고, 이전에는 Codex를 주로 썼습니다. 둘을 번갈아 쓰면서 ‘같은 작업을 다른 모델·다른 하네스로 시켜보면 무엇이 달라지는지’를 꽤 많이 비교해 보았습니다. 작은 LLM을 프로젝트로 직접 제작해 본 적도 있어서, ‘안쪽’에서 보는 눈과 ‘바깥쪽’에서 사용자로 쓰는 눈이 섞여 있는 편입니다.
지금 병행하고 있는 것들은 이렇습니다.
- 글쓰기: 블로그를 포함해서, ‘생각을 정리하는 도구’로서의 LLM
- 캐쥬얼 게임: 이미 앱스토어에 출시해 본 경험이 있고, 후속작을 만들고 있습니다
- 서비스 앱: 실제 운영까지 가는 것들
- FPS 게임: 위 스크린샷의 ShadowSix. 톰 클랜시의 레인보우식스를 떠올리며 프로토타입을 만들고 있습니다
이렇게 성격이 다른 것들을 동시에 돌려봐야 ‘어떤 일에는 잘 맞고, 어떤 일에는 생각보다 약하다’가 보입니다. 아래는 그 과정에서 알게 된, 지극히 주관적인 3가지입니다.
1. 조직에 적용한다면, QA와 PM(Plan)부터 다시 본다
만약 제가 이 일들을 조직 단위로 적용해야 한다면, 가장 무겁게 다루게 될 포지션은 QA와 PM(Plan)일 것 같습니다. 이유는 두 가지입니다.
첫째, LLM을 붙이면 ‘동시에 병행할 수 있는 일의 개수’가 체감적으로 몇 배로 늘어납니다. 그러면 무엇이 병목이 되느냐 — Plan(계획)을 누가 얼마나 잘 리드하느냐가 됩니다. 아이템이 10개 꽂혀 있는데 어떤 것부터 집을지, 어디서 멈출지, 어떤 건 버릴지를 정리하지 못하면 ‘빨라진 엔진’ 자체가 무기가 아니라 혼돈이 됩니다.
둘째, 생성 속도가 빨라질수록 새로 만든 것 / Major·Minor 핫픽스 / 리팩터링 후 회귀 등등 테스트해야 할 케이스가 기하급수적으로 늘어납니다. 사람 수는 그대로인데 변경 건수만 늘어난다면, QA를 예전 방식으로 두는 건 위험합니다. ‘무엇을 자동화할지, 무엇을 사람이 볼지’를 재설계해야 합니다.
그리고 하나 덧붙이자면, 작업하다 당황한 적이 꽤 있었습니다. LLM 답변에 이런 뉘앙스가 섞여 있을 때가 있습니다.
“Fact를 확인하지 못했지만, 일단 그런 것 같아 보여서 Fact처럼 말했습니다.”
주로 모델이 정확하게 모르는 영역의 문제를 풀어달라고 할 때 이런 현상이 나왔습니다. ‘아는 척’이 아니라 ‘모르는 것을 모른다고 말하지 못하는 상태’에 가깝습니다. 이걸 모르고 바로 믿으면 그대로 버그가 됩니다. 그래서 QA가 중요합니다 — 모델이 만든 것을 ‘기본적으로 의심하는 안전망’으로서의 QA입니다.
2. 새로운 프로세스를 만드는 데 시간을 쓰고 싶다
LLM을 도입하는 조직이라면, 저는 ‘새로운 적절한 프로세스를 설계하는 시간’에 꽤 많은 리소스를 쓰고 싶습니다. 효율적인 생산성 향상이 분명히 있다고 판단했기 때문입니다.
다만, 반대도 경험했습니다. 무분별하게 도입하면 시행착오가 기존 프로세스의 안정성에도 영향을 줍니다. 리뷰 기준이 흔들리고, 코드 오너십이 흐려지고, “이거 누가 짠 거였죠?”가 늘어납니다. 그래서 ‘도입 = 생산성 향상’이 아니라 ‘잘 설계된 도입 = 생산성 향상‘입니다.
저는 이 부분을, AI 시대의 엔지니어링 매니저가 가장 먼저 손대야 할 일이라고 보고 있습니다. ‘얼마나 빨리 쓰느냐’가 아니라, ‘팀 단위로 지속 가능한 프로세스를 얼마나 빨리 안정화시키느냐‘의 싸움입니다.
3. 자율 에이전트 — 이미 ‘딸깍’이 되는 영역이 있다
저도 자율 에이전트가 필요해서 여러 방식으로 시도해 보고 있습니다. 재미있는 건, 위에 나열한 작업들 중 어떤 것은 이미 ‘딸깍!’이라고 할 만한 수준이 되었다는 점입니다. 반대로 어떤 일은 여전히 사람이 중간에 개입해야 합니다.
어느 정도 신뢰가 쌓인 파이프라인에서는 --dangerously-skip-permissions 옵션을 걸어두는 것도 더 이상 두렵지 않습니다. 물론 이것은 ‘무서운 옵션을 무섭지 않게 만들 만큼 울타리(샌드박스·검증 체계)를 먼저 만들어 두었기 때문’에 가능한 이야기입니다. 울타리 없이 이 옵션을 켜는 건 그냥 사고입니다.
가장 크게 달라진 건 머릿속의 감각입니다. 생각만 하고 시도하지 않았을 때와 적극적으로 여러 번 돌려본 뒤 사이에, 짧은 시간 안에 꽤 많은 배움이 쌓였습니다. 모든 걸 다 경험해 본 뒤에 의사결정을 할 수는 없지만, 적어도 ‘어떤 영역에 대해서는 더 좋은 판단을 내릴 수 있겠다’는 자신이 생겨가고 있습니다.
So What — 한국 직장인·시니어에게 의미
결국 이 챕터1에서 제가 한국 독자분들께 전하고 싶은 메시지는 간단합니다.
- 시도하세요. 읽는 것과 직접 돌려보는 것 사이에는 ‘몇 달 치’ 차이가 있습니다.
- QA·Plan 관점으로 봐두세요. 실무에 도입할 때 진짜로 필요한 역할이 바뀝니다. AI가 대체하는 건 ‘작업자’가 아니라 ‘관리 안 되는 작업‘입니다.
- 프로세스 설계에 투자하세요. 모델이 아니라 ‘팀의 운영 방식’이 생산성의 상한을 정합니다.
- 자율 에이전트는 이미 일부 영역에서 실전입니다. 모든 영역이 아니라는 점만 잊지 않으면 됩니다.
지금 바로 할 수 있는 것
- 작은 프로젝트 하나를 직접 LLM과 끝까지 밀어보기. 블로그 글 1편도 좋고, 캐쥬얼 게임 프로토타입도 좋습니다. ‘끝까지’가 중요합니다.
- 동일한 작업을 Claude와 Codex(혹은 다른 모델)에 시켜보고 비교하기. 차이를 보면 ‘도구 고르는 눈’이 생깁니다.
- LLM의 답변 중 “확인은 못 했지만” 뉘앙스가 숨은 것을 일부러 찾아보기. 한 번 잡아내면, 그다음부터 똑같은 함정을 피할 수 있게 됩니다.
챕터2에서는 이 중 하나 — 아마도 FPS 게임 또는 자율 에이전트 파이프라인 — 를 골라 더 깊게 들어가 보려 합니다.