cherie-ssom

평소 파이썬으로 코드를 작성할 때 보면 상태를 관리하거나 재사용 가능한 로직을 만들어야 하면 반사적으로 Class부터 떠올리게 된다. __init__으로 초기화하고, 속성에 상태를 담고, 메서드로 동작을 정의하는 방식이 조금이나마 익숙하기 때문이다. 그런데 상태나 로직이 그렇게 복잡하지 않은 경우, 클래스를 만드는 것 자체가 과한 것처럼 느껴질 때가 있다. 바로 그럴 때 훨씬 가볍게 같은 걸 해결하는 방법이 있는데 그것이 바로 클로저다.파이썬에서는 함수 역시 그 자체로 하나의 객체이고, 자신이 정의된 환경(스코프)를 기억할 수 있다는 특징이 있다.이 특징을 이용하면 클래스를 따로 만들지 않고도 상태를 가진 함수를 만들 수 있고 이것이 바로 클로저이다.그리고 이 클로저의 개념을 실무에서 가장 널리 활용하는..

지난 글에서 하네스 엔지니어링의 개념과 그 안의 Skill, Hook, Subagent가 각각 무슨 역할을 하는지 살펴보았다. 복습하자면 하네스 엔지니어링은 모델 한 번의 호출을 잘 쓰는 기술이 아니라, 여러 번의 호출과 여러 개의 프로세스를 어떻게 조립할지 설계하는 기술라는 점이다. 이번 글에서는 그 개념을 실제로 조합해서 만든 도구 세 개를 클로드코드에 직접 설치하고 사용하는 방법을 알아보려고 한다. 클로드 코드 최적화가 필요한 이유앞선 하네스 엔지니어링에 대한 글에서도 설명했듯 클로드코드와 같은 하네스를 사용하면서 엔지니어링이 필요한 이유는 사실상 컨텍스트가 사라지고 비용이 증가하는 문제에서 발생한다. 특히 최근에 클로드의 토큰 사용량이 줄었다는 이야기가 돌고 있다. 사실 사용 자체를 많이하는 것도..

처음 LLM을 썼을 때, 22~24년 동안은 프롬프트를 잘 쓰는 게 전부였다. (논문이나 기술 자체는 더 빨리 발전했을지 몰라도 체감하는 수준은 24년 초까진 여전히 프롬프트 엔지니어링이었다..) 지시문을 명확하게 쓰고, 예시문을 붙이고, 형식을 지정하고 하는 작업을 통해서 결과가 좋아졌다. 하지만 이제는 단순히 챗봇으로만 활용하는 것이라 모든 작업을 통달할 수 있는 에이전트로 접근을 하기 시작했고, 그 에이전트는 여러 턴에 걸쳐 파일을 읽고, 도구를 호출하고, 코드를 짜고, 검증까지 하게 되었다. 즉, 한 번의 대화 안에서 처리해야 할 일이 너무 많아지고, 그 과정에서 쌓이는 부산물 (탐색 로그, 중간 결과)이 정작 중요한 판단을 방해하기 시작한다. 그리고 에이전트를 개발하면서 같은 실수들을 계속해서..

요즘 개발자들은 사실 코드를 직접 작성하기보다 시키고 리뷰하는 것이 더욱 일상이 된 요즘인 것 같다.사실 과거에도 개발자들의 시간 절반은 코드를 읽는 데 할애한다고 했지만, 요즘은 짜는 것부터 시키는... 것 같다. 최근에는 클로드코드나 코덱스 두 개를 가장 많이 사용하는 것 같고, 체감상 코덱스를 쓰는 사람이 조금 더 많은가? 싶긴 하다.하지만 나는 회사에서 클로드를 지원해주고 있기 때문에, 클로드코드를 사용하고 있다. 그리고 사실 사용을 하다 보면 단순히 해줘.라고 진행을 하게 되면 뚝딱 잘 만드는 것처럼 보였지만 최종 결과물들을 보면 놓치는 부분도 많았다. 구체적으로는 높은 결합도의 코드 덩어리, 그리고 빠른 컨텍스스트의 소모 등이 있었다. 사실 이러한 문제는 결국 내가 일을 얼마나 잘 시키느냐에 ..

일을 하다 보면 꼭.. 서버가 필요하게 되고 워크스테이션이 따로 없는 환경에서는 항상 가상의 서버가 필요하게 된다. 특히나 탄력적 확장성으로 자동화 설정만으로도 컴퓨터 사양을 쉽게 바꿀 수도 있고, 서버 개수를 수천 대까지 순식간에 늘리고 줄일 수 있다는 장점이 있다. 그리고 OS 종류도 많고 서버를 껐다가 켰다가 할 수 있어서 비용 관리에도 편리하다는 장점이 있다. (단, 탄력적 IP를 받지 않으면 서버를 껐다가 킬 때마다 계속해서 IP 주소가 바뀌긴 한다.) 어쨌든 오늘은 이런 장점을 가진 AWS의 가상 서버인 EC2를 어떻게 사용할 수 있는지에 대해서 정리해보고자 한다. (엄청 쉽다!) 1. EC2 인스턴스 생성우선 AWS 로그인을 진행한 다음에 EC2를 검색하고 왼쪽 상단에 인스턴스 부분을 눌러면..

개발자라면 누구나 사용하고 있는 깃에서는 충돌 현상이 은근 자주 발생한다. 동일한 파일의 동일한 위치를 여러 브랜치에서 서로 다르게 수정을 하고 하나로 합치려고 하다보니 안맞는 경우가 생기게 된다.특히 협업을 통해서 각자 다른 파트를 진행하는 경우 한쪽에서 업데이트가 늦게되면 더욱 자주 발생한다고 한다. (사실 나의 경우는 사내 1인 AI 개발 체제라...누군가 직접 협업할 일은 없었지만), 작업에 따라서 브런치를 따로 만들어서 진행을 하기도하고, 항상 프로덕트는 main으로 고정해두고 업데이트를 다른 브런치에서 하다가 실제 서비스에서 hotfix가 발생하면 다시 돌아가서 메인에서 핫픽스 브런치를 따로 하나 만들어서 작업을 한 후 main으로 다시 올리고 이 수정사항을 다른 브런치에 다시 합쳐주는 작업을..

RAG 기반의 검색 시스템을 만드는 프로젝트를 진행하면서 어떤 벡터 DB를 사용할까, 그 검색 방식은 어떤 것일까를 고민하게 되면서 공부했던 부분들을 정리해보고자 한다. 기본적으로 내가 선택한 DB는 Qdrant였고, 이는 기본적으로 HNSW 방식을 기반으로 벡터 검색을 수행한다. (현재 대부분의 벡터 DB인 Milvus, Pinecone 등은 거의 대부분 HNSW 알고리즘을 핵심 인덱싱 엔진으로 채택하고 있음) 그렇다면 HNSW라는 게 도대체 뭘까? HNSW(Hierarchical Navigable Small World) 알고리즘은 고차원 벡터 데이터에서 근사 최근접 이웃(ANNs, Approximate Nearest Neighbor Search)을 빠르고 정확하게 찾아내기 위해 설계된 대표적인 그래프..

python 패키지 설치 및 관리, 빌드, 배포까지 가능하며 엄청난 속도를 자랑하는 uv에 대해서 작성해보려고 한다. 주로 프로젝트를 진행하면서 라이브러리를 받을 때는 pip만 활용했었는데, 시스템 파이썬의 표준 라이브러리 손상과 pip의 충돌 등의 문제로 인해서 uv라는 것을 처음 접하게 되면서 그 차이점과 활용법에 대해서 정리하고자 한다. 우선 나의 경우 프로젝트를 진행하면서 torch와 transformer, numpy, qdrant 등 다양한 라이브러리가 계속 특정 작업에서 충돌을 일으키고 있어 가상 환경 자체를 다시 설치하고자 했다. 그런데, UnboundLocalError, TypeError: 'ZipInfo' object is not callable과 같은 에러가 발생하게 되었다. 찾아보니..

그동안 프로젝트를 배포할 때는 깃을 활용하긴 했지만 간간히 파일을 그냥 주고받는 형식으로 아주 일차원적이고 좋지 않은 방법들을 활용했었다.1인 개발 체제다 보니 코드를 관리하더라도 여러 브랜치로 나눠서 관리하고 PR 기능을 자주 활용하는 일이 없었고, 배포할 서버 환경 같은 경우에는 항상 다른 팀원이 세팅을 하게 되어서 컨테이너화는 더더욱 해본 적이 없었다. 이게 너무 불편했던 이유는 다른 백엔드 엔지니어분께서 내가 만든 서비스를 위해 항상 파이썬 환경을 세팅을 미리 동일하게 해야했는데, 사실상 컨테이너화라는 것을 활용하면 그 환경까지 한 번에 만들어서 배포할 수 있기 때문에 상당히 효율적이라고 할 수 있다. 이렇듯 기술적인 부분의 업그레이드도 그렇고 배포가 훨씬 효율적이고 용이하게 만들기 위해서 더이..

Groq은 생성형 AI의 추론 속도를 획기적으로 끌어올리기 위해 개발된 초고속 AI 및 반도체 기업이다.오늘은 이 Groq의 기술적 정리와 사용 방법에 대해서 정리하고자 한다. 가장 핵심적으로는 기존 GPU 중심의 연산 한계를 극복하기 위해서 LPU(Language Processing Unit)라는 새로운 방식의 아키텍처를 도입하여 대규모 언어 모델(LLM) 구동 시 엄청나게 빠른 응답 속도를 자랑한다. Meta AI의 Llama-2 70B 모델을 Groq의 LPU로 수행하면 사용자당 초당 최대 300 토큰을 처리할 수 있으며, 이는 기존 클라우드 기반 모델 대비 최소 3배에서 18배 이상 빠른 성능이라고 한다. 결론적으로는 API를 통해서 여러 모델을 활용할 수 있는데, 상당히 빠른 속도와 비교적 ..