최신뉴스
넘버스
리뷰
How-To
오피니언
테크 라이브러리
컨퍼런스
최신뉴스
넘버스
리뷰
How-To
오피니언
테크 라이브러리
컨퍼런스
BrandZone
TOPIC
톱뉴스 | 많이 본 뉴스 | 토픽 브리핑
1/3
BrandZone
테크라이브러리
넘버스

국내 외장형 엔터프라이즈 스토리지 시스템 시장 향후 5년간 연평균 성장률

4.5
%
국내 외장형 엔터프라이즈 스토리지 시스템 시장 전망(2023-2027) 보고서
출처 : 한국IDC
날짜 : 2023년 05월 31일

“내년에 이직할 가능성이 있다”

52
%
2022 테크 정서 리포트 2022 Tech Sentiment Report
출처 : Dice
날짜 : 2022년 11월 15일

“실제 업무 현장에서 LLM을 쓴다”

30
%
대용량 언어 모델 이용 관련 의료 업계 정보·전산 담당자 설문조사
출처 : mcloudoc
날짜 : 2023년 05월 30일

"보안 문제로 애플리케이션 배포를 지연시키거나 속도를 늦춰야 했다"

67
%
2023 쿠버네티스 보안 현황 State of Kubernetes Security Report 2023
출처 : RedHat
날짜 : 2023년 05월 30일
AIㆍML | 미래기술   1일 전
"공유지의 비극은 어디서든 가능하다" 챗GPT와 LLM의 어두운 미래

기술 세계에서는 모두가 결국 기생 생물이다. 드루팔을 만든 드리스 보이타르트가 몇 년 전에 말했듯이 사람은 모두 만드는 사람(maker)보다는 취하는 사람(taker)에 가깝다. 보이타르트는 오픈소스 커뮤니티의 일반적인 관행을 두고 “취하는 사람은 자신이 이익을 취한 오픈소스 프로젝트에 유의미한 기여로 갚지 않고 의존하는 프로젝트에 해를 끼친다"라고 말했다. 가장 열정적인 오픈소스 기여자라 해도 기여하는 것보다 취하는 것이 더 많을 수밖에 없다.   기생적 경향은 다른 이의 콘텐츠에 의존하는 구글, 페이스북, 트위터에서도 드러났지만, 현재 생성형 AI에서 훨씬 더 선명하게 나타난다. 소스그래프(Sourcegraph) 개발자인 스티브 예게는 “LLM은 소셜, 모바일 또는 클라우드 이후의 가장 큰 변화일 뿐만 아니라, 월드 와이드 웹 이후의 가장 큰 변화”라고 주장했다. 그 말이 맞을 수도 있지만, 대규모 언어 모델(LLM)은 근본 속성이 기생적이다. 다른 사람의 코드 저장소(깃허브), 기술적 질문에 대한 답(스택 오버플로우), 문헌 등에서 정보를 긁어오는 방식에 의존하기 때문이다.   오픈소스에서 그랬듯 콘텐츠를 만들고 모아서 배급하는 쪽에서는 콘텐츠에 대한 LLM 접근을 차단하기 시작했다. 예를 들어 와이어드(Wired)의 보도에 따르면 사이트 트래픽 감소를 겪고 있는 스택 오버플로우는 레딧과 마찬가지로 LLM 제작자에게 LLM 학습에 스택 오버플로우 데이터를 사용하려면 정당하게 돈을 내라고 요구하고 있다. 오픈소스에서 벌어졌던 라이선스 전쟁, 그리고 뉴스 발행사가 구글과 페이스북을 막기 위해 구축했던 페이월을 연상시키는 과감한 조치다. 하지만 정말 효과가 있을까?   공유지의 비극 물론 기술 기생충의 역사는 오픈소스 이전까지 거슬러 올라가겠지만 필자가 경력을 시작한 오픈소스 초기부터 살펴보자. 다른 사람의 기여에 기대 수익을 얻으려는 회사는 리눅스 또는 마이SQL의 극초창기부터 있었다. 예를 들어 리눅스 분야의 경우 최근 록키 리눅스(Rocky Linux)와 알마 리눅스(Alma Linux)라는 두 회사가 레드햇 엔터프라이즈 리눅스(RHEL)와의 완전한 호환성을 약속하고 나섰는데 정작 둘은 레드햇의 성공에는 아무것도 기여하지 않는다. 이 두 RHEL 클론의 성공에 따르는 자연스러운 결과는 숙주가 사라지고 이어 클론 스스로도 사라지게 된다는 것이다. 그래서 리눅스 업계에서는 이들을 가리켜 오픈소스의 '막장'이라고 칭하기도 한다.   지나친 표현일 수도 있지만 요지는 잘 보여준다. 한때 AWS를 향했던 이른바 '노천 채굴' 같은 맥락의 비판이다. 이 비판의 영향으로 여러 클로즈드 소스 라이선스의 변경과 비즈니스 모델의 왜곡, 그리고 오픈소스 지속 가능성에 대한 끝이 없어 보이는 논쟁이 촉발됐다.   물론 오픈소스의 입지는 그 어느 때보다 견고하지만 개별 오픈소스 프로젝트의 상태는 제각각이다. 몇몇 프로젝트와 프로젝트 유지관리자는 커뮤니티 내에서 '테이커'를 관리하는 방법을 마련했지만 그렇지 않은 프로젝트도 있다. 어쨌든 추세적으로 오픈소스의 중요성과 힘은 계속해서 커지고 있다.   우물의 고갈 LLM으로 돌아와 보자. JP 모건 체이스 같은 대기업은 수십억 달러를 투자하고 데이터 과학자, 머신러닝 엔지니어 등을 1,000명 이상 고용해서 개인화와 분석 등에서 막대한 금전적 효과를 거두고 있다. 많은 기업이 챗GPT와 같은 서비스를 공개적으로 채택하기를 주저하고 있지만 현실은 그 기업에 속한 개발자는 이미 LLM을 사용해서 생산성을 높이고 있다는 것이다.   그 효과의 대가가 이제 명확하게 드러나기 시작했다. 역사적으로 생산성 개선의 원천 역할을 해온 스택 오버플로우 같은 기업이 감당해야 하는 대가다.   예를 들어 시밀러웹(Similarweb)에 따르면 스택 오버플로우 트래픽은 2022년 1월 이후 매월 평균 6% 감소해왔고 2023년 3월에는 무려 13.9% 떨어졌다. 이 감소의 원인이 전적으로 챗GPT와 기타 생성형 AI 기반 툴이라고 단정하기는 어렵지만 영향이 없다고도 못할 것이다.   피터 닉시는 인터내셔널.io의 창업자이자 스택 오버플로우의 상위 2% 사용자이다. 지금까지 170만 명 이상의 개발자가 닉시가 작성한 답변을 봤다. 이처럼 스택 오버플로우에서 유명한 닉시도 “스택 오버플로우에 다시 글을 쓸 일은 아마 없을 것”이라고 말했다. 이유가 무엇일까? 챗GPT와 같은 LLM으로 인해 스택 오버플로우의 지식 풀이 고갈될 위험에 처했기 때문이다. 닉시는 “함께 지식 풀을 만들기를 멈추고 그 대신 각자 기계에 바로 쏟아붓는다면 어떤 일이 일어날까?”라고 물었다. 닉시가 말한 “기계”는 챗GPT 같은 생성형 AI를 의미한다. 예를 들어 깃허브 저장소, 스택 오버플로우의 Q&A 등을 이용해 학습된 깃허브의 코파일럿 같은 AI 툴에게서 답을 얻는다면 편리할 것이다. 그러나 스택 오버플로우와 달리 AI와의 질답은 비공개로 이뤄지고 따라서 공공의 정보 저장소로 구축되지도 않는다. 닉시는 “GPT4는 2021년 이전에 스택 오버플로우에서 올라온 질문을 이용해 학습됐다. 과연 GPT6은 무엇을 이용해 학습될까?”라고 질문했다.   일방통행 정보 고속도로 이제 문제가 보이는가? 이것은 그동안 오픈소스 분야에서 벌어졌던 실랑이보다 훨씬 심각한 문제일 수 있다. 닉시는 “이 패턴이 다른 곳에도 복제되고, 인류를 향해 외적으로 확산되던 집단 지식의 방향이 바뀌어 기계의 내부를 지향하게 된다면 이전의 모든 의존과는 비교할 수 없는 방식으로 기계에 의존하게 될 것”이라고 말했다. 그냥 ‘문제’라고 한다면 온건한 표현이다. 닉시는 “빠르게 성장하는 코로나19 변종 같이 AI는 오로지 성장의 힘만으로 지배적인 지식 소스가 될 것이다. 스택 오버플로우를 예로 들면 한때 사람에게 속했던 지식 풀이 트랜스포머 내부에 사용되는 겨우 가중치 하나로 전락하게 되는 것”이라고 강조했다.   여기에는 AI로 끊임없이 밀려 들어오는 엄청난 양의 현금뿐만 아니라 그 외에도 많은 것이 작용한다. 챗GPT 등에 의해 생성되는 정보의 상대적 가치도 살펴봐야 한다. 예를 들어 스택 오버플로우는 2022년 12월부터 챗GPT가 제공한 정보를 기반으로 한 답을 금지했다. 텍스트가 너무 많고 정보의 품질은 떨어진다는 이유다. “챗GPT에서 올바른 답을 얻을 평균적인 비율이 너무 낮고, 챗GPT에 의해 생성된 답을 게시하는 것은 사이트, 그리고 질문을 통해 올바른 답을 찾는 사용자에게 상당히 해롭다.” 챗GPT 같은 부류는 올바른 정보를 생산하도록 설계되는 것이 아니라 단순히 데이터의 패턴에 부합하는 확률론적 정보를 생산하도록 설계된다. 오픈소스에 '막장 기업'이 만연하다고 치자. 그러나 양질의 학습 데이터가 꾸준히 공급되지 않는 LLM은 스스로를 쓰레기 정보로 채우게 되고 유용성은 더 떨어지게 된다.   LLM과 생성형 AI의 가능성을 폄하하는 것이 아니다. 과거 오픈소스, 뉴스 발행사의 사례와 마찬가지로 오픈AI를 비롯한 여러 기업에 집단적으로 생산된 정보를 활용할 수 있도록 도와준 점에 감사한 마음을 가지면서, 동시에 레딧(그 자체가 개인적인 기여의 집합체)처럼 기여자가 각자의 역할에 금전적 대가를 기대하는 것을 지지할 수도 있다. 오픈소스는 이미 라이선스 전쟁을 겪었다. 이제 생성형 AI의 세계에서도 그와 비슷하되 더 큰 파급력을 가진 일이 곧 일어날 것으로 보인다. editor@itworld.co.kr 

챗GPT와 대화하는 자바 앱 만들기
AMD 라데온 RX 7600 리뷰 | 오래 기다렸다, 저렴하고 합리적인 최신 GPU
아이패드용 파이널컷 프로, 로직 프로 리뷰 | ‘전문가 앱’과 ‘완벽한 맥 버전 이식’의 중간 어디쯤
“우주 정거장부터 최신 탱크까지”⋯‘50살’ 이더넷의 성장은 계속된다
글로벌 칼럼ㅣ대규모 언어 모델(LLM)은 ‘척척박사’가 아니다
Sponsored
데이터센터 성능을 재정의하는 게임 체인저 ‘4세대 인텔® 제온® 스케일러블 프로세서’
개발자   2023.05.22
“파이썬 생태계 숨은 보석” 최신 데이터 과학 툴 5가지

파이썬의 풍부한 데이터 과학 툴 생태계는 사용자에게 큰 매력이다. 반면 이처럼 광범위하고 깊은 툴 모음의 유일한 단점은 종종 좋은 툴을 모르고 지나칠 수 있다는 점이다. 여기서는 비교적 새롭거나 덜 알려진 최고의 파이썬 데이터 과학 프로젝트를 소개한다. 폴라스(Polars) 등 전보다 많은 관심을 끌고 있지만 가치에 비해 여전히 덜 알려진 툴도 있고, 커넥터엑스(ConnectorX)와 같이 숨은 보석도 있다.     커넥터엑스 대부분의 데이터는 어딘가의 데이터베이스에 위치하지만 계산은 일반적으로 데이터베이스 바깥에서 이뤄진다. 실제 작업을 위해 데이터를 데이터베이스 안팎으로 옮기는 과정에서 속도가 느려질 수 있다. 는 데이터베이스의 데이터를 파이썬의 많은 일반적인 데이터 랭글링 툴로 불러온다. 필요한 작업을 최소화해서 빠른 속도를 유지해준다.  다음에서 살펴볼 폴라스와 마찬가지로 커넥터엑스는 러스트 라이브러리를 사용한다. 덕분에 파티셔닝과 함께 병렬로 데이터 소스에서 로드하는 기능과 같은 최적화가 가능하다. 예를 들어 파티션 열을 지정해 포스트그레SQL의 데이터를 병렬로 로드할 수 있다.  포스트그레SQL 외에 마이SQL/마리아DB, SQL라이트(SQLite), 아마존 레드시프트, 마이크로소프트 SQL 서버, 애저 SQL 및 오라클에서 읽기도 지원한다. 결과를 판다스 또는 파이애로우 데이터프레임(PyArrow DataFrame)으로 전달하거나, 파이애로우를 거쳐 모딘(Modin), 다스크(Dask) 또는 폴라스로 전달할 수 있다.    덕DB 파이썬을 사용하는 데이터 과학자라면 파이썬과 함께 패키징되는 작지만 강력하고 빠른 관계형 데이터베이스인 SQL라이트를 주목해야 한다. 별도의 애플리케이션이 아닌 프로세스 내 라이브러리로 실행되므로 가볍고 응답성이 우수하다.  는 “OLAP용 SQL라이트를 만들면 어떨까?”라는 질문에 대한 답이라고 볼 수 있다. 다른 OLAP 데이터베이스 엔진과 마찬가지로 열 기반 데이터스토어를 사용하며 장기간 실행되는 분석 쿼리 워크로드에 최적화된다. 또한 예를 들어 ACID 트랜잭션과 같이 일반적인 데이터베이스에서 기대할 법한 모든 기능을 제공한다. 구성해야 하는 별도의 소프트웨어 모음이 없으므로 pip install 명령 하나로 파이썬 환경에서 실행할 수 있다.  덕DB는 CSV, JSON 또는 파케이(Parquet) 형식으로 데이터를 직접 수집할 수 있다. 그렇게 만들어진 데이터베이스는 연도, 월 같은 키를 기반으로 여러 물리적 파일로 파티션해서 효율성을 높일 수 있다. 쿼리는 여타 SQL 기반 관계형 데이터베이스와 똑같이 작동하지만 데이터의 랜덤 샘플을 취하거나 윈도우 함수를 구성하는 등 부가적인 기능도 내장했다. 덕DB의 작지만 유용한 확장 모음에는 전체 텍스트 검색, 엑셀 가져오기/내보내기, SQL라이트 및 포스트그레SQL 직접 연결, 파케이 파일 내보내기 등이 있고, 일반적인 여러 가지 지리공간 데이터 형식도 지원한다.    옵티머스 데이터프레임 중심 프로젝트에 사용하기 위해 데이터를 정제하고 준비하는 작업은 가장 기피하고 싶은 작업 중 하나일 것이다. 이때 는 데이터를 로드, 탐색, 정제하고 다양한 데이터 소스에 다시 쓰기 위한 올인원 툴셋이다. 옵티머스는 판다스, 다스크, CUDF(다스크+CUDF), 벡스(Vaex) 또는 스파크를 기반 데이터 엔진으로 사용할 수 있다. 애로우, 파케이, 엑셀, 일반적인 다양한 데이터 소스 또는 CSV나 JSON과 같은 플랫 파일 형식으로 데이터를 로드하고 다시 저장할 수 있다.  데이터 조작 API는 판다스와 유사하지만 .rows() 및 .cols() 접근자가 추가되므로 데이터프레임 정렬, 열 값에 따른 필터, 기준에 따른 데이터 변경 또는 일부 기준에 따라 연산 범위 좁히기와 같은 작업을 더 쉽게 할 수 있다. 또한 이메일 주소, URL과 같은 일반적인 데이터 유형을 처리하기 위한 처리기도 번들로 함께 제공한다. 옵티머스의 한 가지 문제는 아직 개발 단계임에도 마지막 공식 릴리스가 2020년이라는 점이다.   폴라스 대부분의 시간을 데이터프레임을 다루는 데 보내고 있고 판다스의 성능 제약에 진절머리가 난다면 를 사용해 보자. 파이썬용 데이터프레임 라이브러리인 폴라스는 판다스와 비슷한 편리한 구문을 제공한다. 판다스와 다른 점은 기본적으로 하드웨어를 최대한 활용하는 러스트로 작성된 라이브러리를 사용한다는 것이다. 병렬 처리나 SIMD와 같은 성능 향상 기능을 활용하기 위해 특별한 구문을 사용할 필요가 없다. 자동으로 된다. CSV 파일에서 읽기와 같은 간단한 작업도 더 빠르다.  폴라스는 즉시(eager) 및 지연(lazy) 실행 모드도 제공하므로 쿼리를 즉시 실행하거나 필요한 시점까지 지연시킬 수 있다. 쿼리를 증분 처리하기 위한 스트리밍 API도 제공하지만 아직 스트리밍을 사용할 수 없는 함수가 많다. 러스트 개발자라면 수 있다.    스네이크메이크 데이터 과학 워크플로우는 설정하기 어려운데, 일관적이고 예측 가능한 방식으로 설정하기는 더욱 어렵다. 는 이 문제를 해소하기 위해 개발됐다. 파이썬의 데이터 분석을 자동으로 설정해 다른 모든 사람도 나와 같은 결과를 얻도록 보장한다. 많은 기존 데이터 과학 프로젝트가 스네이크메이크에 의존한다. 데이터 과학 워크플로우에 움직이는 요소가 많을수록 스네이크메이크로 자동화해서 얻는 이익도 커진다.  스네이크메이크 워크플로우는 GNU 메이크(make) 워크플로우와 비슷하다. 규칙을 사용해서 만들 것을 정의해서 이를 통해 무엇을 받아들일지, 무엇을 내보낼지, 이를 달성하기 위해 어떤 명령을 실행할지를 정의한다. 워크플로우 규칙은 멀티스레딩이 가능하며(이점이 있다면), 구성 데이터는 JSON/YAML 파일에서 가져올 수 있다. 또한 워크플로우에 함수를 정의해 규칙에 사용되는 데이터를 변환하고 각 단계에서 수행된 작업을 로그에 쓸 수 있다.  스네이크메이크 작업은 이식이 가능하도록 만들어졌으므로 모든 쿠버네티스 관리 환경, 또는 구글 클라우드 라이프 사이언스(Google Cloud Life Sciences)나 AWS의 티바나(Tibanna)와 같은 특정 클라우드 환경에 배포가 가능하다. 워크플로우를 “동결”해서 정확히 정해진 패키지 집합만 사용할 수 있으며 성공적으로 실행된 워크플로우에 대해서는 자동으로 단위 테스트를 생성해서 함께 저장할 수 있다. 또한 장기 보관을 위해 워크플로우를 타볼(tarball)로 저장할 수 있다.  editor@itworld.co.kr

"쏟아부으면 다 AI옵스?" 네트워크 데이터와 AI 도구의 과제 5가지
에이수스 로그 앨리 리뷰 | 완벽한 휴대용 게이밍 경험, 형편없는 배터리 사용시간
“칩 회사가 이걸 만들었다고?” 인텔의 기묘한 실패작 12가지
“이중·삼중 갈취는 기본” 몸값을 받기 위해 새로운 전술 펼치는 해커들
“쿠버네티스에 핀옵스 더하기” 오픈코스트 활용한 비용 관리법
느려도 너무 느린 노트북, 포기하기 전에 시도해 볼 9가지 방법
글로벌 트렌드 | 네트워크   2023.05.10
화웨이 금지 조치 합류하는 독일…5G 둘러싼 지정학적 ‘관계 방정식’

최대한 많은 네트워크에서 중국제 장비를 배제하려는 미국의 계속되는 외교 노력이 결실을 보고 있는 듯하다. 독일이 다른 여러 유럽 국가의 뒤를 따라 화웨이 및 ZTE 5G 장비 사용을 금지하기로 했다.   중국 정부와 긴밀한 관계인 화웨이와 ZTE의 하드웨어가 국가 안보 위협을 가한다는 미국의 입장에 따라 스웨덴, 노르웨이, 영국은 이미 중국제 장비 금지 조치를 실시했다. 독일이 중국제 장비를 금지할 것이라는 소식은 3월 정부 소식통을 인용한 독일 신문 가 처음 전했다.    화웨이는 유럽에서 여전히 상당한 족적을 갖고 있다. 유럽정책분석센터(CEAP)의 온라인 학술지 밴드위스(Bandwidth)에 게재된 존 스트랜드의 분석에 따르면, 많은 국가가 여전히 5G 네트워크에 화웨이 장비를 가동 중이다. 그 비율은 100%(키프로스)부터 17%(프랑스)까지 다양하다. 프랑스 당국은 화웨이 장비 사용이 가능한 장소를 제한했다. 스트랜드의 분석에 따르면, 독일, 이탈리아, 아일랜드, 폴란드, 스페인, 포르투갈, 네덜란드, 스위스, 핀란드 등의 국가 역시 5G 네트워크 중 상당 부분을 화웨이 장비로 가동하고 있다.   화웨이 금지 조치에 대한 EU의 태도 변화 독일이 다음으로 중국제 장비 금지 조치를 실시할 수 있다는 소식은 화웨이가 유럽에서 차지하는 지위에 대한 일종의 전환점을 나타낸다. 유럽 일부 지역은 이 문제에 대한 미국의 압력에 저항해 왔지만, EU 자체는 독일과 같은 주요 회원국과 함께 방향을 바꾸고 있는 듯하다. 2019년 유럽위원회는 국가 행위자에 의한 5G 네트워크 내 간섭의 위험을 상세히 기술한 를 발표했다. 이는 중국 정부가 지원하는 공급업체들에 대한 경고로 널리 해석됐다. EU의 입장은 미국 지도부의 변화와 일부 관계가 있다. 북대서양조약기구(NATO)를 폄하하고 미국과 EU의 관계 냉각을 주도했던 미국 도널드 트럼프 대통령 행정부로부터 지시받기 꺼리는 국가들은 바이든 대통령 정부를 더 신뢰한다. IDC 선임 조사 책임자 렌 파딜라에 따르면, 이런 점이 정책을 직접적으로 바꾸지는 않겠지만 여전히 영향을 미칠 수 있다. 파딜라는 “대부분 EU 회원국 정부는 트럼프 행정부보다 바이든 행정부를 진지하게 받아들일 준비가 되어 있으며, 바이든 정부가 어떤 방향성을 취하면 그럴 만한 이유가 있다고 생각한다”라고 말했다. 네트워크에서 간섭이 일어날 가능성은 화웨이 장비를 여전히 사용 중인 국가들도 널리 인정하고 있다. 그러나 다른 문제로 인해 노골적인 금지를 결정하는 것은 까다로운 문제다. 하버드 대학교 교수이자 사이버보안 전문가 브루스 슈나이어에 따르면, 네트워크 운용업체들이 화웨이를 계속 사용하는 것은 순 비용 측면에서 매력적인 선택지이기 때문이다. 하지만 슈나이어는 “보안을 원한다면 비용이 든다. 피할 방법은 없다”라고 덧붙였다. 기술 공급망에 영향을 미치는 지정학 서방 국가는 이런 사실을 뒤늦게 자각했으나 배운 점은 있었다. 미국의 반도체 및 과학법(CHIPS and Science Act)과 같은 조치와 유럽에서 시행되는 비슷한 법률은 자국의 칩 제조 역량을 강화해 현재의 미·중 반도체 무역전쟁과 같은 지정학적 요인 등으로 인한 공급망 문제를 미리 예방하려는 노력의 일환이다. 그러나 슈나이어는 이런 노력만으로 문제를 빠르게 해결하기는 어렵다며, “현재와 같은 노동법에서는 비용이 더 드는 대안”이라고 지적했다. 슈나이어에 따르면, 중국 정부가 화웨이 장비를 이용해 국가 네트워크를 염탐할 가능성은 이미 서방 국가에서도 일상적으로 일어나는 일이므로 문제가 되지 않는다. 실제 문제는 무력 분쟁 발생 시 침해된 네트워킹 장비를 사용해 서구의 네트워크를 약화하는 것이다. 슈나이어는 “네트워크 약화로 모든 것의 가동이 중단될 수 있다는 점이 우려된다. 만일 중국이 대만을 침공한다면 대만의 네트워크를 약화할 수 있다. 그것이 실질적인 위험이며, 이는 감지되지 않는 방식으로 진행될 수 있다”라고 말했다. 화웨이 금지 조치, 철거·교체 비용으로 복잡해질 수 있어 새로운 네트워크와 기존 네트워크를 대상으로 한 잠재적인 화웨이 금지 조치에 대한 유럽의 셈법은 비용 문제 때문에 복잡하다. 파딜리아에 따르면, EU 국가에서 화웨이 장비가 널리 보급된 점을 고려하면 금지 조치로 인한 철거 후 교체 비용 때문에 금지 조치를 재고하게 될지 모른다. 파딜리아는 “철거 후 교체 자금이 얼마나 있을지 모르겠다. 각국의 경제 사정에 달려 있다. 예컨대 독일보다는 스페인의 운용업체가 더 많은 영향을 받게 된다”라고 언급했다. 미국이 주도하는 화웨이 장비 사용 금지 압력은 어찌 됐든 결실을 보고 있다. 폴리티코(Politico)에 따르면, 화웨이는 파이브 아이즈(Five Eyes) 국가(미국, 영국, 뉴질랜드, 캐나다, 호주)와 인도에서의 사업을 포기했고 유럽에서의 마케팅 및 로비 활동을 전체적으로 축소하고 통합했다. 최근에는 미국과 EU가 공동으로 말레이시아 정부에 곧 도입할 5G 네트워크에 했다. 익명을 요구한 한 소식통은 화웨이가 규제가 심한 무선통신 분야에서 기업 시장으로 전환 중인 것으로 보인다고 전했다. 계속되는 무역 전쟁에서 양쪽 진영이 제기한 보안 문제는 매우 현실적이다. 중국은 미국의 엔터프라이즈 클라우드 업체 시만텍(Symmantec)을 비슷한 이유로 금지했다. 하지만 슈나이어와 파딜라는 기술이 아니라 지정학이 문제의 핵심이라는 점에 의견을 같이했다. 파딜라는 “기술적인 측면보다 지정학적인 측면이 더 우려된다. 화웨이든 시스코든 네트워크 장비 업체라면 장비 내부에 잠재적으로 보안을 침해할 수 있는 것을 넣는 것이 가능하지만, 화웨이가 그렇게 하고 있음을 입증하는 정보는 전혀 들은 바 없다”며, “모두 외국인 혐오이며 매우 복잡한 문제의 일부에 불과하다”라고 지적했다. editor@itworld.co.kr

네트워크 벤더의 나쁜 상술에 휘둘리지 않는 방법 4가지
“어느 순간 느려졌다면…” 크롬의 성능을 높이는 9가지 설정
AI로 가는 여정을 떠나기 전에 생각해 볼 선결 과제 7가지
"PC BIOS, 웬만하면 손대지 마"…하지만 꼭 업데이트해야 한다면?
갤럭시북 3 프로 360 리뷰 | ‘의심할 여지 없이’ 역대 최고 투인원 노트북
디지털 트윈 개발에 착수하기 전 반드시 거쳐야 할 7단계
AIㆍML | 글로벌 트렌드 | 보안   2023.04.27
챗GPT는 시작에 불과... 수면 위로 드러나는 ‘AI 챗봇’의 안보 위협

챗GPT 그리고 AI 챗봇이 그 이점만큼이나 위험성을 내포하고 있다는 것이 속속 드러나고 있다. 전 세계는 AI 챗봇이 초래할 위험을 고려하는 동시에 앞으로 다가올 미래를 걱정하기 시작했다.  최근 영국 국가사이버보안센터(NCSC)는 AI가 국가 안보에 미치는 위협을 . 곧이어 미국 국가안보국(NSA)의 사이버보안 책임자 롭 조이스도 비슷한 경고를 했다. 여러 국가에서 AI가 야기할 난제와 위협을 심각하게 우려하고 있다. NCSC는 쿼리가 보관된다는 점에서, AI 챗봇과 상호작용한 내용이 챗GPT 같은 AI 챗봇의 기반이 되는 대규모언어모델(LLM)의 일부가 될 수 있다고 지적했다. 이런 쿼리는 사용자의 관심 분야는 물론이고, 더 나아가 해당 사용자가 속한 조직까지 드러낼 수 있다. 조이스는 챗GPT 같은 챗봇이 특히 피싱에서 사용되는 장황하고 어색한 문구를 더 진짜 같고 그럴듯하게 보이도록 개선할 수 있기 때문에 사이버 범죄자의 범죄 능력을 향상시킬 수 있다고 주장했다.     쿼리를 통한 기밀 유출 때마침 삼성전자 반도체 부문에서 챗GPT 사용이 허가된 지 불과 20일 만에 정보 유출 사고가 발생했고, 삼성은 챗GPT 사용으로 기밀 정보가 불특정 다수에게 노출될 수 있다며 주의를 당부했다. 엔지니어들이 ▲ 소스코드 오류 확인, ▲ 불량 설비 파악에 사용되는 코드 최적화, ▲ 녹취 전사본을 기반으로 한 회의록 작성을 위해 챗GPT를 사용했고, 이 과정에서 민감한 기업 정보가 사실상 제3자에게 넘겨져 회사의 통제를 벗어났다. 현재 삼성은 챗GPT 기밀 유출을 원천적으로 막기 위해 자체 AI 서비스 개발을 검토 중이다.  코드42(CODE42)의 CISO 자디 한슨은 이번 삼성 사건을 언급하면서, “유망한 기술이지만 챗GPT가 폭발적으로 사용되면서 잠재적인 위험에 관한 우려가 촉발됐다. 기업에서 직원들이 챗GPT에 데이터를 제공하면 이런 위험은 더욱 커진다”라고 말했다. 이어 “챗GPT와 AI 도구는 매우 강력하고 유용하지만, 직원들은 챗GPT에 입력하기 적절한 데이터와 부적절한 데이터를 알아야 하며, 보안팀은 기업이 챗GPT에 전송하는 데이터에 대해 적절한 가시성을 확보해야 한다. 새롭고 강력한 기술이 발전할 때마다 이에 수반되는 위험을 이해해야 기업을 보호할 수 있다”라고 덧붙였다.  한 마디로, 입력한 정보는 ‘엔터’ 키를 누르는 순간 사라지고, 더 이상 통제할 수 없다. 영업 비밀로 간주되는 정보를 전송했다면 더 이상 비밀이라고 할 수 없다. 삼성은 “전송된 데이터는 이제 오픈AI의 서버에 저장돼 있기 때문에 회수가 불가능하다. 경쟁이 치열한 반도체 업계에서는 어떤 종류의 데이터 유출도 재앙을 불러올 수 있다”라고 전했다.   그렇다면, 정부의 기밀 정보에 관한 쿼리가 국가 안보를 어떻게 위험에 빠뜨릴 수 있는지 추론하는 일은 그다지 어렵지 않을 것이다.    AI가 모든 것을 바꾼다 2023년 초 랜드 연구소(RAND Corporation)의 대표 겸 CEO 제이슨 마테니 박사는 국토안보 및 정부행정 위원회 증언에서 국가 안보 문제로 꼽은 4가지를 . 다음과 같다. • 기술이 국가 안보 체계 밖에 있는 상업적 주체에 의해 주도된다.  • 기술이 빠르게 발전하고 있으며, 정부 정책 및 조직 개혁 속도를 능가한다. • 기술을 평가하는 전문 인력이 민간 부문에 집중돼 있으며 국가 안보에 사용된 적이 거의 없다. • 이런 기술에는 선의적인 사용과 악의적인 사용, 의도적인 오용과 우발적인 오용을 구분하거나 확실한 귀책을 파악하는 기존의 인텔리전스 시그니처가 부족하다. AI가 모든 것을 바꿀 것이라는 말은 과장이 아니다.   커지는 ‘오토GPT(AutoGPT)’의 두려움 이스라엘 국방군 소속 8200부대 출신이자 현재는 센트라(Sentra)의 CTO를 맡고 있는 롭 라이터는 챗GPT를 능가하는 ‘오토GPT(AutoGPT)’ 또는 ‘에이전트GPT(AgentGPT)’의 출현이 가장 두렵다고 말했다. 공격 효율을 수천 배 높일 수 있어서다. 공격자가 오토GPT에 작업을 지시하면 오토GPT는 목표를 달성할 때까지 (‘백만돌이’처럼) 끊임없이 작업을 수행한다. 다시 말해, 맬웨어가 스스로 작동하는 것이다. 오토GPT를 사용하면 공격자는 지속성과 확장성을 모두 갖춘 도구를 갖게 되는 셈이다.  슬래쉬넥스트(SlashNext)의 CEO 패트릭 하르도 해커가 챗GPT를 사용해 표적화된 공격을 더 많이, 더 빠르게 하면서 침해 성공 가능성을 높이고 있다고 언급했다. “오늘날 챗봇이 성공적인 2가지 영역이 있다. 맬웨어와 비즈니스 이메일 침해(BEC)다. 사이버 공격은 기업 내 특정 대상에게 빠르고 빈번하게 전달될 때 가장 위험하다”라고 말했다.   무한한 코드 변형 하르는 “사이버 범죄자는 챗GPT로 코드를 무한하게 변형해 맬웨어 탐지 엔진을 능가할 수 있다. BEC 공격은 피해자가 금융 정보나 데이터를 자발적으로 제공하도록 사회 공학 기법을 시도하는 표적 공격이다. 이런 공격이 성공하려면 개인화된 메시지가 필요하다. 챗GPT는 그럴듯하게 개인화된 이메일을 대량으로 생성할 수 있고, 아울러 무한으로 변형할 수 있다. 이런 공격의 속도와 빈도가 증가해 데이터 유출이 성공할 확률도 높아질 전망이다. 이미 2023년 1분기 보고된 침해 건수부터 많이 증가했다”라고 말했다. 라이터는 인간을 모방하는 챗봇의 능력이 매우 현실적이라고 말했다. 특히 잘못된 정보와 허위 정보에 오랫동안 관여해 온 IRA(Internet Research Agency) 같은 기관이 특정 인물의 말투, 어조, 음색 등을 포착하는 기능을 발전시키기 위해 매진 중일 것이라고 예상했다. 이런 일이 가능하다는 것을 이미 알고 있더라도 막상 실제 인물과 모방된 인물을 마주했을 때 누구의 말을 믿게 될까? 하르는 이 문제를 완화하려면 머신러닝을 기반으로 한 보안이 필요하다고 강조하면서, “AI는 AI로 대항해야 한다”라고 조언했다.    AI 도구 개발을 중단해야 할까? 전 세계 보안기관의 경고는 AI 도구 개발 중단을 촉구하는 많은 사람이 서명한 공개서한의 내용과 일맥상통한다. 하지만 AI 도구 개발을 중단하기에는 너무 늦었다. 최근 미국 상원 군사 위원회가 국방부 작전 개선을 위해 , 미국이 AI 도구 개발을 중단할 경우 국가 안보에 해로울 것이라는 데 의견이 일치한 것에서도 알 수 있다.  청문회에서 증언한 랜드 연구소의 마테니, 팔란티어(Palantir)의 CTO 샴 산카, 쉬프트5(Shift5)의 공동 창립자 겸 CEO 조시 로스피노소는 현재 미국이 우위를 점하고 있는 AI 도구 개발을 중단하면 적대국에게 미국을 따라잡고, 미국이 방어하기 어려운 AI 모델을 만들 기회를 제공한다는 데 의견을 같이했다. 물론 AI 기술을 통제해야 한다는 초당적 합의와 요구도 있었다.  소위원회는 마테니, 샴 산카, 조시 로스피노소에게 국가 안보 보호의 맥락에서 정부가 AI 규제를 어떻게 검토해야 하는지 권고안을 30~60일 내에 제출하라고 요청했다. 지난 4월 19일 청문회에서 오간 논의 내용을 봤을 때, AI 기술은 이중용도(dual-use) 기술로 지정돼, 국가 간 협력이나 공유가 금지되진 않지만 정부가 발언권을 가져야 하는 국제무기거래규정(ITAR)의 적용을 받게 되리라 예상된다.  editor@itworld.co.kr  

2023년 국내 클라우드 컴퓨팅 현황과 전망 : Market Pulse
IT의 시각에서 바라본 직원 모니터링... 기술 전문가 반응은 ‘글쎄’
“인터넷 트래픽의 90% 이상” M2M 상호작용 관리 설계 5계명
“아는 만큼 예뻐진다” 최신 CSS 기능 10가지
“직원 유지율 90%” 기업이 전하는 ‘하이브리드 근무’ 운영팁 7
바꿔야 할까? 모니터 교체가 필요하다는 5가지 신호
개발자   2023.04.18
“브라우저에서 자바 빠르게 실행하기” 예제로 배우는 실전 자바-와즘 변환

웹어셈블리(WebAssembly) 또는 줄여서 와즘(Wasm)은 웹어셈블리로 컴파일이 가능한 모든 언어에 대한 일반화된 가벼운 네이티브 바이너리 형식을 제공한다. 소스 언어가 웹어셈블리로 변환되면 클라우드 가상머신부터 데스크톱, IoT와 모바일 기기에 이르기까지 다양한 컨텍스트에서 이 컴팩트한 바이너리를 실행할 수 있다. 와즘이 지원하는 가장 흥미로운 환경 중 하나는 웹 브라우저다. 여기서는 자바 코드를 웹어셈블리로 컴파일하는 방법을 알아본 다음 웹 서버에서 데모 애플리케이션을 실행하면서 실제로 작동하는 모습을 살펴본다.    자바에 웹어셈블리를 사용하는 이유  와즘은 자바스크립트에서 자바 API를 호출할 수 있는 웹 브라우저의 프론트 엔드에서 자바를 실행하는 방법을 제공한다. 웹어셈블리 컴파일러는 자바 소스(또는 바이트코드)에서 바이너리를 생성하고, 브라우저는 호스트 운영체제 기능을 사용해서 이 바이너리를 실행하므로 OS 수준의 성능을 얻게 된다. 자바 코드는 와즘 바이너리로 변환되고 이 바이너리는 자바스크립트에서 호출할 수 있는 훅을 노출한다.  와즘은 오늘날 주요 브라우저에서 바로 사용할 수 있다. 사용자가 원하는 언어로 무거운 작업을 수행할 수 있도록 뛰어난 성능을 제공한다. 비디오 인코딩, 그래픽 및 기타 고강도 데이터 처리 등에 사용하면 큰 효과를 얻을 수 있다. 심지어 하기도 한다.  자바를 사용한 기간이 어느정도 되면 브라우저의 자바에 대한 이야기를 들을 때 자바 애플릿을 떠올리겠지만, 와즘은 그것과는 전혀 다르다. 와즘은 처음부터 안전한 샌드박스 런타임으로 설계된 현대적 고성능 기술이다. 이식성, 성능, 보안, 다국어 지원을 갖춘 와즘은 현재 기술 환경의 핵심 요소다.    자바에서 와즘으로 : 변환 방식  자바 프로그램을 웹어셈블리로 변환하는 작업은 약간 까다롭다. 추천할 수 있는 완벽한 기준이 될 만한 방법은 없다. 여러 프로젝트가 있지만 성숙하거나 잘 문서화된 것을 찾기가 쉽지 않다. 자바 언어에는 가비지 수집, 리플렉션과 같이 웹어셈블리 트랜스파일러가 해결하기 어려운 몇 가지 문제가 있다. 최상급 자바 와즘 솔루션에 도달하기 위해서는 먼저 이와 같은 부분을 해결해야 할 것으로 보인다.  그랄VM(GraalVM)은 현재 네이티브 이미지 툴을 사용한 와즘 출력을 위한 하고 전반적으로 꽤 좋은 프로젝트다. 그랄VM이 와즘 바이너리를 생성할 수 있게 되면 살펴볼 가치가 있을 것이다. 그 사이 자바에서 와즘으로의 컴파일을 처리하는 데 사용할 수 있는 라이브러리는 다음과 같다.    여기서는 자바 와즘 컴파일에 티VM을 사용한다. 티VM을 만든 참조).   티VM을 사용해 자바를 와즘으로 컴파일하기  티VM은 자바를 재료로 와즘을 만들기 위한 가벼운 라이브러리를 지향한다. 구글 웹 툴킷에서 영감을 받았지만 소스가 아닌 바이트코드를 기반으로 한다. 덕분에 스칼라와 같은 다른 JVM 언어도 처리할 수 있다. 티VM이 제공하는 샘플 프로젝트를 통해 자바 와즘 프로젝트를 간편히 살펴볼 수 있는데 여기서도 이 샘플을 사용한다. 티VM과 샘플 프로젝트 설정  티VM을 사용하려면 자바 8 이상의 JDK가 설치되어 있어야 한다. 여기서는 최신 티VM 버전을 빌드해서 로컬 저장소에 설치한 다음, 와즘을 사용하는 샘플 프로젝트 중 하나를 빌드해서 자바-와즘 컴파일이 어떻게 수행하는지를 살펴본다. T이다.  프로젝트가 체크아웃되면 티VM 라이브러리 자체를 빌드해서 로컬 저장소에 설치해야 한다. 루트 디렉터리로 이동해서 /teavm/gradlew를 입력한다. 이 명령은 독립형 그래들(Gradle) 래퍼 실행 파일을 사용해 티VM을 빌드하고 로컬로 설치한다. 여기까지 완료하면 /teavm/samples/pi 디렉터리로 이동해서 ../../gradlew war를 입력한다. 그러면 그래들은 Pi 샘플 프로젝트를 WAR 파일로 빌드한다. 이 단계가 완료되면 서블릿 컨테이너에 배포할 수 있는 /teavm/samples/pi/build/libs/pi.war 파일이 생성된다.  필자는 이 데모에 우분투를 실행 중이므로 Tomcat을 서비스로 설치한 다음(sudo apt-get install tomcat9) pi.war 파일을 /webapps 디렉터리로 복사했다(sudo cp /teavm-wasm/target/pi.war /var/lib/tomcat9/webapps/). 그 다음 sudo systemctl start tomcat9를 사용해서 톰캣을 시작했다. 다른 방법은 /bin 디렉터리의 start.sh/.bat 스크립트를 사용하는 것이다. 이는 톰캣의 독립형 버전을 다운로드한 경우 가능한 방법이다. 참고로 Pi 샘플은 티VM의 자바스크립트와 와즘 출력 기능을 모두 지원하지만, 여기서는 와즘 부분만 살펴본다.  와즘을 위한 Pi 데모  이제 localhost:8080/pi에서 애플리케이션이 실행 중일 것이다. 브라우저에서 이 URL을 방문하면 간단한 사용자 인터페이스가 표시된다. 인터페이스에는 자바스크립트와 웹어셈블리용으로 하나씩 두 개의 링크가 포함돼 있다. 웹어셈블리를 클릭하면 이 표시된다.   이 인터페이스에서 파이를 계산할 자릿수를 지정할 수 있다. 인터페이스는 계산을 위해 와즘으로 컴파일된 자바를 사용하며, 자바스크립트에서 코드를 호출한다. 이 계산이 어떻게 수행되는지 살펴보자.  /teavm/samples/pi 프로젝트를 보면, 자바와 웹 애플리케이션 소스가 모두 포함된 표준 메이븐/그래들 레이아웃이며 각각 src/main/java와 src/main/webapp에 저장돼 있다. src/main/java/org/teavm/samples/pi/PiCalculator.java의 자바 클래스를 보면 PiCalculator라는 일반적인 자바 클래스임을 볼 수 있다. 이 클래스는 주 메서드를 정의한다. 주 메서드는 args[]에서 하나의 인수를 계산할 자릿수로 취하며 실제 파이 계산을 수행하기 위해 PiDigitSpigot이라는 내부 클래스를 사용하고 java.math.BigInteger라는 단일 자바 라이브러리에 의존한다. 전형적인 자바 프로그램이다. /teavm/samples/pi/build/libs/classes/main으로 이동해서 java org/teavm/samples/pi/PiCalculator 50이라고 입력하면 명령줄에서 파이를 50자리까지 계산해준다  이제 teavm/samples/pi/src/main/webapp의 웹 애플리케이션 부분을 보자. 우리의 관심사는 wasm.html이다. 파일의 대부분은 기본 HTML이지만 예시 1과 같이 살펴볼 만한 흥미로운 자바스크립트가 있다.  리스트 1. 파이 계산을 위한 웹 애플리케이션   let runner = null;   function init() {     TeaVM.wasm.load("wasm/pi.wasm", {       installImports(o, controller) {         function putwchars(address, count) {           let instance = controller.instance;           let memory = new Int8Array(instance.exports.memory.buffer);           let string = "";             for (let i = 0; i < count; ++i) {               string += $rt_putStdoutCustom(memory[address++]);             }           }           o.teavm.putwcharsOut = putwchars;           o.teavm.putwcharsErr = putwchars;         },       }).then(teavm => {         this.instance = teavm.instance;         runner = n => teavm.main([n.toString()]);         document.getElementById("run").disabled = false;       })   }   function calculate() {     var count = parseInt(document.getElementById("digit-count").value);     runner(count);   }   init();   Digit count:     Run 우선 TeaVM.wasm.load("wasm/pi.wasm", { ...라인은 서버에서 pi.wasm  파일을 가져오는 작업을 시작한다. 이 파일은 브라우저에 와즘 파일을 로드하도록 지시하는 내장된 .  가장 흥미로운 부분은 runner = n => teavm.main([n.toString()]); 라인이 있는 콜백 함수다. 여기서 자바스크립트로 자바 main() 함수를 호출하고 계산할 자릿수를 인수로 전달한다. 이제 PiCalculator.java 파일이 어떻게 pi.wasm으로 변환되었는지 살펴보자. 처럼 /pi/build.gradle.kts 파일에서 티VM 플러그인이 자바 파일을 가리키도록 구성됐다. 리스트 2. 자바-와즘 변환 teavm {     js {         addedToWebApp.set(true)     }     wasm {         addedToWebApp.set(true)     }     wasi {         outputDir.set(File(buildDir, "libs/wasi"))         relativePathInOutputDir.set("")     }     all {         mainClass.set("org.teavm.samples.pi.PiCalculator")     } } all 필드에서 mainClass.set("org.teavm.samples.pi.PiCalculator")로 티VM 플러그인이 구성된 것을 볼 수 있다. 자바스크립트와 와즘에 모두 적용되기 때문이다(즉, 프로젝트가 자바스크립트와 와즘 버전을 모두 출력함). build/generated/teavm/wasm/을 보면 티VM이 와즘 파일을 어디에 출력했는지 확인할 수 있다.    결론  와즘은 웹 브라우저에서 우수한 성능으로 자바를 실행할 수 있게 해주는 유망한 기술이다. 아직 미완성이지만 티VM과 같은 라이브러리는 자바와 웹어셈블리를 다루는 간편한 수단을 제공한다. 티VM을 사용하면 자바 코드를 호스트 운영체제 기능을 사용해 브라우저에서 실행되는 컴팩트한 바이너리로 컴파일할 수 있다. 와즘은 자바 기술 환경의 중요한 요소이며 여전히 개발 초기 단계에 있다. 가비지 수집 통합은 여러 주요 영역에서 와즘의 잠재력을 확대할 수 있다. 확실히 주목해야 할 기술이다.  editor@itworld.co.kr

웹 흔적을 모아 사용자 특정하는 '디지털 지문' 이해하기
구글 데이터플렉스 리뷰 | ‘프리뷰 단계인데도’ 데이터 사일로의 완전한 대안
PCIe 5.0 SSD로 업그레이드할 이유 5가지, 그럴 필요 없는 이유 5가지
로우코드·노코드로 빠르게 AI 앱 구축하기··· 4가지 접근법
글로벌 칼럼ㅣAI 챗봇, 검색엔진 아닌 헛소리 생성기다
‘노트북·스마트폰·태블릿’ 하나로... 갤럭시 생태계 활용법
1/2
AIㆍML Matt Asay
글로벌 칼럼ㅣ대규모 언어 모델(LLM)은 ‘척척박사’가 아니다

매우 유창하고 자신감 있게 텍스트를 생성하는 GPT-4 같은 ‘대규모 언어 모델(LLM)’의 부상은 분명 놀라운 일이다. 하지만 과대포장 역시 못지않게 놀라운 수준이다. 마이크로소프트 연구진은 오픈AI의 GPT-4 모델이 을 보여준다고 주장한다. 마이크로소프트에는 유감이지만, 그렇진 않다. 마이크로소프트의 주장이 잘못된 텍스트를 거침없이 내놓는 이른바 ‘환각 현상’을 두고 하는 말은 아닐 것이다. 게다가 GPT는 체스나 바둑 같은 게임에 서툴고, 수학도 잘 못하며, 아마 오류와 버그가 뒤범벅된 코드를 내놓을 수 있다. 그렇다고 LLM/GPT가 모두 과대포장이라는 뜻은 아니다. 전혀 그렇지 않다. 다만 생성형 AI를 둘러싼 논의에서 어느 정도 균형감을 갖고 과대포장을 대폭 걷어내자는 말이다.   오픈AI의 공동 설립자 겸 수석 과학자 일리야 서츠케버를 포함한 몇몇 전문가는 인간의 피드백이 포함된 강화 학습을 추가하면 LLM 환각을 없앨 수 있다고 믿는다. 하지만 메타의 AI 연구소 수석 과학자 얀 르쿤, 최근 구글에서 퇴사한 딥러닝의 아버지 제프리 힌튼 등 다른 전문가는 현재 대규모 언어 모델에 근본적인 결함이 있다고 주장한다. 이 두 사람은 대규모 언어 모델에 언어가 설명하는 현실을 이해하는 데 필수적인 비언어적 지식이 부족하다고 본다. 디프블루(Diffblue) CEO 매튜 롯지는 인포월드와의 인터뷰에서 “게임부터 코드 작성까지 모든 작업에서 작고, 빠르며, 실행 비용이 저렴한 강화 학습 모델이 수천억 개의 매개변수를 가진 LLM을 가볍게 앞선다”라고 밝혔다.  그렇다면 엉뚱한 곳에서 황금을 찾고 있는 건 아닐까?   게임 한판? 롯지의 말처럼 강화 학습이 훨씬 더 잘할 수 있는 영역에 생성형 AI를 우격다짐으로 밀어 넣는 중일 수 있다. 게임이 대표적인 예다. 체스 인터내셔널 마스터인 레비 로즈만이 올린 을 보면, 챗GPT는 자기 말을 잡는 등 터무니없는 수를 두는가 하면, 반칙까지 저지른다. 또한 오픈소스 체스 소프트웨어 스톡피시(Stockfish)는 신경망을 전혀 사용하지 않는데, 10수 만에 챗GPT의 항복을 받아냈다. LLM이 과대포장에 비해 훨씬 못 미친다는 것을 보여주는 좋은 사례다.  구글 알파고는 강화 학습을 기반으로 한다. 강화 학습은 하나의 문제에 다양한 해결책을 생성 및 시도하고, 그 결과를 사용해 다음 제안을 개선한다. 그리고 이 과정을 수천 번 반복해 최상의 결과를 찾는다. 알파고에서 AI는 다양한 수를 시도하면서 해당 수가 좋은 수인지, 해당 위치에서 승리할 가능성이 높은지 등을 예측한다. 이 피드백을 사용해 승리할 수 있는 수순을 따르고, 다른 가능한 수를 생성한다. 이 과정을 확률적 탐색(probabilistic search)이라고 한다. 이 방식은 게임 플레이에 매우 효과적이다. 알파고는 과거에 여러 바둑 고수를 격파했다. 알파고도 완벽한 것은 아니지만, 현재 최고의 LLM보다 성능이 뛰어나다.   확률 대 정확성 LLM이 다른 유형의 AI에 비해 상당히 뒤떨어진다는 증거를 제시하면, 지지자들은 LLM이 “앞으로 더 나아질 것”이라고 이야기한다. 하지만 롯지는 “이 주장이 맞으려면 LLM이 이런 종류의 작업을 더 잘할 수 있는 이유를 이해해야 하지만, 그게 어렵다”라고 언급했다. GPT-4가 특정 프롬프트에 대해 어떤 결과를 내놓을지 아무도 예측할 수 없어서다. 이 모델은 인간이 설명할 수 없다. 그렇기 때문에 프롬프트 엔지니어링은 무의미하다고 롯지는 말했다. 아울러 AI 연구진이 LLM의 새로운 속성(emergent properties)이 존재한다는 것을 증명하기도 어려운 일이며, 예측하기는 훨씬 더 어렵다고 지적했다.  아마도 최선의 반론은 귀납법일 것이다. GPT-4는 GPT-3에 비해 더 크기 때문에 일부 언어 작업에서 더 뛰어나다. 따라서 그보다 더 큰 모델은 더욱 뛰어나지 않을까? 과연 그럴까? 롯지에 따르면 “문제는 GPT-3가 어려움을 겪은 작업에서 GPT-4도 고전하고 있다는 점이다.” 그중 하나가 수학이다. GPT-4는 GPT-3보다 그나마 덧셈은 잘하지만, 곱셈을 비롯한 다른 수학 연산에는 여전히 서툴다. 언어 모델을 더 크게 만든다고 해서 이런 고질적인 문제가 마법처럼 해결되진 않는다. 또 오픈AI조차도 더 큰 모델이 답은 아니라고 밝혔다. 이유는 에서 언급된 적 있는 LLM의 근본적인 특성에 있다. “대규모 언어 모델은 본질적으로 확률적이며, 학습 데이터에서 관찰한 패턴에 따라 가능성 높은 출력을 생성하는 방식으로 동작한다. 수학 및 물리 문제는 대체로 정답이 하나만 존재하는데 이 하나의 답을 생성할 확률은 매우 낮을 수 있다.” 반면 강화 학습 기반의 AI는 목표를 추구하는 AI 프로세스이기 때문에 정확한 결과를 도출하는 데 훨씬 더 뛰어나다. 강화 학습은 원하는 목표를 향해 반복 동작하며, 목표에 가장 근접한 최상의 답을 생산한다. 롯지는 “반면에 LLM은 반복하거나 목표를 추구하도록 설계되지 않았다. ‘적당히 좋은’ 원샷(one-shot) 또는 퓨샷(few-shot) 답변을 제공하도록 설계됐다”라고 강조했다. ‘원샷’ 답변은 모델이 생성하는 첫 번째 답으로, 프롬프트에서 일련의 단어를 예측하는 방식으로 얻는다. ‘퓨샷’ 접근 방식에서는 모델이 더 나은 예측을 할 수 있도록 추가 샘플이나 힌트를 제공한다. 또 LLM은 더 나은 응답의 가능성을 높이기 위해 어느 정도의 무작위성을 수용하기 때문에 동일한 질문에 서로 다른 답을 내놓을 수 있다.  LLM 진영이 강화 학습을 무시하는 것은 아니다. GPT-4는 “인간의 피드백을 통한 강화 학습(RLHF)”을 수용한다. 즉, 코어 모델은 인간 운영자에 의해 일부 답변을 다른 답변보다 선호하도록 훈련되지만, 근본적으로 모델이 생성하는 답을 처음부터 변경하진 않는다. 롯지는 예를 들어 LLM이 “웨인 그레츠키는 아이스 (OO)을/를 좋아한다”라는 문장을 완성하기 위해 다음과 같은 답을 생성할 수 있다고 말했다. 1. 웨인 그레츠키는 아이스크림을 좋아한다. 2. 웨인 그레츠키는 아이스하키를 좋아한다. 3. 웨인 그레츠키는 얼음낚시를 좋아한다. 4. 웨인 그레츠키는 아이스 스케이팅을 좋아한다.  5. 웨인 그레츠키는 아이스 와인을 좋아한다. 여기서 인간 운영자는 웨인 그레츠키가 캐나다의 전설적인 아이스하키 선수이기 때문에 아이스하키(또는 아이스 스케이팅)를 좋아할 가능성이 높다고 생각해 답변의 순위를 매길 수 있다. 이 모델을 학습시키는 데는 인간 운영자의 순위와 더 많은 사람이 작성한 응답이 사용된다. 주목할 부분은 GPT-4가 웨인 그레츠키의 선호도를 정확하게 알고 있는 척하지 않으며, 단지 주어진 프롬프트를 완성하기 위한 가장 가능성 높은 답을 제공한다는 점이다. 결국 LLM은 정확성이나 일관성이 높도록 설계되지 않았다. 롯지는 이 모든 것은 AI를 대규모로 적용하는 데 있어 강화 학습이 생성형 AI를 능가한다는 의미라고 언급했다.   소프트웨어에 강화 학습 적용하기 소프트웨어 개발은 어떨까? 많은 개발자가 깃허브 코파일럿(Copilot), 아마존 코드위스퍼러(CodeWhisperer) 같은 생성형 AI 기반 도구를 사용하면서 생산성 향상을 경험하고 있다. 이런 도구는 통합 개발 환경에서 코드 삽입 지점 전후의 코드를 기반으로 다음에 올 가능성이 높은 코드를 예측한다. 실제로 코파일럿의 최신 버전이 이미 자바 코드의 61%를 생성한다고 말했다. 이러다가 소프트웨어 개발자라는 직업이 사라지지 않을까 걱정하는 사람을 위해 말해두자면, 이런 도구에는 완성된 코드를 확인하고, 제대로 컴파일 및 실행되도록 편집하기 위한 ‘사람의 관리 감독’이 필요하다. 사실상 자동 완성은 IDE의 초창기부터 IDE의 대표적인 기능이었으며, 코파일럿을 비롯한 코드 생성기는 그 기능의 유용성을 대폭 높여줬다. 하지만 자바 코드의 61%를 작성하는 데 필요한 대규모 자율 코딩은 그렇지 않다. 롯지는 강화 학습이 대규모 자율 코딩을 정확하게 수행할 수 있다고 말했다. 물론 롯지가 이렇게 이야기한 데는 다 이유가 있다. 디프블루는 2019년 상용 강화 학습 기반 단위 테스트 작성 도구 ‘커버(Cover)’를 출시했다. 커버는 인간의 개입 없이 전체 단위 테스트를 작성해 복잡하고 오류가 발생하기 쉬운 작업을 대규모로 자동화할 수 있게 해준다. 이런 사실을 고려하면 롯지의 주장이 편향적이라고 할 수 있지 않을까? 당연히 그렇다. 하지만 롯지는 소프트웨어 개발에서 강화 학습이 생성형 AI를 능가할 수 있다는 주장을 뒷받침할 풍부한 경험도 갖고 있다. 현재 디프블루는 강화 학습을 사용해 가능한 모든 테스트 방법을 탐색하고, 각 방법에 자동으로 테스트 코드를 작성하며, 이렇게 작성된 테스트 중 가장 적합한 테스트를 선택한다. 이 도구가 각 방법의 테스트를 생성하는 데 소요되는 시간은 평균 1초다. 롯지는 아무도 이해하지 못하는 프로그램에 대해 1만 개의 단위 테스트 작성을 자동화하는 것이 목표라면 강화 학습이 유일한 현실적 해결책이라면서, “LLM은 경쟁 상대가 되지 않는다. 이 정도 규모에서 사람이 효과적으로 감독하고 코드를 수정할 방법이 없으며, 모델을 더 크고 복잡하게 만든다고 해결되지 않는다”라고 설명했다. 결론은 이렇다. LLM의 가장 강력한 장점은 일반 언어를 처리한다는 것이다. 명시적으로 학습하지 않은 언어 작업도 수행할 수 있다. 즉, 콘텐츠 생성(카피라이팅)을 비롯한 많은 작업에 유용하다. 롯지는 “하지만 그렇다고 해서 LLM이 강화 학습 기반의 AI 모델을 대체할 수 있는 것은 아니다. 강화 학습이 더 정확하고, 더 일관적이며, 대규모로 작동한다”라고 전했다. editor@itworld.co.kr  

AIㆍML   2023.05.24
글로벌 칼럼ㅣ대규모 언어 모델(LLM)은 ‘척척박사’가 아니다
대규모 언어 모델