toss·2026년 8월 13일·5분 읽기큐레이션 요약

AI에게 투자정보를 말하게 하기까지

LLM을 활용한 금융 투자 정보 서비스의 핵심은 문장을 잘 생성하는 데 있지 않고, 생성 전후의 근거 선별·검증·관찰 체계를 설계하는 데 있습니다. 토스증권은 이를 위해 세 가지 관문을 제시합니다. 즉, 말할 정보를 고르고, 생성 과정을 통제하며, 결과를 평가 가능한 구조로 만드는 것입니다. ## 금융 투자 정보가 일반 요약보다 어려운 이유 - **적시성**: 시장 상황은 빠르게 변하므로 늦은 설명은 부정확한 정보가 될 수 있습니다. - **정확성**: 기사에 기업명이 등장했다는 사실만으로 해당 기업의 주가 변동을 설명할 수 없습니다. - 자회사 관련 내용인지 - 유사한 이름의 다른 기업인지 - 단순 홍보성 기사인지 구분해야 합니다. - **검증 가능성**: 모든 설명에 근거를 남기고, 결과를 평가하며, 오류 발생 시 재현할 수 있어야 합니다. - **비정상성**: 실적 시즌, 금리 이벤트, 선거, 지정학적 이슈 등에 따라 데이터 분포와 시장 반응이 달라집니다. ## LLM과 에이전트의 불확실성 - LLM은 비정형 텍스트를 자연어로 재구성하는 데 강하지만, 근거가 부족하면 유창한 오답을 생성할 수 있습니다. - 에이전트 구조에서는 다음과 같은 오류가 여러 단계로 전파될 수 있습니다. - 검색 단계에서 잘못된 근거 선택 - 툴 호출 결과의 오해 - 이전 단계의 잘못된 상태를 다음 판단에 사용 - 따라서 투자 정보 서비스에서는 에이전트의 자율성을 무조건 확대하기보다, 필요한 부분은 제한하고 생성 전후의 통제를 강화해야 합니다. ## 첫 번째 관문: 말할 정보 고르기 ### 입수 단계에서 메타데이터 구축 - 뉴스·공시·재무 데이터를 수집할 때 BERT 기반 분류 모델로 미리 분류합니다. - 데이터에는 다음과 같은 정보를 함께 저장합니다. - 산업·시장·콘텐츠 유형 등의 `taxonomy_tags` - 관련 기업인 `related_entities` - 벡터 검색을 위한 `embedding` - 검색 시점에 매번 분류하는 대신, 데이터가 들어올 때부터 검색과 검증에 필요한 구조를 갖춥니다. ### 후보를 넓게 검색한 뒤 단계적으로 축소 - 하이브리드 리트리버로 후보를 넓게 확보해 재현율을 우선합니다. - 이후 다음 절차로 부적절한 정보를 제거합니다. - **중복 제거**: 의미 유사도 기반으로 같은 이벤트를 클러스터링하고 대표 출처만 남깁니다. - **리랭킹·필터링**: 기업 주가 움직임과의 직접적 관련성을 기준으로 순위를 조정합니다. - **설명 유형 분류**: 실적, 가이던스, 기업 행동 등 주요 설명 패턴을 분류합니다. - **실패 사유 분류**: 광고성, 홍보성, 근거 부족 등의 라벨을 붙여 필터링합니다. - 최종 근거는 다음 순서로 배치합니다. - 무슨 일이 있었는가 - 대상 기업과 어떻게 연결되는가 - 주가 방향과 근거의 방향성이 일치하는가 - 근거가 충분하고 최신인가 이 과정은 LLM에 전달할 정보를 압축하고, 비즈니스 요구에 맞게 배치하는 **컨텍스트 엔지니어링**입니다. ## 두 번째 관문: 생성 과정 통제하기 ### 절차형 태스크 그래프 - 검색, 관련성 판단, 중복 제거, 근거 구성, 응답 생성 등을 독립된 단계로 나눕니다. - 각 단계의 입력·출력 스키마를 명확히 정의하면 다음 효과가 있습니다. - 단계별 디버깅과 평가 가능 - 비용과 레이턴시 예측 - 실패 지점 추적 - 단계별 폴백 설계 ### 자율형 에이전트와 절차형 오케스트레이션의 구분 - 탐색 과정 자체가 중요한 업무에는 자율형 에이전트가 적합합니다. - 투자 아이디어 발굴 - 시장 이벤트의 잠재 시나리오 탐색 - 응답 형식과 판단 절차가 명확한 업무에는 절차형 그래프가 유리합니다. - 특정 기업의 주가 등락 원인 설명 - 정해진 근거 검증과 방향성 판단 - 긴 ReAct 루프는 툴 호출, 토큰, 레이턴시와 실행 경로를 늘리므로 제품 요건이 명확할 때는 과도할 수 있습니다. - 이 경우 LLM은 검색과 판단을 모두 자율적으로 수행하기보다, 요약·재작성·근거 기반 설명에 집중시키는 편이 안정적입니다. ### 절차형 그래프의 재사용성 - 절차형 그래프는 단순한 운영 안정화 수단을 넘어 다른 에이전트가 호출할 수 있는 기능 인터페이스가 됩니다. - 예를 들어 다음과 같은 입력과 출력의 도구로 제공할 수 있습니다. - 입력: 종목, 주가 방향, 시간 범위 - 처리: 검색 → 관련성·방향성 판단 → 중복 제거 → 근거 정렬 → 설명 생성 - 출력: 설명, 근거 목록, 추론 유형 등 - 이렇게 구성하면 상위 에이전트가 복잡한 절차를 직접 계획하지 않고 검증된 기능을 재사용할 수 있습니다. ## 세 번째 관문: 평가 가능한 결과 만들기 ### 범주형 루브릭과 구조화된 출력 - 자연어 답변만 생성하지 않고, 답변과 함께 이벤트 유형·실패 사유 등의 분류값도 생성합니다. - 이를 통해 다음 지표를 측정할 수 있습니다. - 관련성 오탐 감소 여부 - 주가 방향성과 근거 방향성의 불일치 비율 - 부적절한 이슈의 통과율 - 정밀도, 재현율, F1-score - 시장 국면이 바뀌면 새로운 실패 유형과 이벤트 유형을 추가할 수 있도록 분류 체계를 유연하게 운영해야 합니다. - 운영 중 발견된 문제, 평가 데이터셋, 프롬프트 버전, 모델 버전을 연결해야 개선 효과를 재현하고 수치로 확인할 수 있습니다. ### 맥락 기반 Few-shot Retrieval - 고정된 Few-shot 예시는 다양한 금융 이벤트와 시장 국면을 충분히 대표하지 못합니다. - 대신 운영 샘플에 다음 정보를 저장합니다. - 원문 - 판단 결과 - 실패 유형 - 유사도 검색용 임베딩 - 새로운 판단 요청이 들어오면 유사한 과거 사례를 검색해 포지티브·네거티브 예시를 함께 프롬프트에 넣습니다. - 성공 사례와 실패 사례를 동시에 제공하면 모델이 판단의 경계와 오류 패턴을 더 잘 파악할 수 있습니다. - 실제 관련성 검증 태스크에서 재현율을 유지하면서 정확도와 정밀도가 개선되었으며, 특히 False Positive 감소에 효과적이었습니다. ## 프롬프트와 모델 학습을 넘어 필요한 것 - 금융 AI 서비스 품질은 프롬프트와 모델만으로 결정되지 않습니다. - 운영을 위해 다음 요소가 함께 필요합니다. - 적절한 임베딩 모델과 리트리빙 전략 - 별도 분류 모델을 활용한 데이터 구조화 - 근거 검증과 실패 유형 관리 - 단계별 추적 및 평가 - 시장 국면 변화에 따른 평가셋·프롬프트 업데이트 투자 정보 서비스에서는 LLM의 자율성을 최대화하기보다, 근거를 선별하고 검증하는 절차를 명확히 설계하는 것이 중요합니다. 검색·분류·검증은 통제 가능한 그래프로 구성하고, LLM은 구조화된 근거를 바탕으로 설명을 생성하도록 제한하는 방식이 안정성과 확장성을 함께 확보하는 현실적인 접근입니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델프롬프트 엔지니어링multi-agent-systemsembeddings+4

toss·2026년 7월 30일·5분 읽기큐레이션 요약

LLM은 똑똑한데, 왜 우리 회사 일은 모를까

LLM이 사내 질문에 정확히 답하려면 단순히 관련 문서를 검색하는 것만으로는 부족하다. 문서·코드·메신저의 최신성, 상충 여부, 실제 구현과의 일치 여부까지 관리하는 신뢰 가능한 컨텍스트 계층이 필요하며, Topic은 이를 구축하기 위한 시스템이다. Topic은 원본을 의미 단위로 정규화하고, 개념과 관계를 연결한 뒤, 변경된 부분만 선택적으로 검증한다. ## 검색만으로는 신뢰를 보장할 수 없는 이유 - 검색은 질문과 관련된 텍스트를 찾아줄 뿐, 해당 정보가 최종 결정인지 판단하지 못한다. - 문서, 미팅, 코드가 서로 다른 정책을 설명할 수 있다. - 메신저 논의가 실제 결론인지, 문서가 오래된 것인지, 코드 변경이 의도된 것인지 추가 판단이 필요하다. - 에이전트가 각자 원문을 검색하면 자료 선택과 충돌 해석이 달라져 답변 일관성이 떨어진다. - Topic은 출처, 관계, 최신성, 충돌 상태를 공통 계층에서 관리해 사람과 LLM이 같은 근거를 사용하도록 한다. ## 신뢰를 구성하는 여섯 가지 축 - **Granularity**: 독립적으로 관리할 수 있는 적절한 크기와 의미의 컨텍스트인지 판단한다. - **Faithfulness**: 컨텍스트의 주장이나 설명이 원문 근거로 뒷받침되는지 확인한다. - **Staleness**: 정보가 현재도 유효한지 검사한다. - **Canonicality**: 서로 다른 이름이나 표현이 같은 대상을 가리키는지 판단한다. - **Consistency**: 여러 출처의 내용이 서로 양립하는지 확인한다. - **Coverage**: 중요한 근거와 관점이 누락되지 않았는지 살핀다. - 모든 문제를 하나의 신뢰도 점수로 합치지 않고, 규칙·LLM·사람 검토를 각각 적합한 판단에 사용한다. ## Ingest: 출처별 의미 단위를 보존한 정규화 Topic은 문서·코드·메신저의 원본을 공통 `ContentUnit`으로 변환한다. - 주요 필드: - `source_type`: document, code, messenger - `unit_type`: 문서 섹션, 메신저 스레드 등 - `source_uri`: 원문으로 돌아가는 주소 - `content_hash`: 변경 감지용 해시 - `created_at_src`, `updated_at_src` - 출처별 식별자와 구조를 담은 `metadata` - 공통 형식은 후속 추출·검증을 일관되게 만든다. - 출처별 구조는 의미 경계와 증거의 원천을 보존하기 위해 유지한다. ### 문서는 제목 계층 단위로 분할 - Markdown 문서를 고정 길이가 아니라 제목 구조에 따라 나눈다. - 상위 제목 경로를 함께 저장해 문장이 어떤 정책이나 기능에 속하는지 보존한다. - 섹션이 지나치게 긴 경우에만 추가 분할한다. - 문서 경로, 원문 URL, 작성·수정 시각도 검증 정보로 남긴다. ### 메신저는 개별 메시지보다 스레드 단위로 처리 - 메시지 하나만 보면 질문인지 결론인지 알기 어렵기 때문에 스레드 전체를 하나의 의미 단위로 삼는다. - 요약 시: - 함수명, 에러 클래스, 파일 경로 등 기술 식별자를 원문 그대로 보존한다. - 질문, 검토한 선택지, 최종 결과를 구분한다. - 확정된 내용과 미결정 내용을 나눈다. - 대화에 없는 합의를 만들어내지 않는다. - 잡담만 있는 스레드는 컨텍스트로 만들지 않는다. ### 코드는 심볼과 비즈니스 동작을 함께 표현 - 파서로 함수·클래스 등 코드 심볼을 추출한다. - 파일 경로, 심볼 종류, 시작·종료 줄, import 관계는 규칙 기반으로 수집한다. - 여러 심볼을 가로지르는 업무 동작은 `CodeSemanticCard`로 묶는다. - semantic card에는 다음 정보가 포함된다. - 업무 대상과 실제 동작 - 도메인 용어와 코드 식별자 - 저장소·파일·줄·심볼 단위의 근거 span - 기준이 된 `commit_sha` - LLM이 만든 카드는 파일·줄이 실제 존재하는지, 설명을 뒷받침하는 span이 있는지 규칙 기반으로 재검사한다. - 최종 검증에서는 카드의 설명만 믿지 않고 현재 코드의 실제 span을 다시 읽는다. ## Extract: 개념과 관계를 원문 근거와 연결 - 각 `ContentUnit`에서 개념 후보와 이를 뒷받침하는 문장을 추출한다. - 함께 등장한 후보를 중심으로 관계를 제안하고, 표현·의미가 유사한 후보의 중복 가능성을 계산한다. - 충분한 근거가 있을 때만 대표 개념으로 통합한다. - 문서·메신저·코드처럼 출처가 다른 unit 사이에도 연결 후보를 만든다. - 개념과 관계에는 원문 위치, 인용, 판단 상태를 함께 저장한다. ### 사내 용어는 사람 검토를 포함 - 띄어쓰기·대소문자 차이는 정규화와 임베딩으로 자동 탐지할 수 있다. - 사내 약어와 별칭은 잘못 합치면 검색·검증 전체를 오염시킬 수 있다. - 애매한 동의어는 즉시 병합하지 않고 `Synonym Proposal`로 등록한다. - 사람이 승인한 별칭만 관리되는 관계로 반영하며, 거절된 후보는 반복 제안하지 않는다. ### 문서와 코드 관계를 유형별로 구분 - `supported_by`: 코드가 문서의 설명을 뒷받침한다. - `contradicted_by`: 코드와 문서의 동작이 충돌한다. - `mentions`: 같은 기능을 언급하지만 일치·충돌 여부를 판단할 근거가 부족하다. - 임베딩으로 후보를 제한한 뒤, 의미 판단이 필요한 후보만 배치 검증한다. - 관계에는 유형뿐 아니라 신뢰도, 판단 이유, 원문 인용, 검증 상태를 기록한다. - 검증 실패나 낮은 신뢰도는 관계를 저장하지 않는다. 관계가 없다는 것은 무관하다는 뜻이 아니라 아직 확인되지 않았다는 의미다. ## Verify: 변경된 부분만 선택적으로 재검증 - 각 unit의 안정적인 식별자와 `content_hash`를 이용해 변경 범위를 추적한다. - 변경되지 않은 unit의 추출·관계 결과는 재사용한다. - 새로 생성되거나 변경된 unit만 다시 처리한다. - 원본이 삭제되면 해당 원본을 참조하던 관계도 정리한다. - 코드 anchor에는 검증 당시의 commit과 span hash를 저장한다. - 현재 코드에서 anchor가 사라졌으면 orphaned 상태로 표시한다. - anchor의 span hash가 같으면 의미 검증을 생략한다. - span hash가 달라졌으면 변경된 코드에 대해 faithfulness를 다시 검증한다. - 해시와 참조 무결성은 규칙 기반으로 검사하고, 실제 의미가 달라진 경우에만 LLM을 호출한다. - 이 방식은 비용을 줄이면서도 변경 원인과 컨텍스트 상태 변화를 추적하게 해준다. ## 실용적인 결론 사내 LLM의 품질을 높이려면 검색 성능만 개선하기보다, 의미 단위·원문 근거·출처 간 관계·최신성·충돌 상태를 함께 관리해야 한다. 특히 자동화는 명확한 변경 감지와 관계 추출에 사용하고, 사내 용어 통합이나 중요한 정책 판단처럼 맥락 의존적인 문제는 근거를 제시한 뒤 사람의 승인을 받는 방식이 안전하다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델human-in-the-loopsemantic-searchknowledge-graph+4

toss·2026년 6월 9일·3분 읽기큐레이션 요약

빠르게 움직이는 조직에서, TAM은 어떻게 문제를 해결할까?

TAM CONNECT 2025는 토스와 카카오페이의 TAM들이 기술과 비즈니스를 연결하는 역할과 운영 문제 해결 방식을 공유한 자리였습니다. 두 회사의 환경은 달랐지만, 알림 노이즈·담당자 의존성·고객사 커뮤니케이션·AI 활용 등 현장에서 겪는 고민은 비슷했습니다. 글은 TAM을 단순 기술지원이 아닌, 복잡한 문제를 구조화하고 서비스와 조직을 개선하는 기술 기반 문제 해결자로 정의합니다. ## TAM의 역할과 해결하는 문제 - 파트너사의 연동 문제를 해결하고 API 도입을 기술적으로 지원합니다. - 장애 발생 시 고객사와 내부 개발·운영 조직을 연결하고 대응을 조율합니다. - 운영 프로세스를 개선하고 반복되는 문제를 자동화합니다. - 서비스와 플랫폼 구조를 더 나은 방향으로 개선하는 데 참여합니다. - 로그 분석, 우선순위 조율, 장애 대응 등 개발자·PM·운영 담당자의 역할을 상황에 따라 수행합니다. - 인증, Face Connect, 금융 플랫폼, 결제, 파트너 API 등 다양한 서비스 영역을 다룹니다. ## 알림 노이즈를 줄이고 문제를 구조화하기 - 모든 알림이 중요한 것은 아니므로 “정말 확인해야 하는 문제는 무엇인가?”를 먼저 정의했습니다. - 불필요한 알림을 줄이고 장애 패턴을 체계화했습니다. - 반복 이슈를 자동으로 탐지하는 시스템을 구축했습니다. - 정산 불일치의 근본 원인을 분석해 단기 대응이 아닌 재발 방지에 집중했습니다. - 장애를 빠르게 처리하는 것을 넘어, 장애가 반복되지 않는 운영 구조를 만드는 데 초점을 맞췄습니다. ## 특정 담당자에게 의존하지 않는 운영 - 운영 지식이 일부 담당자에게 집중되는 문제를 해결하려 했습니다. - 대응 이력을 투명하게 공유하고 구성원 모두가 같은 정보를 확인할 수 있도록 했습니다. - 담당자가 바뀌어도 누구나 신속하게 문제를 해결할 수 있는 협업 구조를 만들었습니다. - n8n 기반 워크플로 자동화로 디스코드 개발자 커뮤니티의 평균 응답 시간을 10분 이내로 유지했습니다. - LLM을 활용해 로그를 분석하고 장애 원인과 해결 가이드를 자동으로 제안했습니다. ## 고객사 경험을 운영 개선으로 연결하기 - 고객사 담당자였던 경험을 바탕으로 고객이 느끼는 답답함과 필요한 커뮤니케이션을 이해했습니다. - PDCA(Plan-Do-Check-Act) 사이클을 활용해 연동 가이드를 지속적으로 개선했습니다. - 반복되는 문의와 커뮤니케이션을 표준화했습니다. - 운영 프로세스를 구조화해 동일한 문제가 되풀이되지 않도록 했습니다. - TAM의 목표를 단순한 문제 해결이 아니라 문제의 재발 방지로 확장했습니다. ## 회사는 달라도 비슷한 운영 고민 - 고객사와 내부 개발팀 사이에서 이해관계와 우선순위를 조율해야 합니다. - 빠르게 변하는 서비스와 복잡해지는 운영 구조에 대응해야 합니다. - 기술과 비즈니스를 동시에 이해해야 하는 역할의 부담이 있습니다. - TAM은 지원 조직이나 단순 운영 인력이 아니라, 여러 조직을 움직이며 문제를 구조화하는 역할입니다. - 결과적으로 TAM은 기술 기반의 Problem Solver에 가깝다는 공감대가 형성됐습니다. ## AI 시대의 TAM - 로그 분석, 장애 원인 추천, 운영 가이드 생성에 AI를 활용할 수 있습니다. - 반복 문의 응답, 이상 탐지, 문서 검색과 요약도 자동화 대상입니다. - AI가 반복 업무를 대신할수록 TAM은 복잡한 문제 해결과 구조적 개선에 집중하게 됩니다. - 조직 간 조율, 고객 경험 설계, 운영 전략 수립처럼 높은 판단력이 필요한 업무의 중요성이 커질 전망입니다. ## 실용적인 시사점 TAM 조직은 반복 문의와 장애를 개인의 경험으로 처리하기보다, 알림 기준·대응 이력·문서·자동화 시스템으로 표준화하는 것이 중요합니다. 또한 AI를 단순 응답 자동화에만 사용하지 말고, 장애 재발 방지와 운영 구조 개선까지 확장해야 합니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델APIincident-managementfintech+4

toss·2026년 6월 8일·4분 읽기큐레이션 요약

Skill 품질 관리를 위한 Rubric 설계와 시스템 구현

Skill은 코딩 에이전트가 개발 과정에서 호출해 사용하는 문서형 도구이므로, 내용이 좋아도 호출되지 않으면 아무런 가치가 없다. 글은 Skill 품질을 6개 섹션 30개 항목으로 평가하고, 형식처럼 결정적으로 검증할 수 있는 항목은 규칙 기반으로, 호출 적합성처럼 의미 판단이 필요한 항목은 LLM 기반으로 분리해야 한다고 주장한다. 특히 BLOCKER가 하나라도 있으면 F 등급으로 처리해 Merge 차단 여부를 단순하게 판단하는 것이 핵심이다. ## Skill 평가가 어려운 이유 - Skill은 컴파일이나 테스트처럼 명확한 통과·실패 기준이 없다. - 결함이 있어도 호출되지 않거나, 호출돼도 효과가 없는 상태로 조용히 남을 수 있다. - 대표적인 문제는 다음 두 가지다. - **트리거 실패**: 호출 조건을 본문에 작성하고 `description`에는 적지 않아 에이전트가 Skill을 호출하지 못하는 문제 - **형식 위반**: `name`이 kebab-case가 아니거나, `name`과 폴더명이 달라 Skill 자체가 인식되지 않는 문제 ## 규칙 기반 검사와 모델 기반 검사의 분리 - 형식·구조처럼 결과가 명확한 항목은 정규식, 카운트, AST 파싱 등 결정적 도구로 검사한다. - 트리거의 의미나 설명의 충분성처럼 문맥 판단이 필요한 항목은 LLM이 평가한다. - 30개 평가 항목은 다음처럼 나뉜다. - 규칙 검사 17개 - 모델 검사 13개 - 역할을 섞으면 문제가 발생한다. - 결정적 결함을 LLM에 맡기면 애매한 상태를 통과시키는 False Negative가 생긴다. - 의미적 판단을 정규식으로 처리하면 표현의 다양성을 놓쳐 False Positive가 늘어난다. - 규칙 검사는 비용이 거의 없어 모든 PR에서 실행할 수 있고, LLM 검사는 규칙 검사를 통과한 Skill에만 적용해 비용을 줄인다. ## 6개 섹션 30개 항목의 평가 구조 - 각 항목은 `BLOCKER`, `MAJOR`, `MINOR` 심각도를 가진다. - 결과는 S부터 F까지 5단계 등급으로 표시한다. - `BLOCKER`가 하나라도 있으면 무조건 F다. - 세부 등급은 작성자에게 상태를 알려주는 신호로 사용하고, 실제 Merge 차단은 F 여부만으로 결정한다. - 이 방식은 등급의 미세한 차이를 두고 불필요하게 논쟁하는 일을 줄인다. ## 타당성: Skill이 정말 필요한가 - Skill을 만들 만한 가치가 있는지 평가한다. - 핵심 질문은 다음과 같다. - 반복적으로 발생하는 작업인가? - 코딩 에이전트가 일반적인 지시만으로 처리하기 어려운가? - Skill로 만들어 제공할 때 지속적인 이점이 있는가? - 일회성 작업이나 에이전트에게 그대로 시켜도 되는 작업은 Skill로 만들 필요가 없다. - 다른 섹션이 이미 만들어진 Skill의 품질을 점검한다면, 타당성 섹션은 애초에 만들지 말았어야 할 Skill을 걸러내는 역할을 한다. - 이 섹션에는 3개 항목이 있으며 모두 MAJOR 수준이다. ## 구조: 형식 오류를 결정적으로 차단 - 구조 섹션은 8개 항목으로 구성되며, 그중 5개가 BLOCKER다. - 예시로 다음을 검사한다. - frontmatter 존재 여부와 YAML 파싱 가능 여부 - `name`의 kebab-case 준수 여부 - `name`과 폴더명 일치 여부 - `description` 길이가 1~1024자 범위인지 여부 - 본문에 허용되지 않은 XML 태그가 포함됐는지 여부 - 구조 검사는 전부 규칙 기반으로 처리하며 LLM을 사용하지 않는다. - frontmatter 자체가 파싱되지 않는 경우에는 즉시 반환하지만, 그 외 오류는 가능한 한 끝까지 검사한다. - 여러 오류를 한 번에 반환해 PR 작성자가 한 번의 피드백으로 모두 수정할 수 있도록 설계했다. - 형식 검사는 정교함보다 매번 동일한 결과를 내고 누락 없이 동작하는 것이 중요하므로, 단순한 구현을 유지한다. ## 트리거: Description에 WHAT과 WHEN을 함께 작성 - 에이전트는 Skill을 호출할지 결정할 때 이름과 `description`만 본다. - Skill 본문은 호출이 결정된 뒤에 읽힌다. - 따라서 본문에만 다음과 같은 조건을 작성하면 호출되지 않는다. - “언제 사용하는가” - “어떤 상황에서 호출하는가” - `Use when ...` - `description`에는 Skill이 무엇인지뿐 아니라 언제 사용해야 하는지도 포함해야 한다. - 트리거 섹션은 6개 항목으로 구성되며, 본문에만 트리거 조건이 있는 경우 BLOCKER로 처리한다. - 처음에는 `when`, `use when`, “할 때”, “사용 시” 같은 표현을 정규식으로 검사했지만 한계가 있었다. - 한국어 표현을 놓치면 잘못된 BLOCKER가 발생한다. - 이모지, 완곡한 표현, 다양한 문장 구조를 모두 규칙으로 포괄하기 어렵다. - 최종적으로는 “Description이 본문의 트리거 조건을 의미적으로 충분히 포함하는가?”를 LLM이 판단하도록 전환했다. ## 운영 방식과 설계 원칙 - BLOCKER 구조 오류는 LLM 평가 전에 차단해 불필요한 모델 호출을 줄인다. - 구조 검사 결과를 오류 목록으로 한 번에 제공해 수정 비용을 낮춘다. - 복잡한 전략 패턴 같은 확장 설계보다 현재 요구사항에 맞는 단순한 검사 코드를 우선한다. - 규칙 기반과 모델 기반의 책임 영역을 명확히 나누는 것이 Rubric 전체의 핵심 원칙이다. 실무에서는 먼저 frontmatter, 이름 규칙, 폴더 구조 같은 형식 검사를 자동화하고, 이를 통과한 Skill에 대해서만 트리거 적합성과 내용 품질을 LLM으로 평가하는 방식을 권장한다. 특히 `description`에는 Skill의 기능(WHAT)과 사용 시점(WHEN)을 모두 명시해야 하며, BLOCKER 하나만으로도 배포나 Merge를 막도록 운영하면 호출되지 않는 Skill을 조기에 줄일 수 있다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델Pythonyamlcoding-agents+3

toss·2026년 6월 5일·5분 읽기큐레이션 요약

토스팀이 AI 파도를 마주하는 방법: AI Surf Day

토스는 빠르게 변하는 AI를 따라잡기 위해 개인의 학습에만 의존하지 않고, 업무 시간과 조직 문화를 재설계하는 ‘AI Surf Day’를 운영했다. 매주 금요일을 AI 실험과 공유의 시간으로 정해 직군과 숙련도에 관계없이 누구나 AI를 업무에 적용하도록 지원했다. 이 경험은 특정 프로그램보다 자유롭게 시도하고 실패와 성과를 공유하는 문화, 그리고 이를 이끄는 사람들이 AI 전환의 핵심임을 보여준다. ## AI Surf Day의 배경과 목적 - AI 기술이 빠르게 발전하면서 개발자뿐 아니라 PO, 디자이너, 스태프 등 모든 직군에서 AI 활용에 대한 관심이 커졌다. - 반면 비개발 직군을 중심으로 다음과 같은 어려움도 나타났다. - 수많은 AI 정보 중 실제 업무에 유용한 것을 선별하기 어려움 - 새로운 기술을 학습할 별도 시간을 내기 어려움 - AI를 잘 활용하는 사람과 그렇지 못한 사람 사이의 격차와 불안 - 토스는 월요일부터 목요일까지 본업에 집중하고, 매주 금요일은 AI를 실험하고 업무에 적용하는 ‘AI Surf Day’로 운영했다. - 목표는 단순히 AI 도구 사용법을 익히는 것이 아니라, 토스 전체가 AI 기반으로 일하는 문화를 만드는 것이었다. - “파도를 멈출 수는 없지만 서핑하는 방법은 배울 수 있다”는 비유처럼, 예측하기 어려운 AI 변화에 조직적으로 대응하려는 취지를 담았다. ## AI Surf Club: 자율적인 실험과 학습 - 팀원 누구나 AI 관련 주제로 모임을 만들고 참여할 수 있는 핵심 프로그램이다. - 시작과 함께 약 200개의 클럽이 만들어질 만큼 높은 참여가 나타났다. - 대표적인 사례는 다음과 같다. - **AI 안티패턴 스터디** - AI 활용이 잘되지 않았던 시행착오와 실패 사례를 공유했다. - 프로젝트 방향을 잡고 실수를 줄이는 데 도움이 되는 ‘시행착오 방지 가이드’로 내용을 정리했다. - **LLM Wiki 활용법** - 업무 지식이 여러 곳에 흩어진 문제를 해결하기 위해 조직 공동의 지식 자산 구축을 논의했다. - 데이터 엔지니어, 머신러닝 엔지니어, 비즈니스 담당자 등 다양한 직군이 참여해 관점을 넓혔다. - **터미널 초보자를 위한 0단계 모임** - 에이전트 도구 설치나 터미널 사용처럼 기본적인 기술 장벽을 해결했다. - 초보적인 질문도 부담 없이 할 수 있는 안전한 학습 공간을 제공했다. - **금융소비자보호 업무의 AI 전환** - “상담 과정에서 미리 민원을 발견하고 싶다”는 요구에서 출발해 한 달 만에 대외민원 모니터링 포털을 개발했다. - 민원 회신문 초안 작성과 민원 분류 자동화 등 추가 결과물도 만들어냈다. - 가장 큰 성과는 구성원들이 “우리도 AI로 해볼 수 있다”는 자신감을 얻은 점이었다. - **비즈니스 마케팅 팀의 AI 워크숍** - Builder, Curator, Operator, Scouter로 역할을 나누어 AI 도구, 사례, 자동화 결과물을 만들고 공유했다. - 개인의 실험을 다른 팀원이 복제하거나 업무에 적용할 수 있는 자산으로 남기는 데 초점을 맞췄다. ## AI Surf Weekly: 사례와 아이디어의 확산 - 사내 AI 활용 우수 사례, 레슨런, 최신 AI 인사이트를 공유하는 시간이다. - 구체적인 도구 사용법을 일방적으로 교육하기보다, 실제 사례를 보여주고 새로운 아이디어를 떠올리게 하는 방식을 택했다. - 서로 다른 조직의 유사한 문제를 가진 구성원을 연결해 단시간에 결과물을 만들도록 돕기도 했다. - 영업팀의 요구와 유사한 도구를 만든 인사팀 구성원을 연결해 빠르게 업무 도구를 개발했다. - 디자인 자동화에 어려움을 겪던 마케팅 담당자를 디자인 조직의 경험자와 연결해 하루 만에 문제를 해결했다. - 잘 쓰는 사람과 실제 결과물을 공유하면, 구성원들이 자신의 업무에 맞게 응용하면서 새로운 활용 사례가 파생된다는 점을 확인했다. ## AI Surf Evangelist: 현업 중심의 전파 체계 - 조직에서 AI를 잘 활용한다는 것은 개인이 도구를 능숙하게 쓰는 것이 아니라, 기존 업무 흐름을 AI 기반으로 재설계하는 것이다. - 이를 가장 잘 이끌 사람은 실제 업무와 팀의 문제를 잘 아는 현업 구성원이라고 판단했다. - 토스는 AI 기술 전문가보다 다음과 같은 구성원을 에반젤리스트로 선발했다. - 유용한 정보를 발견하면 팀에 공유하는 사람 - 동료가 AI 활용 중 막혔을 때 함께 해결하는 사람 - AI 도입과 전파에 적극적인 사람 - 공개 추천을 통해 이미 비공식적으로 이런 역할을 수행하던 사람을 발굴했고, 총 142명이 선정됐다. - 주요 미션은 다음과 같다. - 3개월 동안 조직 내 AI 활용 사례를 공유 채널에 제보 - 팀 대상 밋업이나 워크숍을 최소 1회 개최 - 유용한 사례와 인사이트를 조직에 전파 - 문화팀은 워크숍 템플릿과 퍼실리테이션을 지원해 각 팀이 ‘업무를 AI 기반으로 재설계한다면?’을 주제로 실험하도록 도왔다. ## OpenAI 협업과 에이전틱 워크플로우 - 5월에는 OpenAI와 협업해 개발자용 Codex 세션, 비개발자용 ChatGPT Agent 자동화 세션, 미니 해커톤을 진행했다. - **iOS Simulator 자동 검증 에이전트** - Codex가 기능 구현, 빌드, 로그인, 입력, 테스트, 수정 과정을 직접 수행했다. - 계획부터 검증 영상 생성까지의 전체 루프를 자동화했다. - **토스플레이스 메뉴 분류 어드민** - AI 에이전트가 매일 상품 데이터를 조회하고 사전 정의된 기준에 따라 1차 분류한다. - 담당자는 알림 링크를 통해 결과를 확인하고 확정 또는 반려한다. - 단순 반복 업무를 재사용 가능한 Agentic Workflow로 전환한 사례다. ## 프로그램보다 중요한 문화와 사람 - AI Surf Day는 6월까지 운영될 예정이지만, 이후 동일한 형식으로 지속될지는 정해지지 않았다. - 글에서 중요하게 본 성과는 특정 프로그램 자체가 아니라 다음과 같은 변화다. - AI를 실험할 수 있도록 공식적인 시간대를 마련함 - 성공뿐 아니라 실패와 시행착오도 공유함 - 서로 다른 팀의 사례와 사람을 연결함 - 워크숍과 결과물이 실제 업무 방식의 변화로 이어짐 - AI 전환을 추진하는 조직이라면 별도 학습 시간을 보장하고, 현업의 자발적 실험을 지원하며, 결과물을 조직 자산으로 공유하는 구조부터 만드는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AIAI 에이전트자동화+4

toss·2026년 3월 20일원문

LLM을 이용한 서비스 취약점 분석 자동화 #2 (새 탭에서 열림)

AI 기술의 비약적인 발전으로 취약점 분석 자동화가 새로운 국면을 맞이한 가운데, 대규모 소스코드를 효율적으로 분석하기 위한 구체적인 기술적 구현 방법과 보안 관점의 변화가 필요합니다. 본 글은 MCP(Model Context Protocol)를 통한 정밀한 코드 탐색과 SAST 도구를 활용한 분석 후보군 추출을 결합하여 분석의 일관성과 정확도를 높인 사례를 제시합니다. 결과적으로 AI가 단순한 보조 도구를 넘어 복합적인 추론을 수행하는 능동적인 보안 분석 주체로 진화하고 있음을 강조합니다. **MCP를 활용한 효율적인 소스코드 탐색** * 기존의 단순 패턴 매칭 방식은 불필요한 탐색으로 토큰을 낭비하거나 정확한 정의를 찾지 못하는 한계가 있어, 이를 개선하기 위해 ctags와 tree-sitter를 결합한 MCP 서버를 구축했습니다. * AI에게 IDE의 'Go to Definition'과 유사한 능력을 부여하기 위해 `find_references`(참조 검색), `read_definition`(심볼 정의 및 함수 범위 감지), `read_source`(주변 코드 읽기), `get_project_structure`(전체 구조 파악) 등 4가지 핵심 도구를 구현했습니다. * 이 시스템은 AI가 원격 서버 환경에서도 프로젝트의 전체적인 청사진을 이해하고, 분석이 필요한 코드의 맥락을 정확하게 짚어낼 수 있도록 돕습니다. **SAST와 AI의 결합을 통한 분석 범위 확장** * 분석의 일관성을 확보하기 위해 SAST(Semgrep 등)를 취약점 탐지용이 아닌, AI가 반드시 검토해야 할 '모든 입력 경로(Taint Path)'를 추출하는 보조 도구로 활용했습니다. * Spring 프레임워크의 @RequestParam, @RequestBody 등 모든 입력 지점(Source)에서 함수 호출(Sink)까지의 도달 경로를 추출하는 규칙을 설정하여 분석 후보군을 빠짐없이 확보했습니다. * 취약점 유무를 판단하기 어려운 복잡한 비즈니스 로직이나 보안 필터링의 유효성을 AI가 직접 검토하게 함으로써, 기존 정적 분석 도구의 한계를 AI의 문맥 이해 능력으로 보완했습니다. **체계적인 추론 과정(CoT) 설계** * AI가 분석을 시작하기 전 '계획 수립 - 도구 실행 - 검증 - 결과 분석'의 단계를 거치도록 Chain of Thought(CoT) 방식을 적용하여 분석 결과의 신뢰도를 높였습니다. * 단순히 코드를 단편적으로 보는 것이 아니라, MCP 도구를 활용해 연관된 코드와 비즈니스 로직을 충분히 탐색한 후 최종 판단을 내리도록 설계하여 오탐(False Positive)을 획기적으로 줄였습니다. * 이러한 구조화된 추론 과정을 통해 AI는 10개의 취약점 중 일부만 찾는 불완전한 분석에서 벗어나, 정해진 후보군 전체를 일관성 있게 전수 조사할 수 있게 되었습니다. **보안 패러다임의 전환** 현재의 AI는 단순한 챗봇을 넘어 보안 전문가의 사고 과정을 모사하는 에이전트로 진화하고 있습니다. 보안 담당자는 이제 AI에게 효율적인 코드 탐색 도구(MCP)를 제공하고 정밀한 분석 경로(SAST 활용)를 설계해 주는 'AI 오케스트레이터'로서의 역할을 고민해야 합니다. AI가 가진 강력한 추론 능력을 신뢰하되, 이를 올바른 방향으로 이끌 수 있는 환경을 구축하는 것이 보안 자동화의 핵심입니다.

대규모 언어 모델데이터베이스 설계Kotlinai-security+4

toss·2026년 3월 17일원문

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 개발은 명시적 코딩(1.0)과 데이터 기반 학습(2.0)을 거쳐, 자연어 프롬프트가 프로그램이 되는 '소프트웨어 3.0' 시대로 진입하고 있습니다. 하지만 강력한 LLM 모델이라도 실질적인 업무를 수행하기 위해서는 모델의 능력을 제어하고 연결하는 '하네스(Harness)'라는 도구적 환경이 필수적이며, 이를 설계하는 데 있어 기존 소프트웨어 1.0의 계층형 아키텍처 원칙은 여전히 유효한 가이드가 됩니다. 결국 미래의 개발은 전통적인 설계 원칙을 유지하면서도, 에이전트가 인간과 소통하며 의사결정을 내리는 'Human-in-the-Loop(HITL)' 모델을 결합하는 방향으로 진화할 것입니다. **소프트웨어 3.0과 하네스의 필요성** - 안드레 카파시는 소프트웨어 3.0을 자연어로 된 프롬프트가 코드를 대신하는 시대로 정의하며, 이것이 이전 세대의 패러다임을 흡수할 것이라고 예측했습니다. - 하지만 LLM 단독으로는 코드베이스를 읽거나 데이터베이스에 접근하는 등의 실질적인 작업을 수행할 수 없다는 한계가 있습니다. - 이를 해결하기 위해 등장한 것이 '하네스(Harness)' 개념으로, 앤스로픽의 'Claude Code'처럼 모델이 도구(Skills)를 사용하고 외부와 통신하며 에이전트로 동작하게 만드는 실행 환경을 의미합니다. **계층형 아키텍처로 매핑한 에이전트 구조** - **슬래시 커맨드(Slash Command) = 컨트롤러(Controller):** `/review`, `/refactor`와 같은 명령어는 사용자 요청을 받아 적절한 워크플로우를 실행하는 서비스의 진입점 역할을 합니다. - **서브 에이전트(Sub-agent) = 서비스 계층(Service Layer):** 여러 기술(Skills)을 조합해 특정 비즈니스 로직을 완수하며, 독립적인 컨텍스트를 유지하는 단위입니다. - **기술(Skills) = 도메인 컴포넌트:** 단일 책임 원칙(SRP)에 따라 코드 리뷰, 테스트 생성 등 명확한 한 가지 기능만 수행하는 가장 작은 단위의 기능 모듈입니다. - **MCP(Model Context Protocol) = 인프라/어댑터:** 외부 API나 DB와의 연결을 추상화하여 내부 로직이 외부 시스템의 구현 상세를 몰라도 동작하게 돕습니다. - **CLAUDE.md = 프로젝트 헌장:** 기술 스택, 코딩 컨벤션 등 프로젝트의 변하지 않는 근간 원칙을 정의하며 시스템의 안정성을 보장합니다. **에이전트 설계에서 경계해야 할 안티패턴** - **God Sub-agent:** 하나의 서브 에이전트가 너무 많은 역할과 권한을 가지게 되면 관리 효율이 떨어지므로 적절한 분리가 필요합니다. - **기능 편애(Feature Envy):** 특정 기술이 자신의 역할 범위를 벗어나 다른 기술의 데이터나 프롬프트에 과도하게 의존하는 경우입니다. - **프롬프트 중복:** 동일한 프롬프트 내용이 여러 기술에 중복되어 포함될 경우 유지보수가 어려워지므로 공통화가 필요합니다. **에이전트만의 핵심 차별점: 질문하는 능력(HITL)** - 전통적인 소프트웨어는 예외 상황에서 미리 정의된 에러를 던지지만, 3.0 시대의 에이전트는 `UserAskQuestion` 기술을 통해 모호한 상황에서 사용자에게 직접 질문을 던질 수 있습니다. - 에이전트는 삭제나 배포처럼 되돌리기 어려운 작업, 혹은 여러 대안 중 선택이 필요한 고위험 상황에서 인간의 판단을 구하는 'Human-in-the-Loop' 구조를 가집니다. - 반면, 관습적으로 처리 가능한 일이나 안전한 반복 작업은 질문 없이 자율적으로 수행함으로써 효율성과 안정성 사이의 균형을 맞춥니다. 소프트웨어 3.0 시대에 적응하기 위해서는 모든 로직을 명시적으로 작성하려는 강박에서 벗어나야 합니다. 대신 계층 분리, 추상화, 단일 책임 원칙과 같은 전통적인 소프트웨어 공학의 정수를 에이전트 설계에 투영하여, LLM을 단순한 자동완성 도구가 아닌 신뢰할 수 있는 협력자로 구축하는 능력이 핵심 경쟁력이 될 것입니다.

대규모 언어 모델쿠버네티스ReactTypeScript+4

toss·2026년 2월 26일원문

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 (새 탭에서 열림)

현재 많은 개발팀이 LLM을 도입하고 있지만, 실제 생산성은 엔지니어 개개인의 'LLM 리터러시'에 따라 극심한 격차를 보이고 있습니다. 이러한 '각자도생'의 한계를 극복하기 위해서는 LLM을 개인의 도구가 아닌 팀 차원의 시스템으로 편입시켜 전체적인 생산성의 저점(Floor)을 높이는 전략이 필요합니다. Claude Code와 같은 생태계를 활용해 팀의 노하우를 '실행 가능한 지식(Executable SSOT)'으로 자산화하는 것이 Software 3.0 시대의 핵심 경쟁력이 될 것입니다. **컨텍스트 엔지니어링과 LLM 리터러시의 격차** * 단순 질문을 반복하는 방식과 작업 전 팀의 가이드라인, 린트 규칙, 코드 패턴 등 '컨텍스트'를 먼저 주입하는 방식은 결과물에서 큰 차이를 만듭니다. * 이러한 생산성 격차는 코딩 실력이 아닌 LLM을 제어하는 노하우의 차이이며, 이를 개인의 센스에만 맡기는 것은 조직적 손실입니다. * 팀 전체의 역량을 상향 평준화하기 위해서는 누구나 최적의 맥락 위에서 작업할 수 있도록 돕는 시스템적 장치(Harness)가 필요합니다. **Claude Code와 마찰 없는 워크플로우 이식** * 브라우저 기반 챗봇으로 코드를 복사·붙여넣기 하는 과정에서 발생하는 문맥 교환(Context Switching) 비용을 최소화해야 합니다. * Claude Code가 제공하는 TUI(Terminal User Interface) 환경은 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 매끄러운 경험을 제공합니다. * 이러한 낮은 진입 장벽은 설계된 AI 워크플로우를 팀원들에게 저항감 없이 전파할 수 있는 기반이 됩니다. **실행 가능한 진실의 원천(Executable SSOT)** * 기존의 위키나 노션 문서는 작성 즉시 낡은 정보가 되지만, 플러그인 형태의 지식은 사람이 읽는 매뉴얼인 동시에 LLM이 즉시 실행하는 시스템 프롬프트가 됩니다. * RAG(검색 증강 생성) 방식은 내부 로직의 불투명성으로 인해 어떤 컨텍스트가 주입될지 예측하기 어렵다는 단점이 있습니다. * 반면 플러그인 방식은 명시적인 코드로서 개발자가 주입되는 맥락을 100% 통제할 수 있어 높은 예측 가능성과 신뢰성을 제공합니다. **계층화된 아키텍처를 통한 거버넌스와 전파** * 지식을 전사 공통(Global), 팀/비즈니스 도메인(Domain), 특정 프로젝트(Local)의 3단계 레이어로 계층화하여 관리함으로써 지식의 파편화를 방지합니다. * `/new-feature`와 같은 슬래시 커맨드를 통해 숙련된 엔지니어의 노하우(이슈 발급, 브랜치 생성, 구현 계획 수립 등)를 모든 팀원에게 즉시 배포할 수 있습니다. * 단순한 린터를 넘어, 메인 브랜치 커밋 시도를 감지하고 정책에 맞는 브랜치 생성을 가이드하는 등 AI 에이전트 기반의 강력한 거버넌스 구현이 가능합니다. **엔지니어링의 본질: 플랫폼 엔지니어링과 데이터 플라이휠** * Software 1.0 시대에 공통 라이브러리로 중복 작업을 줄였듯, Software 3.0에서는 AI 워크플로우 플러그인을 통해 팀의 생산성을 최적화해야 합니다. * 규격화된 플러그인을 통해 축적된 양질의 데이터는 향후 도메인 특화 모델(sLLM)을 파인튜닝하고 평가하는 기반이 됩니다. * 사용자가 많아질수록 데이터가 쌓이고 모델이 정교해지는 '데이터 플라이휠' 구조를 구축하는 것이 AI-Native 조직의 최종 목표입니다. 이제 LLM 활용 능력은 개인의 역량을 넘어 팀이 설계하고 배포해야 할 시스템의 영역입니다. Claude Code의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.

대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜RAG+4

toss·2026년 1월 25일원문

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 3.0 시대는 자연어 프롬프트가 프로그램이 되는 시대이지만, LLM이 실질적인 업무를 수행하기 위해서는 이를 제어하고 연결하는 '하네스(Harness)'가 필수적입니다. Claude Code와 같은 최신 에이전트 도구들은 이러한 하네스의 역할을 하며, 그 내부 구조는 놀랍게도 우리가 익히 알고 있는 소프트웨어 1.0의 레이어드 아키텍처 원칙을 그대로 따르고 있습니다. 결국 좋은 에이전트를 설계하는 힘은 기존의 객체 지향 설계와 추상화 원칙을 얼마나 잘 적용하느냐에 달려 있습니다. **소프트웨어 1.0의 눈으로 본 에이전트 구조** * **Slash Command (Controller):** `/review`, `/refactor`와 같은 명령어는 사용자 요청의 진입점 역할을 하며, 특정 워크플로우를 트리거하는 컨트롤러와 유사합니다. * **Sub-agent (Service Layer):** 여러 기술(Skill)을 조합하여 복잡한 비즈니스 로직을 완성하며, 독립된 컨텍스트를 가져 서비스 계층이나 별도의 스레드처럼 동작합니다. * **Skills (Domain Component):** 단일 책임 원칙(SRP)에 따라 "코드 리뷰", "테스트 생성" 등 명확한 한 가지 역할만 수행하는 기능 단위입니다. * **MCP (Infrastructure/Adapter):** 외부 API나 데이터베이스와의 연결을 담당하며, 내부 로직이 외부 환경에 의존하지 않도록 추상화된 어댑터 역할을 합니다. * **CLAUDE.md (Configuration):** 프로젝트의 기술 스택과 코딩 컨벤션을 담는 파일로, `package.json`이나 `pom.xml`처럼 프로젝트의 고정된 원칙을 정의합니다. **에이전트 설계의 핵심: 질문과 판단의 위임** * **Exception에서 Question으로:** 전통적인 코드에서는 모든 예외를 미리 정의해야 하지만, 에이전트는 불확실한 상황에서 사용자에게 질문(HITL)을 던져 판단을 위임할 수 있습니다. * **질문의 기준:** 삭제나 배포처럼 되돌리기 어려운 작업이나 리스크가 큰 결정은 사용자에게 묻고, 안전하게 반복 가능한 작업은 에이전트가 스스로 처리하도록 설계해야 합니다. * **안티패턴의 답습:** 에이전트 설계에서도 특정 객체가 너무 많은 일을 하는 'God Agent'나 불필요하게 복잡한 호출 구조는 유지보수성을 떨어뜨리는 코드 스멜이 됩니다. **토큰 최적화와 효율적인 설계 전략** * **토큰은 곧 메모리:** 컨텍스트 윈도우(Context Window)를 작업 메모리로 인식해야 하며, 무분별한 파일 읽기나 복잡한 지침은 토큰 폭발(OOM과 유사)을 야기합니다. * **결정적 로직의 분리:** 브랜치 명명 규칙과 같이 판단이 필요 없는 단순 반복 작업은 프롬프트가 아닌 별도의 스크립트로 작성하여 실행하게 함으로써 토큰 소모를 줄여야 합니다. * **점진적 노출(Progressive Disclosure):** 수많은 Skill이 시스템 프롬프트를 점유하지 않도록, 진입점만 제공하고 세부 지식은 필요할 때 참조하게 만드는 '디미터의 법칙'을 적용해야 합니다. 소프트웨어 3.0 시대에도 개발자가 쌓아온 레이어 분리, 추상화, 인터페이스 설계 역량은 여전히 유효합니다. 도구는 LLM으로 바뀌었지만 응집도와 결합도를 고려한 좋은 설계 원칙을 유지할 때, 비로소 실무에서 신뢰할 수 있는 강력한 에이전트를 구축할 수 있습니다.

대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜claude-code+4

toss·2026년 1월 21일원문

개발자는 AI에게 대체될 것인가 (새 탭에서 열림)

현재의 AI 열풍은 막대한 자본이 투입된 버블의 성격을 띠고 있지만, 장기적으로는 개발자의 업무를 근본적으로 재정의하는 도구로 자리 잡을 것입니다. 개발자는 단순히 코드를 생산하는 역할에서 벗어나, 어떤 업무를 AI에게 '추상화(위임)'하고 어떤 핵심 판단력을 유지할지 결정하는 설계자이자 디렉터의 역량을 요구받게 됩니다. 결국 AI 시대의 생존은 기술적 위임의 경계를 설정하고 시스템의 복잡성을 관리하는 '추상화 능력'에 달려 있습니다. ## AI 하이프와 경제적 불균형의 실체 * **아마라의 법칙과 버블:** 기술의 효과는 단기적으로 과대평가되는 경향이 있으며, 현재 AI 시장은 투자 대비 매출 비율이 16:1(설비투자 5,600억 달러 대비 매출 350억 달러)에 달할 정도로 극심한 불균형 상태입니다. * **실질 수익의 부재:** 생성형 AI 도입 프로젝트의 약 95%가 실패하거나 뚜렷한 효율 개선을 보이지 못하고 있으며, 빅테크의 매출조차 상당 부분 내부 거래에 의존하고 있는 실정입니다. * **인력 감축의 역설:** 현재의 개발자 감원은 AI가 업무를 대체했기 때문이라기보다, 막대한 AI 투자 비용을 충당하기 위한 기업의 비용 절감 전략에서 기인한 측면이 큽니다. ## 제번스 패러독스와 직무의 재정의 * **수요의 폭발:** 에어컨 보급률이 높아질수록 관련 산업이 커지듯, AI로 코딩의 문턱이 낮아지면 소프트웨어에 대한 전체 수요와 활용처는 오히려 기하급수적으로 늘어날 것입니다. * **도구로서의 AI:** 과거 게임 엔진이 소규모 팀에게 프로급 역량을 부여했듯, AI는 개발자를 보조하는 강력한 '파워 툴'이 되어 상위 실력자의 생산성을 극대화합니다. * **역할의 변화:** 개발자의 정체성은 코드 작성자에서 '코드 크리에이티브 디렉터'로 변모하며, 시스템 설계, 에이전트 지휘, 결과물 검증이 업무의 중심이 됩니다. ## 위임의 사분면과 추상화의 본질 * **위임의 기준:** '위임하기 쉬운가(기술적 난이도)'는 모델의 발전에 따라 계속 변하는 일시적인 경계일 뿐이며, 중요한 것은 '위임해야 하는가(책임과 판단)'라는 가치 판단의 축입니다. * **추상화로서의 위임:** AI에게 업무를 맡기는 것은 프로그래밍의 '추상화'와 같습니다. 이는 세부 사항을 숨기고 더 이상 신경 쓰지 않겠다는 선언이며, 복잡성을 미래로 이동시키는 레버리지 역할을 합니다. * **유형별 위임 전략:** 단순 CRUD나 보일러플레이트 코드, 테스트 케이스 등 잘 정의된 문제는 AI에게 맡기되, 아키텍처 결정이나 보안 정책, 법규 대응처럼 인간의 판단이 필수적인 영역은 분리해야 합니다. ## 잘못된 추상화와 미래의 리스크 * **추상화의 붕괴:** 트래픽 급증, 법률 개정(GDPR 등), 제로데이 보안 취약점 같은 예외 상황이 발생하면 AI에게 위임했던 '추상화된 업무'가 한꺼번에 무너질 수 있습니다. * **시니어의 역할:** 시스템의 근본이 흔들릴 때 이를 해결할 수 있는 능력은 결국 풍부한 경험을 가진 시니어 개발자의 몫이며, AI 결과물을 맹목적으로 수용할 경우 추상화가 없는 것보다 더 큰 재앙을 초래할 수 있습니다. * **지속 가능한 리팩토링:** 개발자는 AI에게 어떤 컨텍스트를 제공하고 어떤 부분을 직접 통제할지 업무 프로세스를 끊임없이 리팩토링하며 '좋은 추상화'를 구축해야 합니다. 성공적인 AI 활용을 위해서는 AI를 단순한 대체재가 아닌, 복잡성을 관리하는 추상화 도구로 바라봐야 합니다. 기술 발전 속도에 일희일비하기보다, 기술이 해결할 수 없는 '비즈니스 임팩트'와 '시스템의 안정성'에 대한 인간의 판단력을 고도화하는 것이 AI 시대 개발자의 핵심 경쟁력이 될 것입니다.

대규모 언어 모델AI생성형 AI프롬프트 엔지니어링+3

toss·2025년 12월 23일원문

LLM을 이용한 서비스 취약점 분석 자동화 #1 (새 탭에서 열림)

토스 보안 연구팀은 구글의 'Project Naptime'에서 영감을 얻어 LLM 기반의 취약점 분석 자동화 시스템을 구축했습니다. 대용량 코드 처리, 결과의 불확실성, 운영 비용 등 실무 적용 과정에서 마주한 네 가지 핵심 기술적 난제를 단계별로 해결하며 최종적으로 95% 이상의 분석 정확도를 달성했습니다. 기술적 가능성을 넘어 실제 수백 개의 서비스에 지속적으로 적용 가능한 수준의 보안 자동화 환경을 마련했다는 점에 의의가 있습니다. **대용량 소스코드 분석을 위한 MCP 도입** * 단순히 소스코드 전체를 LLM에 입력하는 방식은 토큰 한계와 환각(Hallucination) 문제로 인해 대규모 프로젝트 분석에는 부적합했습니다. * 대안으로 RAG(검색 증강 생성)를 시도했으나 코드 간의 복잡한 연관 관계를 파악하는 데 한계가 있었습니다. * 최종적으로 MCP(Model Context Protocol)를 구축하여 LLM 에이전트가 필요할 때마다 함수 정의나 변수 사용처를 도구 호출(Tool Calling) 방식으로 자유롭게 탐색하도록 설계했습니다. **SAST 결합을 통한 분석 일관성 확보** * 동일한 코드에 대해서도 분석 결과가 매번 달라지는 LLM의 비결정성 문제를 해결하기 위해 정적 분석 도구(SAST)를 결합했습니다. * 빌드 과정이 복잡하고 무거운 CodeQL 대신, 가볍고 빠른 오픈소스 도구인 Semgrep을 활용하여 모든 입력 경로(Source)에서 위험 지점(Sink)까지의 경로를 먼저 수집했습니다. * SAST가 추출한 잠재적 취약 경로를 LLM이 집중 분석하게 함으로써 탐지 누락을 방지하고 분석의 신뢰도를 높였습니다. **멀티 에이전트 체계를 통한 비용 최적화** * 모든 코드 경로를 심층 분석할 경우 발생하는 막대한 토큰 비용을 줄이기 위해 역할을 분담한 세 가지 에이전트를 도입했습니다. * **Discovery 에이전트:** 수집된 경로 중 실제 취약점 가능성이 높은 경로를 1차로 선별하는 거름망 역할을 수행합니다. * **Analysis 에이전트:** 선별된 경로를 심층 분석하여 실제 취약 여부를 판별합니다. * **Review 에이전트:** 최종 결과를 검토하여 오탐(False Positive)을 제거함으로써 분석의 정교함을 더했습니다. **지속 가능한 운영을 위한 오픈 모델 전환** * 상용 클라우드 모델(Claude 등)의 높은 비용 문제를 해결하기 위해 직접 호스팅 가능한 오픈 모델(Open Model)로 전환했습니다. * Qwen3:30B, gpt-oss:20B, llama3.1:8B 등 다양한 모델의 ROI를 비교 분석한 결과, 취약점 분석 정확도와 도구 호출 성능이 가장 우수한 'Qwen3:30B'를 최종 선택했습니다. * 오픈 모델의 성능을 보완하기 위해 프롬프트 엔지니어링과 퓨샷 러닝(Few-shot Learning)을 적용하여 클라우드 모델 못지않은 성능을 구현했습니다. 단순히 최신 기술을 도입하는 것에 그치지 않고, 기업 환경에서 실제 운영 가능한 수준의 '비용 대비 성능'을 확보하는 것이 중요합니다. LLM 취약점 분석 시스템을 구축할 때는 모든 판단을 모델에 맡기기보다 Semgrep과 같은 전통적인 보안 도구로 분석 범위를 좁혀주고, 멀티 에이전트 구조로 단계별 필터링을 거치는 설계가 실무적으로 가장 효과적입니다.

대규모 언어 모델AI모델 컨텍스트 프로토콜sast+4