불과 2년 전까지만 해도 저는 서류 탈락과 면접 불합격 통보를 일상처럼 받아들이고 있었습니다. 그렇게 수십 통의 거절 메일을 받으며, 개발자로서 부족하다고 느끼던 시기가 있었죠. 그러나 이제는 구직 활동조차 하지 않았는데도 여러 곳에서 이직 제안을 받는 상황이 되었습니다. 아마 비슷한 고민을 하는 분들이 있을 겁니다. 회사 업무만으로는 뭔가 부족하다는 느낌, 더 성장하고 싶은데 방법을 모르겠다는 생각… 저도 그랬습니다. 회사 프로젝트는 론칭이 미뤄지기도 하고, 정확히 어떤 기여를 했는지 드러내기도 어려웠죠. 이 글에서는 제가 오픈소스 프로젝트 ‘NotionPresso’를 진행하며 배운 것들을 공유하고자 합니다. 오픈소스 주제를 선정하는 방법부터 구조 설계, 커뮤니티와의 소통, 그리고 결과물을 발전시키는 과정을 담았고, 이 여정을 통해 오픈소스라는 새로운 도전에 대한 작은 동기를 얻을 수 있다면 좋겠습니다.

대부분의 개발자들은 비동기 파이썬이 더 높은 동시성을 제공한다는 것을 알고 있죠. 그래서 동적 웹사이트나 웹 API를 서빙하는 것과 같은 일반적인 작업에서 더 좋은 성능을 보일 거라고 생각하기 쉽습니다. 하지만 안타깝게도 비동기는 파이썬 인터프리터의 성능을 마법처럼 높여주는 해결책이 아닙니다. 실제 상황(아래 참조)에서 테스트해 보면, 비동기 웹 프레임워크는 처리량(초당 요청 수) 면에서 오히려 약간 더 안 좋은 성능을 보이고, 지연 시간의 변동 폭은 훨씬 더 큰 것으로 나타났습니다.

요즘 기술업계에서 가장 핫한 단어는 아마도 AI 에이전트일 겁니다. 지금까지 들었던 에이전트는 영화에서나 나오는 FBI/CIA 에이전트 정도가 다였는데 말입니다. 그렇다고 미리 쫄 필요는 없겠지요. 지금부터 여러분이 저와 딱 10분간만 함께 하면, 그 후에는 AI 에이전트에 대해 잘 이해할 수 있습니다. AI 에이전트란 무엇일까요? 또 무슨 일을, 어떻게 할까요?

한 달 전, 한강 작가의 노벨 문학상 수상으로 세간이 떠들썩했습니다. 하지만 인공지능 업계 종사자들에게는 그보다 훨씬 더 가슴 뛰는 사건이 하나 있었습니다. 바로 노벨 과학상(물리학, 화학 부문) 수상자가 모두 인공지능 발전사의 한 획을 그은 인물들로 채워졌다는 것입니다. 2024년은 인공지능이 주도하는 과학 혁명의 원년이라고 할 수 있습니다. 딥러닝이 어떻게 기존의 과학 연구 패러다임을 혁신적으로 바꾸고 있는지, 노벨 화학상 수상의 중심에 놓인 딥마인드 알파폴드(AlphaFold)의 사례를 살펴보겠습니다. 도대체 인공지능은 어떻게 과학 연구 분야의 난제들을 해결하고 있는 것일까요?

앞서 글에서는 “서비스향으로 AI 모델을 개발한다”라고 할 때, 무엇이 다를지 설명했습니다. 들여다봤더니 정말 많은 일이 있죠? 그 많은 업무는 결국 기술팀에서 감당해야 합니다. 그래서 “효율적으로 이를 잘 감당하려면 조직 구성을 어떻게 하면 좋겠느냐”라는 물음에 대한 답을 제 개인적인 의견을 담아 만들어 봤습니다. 또, 이런 조직 구조를 바탕으로 AI 쪽에서 커리어를 시작하거나, 직종을 전환하려는 개발자를 위한 조언을 몇 가지 준비했습니다.

시장에는 오픈AI의 챗GPT, 앤트로픽의 클로드, 구글의 제미나이 같은 대표 LLM을 제외하고도 수많은 언어 모델이 거의 매일 새롭게 나타나고 있으며, 각 모델마다 고유한 기능과 전문성을 갖추고 있습니다. 그러다 보니 비즈니스 애플리케이션을 고집하지 않아도 어떤 서비스를 만들고자 할 때, 그 기능 요구 사항에 따라 사용자 쿼리를 해석할 때는 어떤 특정 LLM을 사용하고, 해당 쿼리에 대한 응답을 작성하는 데는 완전히 다른 LLM을 사용하고자 하는 필요성이 생길 수 있습니다. 이럴 땐 어떻게 프로세스 파이프라인을 구축해야 할까요? 이런 워크 프로세스를 요청하는 시나리오가 바로 ‘랭체인(LangChain)’ 탄생에 아이디어를 제공합니다.

Wafris는 웹 애플리케이션 방화벽을 오픈소스로 제공하고 있습니다. 저희는 다양한 프레임워크를 지원하는데, 그중에서도 Rails 미들웨어 클라이언트를 제공하고 있죠. 처음 v1 클라이언트를 출시했을 때는 여러분의 앱과 함께 로컬 Redis 데이터스토어를 배포해야 했습니다. 하지만 이제 v2 Rails 클라이언트를 출시하면서 SQLite를 백엔드 데이터스토어로 사용하게 되었습니다. 이 글에서는 Redis에서 SQLite로 마이그레이션하기로 결정한 이유, 성능에 대한 고려 사항, 그리고 아키텍처의 변화에 대해 다룰 예정입니다.

물음표 문자가 생기는 이유를 알기 위해 유니코드에 대해 알아보고, 한글 문자 구성도 확인했습니다. 이제 euc-kr과 함께 utf까지 알아볼 차례입니다. 이 과정을 거쳐 유니코드의 U+FFFD라는 스펙을 찾아내고, 문제를 해결한 과정을 공유하겠습니다. 한글이 어떤 식으로 저장이 되고, 브라우저에서는 어떤 식으로 표현되는지 기억해 주면 좋겠습니다. 또 제가 문제를 해결한 과정을 힌트 삼아 문제가 생길 소지를 살펴보면, 비슷한 문제를 해결하는 데 도움이 될 것이라 생각합니다.

이 글은 함께 일하던 매니저님이 보낸 슬랙 메시지에서 시작되었습니다. “텍스트 에디터로 글을 작성하는 도중에 긴 글을 작성하면 이상한 물음표 글자가 자꾸 생겨요.”, “이 글자를 지우기 위해 글을 수정하고 다시 업로드를 하면 또 다른 곳에 나타나요. 꼭 두더지 같아요!” 이 메시지를 보낸 매니저님은 이런 현상을 보고 ‘유니코드 지옥’이라고 표현했습니다. 이 물음표가 왜 등장하는지, 이 문제를 어떻게 해결할 수 있는지, 그 여정을 함께 해보겠습니다.

실제 서비스를 위한 AI를 만들 때 필요한 것들을 마저 살펴볼까요? 학습 데이터셋 정의와 구축을 마치고 나면 정해야 하는 것은 테스트 방법입니다. 이 방법 역시 서비스 요구 사항으로부터 도출해야 합니다. 즉, “어떻게 이 AI 모델을 평가할 것인가”에 대한 정보를 알아내는 일이죠. 서비스 요구 사항의 쓰임은 여기서 끝이 아닙니다. 또 하나 필요한 작업이 있습니다. 바로 모델에 관련된 요구 사항을 도출하는 일입니다. 이처럼 단순히 AI 모델의 성능을 올리는 작업 외에도 정말 많은 일들이 있습니다. 모델 개발에 어떤 과정들이 필요하다, 이것만 알고 있어도 실무에서 AI 모델을 개발할 때 정말 큰 도움이 될 거라고 믿어 의심치 않습니다.