요즘 OpenClaw가 대세라길래… 저도 한 번 띄워봤습니다. 근데 솔직히 말하면 처음부터 OpenClaw가 목적이었던 건 아니었습니다... 🤔 내가 진짜 하고 싶었던 것제가 원래 하고 싶었던 건 되게 단순했습니다.“외출했을 때, 집에 있는 노트북으로 AI한테 사이드 프로젝트 개발시키기” 이거 하나였습니다. 😅 OpenClaw를 띄우긴 했는데...AWS ECS + FargateDocker로 올리고Claude Code API 연결하고 여기까지는 좋았는데… 👉 비용이 생각보다 부담될 것 같더라구요 물론 막 엄청 비싼 건 아닙니다. Lambda + ECS 조합으로 해서 월 1~2달러 정도 나온다고 하더라구요. 사실 제일 돈이 많이 나올 것 같은 부분은 Cladue API 겠죠...API 기반으로 동작하..

배경현재 개발하고 있는 서비스에서는 사용자가 입력한 ‘주제 + 아이디어 목록’을 기반으로 아이디어를 세부 카테고리로 분류하는 기능이 존재한다. 그리고 이 기능의 특징은 다음과 같다.주제는 고정되어 있지 않다.회의 상황에 따라 매번 달라진다.아이디어 또한 자유 텍스트 형태로 입력된다.예시주제: 서비스 홍보 방안아이디어:인플루언서에게 광고 맡기기지역 커뮤니티에 홍보 글 작성친구들에게 카톡으로 공유 요청SNS 숏폼 영상 제작현재 접근 방식 (프롬프트 기반 분류)시도한 방식LLM(Chat Completion)에 프롬프트로 분류 규칙을 상세하게 설명했다.더보기당신은 '협업 아이디어 정리 도구'의 AI 분류 전문가입니다. User가 제공하는 [분류 기준 주제]에 맞게 [아이디어 목록]을 분석하여, 아이디어를 ..

최근 웹소켓을 사용해 화면 상태를 실시간으로 동기화해야 하는 요구사항이 있었다. 그런데 이게 단순히 채팅처럼 "한 번 데이터를 보내고 끝나는" 형태가 아니라, 그림판처럼 사용자가 작업하는 과정 자체가 실시간으로 보여야 하는 구조였다. 만약 공유 그림판이라면, 사용자가 선을 다 그리고 펜을 떼는 시점에만 서버로 전송한다면 어떻게 될까?→ 다른 사용자는 갑자기 완성된 그림이 뿅 나타나는 것처럼 보이게 된다. 중간 과정이 전혀 보이지 않아 어색하고, 실시간 협업의 느낌도 사라져 버린다. 그래서 처음에는 단순하게 mouseMove 이벤트가 발생할 때마다 웹소켓으로 이벤트를 전송하는 방식으로 구현했다. 하지만 이 방식은 곧 문제가 생겼다.마우스를 조금만 움직여도 엄청나게 많은 이벤트가 전송됨동시에 여러 사용자가 ..

최근 대규모 채팅 서비스를 구축하는 프로젝트에 참여하게 되었고, 실시간 통신을 위해 웹소켓(WebSocket) 을 사용하게 되었다.나는 인프라와 프론트엔드를 담당했는데, 웹소켓은 이번이 처음이어서 직접 공부하고 정리해보는 것이 좋겠다고 생각했다.이번 글에서는 내가 왜 Websocket + SockJS + STOMP를 사용했는지, 어떻게 사용했는지를 중점으로 작성했다.실시간 통신 방식 전반에 대해서는 아래 글에서 이미 다루었기 때문에, 이 글에서는 생략하도록 하겠다.https://yongaricode.tistory.com/7 대규모 채팅 시스템 설계하기 1: 실시간 통신 방식ACC에서 사이드 프로젝트를 시작했다. 주제는 총 4개가 있었는데, 그 중 우리 팀은 대규모 채팅 시스템을 만들기로 했다.📌 채팅 ..

이번주는 주로 백엔드-인프라 연동, 프론트-백엔드 연동을 진행했다.일단 백엔드-인프라 연동을 하면서 예상치 못한 문제들이 많이 있었다...1. SSM으로 Private EC2 접근하기아키텍처를 설계할 때는 별 생각없이 짰는데, 생각해보니 Private EC2에 접근하는 방법이 없었다. 생각해보면 EC2는 Private Subnet에 있고, 사용자는 오직 ALB를 통해 서비스에 접근한다. 즉, 개발자 입장에서 EC2에 직접 접근할 방법이 없었던 것이다.보통이라면 EC2에 탄력적 IP(Elastic IP)를 부여하고 SSH로 접속했겠지만, Private Subnet의 EC2는 외부에서 접근 가능한 퍼블릭 IP를 가지면 안 된다. 그래서 검색해보니, Private Subnet의 EC2에 접근하는 방법은 대표적..

1주차에는 아무것도 정확하게 확정을 내리지 못하고 실시간 통신 공부와 AWS 아키텍처 공부만 하다 끝났다...그래도 2주차에는 최종 아키텍처를 드디어 정했다!이것 때문에 이번 주차에만 인프라 회의를 3번이나 했다... 전체 회의까지하면 4번...ㅜㅜ 지난주에는 정말 막막했는데 그래도 다행히 어느정도 감을 잡은 것 같다!사실 다 쓰자면 너무 주제도 많고, 길어서 우리 팀의 주요 쟁점이었던 API Gateway + Lambda, EC2 + Websocket 중 무엇을 사용할 것이냐를 중심으로 글을 쓰겠다!📍 WebSocket API Gateway + Lambda구성 요소AWS API Gateway (WebSocket 타입)AWS Lambda (메시지 처리)DynamoDB / SQS / Kinesis 등→ ..

졸업 프로젝트로, 사용자의 활동을 기반으로 좋아할 만한 책을 추천해주는 기능을 구현하고자 했다. 👎🏻 초기 접근 방식: 기존 DB 임베딩 + 유사도 검색처음에는 단순한 방법으로 접근했다.기존 백엔드 DB에 저장된 책 정보 전체를 불러와 Vector DB에 임베딩하고, 사용자의 질문을 입력으로 받아 Vector DB에서 유사한 책을 검색해 추천하는 방식이었다. 하지만 결과는 만족스럽지 않았다.책 정보와 리뷰, 사용자 정보가 여러 테이블에 흩어져있어 구조적으로 불안정했고구조화되지 않은 원본 데이터를 그대로 임베딩했기 때문에 유사도 검색 정확도가 낮고, LLM의 hallucination 현상도 심했다.이미 유사도 검색에서 정확도가 낮으니까, LLM을 사용해도 의미가 없었다.🔁 방향 전환: 정보를 구조화한..

ACC에서 사이드 프로젝트를 시작했다. 주제는 총 4개가 있었는데, 그 중 우리 팀은 대규모 채팅 시스템을 만들기로 했다.📌 채팅 시스템 요구 사항일대일 채팅 및 그룹 채팅 지원채팅 이력을 키-값 저장소에 보관평균 1,000명 동시 사용자초당 약 50건의 메시지 처리최대 6개월간 메시지 보관메시지 전송 지연 시간 2초 이내이 외에도 다음과 같은 심화 조건이 있었다:그룹 채팅: 최대 100명까지 참여 가능첨부 파일 전송: 최대 10MB오프라인 메시지 처리: 재접속 시 동기화 지원멀티 디바이스: 동일 계정으로 최대 3대까지 동시 접속 허용우리는 먼저 기본 조건부터 완성하기로 했다.💬 채팅 시스템의 핵심: 실시간 통신일반적인 웹 서비스에서는 HTTP 요청/응답 방식으로 통신하지만, 채팅 서비스처럼 빠른 상..