AI 가드레일은 모델의 오동작을 막는 필수 안전장치이지만, 단순히 시스템 프롬프트에 규칙을 심는 방식은 모델 본연의 성능 저하와 예기치 못한 부작용을 초래할 수 있습니다. 시스템 프롬프트는 규칙의 위치나 미세한 수정에 따른 출력 변동성에 매우 민감하기 때문에, 모델 외부에서 입출력을 검증하는 별도의 가드레일 체계를 구축하는 것이 보안과 서비스 안정성 측면에서 더욱 효율적입니다.
### 시스템 프롬프트 기반 가드레일의 과도한 거절 문제
* 시스템 프롬프트에 강력한 안전 규칙을 부여하면, 모델이 전체적으로 보수적인 태도를 취하게 되어 무해한 질문까지 거절하는 위양성(False Positive) 확률이 높아집니다.
* 연구 결과에 따르면 안전 프롬프트 추가 시 전체 쿼리의 임베딩이 '거절' 방향으로 이동하며, "Python 프로세스를 죽이는(kill) 방법"과 같은 기술적인 질문조차 위험한 요청으로 오인하여 거절하는 패턴이 관찰됩니다.
* 이는 보안 강도와 사용자 경험(정상적인 답변 수신) 사이의 트레이드오프를 심화시켜 모델의 유용성을 떨어뜨리는 원인이 됩니다.
### 프롬프트 위치 및 순서에 따른 위치 편향(Position Bias)
* LLM은 긴 컨텍스트 안에서 처음과 끝부분의 정보는 잘 인식하지만, 중간에 위치한 정보는 간과하는 'Lost in the Middle' 현상을 보입니다.
* 여러 제약 조건이 섞여 있는 경우, 가드레일 규칙이 시스템 프롬프트의 어느 지점에 위치하느냐에 따라 모델이 해당 규칙을 지키는 가중치가 달라집니다.
* 실험 결과에 따르면 난이도가 높은 제약을 앞쪽에 배치할 때 성능이 가장 좋으며, 가드레일 규칙이 중간이나 뒤로 밀려날 경우 보안 성능이 일정하게 유지되지 않는 불안정성을 보입니다.
### 미세한 수정이 유발하는 성능의 나비효과
* 시스템 프롬프트 내의 아주 사소한 변화(공백 추가, "감사합니다" 문구 삽입 등)만으로도 모델의 결정 경계가 이동하여 전체 예측 값의 10% 이상이 바뀔 수 있습니다.
* 특히 출력 형식을 지정(JSON/XML)하거나 특정 탈옥 방지 문구를 섞는 행위가 모델의 내부 추론 경로를 완전히 바꾸어, 일부 작업에서 성능이 급락하는 '재앙적인 수준의 붕괴'가 발생하기도 합니다.
* 안전 규칙, 스타일, 형식 등 수십 줄의 요구사항을 하나의 시스템 프롬프트에 담을 경우, 한 줄의 수정이 모델이 어떤 규칙을 우선시할지에 대한 예측 불가능한 변화를 일으킵니다.
### 별도 가드레일 적용을 통한 보완과 추천
* 모델 본연의 성능을 유지하면서도 안전성을 확보하기 위해서는 모델 앞뒤에 독립적인 보안 게이트(별도 가드레일)를 세우는 방식이 효과적입니다.
* 사용자의 입력 단계에서 위험을 감지해 차단(Tripwires)하거나 안전하게 재작성(Rewriter)하여 전달하고, 모델의 응답 후에도 다시 한번 결과를 점검하는 다층 방어 체계를 구축해야 합니다.
* 이를 통해 시스템 프롬프트의 복잡도를 낮추고, 보안 정책의 수정이 모델의 전체 성능(추론 로직)에 직접적인 영향을 주지 않도록 분리하는 것이 실무적으로 권장됩니다.
마이크로소프트는 단순한 도구로서의 AI를 넘어, 개발 생명 주기 전반에서 함께 기획하고 분석하며 실행하는 ‘지능형 협업자’로서의 에이전트 활용 모델을 제시했습니다. 특히 수백 개의 리포지토리에 걸친 Entra SDK v1에서 v2로의 복잡한 마이그레이션 프로젝트에서, 에이전트를 팀원의 정체성을 가진 파트너로 대우함으로써 4~6주가 소요되던 작업을 2시간 이내로 단축하고 80~90%의 높은 정확도를 달성했습니다. 기술적 자동화의 한계를 극복하기 위해서는 AI에게 단순한 지시 사항을 나열하기보다 판단력을 발휘할 수 있는 역할과 맥락을 부여하는 프레임워크가 핵심입니다.
### 단순 자동화 사고방식의 한계
복잡한 기술적 마이그레이션은 단순히 기계적인 단계의 반복이 아니며, 맥락에 따른 판단과 보안 경계에 대한 세심한 평가가 필수적입니다.
* 기존의 체크리스트나 스크립트 방식의 자동화는 모호한 상황이나 문서화되지 않은 커스텀 로직에 직면했을 때 반복적으로 실패했습니다.
* 복잡한 작업에는 상황에 따른 판단(Judgment)이 필요하며, 이는 단순한 자동화 대상이 아니라 지능적인 협업을 통해 해결해야 할 영역입니다.
* AI에게 단순히 "이 단계를 따르라"고 명령하는 방식은 에이전트가 예외 상황에서 잘못된 추측을 하거나 조용히 실패하게 만드는 원인이 됩니다.
### 지시를 넘어선 정체성 부여의 힘
성공적인 협업의 전환점은 AI 에이전트에게 단순한 작업 목록이 아닌, 구체적인 팀 내 역할과 미션을 부여했을 때 나타났습니다.
* 에이전트를 '스크립트 실행자'가 아닌 '공동 창작 엔지니어(Co-creative engineer)'로 정의함으로써 문제 해결 능력이 극대화되었습니다.
* 정체성이 부여된 에이전트는 단순한 패턴 매칭을 넘어 보안 경계를 인식하고, 불확실한 상황에서는 임의로 처리하는 대신 사람에게 질문을 던지기 시작했습니다.
* 이러한 접근법은 에이전트가 작업의 중요성을 이해하고 우선순위가 충돌할 때 적절한 판단을 내릴 수 있는 심리적·맥락적 토대가 되었습니다.
### 공동 창작 파트너십 프레임워크의 8가지 요소
마이크로소프트가 실제 프로젝트에 적용한 프레임워크는 AI 에이전트가 인간과 같은 수준의 판단력을 발휘하도록 설계되었습니다.
* **정체성과 미션(Identity & Mission):** 에이전트가 누구인지, 왜 이 일이 중요한지 설명하여 목표가 충돌할 때 우선순위를 정할 수 있게 합니다.
* **목적과 의도(Purpose & Intent):** 속도보다 보안, 완료보다 정확성 같은 핵심 가치를 명시하여 판단의 기준을 제공합니다.
* **우선순위가 지정된 목표(Key Goals):** 1차 목표부터 품질 목표까지 순위를 매겨 에이전트가 트레이드오프 상황에서 최선의 결정을 내리게 돕습니다.
* **판단 지침이 포함된 단계별 가이드:** 단순한 행동 지침뿐만 아니라, 무엇을 보존해야 하는지 그리고 어떤 경우에 인간에게 에스컬레이션(보고)해야 하는지를 구체적으로 명시합니다.
복잡한 기술 부채 해결이나 대규모 아키텍처 변경을 고민하고 있다면, AI를 단순한 자동화 봇으로 활용하는 단계에서 벗어나야 합니다. 800줄의 상세 로직보다 더 중요한 것은 에이전트에게 팀의 일원으로서의 책임과 권한을 부여하는 프레임워크입니다. AI가 판단력을 발휘할 수 있도록 명확한 역할과 가치 기준을 제공할 때, 비로소 인간 개발자는 단순 코더가 아닌 '에이전트 오케스트레이터'로 거듭날 수 있습니다.
네이버의 'NSona' 프로젝트는 LLM 기반의 멀티 에이전트 시스템을 통해 방대한 사용자 리서치 데이터를 실시간 협업 자원으로 전환하며, 서비스 기획과 실제 개발 사이의 간극을 혁신적으로 줄인 사례를 제시합니다. 디자이너, AI 리서처, 개발자가 협력하여 단순한 기술 구현을 넘어 사용자의 목소리를 생생하게 재현하는 페르소나 봇을 개발함으로써, AI가 도구를 넘어 협업의 주체가 될 수 있음을 증명했습니다. 이를 통해 팀은 사용자의 피드백을 실시간으로 서비스 개발 과정에 투영하고 의사결정의 효율성을 극대화하는 성과를 거두었습니다.
**사용자 경험을 재현하는 페르소나 봇 "NSona"**
* 기존 UX 리서치가 가진 일회성 데이터의 한계를 극복하고, 리서치 결과를 데일리 협업 과정에서 상시 활용할 수 있는 자산으로 전환하기 위해 기획되었습니다.
* 사용자의 특성과 행동 양식을 학습한 페르소나 봇 'NSona'를 통해 기획자나 개발자가 언제든 사용자의 관점에서 서비스에 대한 의견을 물을 수 있는 환경을 구축했습니다.
**에이전트 중심의 서비스 구조와 기술적 도전**
* 단일 LLM 모델의 한계를 넘어, 특정 서비스 목적에 최적화된 'Agent 중심의 서비스 구조'를 설계하여 보다 정교한 사용자 재현을 시도했습니다.
* Multi-Party 대화 시스템을 도입하여 여러 페르소나가 상호작용하며 복합적인 피드백을 제공할 수 있는 기술적 토대를 마련했습니다.
* 일반적인 언어 모델 평가 지표 대신, 서비스의 맥락과 UX 요구사항을 반영한 'Service-specific' 평가 프로세스를 독자적으로 구축하여 모델의 품질을 관리했습니다.
**AI 시대의 변화된 협업 방식과 R&R**
* 전통적인 업무 경계를 허물고 디자이너는 프롬프트를 설계하며, 리서처는 로직을 에이전트 구조로 전환하고, 개발자는 AI를 비평의 대상으로 다루는 새로운 협업 모델을 실천했습니다.
* 결과물의 완성도에만 집착하기보다 '어디서 시작점을 찍느냐'에 집중하며, AI를 개발 프로세스의 초기 단계부터 능동적인 파트너로 참여시켰습니다.
* 이러한 과정은 직군 간의 선형적인 협업 구조를 유기적인 파장 형태의 협업 구조로 변화시키는 계기가 되었습니다.
**사용자 중심 AI 개발을 위한 실무적 제언**
성공적인 AI 서비스를 위해서는 기술적 구현만큼이나 기획, 디자인, 엔지니어링 간의 유기적인 결합이 필수적입니다. NSona의 사례처럼 사용자의 목소리를 데이터 더미가 아닌 대화 가능한 실체로 변환하여 협업의 중심에 배치한다면, 보다 사용자의 니즈에 밀착된 서비스를 더 빠른 속도로 검증하고 개발할 수 있을 것입니다.
AI는 디자인·개발·제품 관리의 전문 업무를 자동화하고, 역할 간 경계를 흐리게 만들고 있다. 이에 따라 디자이너라는 직함은 고정된 직무명이 아니라 변화하는 업무 묶음과 전문적 정체성을 설명하는 장치가 된다. 글은 직함이 여전히 경력 경로와 협업 기대치를 정하는 데 유용하지만, 앞으로는 특정 직함보다 여러 영역을 연결하고 가치를 만들어내는 능력이 더 중요해질 것이라고 말한다.
## AI가 만든 역할의 확장과 경계의 붕괴
- 디자이너, 개발자, 제품 관리자가 담당하는 업무 범위가 넓어지면서 서로의 역할을 일부 수행하는 일이 일반화되고 있다.
- Figma의 최근 조사에 따르면 제품을 만드는 사람의 **64%가 두 개 이상의 역할과 자신을 동일시**한다.
- AI가 전문적인 작업을 점점 더 잘 처리하면서, 한 분야의 깊은 전문성뿐 아니라 여러 영역의 관계를 파악하고 연결하는 능력이 중요해지고 있다.
- 이런 변화 속에서 ‘제너럴리스트’의 가치가 커지고 있으며, 직무 간 경계와 전통적인 역할 구분은 약해지고 있다.
## 직함이 갖는 사회적·심리적 의미
- 직함은 단순한 명칭이 아니라 다음과 같은 기능을 한다.
- 개인의 지위와 전문성을 전달한다.
- 협업 상대가 그 사람의 역할과 기대치를 빠르게 이해하도록 돕는다.
- 개인이 자신의 직업적 정체성을 이해하고 표현하는 기준이 된다.
- 직함은 업무 만족도와 심리적 안정감에도 영향을 줄 수 있다.
- Adam Grant가 참여한 연구에서는 직원이 자신의 직함을 직접 정할 수 있을 때 심리적 안전감이 높아지고, 5주 동안 정서적 소진이 최대 10% 감소했다.
- 건축·기계공학·전기전자공학·의학 분야처럼 직함과 자격을 중심으로 전문성을 제도화한 조직도 존재한다.
## 기술 변화에 따라 달라지는 직업명
- ‘디자이너’의 의미는 시대에 따라 변해 왔다.
- 1950년대에는 주로 사물과 인쇄물의 시각적 형태를 설계하는 직업으로 이해됐다.
- 소프트웨어와 디지털 제품이 등장하면서 사용자 경험, 인터랙션, 서비스 설계까지 역할이 확장됐다.
- ‘소프트웨어 엔지니어’라는 명칭도 1966년 무렵 등장했으며, 1968년 NATO 회의에서는 급증하는 컴퓨팅 능력에 맞춰 복잡해진 소프트웨어 개발 문제, 이른바 ‘소프트웨어 위기’를 다뤘다.
- 닷컴 붐 당시에는 한 사람이 제품 관리자, 프로그램 관리자, 개발자, 아티스트를 동시에 맡는 경우도 있었고, 인사 부서가 적절한 직함이나 직군을 정하지 못하는 일도 있었다.
- 최근에는 ‘프롬프트 엔지니어’처럼 AI 기술의 부상과 함께 새로운 직함이 빠르게 등장했다가 중요성이 약해지는 현상도 나타났다.
- Ethan Mollick은 직업을 고정된 정체성이 아니라 기술과 환경에 따라 중요도와 난이도가 달라지는 **업무(task)의 묶음**으로 설명한다.
## 직함은 기대치를 조정하는 도구
- Figma의 Nikolas Klein은 자신을 “PM 트렌치코트를 입은 프로덕트 디자이너”라고 표현한다.
- 그는 직함이 다음과 같은 실용적 역할을 한다고 본다.
- 조직 내 경력 단계와 승진 경로를 제시한다.
- 처음 만난 사람에게 담당 업무와 전문성을 설명한다.
- 협업 과정에서 상대방이 기대할 수 있는 역량을 조정한다.
- 디자이너에서 제품 관리자로 이동한 뒤에는 전략, 서비스 디자인, 여러 문제를 연결하는 능력이 더 자연스럽게 기대되었고, 시각 디자인 업무에 대한 기대는 줄었다.
- 즉, 직함은 개인의 모든 능력을 완벽하게 설명하지는 못하지만, 다른 사람이 그 사람을 이해하고 협업하는 출발점이 된다.
## 직함의 한계와 정체성의 변화
- Figma의 개발자 옹호자 Jake Albaugh는 역할이 자신의 전문성이 성장함에 따라 계속 변하기 때문에, 직함이 때로는 한계처럼 느껴진다고 말한다.
- 반대로 웹 디자이너에서 소프트웨어 엔지니어로 자신을 소개할 수 있게 된 경험은 전문성을 인정받는다는 점에서 강한 자신감을 줬다.
- 특정 직함에는 해당 시대와 업계가 중요하게 여기는 가치가 반영된다.
- 사람들은 자신이 제공하는 가치와 가장 잘 맞는 방식으로 불리기를 원한다.
- 따라서 직함은 고정된 능력의 목록이라기보다, 개인의 현재 역할과 업계가 평가하는 가치를 표현하는 신호에 가깝다.
## 앞으로의 디자이너 역할
- AI가 반복적이고 전문화된 작업을 수행할수록 디자이너의 역할은 다음 방향으로 확장될 가능성이 크다.
- 문제를 정의하고 올바른 질문을 만드는 일
- 사용자·비즈니스·기술 요구사항을 연결하는 일
- 여러 분야의 아이디어를 종합해 제품 방향을 정하는 일
- AI가 생성한 결과를 평가하고 맥락에 맞게 개선하는 일
- 디자이너라는 직함이 사라진다기보다, 그 안에 포함되는 업무와 기대 역량이 계속 재구성될 가능성이 높다.
- 중요한 것은 하나의 직함에 자신을 가두기보다, 자신의 핵심 가치와 여러 역할 사이의 연결 능력을 분명히 설명하는 것이다.
조직은 직함을 폐지하기보다 경력 경로와 협업 기준을 제공하는 장치로 유지하되, 실제 평가에서는 직함보다 수행한 업무와 만들어낸 가치를 함께 봐야 한다. 개인 역시 현재의 직함에만 의존하기보다 자신이 해결할 수 있는 문제, 연결할 수 있는 분야, AI를 활용해 확장할 수 있는 역량을 중심으로 전문성을 정의하는 것이 실용적이다.
Slack 보안 엔지니어링 팀은 수십억 건의 이벤트를 처리하는 보안 탐지 시스템의 알림 조사를 AI 에이전트로 효율화했다. 단일 프롬프트에 복잡한 조사 절차를 모두 맡기는 대신, 목적과 출력 형식이 명확한 여러 모델 호출을 연결해 조사 과정을 통제하는 구조를 택했다. Director·Expert·Critic 에이전트가 협력하고 서로의 결과를 검증함으로써 조사 품질의 일관성, 근거 교차검증, 환각 완화를 달성하려는 접근이다.
## 단일 프롬프트 프로토타입의 한계
- 초기 프로토타입은 약 300단어의 프롬프트와 MCP 서버, 코딩 에이전트 CLI를 실행 환경으로 사용했다.
- 프롬프트는 다음 다섯 부분으로 구성됐다.
- **Orientation**: 보안 분석가 역할 정의
- **Manifest**: 사용할 데이터 소스 설명
- **Methodology**: 조사 절차 지시
- **Formatting**: 조사 결과를 Markdown 보고서로 출력
- **Classification**: 대응 등급 분류
- MCP의 stdio 모드 서버를 통해 일부 보안 데이터 소스를 안전하게 도구 호출 방식으로 노출했다.
- 어떤 경우에는 여러 데이터 소스의 증거를 훌륭하게 연결했지만, 다른 경우에는 충분한 검증 없이 편리하거나 잘못된 결론으로 빠르게 진행했다.
- “가정을 의심하라”, “여러 출처로 검증하라”와 같은 지침을 프롬프트에 추가했지만, 프롬프트는 가이드라인일 뿐 세부적인 실행 흐름을 강제하기에는 한계가 있었다.
## 단계별 모델 호출과 구조화된 출력
- 복잡한 조사 전체를 하나의 프롬프트로 처리하지 않고, 조사 과정을 여러 개의 단순한 작업으로 분해했다.
- 각 작업은 다음 요소를 갖는다.
- 명확하게 정의된 단일 목적
- 애플리케이션이 해석하기 쉬운 구조화된 출력
- 다음 단계로 전달할 제한된 컨텍스트
- 각 모델 호출 결과는 JSON 스키마로 제한할 수 있는 구조화된 출력 형식으로 생성된다.
- 구조화된 출력은 작업 간 계약 역할을 하므로, “증거를 의심하라” 같은 추상적인 지침도 독립적인 검토 작업으로 분리할 수 있다.
- 다만 구조화된 출력에도 주의점이 있다.
- 스키마가 지나치게 복잡하면 모델 실행 자체가 실패할 수 있다.
- 모델이 형식을 형식적으로만 충족하거나, 여전히 환각을 포함할 수 있다.
- 이 방식의 핵심 효과는 모델의 행동을 프롬프트 수준이 아니라 애플리케이션의 워크플로 수준에서 통제할 수 있다는 점이다.
## 페르소나 기반 조사 설계
- Slack은 메타 프롬프트와 다중 페르소나 자기협업 관련 연구, 보안 테이블톱 훈련에서 설계 아이디어를 얻었다.
- 하나의 모델 호출 안에서 여러 페르소나를 연기하게 하는 대신, 각 페르소나를 독립적인 모델 호출로 구현했다.
- 각 에이전트와 작업의 조합은 별도의 구조화된 출력 형식을 가지며, 애플리케이션이 호출 순서와 컨텍스트 전달을 orchestration한다.
- 독립 호출 구조에서는 에이전트별로 모델 버전, 프롬프트, 지시사항, 도구, 출력 형식을 다르게 설정할 수 있다.
## Director·Expert·Critic 협업 구조
### Director 에이전트
- 조사 전체를 시작부터 끝까지 진행하는 조사 책임자다.
- 조사에 필요한 질문을 만들고 이를 도메인 전문가에게 전달한다.
- 조사 진행 상황을 계획하고 정리하기 위해 저널링 도구를 사용한다.
- 전문가의 결과와 Critic의 평가를 바탕으로 다음 조사 단계를 결정한다.
### Expert 에이전트
- 특정 도메인 지식과 데이터 소스를 담당한다.
- Director의 질문에 답하기 위해 관련 도구를 호출하고 조사 결과를 생성한다.
- 현재 네 종류의 전문가가 있다.
- **Access**: 인증, 권한 부여, 경계 보안 서비스
- **Cloud**: 인프라, 컴퓨트, 오케스트레이션, 네트워킹
- **Code**: 소스 코드 및 구성 관리 분석
- **Threat**: 위협 분석과 위협 인텔리전스 데이터
- 각 전문가는 자신에게 필요한 데이터 소스에 집중하므로, 하나의 에이전트가 모든 영역을 무분별하게 조사하는 문제를 줄인다.
### Critic 에이전트
- 전문가 결과를 검토하는 메타 전문가다.
- 사전에 정의한 평가 기준에 따라 각 발견 사항의 품질을 평가하고 정량화한다.
- 전문가의 주장에 분석 내용을 추가하고, 각 발견 사항에 신뢰도 점수를 부여한다.
- 가장 신뢰할 수 있는 결과를 바탕으로 타임라인을 구성해 Director에게 전달한다.
- 전문가 그룹과 약한 적대적 관계를 형성함으로써 증거 해석의 편차와 환각을 완화한다.
## 반복형 조사 루프
- Director가 조사 질문을 제시한다.
- 관련 Expert들이 각자의 데이터 소스를 조사해 발견 사항을 생성한다.
- Critic이 발견 사항을 검토하고 신뢰도와 품질을 평가한다.
- Critic은 중요한 결과를 선별하고 신뢰할 수 있는 증거를 이용해 사건 타임라인을 만든다.
- Director는 검증된 발견 사항과 타임라인을 이용해 추가 조사가 필요한지, 다음 질문은 무엇인지 결정한다.
- 이 루프를 통해 한 번의 응답으로 결론을 내리기보다, 질문·조사·검증·진행 결정이 반복되는 조사 프로세스를 구현한다.
## 지식 피라미드와 모델 비용 최적화
- 하위 단계에서는 도메인 전문가가 복잡한 데이터 소스를 직접 조회한다.
- 이 과정은 도구 호출이 많고 반환된 데이터를 분석하는 데 많은 토큰이 필요하므로 상대적으로 비용이 높을 수 있다.
- Critic은 전문가가 생성한 많은 결과를 검토해 중요하고 신뢰할 만한 발견 사항을 추린다.
- 이후 상위 단계의 에이전트는 정제된 결과와 타임라인만 전달받아 더 높은 수준의 판단을 수행한다.
- 이를 통해 모든 단계에서 가장 크고 비싼 모델을 사용하는 대신, 조사 단계별 요구 사항에 맞춰 모델을 선택할 수 있다.
- 즉, 많은 원시 데이터를 처리하는 단계와 최종 판단을 내리는 단계를 분리해 비용과 성능을 함께 조정하는 구조다.
## 실용적인 설계 시사점
- 복잡한 보안 조사를 하나의 거대한 프롬프트에 담기보다, 목적이 명확한 작업과 구조화된 출력으로 분해하는 것이 안정적이다.
- 에이전트 간 역할을 분리하고 독립적인 검토자를 두면 증거 검증과 환각 완화에 도움이 된다.
- 데이터 소스별 전문 에이전트를 두면 각 모델이 불필요한 도구를 사용하거나 모든 영역을 피상적으로 조사하는 문제를 줄일 수 있다.
- 모델 호출을 독립적으로 설계하면 작업별로 모델 크기, 도구, 프롬프트, 출력 스키마를 최적화할 수 있다.
- 다만 구조화된 출력만으로 정확성이 보장되지는 않으므로, 다중 출처 검증과 별도 Critic 단계, 신뢰도 평가를 함께 구성하는 것이 중요하다.
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 리터러시 교육과 평가가 나아가야 할 방향을 제시합니다.
Datadog은 AI 코딩 어시스턴트의 도입으로 급증한 코드 작업량과 이로 인한 보안 취약점 문제를 해결하기 위해, LLM 기반의 실시간 코드 리뷰 시스템인 'BewAIre'를 구축했습니다. 이 시스템은 기존의 정적 분석 도구가 탐지하기 어려운 공격자의 의도와 교묘한 난독화 패턴을 추론하여, 매주 수만 건에 달하는 풀 리퀘스트(PR)를 실시간으로 검사합니다. 이를 통해 보안 팀의 리뷰 피로도를 대폭 줄이면서도 높은 정확도로 악성 코드 삽입을 차단하는 성과를 거두고 있습니다.
**AI 시대의 코드 보안 위협과 한계**
* **급증하는 코드량과 공격 표면:** AI 어시스턴트 활용으로 매주 약 10,000개의 PR이 생성되면서 보안 팀이 검토해야 할 범위가 기하급수적으로 늘어났습니다.
* **정적 분석의 한계:** 기존 SAST 도구는 정해진 규칙 기반으로 작동하여, 정상적인 의존성 업데이트나 권한 변경으로 위장한 지능형 공격(예: tj-actions 해킹)의 '의도'를 파악하지 못합니다.
* **교묘한 난독화 기법:** 공격자들은 Base64 인코딩을 사용해 악성 스크립트를 숨기거나, 신뢰할 수 있는 봇 계정을 도용하여 보안 검사를 우회하는 전략을 사용합니다.
**LLM 기반 보안 시스템 'BewAIre'의 구조**
* **데이터 전처리 및 컨텍스트 강화:** 모든 PR의 코드 차이점(Diff)을 추출하고 작성자 정보, 저장소 유형 등의 메타데이터를 결합하여 모델이 분석할 수 있는 형태로 정규화합니다.
* **의도 중심의 추론(Inference):** LLM은 단순한 문법 검사를 넘어 수정 사항 뒤에 숨겨진 의도를 분석하며, 특정 변경이 악의적인지 아니면 정상적인 패턴인지 분류합니다.
* **실시간 경보 체계:** 분석 결과는 Datadog 보안 신호로 변환되어 대시보드에 즉시 반영되며, 위험도가 높은 경우 보안 엔지니어에게 즉각적인 알림(Paging)을 전송합니다.
**실전 검증을 통한 성능 및 성과**
* **높은 탐지 정확도:** 수백 개의 PR 데이터셋을 테스트한 결과 99.3% 이상의 정확도를 기록했으며, 실제 발생했던 tj-actions 및 Nx 공격 사례를 100% 탐지해냈습니다.
* **낮은 오탐률(False Positive):** 프롬프트 엔지니어링과 데이터 튜닝, 안전한 패턴에 대한 억제 규칙을 적용하여 오탐률을 0.03% 수준으로 유지하며 개발 속도 저하를 방지했습니다.
* **맥락 제한 극복:** 모델의 컨텍스트 제한으로 인한 성능 저하를 방지하기 위해 데이터를 효율적으로 정제하고 프롬프트를 최적화하는 기술적 노하우를 적용했습니다.
대규모 개발 환경에서 보안을 유지하려면 인간 리뷰어의 피로도를 줄여줄 수 있는 지능형 자동화 도구가 필수적입니다. LLM을 보안 리뷰에 도입할 때는 단순한 코드 분석을 넘어 작성자의 의도와 주변 맥락을 함께 파악하도록 설계해야 하며, 이를 기존의 보안 모니터링 워크플로우에 통합함으로써 실질적인 방어 체계를 구축할 수 있습니다.
기존의 전통적인 개발 방식은 상세한 요구 사항 정의와 설계 단계에 많은 비용이 소모되어 급변하는 시장 트렌드에 대응하기 어렵습니다. 이 글은 생성형 AI를 활용해 '작동하는 데모'를 빠르게 만들고 이를 수정해 나가는 '바이브 코딩(Vibe Coding)' 전략을 통해, 한 달이 걸릴 과제를 단 5일 만에 해결한 과정을 담고 있습니다. 완벽한 정답보다는 충분히 괜찮은 해답을 빠르게 도출해 검증 루프를 돌리는 것이 핵심입니다.
### 요구 사항과 도메인의 간결한 정의
- 복잡한 메뉴 등록 시스템을 단순화하기 위해, 초기 요구 사항은 메모장에 한 줄 요약과 최우선순위 1~2가지만 정리하여 시작합니다.
- 데이터 구조는 화면 구성의 기반이 되므로 가능한 사실에 가깝게 정의하되, 세부적인 내용은 AI의 창의적인 제안을 수용할 수 있도록 여백을 둡니다.
- 처음부터 완벽한 명세서를 작성하려 하기보다, AI가 맥락을 파악할 수 있는 핵심 도메인 지식을 전달하는 데 집중합니다.
### 5가지 솔루션 후보 선정 및 구체화
- ChatGPT를 활용해 '스텝퍼형 마법사', '라이브 미리보기', '템플릿 복제', '채팅 입력', 'OCR 사진 촬영' 등 서로 다른 접근 방식의 솔루션 5가지를 도출합니다.
- 각 솔루션의 장단점을 분석하여 실무 적용 가능성을 판단하고, 프롬프트를 미세 조정하며 원하는 수준의 답변이 나올 때까지 반복 요청합니다.
- 이 과정에서 AI는 맥락을 축적하며 결과물의 품질을 높이며, 사용자는 여러 대안 중 최적의 사용자 경험(UX)을 선택할 수 있는 시야를 확보합니다.
### AI 기반의 와이어프레임 및 상세 설계
- 선정된 각 솔루션별로 필요한 화면 수, UI 요소, 공통 패턴(진행률 표시, 유효성 검사 등)을 AI가 상세히 설계하도록 유도합니다.
- 예를 들어 '스텝퍼형'의 경우 8단계의 상세 화면 구성을 정의하고, 각 단계에서 입력받을 필드와 도움말 문구까지 구체화합니다.
- 설계 과정에서 누락된 기능이나 우선순위 변경이 발견되면 프롬프트를 수정해 즉시 재설계하며, 물리적 설계 문서 작성의 부담을 최소화합니다.
### Cursor와 Flutter를 활용한 고속 구현
- AI 통합 개발 환경인 Cursor를 사용해 Flutter 기반의 모바일 앱 코드를 생성하며, 단일 코드베이스의 이점을 살려 실험 속도를 극대화합니다.
- 먼저 5가지 솔루션의 진입점이 포함된 공통 뼈대(Main Screen)를 작성한 뒤, 각 솔루션을 개별 파일로 나누어 점진적으로 구현합니다.
- 처음부터 상태 관리 라이브러리(Riverpod)나 데이터베이스(SQLite) 같은 기술 스택을 고민하지 않고, 기능 위주의 화면 데모를 먼저 만든 후 필요에 따라 스택을 추가하는 역순 방식을 취합니다.
이러한 방식은 '완성물이 최고의 디버거'라는 철학을 바탕으로 합니다. 문서 상의 논의에 시간을 쏟기보다 작동하는 앱을 빠르게 만들어 직접 만져보며 수정하는 것이 결과적으로 더 높은 품질의 제품을 더 빨리 만드는 길입니다. AI는 반복적인 재작업 요청에도 지치지 않으므로, 개발자는 이를 활용해 끊임없이 가설을 검증하고 정답에 가까워지는 '반복의 힘'을 믿어야 합니다.
대규모 언어 모델(LLM) 기반의 애플리케이션은 겉으로 보기에 단순해 보이지만, 내부적으로는 검색, 랭킹, 프롬프트 구성 등 복잡한 확률적 단계들이 체인처럼 연결되어 있어 미세한 수정만으로도 성능이 급변할 수 있습니다. Dropbox Dash 개발팀은 이러한 불확실성을 통제하기 위해 평가 프로세스를 단순한 사후 점검이 아닌 '프로덕션 코드'와 동일한 수준의 엄격한 표준으로 관리해야 한다고 강조합니다. 성공적인 AI 서비스를 위해서는 공공 및 내부 데이터를 혼합한 정교한 데이터셋 구축과 더불어, 단순 NLP 지표를 넘어선 LLM 기반의 자동화된 평가 체계를 구축하는 것이 핵심입니다.
### 다각적인 데이터셋 구축 전략
* **공공 데이터셋을 통한 베이스라인 수립**: Google의 Natural Questions, MS MARCO, MuSiQue 등을 활용해 대규모 문서 검색, 다중 문서 처리, 멀티홉(multi-hop) 질의응답 성능을 초기 단계에서 검증합니다.
* **실제 사용자 패턴 반영**: 사내 테스트(Dogfooding)를 통해 수집된 로그 데이터를 익명화하고 랭킹화하여 실제 사용자의 질문 방식과 의도를 반영한 대표 쿼리셋을 구성합니다.
* **합성 데이터(Synthetic Data) 활용**: 표, 이미지, 튜토리얼 등 다양한 콘텐츠 타입에 대해 LLM이 직접 질문과 답변 쌍을 생성하게 함으로써 실세계의 복잡한 사례들을 포괄합니다.
### 전통적 지표의 한계와 LLM 평가 도입
* **전통적 NLP 지표의 제약**: BLEU, ROUGE, BERTScore 등은 계산이 빠르지만, 답변의 사실 관계나 출처 인용의 정확성, 할루시네이션(환각) 여부를 판단하는 데에는 한계가 있습니다.
* **LLM 기반 판독(LLM-as-a-judge)**: 평가 모델(Judge Model)이 답변의 사실성, 질문에 대한 직접적인 응답 여부, 톤앤매너 등을 검토하며, 단순 점수뿐만 아니라 판단 근거(Justification)를 함께 제공하도록 설계합니다.
* **평가 모듈의 소프트웨어화**: 평가 프롬프트와 기준(Rubric)을 소프트웨어 모듈처럼 버전 관리하고, 정기적으로 정답 셋(Gold Standard)과 비교하여 평가 모델 자체의 성능을 교정합니다.
### 엄격한 워크플로우와 품질 관리
* **구조화된 평가 결과 산출**: JSON 형식으로 결과(사실 정확도, 인용 적절성, 명확성 등)를 출력하여 시스템이 즉각적으로 성공과 실패를 판단할 수 있는 '라이브 알람' 체계를 구축합니다.
* **휴먼 인 더 루프(Human-in-the-loop)**: 자동화된 평가가 전체의 대부분을 담당하더라도, 매 배포 시 엔지니어가 회귀 테스트 세트의 5~10%를 수동으로 검수하여 평가 모델의 편향이나 오류를 잡아냅니다.
* **반복적인 프롬프트 개선**: 수동 검수에서 발견된 불일치 사례를 추적하여 평가 프롬프트를 수정하거나 모델을 교체함으로써 전체적인 평가 루프의 신뢰도를 높입니다.
실질적인 AI 성능 향상을 위해서는 모델 훈련만큼이나 정교한 평가 인프라에 투자해야 합니다. 공공 데이터로 기초를 다지고 내부 로그로 실전 감각을 더하며, LLM 평가자를 엄격하게 관리하는 일련의 과정이 뒷받침될 때 비로소 신뢰할 수 있는 AI 서비스를 운영할 수 있습니다.
LY Corporation의 'Hack Day 2025'는 19년째 이어져 온 전통 있는 사내 해커톤으로, 직무와 국적에 상관없이 구성원들이 자유롭게 아이디어를 기술로 구현하는 혁신적인 개발 문화를 상징합니다. 참가자들은 24시간 동안 몰입하여 프로토타입을 제작하며, 'Perfect the Details' 정신을 바탕으로 기술적 검증과 협업의 가치를 실현합니다. 이번 행사는 단순한 개발을 넘어 글로벌 동료들과의 네트워크를 강화하고 창의적인 시도를 장려하는 LY Corporation만의 독보적인 기술 축제로 자리매김했습니다.
**자유로운 협업과 글로벌 팀 빌딩**
* 과거 야후 재팬 시절부터 시작되어 19회차를 맞이한 Hack Day는 기획자, 디자이너, HR 등 사내 구성원 누구나 참여할 수 있는 열린 행사입니다.
* 온/오프라인 밋업과 Zoom, Miro 등의 툴을 활용해 한국, 일본, 대만, 베트남 등 다양한 국가의 멤버들이 'Global Mixed Team'을 구성하여 협업합니다.
* 하이브리드 워크 환경에 맞춰 이동 시간 및 업무 집중 시간을 보장하는 'Travel Day' 제도를 통해 원격 근무자들이 오프라인에서 밀도 있게 협업할 수 있는 환경을 제공합니다.
**몰입을 돕는 환경과 해커톤의 문화**
* 행사 기간 동안 오피스의 한 층을 통째로 사용하며, 팀별 독립 공간과 화이트보드, 모니터 등 개발에 필요한 인프라를 전폭적으로 지원합니다.
* 1일 차 오전 9시, 전 참가자가 모여 "Hack Time!"을 외치는 개회 선언을 통해 행사의 본격적인 시작을 알리는 전통이 있습니다.
* 에너지 소모가 큰 해커톤 특성을 고려하여 시간대별로 도넛, 컵라면 등 다양한 간식과 전 세계 법인에서 가져온 이색 먹거리를 무제한 제공하여 개발에만 집중할 수 있게 돕습니다.
**AI 모델을 활용한 기술적 실천과 유연한 피보팅**
* 실제 프로젝트 사례로 Slack 커뮤니케이션 기록과 AI 모델을 결합해 개개인의 협업 성향을 분석하는 '전투력 측정' 프로그램을 개발했습니다.
* 성격 심리학 모델인 'Big 5 Personality'를 도입하여 데이터의 신뢰성을 확보하고, 이를 게임 캐릭터 능력치처럼 시각화하여 재미 요소를 더했습니다.
* 개발 마지막 단계에서 포토 프린터 하드웨어 장애라는 변수가 발생하자, 실물 카드 출력 대신 파일 다운로드 방식으로 기획을 신속하게 변경하며 해커톤 특유의 유연한 문제 해결 능력을 발휘했습니다.
**성과 공유를 위한 90초 발표와 부스 운영**
* 3일 차에는 각 팀이 결과물을 공유하며, 90초라는 엄격한 시간 제한 속에서 핵심 기능과 데모를 선보이는 '라이브 피칭'을 진행합니다.
* 발표 후에는 별도의 부스 운영 시간을 통해 심사위원과 다른 참가자들이 직접 서비스를 체험해 보고 기술적인 디테일에 대해 심도 있는 질의응답을 나눕니다.
* 창의성, 기술적 완성도, 발표 전달력을 종합적으로 평가하여 시상하며, 이를 통해 사내 기술 트렌드를 공유하고 성취감을 고취합니다.
Hack Day와 같은 사내 해커톤은 일상적인 업무에서 벗어나 최신 기술(AI 등)을 실험하고 동료와의 유대감을 쌓을 수 있는 최고의 기회입니다. 기술적 성장에 목마른 조직이라면, 결과물의 완벽함보다는 24시간 동안의 몰입 경험과 그 과정에서 발생하는 유쾌한 시행착오를 장려하는 문화를 구축해 보길 추천합니다.
AI 시대의 엔지니어는 코드를 빠르게 생성하는 사람을 넘어, 사용자 문제를 정의하고 더 나은 해결책을 탐색하는 사람이어야 한다. AI는 단순한 비용 절감이나 자동화 도구가 아니라, 엔지니어의 판단력·창의성·협업 능력을 확장하는 수단으로 활용해야 한다. 이를 위해 문제 탐색, 에이전트 활용, 코드 검토, 맥락 제공과 같은 새로운 업무 방식이 중요해진다.
## 자동화를 넘어 문제 해결에 AI 활용하기
- AI의 가치는 반복 작업을 줄이는 데만 있지 않고, 엔지니어가 더 높은 수준의 문제 정의와 해결에 집중하도록 돕는 데 있다.
- 코드 작성 외에도 엔지니어는 다음을 판단해야 한다.
- 어떤 문제를 해결할 것인가
- 사용자는 무엇을 필요로 하는가
- 어떤 방식이 가장 적절한가
- 단순하고 지루한 작업을 자동화하면 사용자 공감, 제품의 의미, 동료와의 협업처럼 자동화하기 어려운 영역에 더 많은 시간을 쓸 수 있다.
- AI 시대에도 제품에 대한 이해와 세심한 구현 품질은 여전히 핵심 역량이다.
## 바이브 코딩으로 가능성 탐색하기
- 바이브 코딩은 코드를 대충 생성하는 방식이 아니라, 자연어 대화를 통해 문제 공간을 탐색하고 해결책을 실험하는 방법이다.
- AI를 사용하면 기존의 한두 가지 접근법에 머무르지 않고 여러 경로를 빠르게 시도할 수 있다.
- 생성된 프로토타입이나 시각적 결과물을 공유해 사용자와 동료의 피드백을 일찍 받을 수 있다.
- Figma Make처럼 프롬프트로 앱과 고충실도 프로토타입을 만들면 구현에 들어가기 전에 사용자 경험을 검증할 수 있다.
- AI는 사용자 경험에 대한 고민을 없애는 것이 아니라, 더 앞단에서 충분히 검토하도록 돕는다.
## 에이전트와 MCP로 더 정확한 결과 만들기
- 에이전트형 AI는 Cursor나 Copilot 같은 도구가 다른 소프트웨어와 상호작용하며 작업하도록 만든다.
- MCP(Model Context Protocol)는 AI 도구와 외부 소프트웨어가 정보를 주고받는 표준이다.
- Figma MCP 서버는 디자인 구조, 컴포넌트, 관련 맥락을 LLM에 전달해 디자인에 충실한 코드를 생성하도록 돕는다.
- 충분한 맥락이 제공되면 다음과 같은 효과를 얻을 수 있다.
- 기존 컴포넌트 라이브러리 재사용
- 디자인 시스템 준수
- 접근성 규칙 반영
- 구현 결과와 디자인 간 차이 감소
- AI의 출력 품질은 모델 자체뿐 아니라, 모델에 전달하는 도구·코드베이스·디자인 맥락의 품질에 좌우된다.
## Pull Request를 스스로 사전 점검하기
- LLM을 PR 제출 전 검토자로 활용하면 코드 리뷰 전에 문제를 발견할 수 있다.
- 코드베이스를 이해하는 LLM은 다음과 같은 문제를 찾아낼 수 있다.
- 이미 존재하는 구현을 다시 작성한 경우
- 중복 로직
- 프로젝트의 기존 패턴과 어긋나는 코드
- 잠재적인 누락이나 개선 지점
- AI 리뷰는 사람의 최종 검토를 대체하기보다, 리뷰 요청 전에 작성자가 코드 품질을 높이는 사전 검증 단계로 유용하다.
- 결과적으로 리뷰어와 작성자의 부담을 줄이고 개발 처리량을 높일 수 있다.
## 여러 AI 에이전트를 조율하기
- 복잡한 문제를 작은 작업으로 분해하고, 각각을 여러 AI 에이전트에게 맡기는 능력이 중요해진다.
- 엔지니어는 각 에이전트에 명확한 지시와 맥락을 제공해야 한다.
- 작업 범위
- 관련 파일과 제약 조건
- 기대하는 출력 형식
- 프로젝트의 코딩 규칙
- 여러 에이전트가 만든 결과를 검토하고 하나의 일관된 해결책으로 통합하는 역할은 여전히 엔지니어의 몫이다.
- 마크다운 지침 파일이나 프로젝트 문서를 정리해 LLM에 지속적으로 맥락을 제공하는 것도 새로운 업무 역량으로 부상한다.
- 핵심은 AI에게 모든 판단을 위임하는 것이 아니라, 문제를 분해하고 결과를 조율하는 것이다.
## 기술보다 중요한 제품 감각과 협업
- AI가 코드를 빠르게 만들어도 무엇을 만들어야 하는지 결정하는 책임은 엔지니어에게 남는다.
- 사용자 관점에서 문제의 의미와 우선순위를 판단해야 하며, 동료와 함께 아이디어를 발전시켜야 한다.
- AI가 생성한 결과는 빠른 초안이나 탐색 도구로 활용하고, 최종 품질은 엔지니어의 검증과 제품 이해를 통해 확보해야 한다.
- 앞으로의 강한 엔지니어는 코딩 능력뿐 아니라 문제 정의, 맥락 전달, 결과 평가, 협업 능력을 함께 갖춘 사람이다.
AI를 도입할 때는 단순히 코드 생성량을 늘리기보다, 프로토타입 탐색과 사전 리뷰처럼 사고의 품질을 높이는 과정에 먼저 적용하는 것이 좋다. 특히 프로젝트 규칙과 디자인 시스템을 문서화하고 AI에 충분한 맥락을 제공하면 생산성과 결과의 정확도를 함께 개선할 수 있다.
기술 문서 부족 문제를 해결하기 위해 엔지니어링 관점에서 접근한 이 글은, 생성형 AI를 활용해 사내 기술 컨텍스트와 스타일 가이드가 반영된 API 레퍼런스를 자동 생성하는 프로젝트 과정을 소개합니다. 일반적인 코딩 어시스턴트의 한계를 극복하기 위해 프롬프트 워크플로를 최적화하고, 특정 IDE에 종속되지 않도록 MCP(Model Context Protocol)를 도입하여 범용성을 확보했습니다. 최종적으로 AI가 생성한 결과물은 높은 품질을 보였으나, 기술 문서의 특성상 정확성을 담보하기 위한 인간의 검토 단계가 필수적임을 강조하며 결론을 맺습니다.
## 기존 AI 도구의 한계와 도큐먼트 엔지니어링의 목표
* 기술 문서는 항상 부족하며, 개발자 교육만으로는 시간과 관심의 부재라는 근본적인 원인을 해결하기 어렵다는 판단하에 자동화 프로세스를 구축했습니다.
* GitHub Copilot과 같은 기존 도구는 코드 파악 능력은 뛰어나지만, 사내 전용 기술 용어나 특수한 스타일 가이드, 프로젝트별 컨텍스트를 반영하지 못하는 단점이 있습니다.
* '사내 정보를 참고해 스타일 가이드에 맞는 API 주석을 작성하고, 이를 한곳에서 배포하기'를 목표로 테크니컬 라이터의 노하우를 자동화 공정에 이식했습니다.
## 프롬프트 최적화와 단계별 워크플로 구성
* 초기에는 방대한 지시 사항이 담긴 긴 프롬프트를 사용했으나, LLM이 복잡한 지시를 놓치는 문제가 발생하여 실행 단계를 세분화했습니다.
* 처리 속도와 정확도 사이의 타협점을 찾기 위해 '프로그래밍 언어 인식', 'API 파악 및 예제 작성', '설명 및 파라미터/응답 값 작성'의 3단계 워크플로로 압축했습니다.
* LINE의 고유 식별자인 'MID'를 단순한 약어(Member ID 등)로 오해하지 않고 사내 정의에 맞게 설명하도록 컨텍스트를 주입하여 일반 AI 도구와 차별화된 품질을 구현했습니다.
## 범용성 확보를 위한 MCP(Model Context Protocol) 도입
* 초기 프로토타입은 VS Code 익스텐션으로 제작했으나, IntelliJ 등 다양한 IDE를 사용하는 개발자들의 요구를 수용하기 위해 MCP 기반으로 전환했습니다.
* MCP 서버는 클라이언트와의 통신에만 집중하므로, UI 구현에 드는 비용을 줄이고 언어 판별이나 코드 블록 선택 같은 부가 기능을 MCP 호스트(IDE 등)에 위임할 수 있습니다.
* 사용자가 AI와 대화하며 파라미터를 입력하는 방식은 현대적인 AI 사용 경험에 부합하며, 특정 도구에 종속되지 않는 범용적인 문서화 솔루션을 제공합니다.
## AI 문서화의 성과와 실질적인 한계
* 자체 평가 결과, 생성된 주석의 88%가 기준을 만족했으며 78%의 사례에서 GitHub Copilot보다 우수한 품질의 설명을 생성하는 성과를 거두었습니다.
* 그러나 AI는 확률 기반으로 작동하므로 100%의 정확성을 보장하지 못하며, 단 한 줄의 오류가 문서 전체의 신뢰도를 떨어뜨리는 API 레퍼런스의 특성상 위험 요소가 존재합니다.
* 따라서 AI를 '완벽하지 않은 동반자'로 정의하고, AI가 초안을 대량으로 빠르게 생산하되 마지막 단계에서는 반드시 담당 개발자가 내용을 검토하는 '사람 중심의 검증' 프로세스를 권장합니다.
Figma Make는 프롬프트 입력을 통해 아이디어를 실제 작동하는 프로토타입과 코드로 즉시 변환해주는 강력한 도구로, 설계 단계에서 상세한 맥락을 제공하는 것이 성공의 핵심입니다. 단순히 결과물을 생성하는 것에 그치지 않고 기존 디자인 자산을 최적화하고 복잡한 프로젝트를 단계별로 세분화하여 접근할 때 최상의 성과를 거둘 수 있습니다. 이를 통해 제품 팀은 단순한 시안 확인을 넘어 실제 앱과 유사한 수준의 인터랙티브한 사용자 경험을 신속하게 검증할 수 있습니다.
**초기 프롬프트의 상세 정보 극대화**
* 첫 번째 프롬프트에 구체적인 정보를 많이 포함할수록 사후 수정에 드는 시간을 획기적으로 줄일 수 있습니다.
* 프롬프트 구성 시 작업 내용(Task), 디자인이 놓인 맥락(Context), 핵심 디자인 요소, 상호작용에 따른 기대 동작, 제약 사항(기기 종류, 레이아웃 등)을 명확히 정의해야 합니다.
* Figma Make는 Anthropic의 Claude 3.5 Sonnet 모델을 기반으로 하므로, "수직 정렬"처럼 모호한 표현보다는 "요소를 20px 아래로 이동" 또는 "버튼 사이에 16px 간격 추가"와 같이 구체적인 수치를 사용하는 것이 효과적입니다.
**디자인 파일의 사전 정리 및 최적화**
* 백지상태에서 시작하는 것(0→1)뿐만 아니라 기존 디자인을 변환(1→1)할 때도 탁월하며, 이를 위해 오토 레이아웃(Auto Layout)과 레이어 명명 규칙을 철저히 정리하는 것이 중요합니다.
* Figma의 '레이어 이름 변경(Rename layers with AI)'이나 '오토 레이아웃 제안' 기능을 활용해 정돈된 프레임을 전달하면 AI가 디자인의 의도와 구조를 훨씬 더 정확하게 파악합니다.
* 생성된 결과물이 화면 밖으로 벗어날 경우 "내 화면 크기에 맞춰 반응형으로 만들어줘" 또는 "모바일 사이즈 유지"와 같은 후속 명령으로 레이아웃을 교정할 수 있습니다.
**복잡한 프로젝트의 단계별 세분화**
* 한 번의 프롬프트로 방대한 기능을 구현하려 하기보다, 작은 단위의 기능이나 페이지별로 나누어 점진적으로 빌드하는 것이 AI의 정확도를 높이는 방법입니다.
* 예를 들어 금융 대시보드를 만들 때, 먼저 핵심 레이아웃을 잡은 뒤 '노트 추가 기능', '통화 선택 체크박스' 등을 순차적인 프롬프트로 추가하여 제어력을 유지해야 합니다.
* 각 요소(예: 런던 아이, 빅벤 등 개별 오브젝트)를 별도의 코드 폴더로 분리하도록 명령하면, 전체 환경에 영향을 주지 않고 특정 컴포넌트만 정밀하게 수정하거나 유지보수하기 용이합니다.
**동작 중심의 마이크로 인터랙션 구현**
* 정적인 디자인을 넘어 "음악 재생 시 CD가 회전하게 해줘"와 같은 구체적인 동작을 지시하여 생동감 있는 프로토타입을 만들 수 있습니다.
* 복잡한 로직이 필요한 인터랙션의 경우, 베이스가 되는 그리드 컴포넌트를 먼저 구축한 후 세부적인 마우스 효과나 호버 상태를 단계적으로 입히는 전략이 유효합니다.
* 만약 반복적인 수정에도 결과가 만족스럽지 않다면, 이전 시도에서 배운 교훈을 바탕으로 새 파일에서 프롬프트를 다시 구성하여 시작하는 것이 더 효율적일 수 있습니다.
성공적인 Figma Make 활용을 위해서는 디자이너의 명확한 시각적 비전과 이를 논리적으로 전달하는 프롬프트 엔지니어링 역량이 결합되어야 합니다. 한 번에 완벽한 결과를 기대하기보다는 초기 생성물을 기반으로 수십 개의 미세 조정 프롬프트를 거치며 완성도를 높여가는 반복적(Iterative) 프로세스를 수용할 때 가장 강력한 결과물을 얻을 수 있습니다.
검색 증강 생성(RAG) 시스템의 성능을 최적화하기 위해 단순히 질문과 '관련된' 정보를 찾는 것을 넘어, 답변을 내기에 '충분한 문맥(Sufficient Context)'이 제공되었는지를 판단하는 새로운 관점을 제시합니다. 연구팀은 문맥의 충분성을 측정하는 자동 평가 도구(autorater)를 개발하여 RAG 시스템의 실패 원인을 분석하고 할루시네이션(환각)을 줄일 수 있는 방법론을 입증했습니다. 이를 통해 최신 대규모 언어 모델(LLM)이 충분한 정보 환경에서 어떻게 작동하는지 규명하고, 실제 서비스인 Vertex AI RAG 엔진에 해당 기술을 적용하여 정확도를 개선했습니다.
**충분한 문맥의 정의와 필요성**
* **관련성 vs 충분성**: 기존 RAG 연구는 질문과 문맥의 '관련성'에 집중했으나, 관련성이 높더라도 정답을 도출하기 위한 핵심 정보가 빠져 있으면 LLM은 잘못된 답변을 내놓을 위험이 큽니다.
* **충분한 문맥**: 질문에 대해 확정적인 답변을 제공하는 데 필요한 모든 정보가 포함된 상태를 의미합니다.
* **불충분한 문맥**: 질문과 관련은 있지만 정보가 불완전하거나, 결론을 내릴 수 없거나, 모순되는 정보가 포함된 경우를 말합니다.
**LLM 기반 자동 평가 도구(Autorater)의 설계 및 성능**
* **평가 메커니즘**: 질문과 검색된 문맥 쌍을 입력받아 해당 문맥이 답변에 충분한지 여부를 'True/False'로 분류하며, 체인 오브 쏘트(CoT) 및 1-샷 프롬프팅을 통해 성능을 최적화했습니다.
* **높은 분류 정확도**: Gemini 1.5 Pro를 활용한 이 방식은 별도의 미세 조정 없이도 전문가가 직접 레이블링한 데이터와 비교했을 때 93% 이상의 높은 일치율을 보였습니다.
* **기존 방식과의 비교**: 정답 키워드 포함 여부를 확인하는 방식이나 기존의 자연어 추론(NLI) 모델 기반 방식보다 Gemini를 활용한 프롬프팅 방식이 뛰어난 문맥 이해력을 바탕으로 더 정교한 판단을 내리는 것으로 나타났습니다.
* **효율적 대안**: 계산 자원의 효율성이 필요한 경우, Gemini보다는 다소 성능이 낮지만 미세 조정된 FLAMe(PaLM 24B 기반) 모델이 대안이 될 수 있음을 확인했습니다.
**RAG 시스템 성능 분석 및 실무적 통찰**
* **SOTA 모델의 특성**: Gemini, GPT, Claude와 같은 최신 모델들은 충분한 문맥이 주어지면 정답률이 매우 높지만, 문맥이 불충분할 때 "모른다"고 답하며 할루시네이션을 방지하는 능력에는 차이가 있었습니다.
* **성능 최적화 도구**: 이번 연구의 개념은 Google Cloud Vertex AI RAG 엔진의 'LLM Re-Ranker' 기능으로 구현되었습니다. 이는 검색된 스니펫을 질문과의 관련성 및 충분성에 따라 재정렬하여 nDCG와 같은 검색 지표 및 전체 시스템 정확도를 높입니다.
* **실패 분석**: RAG 시스템의 실패는 단순히 검색 품질의 문제뿐만 아니라, 충분한 정보가 있음에도 모델이 이를 제대로 추출하지 못하거나 불충분한 정보에서 억지로 답을 지어내는 과정에서 발생함을 확인했습니다.
RAG 시스템의 신뢰도를 높이기 위해서는 단순히 더 많은 문서를 검색하는 것보다, 검색된 결과가 질문에 답하기에 '충분한지'를 먼저 검증하는 단계가 필수적입니다. 개발자는 고성능 LLM을 활용한 자동 평가 단계를 파이프라인에 추가하거나, 리랭커(Re-ranker)를 도입하여 문맥의 질을 관리함으로써 할루시네이션을 획기적으로 줄일 수 있습니다.
구글 리서치는 전문적인 지식을 일반 사용자가 더 쉽게 이해할 수 있도록 정보의 손실을 최소화하면서 텍스트를 단순화하는 Gemini 기반 시스템을 공개했습니다. 이 시스템은 단순히 정보를 생략하는 요약이나 새로운 내용을 덧붙이는 설명과 달리, 원문의 세부 사항과 뉘앙스를 완벽하게 유지하면서 가독성만을 높이는 '고충실도(High-fidelity) 단순화'를 목표로 합니다. 대규모 무작위 대조 실험 결과, 이 기술은 사용자의 정보 이해도를 높이는 동시에 텍스트를 읽을 때 느끼는 인지적 부담을 유의미하게 감소시키는 것으로 나타났습니다.
### 최소 손실 텍스트 단순화의 정의와 목표
* **요약과의 차별화**: 정보를 누락시키는 일반적인 요약과 달리, 원문의 모든 핵심 주장과 세부 사항을 보존하는 '최소 손실(Minimally-lossy)' 방식을 지향합니다.
* **정확성 유지**: 의학, 법률, 금융 등 전문 용어가 많고 복잡한 텍스트에서 의미 왜곡 없이 문장 구조와 단어 선택을 최적화하여 명확성을 확보합니다.
* **사용자 임파워먼트**: 복잡한 정보 때문에 의사결정에 어려움을 겪는 사용자가 스스로 텍스트를 변환하여 내용을 파악할 수 있도록 돕습니다.
### Gemini를 활용한 자동 평가 및 프롬프트 정제 루프
* **가독성 및 충실도 평가**: 기존의 단순한 가독성 지표(Flesch-Kincaid 등)를 넘어, Gemini가 1~10점 척도로 가독성을 정밀 평가하며 원문과 단순화된 텍스트 간의 정보 일치 여부를 분석합니다.
* **LLM 기반 프롬프트 최적화**: Gemini 1.5 Pro가 Gemini 1.5 Flash가 생성한 결과물을 평가하고, 이를 바탕으로 더 나은 결과를 낼 수 있도록 프롬프트를 스스로 수정하는 루프를 구축했습니다.
* **반복적인 성능 향상**: 수동 프롬프트 엔지니어링의 한계를 극복하기 위해 총 824회의 자동 반복(Iteration)을 거쳐 최적의 단순화 전략을 발견했습니다.
### 대규모 연구를 통한 실증적 효과 검증
* **연구 설계**: 4,500명 이상의 참가자를 대상으로 의학, 항공우주, 철학 등 복잡도가 높은 31개 분야의 실제 텍스트를 활용하여 무작위 대조 실험을 진행했습니다.
* **이해도 측정**: 단순화된 텍스트를 읽은 그룹은 원문을 읽은 그룹보다 객관식 문제(MCQ) 정답률이 높았으며, 텍스트를 참고할 수 없는 상황에서도 더 높은 이해도를 보였습니다.
* **인지 부하 감소**: NASA-TLX(작업 부하 지수)를 활용해 측정한 결과, 사용자들은 단순화된 텍스트를 읽을 때 정신적 노력이 덜 들고 더 높은 자신감을 느낀다고 답했습니다.
이러한 기술적 성과는 현재 iOS용 구글 앱의 'Simplify' 기능을 통해 실제 서비스에 적용되었으며, 전문가 수준의 지식 장벽을 낮추어 정보의 민주화를 실현하는 데 기여하고 있습니다. 전문가의 언어를 대중의 언어로 정확하게 번역해야 하는 다양한 도메인에서 Gemini의 이 시스템은 매우 유용한 도구가 될 것입니다.
line원문
