POSTS.

위스키를 좋아하다 보니 위스키 직구 비용 계산 iOS 앱도 앱스토어에 올렸고 이런저런 개인적인 어플리케이션을 만들어 사용하고 있다. 전세계적으로 위스키 가격이 저렴해지고 있고, 물량들도 조금씩 풀리고 있어서 오늘은 n8n을 사용해서 주로 사용하는 해외 위스키 판매점의 재고 변화를 모니터링하는 기능을 구현해봤다. 매일 매일 특정 시간에 영국의 위스키 온라인 판매점의 관심 위스키 목록을 https request 로 파싱해서 가져와서 n8n 자체 DB에 저장한 다음 호출 때 나타난 위스키 목록과 비교를 한 뒤 재고 변화, 신규 위스키 보틀 입고를 확인해 변동 사항을 내 이메일로 전송한다. n8n에 새로 도입된 자체 DB 덕분에 간편하게 구현이 가능했고 이런 기능 이외에도 발빠르게 업데이트를 꽤나 자주 하고 있다. 자동화 분야에서 n8n이 매우 강력해서 잘 쓰고 있는 입장이지만, 어제인가 그제인가 구글에서도 워크 플로우 스튜디오를 내놨다. 아이디어와 조금의 기술적 이해가 있으면 삶이 한스푼 정도 더 나아지고 있다. 뭐, 덕분에 이제 매일 위스키 재고를 직접 파악하러 사이트에 접속할 필요가 없으니 나야 큰 덕을 보는 셈이다. n8n이든 Make가 됐든, 뭐든 바이브 코딩만 하지 마시고 자동화 도구들로 워크 플로우를 꼭 짜보셨으면 좋겠다. 참고로 위스키 직구 구매 계산 앱은 👇

평소 온라인 강의를 할 때 줌을 통해 진행을 하면 실시간 채팅을 확인하느라 강의의 흐름이 깨지거나, 혹은 강의를 보시는 분들도 다른 분들과 소통을 강의 화면 내에서 진행을 하지 못하는 점 등이 아쉬웠다. 그래서 개발하여 사용하던 뮨이라는 서비스가 있었는데, 기존 서비스는 웹소켓이 아닌 파이어베이스의 Firestore로 데이터베이스 Listening을 통해 구현을 하고 있었고, 실시간 협업 보드 등의 추가 개발 기능에 대한 부분에서 다소 아쉬운 감이 있던 차에 아예 백엔드를 통채로 독자 서버로 구축하는 새로운 개발 작업을 진행했다. 다양한 기능들이 있지만, 채팅 자체가 메인이라 웹소켓 통신으로 유기적으로 서버와 클라이언트가 간편히 통신할 수 있는 구조를 활용했고, 사용하는 리눅스 VM의 비용을 줄이기 위해 컴퓨팅 성능을 낮춘 관계로 프론트는 외부 PaaS를 통해 리소스를 분산시키기로 했다. 대부분 바이브 코딩 입문자들은 주로 파이어베이스의 파이어스토어의 OnSnapshot, 혹은 Supabase의 Realtime DB로 구현을 하면 될테지만, 결국 사용자가 늘고 트래픽이 늘면 PaaS 의존성에 대한 경제적 비용이 상승하게 된다. 게다가 실제로 웹소켓 통신의 장점도 꽤나 크기 때문에 아예 이번에는 독자 서버로 가닥을 잡았다. 이번 플랫폼은 간단히 다음과 같은 형태로 구현된다. 개발 레포 : 프론트 / 백엔드 모노레포 구조 프론트는 Vercel로 배포 API 서버는 리눅스 VM / NodeJS / Apache 리버스 프록시 / SSL DB는 PostgresQL 바이브 코딩을 주로 즐기는 분들은 백엔드를 주로 Supabase를 사용하는게 트렌드라면 트렌드인데, 특히 MCP 등으로 그냥 개발을 하게 되면 결국 프론트에서 Supabase를 API 통신으로 제어하는 형태가 되고, 결국 보안 이슈가 터진다. 특히 초보분들에게는 귀찮고 까다로운 RLS 설정에서 헤매는 경우가 많고, 인공지능으로 보안 이슈를 잡다보면 서비스 기능이 동작이 안되는 경우가 허다하다. 특히 전혀 DB 구조와 설계를 염두해두지 않고 오로지 바이브 코딩으로 진행하다 보면 결국 DB 단에서 꼬여 RLS 설정을 제대로 하기 힘든 경우가 생긴다. 이런 경우는 대부분 프론트에 노출된 Anon 키만으로도 데이터베이스 통채로 털릴 수 있다.(실제로 친한 선생님 중 유사한 사례를 겪으신 분이 계신다.) 이건 사실 파이어베이스도 동일하다. 그래서 역시나 가장 좋은 건 철저히 백엔드를 통해 DB를 읽고 쓰는거다. 그러기 위해서는 역시나 백엔드 API 서버를 구축해야한다. 백엔드 서버를 구축해도 좋고, 서버리스 함수나 엣지 펑션 등으로 백엔드 관련 작업을 진행해도 좋다. 다만, 역시나 사용자가 대규모로 생기면 서버리스나 엣지 펑션도 결국 비용 문제로 귀결 되기 때문에 가장 좋은 건 직접 구축.

개발하고 있는 교육 서비스 그라운드에 메타 그라운드 서비스를 신규 기능으로 추가했습니다. 국내에선 ZEP 이나 개더 타운 등이 잘 알려져있고 특히 ZEP이 매우 많은 기능과 다양한 기능들로 특히 교육계에서 많이 활용되고 있기도 하죠. 학생들과 수업하면서 메타버스 형태의 게이미피케이션 기능 구현에 대한 학생들의 니즈가 크다는 걸 알고 있고, 언젠가는 구현을 해봐야지하고 생각하던 기능이기도 했는데요. 다만 소규모 서비스를 운용하는 입장이라 웹소켓 등으로 통신하기 보다는 서버 리소스를 최소화 하면서도 학생들에게는 유사한 UX를, 그리고 교사들에게는 공간(Space) 개념의 핵심적인 교육 기능을 제공하기 위해 한 몇일은 구현 방식에 대해 고민했던 것 같습니다. 오픈소스 WorkAdventure 도 고려를 했었는데, 그렇게 되면 기존의 그라운드와 너무 동떨어진 구현이 될것이 뻔한데다 실제 별도 운영 서버를 추가로 구현하고 이리저리 복잡한 통신 방법을 고려해야 했기 때문에 그냥 한땀한땀 직접 모두 만들자-로 결정이 되었습니다. 결과적으로 메타 그라운드라고 오픈된 이 서비스는 교사가 맵 에디터에서 공간을 기반으로 맵을 에디팅하면, 학생들은 이동 창구를 통해 여러 공간을 이동하며, 클래스원들에게 학생들이 위치한 "공간"에 대한 정보를 전파합니다. 이 개념을 구현하기 위해서, 일단 접속 화면 라우팅을 개발 모드에서 세팅하고, 메타 그라운드 룸 진입 페이지, 맵 에디터 페이지, 실제 메타 그라운드 실행 페이지 등 다양한 컴포넌트를 먼저 고민하고, 연동 방식을 설계한 뒤에 인공지능과 함께 작업을 시작했습니다. 바이브 코딩이라기 보다는 설계안을 디테일하게, 인공지능에게 요청하는 건데 개인적으로는 별도의 PRD 문서를 인공지능에게 요청해서 만들기 보다는 제가 PRD 초안을 만들고, 이후에 체크리스트화 하여 작업하도록 인공지능에게 지시하는 편입니다. 여튼 그렇게 하루종일 컴퓨터 앞에서 개발을 진행했고, One Canvas 기반의 공간 스페이스 구조가 핵심인 메타 그라운드의 베타 버전이 오픈되었습니다.

에듀테크 서비스에 내이티브 AI는 필수인가? 요즘 에듀테크 관련 이런 저런 데이터들을 검토하고, 분석하고 있다. 특히 AI 기술이 삶 속에 깊숙히 들어온 가운데 거의 모든 에듀테크 관련 기업들이 AI 기술을 도입하고 있는데, 이에 대해 최근 느끼고 있는 생각들을 단편적으로나마 조금 정리해보고자 한다. 최근 급속도로 발전하는 AI 기술에 대해 수많은 기업들은 이 기술을 도입하지 않으면 뒤쳐질지 모른다는 강박에 시달리고 있어 보인다. 패들렛을 위시하며, 정말 굳이 AI가 필요하지 않은 거의 대부분의 서비스들에도 AI 도입 추세가 급물살을 타고 있는데, 이게 과연 좋은 전략인가?에 대해서는 꽤 회의적이다. 이유는 사실 심플한데, 최근 브라우저에 도입되는 AI 기능들, 특히 퍼플렉시티나 OpenAI가 내보인 브라우저 기반의 인공지능 에이전트가 플랫폼을 넘나들면서, 사용자의 패턴을 메모라이징 한뒤 그에 따라 거의 대부분의 작업을 처리할 수 있는 기반이 마련되었기 때문이다. 특히 기존의 자체 인공지능 모델을 기반으로 콘텐츠를 저작한다던가 혹은 이미지를 편집한다던가 하는 형태의 플랫폼 자체의 AI 기능들은 동일한 기능을 처리하는 더 거대한 범용 외부 인공지능 에이전트들에 비해 경쟁력이 약할 수 밖에 없다. 예를 들어 패들렛이 TA 기능을 바탕으로 특정 교사가 원하는 수업 흐름을 자동으로 패들렛 보드에서 생성해준다고 가정해보자. 이는 사실 굳이 패들렛의 인공지능이 아니더라도 OpenAI 의 아틀라스 등의 브라우저가 할 수 있는 영역이 훨씬 더 많다. 예컨데 특정 출판사의 특정 콘텐츠를 기반으로 한 수업 자료를 생성한다고 할 때 패들렛 내부의 AI는 특정 출판사의 사용자 인증 기반의 콘텐츠를 접근하지 못하고, 당연히 그에 대한 자료를 기반으로 수업 흐름을 설계할 수 없지만 인공지능 브라우저라면 이야기가 다르다. 아틀라스는 사용자 인증 정보를 브라우저에 저장함은 물론 원하는 무수한 사이트를 스스로 탐색하며, 자료를 검토하고 패들렛의 DOM 요소를 확인 후 직접 패들렛 상에서 작업을 완료한다.

KTV 국민방송(25.11.10.) 인공지능 인재 양성 방안 교육부 브리핑 # 교육부 「모두를 위한 AI 인재양성 방안」, 2025.11 정책 학교급별 적용 사항 요약 교육부가 AI 인재양성을 위한 로드맵을 공개했습니다. 사실 완벽한 교육 정책이라기 보다는 인재육성에 초점을 맞춘 청사진이라고 보는 것이 정확할 듯 한데요. 아직은 너무나 거시적인 계획이라 세부 추진 계획이 나와야 실제 현장에서의 방향성과 움직임이 가시적으로 확인될 듯 합니다. 일단 학교급별 계획을 정리해봤습니다. 초등학교 관련 ■ 초등학교 AI 기본교육 확대 놀이와 체험 중심의 방과후 프로그램 운영 : 초등학교 저학년부터 놀이와 체험 중심 활동을 통해 AI에 대한 이해와 친숙도를 높이는 다양한 방과후 프로그램을 운영. 초등 실과 및 교과 연계 초등 실과나 다른 교과에서도 AI 관련 교육자료를 활용하여 기본 소양을 쌓을 수 있는 기회를 제공. AI 중점학교 확대 계획(안) ('25년) 초등학교 308교(5.0%) → ('28년) 1,000교(16.2%)로 확대 정보교과 시수 확대 : (초) 34시간 → 68시간 중점학교를 지역 AI 교육의 중심축으로 육성. ■ 디지털 새싹 프로그램 대상: 초‧중‧고 학생 내용 예시: 「AI 플레이 그라운드」(초등학생용): 음성인식, 이미지, 음악 생성 기술 체험 및 AI 기반 게임 제작을 통해 인공지능 역량 함양.

커서에서 새로 도입된 자체 모델 Composer 성능이 꽤나 준수하다. 요금은 클로드 4.5 소넷의 반값에도 못 미치고 속도는 매우 빠르니 왠만한 작업에는 클로드 소넷을 사용하기 이전에 비용이 동일한 Composer 와 gpt-5-Codex 를 주로 사용해도 큰 무리가 없어 보인다. 요금을 코덱스와 동일하게 설정한 것은 모종의 자신감이 아닌가 한데, 요즘 코덱스도 잘 쓰고 있는 입장에서 당분간 컴포저로 작업을 해보려고 한다. 일단 간단히 커서 2.0에서 컴포저로 단 한문단의 프롬프트로 내가 요청한 프레임워크, 라이브러리를 모두 적용한 프로젝트를 단 한번의 모듈 설치 오류 수정만으로 완성했고 속도도 매우 빨랐다. 특히 이번에 추가된 에이전트 모드 뷰를 사용해서 만들어봤는데, 아마도 러버블이나 기타 바이브 코딩 화면에 익숙하셨던 분들이라면 아무런 이질감 없이 훨씬 가벼운 마음으로 코딩을 시작할 수 있을 것 같다. 에이전트 뷰는 코드 에디터를 숨기고, 오로지 대화 모드로 동작한다. 그리고 터미널도 백그라운드에서 모두 띄워준다. 물론 에이전트 화면에서도 터미널 윈도우와 코드 윈도우를 띄울 수는 있다. 이 경우 대화 창이 메인이고, 코드와 터미널이 서브 사이드 패널로 나타난다. 이렇게 쭉 다 알아서 자기가 다 작성하고, 컴포저로 만들었더니 전광석화과 같은 속도로 프로토타이핑이 가능했다. 나름 디자인도 요청에 맞게 유려하게 잘 만들어줌. 커서 2.0에서 대화창에 타이핑을 하면 터미널로 포커싱이 이동되는 버그가 있었는데, 오늘 또 한번의 업데이트로 인해 해결이 된것 같은 느낌이 있다. 윈드 서프와 번갈아가며, 하루에 두어번 업데이트를 하는 듯 한데, 대단한 업데이트 속도다.

주력으로 사용하는 커서가 새로운 메이저 업데이트를 내면서 대거 기능 향상을 이뤄냈습니다. 2.0 버전인만큼 독자적으로 테스트 하던 치타(cheetah)가 자신들의 독자 모델이었음을 밝혔고, 그 모델을 바탕으로 컴포저(composer-1)이라고 하는 코딩 모델을 선보였습니다. 치타가 기존 이름이었던 만큼 코딩 능력이 최상위는 아니지만 일단 준수한 성능에 속도가 타의 추종을 불허하는군요. 사실 2.0에서 가장 큰 변화는 한번의 명령에 다양한 모델들을 병렬 실행할 수 있다는 점입니다. 클로드 코드에서 여러 모델들을 병렬 처리 하는 기능으로 많은 호응이 있었는데, 커서는 이제 독자 모델 + 다른 모델들을 모두 한번의 작업에 일꾼으로 부릴 수 있습니다. 다양한 에이전트가 각자의 워크트리를 생성해서 병렬적으로 코드 간섭 없이 작업을 처리합니다. 그리고 각각 작업을 시킨 모델들이 어떤 작업을 얼마만큼 진행했는지도 모두 확인이 가능합니다. 각각의 에이전트 작업 결과를 선택하거나 각 모델들의 결과물을 선택적으로 머징(merging)할 수도 있습니다. 그리고 이제 완벽히 바이브 코더들을 위한 에이전트 인터페이스도 도입을 했는데요. 러버블이나 기타 인공지능 기반 바이브 코딩 서비스들과 거의 유사한 대화형 코딩 뷰를 제공합니다. 아래 이미지는 실제 에이전트 뷰에서의 화면입니다. 프로젝트의 코드를 보여주는 대신 정말 손쉽게 에이전트만으로도 앱을 코딩할 수 있는 뷰 모드로 초보자분들에게 특히 편리할 것 같은데요. 저도 조만간 한번 에이전트 모드로 앱을 구축해보고 후기를 남겨드리겠습니다. 상세한 업데이트 정보는 아래에서 확인하실 수 있습니다.

구글 크롬이 제미나이 연동으로 생태계를 잡아 먹나 했더니 openai 는 아예 자체 브라우저를 개발했습니다. 사실 기존에 PC 기반 컨트롤 에이전트를 자체 브라우저화 한 것인데, 최근에 퍼플렉시티에서 코멧 브라우저를 내놓았고, 이어 OpenAI 도 자체 브라우저를 내 놓은 것은 그리 놀라운 일은 아닙니다. 구글이 이미 유료 유저들을 대상으로 크롬 브라우저에 제미나이를 통합해둔 상황이니 구글의 거센 반격을 대비하려면, 이제 브라우저 시장에서도 점유율을 가져가야 할 수 밖에 없는 상황이죠. 다만 이번에 출시된 OpenAI 의 아틀라스 브라우저 역시 구글 크로미움 기반의 웹 브라우저입니다. 구글이 일찌감치 키운 크롬 브라우저 엔진이 타 경쟁업체들에게 유용하게 사용된다는 점이 재미있기도 합니다. 여튼 아직 아틀라스는 맥OS용으로만 출시가 되었기에 많은 분들은 사용하실 수 없어서 제가 먼저 간단하게 사용해봤습니다. 일단 ChatGPT 유료 유저인 경우에 에이전트 기능을 사용할 수 있는데, 여기서 에이전트 기능은 바로 브라우저를 직접 제어하는 기능입니다. 아래는 간단히 아틀라스 브라우저가 트라이디스라는 교육플랫폼에 포스트를 여러개 작성하는 기능이 동작하는 화면입니다. 속도는 느리지만 브라우저 자체에 AI 가 붙다보니 브라우저 프론트엔드에서 그려지는 DOM 요소들을 직접 확인하고, 직접 DOM 노드를 확인해서 동작을 처리합니다. 그래서 단순히 화면을 스크린샷으로 찍어 동작하는 방식보다 보다 정교하게 작동이 가능하고, 미래에는 직접 프론트의 코드를 브라우저 상에서 처리해서 실시간으로 프론트엔드 수준에서 앱을 리모델링 할 수도 있을겁니다. 이런 구조이다 보니, 대화를 통해서 브라우저 자동화 작업들을 쉽게 처리할 수 있는 시대가 되었습니다. 아직은 속도가 꽤 느린것이 문제지만 앞으로 최적화된다면 활용 방법이 무궁무진 하지 않을까 합니다. 특히, 이번 퍼플렉시티의 코멧, OpenAI의 아틀라스 브라우저는 사실 구글이 앞으로 크롬 브라우저로 하고자하는 것을 미리 보여준 셈입니다. 이미 서드파티 browserbase.com 같은 경우는 다양한 인공지능 모델을 가상화 브라우저 환경에서 앞서 보여드린 화면처럼 에이전트 기능으로 활용하기도 하죠. https://gemini.browserbase.com 를 통해 테스트해보실수도 있습니다.