이미 사용 중인 스크랩북 이름입니다.
다른 이름을 지정해 주세요.
중소 IT 채용 시장에는 적합한 사람을 구하기 어렵다는 한탄이 많다. 그런데 간혹 그 어려움의 이유가 보이는 채용 공고를 만나기도 한다. 심지어 최근 본 어떤 공고는 담당 업무 항목을 채우지 않아, “상세내용을 입력하세요” 문구가 그대로 노출되고 있었다. 담당 업무 항목은 구직자의 지원 여부를 결정할 매우 중요한 정보다. 이런 성의 없는 채용 공고는 적합한 인재를 만날 가능성을 떨어뜨릴뿐더러 회사에 대한 인상까지 나쁘게 만든다. 이번 기회에 중소 IT 기업 채용 공고의 나쁜 사례들을 살펴보고 그에 대한 처리 방식을 제안하려고 한다. 중소 IT 기업에서 인사를 담당하거나 관련 있는 분들이 주목하면 좋겠다. 아울러 IT 직군 구직자들도 원하는 일자리를 얻는 데 도움을 얻길 바란다.
“ChatGPT 美 변호사 시험 상위 10%로 통과”, “Claude 3, AI 첫 IQ 100 돌파” 위와 같이 AI의 능력을 홍보하는 문구들을 자주 접하셨을 것 같습니다. 이러한 성과들이 대단해 보이기는 하지만, 한편으로는 그 수준이 어느 정도인지 체감이 안 될 때가 있는데요. 마침 지난주 목요일 치러진 2025 대학 수능 시험을 통해 AI 능력을 시험해 보기로 했습니다. 평가 과목으로는 국어, 영어, 수학을 선택했는데요. 그 이유는 AI의 언어 처리 능력과 수리적 사고력을 종합적으로 평가하기 위함이고, 특히 한국어 능력 수준이 어느 정도 되는지 가늠해 보기 위함입니다.
잘 성장하던 아크(Arc) 브라우저가 돌연 업데이트 중단을 선언했다. 지난 10월 25일, 아크의 개발사인 더브라우저컴퍼니의 대표가 유튜브에 영상을 올렸는데, 더 이상 아크에 기능을 추가하지 않겠다고 발표한 것이다. 앞으로는 보안 업데이트만 진행할 것이며, 나머지 시간은 새 제품을 개발하는 데 집중할 예정이라고 한다. 더브라우저컴퍼니는 지난 3월에 5천만 달러(약 690억 원)의 추가 투자를 받은 터라, 회사 사정이 어려워서는 아닐 것이다. 아크의 사용자 수도 계속 증가세라 지표가 나쁜 것도 아니었다. 그렇다면 아크 브라우저는 왜 돌연 업데이트를 중단한 걸까?
시장에는 오픈AI의 챗GPT, 앤트로픽의 클로드, 구글의 제미나이 같은 대표 LLM을 제외하고도 수많은 언어 모델이 거의 매일 새롭게 나타나고 있으며, 각 모델마다 고유한 기능과 전문성을 갖추고 있습니다. 그러다 보니 비즈니스 애플리케이션을 고집하지 않아도 어떤 서비스를 만들고자 할 때, 그 기능 요구 사항에 따라 사용자 쿼리를 해석할 때는 어떤 특정 LLM을 사용하고, 해당 쿼리에 대한 응답을 작성하는 데는 완전히 다른 LLM을 사용하고자 하는 필요성이 생길 수 있습니다. 이럴 땐 어떻게 프로세스 파이프라인을 구축해야 할까요? 이런 워크 프로세스를 요청하는 시나리오가 바로 ‘랭체인(LangChain)’ 탄생에 아이디어를 제공합니다.
Wafris는 웹 애플리케이션 방화벽을 오픈소스로 제공하고 있습니다. 저희는 다양한 프레임워크를 지원하는데, 그중에서도 Rails 미들웨어 클라이언트를 제공하고 있죠. 처음 v1 클라이언트를 출시했을 때는 여러분의 앱과 함께 로컬 Redis 데이터스토어를 배포해야 했습니다. 하지만 이제 v2 Rails 클라이언트를 출시하면서 SQLite를 백엔드 데이터스토어로 사용하게 되었습니다. 이 글에서는 Redis에서 SQLite로 마이그레이션하기로 결정한 이유, 성능에 대한 고려 사항, 그리고 아키텍처의 변화에 대해 다룰 예정입니다.
피그마(Figma)는 지난 6월 Config 2024에서 AI 기능 업데이트를 발표했습니다. 디자인 생성부터 이미지 처리, 텍스트 수정까지 자동화하여, 디자인 프로세스를 간소화할 다양한 기능을 소개했는데요. 아쉽게도 그중 ‘메이크 디자인(Make Design)’ 서비스를 7월 초 일시 중단했습니다. 그리고 피그마는 최근 ‘메이크 디자인(Make Design)’ 기능을 ‘First Draft’라는 이름으로 다시 공개했습니다. 그러나 피그마가 해당 기능을 재정비하는 사이, 텍스트로 화면을 설계할 수 있는 서비스가 여럿 주목받았는데요. 오늘은 최근 베타 서비스를 시작한 ‘Polymet’을 살펴보고자 합니다.
트랜잭셔널 메시징이란 “메시지를 데이터베이스 트랜잭션의 일부로 발행하는 것”을 의미한다. 애플리케이션 비즈니스 로직에 의해 데이터베이스를 수정하는 작업과 메시지 큐에 메시지를 발행하는 작업, 두 가지 작업을 원자적으로 수행하여 데이터 일관성을 보장하는 것이다. 이 글에서는 트랜잭셔널 메시징을 구현하는 두 가지 패턴을 소개한다. 이어 포스트그레스큐엘(PostgreSQL)을 이용하여 이를 더 단순하게 만드는 방법을 다룬다. 포스트그레스큐엘과 PGMQ를 함께 사용하면 데이터베이스 단일 트랜잭션으로 두 가지 작업을 묶을 수 있다.
저는 다국적 IT 회사에서 10년 가까이 일하면서 다양한 나라의 개발자와 엔지니어를 만났습니다. 오랜 기간 그들과 협업하는 과정에서 개발자의 영어 구사 능력에 자연스레 관심을 가지게 되었습니다. 한편 그 회사에서 일하는 한국인 개발자들과 함께 할 기회도 많았습니다. 그들이 다른 나라 개발자에 비해 뒤지지 않는 뛰어난 개발 실력을 갖추고도, 오로지 영어 때문에 능력을 온전히 평가받지 못하는 모습 역시 보고는 했습니다. 이번 글에서는 개발자가 영어 공부를 해야 하는 이유를 사실과 데이터에 근거해 살펴보고자 합니다. 글의 마지막에는 제 개인적인 견해를 바탕으로 ‘개발자에게 영어가 중요한 또 다른 이유’를 덧붙이고자 합니다.
소프트웨어 산업에는 하루에도 수십 개의 새로운 약어와 개념이 등장합니다. 특히나 빠르게 변하는 AI 기술 같은 경우라면 더욱 말입니다. AI를 제대로 맛보게 해 준 챗GPT와 같은 LLM이 우후죽순으로 등장하더니, 지금은 또 메타의 라마로 대표되는 SLM 혹은 sLLM이라는 게 나오고, AI를 완성시키는 AGI라는 개념도 이해해야 하는데, 또 검색-증강 생성이라며 RAG라는 말이 심심치 않게 들립니다. 배경 개념을 알고 거기에 쉬운 스토리를 붙이면 이해에 어렵지 않습니다. 최소한 이 글을 끝까지 읽으신다면 RAG에 대한 이해는 제가 책임지겠습니다. 자, 시작합니다.
한창 MSA(Microservices Architecture)로의 전환을 진행하는 중이었던 저희 팀은 새로운 branch 전략이 필요한 상황이었습니다. MSA로 전환하면서 기존 정기 배포 방식은 버리고 수시 배포를 하기로 결정했기 때문이었죠. Git-flow, Github-flow, Gitlab-flow를 포함해 여러 branch 전략을 살펴보았지만, 팀 환경에 꼭 맞는 branch 전략은 없었습니다. 그래서 팀의 요구 사항과 환경에 맞는 branch 전략을 직접 만들기로 결정했습니다.
레거시 코드 정리는 모든 개발자에게 피할 수 없는 과제이자 커다란 부담이다. 특히 시간이 지나면서 유지 보수가 어려워진 코드는 점차 기술 부채로 쌓여가며, 프로젝트의 장기적인 성장을 방해하는 요소로 작용하게 된다. 최근 레거시 코드 정리 작업을 맡게 되었고, 최대한 안전하게 코드를 변경할 방법을 찾기 시작했다. 검토할 코드 양이 많아 일정 산정부터 쉽지 않았지만, 동료들에게 조언을 구하며 체계적으로 접근해 큰 문제 없이 마무리할 수 있었다. 내가 얻은 교훈은 레거시 코드를 정리할 때는 무엇보다 코드의 안정성을 최우선으로 해야 한다는 것이다. 오늘은 코드의 안정성을 해치지 않고, 레거시 코드를 정리하는 방법을 이야기해 보고자 한다.
