LLM을 이용한 웹브라우징 자동화하는 솔루션

AI|2024. 2. 11. 05:55

LLM의 가장 큰 단점이 모델을 만들어진 이후 새로운 지식이나 뉴스에 대한 정보는 모르는 부분입니다. 그래서 최근 정보를 LlaMa2에 물어보면 다음과 같이 대답을 합니다.

> 2024년 1월에 일어나 주요 뉴스를 알려주세요
2024년 1월에 발생한 주요 뉴스는 아직 알려지지 않았습니다. 저는 인공지능 모델이며, 현재 시점에서 미래의 사건을 예측할 수 없습니다. 뉴스는 실제 사건이 발생한 후에 보도되므로, 2024년 1월에 발생한 주요 뉴스는 해당 시기에 가까워질 때까지 알 수 없습니다.

ChatGPT는 실시간 웹브라우징 기능을 지원하는데, 아직 제약적입니다. 우선  Bing으로 검색을 통해 인터넷을 검색하여 최신 정보를 통해 질문에 대한 답변을 제공하는 기능하지만, 유료 사용자만 사용 가능입니다. 브라우징은 하나의 통합된 모델로 통합되어 있으며, 모델 선택기에서 GPT-4를 선택하면 액세스할 수 있습니다

하지만, LLM으로 웹브라우징을 자동화하려는 회사가 있습니다. 바로 Adept AI입니다. 브라우저 뿐만 아니라 모든 응용 앱도 가능하게 하려고 하는 것이 이 회사의 목적인 것 같습니다.

https://www.adept.ai/

 

Adept: Useful General Intelligence

Adept is an ML research and product lab building general intelligence by enabling humans and computers to work together creatively.

www.adept.ai

우리가 일상적으로 사용하는 앱을 자동화해준다면 물건을 사거나 주문을 할 때 매우 편리할 것 같은데, 얼마나 잘 될지는 두고 봐야겠네요.

댓글()

웹브라우저 성능 측정하는 사이트

WebKit|2019. 8. 19. 16:10

웹브라우저에서 GPU가속 성능 측정할 때, 자주 사용하던 웹사이트들이다. 웹브라우저를 임베디드 기기에 포팅한 후, 그래픽 성능을 측정할 때 사용할 수 있다.

Web Benchmark

WebGL Test

Canvas Test

zero-copy textur upload

4K video

댓글()

소프트웨어 개발 환경의 변화와 향후 전망

Software|2007. 4. 15. 22:46
SW 개발자의 큰 걱정 중 하나는 계속 공부를 해야 한다는 것입니다. SW분야 만큼 기술의 변화, 발전 속도가 빠른 분야도 없을 것입니다. 저 개인적으로는 이런 변화를 즐긴다고 자부해왔지만, 가끔은 애써 나하고는 무관하다라고 외면하는 경우도 있습니다. 물론, 변하지 않는 핵심을 잘 이해하고 있으면 새로운 기술에 대한 적응은 쉽습니다. 하지만 관심마저 저버린다면 누구와 대화라도 나누기가 힘들어집니다.

90년대 부터 제가 경험한 SW 개발환경의 변화와 향후 발전 방향에 대해 간략하게 알아보도록 하겠습니다. 이런 글을 쓰게 된 이유는 앞으로의 일어날 변화가 지금까지 경험한 변화 가운데 가장 크다고 생각하고 있고 저 자신도 이러한 변화에 발맞추어 나가려고 하기 때문입니다.

객체지향 프로그래밍(OOP)와 GUI 프로그래밍
90 년대 초반, 이 때는 대부분의 SW 개발자가 도스에서 C 프로그래밍을 하던 시절이였습니다. 이 때 두가지 변화의 물결이 다가왔는데, 바로 OOP와 윈도 프로그래밍이였습니다. 볼랜드의 OWL(Object Windows Library)과 비주얼 C++의 MFC(Microsoft Foundation Class Library)와의 전쟁에서 비주얼C++가 승리하면서 마이크로소프트는 개발툴에서도 독점을 이어나갔습니다. 하지만 진짜 비주얼 개발툴은 바로 비주얼 베이직이였습니다. 수 많은 초보 개발자를 윈도 개발자로 다시 태어나게한 일등 공신이라고 생각합니다.

기상기계(Virtual Machine)기반의 자바 언어 등장
97년이였던 것 같습니다. 자바(Java)의 등장은 많은 개발자에게 신선한 충격으로 다가왔습니다. 크로스 플랫폼을 지원하며 개발툴도 무료로 제공되었고 네트워크 어플리케이션 부터 GUI 프로그램까지 쉽게 개발할 수 있었습니다. 지금까지 개발된 어떤 언어보다 명시적이고 풍부한 기능을 제공하였고 쉽게 배울 수 있었습니다. 한 때, 웹 브라우저에서 동작하는 유일한 어플리케이션 실행 환경으로 각광을 받았지만, 플래시(Flash)에 밀렸고 현재는 모바일이니 서버쪽에서 많이 쓰이고 있습니다. 하지만 이클립스(Eclipse)와 같은 네이티브(native) UI기반의 SW 프레임웍(framework)이 등장하면서 현재는 데스크탑 환경에서 풍부한 UI를 제공하고 있습니다.
자바는 현재도 JSR(Java Sepcification Request)을 통해 새로운 기술과 기능에 대한 자바 API 규약이 나오고 있으며 계속 진화, 발전하고 있습니다.

웹과 스크립트 언어
많 은 소프트웨어가 웹을 기반으로 개발되면서 스크립트 기반의 개발환경 또는 언어가 대중화되기 시작합니다. 서버측면에서는 ASP, JSP, PHP가 대중화되었고 웹브라우저에서는 자바스크립트(JavaScript)가 사용되었습니다. 자바스크립트는 자바 보다는 오히려 C언어와 유사한 부분이 많죠. 물론 이전부터 파이썬(python), 펄(perl)도 CGI 개발에 사용되고 있었죠. 하여간 스크립트 언어 하면 웹을 연상할 만큼 웹 어플리케이션 개발에 많이 사용되고 있습니다. 하지만 스크립트 언어는 유닉스의 역사와 함께할 만큼 오랜 세월 동안 사용되어 왔습니다. 근래들어 루비가 많은 관심을 끌고 있더군요. 이러한 사실은 몇 년전 부터 시작된 대안언어축제라는 행사를 통해 알게되었습니다.

Win32API와 MFC의 종말(?)


얼마 전 뉴욕타임즈 리더라 는 프로그램을 다운로드 받았는데, UI가 좀 색다르게 구성되었고 글꼴 출력이 무척 미려했습니다. 닷넷(.Net) 프레임워크에서 제공하는 WPF(Windows Presentation Framework)를 사용해서 개발된 프로그램이였습니다. 비록 닷넷 프레임웍 런타임(runtime) 환경을 다운로드 받아야 했지만, 기존 윈도 프로그램에서 볼 수 없었던 부드러움과 신선함을 느낄 수 있었습니다. 닷넷 프레임워크는 마이크로소프가 자바를 대항에서 만든 윈도 기반의 어플리케이션 실행 환경입니다. 비주얼 베이직과 같은 런타임 실행 환경과 다양한 소프트웨어 컴포넌트로 구성되어 있습니다. C#이라는 언어에 의존적이지 않고 다양한 언어를 지원할 수 있도록 공통 언어 인프라스트럭쳐(Common Language Infrastructure)를 제공하고 있습니다. 단순히 자바를 죽이기 위해 개발된 것 보다 윈도의 차세대 SW 플랫폼을 만들기 위한 전략으로 개발된 것 입니다.

이런 사실 때문에 Win32 API와 MFC가 윈도 개발의 모든 것이라고 생각했던 많은 개발자에게 또 다른 고민거리를 안겨주었습니다. 이것은 비주얼 베이직이 등장할 때와 또 다른 문제였습니다. 마이크로소프트가 닷넷 프레임워크를 향후 윈도 프로그래밍의 주력으로 밀 것이 분명해보였고 이것은 윈도 비스타가 출시되면서 현실이 되었습니다.
윈도 비스타의 새로운 기능인 벡터 방식의 그래픽, 3D기능, 애니메이션 기능은 바로 닷넷 프레임워크 3.0에서 제공하는 WPF의 기능이며 현재 윈도XP에서도 지원하고 있습니다. 이 기능을 제대로 활용하려면 닷넷 프레임웍을 새로 공부해야 하고 비주얼 스튜디오2005에도 익숙해야 하며 무엇보다는 UI를 만들려면 XAML(eXtensible Application Markup Language)을 잘 알아야합니다. UI가 기존의 대화상자나 콘트롤 위주가 아니라 벡터 그래픽, 3D, 애니메이션, 동영상이 결합되기 때문에 이를 통합 할 도구의 사용법도 익혀두어야 합니다. 앞으로 플래시 만큼 상큼하고 역동적인 UI를 윈도 어플리케이션에도 흔히 볼 날도 머지 않았습니다. 물론 많은 개발자들이 이를 지원할 수 있도록 공부를 해야겠지요.

웹에서 데스크탑으로
소프트웨어를 개발할 수 있는 방법이 점점 더 다양해져가고 있습니다. 이전에는 나름대로 고유영역이 있었습니다. C,C++는 높은 성능과 최척화가 필요한 부분에 사용되었고, 자바는 네트웍 환경에서 서비스나 데이터를 처리하는데 많이 사용됩니다. 웹은 브라우저 기반의 정보 서비스와 같은 주로 정적인 정보 제공하는 역할을 제공했었지요. 플래시는 벡터 방식의 단순한 애니메이션을 보여주는 기능을 해왔습니다. 하지만 지금은 그 경계가 무너지고 있습니다. 특히 웹브라우저와 플래시는 자신의 영역을 계속 넓혀가고 있습니다. 웹브라우저는 Ajax기술을 이용하여 웹 페이지 변경 없이, 마치 데스크탑 어플리케이션 처럼 풍부한 UI를 지원합니다. 플래시도 마찬가지로 단순한 애니메이션 저작툴이 아닌 다양한 응용 어플리케이션도 개발할 수 있는 소프트웨어 플랫폼의 역할을 할 수 있을 정도로 기능이 강화되고 있습니다. 이들 인터넷 기반의 새로운 어플리케이션 형태를 RIA(Rich Internet Application)라는 부르고 있습니다. 웹브라우저를 기반으로 마치 전통적인 데스크탑 어플리케이션과 같은 기능을 제공하는 소프트웨어를 부르는 말입니다. 지금 RIA가 데스크탑 어플리케이션을 따라가고 있다면 데스크탑 어플리케이션은 WPF와 같은 기술을 통해 한 발짝 더 나아가려 하고 있습니다. 이런 흐름에서 도도하게 옛 방식만을 고수하기는 힘들 것입니다.

변화가 싫다면 발전 속도가 느린 시스템 프로그래밍 이하를 파고 들던지 아니면 새로운 환경에서 좀 더 유연한 개발 언어, 개발 환경을 통해 지금 보다 나은 풍부한 사용자 경험과 편리함을 제공하면 어떨까요? 물론 SW 개발도 이전보다 더 쉽고 재미있어야 하겠죠?

댓글()

브라우저 호환성

Web|2006. 5. 21. 00:12
IE를 이용해서 내 블로그에 등록된 글을 보다가 갑자기 좌측 메뉴가 밑으로 밀리는 현상을 발견하게 되었다. 문제의 원인을 찾느라 HTML소스 코드를 한참 뒤져봤는데, 문제는 이미지 폭이였다.

Firefox나 Apple의 Safari같은 경우 이미지 폭이 블로그 본문 폭을 넘어서면 자동으로 그림을 줄여준다. 그 품질은 브라우저 마다 플랫폼 마다 다른 것 같다. 맥에서는 이미지가 깨지지 않고 자연스럽게 줄어든다. 맥에서 이미지를 렌더링하는 API가 렌더링 크기에 맞게 이미지를 scaling해주는 것 같다. 문제는 IE인데, 원래 크기로 이미지가 나타나는데, 그 크기가 블로그 본문을 넘어서면 메뉴가 이미지를 피해 본문 뒤로 밀리는 것이다. 기존처럼 Table 태그를 이용해서 전체적인 윤곽을 잡았다면 이런 현상은 없겠지만, 워드프레스는 CSS를 이용해서 전체 윤곽을 잡기 때문에, 이미지와 메뉴를 같은 영역에서 표시할 경우, 브라우저 마다 다르게 렌더링 되고 있는 듯 보인다.
사실 XHTML, CSS 스펙을 아무리 잘 정의해도 이를 화면에 그려낼 때는 사소한 부분에 구멍이 생기게 마련이다. 이 경우 가장 대중적인 브라우저를 렌더링 방식을 모방하게 되는데, 지금은 사정이 그렇지 못한 것 같다. 대부분의 공개 소프트웨어가 Firefox를 기반으로 개발되다 보니 오히려 미묘한 부분에 있어서 IE에서 문제를 일으키고 있다. 물론 IE가 CSS 풀스펙을 지원하지 못해 생기는 문제일 수도 있다.
미묘하지만 이러한 브라우저 호환성은 실제 컨텐츠를 개발할 때 늘 문제거리가 되고 만다.

TV 제품 마다 다르게 방송신호를 보내거나 영상을 만들어한다고 생각해보자. 가정마다 TV를 채널별로 갖고 있을 수도 있다. 무척 우스운 일 처럼 보이지만 실제 웹을 두고 이런 일이 벌어지고 있다. 표준화가 어렵기는 하지만 조금만 욕심을 버리고 기술의 표준화를 통해 웹의 접근성을 높였으면 좋겠다. 특정 컨텐츠를 이용하기 위해 또 다른 컴퓨터를 켜는 일은 더 이상 없어야 할 것이다.

'Web' 카테고리의 다른 글

스프링 노트 사용자 모임 참석 후기  (0) 2007.05.07
멀고도 험한 오픈웹 세상.. 황당한 금융결재원  (0) 2007.04.28
Digg  (4) 2006.04.07
PHP에서 XML파서와 RSS Reader 이용하기  (0) 2005.04.03
RSS와 XML  (1) 2004.09.26

댓글()

XML, HTML을 대신할 것인가?

Web|2002. 12. 3. 10:39
HTML은 분명 문제가 많습니다. 데이터 중심이기보다는 문서 렌더링을 위한 표준이므로, HTML을 처리하여 정보를 얻는데 문제가 많습니다. 특히 IE가 오류난 HTML문서도 웬만큼 잘 보여주는 것도 HTML를 처리하는데 많은 부담을 주고 있습니다.

그래서 XML을 따르는 HTML규격이 표준화되었고 향후 XHTML 형태로 웹문서가 작성될 전망입니다.

많은 브라우저들이 XML처리를 지원하고 있으나 이러한 방식은 아직 표준화되지 못했습니다. IE에서 XML,XSLT로 HTML문서를 렌더링하여 보여주는 것은 앞으로 웹의 변화 모습의 한 예일 수도 있으나 어쩌면 IE만의 기능을 일 수도 있습니다.

지금 문제는 다양한 단말환경을 현재의 방식으로 지원하기 힘들다는 점입니다. PC뿐만 아니라 PDA나 핸드폰같은 작은 화면을 가진 단말환경에서도 웹브라우징을 하고 있습니다. 하지만 여러 제약으로 제대로 이루어지지 않고 있습니다.

결국 서버에서 XML을 이용하여 다양한 단말환경을 지월할 수 있는 체제로 변화되지 않을까 생각합니다. 단말환경에서 바로 XML데이터를 받아 변환과정을 거쳐 화면에 보여주는 것은 부담이 클 것 같습니다.

DB에서 생성된 데이터는 다양한 단말환경에 따라 서버에서 렌더링된 문서를 생성하여 전송하는 형태로 갈 것입니다.

이때, 단말환경이 수용할 수 있는 다양한 XML응용표준이 XHTML안에 포함되어 클라이언트에 전송되면 브라우저에서 이를 렌더링하여 화면에 보여주겠죠. ?MathML이나 SVG가 이런 형태가 될것입니다. 부분적으로 지금 웹브라우저에서 가능하며 앞으로 이런것들이 표준화되면 일반화될것입니다. 경우에 따라 ?MathML이나 SVG가 서버에서 이미지로 처리되어 클라이언트에게 전달될수도 있습니다. PDA나 핸드폰에서는 후자 방식이 채택될 것입니다.

사실 XSL은 디자인 유연성이 많이 떨어집니다. 그냥 문서를 출력한다면 괜찮겠지만 요즘처럼 복잡한 구조의 웹페이지를 구현하기는 힘들것입니다.

결론적으로 HTML은 XHTML로 진화하여 화면 렌더링을 위한 표준안으로 살아남을 것이고 클라이언트 보다는 서버에서 XML을 이용한 컨텐츠 생성이 이루어질 것입니다. 데이터 교환에는 XML데이터가 중심이 되겠지만 웹브라우저에 문서가 렌더링되기위해서는 여전히 HTML이 XHTML이 되어 전송될 것입니다.

2002 12/3 (위 글을 http://geekforum.kldp.org/ 에 올렸던 글입니다.

'Web' 카테고리의 다른 글

Digg  (4) 2006.04.07
PHP에서 XML파서와 RSS Reader 이용하기  (0) 2005.04.03
RSS와 XML  (1) 2004.09.26
어떤 브라우저도 차별받지 않는 세상이 왔으면 좋겠습니다.  (1) 2004.09.26
재밌는 인터넷 즐기기~  (1) 2004.09.05

댓글()