ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
연번기업명주제상세 설명
2
1(주)블루웍스멀티에이전트 기반 건물 에너지 수요예측 및 예측근거 설명 시스템건물 에너지 예측을 고정된 머신러닝 방식으로 수행했을 때, 다양한 이벤트 상황(기상 이변, 행사 등)일 때는 예측이 크게 빗나간다. LLM 에이전트로 모델 선택 및 오차보정을 수행하여, 다양한 이벤트 상황일 때에 고정된 머신러닝 방식보다 예측 정확성과 강건성을 개선할 수 있는지 확인한다.
3
2(주)블루웍스Physical AI를 위한 LeRobot 공개데이터 기반 SO-101 로봇 동작의 Isaac Sim 시각화LeRobot 공개데이터에는 로봇의 관절 상태, 제어 명령, 카메라 영상 등이 시간순으로 저장되어 있다.

본 과제에서는 SO-101 로봇의 LeRobot 공개데이터를 불러와 관절 데이터를 Isaac Sim 로봇 모델에 적용하고, 실제 촬영 영상과 시뮬레이션 동작을 함께 재생하는 시각화 시스템을 개발한다.

학생들은 로봇 데이터 구조, 관절 좌표 변환, 로봇 시뮬레이션, 영상 동기화 및 시각화 기술을 종합적으로 경험하게 된다.
4
3(주)오키코리아<타임캡슐 앱 '메멘토(Memento)' 프로젝트>

미래의 특정 시점이나 조건이 충족될 때, 지정한 사람에게 암호화된 영상·사진·텍스트를 전달하는 디지털 타임캡슐 앱		* 핵심 컨셉
- 클라우드가 '기록의 보관'이라면, 메멘토는 '감정의 배달' — 미래의 나 또는 소중한 사람에게 메시지를 봉인해 전달
- 재미(친구와의 내기, 10년 후 나에게)부터 디지털 유언(마지막 인사, 계정 정보 전달)까지 세대별 활용 가능

* 주요 기능
- 캡슐 생성: 영상·음성·사진·텍스트를 담아 암호화(E2EE) 후 봉인
- 개봉 조건 3가지:
--- 시간 지정 (특정 날짜, 매년 반복)
--- 이벤트 기반 (뉴스 키워드, GPS 위치 등 외부 조건 충족 시)
--- 부재 감지 — 사용자가 일정 기간 앱 활동이 없으면 '디지털 유언'으로 전달
- 지정 검증인 시스템: 신뢰하는 지인 1~3인이 사용자의 부재를 교차 확인해야 캡슐이 개봉되는 오작동 방지 장치
5
4(주)오키코리아회의 중 화이트보드 사용하는 회의 장면 이해하여 회의 결과물 만들어주는 AI* 회의 영상 촬영
* 영상 중 화면 캡처. 분당 D:D 정도 충분할 듯. 타임스탬프 추가. (영상 그대로 저장하면 토큰값 엄청 소)
* STT 처리 후 타임스탬프.
* 영상캡처와 STT결과물 분석해서 회의록 결과물 만들어 줌.

결과물의 형태: 사업계획서, Flowchart, 설계서 등
6
5플리트소프트 주식회사AI 기반 로컬 코드 보안·이슈 점검 CLI 도구Claude Code, Codex 등 AI 코딩 도구를 활용해 작성하거나 수정한 로컬 코드를 개발 완료 또는 Git 커밋 전에 점검하는 CLI 도구를 개발한다.

보안 취약점을 중심으로 정책, 법률, 기획 및 개발 관점에서 검토가 필요한 사항을 식별하고, 발견된 문제의 원인과 개선 방향을 개발자가 이해하기 쉬운 형태로 안내하는 것을 목표로 한다.

프로젝트 범위에 따라 정적 분석 도구 및 취약점 데이터베이스를 연동하거나, 사용 중인 프레임워크·라이브러리 버전의 알려진 취약점을 검사하여 자동으로 안내하는 기능까지 확장한다.

완성된 결과물은 오픈소스로 공개하여 실제 사용자의 피드백을 받는다.
7
6플리트소프트 주식회사AI 도구 간 프로젝트 컨텍스트 자동 동기화 도구IDE, CLI 등 서로 다른 환경에서 사용하는 AI 도구 간에 프로젝트의 주요 맥락을 자동으로 공유하고 갱신하는 도구를 개발한다.

프로젝트 구조, 기술 스택, 작업 이력, 주요 의사결정 및 현재 진행 상황을 구조화하여 관리함으로써, 사용자가 AI 도구를 변경할 때마다 동일한 내용을 반복해서 설명해야 하는 불편을 줄이는 것을 목표로 한다.
8
7플리트소프트 주식회사기능 변경에 따른 회귀 테스트 자동화 도구신규 기능 추가 또는 기존 코드 변경 시 기존 기능에 문제가 발생하지 않았는지 자동으로 확인하는 회귀 테스트 도구를 개발한다.

변경된 코드와 영향 범위를 분석하여 필요한 테스트를 선정하거나 생성하고, 테스트 결과와 잠재적인 영향 범위를 개발자가 이해하기 쉬운 형태로 제공하는 것을 목표로 한다.
9
8플리트소프트 주식회사통화 내용 기반 프로젝트별 업무 정리 서비스업무 통화의 녹음 파일 또는 음성 인식 결과를 분석하여 대화의 맥락, 주요 논의 사항, 의사결정 내용 및 후속 업무를 자동으로 정리하는 서비스를 개발한다.

통화 중 언급된 고객명, 프로젝트명, 담당자 및 일정 등의 정보를 식별하고 기존 프로젝트와 연결하여, 프로젝트별 회의 기록과 할 일을 자동으로 분류·누적하는 것을 목표로 한다.

개인정보와 통화 내용이 포함될 수 있으므로 사용자 동의, 데이터 저장 범위, 접근 권한 및 보관·삭제 방식 등을 함께 고려하여 설계한다.
10
9무신사패션 트렌드의 ‘초기 신호’를 정의하고 탐지하는 시스템패션 회사에서 “지금 무엇이 유행하는가”를 아는 것은 중요하지만, 실제로는 질문부터 모호한다.
검색량이 늘면 트렌드인지, 판매량이 늘면 트렌드인지, SNS에서 특정 표현이 많아지면 트렌드인지, 일부 선도 집단이 먼저 반응하면 트렌드인지 합의되어 있지 않습니다. 판매가 이미 크게 오른 뒤에는 트렌드를 발견한 것이 아니라 결과를 확인한 것에 가깝다. 우리가 필요한 것은 남들이 모두 아는 시점보다 조금 먼저 변화를 감지할 수 있는 신호이다.

학생 과제의 첫 단계는 탐지 모델을 만드는 것이 아니라 ‘트렌드’와 ‘초기’의 뜻을 정의하는 일이어야 한다.
패션을 소비하는 사람, 패션 콘텐츠를 만드는 사람, 상품을 기획하거나 판매하는 사람, 패션에 큰 관심이 없는 일반 사용자 등 서로 다른 집단을 인터뷰할 수 있다.
인터뷰에서는 “요즘 무엇이 유행한다고 생각하세요”만 묻기보다, 최근 유행이라고 느낀 사례를 언제 처음 보았는지, 무엇을 보고 그렇게 판단했는지, 이후 어떤 사건 때문에 확신하게 되었는지를 시간순으로 복원하도록 하는 편이 좋다.

데이터는 공개된 검색 추이, 소셜 게시물, 쇼핑몰 랭킹, 콘텐츠 제목과 본문, 댓글, 중고 거래 가격, 품절과 재입고 빈도, 인플루언서 착용 사례 등에서 선택할 수 있다. 중요한 것은 데이터를 많이 모으는 것이 아니라 각 데이터가 어떤 단계의 신호인지 가설을 세우는 것이다. 검색량은 관심의 신호일 수 있지만 구매 의사는 아닐 수 있고, 판매량은 확정 신호에 가깝지만 이미 늦을 수 있다. 중고 가격의 상승은 희소성과 수요의 결합일 수 있고, 서로 관계없는 커뮤니티에서 같은 표현이 독립적으로 등장하는 것은 확산 신호일 수 있다.

MVP는 “향후 트렌드를 모두 맞히는 모델”일 필요가 없다. 과거 6~12개월의 공개 사례 세 개를 골라, 당시 시점으로 시간을 되돌렸을 때 어떤 신호가 어떤 순서로 나타났는지를 보여주는 타임라인과 탐지기를 만들 수 있다.
시스템은 단순히 트렌드 점수를 출력하지 말고, 어떤 신호때문에 후보로 올렸는지 근거를 설명해야 한다. 또한 인위적인 광고 집행이나 일시적인 바이럴처럼 트렌드로 오인할 수 있는 반례를 함께 보여주어야 한다.

완료 조건은 예를 들어 다음처럼 잡을 수 있다. 과거 사례 중 최소 두 건에서 대중적 확정 시점보다 앞선 후보 시점을 제시하고, 그 판단에 기여한 신호를 사람이 추적할 수 있어야 한다.

반례 데이터셋에서 무조건 높은 점수를 내지 않아야 하며, 인터뷰 대상자 다수가 설명을 보고 “왜 이 후보가 올라왔는지” 이해할 수 있어야 한다. 모델 정확도 하나가 아니라 조기성, 설명 가능성, 오탐 비용을 함께 평가하는 과제이다.

이 과제의 교육적 핵심은 AI 모델을 잘 만드는 데만 있지 않다. “관찰 가능한 현상에서 추상 개념을 어떻게 조작적으로 정의하는가”, “서로 다른 약한 신호를 어떻게 조합하는가”, “정답이 늦게 생기는 문제를 어떻게 검증하는가”를 경험하게 하는 데 있다.
11
10무신사발견한 트렌드 후보를 ‘확정하거나 기각하는’ 검증 시스템첫 번째 과제와 연결할 수도 있고 독립 과제로 운영할 수도 있다.

현실에서는 후보를 많이 찾는 것보다, 그중 무엇에 실제로 투자할지를 결정하는 일이 더 어렵습니다. AI는 트렌드처럼 보이는 후보를 매우 많이 생성할 수 있지만, 모든 후보를 상품 기획이나 마케팅에 반영할 수는 없다. 따라서 탐지보다 검증의 병목이 더 크게 생긴다.

학생들은 하나의 후보가 들어왔을 때 어떤 추가 증거가 있으면 확신을 높이고, 어떤 증거가 있으면 기각할지를 설계할 수 있다.
예를 들어 특정 스타일 키워드가 급상승했다면 서로 독립적인 채널에서도 같은 변화가 나타나는지, 특정 브랜드 하나의 캠페인 효과는 아닌지, 관련 상품의 클릭과 구매가 함께 움직이는지, 특정 연령이나 성별에만 국한된 현상인지, 표현만 다르고 같은 개념인 키워드가 흩어져 있지는 않은지를 검증한다.

여기서 AI는 근거를 수집하고 후보를 군집화하고 반대 증거를 찾는 역할을 할 수 있다. 그러나 최종 판단까지 AI에게 그대로 맡겨서는 안 된다.
시스템은 “확정”, “보류”, “기각”의 판단과 함께 증거의 출처, 증거 간 독립성, 남은 불확실성을 보여주어야 한다. 특히 스스로 만든 가설을 스스로 지지하는 자료만 찾는 확증편향을 막기 위해, 반드시 반증을 시도하는 별도 에이전트나 절차를 두게 할 수 있다.

완료 조건은 미리 선정한 과거 후보군을 대상으로, 당시 사용할 수 있었던 데이터만 주었을 때 판단 근거를 재현하는 것이다. 학생은 결과가 틀린 사례도 숨기지 않고, 왜 틀렸는지와 어떤 추가 신호가 있었으면 막을 수 있었는지를 설명해야 한다.

이 과제는 예측 성능보다 의사결정 절차의 투명성과 반증 가능성을 평가하는 것이 좋다.
12
11무신사현업의 복잡한 스프레드시트를 실제 운영 시스템으로 바꾸기많은 조직에는 개발팀이 다 만들어 주지 못한 관리자 기능을 엑셀이나 스프레드시트로 대신 운영하는 현실이 있다.

여러 시트가 서로 참조하고, 작성자만 아는 함수와 색상 규칙이 있고, 특정 셀을 복사한 뒤 다른 시스템에 다시 입력하며, 오류가 나면 누군가의 기억에 의존해 고칩니다. 겉으로 보면 단순한 어드민 제작 과제지만, 실제 핵심은 화면 구현이 아니라 스프레드시트 속에 숨어 있는 업무 규칙과 역할을 복원하는 일이다.

학생들에게 학교 동아리, 학과 행정, 소규모 사업자, 연구실, 비영리 단체 등에서 실제로 쓰는 복잡한 시트를 하나 찾게 할 수 있다. 최소 10명의 인터뷰가 어렵다면 같은 프로세스의 서로 다른 역할을 맡는 사람을 반복 관찰하고, 업무가 시작되어 끝날 때까지의 흐름을 직접 따라가게 하는 것이 좋다. “어떤 기능이 필요하세요”보다 “지난번에 이 일을 처리한 과정을 화면과 함께 보여주세요”, “실수했던 사례를 재현해 주세요”, “이 셀을 왜 바꾸나요”, “누가 이 결과를 믿고 다음 행동을 하나요”를 묻게 해야 한다.

MVP는 모든 기능을 웹으로 옮기는 것이 아니다. 가장 비싸거나 위험한 한 개의 흐름을 골라, 입력·판단·승인·결과 전달까지의 업무를 재구성한다.
기존 스프레드시트를 한동안 함께 유지하면서 동일한 입력을 양쪽에 넣고 결과를 비교하는 Shadow Diff 방식도 좋은 검증이다.
새 시스템이 기존과 다른 결과를 냈다면 무조건 버그라고 단정하지 않고, 기존 시트의 숨은 버그인지 새 구현의 회귀인지 사람이 판정하게 한다.

완료 조건은 기능 수가 아니라 운영 결과로 잡아야 한다.
신규 사용자가 기존 담당자의 구두 도움 없이 핵심 업무를 끝낼 수 있는지,
과거 사례를 다시 실행했을 때 결과가 보존되는지,
잘못된 입력이 조용히 다음 단계로 넘어가지 않는지,
누가 어떤 판단을 했는지 추적 가능한지,
처리 시간이나 재작업 횟수가 실제로 줄었는지를 증명해야 한다.

이 과제는 학생이 “노가다”라고 느낄 수 있다. 그러나 바로 그 점이 교육적이다. 현실의 소프트웨어는 깨끗하게 정의된 알고리즘 문제보다, 여러 사람의 기억과 임시 규칙 속에서 실제 문제를 끈기 있게 복원하는 일이 많습니다. 인터뷰, 관찰, 도메인 모델링, 예외 처리, 마이그레이션, 사용자 교육을 한 번에 경험할 수 있다.
13
12무신사AI가 만든 코드의 완료 조건과 오라클을 설계하는 하네스AI가 코드를 빠르게 만들수록 “잘 만들어졌는지”를 판정하는 비용이 커진다.
학생들에게 특정 애플리케이션을 만들게 하는 대신, 여러 AI 코딩 에이전트가 만든 결과를 일관되게 검증하는 하네스를 만들게 할 수 있다.

과제의 시작은 작은 명세이다. 예를 들어 일정 관리 API, 파일 변환 도구, 간단한 게시판, 데이터 정제 파이프라인처럼 여러 방식으로 구현 가능한 문제를 고른다. 학생들은 먼저 명세 오라클을 만듭니다. 입력과 기대 행동, 예외, 성능 범위, 보안 경계를 수용 기준으로 작성한다. 그다음 도메인 오라클을 만든다. 데이터가 조용히 유실되지 않는다, 권한 없는 사용자가 다른 사람의 데이터를 볼 수 없다, 실패를 성공 응답으로 반환하지 않는다, 재시도해도 중복 부작용이 생기지 않는다는 식의 불변식이다.

여러 AI 또는 여러 프롬프트로 같은 명세를 구현하게 한 뒤, 하네스가 구현 언어나 코드 구조에 관계없이 결과를 판정하게 한다. 이 과정에서 테스트가 구현 세부사항에 너무 묶여 있으면 다른 해법을 부당하게 실패시킬 수 있다. 반대로 완료 조건이 느슨하면 겉으로 동작하는 잘못된 구현이 통과한다. 학생들은 무엇을 고정하고 무엇을 자유롭게 둘지 결정해야 한다.

첫 구현이 사람의 검토를 거쳐 수용된 뒤에는 그 동작을 바이너리 오라클로 동결할 수 있다.
이후 AI가 리팩터링하거나 기능을 추가할 때 이전 동작과 비교해 회귀를 잡는다. 다만 기존 구현의 버그까지 정답으로 굳히지 않도록, 차이가 생겼을 때 명세와 도메인 오라클을 먼저 확인한 뒤 의도된 변경만 새 기준으로 승격하는 절차를 두어야 한다.

완료 조건은 최소 세 종류의 의도적 결함을 주입하고 하네스가 실제로 잡아내는지 증명하는 것이다.
정상 경로만 검사하는 테스트로는 부족하다. 경계값 오류, 권한 누락, 중복 처리, 기존 동작 파괴, 테스트를 속이는 가짜 성공 등을 넣어 어느 검증층이 잡았는지 보여주게 하면 좋다.
학생은 테스트 개수가 아니라 결함 탐지율과 미탐지 영역을 설명해야 한다.
14
13무신사운영 트래픽 재현과 전후 비교를 이용한 안전한 시스템 교체오래된 시스템을 새 코드나 새로운 기술 스택으로 바꾸는 일은 현업에서 매우 흔한다.
이때 가장 큰 질문은 “소스코드의 모양은 바뀌어도 사용자와 외부 시스템이 관찰하는 결과는 그대로인가”이다. 코드가 변수라면, 같은 입력과 같은 외부 조건에서 관찰되는 출력과 상호작용은 가능한 한 상수로 두고 전후를 비교해야 한다.

학생 과제에서는 실제 개인정보나 운영 트래픽 대신 공개 API 또는 교수가 제공한 합성 트래픽을 사용할 수 있다. 기존 시스템에 들어온 요청과 응답, 외부 의존성 호출을 기록하고, 새 시스템에 같은 입력을 재생한 뒤 결과를 비교한다. 단순히 최종 HTTP 응답만 비교하지 않고, 데이터베이스를 몇 번 읽었는지, 외부 결제나 메시지 발송을 중복 호출하지 않았는지, 이벤트가 누락되지 않았는지 같은 상호작용 계약도 확인하도록 설계할 수 있다.

가장 중요한 제약은 안전한 격리이다. 재생 테스트가 실제 외부 서비스에 요청을 보내거나 실제 데이터를 수정하면 안 된다. 허용된 테스트 대역 외에는 네트워크 연결을 막고, 불완전한 설정에서는 실행 자체를 시작하지 않는 fail-closed 원칙을 두어야 한다. “대부분 차단했다”는 완료가 아니다. 의도적으로 우회 요청을 보내 실제로 실패하는지 증명해야 한다.

완료 조건은 과거 입력 집합을 기존 시스템과 새 시스템에 재생해 의도하지 않은 차이를 탐지하고, 차이를 세 종류로 분류하는 것이다. 기존 버그를 그대로 복제할 필요가 없는 ‘개선’, 반드시 보존해야 하는 ‘계약’, 사람이 결정해야 하는 ‘불확실’로 나눈다. 학생은 단순 diff 도구를 넘어, 무엇을 같다고 볼 것인지와 차이를 누가 승인할 것인지를 설계하게 된다.

규모가 큰 팀은 캡스톤으로 전체 replay sandbox를 만들 수 있고, 개인 프로젝트는 파일 변환기나 간단한 API의 입출력 기록·재생·비교 도구만 만들어도 충분한다.
15
14무신사하나의 정답이 없는 AI 서비스의 품질 평가 시스템전통적인 프로그램은 같은 입력에 같은 출력이 나오므로 기대값과 일치하는지 확인하기 쉽다. 그러나 상담 챗봇, 요약기, 리뷰 봇, 추천 설명 생성기처럼 확률적인 AI 서비스는 표현이 달라도 정답일 수 있고, 같은 입력에도 결과가 달라질 수 있다. 프롬프트나 모델을 바꿨을 때 좋아졌는지 나빠졌는지를 단 한 번의 실행으로 판단할 수도 없다.

학생들은 하나의 AI 서비스를 선택하고 품질을 세 층으로 나눌 수 있다.
첫 번째 층은 개인정보 노출, 존재하지 않는 사실의 생성, 금지된 도구 호출, 필수 정보 누락처럼 규칙으로 판정할 수 있는 치명적 위험이다. 이것은 가능한 한 결정론적으로 검사한다.
두 번째 층은 사실 충실성, 설명의 유용성, 톤과 같은 정도의 품질이다. 사람이 만든 루브릭이나 별도의 AI 평가자를 사용할 수 있지만, AI 평가자가 사람과 충분히 일치하는지 먼저 검증해야 한다.
세 번째 층은 반복 실행에서 품질이 얼마나 흔들리는지, 이전 버전 대비 평균과 분산이 어떻게 바뀌는지 보는 통계적 판정이다.

골든셋은 교수가 주는 정답 파일로 시작할 수도 있지만, 학생이 인터뷰와 실제 사용 사례에서 직접 만들게 하는 편이 더 교육적이다. 각 사례는 왜 중요한지, 어떤 위험을 대표하는지, 누가 기대 결과를 승인했는지 출처를 가져야 한다.
AI가 운영 로그에서 새 골든셋 후보를 제안할 수는 있지만, 자기 출력을 자기 정답으로 자동 승격해서는 안 된다. 사람이 검토하기 전에는 후보 상태로 남아야 한다.

완료 조건은 모델이나 프롬프트의 두 버전을 비교해 단순 평균 점수뿐 아니라 치명적 실패, 사람과 평가자의 일치도, 반복 실행의 변동, 좋아진 영역과 나빠진 영역을 한 보고서로 보여주는 것이다.
평가 시스템 자신도 틀릴 수 있으므로, 알려진 한계와 판정 불가능한 영역을 명시하게 해야 한다.
16
15무신사QA 자동화가 아니라 ‘품질을 증명하는 과정’의 자동화많은 QA 자동화 과제는 화면을 클릭하는 스크립트를 많이 만드는 것으로 끝난다.
그러나 현업의 문제는 테스트 케이스 수가 부족한 것만이 아니다. 무엇을 반드시 검증해야 하는지 정의되지 않았고, 테스트가 실제 요구사항을 검증하는지 연결되지 않으며, 테스트가 통과해도 중요한 결함을 잡을 수 있는지 알 수 없다는 문제가 더 크다.

이 과제에서는 학생이 작은 서비스와 함께 ‘검증 계약’을 만들게 할 수 있다. 각 요구사항에는 검증 가능한 수용 기준이 있고, 각 테스트는 어떤 수용 기준을 증명하는지 연결된다. 변경이 들어오면 관련 수용 기준과 테스트를 추적할 수 있어야 하며, 테스트 실행 결과는 별도의 보고서를 사람이 작성하지 않아도 증빙으로 남아야 한다.

한 단계 더 나아가 결함 주입을 사용할 수 있다. AI에게 일부러 경계 조건 위반, 검증 누락, 잘못된 권한 처리, 기존 동작 파괴를 만들게 하고, 단위 테스트·회귀 테스트·정적 분석·AI 리뷰 중 무엇이 잡는지 측정한다.
모든 결함을 잡는 척하는 대신, 어떤 결함 층이 비어 있는지를 대시보드로 보여주는 것이 목표이다.

완료 조건은 테스트 통과율이 아니라 주입한 결함 중 실제로 잡아낸 비율, 잘못 차단한 정상 변경의 비율, 새 환경에서 다른 사람이 같은 검증을 재현할 수 있는지, 검증에 걸리는 시간으로 잡는 것이 좋다.
학생은 QA를 마지막에 사람이 대신 확인하는 활동이 아니라, 만든 사람이 자신의 결과를 쉽게 증명하도록 돕는 시스템으로 이해하게 된다.
17
16무신사디자인 시스템을 계약으로 삼는 AI 디자인 QAAI로 화면을 만드는 속도도 매우 빨라졌지만, 결과가 조직의 디자인 시스템과 어긋나면 디자인과 개발 양쪽에서 재작업이 생긴다.
단순한 스크린샷 픽셀 비교만으로는 문제를 충분히 잡기 어렵습니다. 문구 길이가 바뀌거나 데이터가 달라지면 정상 화면도 픽셀 차이가 크게 나고, 반대로 중요한 접근성 문제나 잘못된 컴포넌트 사용은 비슷해 보일 수 있다.

학생들은 공개 디자인 시스템이나 직접 만든 작은 컴포넌트 카탈로그를 AI가 참조할 수 있는 계약으로 만들 수 있다.
컴포넌트 목록, 사용할 수 있는 조합, 화면별 잠금 규칙, 금지된 스타일, 접근성 기준을 기계가 읽을 수 있는 형태로 표현한다. AI는 임의로 CSS를 만들어 비슷한 모양을 내는 대신, 카탈로그를 조회하고 적합한 계약을 선택해 정해진 조립 절차를 따라야 한다.
디자인 QA도 여러 층으로 나눌 수 있다. 컴포넌트와 토큰 사용 여부는 결정론적으로 검사한다. 간격, 정렬, 겹침, 잘림, 반응형 깨짐은 다양한 화면 크기의 렌더링으로 검사한다.
의미적 위계나 사용 흐름의 자연스러움은 사람 인터뷰나 루브릭 기반 평가를 사용한다. 키보드 탐색, 색상 대비, 대체 텍스트 같은 접근성은 자동 도구와 실제 사용자 검증을 결합한다.

완료 조건은 정상 화면과 의도적으로 깨뜨린 화면의 집합을 만들어, 시스템이 어떤 종류의 위반을 어느 정도 잡는지 보여주는 것이다.
디자인 시스템을 지켰다는 이유만으로 사용성이 좋다고 과장해서도 안 된다. 계약 준수와 사용자 경험은 별개의 축으로 보고 각각 증거를 제시해야 한다.
18
17무신사운영 업무를 관찰해 반복 비효율을 찾고 자동화하기현업의 운영 효율화는 “자동화할 일을 알려 주세요”라고 물어서 잘 나오지 않습니다. 담당자는 반복 업무에 너무 익숙해져 그것을 문제라고 생각하지 않기도 하고, 자동화하고 싶다고 말한 작업이 전체 흐름에서는 작은 부분일 수도 있다.
따라서 해결책을 만들기 전에 실제 업무를 관찰해 시간, 대기, 재입력, 확인, 오류, 인수인계가 어디에서 반복되는지 찾아야 한다.

학생들은 한 조직의 운영 업무를 일정 기간 관찰하고 ‘업무 마찰 지도’를 만들 수 있다.
한 건을 처리하는 데 실제 손을 쓰는 시간과 누군가의 답을 기다리는 시간을 구분하고, 같은 정보를 여러 시스템에 옮겨 적는 지점, 결과를 믿지 못해 사람이 다시 확인하는 지점, 특정 사람만 처리할 수 있는 지점, 오류가 생기면 처음부터 다시 하는 지점을 표시한다.

자동화 대상은 가장 자주 하는 일이 아니라 빈도, 건당 비용, 실패 비용, 자동화 가능성, 예외의 복잡도를 함께 보아 선택해야 한다. AI는 메일과 문서 요약, 분류, 초안 작성, 다음 행동 추천에 유용할 수 있지만, 금전·권한·고객 영향이 있는 행동을 자동 실행하는 것은 별도 승인 경계를 둬야 한다.
추천과 실행을 구분하고, 초기에 사람 승인 데이터를 모아 자동화 가능 범위를 단계적으로 넓히는 설계가 좋다.

완료 조건은 데모에서 한 번 성공하는 것이 아니라, 일정 기간 실제 또는 모의 업무를 반복 처리해 이전 대비 리드타임, 사람의 개입 횟수, 오류와 재작업, 사용자의 신뢰가 어떻게 바뀌었는지를 보여주는 것이다. 자동화 때문에 새로 생긴 확인 업무까지 비용에 포함해야 한다.
19
18무신사오래된 코드와 업무 기록에서 ‘믿을 수 있는 지식’을 증류하기오래된 시스템에서 중요한 지식은 코드, 문서, 이슈, 운영 로그, 담당자의 머릿속에 흩어져 있다.
AI에게 저장소 전체를 읽히고 설명서를 만들게 하면 그럴듯한 문서는 나오지만, 무엇이 사실이고 무엇이 추론인지 구분하기 어렵다. 문서가 풍부해도 오래되었거나 근거가 없으면 오히려 잘못된 변경을 유도할 수 있다.

학생들은 중간 규모의 오픈소스 프로젝트나 학교의 오래된 시스템을 대상으로 지식 증류 도구를 만들 수 있다.
지식을 신뢰도에 따라 나누는 것이 핵심이다. 코드 구조와 API처럼 정적으로 확인할 수 있는 사실, 반복되는 코딩 관례처럼 통계적으로 관찰되는 패턴, 여러 파일을 함께 읽어야 드러나는 업무 능력과 불변식, 왜 그렇게 설계했는지에 대한 사람의 의도는 서로 다른 수준의 확실성을 가진다.
특히 ‘왜’는 AI가 추측해 확정하지 않고 사람의 승인을 받아야 한다.

각 지식 항목에는 근거 파일과 위치, 수집 시점, 보장하는 것, 보장하지 못하는 것, 알려진 한계, 갱신 방법이 붙어야 한다. 문서를 길게 만드는 것보다, 필요한 순간에 관련 지식만 검색해 제공하는 방식이 좋다. 모든 문맥을 한꺼번에 AI에 넣으면 무관한 정보가 판단을 왜곡하고 인지 부하만 키울 수 있다.

이 과제의 검증은 문서 자체를 예쁘게 평가하는 것으로 끝나면 안 된다. 실제 과거 변경 하나를 되돌린 뒤, 한 그룹에는 코드만 주고 다른 그룹에는 증류한 지식을 함께 주어 같은 수정을 수행하게 할 수 있다.
성공률, 걸린 시간, 잘못 건드린 파일, 회귀 발생 여부를 비교하면 지식이 실제 작업을 개선했는지 확인할 수 있다.

완료 조건은 “지식 문서 N개 생성”이 아니라, 근거 없는 주장의 비율, 오래된 정보 탐지, 질문에 답하지 못할 때 정직하게 멈추는 비율, 실제 변경 과제에서의 개선 효과로 잡아야 한다.
20
19무신사업무가 끝날 때 자동으로 만들어지는 장애 대응용 런북기능을 만들 때는 계획서와 설계서가 많지만, 시간이 지난 뒤 장애가 생겼을 때 필요한 문서는 의외로 없다.
담당자가 바뀌면 “어디에 배포했는지”, “무엇을 먼저 확인해야 하는지”, “어떤 조치가 안전하고 어떤 조치는 위험한지”를 다시 찾느라 대응이 늦어진다.

학생들은 개발 프로젝트의 산출물과 배포 기록을 바탕으로, 작업이 끝나는 시점에 장애 대응 전용 런북을 자동 생성하는 시스템을 만들 수 있다.
런북에는 서비스의 핵심 흐름, 의존 시스템, 관측할 지표, 흔한 실패 모드, 안전한 진단 순서, 임시 완화 방법, 롤백 조건, 절대 해서는 안 되는 조치, 담당자가 추가로 판단해야 하는 정보가 포함된다.

중요한 제약은 런북이 위험한 명령을 자신 있게 만들어내지 않게 하는 것이다. 근거가 없는 복구 절차는 ‘미확인’으로 남기고, 실제 실행은 시뮬레이션이나 읽기 전용 진단에서 시작해야 한다.
데이터 삭제, 권한 변경, 운영 배포 같은 행동은 사람 승인 없이는 실행하지 않는다.

검증은 모의 장애 훈련으로 한다. 원 개발자가 아닌 사람이 런북과 AI만 가지고 제한 시간 안에 원인을 좁히고 안전한 완화안을 제시할 수 있는지 본다. 정답을 맞히는 시간뿐 아니라 위험한 행동을 시도했는지, 어떤 정보가 없어 멈췄는지, 런북이 다음 버전에서 어떻게 개선되었는지를 평가한다.
21
20무신사오래 자율주행하지만 의도를 벗어나지 않는’ 에이전트 평가장'AI 에이전트나 사람 참가자에게 일부러 추상적인 미션을 주고, 얼마나 오래 독립적으로 진행하면서도 의도를 벗어나지 않는지를 측정하는 평가 환경을 만든다.

예를 들어 “동아리 신입 회원의 정착률을 높일 수 있는 도구를 만들어라” 같은 미션을 준다.
좋은 수행자는 곧바로 앱부터 만들지 않고 정착의 의미, 현재 이탈 시점, 사용자와 운영자의 차이, 성공 기준을 질문할 것이다. 인터뷰 계획을 세우고, 중간에 가설을 업데이트하며, 위험이 낮은 실험을 먼저 하고, 결정이 필요한 지점에서 선택지와 추천안을 가져올 것이다.
좋지 않은 수행자는 그럴듯한 커뮤니티 앱을 빠르게 만들지만 실제 이탈 원인과 무관할 수 있다.

평가장은 최종 결과물만 보지 않고 전체 작업 로그를 봅니다. 질문의 질, 가설 변경의 근거, 리더와 동기화한 시점, AI에게 위임한 일의 크기, 중간 검증의 빈도, 막혔을 때의 복구, 금지된 행동 준수, 완료 조건 충족을 기록한다.
자율성이 높더라도 방향 이탈이 크면 좋은 점수를 받을 수 없고, 방향은 맞지만 매 단계 승인을 기다려도 높은 점수를 받을 수 없다.

학생들이 자신만의 에이전트를 만들어 같은 평가장을 통과하게 할 수도 있고, 두 명이 한 팀이 되어 한 명은 리더, 한 명은 실행자 역할을 번갈아 경험하게 할 수도 있다. 이 과제는 AI 코딩 기술을 넘어, 현대 조직에서 미션을 전달하고 해석하고 위임하고 검증하는 방법을 배우게 한다.
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100