통합 피드
모든 커뮤니티의 최신 글을 모아봅니다.
중년개발자
@loxo
Codex 5.6 모델 선택 가이드(Sol, Terra, Luna)
Codex 5.6 모델 선택 가이드 5.6 Terra를 기본값으로 두고, 복잡도와 작업량이 명확할 때만 Sol 또는 Luna로 바꾸는 것이 개발 흐름에서 가장 단순하다. 이름을 기억하는 비유: Sol(태양)은 가장 깊은 판단을 밝히고, Terra(대지)는 일상 개발의 안정된 기반이 되며, Luna(달)는 가벼운 반복 작업을 빠르게 이어 간다. 이는 모델 선택을 돕기 위한 상징적 설명이며, OpenAI의 공식 명명 해설은 아니다. 빠른 선택 | 상황 | 선택 | 이유 | |---|---|---| | 설계 판단, 어려운 버그, 보안/마이그레이션, 큰 변경 | 5.6 Sol | 품질과 깊은 추론을 우선한다. | | 일반 기능 개발, 버그 수정, 테스트, PR 정리 | 5.6 Terra | 성능과 사용 효율의 균형이 좋아 기본값으로 적합하다. | | 작은 반복 작업, 대량 수정, 빠른 피드백 루프 | 5.6 Luna | 속도와 고처리량 작업에 적합하다. | 속도와 토큰 비용 속도는
0
0
2
중년개발자
@loxo
대규모 프로젝트에서 코드를 함부로 바꾸면 안 되는 이유
대규모 코드베이스를 이해한다는 착각, 그리고 LLM이 바꾸는 일하는 방식 대규모 프로젝트 또는 유지 보수 처음 들어가면 이상한 경험을 하게 됩니다. 분명 소스는 열려 있고, 클래스 이름도 읽을 수 있고, 메서드도 따라갈 수 있습니다. 그런데 작은 기능 하나를 고치려고 하면 생각보다 훨씬 많은 질문이 생깁니다. 왜 이 검증은 여기서 하지 않고 세 단계 앞에서 하는가? 동일해 보이는 코드가 왜 모듈마다 조금씩 다른가? 이 조건문은 정말 필요한가? 사용되지 않는 것처럼 보이는 필드는 왜 아무도 지우지 않는가? 더 깔끔한 방법이 있는데 왜 이렇게 복잡하게 구현했는가? 이때 개발자는 흔히 두 가지 착각에 빠집니다. 첫 번째는 “전체 구조를 충분히 이해한 다음 수정해야 한다”는 생각이고, 두 번째는 “기존 코드보다 더 좋은 방식으로 새롭게 구현하면 된다”는 생각입니다. Sean Goedecke의 두 글은 이 두 착각을 동시에 깨뜨립니다. 대규모 코드에서 가장 위험한 실수는 나쁜 코드가 아니라
0
0
2
중년개발자
@loxo
영수증 테스트의 합성데이터 와 Golden Dataset 데이터 및 평가 검증
합성 데이터로 다양한 경우를 넓게 만들고, 실제 영수증으로 만든 Golden Dataset을 최종 평가 기준으로 사용하는 것입니다. 다국어 영수증 AI 검증 데이터 설계 및 샘플 목적 이 문서는 Gemini Vision API를 이용한 다국어 영수증 분석 기능을 검증하기 위한 테스트 데이터 설계 방법과 샘플 데이터를 정의한다. 지원 대상 언어는 다음과 같다. 한국어 영어 일본어 다국어 혼합 영수증 검증 대상 기능은 다음과 같다. 영수증 문서 판별 언어 판별 상호 및 거래정보 추출 상품 항목 추출 수량, 단가, 금액 추출 할인, 세금, 포인트 추출 결제수단 추출 항목 합계 계산 최종 결제금액 검증 불확실한 정보에 대한 보수적 처리 이미지에 없는 정보의 생성 방지 JSON 스키마 준수 여부 검증 관련 용어 2.1 Synthetic Data 실제 데이터의 구조와 특징을 모방하여 인위적으로 생성한 데이터다. 한국어로는 일반적으로 다음과 같이 표현한다. 합성 데이터 인공 생성 데이터 모의
0
0
2
중년개발자
@loxo
다국어 영수증 읽기 프롬프트
다국어 영수증 항목 추출 및 금액 검증 프롬프트 Multilingual Receipt Extraction and Validation Prompt 多言語レシート抽出・金額検証プロンプト <GUARDRAIL> 영수증 이미지에서 실제로 확인되는 정보만 추출한다. 문서에 존재하지 않는 정보는 생성하거나 보완하지 않는다. 근거가 불충분한 경우 추측하지 말고 보수적으로 판단한다. 흐리거나 가려지거나 잘려서 확실하게 판독할 수 없는 값은 null로 반환한다. 영수증의 일반적인 형식이나 상식만으로 누락된 값을 채우지 않는다. 계산 결과를 맞추기 위해 이미지에 인쇄된 값을 변경하지 않는다. 영수증에 없는 세율, 통화, 환율, 수량, 단가, 상품 분류를 임의로 적용하지 않는다. 한국어, 영어, 일본어가 혼합되어 있어도 각 문자의 원문을 가능한 한 그대로 보존한다. 상호명, 지점명, 상품명, 결제수단명 등의 원문을 임의로 번역하거나 로마자로 변환하지 않는다. 서로 다른 영수증의 항목이나 금액을 합치지
0
0
3
중년개발자
@loxo
React는 왜 라이브러리이고 Vue는 왜 프레임워크에 가까운가
React는 왜 라이브러리이고 Vue는 왜 프레임워크에 가까운가 먼저 결론부터 React와 Vue는 모두 화면을 만드는 도구이지만, 개발자를 이끄는 방식이 다릅니다. text React = UI를 만들기 위한 핵심 기능을 제공하는 라이브러리 Vue = UI 개발에 필요한 구조와 규칙을 비교적 통합적으로 제공하는 프레임워크 조금 더 정확히 표현하면 다음과 같습니다. | 구분 | React | Vue | |---|---|---| | 공식적인 성격 | UI 라이브러리 | 프로그레시브 프레임워크 | | 핵심 역할 | 컴포넌트와 화면 렌더링 | 컴포넌트 기반 애플리케이션 개발 | | 상태 관리 | 직접 선택 | 공식 생태계 Pinia 제공 | | 라우팅 | React Router 등 선택 | Vue Router 제공 | | 파일 구조 | 개발자가 결정 | 비교적 정형화 | | 문법 스타일 | JavaScript 중심 JSX | HTML, CSS, JavaScript를 분리한 SFC | |
0
0
7
중년개발자
@loxo
LangGraph 멀티 에이전트 사칙연산 계산기
LangGraph 멀티 에이전트 사칙연산 계산기 이 프로젝트는 LangGraph를 이용해 다음 구조를 구현합니다. 사용자가 사칙연산 수식을 입력 Parser가 숫자와 연산자를 분석 Supervisor가 담당 Agent를 선택 전문 Agent가 계산 Formatter가 최종 결과를 출력 이 예제에서는 사칙연산을 각각 별도의 전문 Agent로 분리합니다. text 덧셈 → Addition Agent 뺄셈 → Subtraction Agent 곱셈 → Multiplication Agent 나눗셈 → Division Agent 잘못된 입력 → Error Agent 프로젝트 구조 먼저 다음과 같은 구조로 프로젝트를 만듭니다. text langgraph-multi-agent-calculator/ ├── app/ │ ├── agents/ │ │ ├── init.py │ │ └── arithmetic_agents.py │ ├── init.py │ ├── formatter.py │ ├──
0
0
6
중년개발자
@loxo
LangChain으로 AI Agent 직접 만들기: 기초부터 실전까지
LangChain으로 AI Agent 직접 만들기: 기초부터 실전까지 목표 이 문서는 LangChain과 LangGraph를 이용해 AI Agent를 직접 개발하려는 개발자를 위한 입문서입니다. 단순히 LLM API를 호출하는 수준을 넘어, Agent가 어떻게 판단하고 Tool을 선택하며 작업을 수행하는지 이해하는 것을 목표로 합니다. Agent란 무엇인가? 일반적인 챗봇은 다음과 같이 동작합니다. text 사용자 질문 │ ▼ LLM │ ▼ 답변 생성 질문을 받으면 LLM이 바로 답변을 생성합니다. 반면 AI Agent는 질문을 받은 뒤 필요한 행동을 스스로 선택합니다. text 사용자 질문 │ ▼ LLM이 상황 판단 │ ├──────────────┐ ▼ ▼ Tool 실행 바로 답변 │ ▼ 실행 결과 분석 │ ▼ 필요하면 다른 Tool 실행 │ ▼ 최종 답변 즉, Agent는 단순히 문장을 생성하는 것이 아니라 상황에 따라 행동(Action)을 선택하는 시스템입니다. 예를 들어
0
0
7
중년개발자
@loxo
폭스바겐은 왜 소프트웨어 개발에 막대한 돈을 쓰고도 실패했는가 - 23조 ~40조 프로젝트
폭스바겐은 왜 소프트웨어 개발에 막대한 돈을 쓰고도 실패했는가 결론부터 말하면 폭스바겐의 실패 원인은 독일 엔지니어가 부족해서도, 개발자가 무능해서도 아니다. 가장 근본적인 원인은 다음과 같다. 폭스바겐은 소프트웨어를 새로운 제품 운영체계로 보지 않고, 자동차 부품처럼 대규모 조직과 예산으로 통합할 수 있다고 판단했다. 즉, 소프트웨어를 잘 만들기 위해 회사를 바꾼 것이 아니라, 기존 자동차 회사의 구조 안에 소프트웨어 조직을 집어넣었다. 폭스바겐은 제조업에서는 세계 최고 수준이었지만, 바로 그 성공 방식이 소프트웨어에서는 오히려 장애물이 됐다. 정말 23조 원을 투자했는가 폭스바겐의 소프트웨어 투자 금액은 집계 범위에 따라 다르게 표현된다. 폭스바겐은 2020년 당시 2025년까지 디지털화에 약 270억 유로를 투자하겠다고 발표했다. 현재 환율로 단순 환산하면 40조 원을 넘을 수 있다. 다만 이 금액에는 차량 소프트웨어뿐 아니라 공장, 판매, 기업 IT 등 광범위한 디지털
0
0
8
중년개발자
@loxo
우리는 이미 특이점의 입구에 서 있는지도 모른다 - 하사비스가 7월 14일
우리는 이미 특이점의 입구에 서 있는지도 모른다 산업혁명보다 10배 큰 충격이 10배 빠른 속도로 올 수 있다고 경고해 온 데미스 하사비스가, 이번에는 그 속도를 제어하기 위한 구체적인 장치를 제안했습니다. 하사비스가 7월 14일 공개한 칼럼의 핵심은 단순합니다. AGI 개발을 멈추자는 것이 아니라, 인간이 통제할 수 있는 속도로 전진하자는 것입니다. AGI란 무엇인가 AGI는 Artificial General Intelligence, 즉 범용 인공지능을 뜻합니다. 현재의 AI는 특정 분야에서 매우 뛰어난 도구에 가깝습니다. 코딩을 돕는 AI 이미지를 만드는 AI 문서를 요약하는 AI 단백질 구조를 분석하는 AI 각각의 능력은 강력하지만, 아직은 사람이 목표를 정하고 필요한 도구를 선택해야 합니다. 반면 AGI는 인간처럼 여러 분야의 지식을 연결하고, 처음 접한 문제를 이해하며, 스스로 해결 방법을 찾아가는 인공지능입니다. 쉽게 비유하면 현재 AI는 각 분야의 뛰어난 전문 기술자에
0
0
7
중년개발자
@loxo
AI 에이전트 시대, IDE 다음은 Orca ADE?
요즘 뜨는 AI 개발 트렌드, Orca ADE가 주목받는 이유 최근 AI 코딩 트렌드는 AI를 얼마나 잘 쓰느냐 에서 여러 AI를 어떻게 함께 관리하느냐로 빠르게 넘어가고 있습니다. Cursor, Claude Code, Codex 같은 AI 코딩 도구를 함께 사용하는 개발자가 늘어나면서, 여러 AI가 동시에 작업하는 환경을 관리하는 것이 새로운 과제가 되고 있습니다. 이런 흐름에서 최근 관심을 받고 있는 프로젝트가 Orca ADE(Agent Development Environment) 입니다. 아직 직접 사용해보진 않았지만, 공식 소개를 보면 기존 IDE와는 조금 다른 방향을 제시합니다. Orca ADE의 핵심 여러 AI 에이전트를 동시에 실행 Git Worktree 기반으로 작업 공간을 분리해 충돌 방지 Claude Code, Codex 등 다양한 CLI 기반 AI 지원 AI별 진행 상황과 변경 사항을 한 화면에서 관리 Diff 기반으로 AI가 만든 코드를 검토 후 반영 즉,
0
0
10
중년개발자
@loxo
AI 용어 및 검색방법 절차
📚 AI는 어떻게 기억을 찾을까? 도서관 탐정으로 배우는 RAG, 임베딩, 벡터, 리트리버 이야기 한 줄 요약 LLM(ChatGPT)은 모든 것을 외우고 있는 것이 아니라, 도서관에서 자료를 찾아와 답하는 똑똑한 사서라고 생각하면 이해가 쉽다. 어느 날... 당신은 엄청나게 큰 도서관의 관장이 되었다. 이 도서관에는 회사 문서 PDF 이메일 소스코드 위키 회의록 매뉴얼 수백만 권이 있다. 그러던 어느 날 누군가 물어본다. "2025년에 우리 회사에서 PostgreSQL 업그레이드 정책이 뭐였죠?" 문제는... 사서가 모든 책을 읽을 시간은 없다. 그렇다면 어떻게 몇 초 안에 답을 줄 수 있을까? 바로 여기서 RAG가 등장한다. RAG(Retrieval-Augmented Generation)란? RAG는 검색(Retrieval) 후 생성(Generation) 이라는 뜻이다. 즉, text 질문 ↓ 관련 문서 검색 ↓ LLM에게 전달 ↓ 답변 생성 ChatGPT가 모르는 회사 문서를
0
0
16
중년개발자
@loxo
PostgreSQL 19 Beta, 개발자가 주목해야 하는 이유
PostgreSQL 19 Beta, 개발자가 주목해야 하는 이유 PostgreSQL 19 Beta를 일반적인 웹 개발자와 백엔드 개발자의 시점에서 쉽게 이해해보자. PostgreSQL 19 Beta란? PostgreSQL은 오픈소스 데이터베이스(DBMS) 중 가장 강력한 제품 중 하나입니다. 현재 많은 서비스들이 카카오 당근 쿠팡 토스 네이버 다양한 스타트업 등에서 PostgreSQL을 사용하고 있습니다. 이번 PostgreSQL 19 Beta는 정식 버전이 출시되기 전에 기능을 미리 공개한 버전입니다. 베타 버전은 실제 서비스보다는 테스트 및 기능 검증을 위한 버전이며, 올해 정식 출시가 예정되어 있습니다. 한 줄 요약 PostgreSQL 19는 "더 빠르고, 더 똑똑하고, 운영하기 쉬운 데이터베이스"를 만드는 데 집중한 버전입니다. 개발자가 가장 체감하는 변화 조회 속도가 더욱 빨라진다. 가장 먼저 체감하는 부분입니다. 예를 들어 sql SELECT * FROM orders
0
0
26