human-in-the-loop

7 개의 포스트

toss5분 읽기큐레이션 요약

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의 품질을 높이려면 검색 성능만 개선하기보다, 의미 단위·원문 근거·출처 간 관계·최신성·충돌 상태를 함께 관리해야 한다. 특히 자동화는 명확한 변경 감지와 관계 추출에 사용하고, 사내 용어 통합이나 중요한 정책 판단처럼 맥락 의존적인 문제는 근거를 제시한 뒤 사람의 승인을 받는 방식이 안전하다.

원문 읽기(새 탭에서 열림)
meta5분 읽기큐레이션 요약

AI 네이티브 시대의 프라이버시 인식 인프라: 자산 분류 사례 연구

프라이버시 통제는 데이터의 정체와 사용 맥락을 정확히 이해해야 제대로 작동하며, 이를 위한 자산 분류가 모든 보존·접근·목적 제한·공유·익명화 정책의 기반이 된다. Meta는 LLM을 모든 운영 판단에 사용하는 대신, 풍부한 맥락과 인간 검토를 바탕으로 모호하거나 새로운 자산을 해석하게 하고, 검증된 패턴은 버전 관리되는 결정론적 규칙으로 전환하는 하이브리드 방식을 제안한다. 그 결과 일상적인 운영 집행은 빠르고 재현 가능하며 감사하기 쉬운 규칙이 담당하고, LLM은 점차 예외적인 경우에만 사용된다. ## 프라이버시 인프라에서 자산 분류가 중요한 이유 - 프라이버시 인식 인프라(PAI)는 다음 네 가지 운영 문제를 다룬다. - 어떤 데이터가 존재하고 어떻게 관리되는지 파악 - 특정 정책과 관련된 데이터 흐름 탐색 - 보존 기간, 접근 권한, 허용 목적, downstream 공유 제한 집행 - 검증 가능한 증거를 통한 컴플라이언스 입증 - 자산 분류는 이 중 ‘데이터 이해’ 계층에 해당하며, 이후 모든 통제의 기반이 된다. - 분류 대상은 테이블과 컬럼에 한정되지 않는다. - 중첩 페이로드의 필드 - 로그 키와 이벤트 파라미터 - API 필드 - ML 피처와 임베딩 - 중간 파이프라인에서 생성된 파생 데이터셋 - 같은 데이터가 파이프라인을 거치며 피처, 모델 학습 데이터, 결합된 파생 신호 등 여러 표현으로 바뀌므로, 분류는 데이터의 형태보다 의미와 계보(lineage)를 따라야 한다. ## 데이터 분류가 어려운 네 가지 이유 - **노이즈가 많고 신호가 약하다** - 자산마다 수십 개의 맥락 필드를 제공하면 모델이 매번 중요한 정보를 다시 찾아야 한다. - 불필요한 필드가 토큰과 주의를 소모해 실제 결정 경계를 흐린다. - 예를 들어 `age`는 개인정보 맥락에서는 사람의 나이지만, 인프라 파이프라인에서는 캐시 TTL일 수 있다. - 코드 해석과 lineage 분석이 없으면 캐시 파이프라인 전체에 불필요한 제한이 적용되는 false positive가 발생한다. - **관련 정보가 여러 시스템에 흩어져 있다** - 코드, 데이터 계보, 소유자, 의미론적 주석, 문서, 실제 사용 패턴을 함께 확인해야 한다. - **요구사항과 정책 해석이 계속 변한다** - 제품 기능이 빠르게 바뀌면 정적 규칙이나 주기적 수동 검토만으로는 정책 공백이 생긴다. - **분류 오류가 downstream 전체에 전파된다** - false positive는 불필요한 제한을 유발한다. - false negative는 보호되지 않은 데이터가 남는 문제를 만든다. - 따라서 모호성을 다루는 추론 능력과 설명·재현 가능한 집행 방식이 모두 필요하다. ## LLM과 결정론적 규칙의 역할 분담 - LLM은 다음 상황에 제한적으로 사용한다. - 기존 규칙으로 처리하기 어려운 모호한 자산 - 초기 데이터가 부족한 cold start 상황 - 이전에 보지 못한 새로운 패턴 - 검증된 패턴은 버전이 있는 결정론적 규칙으로 변환한다. - 낮은 지연 시간 - 동일 입력에 대한 재현성 - 실행 결과의 감사 가능성 - 대규모 운영에 적합한 비용과 성능 - 일반적인 운영 판단은 LLM이 아니라 규칙이 담당한다. - 인간은 다음 단계에 관여한다. - 기준 라벨(reference label) 판정 - 보호 정책에 영향을 주는 규칙 승격 검토 및 승인 - 장기적으로는 LLM이 담당하는 운영 범위를 줄이고, 규칙이 처리하는 안정적인 영역을 넓히는 것이 목표다. ## 원칙 1: 프롬프트보다 맥락이 중요하다 - 분류 실패의 주요 원인은 지시문이 약해서가 아니라 모델에 제공된 증거가 부족하거나 정리되지 않았기 때문이다. - 원시 필드를 그대로 전달하면 중요한 정보와 오해를 일으키는 정보가 섞인다. - 대신 다음 요소를 포함한 **evidence brief**를 구성한다. - 판단을 지지하는 신호 - 판단과 모순되는 신호 - 각 정보의 출처(provenance) - 모델이 이미 알고 있는 정보와 중복되는 순환 필드의 마스킹 - 프롬프트를 계속 최적화하는 것보다, 코드·계보·소유권·문서 등 관련 증거를 선별하고 구조화하는 편이 정확도 향상에 더 효과적이다. - 즉, 모델에 무엇을 어떻게 묻는지보다 먼저 무엇을 보여줄지를 설계해야 한다. ## 원칙 2: 평가와 최적화를 분리한다 - LLM의 결과는 추천이며, 그 자체가 정답 데이터가 되어서는 안 된다. - 평가 체계는 분류기와 독립적으로 유지해야 한다. - 서로 다른 모델과 프롬프트 전략 - 고정된 reference set - 사람이 검토한 라벨 - 회귀(regression) 통과 기준 - 분류 결과를 다시 평가 기준으로 사용하면 실제 개선이 아니라 모델의 드리프트를 측정할 위험이 있다. - 인간 검토 라벨은 모델 출력과 분리된 신뢰 가능한 기준점으로 사용해야 한다. ## 원칙 3: 안정적인 동작을 규칙으로 증류한다 - 반복적으로 검증된 분류 패턴은 사람이 검토한 뒤 결정론적 규칙으로 만든다. - 규칙에는 버전, 적용 조건, 판단 근거를 남겨야 한다. - 규칙 기반 집행은 LLM 추론보다 빠르고, 결과를 재생(replay)할 수 있으며, 감사와 디버깅이 쉽다. - LLM은 새로운 패턴을 발견하는 학습 장치로 활용하고, 안정화된 지식은 규칙에 축적한다. ## 플랫폼 서비스로서의 분류 계약 분류기는 개별 모델 호출이 아니라 안정적인 플랫폼 서비스처럼 설계해야 한다. - 입력 - 자산 식별자 - 정리된 맥락 정보 묶음 - 출력 - 분류기 taxonomy상의 카테고리 - 모델의 원시 confidence score - 판단에 영향을 준 증거를 보여주는 decision trace - 결정론적 규칙으로 판단했다면 매칭된 규칙 - 사용된 맥락, 규칙, 프롬프트의 버전 정보 - confidence는 모델의 자기평가일 뿐이므로, 사람이 검토한 라벨과 비교해 실제 보정 상태를 평가해야 한다. - 모든 분류기를 하나의 보편적 taxonomy로 통합하지 않고, 각 분류기가 하나의 범위가 좁은 질문을 담당하도록 한다. - 예: 사용자 데이터인지 운영 데이터인지 분류 - 예: 특정 AI 학습 용도에 적합한 자산인지 분류 - 좁은 범위의 분류기는 평가·디버깅·거버넌스가 쉽고, 여러 분류기의 결과를 downstream에서 조합할 수 있다. 실무적으로는 LLM을 최종 집행 엔진으로 삼기보다, 사람이 검토한 라벨과 충분한 맥락을 이용해 새로운 패턴을 발견하는 보조 계층으로 두는 것이 바람직하다. 이후 안정화된 판단은 버전 관리되는 규칙으로 승격해 운영하고, 모든 결과에 증거·버전·추적 정보를 남겨 재현성과 감사 가능성을 확보해야 한다.

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

Browser Run: 에이전트에게 브라우저를 제공하세요 (새 탭에서 열림)

Cloudflare는 기존의 'Browser Rendering' 서비스를 'Browser Run'으로 재브랜딩하며 AI 에이전트가 웹과 상호작용하는 데 최적화된 강력한 브라우징 인프라를 공개했습니다. 이 서비스는 Cloudflare의 글로벌 네트워크에서 전체 브라우저 세션을 실행하고, 에이전트가 사이트 탐색, 데이터 추출, 폼 작성 등을 대규모로 수행할 수 있도록 지원합니다. 결과적으로 개발자는 인프라 관리 부담 없이 AI 에이전트에게 실시간 모니터링, 인간 개입, 세밀한 제어 기능을 갖춘 브라우저를 제공할 수 있게 되었습니다. **에이전트 중심의 확장된 브라우저 인프라** * **온디맨드 인스턴스 실행:** Cloudflare 글로벌 네트워크를 통해 헤드리스 크롬(Chrome) 인스턴스를 즉시 생성하며, 버전 관리나 서버 유지보수 없이 저지연 환경에서 브라우징 세션을 운영할 수 있습니다. * **대규모 동시성 지원:** 동시 실행 가능한 브라우저 한도를 기존 30개에서 120개로 대폭 늘려, 대량의 작업을 동시에 처리해야 하는 에이전트의 요구사항을 충족합니다. * **에이전트 SDK 결합:** Agents SDK와 연동하여 웹을 탐색하고 정보를 기억하며 자율적으로 행동하는 장기 실행(Long-running) 에이전트 구축이 가능합니다. **CDP 엔드포인트를 통한 정밀한 제어** * **직접적인 프로토콜 노출:** Chrome DevTools Protocol(CDP) 엔드포인트를 직접 노출하여 에이전트가 브라우저에 대해 최대 수준의 제어권을 가질 수 있게 합니다. * **효율적인 모델 통신:** Puppeteer나 Playwright 같은 고수준 라이브러리를 거치지 않고 원시 CDP 메시지를 모델에 직접 전달할 수 있어, 토큰 효율적인 브라우저 제어가 가능합니다. * **간편한 이관:** 기존에 자체 호스팅 크롬에서 실행하던 CDP 기반 자동화 스크립트를 코드 한 줄의 설정 변경(WebSocket URL 교체)만으로 Browser Run에서 실행할 수 있습니다. **실시간 모니터링과 인간 협업 기능** * **Live View:** 에이전트가 현재 무엇을 보고 어떤 동작을 하는지 실시간으로 확인하며, 작업 실패 시 원인을 즉각 파악할 수 있습니다. * **Human in the Loop:** 로그인이나 예상치 못한 예외 상황 발생 시 에이전트가 작업을 중단하는 대신 인간에게 제어권을 넘기고, 문제가 해결되면 다시 제어권을 받아 작업을 이어가는 워크플로우를 지원합니다. * **세션 녹화(Session Recordings):** DOM 변경, 사용자 상호작용, 페이지 탐색을 포함한 모든 세션을 녹화하여 사후 디버깅 및 분석에 활용할 수 있습니다. **생태계 확장 및 차세대 웹 표준 지원** * **MCP(Model Context Protocol) 지원:** Claude Desktop, Cursor, OpenCode와 같은 AI 코딩 에이전트들이 Browser Run을 원격 브라우저로 사용할 수 있도록 지원합니다. * **WebMCP 도입:** 웹사이트가 에이전트가 수행 가능한 액션을 직접 선언하게 함으로써, 인간 중심의 웹 구조에서 발생하던 에이전트의 탐색 오류를 줄이고 신뢰성을 높입니다. Cloudflare Browser Run은 단순한 브라우저 자동화 도구를 넘어 AI 에이전트의 '눈'과 '손' 역할을 하는 필수 인프라로 자리 잡고 있습니다. 특히 복잡한 로그인 처리나 실시간 디버깅이 필요한 에이전트 환경을 구축하려는 개발자에게 CDP 직접 노출과 Human-in-the-loop 기능은 매우 강력한 이점을 제공할 것입니다.

figma3분 읽기큐레이션 요약

디자이너 수요가 증가하는 이유 | Figma 블로그

AI 시대에 기업의 디자이너 수요는 감소하기보다 오히려 다시 증가하고 있다. Figma의 조사에서 82%의 디자인 리더가 디자이너 수요가 증가했거나 유지됐다고 답했으며, AI 도구 활용과 AI 제품 설계 역량이 채용의 중요한 기준으로 떠올랐다. 특히 빠르게 성장하는 기업일수록 디자인을 제품 차별화와 매출 성장을 이끄는 전략적 기능으로 보고 더 적극적으로 채용하고 있다. ## 기술 산업을 넘어 증가하는 디자인 채용 - 조사 대상 리더의 **82%**는 조직의 디자이너 수요가 증가했거나 현재 수준을 유지하고 있다고 답했다. - 약 **47%**는 수요가 증가했다고 응답했다. - 수요가 증가한 기업 중 다수는 최소 **10% 이상** 증가했다고 답했으며, 25% 이상 증가한 기업도 상당수였다. - 기술 기업이 채용을 주도하지만, 디자인 수요는 다양한 산업으로 확산되고 있다. - 북미의 비기술 기업도 디자인 인력을 적극적으로 채용하는 편이다. - 유통, 출판, 항공 등은 디지털 접점을 강화하고 고객 경험을 개선하기 위해 디자이너를 필요로 한다. - 기업 성장률이 높을수록 디자인 채용 의향도 높았다. - 업계 평균보다 빠르게 성장하는 기업의 **46%**가 향후 6개월 내 채용 확대를 계획했다. - 평균 성장 기업은 **40%**, 성장 속도가 느린 기업은 **33%**였다. - 고성장 기업은 디자인을 단순한 시각적 완성도가 아니라 다음과 같은 전략적 수단으로 인식한다. - 아이디어를 더 빠르게 검증 - 전략을 실제 제품으로 전환 - 경쟁사와 차별화 - 고객 기대에 대응하고 매출 창출 - 채용 시장에 대한 체감은 아직 낙관적이지 않다. - 전체 채용 환경이 개선되고 있다고 보는 채용 관리자는 **20%**에 그쳤다. - 그러나 2025년 디자인 직무 채용 공고는 일부 디자인 중심 벤처캐피털 포트폴리오에서 전년 대비 약 **60% 증가**했다. - 향후 6개월 내 추가 인력을 채용하려는 관리자는 **40%**였다. ## AI가 디자이너 수요를 촉진하는 이유 - AI 모델과 도구가 빠르게 발전하면서 기업은 새로운 업무 방식에 즉시 적응할 수 있는 디자이너를 찾고 있다. - 기업이 요구하는 역량은 두 방향으로 확대되고 있다. - AI 도구를 디자인 업무에 활용하는 능력 - AI 기반 제품과 서비스를 설계하는 능력 - 채용 관리자의 **73%**는 AI 도구 숙련도에 대한 수요가 증가했다고 답했다. - **79%**는 AI 제품을 설계할 수 있는 지식의 중요성이 커졌다고 응답했다. - AI 역량은 더 이상 선택적인 우대 조건이 아니라 필수 요건에 가까워지고 있다. - 특히 기업은 다음 역량을 결합한 인재를 선호한다. - 기술적 이해도 - 전략적 사고 - 창의적이고 틀을 벗어난 문제 해결 - 인간이 개입하는 human-in-the-loop 방식에 대한 이해 - 인간의 판단을 보완하는 human-augmented AI 활용 능력 - 따라서 AI 시대의 디자이너는 AI 제품의 사용자 경험을 설계하는 동시에, 자신의 디자인 프로세스에도 AI를 효과적으로 통합해야 한다. ## 기업이 시니어 디자이너를 우선하는 배경 - 글은 다음 섹션에서 기업들이 **시니어 인재를 우선적으로 채용하는 현상**을 다룬다. - 공개된 내용에 따르면, 빠른 실행이 요구되는 환경에서 기업은 단순한 제작 능력보다 다음과 같은 역량을 갖춘 디자이너를 중시하고 있다. - 높은 수준의 판단력 - 복잡한 문제를 해결하는 경험 - 빠르게 변화하는 프로젝트를 주도하는 능력 - 다만 제공된 글은 이 섹션의 문장이 중간에서 끝나 있어, 시니어 인재에 대한 구체적인 조사 수치와 세부 근거는 확인할 수 없다. 디자이너는 시각 디자인 툴 숙련도만 강화하기보다 AI 도구를 실제 업무에 적용하고, AI 제품의 작동 방식과 사용자 경험을 함께 이해하는 역량을 갖추는 것이 유리하다. 또한 빠르게 성장하는 조직이 요구하는 전략적 사고와 제품 개발 전반의 판단력을 함께 키우는 것이 향후 채용 경쟁력을 높이는 방법이다.

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

소프트웨어 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으로 바뀌었지만 응집도와 결합도를 고려한 좋은 설계 원칙을 유지할 때, 비로소 실무에서 신뢰할 수 있는 강력한 에이전트를 구축할 수 있습니다.

kakao원문

[AI_TOP_100] 문제 출제 후기 – 기술이 아닌, 사람을 묻다. (새 탭에서 열림)

AI 기술이 비약적으로 발전하는 시대에 도구를 다루는 인간의 실제 문제 해결 역량을 측정하기 위해 ‘AI TOP 100’ 경진대회가 기획되었습니다. 단순히 AI를 사용하는 수준을 넘어, 인간과 AI의 긴밀한 협업 과정을 통해 복잡한 현실 문제를 해결하고 최적의 의사결정을 내리는 ‘문제 해결자’를 선별하는 데 초점을 맞추었습니다. 결과물뿐만 아니라 AI의 한계를 인간의 통찰로 보완해 나가는 '과정' 자체를 핵심 평가 지표로 삼은 것이 이번 대회의 결론입니다. **AI와 인간의 협업 루프(Human-in-the-loop) 설계** * 단순히 문제를 복사하여 붙여넣는 방식으로는 해결할 수 없도록, 사람의 분석과 AI의 실행, 그리고 다시 사람의 검증이 순환되는 구조를 지향했습니다. * 사람은 직관적으로 파악하지만 AI는 분석하기 어려운 데이터 구조(식단표, 복잡한 표의 행/열 관계 등)를 제공하여 인간의 사전 가이드가 성능을 좌우하게 설계했습니다. * 이미지 생성과 피드백 분석, 프롬프트 개선 과정을 에이전트에게 위임하여 자동화 파이프라인을 구축하는 등 고도화된 협업 능력을 측정했습니다. **'딸깍' 방지를 위한 입체적인 난이도 설계** * 최신 AI 모델이 단 한 번의 프롬프트(One-shot)로 정답을 맞히지 못하도록 의도적인 기술적 제약과 논리적 미로를 문제 속에 배치했습니다. * '낮은 진입 장벽과 높은 천장' 원칙에 따라, 초보자도 쉽게 접근할 수 있는 시작 문항부터 깊은 통찰이 필요한 킬러 문항까지 '난이도 사다리' 구조를 도입했습니다. * 특정 프레임워크에 국한되지 않고 출제자가 예상치 못한 창의적인 방식으로도 문제를 해결할 수 있는 열린 구조를 유지했습니다. **현실의 복잡성을 반영한 4가지 문제 패턴** * **분석 및 정의(Insight):** 정답이 없는 복합 데이터 속에서 유의미한 문제나 기회를 스스로 발견하는 역량을 평가합니다. * **구현 및 자동화(Action):** 정의된 문제를 해결하기 위해 AI 솔루션을 실제 작동하는 코드나 워크플로로 구현하는 능력을 측정합니다. * **전략 및 창의(Persuasion):** 기술적 솔루션을 비기술 이해관계자에게 설득력 있게 전달하기 위한 논리와 창의적 콘텐츠 생성 능력을 확인합니다. * **최적화 및 의사결정(Decision):** 제약 조건 하에서 목표를 최대화하는 최적의 의사결정 시뮬레이션을 수행합니다. **엄격한 검증을 거친 문제 고도화 파이프라인** * 아이디어 단계부터 최종 확정까지 4단계의 파이프라인을 구축하고, 출제위원 내부 테스트 및 알파·베타 테스트를 통해 문제의 신뢰도를 검증했습니다. * AI 모델이 매일 업데이트되어 어제의 난제가 오늘의 쉬운 문제가 되는 환경에 대응하기 위해 지속적인 실증 테스트를 반복했습니다. * 문제의 겉보기 난이도가 아니라 실제 해결에 필요한 노력 비용을 기준으로 점수를 재조정하는 '캘리브레이션' 과정을 거쳐 변별력을 확보했습니다. AI 시대의 진정한 경쟁력은 도구의 기능을 단순히 암기하는 것이 아니라, AI의 한계를 명확히 이해하고 이를 인간의 기획력으로 보완하여 실질적인 가치를 만들어내는 데 있습니다. 이번 출제 후기는 기술보다 '그 기술을 다루는 사람'의 사고방식이 더 중요하다는 점을 강조하며, 앞으로의 AI 리터러시 교육과 평가가 나아가야 할 방향을 제시합니다.

line원문

IUI 2025 참관기: AI의 지속성과 인간 중심의 AI에 대해서 (새 탭에서 열림)

IUI(Intelligent User Interfaces) 2025 학회에서는 단순히 기술적 성능이 뛰어난 AI를 넘어, 인간의 능력을 증강하고 윤리적 책임을 존중하는 '인간 중심의 AI(Human-Centered AI)'가 핵심 화두로 다뤄졌습니다. 전문가들은 AI가 인간의 인지와 현실을 어떻게 재설계할 것인지, 그리고 복잡한 모델을 사용자가 어떻게 신뢰하고 통제할 수 있을지에 대한 실천적인 방법론을 제시했습니다. 결론적으로 미래의 AI는 독립적인 자동화 도구가 아니라, 인간과 상호작용하며 함께 성장하고 사회적 맥락 안에서 투명하게 소통하는 협력적 지능으로 진화해야 함을 강조했습니다. **리얼리티 디자인: 인터페이스를 넘어 현실을 설계하는 AI** * HCI(인간-컴퓨터 상호작용) 연구의 범위를 단순한 화면 속 인터페이스에서 인간의 삶이 이루어지는 '현실 자체'로 확장해야 한다는 '리얼리티 디자인' 개념이 제시되었습니다. * AI와 센서, XR 기술을 결합하여 인간의 기억을 기록 및 재구성하거나, 특정 음성을 선택적으로 청취하고 동작을 슬로 모션으로 지각하는 등 인간의 감각과 인지 능력을 물리적으로 증강하는 연구 사례들이 소개되었습니다. * 다만, 기술이 인간의 사고와 학습 의지를 약화시켜 '인지적 퇴화'를 초래할 수 있다는 점이 경고되었으며, 기술과 인간이 서로 영향을 주고받는 순환적 관계임을 고려한 설계가 필요합니다. **인간 중심의 AI 투명성: 사회기술적 간극 해소** * 기존의 기술 중심적 설명 가능성(XAI)에서 벗어나, 사용자가 실제 맥락에서 이해하고 신뢰할 수 있는 '사회기술적(socio-technical)' 관점의 투명성 확보가 강조되었습니다. * 투명성을 구현하기 위한 구체적 방법론으로 확정적이지 않은 결과를 명확히 전달하는 '불확실성 커뮤니케이션', 조건 변화에 따른 결과 차이를 보여주는 '반사실적 설명', 사용자가 피드백을 통해 모델을 조정하는 '상호작용 기반 투명성'이 제시되었습니다. * LLM 시대의 투명성은 단순한 정보 공개를 넘어 모델 카드(Model Card)를 통한 데이터/개발 배경 공유, 안전성 및 리스크 평가 결과 포함, 그리고 사용자가 직접 통제권을 가질 수 있는 수단을 함께 제공하는 방향으로 나아가야 합니다. **인터랙티브 머신러닝: 사용자와 함께 성장하는 모델** * AI를 고정된 데이터를 학습하는 정적 도구로 보지 않고, 사용자가 모델의 오류를 수정하고 그 피드백이 다시 학습에 반영되는 '인간 참여형(Human-in-the-loop)' 루프의 중요성이 재조명되었습니다. * 이 방식은 교육 도구에서 학생들이 데이터를 조작하며 학습 원리를 깨우치게 하거나, 연구 현장에서 대규모 데이터를 분석할 때 인간의 직관을 결합하는 등 다양한 실무 분야에서 인용되고 있습니다. * 좋은 AI의 기준은 독립적인 성능 수치보다 사용자와의 지속적인 상호작용을 통해 얼마나 유연하게 적응하고 발전할 수 있는지에 달려 있습니다. **전문가 협업 시스템: 상담 분석을 돕는 AI** * 아동 상담 분석과 같이 고도의 전문성이 필요한 영역에서 AI가 상담사의 녹취 및 전사 작업을 보조하고, 상담사가 AI의 결과물을 손쉽게 편집 및 교정할 수 있는 협업 시스템 연구가 발표되었습니다. * 이는 AI가 인간의 일자리를 대체하는 것이 아니라, 번거로운 작업을 효율화함으로써 전문가가 본연의 가치 있는 업무에 집중할 수 있도록 돕는 실질적인 협업 모델의 예시를 보여줍니다. **실용적 제언** AI 시스템을 설계할 때 단순히 정확도를 높이는 데 그치지 말고, 사용자가 시스템의 판단 근거를 납득할 수 있는 '설명 수단'과 잘못된 결과를 바로잡을 수 있는 '통제 수단'을 반드시 세트로 설계해야 합니다. 특히 고위험군 서비스를 개발할 때는 모델의 불확실성을 시각적·언어적으로 친절하게 전달하여 사용자가 적절한 수준의 신뢰를 형성하도록 유도하는 것이 중요합니다.