[태그:] AI

기업 10곳 중 8곳이 AI 에이전트를 검토 중이거나 이미 쓰고 있다고 답했다. 실험 단계는 진작에 지났다는 뜻이다. 근데 진짜 문제는 그 다음부터다. 도입은 했는데, 기대했던 성과가 안 나온다는 하소연이 여기저기서 들린다. 원인을 하나씩 파고 들어가 보면 결국 한 지점에서 막힌다. 데이터.

챗봇이랑 뭐가 다른데?

AI 에이전트랑 챗봇을 같은 걸로 착각하는 사람, 생각보다 많다. 챗봇은 물어보면 답만 한다. 에이전트는 다르다. 스스로 판단하고, 여러 단계를 거쳐 실제로 일을 처리한다.

• 고객 문의를 읽고 환불 규정 확인한 다음, 진짜로 환불까지 처리
• 재고 데이터 조회해서 부족한 품목을 발주 시스템에 자동 등록
• 코드 저장소 뒤져서 버그 찾고 수정안까지 작성

핵심은 행동이다. 대답만 던지고 끝나는 게 아니라 실제 시스템을 건드린다. 이 지점에서 챗봇과는 완전히 다른 물건이 된다.

데이터가 왜 생사여탈권을 쥐고 있나

에이전트가 알아서 움직인다는 건 양날의 검이다. 데이터가 정확하면 업무 속도는 몰라보게 빨라진다. 근데 데이터가 틀렸거나 오래됐으면? 그 오류가 그대로 실행된다. 챗봇이 이상한 답을 뱉으면 사람이 걸러내고 넘어가면 그만이다. 에이전트는 걸러낼 틈도 없이 주문을 넣고, 이메일을 보내고, 시스템 값을 바꿔버린다. 되돌리기 번거로운 일들이다.

MIT 테크놀로지 리뷰가 짚은 대로, 에이전트 프로젝트의 ROI는 모델 성능보다 데이터 인프라 쪽에 달려 있는 경우가 많다고 한다. 아무리 좋은 모델을 붙여놔도 참조하는 데이터가 사일로에 갇혀 있거나 갱신이 느리면, 결과물은 부실할 수밖에 없다. 모델 탓이 아니라는 얘기다.

도입한 기업들, 다 이 벽에 걸린다

실제 사례를 뜯어보면 패턴이 비슷하다.

• 데이터 사일로 — 부서마다 다른 시스템에 데이터가 흩어져 있어서 에이전트가 전체 그림을 못 본다
• 신선도 부족 — 하루 한 번 배치로 갱신되는 데이터를 실시간 판단에 쓰다 보니 엇박자가 난다
• 권한 관리 공백 — 누가 어떤 데이터에 접근해서 뭘 했는지 추적이 안 되는 경우가 태반이다

이 셋 중 하나만 걸려도 프로젝트는 파일럿 단계에서 멈춘다. 셋 다 걸리면? 말할 것도 없다.

믿고 쓸 만한 데이터 인프라, 조건은 네 가지

에이전트를 실전에 투입하려면 최소 이 네 가지는 갖춰야 한다.

• 정확성 — 출처가 검증된 데이터, 중복이나 오류 없는 값
• 접근성 — API나 MCP(Model Context Protocol) 같은 표준 연동으로 여러 시스템을 한 창구에서 조회
• 거버넌스 — 누가 뭘 봤고 뭘 바꿨는지 남는 감사 로그, 세밀한 권한 설정
• 실시간성 — 재고, 가격, 상태값처럼 자주 바뀌는 데이터는 최소 몇 분 단위로 갱신

개인적으로 이 넷 중에서 거버넌스를 제일 늦게 챙기다가 뒤통수 맞는 조직, 진짜 많이 봤다. 초반엔 다들 정확성이랑 속도에만 매달린다. 그러다 에이전트가 잘못된 권한으로 민감 데이터를 건드리는 사고가 한 번 터지면, 그제서야 부랴부랴 손보기 시작한다. 순서가 항상 거꾸로다.

도입 전에 체크해야 할 것들

실무에서 바로 써먹을 수 있는 점검 항목이다.

• 에이전트가 접근할 데이터 소스 목록, 전부 파악했는가
• 각 데이터의 갱신 주기와 신뢰도를 알고 있는가
• 잘못된 행동을 했을 때 되돌릴 롤백 절차가 있는가
• 사람이 최종 승인해야 하는 액션과 자동 실행해도 되는 액션, 구분해뒀는가
• 파일럿 성공 여부를 판단할 명확한 KPI(처리 시간, 오류율, 비용 절감액 등)를 세웠는가

결국 남는 조직과 사라지는 조직

성과 낸 조직들 보면 접근 방식이 비슷하다. 전사 도입부터 밀어붙이지 않는다. 반복 업무 하나 골라서 좁게 시작한다. 그 안에서 데이터 파이프라인 다듬고 거버넌스 체계 검증한 다음에야 범위를 넓힌다. 처음부터 완벽한 데이터 인프라 갖추고 시작하는 조직, 거의 없다. 작은 실패를 빨리 겪고 고쳐나가는 속도. 그게 결과를 가른다.

궁금할 만한 것들

Q. AI 에이전트 도입에 꼭 대규모 데이터팀이 필요한가?
아니다. 소규모 팀도 데이터 소스를 3~4개로 좁혀서 시작하면 충분히 검증 가능하다. 규모보다 데이터 정합성 체크 프로세스가 있느냐가 관건이다.

Q. RAG(검색증강생성)만 잘 구축하면 데이터 문제는 해결되나?
RAG는 참조용 데이터를 잘 찾아오는 기술이다. 그 데이터 자체의 정확성이나 신선도까지 보장해주는 건 아니다. 소스 데이터 관리가 먼저다.

Q. 기존 챗봇 시스템에서 에이전트로 넘어갈 때 뭐부터 바꿔야 하나?
권한 체계부터 다시 짜는 걸 추천한다. 챗봇은 답변만 하지만 에이전트는 실행 권한을 갖는다. 기존의 느슨한 접근 제어를 그대로 가져가면, 사고 확률이 확 올라간다.

출처: MIT Tech Review AI

2017년, 구글 연구진이 트랜스포머 구조를 세상에 내놨다. 벌써 9년 전 일이다. 그런데 지금 나오는 AI 모델을 보면, 거의 다 이 뼈대를 그대로 쓴다. GPT 계열도, 제미나이도, 클로드도 예외는 없다. 근데 최근 분위기가 좀 달라졌다. 이 표준에 도전장을 내미는 스타트업들이 하나둘 늘고 있어서다. 트랜스포머 다음은 뭐가 될지, 학계 연구 흐름은 어디로 튀고 있는지 한번 정리해봤다.

왜 다들 트랜스포머를 쓰나

핵심은 셀프 어텐션(self-attention)이다. 문장 안의 모든 단어가 서로 얼마나 관련 있는지, 한 번에 계산해버리는 방식. 이 덕분에 GPU로 병렬 학습이 가능해졌고, 학습 속도가 확 빨라졌다. 데이터랑 연산량을 늘리면 성능이 예측 가능한 곡선을 그리며 좋아진다는 ‘스케일링 법칙’도 여기서 나왔다. 오픈AI, 구글, 앤스로픽… 다 이 위에 모델을 쌓아 올린 이유다.

근데 약점도 뚜렷하다

문제는 셀프 어텐션의 연산량이 입력 길이의 제곱에 비례한다는 것. 문장이 두 배 길어지면 연산량은 네 배로 뛴다. 긴 문서, 긴 대화를 다룰수록 메모리와 비용이 기하급수적으로 불어난다. 긴 문맥 창 지원한다고 광고하는 모델일수록, 뒤에서는 추론 비용이 만만치 않게 들어간다. 이건 좀 아이러니한 부분이다. 실시간 응답이 필요한 서비스나 스마트폰 같은 온디바이스 환경에서는, 이 구조가 부담스러울 수밖에.

그래서 나온 대안들, 뭐가 다를까

• SSM(상태공간모델): 대표주자는 Mamba다. 연산량이 입력 길이에 비례해서 늘어난다. 긴 시퀀스 처리에 유리한 이유다.
• MoE(전문가 혼합): 전체 파라미터 중 일부만 골라 활성화하는 방식. 미스트랄의 Mixtral이 대표적이다. 모델은 크게 키우되, 실제 연산은 아껴 쓰는 셈.
• RWKV: RNN 구조를 현대적으로 재해석했다. 추론 비용 낮추는 데 초점을 맞췄다.
• 하이브리드 구조: 트랜스포머 레이어 사이에 SSM을 섞는다. AI21의 Jamba가 대표 사례.

스타트업들이 새 구조에 뛰어드는 진짜 이유

빅테크만큼 GPU를 쌓아둘 수 없는 스타트업 입장에서, 연산 효율은 곧 생존 문제다. 추론 비용을 낮추면 그만큼 서비스 마진을 확보할 여지가 생긴다. 음성 AI 스타트업 카르테시아(Cartesia)가 SSM 기반 모델을 밀고 있는 것도, AI21이 하이브리드 구조 Jamba를 내놓은 것도 다 이런 배경에서다. 코드 생성, 음성 처리, 로봇 제어처럼 특정 영역에 특화된 모델을 만들 때는, 범용 트랜스포머보다 목적에 맞춘 구조가 훨씬 잘 먹힌다.

학계 연구 흐름도 슬쩍 바뀌는 중

초대형 모델을 처음부터 학습시키려면 수백억 원대 연산 비용이 든다. 대학 연구실이 감당할 규모가 아니다. 그러다 보니 새 아키텍처를 밑바닥부터 설계하는 연구는, 빅테크와 자금력 있는 스타트업 쪽으로 무게중심이 옮겨갔다. 대신 학계는 다른 쪽으로 눈을 돌렸다. 모델 성능을 검증하는 벤치마크 설계, 모델 내부가 어떻게 작동하는지 뜯어보는 해석가능성 연구, 그리고 작은 모델로도 성능을 끌어올리는 경량화·압축 연구. 메타나 미스트랄 같은 곳이 모델 가중치를 오픈소스로 풀면서, 학계도 실험할 발판을 얻은 게 이 흐름을 거들었다.

그래서 실무자는 지금 뭘 챙겨야 하나

특정 API 하나에만 발 담그기보다, 아키텍처별 특성을 알아두는 편이 낫다. 긴 문서나 긴 대화 이력을 다루는 서비스를 만든다면, SSM이나 하이브리드 계열 모델을 한번 벤치마크 해볼 만하다. 비용이 서비스 마진을 좌우하는 구조라면, MoE 기반 모델부터 검토하는 게 맞다. 이 부분은 직접 벤치마크 돌려보면 확실히 체감된다. 허깅페이스 트렌딩 모델이나 오픈소스 리더보드를 주기적으로 훑어보는 것만으로도, 흐름을 놓치지 않을 수 있다.

그럼 트랜스포머는 없어지나

아니다. 당장은. 트랜스포머는 여전히 압도적 다수 모델의 기반이고, 생태계와 도구가 가장 잘 갖춰진 구조다. 다만 모든 상황에 다 맞는 만능 구조는 아니라는 공감대가 커지는 중이다. 앞으로는 상황에 맞춰 SSM, MoE, 하이브리드를 섞어 쓰는 쪽으로 재편될 가능성이 높다. 어떤 구조가 표준이 되든, 그 변화를 먼저 알아채는 쪽이 서비스 설계에서 유리한 고지를 차지하게 될 거다.

출처: MIT Tech Review AI

AI 이미지 생성 도구 하나면 몇 초 만에 그럴듯한 가짜 사진이 나온다. 텍스트든 이미지든 영상이든, 이제 육안으로 진짜와 가짜를 가르기가 쉽지 않다. 정교하게 조작된 콘텐츠는 소셜미디어를 타고 순식간에 퍼진다. 정부와 플랫폼 기업은 이걸 걸러내는 방법을 놓고 계속 부딪힌다. 실전에서 써먹을 수 있는 구별법과 관련 용어, 그리고 논쟁의 핵심까지 정리해봤다.

가짜뉴스도 종류가 다르다 — 미스인포메이션 vs 디스인포메이션

가짜뉴스를 부르는 말이 하나가 아니다. 미스인포메이션(misinformation)은 퍼뜨리는 사람한테 악의가 없는 경우를 가리킨다. 잘못 알고 그냥 공유해버리는 흔한 사례가 여기 속한다. 반대로 디스인포메이션(disinformation)은 다르다. 여론을 흔들거나 특정 세력한테 이득을 주려고 일부러 만들어 퍼뜨리는 허위 정보다. 국가가 뒤에서 벌이는 정보전에서 자주 쓰이는 용어이기도 하다.

여기에 하나 더, 맬인포메이션(malinformation)이라는 개념도 있다. 사실이긴 한데 맥락을 왜곡해서 해를 끼치려는 목적으로 유포되는 정보를 뜻한다. 사적인 정보를 짜깁기해 특정 인물을 저격하는 식이다. 세 용어를 구분해둬야 관련 정책 기사나 팩트체크 보도를 제대로 읽어낼 수 있다.

AI는 가짜뉴스를 어디까지 정교하게 만드나

생성형 AI가 나오기 전엔 조작된 이미지나 영상 하나 만들려 해도 편집 기술이 필요했다. 지금은? 텍스트 프롬프트 몇 줄만 입력하면 실제 인물의 얼굴과 목소리를 합성한 딥페이크 영상이 몇 분 안에 나온다. 대규모언어모델(LLM)은 그럴듯한 문체로 가짜 기사를 대량 찍어내는 데도 쓰인다. 이 정도면 웬만한 전문가도 한 번에 못 알아챈다.

• 텍스트: 실제 언론사 문체를 흉내 낸 가짜 기사, 봇 계정으로 대량 유포
• 이미지: 실존하지 않는 인물이나 사건을 담은 합성 사진
• 음성·영상: 정치인이나 유명인의 발언을 조작한 딥페이크

텍스트 가짜뉴스, 체크포인트 3가지만 기억하자

첫째, 출처부터 본다. 기사 하단에 기자명과 발행사가 적혀 있는지, 그 매체가 실제로 검색되는 언론사인지 확인한다. 둘째, 교차 확인. 같은 내용을 다른 매체에서도 다뤘는지 찾아본다. 단독 매체 한 곳에서만 도는 자극적인 소식은 일단 의심하고 보는 게 맞다. 셋째, 제목과 본문이 맞는지 본다. 감정을 자극하는 제목에 비해 실제 팩트가 빈약하면, 조작 가능성이 높다.

이미지·영상 딥페이크, 여기서 허점이 드러난다

딥페이크 영상은 눈 깜빡임 빈도, 조명과 그림자의 부자연스러움, 입 모양과 음성 사이 미세한 싱크 오차에서 허점이 드러나는 경우가 많다. 이미지라면 구글 렌즈(Google Lens)나 틴아이(TinEye) 같은 역이미지 검색 도구로 원본 출처를 추적할 수 있다. 영상 검증이 필요할 땐 InVID-WeVerify 같은 브라우저 확장 프로그램이 쓸만하다. 프레임 단위 분석이나 메타데이터 확인까지 되니까.

팩트체크 사이트, 이 정도는 즐겨찾기 해두자

직접 검증하기 어려운 소식은 팩트체크 전문 기관을 거치는 편이 빠르다.

• SNU 팩트체크: 서울대 언론정보연구소가 운영하는 국내 언론 협업 검증 플랫폼
• 네이버 팩트체크: 포털 안에서 이슈별 검증 기사를 모아 보여주는 서비스
• 구글 팩트체크 익스플로러: 전 세계 팩트체크 매체의 검증 결과를 키워드로 검색
• 스노프스(Snopes): 해외발 루머와 도시전설까지 폭넓게 다루는 원조 팩트체크 사이트

정부 규제 vs 표현의 자유, 이 논쟁이 안 끝나는 이유

정부 차원에서 허위정보 대응 조직을 두는 나라가 늘고 있다. 선거철 외국발 정보 조작이나 공중보건 관련 허위정보를 추적한다는 명분이다. 문제는 이 조직의 판단 기준이 불투명할 때 터진다. 정부나 플랫폼이 특정 정치 성향 콘텐츠만 골라 걸러낸다는 의혹이 나오면, 논쟁은 곧장 검열 시비로 번진다. 미국에서는 이런 대응 체계를 두고 ‘검열산업복합체(censorship-industrial complex)’라는 말까지 나왔다. 정부 기관과 빅테크, 학계 연구기관이 손잡고 특정 여론을 억누른다는 비판적 시선을 담은 조어다.

유럽연합은 디지털서비스법(DSA)으로 플랫폼에 허위정보 대응 의무를 지운다. 반면 미국은 수정헌법 1조에 따른 표현의 자유 침해 여부를 놓고 정부 개입 자체에 회의적인 목소리가 크다. 둘 중 어느 쪽이 맞는지는 아직 결론이 안 났다. 솔직히 여기서 갈린다. 콘텐츠 검증 책임을 정부, 플랫폼, 이용자 중 누가 얼마나 짊어져야 하는지에 대한 답이 지역마다 다르기 때문이다.

자주 나오는 질문들

Q. 팩트체크 사이트도 편향될 수 있나?
가능하다. 팩트체크 기관도 특정 이슈를 어떻게 고르고 해석하느냐를 두고 편향 논란을 겪는다. 한 곳의 판정만 믿기보다 여러 매체의 검증 결과를 비교하는 습관, 이게 안전하다.

Q. 딥페이크 탐지 AI는 얼마나 정확한가?
탐지 모델과 생성 모델은 서로 학습하며 발전하는 관계다. 쫓고 쫓기는 셈이다. 현재 상용 탐지 도구의 정확도는 콘텐츠 종류와 조작 수준에 따라 편차가 크다. 도구 하나에만 기대지 않는 게 좋다.

Q. 개인이 허위정보 유포에 연루되면 법적 책임이 있나?
나라마다 다르다. 다만 명백한 허위 사실 적시로 명예훼손이나 업무방해에 해당하면 처벌로 이어진 사례도 있다. 단순히 공유만 했더라도 악의적 의도가 확인되면 책임을 피하기 어렵다.

출처: MIT Tech Review AI

코드 한 줄만 부탁했는데 프로젝트 구조 전체를 알아서 짜준다. 요즘 얘기다. 개발자 커뮤니티에는 클로드 코드로 하루 만에 예전 팀 프로젝트급 결과물을 뽑아냈다는 후기가 꾸준히 올라온다. 동시에 오픈소스 쪽에서도 심상치 않은 움직임이 있다. B200 GPU 48장으로 나흘 만에 코딩 특화 모델을 학습시켜 공개한 사례가 나온 거다. 문제는 이거다. 막상 실무에 도입하려니 뭘 골라야 할지 감이 안 온다. 상용 AI 코딩툴과 오픈소스 모델은 접근 방식부터 완전히 다르다. 성능 숫자만 보고 결정했다가는 나중에 후회하기 십상이다.

AI 코딩 어시스턴트, 뭐가 다른가

큰 틀에서 보면 두 갈래다. 클로드 코드, 깃허브 코파일럿, 커서 같은 상용 에이전트형 툴 하나. 허깅페이스에 가중치를 공개하는 오픈소스 코딩 모델이 다른 하나다. 전자는 코드 생성은 기본이고 파일 탐색, 터미널 명령 실행, 테스트 실행까지 하나의 워크플로우로 묶어놨다. 후자는 모델 자체 성능을 API나 로컬 환경에 붙여 쓰는 방식이다. 이름은 똑같이 ‘코딩 AI’인데, 써보면 경험이 꽤 다르다.

클로드코드류 에이전트형 툴, 뭐가 강한가

상용 툴이 앞서는 지점은 단순 코드 생성이 아니다. 작업을 끝까지 완수하는 능력이다. 구글의 한 엔지니어가 자기 팀이 1년 걸려 만든 분산 에이전트 오케스트레이션 시스템을, 클로드 코드에 세 문단짜리 설명만 던져주고 한 시간 만에 근사치로 뽑아낸 사례가 화제였던 것도 이 때문이다. 실무에서는 코드를 짜는 시간보다 여러 파일을 오가며 컨텍스트를 붙잡고, 에러 나면 스스로 고쳐보는 반복 작업이 훨씬 비중이 크다. 이 부분, 에이전트형 툴이 확실히 한 수 위다.

• 파일 시스템과 터미널을 직접 다루는 에이전트 워크플로우
• 대화형으로 요구사항을 다듬어가며 반복 개선 가능
• 별도 인프라 구축 없이 바로 쓰는 접근성

오픈소스 코딩 모델이 뜨는 이유

오픈소스 진영은 투명성과 재현 가능성을 무기로 든다. 크립토 벤처 파라다임 투자를 받은 누스 리서치가 내놓은 NousCoder-14B가 대표 사례다. 알리바바의 Qwen3-14B를 베이스로 강화학습을 거쳤고, 경쟁 프로그래밍 벤치마크 LiveCodeBench v6에서 정확도를 7%포인트 넘게 끌어올렸다. 여기서 볼 대목은 따로 있다. 모델 가중치만 던져준 게 아니라, 검증 가능한 보상 신호로 학습시키는 강화학습 환경과 훈련 코드 전체를 아파치 2.0 라이선스로 풀었다는 점. 이러면 연구자가 같은 방식으로 재현하거나 다른 도메인에 응용할 여지가 생긴다.

학습 방식도 재미있다. 모델이 코드를 생성하면 실제로 돌려서 테스트 케이스를 통과하는지 아닌지, 이진 신호로만 피드백을 준다. 여기에 DAPO라는 동적 샘플링 기법을 붙여서, 이미 다 맞히거나 다 틀리는 문제는 학습에서 빼는 식으로 효율을 끌어올렸다. 학습에는 24,000개의 경쟁 프로그래밍 문제를 썼는데, 연구진 스스로 이게 인터넷에 존재하는 검증 가능한 문제 풀 규모와 비슷한 수준이라고 밝혔다. 데이터가 무한하지 않다는 얘기, 은근히 무겁게 다가온다.

벤치마크 숫자만 믿으면 안 되는 이유

벤치마크 점수 높다고 바로 실무에 갖다 쓸 수 있는 건 아니다. NousCoder-14B는 경쟁 프로그래밍 문제 풀이에 최적화된 모델이다. 단발성 문제 해결에는 강한데, 이게 에이전트형 작업 — 여러 파일을 오가며 대규모 코드베이스를 리팩터링하는 작업 — 에도 똑같이 강한지는 별개 질문이다. 실제로 공개 직후 커뮤니티에서 “원샷 코딩이냐 에이전틱 작업이냐”를 묻는 질문이 나왔을 정도. 벤치마크는 특정 조건에서의 스냅샷일 뿐이다. 자기 워크플로우와 벤치마크가 재는 능력이 얼마나 겹치는지부터 따져봐야 한다.

비용과 데이터 보안, 실무에서 진짜 갈리는 지점

결정적으로 갈리는 건 결국 비용 구조와 데이터 통제권이다. 상용 툴은 구독료나 API 사용량 기반 과금이라 초기 진입은 쉽다. 다만 사용량이 늘수록 비용도 비례해서 커진다. 반면 오픈소스 모델은 초기에 GPU 인프라를 갖추거나 클라우드 임대 비용이 든다. 대신 세팅만 끝내두면 사내 코드가 외부 서버로 안 나간다는 게 큰 장점이다. 금융권이나 보안 민감 업종에서 오픈소스 모델을 자체 서버에 올려 쓰는 사례가 늘어나는 것도 이 때문이다.

• 상용 에이전트형: 빠른 도입, 높은 완성도, 대신 사용량 기반 비용과 외부 서버 의존
• 오픈소스 모델: 초기 인프라 비용 발생, 대신 데이터 통제권과 커스터마이징 자유도 확보
• 하이브리드: 민감한 코드는 오픈소스 모델로, 반복 작업은 에이전트형 툴로 나눠 쓰는 방식도 늘어나는 추세

결국 뭘 골라야 하나

1인 개발자나 소규모 팀이면 굳이 인프라 구축할 필요 없다. 상용 에이전트형 툴로 시작하는 게 합리적이다. 반대로 사내 코드 유출이 민감한 조직이거나, 특정 도메인 — 경쟁 프로그래밍이든 특정 언어 특화든 — 에 맞춰 모델을 파인튜닝하고 싶다면 오픈소스 쪽이 장기적으로 남는 게 많다. 하나 더 기억해둘 점. 오픈소스 코딩 모델의 학습 데이터가 이미 인터넷상 검증 가능한 문제 풀에 근접했다는 연구진 언급, 그냥 지나칠 얘기가 아니다. 앞으로는 모델이 스스로 문제를 만들고 풀어보는 셀프플레이 방식 연구가 관건이 될 가능성이 크다. 지금 어떤 툴을 쓰든, 이 흐름이 도구 선택 기준 자체를 계속 바꿔놓을 걸로 보인다.

출처: VentureBeat AI