【JSAI2026】OS-31 「LLM 시대의 소프트웨어 공학」 세션 정리

본 기사는 2026년도 인공지능학회 전국대회(JSAI2026)의 오거나이즈드 세션(Organized Session)

OS-31 「LLM 시대의 소프트웨어 공학」의 개최 리포트입니다. 저는 오거나이저(Organizer) 중 한 명이자, 발표자(5J2-OS-31a-03)이기도 한 입장에서 당일 진행된 12개의 발표를 「현장 엔지니어가 가져갈 수 있는 논점」으로 압축하여 정리했습니다.

• LLM은 소프트웨어 공학을 「코드를 빠르게 쓰는 도구」에 머물게 하지 않고, 설계·테스트·평가·조직·교육의 모든 것을 뒤흔들고 있다.
• 12개의 발표를 관통하는 최대 논점은 「사양의 암묵성(Implicit Specification)」 —— 명문화되지 않은 기대·의도·판단을 어떻게 다룰 것인가가 LLM 시대 소프트웨어 공학(SE)의 핵심이다.
• 또 다른 기저에 흐르는 주제는 「평가의 자기참조성(Self-referentiality of Evaluation)」 —— LLM-as-a-Judge를 비롯하여 「AI를 AI로 평가·검증하는」 순환의 신뢰성을 어떻게 담보할 것인가.
• 「개인의 생산성은 올라가는데 조직의 성과로 직결되지 않는다」는 **생산성의 역설(Productivity Paradox)**이 여러 발표에서 공유되었다. 병목 구간은 코딩이 아니라 프로덕트 매니지먼트(Product Management)와 조직 구조 측면에 있다.

항목	내용
대회	2026년도 인공지능학회 전국대회 (제40회, JSAI2026)
...
「LLM으로 코드를 짤 수 있다」 그 너머에서, 소프트웨어 공학 자체가 어떻게 변할 것인가 / 변하지 않을 것인가를 이론·실증·교육·거버넌스의 다각도에서 묻는 세션이었습니다.

▲ 마지막 날 오후임에도 불구하고 많은 분이 모여주셔서 감사합니다.

「AI 에이전트 = LLM을 부품으로 포함하는 소프트웨어 시스템」이라고 정의했을 때, 비즈니스 프로세스 사이를 잇는 「중개 프로세스(Intermediary Process)」에 서 있는 인간을 어떤 경우에 AI로 대체할 수 있는가 —— 라는 질문을 이론적으로 고찰합니다.

인간을 기계로 대체할 때의 이점으로 노동 조건의 제약으로부터의 자유(24시간 365일, 해고 용이, 복지 비용 불필요), 보안(「인간은 정보 보안의 가장 취약한 부분」, AI는 뇌물이나 미인계가 통하지 않음), 안정성·재현성·테스트 가능성(동일 조건에서 반복하면 출력은 일정 분포로 수렴, 가정 조건에서의 반응 테스트도 가능), 프라이버시(사람에게는 보여주고 싶지 않지만 기계라면 괜찮다는 심리)를 정리했습니다. 「할루시네이션(Hallucination)이나 설명 불가능성은 AI 특유의 결점이 아니라 인간에게도 나타나는 현상이다」라는 지적도 날카로운 관점이었습니다.

그럼에도 대체가 진행되지 않는 핵심은 **명문화되지 않은 「암묵적 기대(Implicit Expectation)」**입니다. 예로 든 것이 대형 외식 체인 음식점에 도입된 생성 AI 주문 로봇입니다. 명시적인 기대는 「주문에 응하는 것」이지만, 암묵적인 기대에는 「손님이 갑자기 쓰러지면 대응하는 것」이 포함됩니다. 민법의 선관주의 의무(선량한 관리자로서 당연히 해야 할 일을 해야 하는 의무)에 AI는 응할 수 없습니다. 나아가 민간 여객기의 항공 기관사가 2명으로 운항 인원이 줄어든 역사(자동화로 인해 워크로드(Workload)는 2명으로 제어 가능하며, 3명째가 극적으로 안전성을 높이는 것은 아님)를 보조선으로 삼아, 자동화의 과거 사례로부터 배울 점이 많음을 보여줍니다. 결론은, 기대를 명시적이고 망라적으로 기술할 수 있는 중개 프로세스는 자동화할 수 있지만(엘리베이터 안내원, 전화 교환수 등), 암묵적 기대가 남는 경우에는 즉각적인 대체가 어렵다는 것입니다. 다만 LLM은 인간의 「상식」을 잘 알고 있으므로 잘 활용할 수 있는 가능성이 있다고 합니다.

주목 포인트:
「명문화할 수 있는 중개 프로세스」인지 여부가 당면한 AI 대체의 경계선이 된다.

생성 AI를 활용하는 기업 20개사 이상에 대한 인터뷰(NEDO 「AI 세이프티 강화에 관한 연구개발」 사업)를 바탕으로, 성과를 **「생성 AI 실천 가이드와 기업 사례집」**으로 공표한 발표입니다. 당초에는 「공통된 AI 세이프티 관점을 정리하고 평가 벤치마크(Benchmark)를 만들어 공개하면 각 기업이 사용할 것이다」라는 목표였으나, **격차(Gap)**에 직면하게 됩니다. 어느 기업도 벤치마크를 사용하고 있지 않았고, 대처해야 할 리스크는 제각각이라 공통점이 거의 없었습니다. 그리고 각 기업은 「AI 세이프티를 확립한 후 본업에 도입」하는 것이 아니라, 이용을 확대하면서 단계적으로 AI 세이프티를 확립하고 있었다고 합니다.

이후의 **발견 (Discovery)**이 시사하는 바가 컸습니다. 개발 방법론도 AI 세이프티 (AI Safety)도 애자일 (Agile)에 기반한 학습과 개선이며, AI 거버넌스 (AI Governance)는 「AI를 활용하지 않을 리스크」에 대한 대응이기도 합니다. 이를 GenAIOps (DevOps를 생성형 AI용으로 확장하여 AI 세이프티 및 AI 거버넌스를 포함)로 체계화합니다. MLOps에서는 「개발·운영 vs 데이터의 리스크 관리」가 대립하기 쉬웠던 반면, GenAIOps에서는 업무 전문가가 팀의 일원이 되어 이네이블링 팀 (Enabling Team)을 통해 협조하는 구조 (ISO/IEC 42001 등을 참조)를 제안합니다. 구현 사례로는, 어느 온라인 약국의 에이전트 사례 —— 문의를 규칙과 LLM으로 분류하고, 에이전트로 대응이 불가능하면 약사에게 폴백 (Fallback)하는 에이전틱 워크플로우 (Agentic Workflow) —— 및, 어느 기업의 ISO/IEC 42001 인증 취득 사례 (모든 업무를 한 번에 인증 범위로 잡지 않고 단계적으로 확대, 기존 ISMS를 AI로 확대)가 소개되었습니다.

그리고 본 기사 서두에서 언급한 생산성의 역설 (Productivity Paradox). McKinsey 조사에 따르면 88%의 조직이 AI를 이용하지만, 전사적 스케일링 (Scaling) 단계는 약 3할에 불과하며, 실질적인 수익 효과를 얻는 「하이 퍼포머 (High Performer)」는 **전체의 6%**입니다. 이들은 AI를 통한 비즈니스의 근본적인 변혁을 타사보다 3.6배 더 강력하게 지향하고 있다고 합니다. 병목 현상 (Bottleneck)은 코딩이 아니라, PM 및 조직 구조 측면에 있습니다.

주목 포인트: 방법론을 연마하는 것만으로는 닿을 수 없다.

조직 설계야말로 LLM 활용의 병목이다. AI 세이프티는 「확립한 후 도입」하는 것이 아니라 「사용하면서 키워나가는 것」이다.

관련 자료: 생성형 AI 실천 가이드와 기업 사례집

오거나이저 중 한 명인 저 자신의 발표입니다. 출처는 MLSE 「LLM 도메인 적용 WG」 워크숍입니다. 메시지는 **「한정된 리소스 안에서 『무엇을 평가하고, 무엇을 과감히 평가하지 않을 것인가』를 근거와 함께 결정하고 기록하는 것」**입니다.

평가 대상이 Chatbot형 → Agent형으로 진화하며, 도구 선택·실행 계획·중간 상태·회복성·인간 개입과 같은 관점이 새롭게 추가되는 한편, 역할이 다른 국내 3대 가이드라인 —— AI 사업자 가이드라인 (원칙: Why/What) / AI 세이프티에 관한 평가 관점 가이드 (안전성 관점) / AI 프로덕트 품질 보증 가이드라인 (LLM 편) (구체적인 평가 방법: How) —— 은 스코프 (Scope)와 입도 (Granularity)가 달라 단순 통합할 수 없습니다. 어떤 가이드라인(GL)도 「관점·방법」은 제시하지만 「한정된 리소스 하에서의 우선순위 설정」은 제시하지 않는다는 것이 문제의식이었습니다.

이에 따라 3단계 (① 시스템 특성 파악 ② 평가 관점 추출·통합 ③ MoSCoW = Must/Should/Could/Won't를 통한 우선순위 설정)를 제시합니다. 판정은 영향도·발생 가능성·가치 기여도의 3축으로 수행하며, Won't (과감히 평가하지 않음)에는 이유를 명시합니다. 대조적인 2가지 사례 (음식점 주문 Bot / 여행 수배 Agent)에 적용해 보니, 시스템 유형에 따라 Must의 내용이 바뀌었습니다 (Bot = 사실성·안전성 / Agent = 도구 활용·제어 가능성). 한편, 두 사례 모두 공정성은 Won't (차별 리스크가 상대적으로 낮음, ※이용자층 확대·다중 공급업체화가 발생하면 Could로 승격된다는 트리거 조건부)로 판단했습니다.

「Won't 명시」는 AI 사업자 가이드라인이 요청하는 투명성·책임성 (Accountability) / 리스크 기반 접근법 (Risk-based Approach)의 구현이기도 합니다. 「평가하지 않음」은 「평가하지 않아도 된다」는 보증이 아니라, 상황 변화에 따른 지속적인 재검토의 기점 —— 이 점이 본 발표의 주안점입니다. 한계점으로는 우선순위의 객관적 기준이 미확립 (정량화가 과제), 에이전트 사례의 축적 부족, 운영 페이즈 (Phase)로의 확장을 자인하고 있습니다.

주목 포인트: 망라적 평가는 비현실적이다.

「과감히 평가하지 않을 것을 근거와 함께 기록하는 것」이 가이드라인 시대의 품질 보증 실효성을 높인다.

본 발표는 우선 「LLM 시대의 SE (Software Engineering)」를 세 가지 방향으로 정리합니다. LLM for SE (LLM으로 SE를 지원) / SE for LLM (LLM 애플리케이션 자체의 공학)에 더해, 세 번째 방향인 SE for LLM-Embedded Software (LLM을 주인공으로 삼지 않고, 통상적인 소프트웨어의 일부분으로組み込む(組み込む, 포함시키는) 측면의 설계)를 본 발표의 위치로 명시합니다. 특히 결정론적인 거동 (Deterministic Behavior)이 기대되는 시스템에의 임베딩 (Embedding)을 다룬다는 점이 특징입니다.

기존의 소프트웨어 부품이 암묵적으로 전제해 온 사항들——①결정성 (Determinism) (동일한 입력에는 동일한 출력) ②상시 이용 가능성 (Availability) (호출하면 반드시 동작) ③거동의 보장 (Guaranteed Behavior)——은 모두 '결정론적' 전제 위에 성립합니다. 하지만 LLM은 출력이 분포(Distribution)로서 반환되기 때문에 이 전제가 무너집니다. 온디바이스 LLM(Chrome 내장 Gemini Nano, 린 캔버스 지원 앱 사례)에서는 확률적 부품의 성질에 더해 실행 형태 고유의 제약이 더해지며, 이를 3가지 유형 (계산 자원 / 불확실성 / 실행 환경)으로 정리합니다.

그 위에서 제시된 설계 패턴은 명쾌했습니다.

폴백(Fallback)을 통상계로: 실패나 이용 불가능을 예외 처리(Exception Handling)가 아닌 '통상적인 상태의 일부'로서 처음부터 구조에 포함시킨다. 규칙 기반(Rule-based)으로 성립하는 구성을 베이스라인으로 삼고, LLM은 '사용할 수 있으면 품질이 올라가는' 확장 옵션으로 둔다. -
책임 분리 (Separation of Concerns): 결정론적으로 작성할 수 있는 부분은 결정론에 가깝게 작성하고, 확률적인 부품에 맡기는 범위를 필요 최소한으로 좁힌다 (수치 계산은 Python 코드 생성 및 실행, 정형 브라우저 조작은 Playwright로 절차 고정 등). "LLM을 어떻게 사용할 것인가" 이전에 "LLM에 맡길 범위를 어떻게 좁힐 것인가"를 결정한다. -
캐시의 목적이 가속화에서 안정화로 변질: 캐시 키(Cache Key)에 **「입력 텍스트 × 규칙 기반 평가 결과」**를 사용하여, 비결정적인 출력을 고정함으로써 응답을 안정시킨다.

요약하자면 **「결정론적으로 제약할 것인가 / 확률적인 상태 그대로 활용할 것인가, 그 선택은 데이터의 강건성 (Robustness)이 규정한다」**입니다. LLM을 **「신뢰할 수 없는 가능성을 내포하는 부품」**으로 간주하는 재정의가 설계 판단으로서 구체화되어 있었습니다.

주목 포인트:

폴백은 예외가 아닌 통상계. 비결정적인 부품을 결정적인 시스템에組み込む(組み込む, 편입시키는) 방법론.

참고 기사: Gemini Nano로 변하는 Web 앱 개발 ~ 온디바이스 AI로 실현한 「프라이버시 보호형 린 캔버스 지원 도구」

Fault Localization (결함 위치 특정, FL)은 클래스, 메서드, 행 등의 단위로 "버그일 확률 = 의혹치 (Suspiciousness Score)"를 예측하는 태스크입니다. 기존의 통계적 수법 (Tarantula/Ochiai/Dstar 등의 SBFL/MBFL)도, 머신러닝·LLM 수법도, 개발자가 작성한 테스트 오라클 (Test Oracle)이나 사양서, 대상 언어의 버그 데이터를 필요로 하며, 이를 작성하는 데 시간과 노력이 들한다는 것이 과제 의식입니다. 본 연구는 소스 코드에 관한 정보만으로 FL을 수행하여 개발자의 부담을 줄이는 것을 목표로 합니다.

제안 수법은 3단계입니다. ①의도 사양 작성 (소스 코드, 호출 관계, 메서드 명으로부터 개발자가 의도한 사양을 LLM으로 추정하여 테스트 및 구현의 '정답 데이터'로 사용) ②테스트 작성 (의도 사양과 소스 코드로부터 논리 커버리지 (Logical Coverage)를 최대화하는 입력과 의도에 부합하는 기대 출력을 생성) ③의혹치 산출 (테스트 입력에 대한 실제 출력을 **Chain of Thought (CoT)**로 트레이스 예측하여, 의도한 출력과의 불일치를 통해 의혹치를 0~100%로 산출).

실험은 Defects4J (v3.0.1)의 Lang (버그 58건, 평균 메서드 수 약 1954), 모델은 Qwen3-coder:30b, 평가 지표는 **MFR (Mean First Rank, 낮을수록 좋음)**을 사용했습니다. 각 단계의 기여도를 보면, LLM 단순 프롬프트 1218.91 → 사양과의 비교 980.47 → 제안 수법 (사양 + 테스트) 882.52로, 사양과 테스트의 비교가 정밀도를 끌어올리고 있었습니다. 정직했던 부분은 고찰입니다. "버그인 메서드의 순위가 크게 올라간 것이 아니라, 버그가 아닌 메서드의 순위가 내려간" 결과이며, 진정으로 효과를 보려면 버그를 트리거하는 테스트의 생성이 필요하다고 다음 과제를 명시한 점입니다.

주목 포인트:

「소스 코드만으로 FL」에 대한 도전. 핵심은 버그를 "밟게 만드는" 테스트를 자동 생성할 수 있는가에 달려 있음.

생성형 AI가 사양서로부터 코드 일체를 생성하는 개발에서는 코드 설계가 블랙박스화되어, **사양서의 내용이 부족하거나 오류 없이 코드로 반영되었는지 확인(정합성 확인)**하는 것이 어려워집니다. 게다가 기존에는 사양서와 코드를 직접 비교하기 때문에 정밀도가 담당자의 경험과 숙련도에 의존합니다. 본 연구는 사양서와 코드를 각각 모델로 변환하여 동일한 기준으로 비교함으로써, 이러한 공수 증대와 개인 의존성(属人化, 속인화) 문제를 해소하고 생성형 AI로 자동화하는 수법입니다.

7가지 정합성 확인 관점에 따라, 표 형식 모델 (Table-based Model) (데이터·파일·입출력·UI 연계 등의 요구사항이 적절히 정의되어 있는지)과 도식 형식 모델 (Diagram-based Model) (기능·조작·사상의 연결, UI 간의 상태 전이와 전이 조건의 일치)을 구분하여 사용합니다. 구현은 VS Code 확장 + GitHub Copilot의 Custom Agents (관점별로 역할 분담을 한 에이전트 군)로 자동화했습니다. 평가 대상은 Word 애드인 형식의 툴(사양 76쪽 / 코드 약 4.2만 행 / 기능 31종류)입니다.

결과는 매우 놀라웠으며, 수작업으로 전 항목을 확인하는 것에 비해 정합성 확인 공수를 97% 절감했고, **진양성률(True Positive Rate) 96.6% · 위양성률(False Positive Rate) 5.5%**를 기록했습니다. 주목할 점은 오검출이 위음성(False Negative)보다 위양성(FP)에 치우쳤다는 것과, 위양성의 76%가 사양서 기인이었다는 점입니다. 나아가 그 주된 원인은 "사람에게만 친숙한 기술(Human-friendly description)" — 예를 들어 이미지에서 유래한 표현이나, 도식으로만 설명되어 있는 부분(WebBrowser를 SVG 이미지로 나타내는 등)이었습니다. 즉, 위양성의 주된 원인은 수법(Method)이 아니라, 생성형 AI의 해석 능력(과 인간을 위해 작성된 사양)에 있다고 구분되었습니다.

주목 포인트: 정합성 확인은

공수 97% 절감이 가시권에 들어왔다. 다만 "사람에게만 이해되는 사양(이미지·암묵적 기술)"은 AI가 걸려 넘어지기 마련 — 사양 기술 방식 자체에 대한 질문이 던져진다.

20주년이 넘는 산업계 엔지니어 대상 소프트웨어 공학 교육 프로그램인 "Top SE"의 경험으로부터 (2025년·20기생은 수강생 57명 / 누적 900명 초과, 강사 61명, 실천 연습 15그룹). 우선 제시된 것은, LLM/AI for SE가 "맡기는 방법과 검증을 설계하는" 단계로 나아가고 있다는 현상 인식입니다 — 코딩 에이전트화(Coding Agent: PR 작성·버그 수정·테스트 작성을 비동기적으로 위임하고, 사람은 리뷰와 리스크 판단에 집중), CI/CD와의 접속, SDLC 전반의 자동화("점"에서 "선"으로), 품질·통제가 차별화 요소가 됨. 엔지니어의 역할은 "자신이 있어야 할 모습을 정의하고 달성하는 것"에서 "있어야 할 모습으로부터 맡기는 방법·안전망·검증을 설계하는 것"으로 이동한다고 정리합니다.

교육 측면에서는, 연간 코스의 강의에 생성형 AI 관련 신규 강의가 2023년부터 매년 업데이트되어 추가되고 있으며, 추상적인 테마를 강사가 제시하고 수강생이 구체화하는 "실천 연습"에서는 "LLM/AI & SE의 새로운 미래 탐구" 색채가 짙게 나타나고 있습니다. 상징적이었던 것은 형식 사양 기술의 실천적 활용을 쫓는 테마로, 이전에는 몇 명이서 1개 케이스를 다루었으나 2025년도에는 5명이 각각 서로 다른 케이스를 완수 — 생성형 AI로 학습과 탐구가 가속화되었으며, 형식 기법(Formal Methods)에 대한 흥미도 높아졌다고 합니다.

마무리는, 소프트웨어 공학의 원칙·기술을 AI 활용을 전제로 한 세계의 소양·기반으로 적합·진화시키는 것입니다. "프로덕트의 전달 방식", "책임지는 방식"은 유지하면서, 다소 점진적으로 흐르기 쉬운 상황 속에서, "유지보수를 그만두고 재생성하는" 것과 같은 파괴적·근원적인 패러다임 시프트를 어떻게 선도하고 체계화할 것인가라는 과제를 남겼습니다.

주목 포인트: 엔지니어 교육의 주제가 "만드는 힘"에서

"맡기는 방법·안전망·검증을 설계하는 힘"으로 이동하고 있다.

"AI 서비스 시스템 개발을 효과적으로 수행하고 싶다"를 출발점으로, 사업 부문과 IT 부문의 격차(자신의 활동이 프로젝트에 어떻게 기여하는지 불명확함 등)를 배경으로, 프로젝트 실천 노하우를 재사용 가능한 지식으로 체계화하는 시도입니다 (MLSE의 WG에서 2020~2022년도에 실시).

절차는, ① 프로젝트 실천에 공통되는 활동으로부터 **개발 모델 (참조 모델)**을 작성 ② 이를 바탕으로 실천가로부터 지견을 수집 ③ 베스트 프랙티스(BP)로 정비 — 과정을 통해 28개의 BP를 수집했습니다. 다만 "경험이 적은 실무자(특히 PM)는 사용할 수 있는 해결책이 있어도 알아차리지 못하지 않을까?"라는 문제의식으로부터, 해결책을 적용해야 할 결핍·징후를 "불길한 냄새(Smell)"로 연결하고, 나아가 안티 패턴 (Anti-pattern) (패턴명 / 불길한 냄새 / 해결책 / Force=적용 시의 압력·영향,의 4요소로 기술. 예: AP02 "너무 높은 기대")으로 정비했습니다. WS(온라인 툴 Mural)에서는 기존 28개 BP의 **53.6%**에 냄새가 연결되었고, 새롭게 9개가 추가되어 중복을 제외한 18개의 냄새를 얻었다고 합니다.

정리된 안티패턴은 AI 프로젝트 관계자인 실무자 200명을 대상으로 한 온라인 조사에서 유용성을 평가받았습니다. 모든 패턴에 대해 60% 이상이 "경험했다/향후 경험할 것 같다"라고 인식(평균 71.6%)하여, 실천 현장에서 유용한 안티패턴을 만들었음을 보여줍니다. LLM 시대로의 전개로서, 쇼난 회의(Shonan Conference) No.241 「Patterns and Practices in AI Engineering and Governance」에서의 논의를 소개합니다. 이는 **인간과 AI의 Co-Design (공동 설계)**을 전제로, 패턴 기술을 인간과 AI 각각의 특성에 맞춰 확장하고, 프로젝트의 문맥에서 "왜·어떻게 사용하는가"를 기술하는 **Project Language (프로젝트 언어)**라는 방향성입니다.

주목 포인트: 베스트 프랙티스(Best Practice)는 "가지고 있는 것"만으로는 사용되지 않는다.

"불길한 냄새(Code Smell)"와 결합될 때 비로소 현장에서 발화한다.

MLSE 「AI와 애자일 WG」의 성과(리포트 초판은 2026년 4월 공개 예정). Snowden의 Future Backwards에서 착안한 시나리오형 백캐스팅 (Scenario-based Backcasting)(2030년의 미래상 ← 비판적으로 본 현재 위치 ← 격차로부터 역산)을 통해, 문헌 조사(DORA 2025, TOSEM의 2030 로드맵 등)와 더불어 우시오 츠요시(Tsuyoshi Ushio)·요시하 류타로(Ryutaro Yoshiha)·우루시하라 시게루(Shigeru Urushihara) 등 입장이 다른 실무자 인터트뷰로 내용을 보강했습니다.

그려진 2030년의 미래상은 세 가지입니다. ① 병목 현상은 "이동"이 아니라 "해소"된다 (피드백 루프 자체가 고속화되어, "만들고 시도하고 배우고 버리는" 사이클이 형성됨) ② Copilot에서 Autopilot으로의 연속적 스펙트럼 (팀은 소수의 인간 + 다수의 AI 에이전트 군단으로 구성되며, 암묵지의 언어화를 통해 AI가 자율적으로 가동됨. 우루시하라 씨는 "마크다운 10페이지의 규칙으로 200개의 에이전트를 병렬 실행", 우시오 씨는 "지금 나는 에이전트의 매니저다"라고 언급) ③ 인간의 활동 영역 이동 (개발자 → 아키텍트/리뷰 책임자, PO는 전략·공감으로, 스크럼 마스터는 인간+AI 하이브리드 조직의 코치로 변화).

압권은 비판적인 현재 위치입니다. "인간적 기술이 (AI와의) 해자(Moat)다"라는 통설에 대해, 공감(ChatGPT가 의사보다 9.8배 높게 평가됨)·창의성(GPT-4가 토란 테스트 상위 1% 기록)·설득(64.4%로 인간을 초과) 측면에서 LLM이 추격 또는 능가하고 있음을 실증적으로 제시합니다. 나아가 AI의 구조적 한계(할루시네이션(Hallucination), 컨텍스트 의존적 태스크, Sycophancy(과잉 동조), 개념은 설명할 수 있지만 적용은 못 하는 "포템킨 이해(Potemkin Understanding)")와 인간+AI 협업의 함정—개입의 역설 (Paradox of Intervention) (인간+AI가 단독일 때보다 성능이 떨어짐, Vaccaro 등)·인지적 위축 (Cognitive Atrophy) (AI 의존으로 인해 비판적 사고가 저하됨, Lee 등)·협업에 의한 고립 (Isolation through Collaboration) (고독감·비생산적 행동, Meng 등)을 언급하며, 진정한 해자는 오히려 **신체성(Embodiment)·장기적 관계·문맥적 견고성(Contextual Robustness)**에 있다고 재정의했습니다. 미래를 위한 돌파구로서 지식 언어화의 공유 기반, HITL(Human-in-the-Loop)의 양에서 질로의 재설계 (Programming with Trust), 인재 육성 모델의 쇄신, 프로덕트 구조력의 조직적 획득이라는 4가지를 제시했습니다.

주목 포인트: "공감이나 창의성은 인간의 영역"이라는 전제는 이제 무조건적으로 둘 수 없다.

진정한 해자는 신체성·장기적 관계·문맥적 견고성으로 향한다.

LLM의 등장으로 대화 시스템(자연어로 인간과 정보를 주고받는, 특히 멀티턴(Multi-turn) 방식)은 기존 과제의 상당수를 해결하며 실용화가 진행되는 한편, 그 설계·구축·운용에 관한 지식은 아직 정리되지 않았다는 문제의식을 가집니다. 많은 연구 목표가 "사용자 만족도·경험의 향상"에 치우쳐 있고, 구축·운용 비용이나 리스크가 평가 항목에 포함되어 있지 않기 때문에 기술의 진전도 불충분하며, 그렇기에 소프트웨어 공학적 연구가 필요하다고 논지를 세웁니다.

이에 대화 시스템의 라이프사이클을 6개 페이즈(요구사항 획득·분석 / 설계 및 사양 책정 / 구축 / 테스트 / 배포·운용·모니터링·유지보수 / 지속적 개선)로 나누고, LLM 특유의 과제를 나열합니다. 요구사항(개인정보·기밀정보 유출, 할루시네이션·편향, 프롬프트 인젝션(Prompt Injection) 등의 공격, API 이용료·HW 비용·전기료 등의 비용, 지연 시간), 설계(아키텍처의 SE(Software Engineering)적 평가, 요구사항에 맞춘 모델 선택, 음성 인식·음성 합성의 연결을 고려한 설계), 구축("프롬프트웨어 공학(Promptware Engineering)" = 프롬프트를 소프트웨어로 취급[Chen 25] 관점에서의 프롬프트 관리), 테스트(LLM 기반 사용자 시뮬레이터, 결과로부터의 문제 발견 = LLM-as-a-Judge 포함, 음성 입출력 + LLM 기인 문제), 운용(상용 LLM의 성능 변화 탐지, 로그를 통한 문제 발견). LLM 대화 시스템 개발의 "전체 지도"입니다.

향후 방향성으로서, 대화 시스템 연구자·소프트웨어 개발자·비즈니스 담당자 등 입장이 다른 관계자들의 공통 이해를 촉진하는 「디자인 패턴 (Design Pattern)」 을 제시했습니다.

주목 포인트: 대화 시스템의 평가는 만족도만으로는 부족하다.

비용·리스크·음성 I/O·상용 LLM의 변화까지 포함해야 비로소 “공학 (Engineering)”이 된다.

풍경 사진과 달리 캐릭터는 시각적으로 동일성 판정이 용이하며, 지적 재산권이 있는 캐릭터와 흡사한 생성은 기업 사용 시 레퓨테이션 리스크 (Reputation Risk, 평판 리스크)의 핵심입니다. 게다가 학습 데이터셋은 미상(unknown)이고 내부 구조는 불가시적(invisible)이기 때문에 리스크를 평가하는 수법이 확립되지 않았으며, 결과적으로 실제 리스크 수준을 초과하여 제공 범위와 용도를 제한하게 됩니다. 이 「과도한 제한」을 해결하기 위해, 이미지 생성 AI의 「저작물 재현 유도 내성」을 배포 전에 기계적으로 평가하는 프레임워크를 제안합니다.

메커니즘은, ①별도의 LLM으로 평가 대상 캐릭터를 생성 (장르 〈게임/애니메이션·만화/영화/음악·아이돌/Vtuber/특촬…〉 × 글로벌/국내 한정 × 메이저/니치,로 작품·캐릭터명을 선정) ②캐릭터명을 포함한 직접 지시 (Direct Prompt) 와, 명칭을 숨기고 외형적 특징으로 표현하는 간접 지시 (Indirect Prompt) 두 가지 방식으로 생성 ③일반적인 이미지 검색의 최상위 결과를 「정답 이미지」로 삼고, 별도의 멀티모달 AI로 의미적·구조적 유사도를 0~100%로 판정하는 흐름입니다.

지견이 구체적이었습니다. DALL-E3는 캐릭터명의 직접 지시는 가드(Guard)로 거부하는 반면, 외형 특징의 간접 지시로는 흡사한 생성이 일어날 수 있음을 확인했습니다. 게다가 일본어보다 영어 프롬프트(Prompt)의 유사도가 높은 경향을 보였습니다. 서비스 비교(FLUX1/Grok3/DALL-E3)에서는 영어 간접 지시는 모두 유사도 60%대까지 비슷하게 분포하는 반면, FLUX1만은 일본어 프롬프트에서 유사도 20% 이하가 8할 이상을 차지했습니다. 이는 일본어 필터가 작동하고 있거나 일본어 어노테이션(Annotation)이 한정적이기 때문이라고 추정할 수 있습니다. 총괄적으로 「최대 유사도」가 아닌 분포로 파악해야 하며, 「영어 × 캐릭터 브랜드/애니메이션·만화 장르에 대한 간접 지시」 프롬프트의 사전 평가가 유도 저지에 유효하다고 구분했습니다.

주목 포인트: 저작권 리스크는

서비스 간 상대 비교가 가능한 단계로. 단, 방어의 허점은 간접 지시 × 영어 — 이름을 말하지 않아도 “그것”은 생성될 수 있다.

리니어형(Linear) 채팅 UI에는 두 가지 문제점이 있습니다. ①화제가 바뀌면 AI 측은 입력 컨텍스트(Context) 증대로 인해 응답 품질이 저하되고, 사용자 측은 이력 스크롤이나 프롬프트의 장문화(Long-context)를 강요받습니다. ②AI의 여러 제안에 대해 즉시 한 가지 안으로 수렴해 버려, 유력한 대안이 기각됩니다. 본 연구는 대화 이력을 트리 구조(Tree Structure)로 분기·시각화하고, 선택 노드에서 루트(Root)로 이어지는 경로만을 컨텍스트로 사용하는 UI (모델 GPT-4o)를 제안하였으며, 리니어형과의 피험자 내 실험 (Within-subjects experiment) (20명, 평균 21.4세, 「예산 1인당 8만 엔·친구 4명과 2박 3일 여행 계획」을 최소 10분~최대 15분, 7분 시점에서 구두로 조건 추가)을 통해 검증했습니다.

세 가지 가설에 대해 결과는 모두 「부분적으로 지지」 되었습니다. H1 (인지 부하 저감·수용성) … SUS(사용성)는 트리형이 유의미하게 낮은 반면, UTAUT의 유희적 동기·UX의 유희적 품질은 유의미하게 높았습니다 (NASA-TLX는 유의차 없음). H2 (입력 비용 저감·신뢰감 향상) … 평균 입력 글자 수는 유의미하게 감소했으나, AI에 대한 신뢰감은 유의차가 없었습니다. H3 (다각적인 비교 검토 촉진) … 명사의 유니크(Unique) 수는 유의차가 없었으나, 토픽 수·발화 수·태스크 시간이 유의미하게 증가하여 대화 내용의 다양성 향상이 나타났습니다. 요컨대 **「사용 편의성에서는 뒤처지지만, “즐거움”과 “다각적 검토”에서는 승리한다」**고 할 수 있습니다. 한계점으로는 참가자의 AI 채팅 숙련도 편차, 신규성에 따른 일시적 평가 가능성, 태스크 결과물의 질(Performance) 미평가 등을 꼽았습니다.

주목 포인트: 채팅 UI는 「빠르게 한 가지 안으로」가 정답이 아니다.

분기하여 조망하는 설계가 비교 검토에서는 다양성을 끌어낸다.

12개의 논문을 나열하며 보인, 오거나이저(Organizer) 관점에서의 논점을 공유합니다.

암묵적 기대의 언어화 (31a-01), 의도적으로 평가하지 않는 판단의 명시 (31a-03), 의도 사양의 추론 (31a-05), 이미지 전용 사양의 문제 (31a-06) — 모두 「명문화되지 않은 사양」이라는 동일한 벽에 부딪혀 있습니다. LLM이 다룰 수 있는 것은 명문화된 사양이며, 암묵적인 부분이 바로 남겨진 난관입니다.

31a-02와 31a-04가 공유하는 관점입니다. 다만, **부품의 단위·책임 경계·인터페이스(Interface, 계약)**를 어떻게 정의할지에 대한 통일된 견해는 아직 없습니다. '신뢰할 수 없는 가능성을 내포하는 부품'을 어떻게 포함할 것인가는 소프트웨어 공학(Software Engineering)의 고전적인 테마가 재등장한 것이기도 합니다.

후반부에는 머신러닝 공학 연구회 계열의 '지식 체계화' 지향(31b-01, 02, 04)이 이어지는 가운데, 31b-03만이 낙관론에 대해 비판적인 렌즈를 투사합니다. '정리하며 나아가는' 진영과 '전제를 의심하는' 진영 사이의 대화가 논의를 심화시키는 축이 되었습니다.

LLM-as-a-Judge(31a-02, 31b-04), AI에 의한 저작권 유사도 판정(31b-05), AI에 의한 사양 정합성 확인(31a-06)——이들은 모두 'AI를 AI로 평가·검증하는' 순환을 내포합니다. 이 순환의 신뢰성을 어떻게 근거 지을 것인가는 LLM 시대의 모든 평가론에 관통하는 질문입니다.

오픈된 장소 특유의 자극적인 질의응답이 오갔습니다. 인상 깊었던 문답을 발췌합니다.

회장과 Slack 양쪽에서 가장 뜨거웠던 논점. **"선관주의 의무(Duty of Care)와 같은 암묵적인 기대에 각 LLM(GPT/Gemini/Claude)이 어느 정도 부응할 수 있는지에 대한 벤치마크가 있는가"**라는 질문에 대해, 마루야마 씨는 **"선관주의 의무는 망라성을 실질적으로 담보할 수 없다. 법의 운용은 문제가 발생한 사후에 그 시점의 사회 통념에 따라 결정된다"**라고 응답했습니다. 모든 암묵적인 기대를 망라적으로 명문화할 수 없는 이상, 그 부분은 사람이 담당해야 할 역할이라는 정리로 마무리되었습니다.

첫걸음으로는 'ChatGPT로 브레인스토밍(Wall-hitting)을 하며 발생할 수 있는 일들을 나열하게 하는 것'이 현실적입니다. 본질적으로는 AI의

프레임 문제(Frame Problem)로 귀결되며, FMEA(고장 형태 및 영향 분석)처럼 '이 부품이 고장 나면 어떤 일이 발생하는가'를 키워드로 브레인스토밍을 통해 나열해 나간다는 지침도 제시되었습니다.

**"확률적인 테스트를 할 수밖에 없어 시행 횟수가 늘어나고, 시간과 토큰(Token) 비용이 증가한다"**는 현장의 고민이 공유되었습니다. 결정적인 수법은 아직 없지만, 평가는 로컬 LLM(소형·고속), 실운용은 리치(Rich)한 API라는 역할 분담을 통해 비용을 부분적으로 절감한다는 실천적 지혜가 오갔습니다(저 자신도 로컬 LLM을 병용하여 토큰 비용 절감을 시도하고 있습니다).

사양↔코드 정합성에 관한 발표에 대해, 회장으로부터 **"기능 ID를 부여함으로써 사양서·코드·테스트 출력의 일관성이 향상되었다"**라는 지견 공유가 있었습니다. V자형 개발 모델에서 각 요소에 ID를 부여하고, 코딩 에이전트(Coding Agent)가 이를 잘 작성하도록 만드는 수법입니다. 발표 수법과는 별개로, 식별자(Identifier) 설계가 AI 시대의 추적성(Traceability)의 핵심이 될 것이라는 시사점으로 다가왔습니다.