오늘 AI 뉴스는 한마디로 “모델이 아니라 운영이 제품을 만든다” 쪽으로 기운다. 에이전트는 기본값과 안전장치가 승패를 가르고, 연구용 추론은 별도 라인업으로 굳고, 경량 오픈소스는 진짜 배포 단계로 들어왔다.
에이전틱 코딩: 똑똑함보다 “기본값 + 가드레일 + 서빙”이 더 무섭다
요즘 코딩 에이전트 제품들을 보면, 성능을 자랑하는 문장보다 “어떻게 돌릴 거냐”가 더 앞에 온다. 단순히 코드 한 덩이를 잘 짜는 모델을 넘어서, 레포를 읽고, 테스트를 돌리고, 실패를 되돌리고, PR을 쪼개고, 리뷰 코멘트를 반영하는 전체 루프가 본체가 됐다.
여기서 중요한 건 모델이 아니라 기본값이다. 예를 들면 이런 것들.
- 기본으로 테스트를 돌리나, 아니면 사용자가 시키기 전엔 안 하냐
- 실패했을 때 재시도 전략이 있나, 아니면 “그냥 다른 말로 다시”가 전부냐
- 접근 권한과 실행 권한을 어디까지 열어두나
- 로그와 아티팩트를 남겨서 팀이 재현할 수 있게 하냐
에이전틱 코딩은 “답을 잘한다”보다 “팀에서 사고를 덜 친다”가 더 가치가 크다. 코드가 잘못되면 롤백하면 되는데, 자동으로 날려버린 설정값이나 엉뚱하게 건드린 인프라 리소스는 비용이 바로 튀어나온다. 그러니까 경쟁력은 모델 IQ가 아니라, 실행 경로에 깔아둔 브레이크 품질로 수렴한다.
또 하나는 서빙 품질이다. 에이전트가 IDE나 CLI에 붙는 순간, 토큰이 1% 더 정확한 것보다 “지금 바로 반응하냐”가 체감 차이를 만든다. 그래서 모델 회사들이 점점 “추론 최적화, 캐시, 스트리밍, 저지연” 같은 인프라 이야기를 제품 이야기의 중심에 놓는다. 사용자 입장에서는 간단하다. 똑같이 똑똑하면, 더 빨리 움직이는 놈이 이긴다.
연구용 딥 리즈닝: 대화형 모델과 완전히 다른 제품이 된다
연구/공학 쪽 문제는 보통 데이터가 지저분하고, 제약이 문서에 안 적혀 있고, 정답이 하나가 아니다. 그래서 여기서 필요한 건 “그럴듯한 답”이 아니라 “재현 가능한 작업 흐름”이다.
딥 리즈닝 계열 모델이 의미 있는 이유는, 사람도 헷갈리는 문제를 풀 때 결과물의 형태가 달라지기 때문이다.
- 최종 답만 주는 게 아니라, 가정과 조건을 구조화해서 남긴다
- 실험 계획이나 검증 항목을 먼저 만든다
- 실패했을 때 어디서부터 다시 확인해야 하는지 체크리스트가 생긴다
이 흐름이 굳어지면 제품 라인업이 분리된다. 일상 대화용 모델은 빠르고 저렴하게 넓게 커버하고, 연구용은 느려도 깊게, 대신 기록과 검증을 남기는 쪽으로 간다. 같은 “LLM”이라도 사실상 다른 공구다. 망치랑 토크 렌치가 둘 다 금속 막대라고 같은 제품군인 건 아니니까.
그리고 이쪽은 벤치마크 점수만으로는 부족하다. 팀 단위로 쓰려면 결국 다음이 필요하다.
- 결과를 공유하고 버전 관리할 수 있는 형태
- 입력 데이터와 파라미터를 묶어서 재현 가능하게 남기는 기능
- 도메인별 규정과 안전 요구사항을 충족하는 감사 로그
결국 딥 리즈닝은 “모델 출시”보다 “워크플로우 출시”가 된다.
온디바이스 + 경량화 + 오픈소스: 이제는 ‘데모’가 아니라 ‘배포’ 단계
오픈소스 모델은 한동안 “성능이 어디까지 따라왔냐”로 이야기했는데, 지금은 질문이 바뀌었다. “이걸 프로덕션에서 어떻게 굴리냐”가 핵심이다. 그리고 그 답은 대체로 경량화와 온디바이스 쪽에 있다.
온디바이스의 매력은 단순히 비용 절감이 아니다.
- 지연 시간이 예측 가능하다
- 네트워크가 끊겨도 기능이 유지된다
- 민감 데이터가 밖으로 안 나간다
특히 제품팀 입장에서는, 개인정보/기밀 데이터 처리 이슈가 한 단계 내려간다는 게 크다. ‘서버에 보내도 괜찮을까’에서 ‘로컬에서 돌리자’로 가면, 법무/보안/리스크의 속도가 달라진다.
여기에 양자화, 증류, 스파스, KV 캐시 최적화, 컴파일러 기반 그래프 최적화 같은 것들이 붙으면서 “작은데 쓸만한 모델”이 확 늘어난다. 그리고 오픈소스 생태계는 여기서 강하다. 모델 자체도 모델인데, 변환과 실행 도구 체인이 빠르게 쌓인다. 누가 이기냐는 생각보다, 그냥 선택지가 폭발하는 국면이다.
다만 경량화는 공짜가 아니다. 성능이 내려가면, 결국 프롬프트/툴/가드레일을 더 빡세게 해야 한다. 그래서 온디바이스가 커질수록, 소프트웨어 엔지니어링이 다시 중요해진다. 모델이 약해도 제품이 강하면 된다. 그런데 그 ‘제품이 강함’은 대부분 엔지니어링 부채로 환산된다. 그러니까 팀이 감당할 체력을 보고 골라야 한다.
안전과 컴플라이언스: “착한 척”이 아니라 기능이고, 경쟁력이고, 비용 절감이다
가드레일은 예전엔 슬라이드 마지막에 들어가는 “우리는 안전을 중요하게 생각합니다” 영역이었다. 지금은 다르다. 에이전트가 행동하기 시작하면 안전은 기능이 된다. 더 정확히는 브레이크와 핸들이다.
안전이 기능이 되면, 평가도 기능이 된다. 제품이 커질수록 다음이 필요해진다.
- 프롬프트/정책 변경이 실제로 리스크를 낮췄는지 확인하는 회귀 테스트
- 다국어에서 정책 일관성이 유지되는지 보는 평가 세트
- “거절” 자체가 품질을 해치지 않도록 사용자 경험 설계
여기서 재미있는 포인트는, 안전이 비용이 아니라 비용 절감으로 연결된다는 점이다. 사고가 한 번 나면 손실이 너무 크다. 그래서 안전은 “속도를 늦추는 것”이 아니라, 조직 전체의 개발 속도를 유지하는 보험이 된다. 그리고 보험은 결국 숫자로 측정된다. 보안팀이 좋아하는 종류의 숫자 말이다.
예상되는 미래 (Expected Future)
오늘 이야기를 한 줄로 요약하면 이거다. AI는 이제 ‘모델’ 경쟁이 아니라 ‘제품 운영’ 경쟁이다. 그래서 앞으로 1~2년은 다음이 더 선명해질 것 같다.
- 에이전틱 코딩은 디폴트가 된다. 대신 “기본값이 안전한 에이전트”가 표준이 된다. 빠른데 테스트 안 도는 에이전트는 개인 장난감으로 남고, 팀 도구는 결국 가드레일 중심으로 굳는다.
- 연구용 딥 리즈닝은 모델 스펙보다 실험 재현성과 협업 UX로 차별화된다. 논문 요약을 잘하는 건 시작이고, 연구 노트가 자동으로 쌓이는 도구가 먹는다.
- 온디바이스는 ‘비용’이 아니라 ‘규정’ 때문에 더 커진다. 데이터가 밖으로 못 나가는 산업이 많고, 그런 곳에서는 작은 모델이 왕이 된다.
- 안전/컴플라이언스는 선택이 아니라 플랫폼 요구사항이 된다. 앞으로는 “안전하지 않아서 못 판다”가 더 자주 등장할 거다.
결국 이 시장에서 오래 버티는 팀은 두 부류일 가능성이 높다. 하나는 인프라를 돈으로 밀어붙이는 팀, 다른 하나는 도메인에서 평가/안전/워크플로우까지 엮어서 작지만 딱 맞는 제품을 만드는 팀. 중간은 계속 얇아진다.