AI Insight

AI Insight

9개의 게시글

2026-09-10

사람 중심 관리에서 AI 기반 무인 레포지토리 운영으로

코드는 AI가 짜는데 왜 레포지토리는 여전히 사람이 관리할까?   AI는 이제 복잡한 알고리즘 문제도 풀고, 코드 수정까지 수행할 수 있는 수준에 가까워지고 있습니다.   그런데 실제 개발 현장에서는 이슈를 전달하고, 담당자를 찾고, 처리 상태를 확인하는 일을 여전히 사람이 직접 챙기는 경우가 많습니다.     이슈가 사라지는 흔한 상황 2가지   중복되는 알림으로 확인이 지연되고 실시간으로 처리 상태를 파악이 어려워집니다.   담당자가 오류를 발견해도 그 내용이 DM, Notion, Jira, GitHub, Sentry에 흩어지면 이슈의 현재 상태를 한눈에 파악하기 어렵습니다.   그렇다면 문제의 본질은 무엇일까요?   문제는 '이슈'가 아니라 '주소'와 '상태'입니다   여기서 말하는 주소와 상태는 다음을 의미합니다. 주소: 이슈가 어느 제품, 어느 레포지토리의 문제인가 상태: 현재 어디까지 처리되었는가   주소와 상태, 이 두 가지가 명확하지 않으면 자동화가 시작되기 어렵습니다.   에이전트가 읽을 수 있는 상태 머신이 필요합니다   코딩 에이전트를 바로 연결한다고 무인 운영이 완성되는 것은 아닙니다.    먼저 이슈가 접수되고, 분류되고, 레포지토리와 연결되고, 처리 상태가 갱신되며, 결과가 다시 제보자에게 돌아가는 흐름이 필요합니다.   즉, 사람이 기억으로 관리하던 업무를 에이전트가 읽을 수 있는 상태 머신으로 바꿔야 합니다.   1. 모든 이슈가 단일 창구로 접수 2. 제품, 담당, 팀, 우선순위 정리 3. 실제 레포지토리와 연결 4. 사람과 에이전트 상태 동기화 5. 최초 제보자에게 결과 회신   이 다섯 가지가 갖춰지면, 이슈는 사람의 기억이 아니라 에이전트가 다룰 수 있는 데이터가 됩니다.   사용자는 VIT에 한 번만 제보합니다   VIT는 이슈를 한곳에서 접수하고 단일 이슈 ID를 부여하는 사내 이슈 트래커입니다.   사용자는 증상과 재현 절차를 한 번만 입력하면 됩니다. 이후 제품·팀·레포지토리 매핑, 중복 정리, 우선순위 판단, 처리 상태 갱신과 결과 회신은 시스템이 이어받습니다.   VIT는 한 번의 제보가 처리까지 이어지도록 만듭니다.        이슈는 PR과 검증으로 이어집니다   VIT에서 구조화된 이슈는 실제 GitHub 레포지토리와 연결됩니다.   이후 agent-maintainer가 이슈를 분류하고, 코딩 에이전트에 작업을 배정하며, 수정 패치와 테스트, PR 검증 과정을 이어갑니다.   1. TRIAGE | 이슈 분류 이슈를 확인하고 작업 가능한 상태로 정리합니다. 2. DISPATCH | 배정 코딩 에이전트에게 작업을 전달합니다. 3. PATCH | 수정 오류를 재현하고 코드를 수정합니다. 4. REVIEW | 검증 독립 검증과 증거 묶음을 생성합니다. 5. LAND | 병합 기준 브랜치에 안전하게 반영합니다.  6. RECOVER | 복구 실패 시 다시 수정 루프로 돌아갑니다.   완벽한 완료는 PR 머지가 아닙니다   무인 운영에서 PR 머지와 CI 통과는 완료를 위한 중간 단계일 뿐입니다.   정말 중요한 것은 처음 제보된 이슈가 실제 환경에서 사라졌는지 확인하는 것입니다.   그래서 시스템은 스테이징 환경에서 최초 제보의 재현 절차를 다시 수행하고, 결과를 기준에 따라 판정합니다.   FIXED 문제가 사라진 경우, 완료 처리하고 제보자에게 알립니다.   NOT FIXED 문제가 남아 있는 경우, 이슈를 다시 열고 후속 작업을 만듭니다.   INCONCLUSIVE 환경 변화 등으로 판단이 어려운 경우, 조건을 맞춰 다시 검증합니다.     무인 운영에도 사람이 지키는 경계는 있습니다   무인 운영은 모든 일을 AI에게 맡기는 방식이 아닙니다.   반복 가능하고 기준이 명확한 작업은 자동화하되, 불확실성이 큰 판단과 고위험 변경, 되돌리기 어려운 작업은 사람의 영역으로 남겨야 합니다.   결국 무인 레포지토리 운영은 사람이 이슈를 더 열심히 관리하는 것이 아니라, 이슈가 맞는 레포지토리로 흐르고 결과가 제보자에게 돌아오게 만드는 구조입니다.   이슈의 주소와 상태가 정리될 때, 접수부터 PR·검증·피드백까지 이어지는 AI 기반 무인 운영 루프가 완성됩니다.   자세한 내용 확인하러 가기  

2026-09-03

챗봇에는 착한 사용자만 있다? RAG 기반 AI 에이전트 검증

AI 에이전트를 검증할 때 모의 사용자와 대화를 시켜봅니다.   그런데 이 모의 사용자, 정말 실제와 유사하다고 볼 수 있을까요?     기본적으로 LLM에게 사용자 역할을 맡기면 매우 협조적인 태도를 보입니다. 또박또박 질문하고, 답변을 잘 기다립니다.   그런데 실제 사용자는 다릅니다. 말을 끝까지 하지 않고, 질문을 중간에 끊기도 하며, 갑자기 엉뚱한 것을 묻습니다.   협조적인 모의 사용자로만 시험한 챗봇은 이러한 점을 충분히 반영하기 어렵습니다.   이번 AI 인사이트에서는 실제 사용자에 가까운 비협조적 페르소나가   AI 에이전트의 숨은 결함을 어떻게 드러내는지 세 편의 논문을 통해서 확인합니다.   이어서 슈어소프트테크의 AI 에이전트 검증 플랫폼 VERIFAI-A의 CX 방법론은 어떻게 구현하고 있는지도 함께 살펴봅니다.     태도만 바뀌어도 결함이 쏟아진다   ChatChecker는 동일한 챗봇을 대상으로 표준 페르소나와 무례하고 조급하며 비꼬는 페르소나를 비교했습니다.   그 결과 페르소나의 태도만 바뀌어도 대화 붕괴, 품질 저하, 시스템 크래시와 같은 문제가 더 많이 드러났습니다.   이는 AI 에이전트가 정중하고 협조적인 질문에는 안정적으로 답하더라도, 태도가 달라지면 표면적으로 보이지 않던 결과가 드러날 수 있음을 보여줍니다.   비협조도 분류하고 통제할 수 있다   NCUser는 실제 사용자처럼 까다로운 행동을 체계화합니다.  여기서 중요한 점은 비협조적 사용자를 단순히 '무례한 고객'으로 만드는 것이 아니라, 목표 달성에 필요한 정보는 반드시 전달하도록 통제했다는 것입니다.   이 방식은 AI 에이전트가 예측하기 어려운 상황에서도 사용자의 목표를 놓치지 않고 응답할 수 있는지 확인하는 데 활용될 수 있습니다.   지식이 있어야 핵심을 짚는다   SAGE는 고객 프로필과 실제 문서를 함께 반영해, 제품과 서비스에 대한 구체적인 지식을 바탕으로 챗봇의 답변을 시험하도록 설계했습니다.   실험 결과에서도 SAGE는 실제 사람이 찾은 버그보다 더 많은 버그를 찾아냈고, 문서 지식을 제거했을 때는 버그 발견 수가 줄어드는 것으로 나타났습니다.   이는 비협조적 페르소나가 효과를 내려면 성격 외에도, 실제 업무 맥락과 지식이 함께 필요하다는 점을 보여줍니다.     종합해보면 AI 에이전트의 깊은 결함을 찾기 위해서는 세 가지 요소가 갖춰져야 합니다.   첫째, 태도입니다. 항상 정중하지 않으며, 때로는 조급하거나 불만을 표합니다.   둘째, 비협조적 행동입니다. 주제를 벗어나거나, 불완전하게 말하거나, 제공하기 어려운 요구를 할 수 있습니다.   셋째, 업무 지식입니다. 실제 서비스와 정책, 제품 정보를 바탕으로 구체적인 질문을 던집니다.     슈어소프트테크 AI 에이전트 검증 플랫폼 VERIFAI-A   VERIFAI-A는 이러한 관점을 CX(Customer Experience) 검증 방법론으로 구현합니다.   지식과 성격을 가진 비협조적 페르소나를 통해, 실제 고객 상황에 가까운 AI 에이전트 검증을 수행합니다.      VERIFAI-A의 CX 테스트 케이스는 3단계의 파이프라인으로 구성됩니다.   먼저 약관,매뉴얼,FAQ 등을 벡터 DB로 구축하고 페르소나의 목표와 관련된 지식을 부여합니다.   이후 네 가지 비협조적 행동을 강도와 함께 조합해 페르소나에 주입합니다.   마지막으로 대화 내내 필요한 정보가 전달되었는지 확인해, 실패 책임이 시뮬레이터로 돌아가지 않도록 목표 정렬을 추적합니다.   이 과정은 챗봇이 답변을 잘했는지 확인하는 것을 넘어, 실제 고객과 유사한 압박 상황에서도 목표 달성, 지식 활용, 응답 일관성, 결함 노출 여부를 함께 확인하는 방식입니다.     동일한 챗봇과 시나리오에서 비교한 결과 대화가 길어지고, 도전·추궁 발화율이 증가했으며, 기존 방식에서는 드러나지 않던 타깃 결함까지도 확인할 수 있었습니다.     착한 사용자만으로는 보이지 않는 결함이 있습니다   AI 에이전트 검증은 정답에 가까운 질문을 던지는 수준에서 나아가 실제 고객과 유사한 다양한 대화 조건을 재현하는 방향으로 확장되어야 합니다.   특히 태도, 비협조적 행동, 업무 지식이 결합된 페르소나는 일반적인 모의 사용자 테스트에서 드러나기 어려운 결함을 확인하는 데 활용할 수 있습니다.   VERIFAI-A CX 방법론은 이러한 관점을 바탕으로 AI 에이전트가 실제 고객과의 복잡한 상호작용 속에서도 목표를 달성하고, 필요한 정보를 제공하며, 안정적으로 응답할 수 있는지 검증합니다.   자세한 내용 확인하러 가기  

2026-08-27

정적 분석은 통과했는데 런타임에서 에러가 발생한다면?

"정적 분석은 통과했는데 런타임에서 에러가 발생한다면?"   이번 2026 AI Insight에서는 정적 분석이 잡지 못하는 런타임 에러를 대상으로,   AI 에이전트가 어떤 단서를 수집하고 어떤 방식으로 구조를 분석하여 수정 제안과 검증 과정을 지원하는지 살펴보겠습니다.     정적 분석이 잡지 못하는 에러가 있다   정적 분석은 코드를 실행하지 않고 문법과 규칙을 검사하는 방식으로, 컴파일 오류나 코딩 컨벤션 위반과 같은 문제를 사전에 발견하는데 활용됩니다.   그러나 모든 결함이 정적 분석 단계에서 드러나는 것은 아닙니다.   NullpointerException, 역직렬화 오류, SQL 별칭 참조 오류처럼 실제 실행 과정에서 발생하는 런타임 결함은 코드를 실행해봐야 확인할 수 있습니다.   사후 알림에서 자율 디버깅으로의 전환   기존에는 에러가 발생한 뒤에 개발자가 로그 확인부터 수정∙빌드까지 반복해야 합니다.   이제는 실시간으로 예외를 감지하고 AI가 원인 분석과 수정 제안 과정에 자동 개입합니다.   이렇게 되면 개발자는 빌드가 통과된 수정안을 검토하여 바로 적용할 수 있습니다.   AI 에이전트는 관련 단서와 코드 구조를 읽습니다   AI가 런타임 에러를 분석하기 위해서는 단순히 에러 텍스트만 확인하는 것으로는 부족합니다.   에러 메시지에서 변경 이력과 환경 설정 파일, DB 설정 등 원인 추정에 필요한 정보를 함께 수집합니다.   또한 코드 구조 그래프를 활용하여 에러 지점을 판단하여 수정에 따른 영향 범위와 부작용이 적은 수정 경로를 안내합니다.   바로 수정하지 않고 다음과 같은 과정을 거칩니다   런타임 에러 분석 과정에서 AI 에이전트는 코드를 바로 수정하는 것이 아니라, 판단에 피룡한 정보부터 정리합니다.   tree-sitter 기반 AST 압축을 통해 필요한 맥락만 남기고, 하이브리드 RAG를 통해 벡터 유사도 검색과 키워드 정확 매칭을 결합해 과거 해결 사례를 참고합니다.   이후 자기비판 추론을 통해 논리적 허점과 근거 부족을 점검하고, 격리된 환경에서 먼저 컴파일 검증을 수행합니다.   실패할 경우에는 1회 자가 교정을 거치고 빌드하여 개발자에게 검토 가능한 수정 제안을 전달합니다.      실측한 결과 이렇게 달라졌습니다   실제 적용 결과, 격리 빌드 컴파일 성공률은 84.2%로 확인되었습니다. 디버깅 소요 시간은 평균 25분에서 평균 140초로 감소하였으며, AST 기반 코드 압축을 통해 토큰 사용량은 평균 15.5% 절감되었습니다.   이는 AI가 수정 제안은 무분별하게 생성하는 방식이 아니라, 단서 수집부터 구조 분석을 통해 검증된 수정안을 제공하는 방식으로 반복 디버깅 부담을 줄이는 데 기여하였음을 보여줍니다. "AI 분석을 신뢰로 연결하는 검증의 역할"   AI 기반의 런타임 에러 분석은 정적 분석이 놓칠 수 있는 실행 단계의 결함을 감지하고, 원인 분석과 수정 제안, 격리 빌드 검증까지 지원합니다.   하지만 모든 오류를 자동으로 해결할 수 있는 것은 아니며, 사람의 판단이 필요한 영역은 여전히 존재합니다.   따라서 AI 시대의 런타임 에러 대응은 AI가 빠르게 분석하고, 사람은 검증하는 구조로 발전해야 합니다.   생성과 수정의 속도보다 중요한 것은, 그 결과가 실제로 안전하고 신뢰할 수 있는지 확인하는 과정입니다.   자세한 내용 확인하러 가기  

2026-08-20

AI 테스트 자동화, 핵심은 무엇일까?

"테스트 자동화의 기준이 달라지고 있습니다."   기존 테스트 자동화는 사람이 작성하고 실행하기 쉬운 구조가 중요했습니다. 하지만 AI가 테스트 시나리오를 분석하고, 코드를 생성하고, 실패 원인을 분석하는 단계까지 들어오면서 그 기준이 달라지고 있습니다.     이번 2026 AI Insight에서는 기존 자동화 프로젝트에서 AI를 통해 얻은 인사이트를 중심으로 살펴봅니다.     기존 자동화 코드는 AI에게 친절하지 않습니다.   Selenium 기반 자동화 코드는 XPath나 CSS Selector 중심으로 구성되는 경우가 많습니다.   이는 사람이 보기에도 의도를 파악하기 어려운 경우가 있고 AI 역시 해당 요소을 보고 정확한 판단을 하기 어렵다는 한계가 있습니다.   중요한 것은 프레임워크 교체가 아니라 구조의 재설계입니다.   Playwright 전환은 사용자의 인지 방식에 가까운 정보를 제공합니다. 즉, AI가 이해할 수 있는 '의미 중심의 자동화 구조'로 재설계한다는 점입니다.     Claude를 활용한 자동화 파이프라인은 자연어 시나리오를 입력하는 것에서 시작됩니다.   Claude는 시나리오의 의도를 분석하고, 기존 자동화 함수와 매칭한 뒤 실행 가능한 테스트 코드 초안을 생성합니다.   이 때 Claude Code와 Claude in Chrome을 분리하는 것이 중요합니다.            자동화 자산이 늘어나게 되면 AI가 생성해야 할 코드는 줄고, 기존 검증된 함수를 재사용하는 비율이 높아짐에 따라 그 효과는 더욱 커집니다.   그렇다면 테스트 자동화의 경쟁력은 무엇일까요?     경쟁력은 바로 '구조와 검증'입니다.   결국 AI 시대에 더 많은 코드를 빠르게 생성해내는 것이 아닌, 검증된 결과를 재사용하여 품질을 높이는 방향으로 진화해야 합니다.   이를 위해서는 AI가 활용할 수 있는 자동화 구조와 이를 검증핮는 체계가 뒷받침되어야 합니다.    슈어소프트테크는 미션 크리티컬 산업에서의 경험을 바탕으로 AI가 활용되는 테스트 자동화 환경에서도 신뢰할 수 있는 품질 검증 역량을 강화해 나가겠습니다.   아래 링크를 통해 더욱 자세한 내용을 확인하실 수 있습니다.   자세한 내용 확인하러 가기  

2026-07-29

AI 시대의 새로운 개발 역량, 하네스 엔지니어링

  "이제 AI가 코드를 작성하고 문서를 요약하고, 업무 흐름을 제안합니다."     AI가 실무에 깊숙이 자리 잡을수록 '어떤 AI 모델을 사용할 것인가'가 를 넘어서  'AI가 안정적으로 일할 수 있는 환경을 어떻게 만들 것인가'에 집중하기 시작했습니다. 이번 2026 AI Insight에서는 그 방법으로 주목받고 있는 하네스 엔지니어링의 개념과 좋은 하네스가 되기 위한 다섯 가지 구성 요소를 정리해보았습니다.       엔지니어링은 다음과 같이 3단계로 진화했습니다.     하네스 엔지니어링은 AI가 단순히 '답을 잘 내는 것'을 넘어, 정해진 기준 안에서 안전하고 일관되게 작동하도록 만드는 설계 방식입니다.     좋은 하네스가 되기 위해서는 아래와 같이 다섯 가지 구성 요소를 갖춰야 합니다.         다섯 가지 요소를 갖춘 AI는 스스로 점검하고, 일관된 방식으로 작업을 수행할 수 있습니다.   즉, 좋은 하네스는 AI 결과를 더 안정적이고 신뢰할 수 있도록 합니다. 하네스 엔지니어링은 AI를 안정적으로 활용하기 위한 중요한 방식이지만, 설계 이후에도 비용∙유지보수∙진부화에 대한 지속적인 관리가 필요합니다.   그렇다면 실제로 안전하고 신뢰할 수 있는 하네스로 작동하려면 어떻게 해야 할까요?       그 해답은 '검증'에 있습니다.   AI가 실제 업무 환경에서 안정적으로 작동하고, 예측 가능한 결과를 내며, 위험한 행동을 줄일 수 있는지 확인하는 검증 체계가 함께 필요합니다.     슈어소프트테크는 앞으로도 AI 모델이 작동하는 환경과 프로세스까지 검증하는 기술을 고도화하며 AI 시대의 검증 경쟁력을 만들어갈 것입니다.

2026-07-22

AI 협업, 개발 프로세스의 변화

  "AI가 바꾸는 개발의 흐름"   최근 local sLLM과 AI 코딩 도구가 개발 과정에 폭넓게 활용되면서, 개발 방식 자체에도 변화가 나타나고 있습니다.   자연어로 요구사항과 아이디어를 먼저 구체화하면 AI가 이를 바탕으로 초안 코드를 빠르게 생성할 수 있기 때문에,   구현보다 앞서 요구사항을 정교하게 정리하는 방식으로 무게중심이 옮겨가고 있는 것입니다.   그렇다면 이러한 변화는 실제 개발 현장에서 어떤 영향을 주고 있을까요? AI가 만들어가고 있는 개발 프로세스의 변화를 정리해보았습니다.       '직접 만드는 일'에서 '함께 조율하는 일'로 변화하는 개발자의 역할 과거에는 개발자가 요구사항을 해석하고 코드를 직접 작성하며 문제를 해결했습니다. 이제는 AI가 요구사항 정리부터 구조 제안, 코드 초안 생성 등 개발 과정의 일부를 빠르게 지원합니다.   개발자는 모든 코드를 처음부터 작성하기보다, AI가 제안한 결과를 검토하고 방향을 조율하며 최종 품질을 완성하는 역할로 확장되고 있습니다.       그렇다면 어떤 방식으로 AI와 협업해야 할까요? 3단계의 실무 워크플로우를 자세히 살펴보겠습니다.                 이러한 워크플로우를 실무에 적용할 때에는 실무 리스트도 함께 고려해야 하며, 다음과 같습니다. AI 활용이 늘어날수록 개발자에게는 더욱 정교한 검토 역량이 필요합니다.   위에서 살펴본 리스크에서 알 수 있듯이, 앞으로 개발자에게는 코드를 작성하는 역량 뿐만 아니라, AI가 만든 결과를 해석하고 검증하며 조율하는 역량이 더욱 중요해질 것입니다.     슈어소프트테크는 AI 시대의 개발 흐름 속에서 '신뢰를 검증하는 역할'을 강화하겠습니다.   AI 기반 개발의 가치는 결국 생성된 결과가 안전하게 동작하고, 설계 의도와 실제 구현이 일치하며, 장기적으로 신뢰할 수 잇는 품질을 유지하는가에 있습니다.   슈어소프트테크는 미션 크리티컬 산업에서 축적한 소프트웨어 검증 경험을 바탕으로, AI가 활용하는 개발 환경에서도 안전성과 신뢰성을 확인할 수 있는 검증 기술과 프로세스를 지속적으로 고도화해 나가겠습니다.

2026-07-16

AI는 왜 그럴듯하게 틀린 답을 할까?

  "AI는 왜 그럴듯하게 틀린 답을 할까?"   ChatGPT 같은 생성형 AI는 이제 일상과 업무에서 자연스럽게 사용되고 있습니다. 문서 작성, 코드 생성, 자료 요약, 고객 응대까지 활용 범위도 빠르게 넓어지고 있죠!   하지만 생성형 AI를 사용할 때 한 번쯤 이런 경험을 해본 적이 있을 겁니다.   "말은 굉장히 자연스러운데, 자세히 보니 틀린 답이네?"     이처럼 AI가 사실과 다른 내용을 그럴듯하게 만들어내는 현상을 환각, Hallucination이라고 합니다. 특히 국방, 금융, 의료처럼 정확성이 중요한 분야에서는 AI의 잘못된 답변이 단순한 실수를 넘어 큰 리스크가 될 수 있습니다.   이번에는 어려운 기술 설명보다는, LLM 환각이 왜 발생하는지, 그리고 어떤 방식으로 줄일 수 있는지 쉽게 살펴보겠습니다!       LLM은 왜 환각을 일으킬까?   LLM은 우리가 생각하는 것처럼 정보를 책장에 저장해 두고, 필요할 떄 정확히 꺼내오는 방식으로 작동하지 않습니다.   대신 지금까지 학습한 데이터를 바탕으로 "다음에 어떤 단어가 오는 것이 가장 자연스러울까?"를 예측합니다.   쉽게 말해 LLM은 정답을 확인해서 말한다기보다, 문맥상 가장 그럴듯한 문장을 만들어내는 데 가깝습니다.   그래서 질문이 모호하거나, 근거가 부족하거나, 복잡한 추론이 필요한 경우에는 실제와 다른 답변을 자연스럽게 생성할 수 있습니다.   * AI는 때때로 모르는 것을 모른다고 말하기보다, 가장 그럴듯한 답을 만들어낼 수 있습니다. 그래서 생성형 AI를 사용할 때는 답변이 자연스러운지보다 근거가 있는지를 확인하는 것이 중요합니다.       환각을 줄이는 방법은?   LLM 환각을 줄이기 위한 방법은 크게 세 가지로 볼 수 있습니다.     어렵게 말하면 검색 강화, 추론 구조화, 출력 검증입니다.     1. 자료를 보고 답하게 하기 첫 번째 방법은 AI가 혼자 기억에 의존해 답하지 않도록, 외부 문서나 데이터를 먼저 참고하게 하는 것입니다.     대표적인 기술이 RAG입니다. RAG은 AI가 답변하기 전에 관련 자료를 먼저 찾고, 그 자료를 바탕으로 답하도록 만드는 방식입니다.   예를 들어 시험을 볼 때 아무 자료 없이 푸는 것보다, 교과를 펼쳐 놓고 푸는 것이 더 정확하겠죠.   AI도 마찬가지입니다. 근거 자료를 함께 제공하면, AI가 그럴듯한 답을 만들어낼 가능성을 줄일 수 있습니다.   다만 자료를 찾는 것만으로는 충분하지 않습니다. 잘못된 자료를 참고하면 여전히 틀린 답을 할 수 있기 때문입니다.     그래서 질문을 검색하기 좋은 형태로 바꾸는 Query Rewriting, 검색된 자료 중 더 적합한 것을 다시 고르는 Reranking 같은 기술도 함께 사용됩니다. * AI가 혼자 답하지 않도록, 관련 자료를 찾고 좋은 근거를 골라 답하게 만드는 방식   2. 바로 답하지 말고, 단계별로 생각하게 하기 두 번째 방법은 AI가 바로 결론을 내리지 않고, 단계적으로 생각하도록 만드는 것입니다.   복잡한 질문일수록 바로 답하면 오류가 생기기 쉽습니다.   사람도 어려운 문제를 풀 때는 바로 답을 쓰기보다, 조건을 정리하고, 계산하고, 중간 과정을 확인합니다.   AI도 비슷합니다.     CoT, Chain-of-Thought는AI가 중간 추론 과정을 거쳐 답에 도달하도록 유도하는 방식입니다. 이렇게 하면 AI가 논리적으로 건너뛰거나, 잘못된 결론을 내릴 가능성을 줄이는 데 도움이 됩니다.   * AI에게 바로 답을 요구하는 대신, 생각의 과정을 나누어 답하도록 만드는 방식   3. 답변의 근거를 확인하게 하기 세 번째 방법은 AI가 답변한 뒤,  그 답변이 어떤 근거에서 나왔는지 확인할 수 있게 만드는 것입니다.     대표적인 기술이 XAI, Explainable AI입니다. XAI는 AI가 왜 그런 답을 했는지, 어떤 데이터나 문서를 바탕으로 답했는지 설명할 수 있도록 돕는 기술입니다.   앞으로는 단순히 "AI가 답을 잘했는가?"만 보는 것이 아니라, "AI가 어떤 근거로 그렇게 답했는가?", "그 근거를 사람이 확인할 수 있는가?"다 더 중요해질 것입니다. * AI의 답변을 그대로 믿는 것이 아니라, 답변의 출처와 근거를 확인할 수 있게 만드는 방식   AI 시대, 중요한 것은 '잘 쓰는 것'만이 아닙니다   생성형 AI는 앞으로 더 많은 업무와 산업 현장에 활용될 것입니다. 하지만 AI를 잘 활용하기 위해서는 단순히 빠르게 답을 얻는 것만으로는 충분하지 않습니다.   AI가 제시한 답변이 믿을 수 있는지, 어떤 근거를 바탕으로 만들어졌는지, 중요한 의사결정에 활용해도 되는지 확인할 수 있어야 합니다.     결국 AI 시대의 핵심은 AI를 사용하는 것에 나아가, AI를 신뢰할 수 있게 검증하는 것입니다.   슈어소프트테크는 이러한 기술 흐름을 바탕으로, 다양한 산업 분야에서 신뢰할 수 있는 AI 플랫폼과 검증 체계 구축을 지속해 나가고자 합니다.

2026-07-09

퀴즈로 핵심만 빠르게 정리하는 AI 기본법

    "기업은 AI 기본법의 책임 주체와 주요 의무사항을 얼마나 정확히 이해하고 있을까요?"     AI가 의사결정과 서비스 운영에도 직접적으로 관여하게 되면서, 성능만큼이나 안전성과 신뢰성을 확보하는 일이 중요해졌습니다.   이에 발맞춰 2026년 1월 22일, 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」 이 시행되었습니다.   AI 기본법의 핵심을 알아야 기업에 필요한 올바른 대응을 제대로 준비할 수 있습니다.   다음 퀴즈를 통해 확인해보세요!   ——————————   정답: O   생성형 AI 서비스를 제공하는 기업은 이용자에게 AI 사용 사실을 사전에 알리고, AI가 만든 결과물에는 생성 사실을 표시해야 합니다.   즉, 고지는 서비스에 AI가 활용되었음을 알리는 것이고, 표시는 개별 결과물이 AI로 생성되었음을 구분하는 것입니다.   정답: X   외부 API를 사용하더라도 AI 서비스를 최종 제공하는 주체가 책임져야 합니다.   따라서 외부 솔루션을 활용했다는 이유만으로 최종 서비스 제공자의 책임이 사라지는 것은 아닙니다.       정답: 1. 생성형 AI  2. 고영향 AI  3. 일반 AI 시스템       정답: 판단 근거와 기록   AI 유형에 따라 적용되는 의무와 규제 수준이 달라지므로, 어느 유형에 해당하던지 결과 뿐만 아니라 판단한 근거와 검토 과정도 기록으로 남겨두는 것이 중요합니다.         정답: 검증   AI를 믿고 사용하기 위해서는 실제 환경에서의 성능을 비롯해 강건성, 위험성, 품질, 예외 상황 대응 등을 확인해야 합니다.   즉, 검증은 AI의 성능과 안전성을 객관적으로 확인하는 핵심입니다.   ——————————     AI 기본법은 AI 활용을 제한하기 위한 법이 아닌, 기업과 이용자가 더욱 안전하게 신뢰하고 활용할 수 있는 기준을 마련한 법입니다.   따라서 기업은 자사가 제공하는 AI의 유형과 책임 주제를 정확히 파악하고, 적용되는 고지∙표시 및 안전 관리 의무를 확인해야 합니다.     슈어소프트테크는 미션 크리티컬 산업에서 축적한 SW 시험∙검증 경험을 바탕으로, 안전한 AI를 개발하고 운영할 수 있도록 AI 신뢰성 검증 기술과 서비스를 고도화해 나가겠습니다.  

2026-06-29

기업이 주목해야 할 'Trustworthy AI'와 'Physical AI'

  "AI를 얼마나 잘 만드는가보다, 얼마나 신뢰할 수 있는가가 더 중요한 시대."   생성형 AI의 등장 이후 기업들은 AI를 활용한 업무 혁신을 빠르게 추진하고 있습니다. 이제 AI는 단순한 챗봇을 넘어 AI Agent, 자율주행, 로봇, 디지털 트윈 등 현실 세계까지 영역을 넓혀가고 있습니다.    하지만 AI 의 활용 범위가 넓어질수록 기업들의 고민도 달라지고 있습니다.    "AI를 만들 수 있는가?" 에서 "AI를 믿고 사용할 수 있는가?" 로 말입니다.     1. Trustworthy AI : 신뢰할 수 있는 AI가 경쟁력이 된다.   Trustworthy AI는 단순히 성능이 뛰어난 AI가 아니라, 사람이 믿고 사용할 수 있는 AI를 의미합니다. AI가 금융, 의료, 제조, 국방 등 핵심 산업으로 확대되면서 기업들은 이제 다음과 같은 요소를 함께 고려해야 합니다.   - AI Safety - AI Verification - AI Evaluation - AI Regulation - AI Transparency   AI를 개발하는 것만으로는 충분하지 않습니다. 검증을 통해 신뢰성을 확보하는 것이 기업 경쟁력이 되고 있습니다.       2. Physical AI : AI가 현실 세계를 움직인다.   생성형 AI가 디지털 공간을 변화시켰다면, Physical AI는 현실 세계를 변화시키고 있습니다. Physical AI는 AI가 실제 환경을 인식하고 판단하며 행동하는 기술을 의미합니다.   대표적인 사례는 다음과 같습니다. - 자율주행 자동차 - 휴머노이드 로봇 - 산업용 로봇 - 디지털 트윈 - 스마트팩토리 - 드론   AI는 이제 화면 속이 아니라 현실에서 움직이고 있습니다.       과거와 지금   AI는 단순히 기술을 만드는 시대를 넘어, 이제는 신뢰하고 안전하게 활용하는 시대로 진화하고 있습니다.           마무리하며... AI 산업은 이제 더 똑똑한 AI를 만드는 경쟁에서,  더 신뢰할 수 있는 AI를 만드는 경쟁으로 빠르게 변화하고 있습니다.   Trustworth AI와 Physical AI는 이러한 변화를 대표하는 핵심 키워드이며, 앞으로 기업의 경쟁력을 결정하는 중요한 요소가 될 것입니다.   슈어소프트테크 AI Insight는 AI 기술과 산업 동향을 깊이 있게 분석하고, 기업이 실제 현장에서 활용할 수 있는 다양한 인사이트를 지속적으로 제공하겠습니다.    

Contact

슈어소프트테크와 함께 시작해보세요!

개발 환경에 맞춘 최적의 검증 솔루션을 제안해 드립니다.

close