업계 반발에도 RE Engine으로 진입하는 Capcom AI 게임 개발
Capcom은 개발자들 사이에서 생성형 AI에 대한 반대가 커지는 가운데, AI 게임 개발 전략을 RE Engine에 도입했다. 10월 2일 열린 기술 컨퍼런스에서 프로그래머 Ishida Satoshi는 회사의 내부 제작 기반을 단계적으로 재구축하기 위한 계획인 REX를 발표했다.
이 제안은 챗봇이 완성된 게임을 생성하도록 하는 것보다 훨씬 구체적이다. Capcom은 AI가 인간 개발자와 함께 읽고, 수정하고, 테스트하고, 점검할 수 있는 소프트웨어 시스템을 구축하려 한다. 회사가 밝힌 목표는 “AI와 함께 게임을 만드는 미래”다.
이 구분은 Capcom이 업계의 뚜렷한 분열 속에서 이 선택을 하고 있다는 점에서 중요하다. 스튜디오는 더 큰 프로젝트, 더 긴 제작 주기, 고비용의 품질 보증 업무에 직면해 있다. 그러나 많은 아티스트, 디자이너, 작가, 프로그래머는 생성형 AI가 일자리, 창작물의 소유권, 노동 환경을 위협한다고 본다.
Capcom은 Resident Evil, Monster Hunter, Street Fighter 전반에 사용되는 엔진 내부에 해답을 배치하고 있다. REX가 성공한다면 AI 지원은 출시 직전에 추가되는 눈에 보이는 기능이 아니라 개발을 뒷받침하는 인프라의 일부가 될 것이다.
Capcom AI 게임 개발은 창작 계층 아래에서 시작된다
Capcom은 완전한 게임을 생성하는 기계를 발표하는 것이 아니라, AI 호환성을 중심으로 제작 시스템을 재설계하고 있다.
Ishida는 도쿄에서 열린 Capcom Open Conference RE: 2026에서 이 계획을 발표했다. Capcom은 이미 독자 엔진의 다음 단계로 RE neXt Engine의 약자인 REX를 제시한 바 있다. 10월 발표는 이 로드맵에 보다 분명한 AI 방향성을 부여했다.
시점도 의도적이었다. RE Engine 개발은 2014년에 시작됐고, 이 기술은 2017년 Resident Evil 7과 함께 처음 출시됐다. 최초의 REX 컨퍼런스 보도에 따르면, Capcom은 이후 이를 27개 이상의 타이틀에 사용했다.
엔진은 게임을 제작, 실행, 디버그, 출시하는 데 쓰이는 공통 시스템을 제공한다. 그래픽, 애니메이션, 데이터, 물리, 도구, 플랫폼 지원 및 기타 기술 기능을 관리할 수 있다. 모든 제작팀이 이에 의존하기 때문에 엔진 변화는 스튜디오 전반의 업무 방식을 바꿀 수 있다.
컨퍼런스 보고서에 따르면 현재 2,000명 이상의 Capcom 개발자가 RE Engine을 사용한다. 이들에는 해외 직원과 다른 개발 환경에 익숙한 직원도 포함된다. 따라서 이 시스템은 원래 설계자들이 예상했던 것보다 더 많은 사람, 프로젝트, 업무 방식을 지원해야 한다.
게임 규모 역시 또 다른 문제를 만든다. 현대 게임에는 방대한 캐릭터, 애니메이션, 환경, 인터페이스 요소, 플랫폼별 구성 등이 포함된다. 작은 수정 하나도 대규모 데이터 세트 전반에 걸친 처리, 변환, 검증, 테스트를 촉발할 수 있다.
REX는 Capcom의 기존 기반을 버리지 않고 이러한 병목을 해결하기 위해 설계됐다. 회사의 엔진 로드맵은 RE Engine을 완전히 교체하는 대신 새 기술을 추가하는 점진적 전환을 설명한다.
이러한 점진적 접근 방식은 마이그레이션 위험을 줄인다. 팀은 기반 도구가 단계별로 바뀌는 동안에도 계속 게임을 출시할 수 있다. 또한 Capcom은 개별 구성 요소를 전사적으로 적용하기 전에 실제 제작 환경에서 시험할 수 있다.
공개 발표에서는 REX 내부의 여러 명명된 시스템을 소개했다. RE:Dox는 다양한 유형의 데이터가 표현되고 처리되는 방식을 표준화한다. RE:UI는 내부 개발 도구에 사용되는 인터페이스 프레임워크의 일부를 대체한다.
RE:Log는 기술 로그와 커뮤니케이션을 중앙화한다. RE:Flows는 시각적 게임 로직을 표준화된 프로그래밍 언어로 변환한다. RE:Runtime은 엔진이 대규모 객체 및 캐릭터 그룹을 처리하는 방식을 바꾼다.
이 구성 요소들이 모두 AI 제품은 아니다. 당장의 작업 대부분은 속도, 메모리 사용량, 데이터 일관성, 자동화, 협업 용이성에 관한 것이다. 그러나 이들이 공유하는 구조는 이후 더 깊은 수준의 기계 지원을 위한 엔진 기반을 마련한다.
이는 Capcom의 발표가 우선 인프라에 관한 이야기임을 뜻한다. 회사는 AI에 더 중요한 업무를 맡기기 전에 개발자와 기계가 이해해야 하는 정보를 재구성하고 있다.
REX가 엔진을 AI가 읽기 쉽게 만드는 이유
REX는 표준화된 코드와 데이터를 유용한 AI 지원의 전제 조건으로 본다.
AI 시스템은 내부 도구가 일관되지 않은 형식, 문서화되지 않은 동작, 또는 학습 자료에 전혀 등장하지 않는 특수 코드에 의존할 때 어려움을 겪는다. 인간 직원도 같은 장애물에 직면한다. 시스템이 공통된 패턴을 따를 때 두 집단 모두 혜택을 본다.
Capcom은 REX가 기반 기술의 더 많은 부분을 널리 이해되는 프로그래밍 규칙으로 옮길 것이라고 말한다. RE:Flows는 이러한 전략을 보여준다. 디자이너는 시각적으로 게임 동작을 조합할 수 있으며, 이 도구는 인터페이스 뒤에서 그 작업을 표준화된 코드로 변환한다.
그 이점은 편의성을 넘어선다. 시각적 스크립팅 도구는 종종 검토, 병합, 디버그가 어려워지는 형식으로 로직을 저장한다. 해당 로직을 읽을 수 있는 코드로 변환하면 협업과 자동화된 분석이 더 실용적으로 바뀐다.
AI 보조 도구는 장차 이 결과물을 점검해 오류를 설명하고, 수정안을 제안하거나, 테스트를 생성할 수 있다. 개발자는 여전히 의도한 동작을 정의한다. 기계는 일관된 기술적 표현을 기반으로 작동한다.
RE:Dox는 데이터에도 유사한 방식을 적용한다. 게임에는 각각 자체 규칙과 종속성을 가진 다양한 특수 형식이 존재한다. 공통 데이터 모델은 변환 작업을 줄이는 동시에 자동화된 시스템이 관계를 추적하기 쉽게 만들 수 있다.
RE:Log는 관측 계층을 구축한다. 로그는 개발 과정의 오류, 경고, 성능 이벤트 및 기타 활동을 기록한다. 이러한 기록을 중앙화하면 엔지니어는 증거가 개별 장비에 흩어지는 대신 검색 가능한 이력을 확보하게 된다.
이 이력은 현재의 인간 진단과 향후 AI 지원 진단을 모두 뒷받침할 수 있다. 모델은 새 장애를 이전 사고와 비교하고, 관련 변경 사항을 식별하며, 가능한 원인을 제안할 수 있다. 그 가치는 정확한 기록과 통제된 접근 권한에 달려 있다.
Capcom은 이미 조직 지식 시스템에 관심을 보여 왔다. 컨퍼런스 프로그램에는 10년간 축적된 기술 지식에 접근하기 위한 내부 대규모 언어 모델 인터페이스인 REAssistAI가 포함됐다. 이 프로젝트는 본 발표에서 자세히 설명한 5개 REX 구성 요소와는 별개이지만, 같은 논리를 따른다.
회사는 사실상 개발 이력을 기계가 읽을 수 있는 맥락으로 전환하고 있다. 이 접근 방식은 문서와 기록이 일상적인 기술 업무와 연결된 특화 엔지니어링 지식 베이스와 닮아 있다.
RE:UI는 테스트 가능성을 통해 기여한다. Capcom은 사람이 화면을 지켜보지 않아도 소프트웨어가 구성 요소를 점검할 수 있도록 인터페이스 프레임워크를 설계했다. 이러한 분리는 자동화된 테스트를 더 쉽게 실행하고 반복할 수 있게 한다.
RE:Runtime은 실행 성능을 다룬다. 이 시스템은 모든 객체를 개별적으로 관리하는 대신 작업을 더 효율적으로 처리할 수 있는 블록으로 묶는다. 또한 개발자 친화적 코드를 Capcom의 성능 지향 RE:C++ 언어로 변환한다.
이러한 변화가 AI가 매력적인 Resident Evil 레벨을 독립적으로 설계할 수 있음을 뜻하지는 않는다. 이는 자동화 도구가 작동할 수 있는 더 정돈된 운영 표면을 마련한다. Capcom은 우선 인간과 기계 모두의 작업을 불안정하게 만드는 모호성을 줄이고 있다.
이것이 회사의 더 큰 주장 뒤에 있는 메커니즘이다. AI는 엔진이 코드, 데이터, 로그, 테스트, 워크플로를 소프트웨어가 일관되게 해석할 수 있는 형태로 노출한 뒤에야 유용해진다.
진짜 갈등은 지원과 대체 사이에 있다
Capcom은 AI를 제작 파트너로 규정하는 반면, 많은 개발자는 같은 기술을 인력 대체로 이어지는 경로로 본다.
회사가 선호하는 활용 사례는 내부 업무에 초점을 맞춘다. Ishida는 AI가 프로그램을 이해하고, 코드를 만들고, 테스트 세션을 실행하며, 빌드의 결함을 점검할 수 있는 미래를 설명했다. 이러한 업무는 창작 과정 주변에 위치하지만, 누가 그 일을 수행하는지에는 여전히 영향을 줄 수 있다.
테스트는 분명한 사례를 제공한다. 대규모 게임은 캐릭터, 환경, 하드웨어 구성, 플레이어 행동 전반에 걸쳐 반복적인 검사를 필요로 한다. 자동화 에이전트는 인간 테스터보다 더 오랜 시간 예측 가능한 시나리오를 실행할 수 있다.
Capcom의 컨퍼런스 프로그램은 영상과 오디오를 모두 평가하는 자율 테스트도 별도로 다뤘다. 이러한 시스템은 재현 가능한 오류를 더 일찍 찾는 데 도움이 될 수 있다. 그러나 전투가 공정하게 느껴지는지, 농담이 효과를 내는지, 공포 장면이 의도한 긴장감을 조성하는지는 자동으로 판단할 수 없다.
코드 지원도 비슷한 구분을 지닌다. AI는 일상적인 구현 초안을 작성하고, 문서를 검색하며, 흔한 실수를 식별할 수 있다. 하지만 엔지니어는 여전히 아키텍처, 성능, 보안, 유지보수성, 잘못된 제안이 초래할 결과를 평가해야 한다.
이러한 인간 검토는 사소한 마지막 단계가 아니다. 게임 엔진은 여러 플랫폼에서 엄격한 메모리 및 시간 제약 아래 작동한다. 모델의 그럴듯한 답변도 특정 부하에서만 나타나는 미묘한 오류를 일으킬 수 있다.
Capcom은 이미 다른 영역에서 생성형 AI를 실험했다. Google은 이 퍼블리셔가 게임 설정과 오브젝트를 위한 대량의 아이디어를 생성하기 위해 Vertex AI와 Gemini를 사용한다고 밝혔다. Capcom AI 프로젝트는 생성된 자산을 직접 출시하기보다 브레인스토밍을 가속하는 수단으로 제시됐다.
이전 프로젝트는 유난히 반복적인 업무를 다룬 것으로 전해진다. 팀은 일관된 가상 세계를 개발하는 과정에서 때로 수십만 개의 배경 아이디어가 필요했다. 모델은 제약 조건 안에서 초기 후보를 만들고, 직원들은 관련성과 품질을 평가할 수 있었다.
REX는 범위를 브레인스토밍에서 기술적 제작으로 확장한다. Capcom이 AI 생성 아트를 출시 게임에서 제외하더라도 이는 의미 있는 확대다. 코드 생성, 자동화 테스트, 로그 분석은 모두 일정, 인력 구성, 책임에 영향을 미친다.
노동 환경은 이러한 선택을 민감하게 만든다. 2026년 개발자 설문조사는 게임 업계 종사자 2,300명 이상으로부터 응답을 수집했다. 조사 결과 36%가 업무에서 생성형 AI를 사용한다고 답했다.
도입이 곧 지지로 이어지지는 않았다. 생성형 AI가 업계에 부정적 영향을 미치고 있다고 답한 비율은 52%로, 1년 전의 30%보다 높았다. 긍정적 영향을 준다고 본 비율은 7%에 그쳤다.
반대는 게임 제작과 가장 가까운 노동자들 사이에서 특히 강했다. 부정적 응답은 비주얼 및 테크니컬 아티스트에서 64%, 디자인 및 내러티브 종사자에서 63%, 프로그래머에서 59%에 달했다.
이 결과는 Capcom AI 게임 개발의 핵심 긴장을 만든다. 경영진은 자동화를 늘어나는 제작 비용에 대한 방어 수단으로 볼 수 있다. 노동자는 같은 투자를 이미 정리해고의 영향을 받은 직무에 대한 압박으로 볼 수 있다.
Capcom은 REX가 직무를 없앨 것이라고 발표하지 않았다. 또한 이 프로젝트와 연계된 인력 보장도 제공하지 않았다. 책임 있는 해석은 무해한 지원이라고 단정하거나 자동화된 대체 계획이라고 선언하는 것 사이에 있다.
Capcom이 성공을 어떻게 측정하느냐가 결정적인 쟁점이 될 것이다. 대기 시간 단축, 버그 조기 발견, 반복 작업 감소를 통해 REX를 평가한다면 파트너십 주장은 신뢰를 얻을 수 있다. 인력 감축이 주된 결과가 된다면, 대체에 대한 우려는 더 이상 쉽게 일축하기 어려워진다.
저작권, 보안, 신뢰성은 여전히 해결되지 않았다
기계가 읽을 수 있는 엔진이 훈련 데이터의 소유자, 생성된 코드의 승인권자, 자동화 실패 시 책임자를 결정해 주는 것은 아니다.
Capcom은 이러한 위험 가운데 일부를 인정하고 있다. 회사는 공개된 투자자 대화에서 이미 버그 점검과 RE Engine 효율 개선에 AI를 활용하고 있다고 밝혔다. 또한 저작권, 데이터 보안, 전문 인력 교육을 계속되는 우려 사항으로 지목했다.
저작권 문제는 시스템과 그 입력 데이터에 따라 달라진다. 승인된 Capcom 코드를 사용해 내부적으로 훈련된 도구는 출처를 알 수 없는 저장소로 훈련된 공개 모델과 다른 위험을 수반한다. 컨퍼런스 발표에서는 완전한 모델 거버넌스 정책이 제시되지 않았다.
선별된 기술을 공개하는 일도 또 다른 복잡성을 더한다. Capcom은 외부 개발자와 AI 시스템이 RE:Dox 및 RE:Log를 이해할 수 있도록 해당 기술의 일부를 공개할 계획인 것으로 전해졌다. 오픈 소스 코드는 문서화, 테스트, 상호운용성을 개선할 수 있다.
그러나 신중한 보안 검토가 필요한 아키텍처 세부 사항을 노출할 수도 있다. Capcom은 재사용 가능한 인프라를 독점 시스템, 자격 증명, 게임 데이터, 미공개 제작 정보와 분리해야 한다. 공개 저장소만으로 안전한 AI 활용이 보장되지는 않는다.
데이터 유출은 더 즉각적인 업무 환경의 우려를 낳는다. 프롬프트가 통제된 환경을 벗어나면 개발자는 기밀 코드나 에셋을 노출할 수 있다. 엔터프라이즈 접근 규칙, 로그 기록, 보존 제한, 모델 격리는 모델의 역량만큼이나 중요해질 것이다.
신뢰성은 별개의 위험을 제기한다. 대규모 언어 모델은 검증된 엔지니어링 판단이 아니라 그럴듯한 결과를 생성한다. API를 지어내거나 플랫폼 제약을 간과하고, 컴파일은 되지만 올바르게 작동하지 않는 코드를 권장할 수 있다.
자동화된 테스트 역시 입력받는 테스트를 반영한다. 에이전트는 예상치 못한 플레이어 행동을 놓친 채 스크립트화된 경로를 반복적으로 완료할 수 있다. 혼란스러운 디자인, 접근성 문제, 흥미롭지 않은 전투 조우를 인식하지 못한 채 기술적 안정성만 확인할 가능성도 있다.
REX는 생성 과정을 실행 및 검증과 연결함으로써 일부 실패를 줄일 수 있다. 코드를 작성하고, 빌드하고, 테스트를 실행하는 어시스턴트는 분리된 프롬프트만으로 작업하는 도구보다 더 나은 피드백을 받는다. 그럼에도 인간이 정의한 승인 기준은 여전히 필요하다.
창의적 품질은 여전히 더 형식화하기 어렵다. Capcom의 게임은 타이밍, 비주얼 디렉션, 레벨 구성, 성능, 그리고 의도적으로 설계된 플레이어 기대에 의존한다. 이러한 특성은 단지 유효한 코드가 아니라 반복과 판단을 통해 나타난다.
Pragmata는 이 발표에 독특한 문화적 배경을 제공한다. 이 게임의 공상과학 서사는 인공지능에 대한 위험한 의존을 탐구한다. Capcom의 제작 전략이 그 허구와 동일한 것은 아니지만, 그 대비는 실제 문제를 부각한다.
회사는 개발자들에게 가장 가치 있는 IP를 만드는 데 사용되는 시스템 내부의 AI를 신뢰해 달라고 요구하고 있다. 그 신뢰는 눈에 보이는 안전장치, 정확한 결과, 명확한 책임성에서 나와야 한다. 협업에 관한 슬로건은 이러한 통제를 대체할 수 없다.
따라서 가장 큰 미해결 질문은 거버넌스다. 누가 생성된 변경 사항을 승인할 수 있으며, 그러한 변경 사항은 어떻게 표시되는가? 모델은 어떤 데이터에 접근할 수 있고, 그 데이터는 얼마나 오래 보존되는가?
Capcom은 또한 인간 검토자에게 자동화된 결과물을 검토하고 이의를 제기할 충분한 시간이 주어지는지 판단해야 한다. AI 지원은 팀이 책임 있게 검토할 수 있는 속도보다 더 빠르게 제안 코드의 양을 늘릴 수 있다. 생성 속도가 빨라진다고 제작 속도까지 빨라지는 것은 아니다.
신뢰할 수 있는 프로그램이라면 외부로 유출된 결함, 오탐, 검토 시간, 보안 사고, 직원 경험을 추적할 것이다. Capcom은 아직 이러한 측정치를 공개하지 않았다. 그때까지 REX는 입증된 제작 개혁이 아니라 기술적 방향성에 머문다.
Capcom의 AI 전략이 효과를 내는지 보여줄 세 가지 신호
다음 증거는 실제 작동하는 도구, 공개된 안전장치, 측정 가능한 개발 성과에서 나와야 한다.
첫 번째 신호는 REX 구성 요소의 출시와 도입이다. Capcom은 전환이 점진적으로 이뤄질 것이라고 밝혔으며, 이는 개별 시스템을 더 쉽게 평가할 수 있게 한다. RE:Dox, RE:UI, RE:Log, RE:Flows, RE:Runtime은 더 폭넓은 AI 비전이 도래하기 전에 관찰 가능한 변화를 만들어야 한다.
유용한 증거로는 반복 작업 시간 단축, 도구 멈춤 현상 감소, 더 빠른 데이터 처리, 더 신뢰할 수 있는 자동화 테스트 등이 있다. 시연은 제한적인 실험실 사례가 아니라 실제 제작 환경을 보여줘야 한다.
오픈 소스 활동도 또 하나의 지표가 될 것이다. 공개 코드, 문서, 이슈 이력, 외부 기여는 선별된 REX 기술이 검증을 견딜 만큼 성숙했는지 보여줄 수 있다. 또한 어떤 부분이 여전히 내부에 남아 있는지도 분명히 할 수 있다.
두 번째 신호는 Capcom의 거버넌스 정책이다. 회사는 저작권과 보안 우려를 인정했지만, 이를 인정하는 것만으로 운영 규칙이 수립되는 것은 아니다. 개발자는 모델이 어떤 데이터를 사용하는지, 어떤 결정에 인간의 승인이 필요한지 알아야 한다.
공개 내용은 기존 자동화와 생성형 AI를 구분해야 한다. 런타임 객체를 그룹화하는 시스템은 소스 코드를 생성하는 모델과 동일하지 않다. 이를 하나의 AI 라벨로 묶으면 기술적 평가와 노동 논의 모두의 정밀성이 떨어진다.
Capcom은 생성된 코드에 식별 가능한 출처 정보가 부여되는지도 설명해야 한다. 검토자는 어떤 모델이 변경을 만들었는지, 어떤 맥락을 제공받았는지, 어느 직원이 이를 승인했는지에 대한 기록이 필요하다. 이 기록은 이후 결함이 발생할 때 중요해진다.
세 번째 신호는 제작팀과 일정에 실제로 어떤 일이 벌어지는지다. 게임이 더 정교해지면서 Capcom은 증가하는 투자 수요에 직면하고 있다. 회사의 자체 보고에 따르면 판매 확대를 계속하면서 수익률도 개선하고자 한다.
REX가 대기 시간과 반복 업무를 없앤다면, 팀은 디자인, 최적화, 플레이어 중심 테스트에 더 많은 시간을 쓸 수 있어야 한다. 이런 결과는 AI가 파트너로 작동한다는 Capcom의 주장을 뒷받침할 것이다.
일정이 계속 늘어나는 동시에 업무 강도가 높아진다면 효율성 주장은 약해진다. 품질 데이터의 개선 없이 AI 도입이 초급 인력 채용 축소나 테스트팀 축소와 함께 이뤄지는 경우도 마찬가지다.
업계의 정서는 여전히 유용한 균형추가 될 것이다. GDC 설문조사는 사용과 수용이 서로 반대 방향으로 움직일 수 있음을 보여준다. 개발자는 고용주가 요구하기 때문에 도구를 도입하면서도 그 가치를 계속 의심할 수 있다.
경쟁사의 움직임도 중요하다. 2026년 설문조사에서 Unreal Engine은 개발자 42%가 주로 사용하는 엔진이며, Unity는 30%를 차지한다. 이들의 AI 도구는 Capcom의 내부 플랫폼을 평가할 외부 기준을 마련한다.
Capcom은 RE Engine을 범용 상용 제품으로 판매하지 않으므로 엔진 시장에서 승리하기 위해 REX가 필요한 것은 아니다. 그러나 내부 도구는 더 큰 외부 플랫폼을 사용하는 스튜디오에 제공되는 기능과 경쟁할 수 있어야 한다.
엔진에 대한 회사의 통제력은 장점이다. Capcom은 AI 도구를 자사의 데이터 형식, 빌드 시스템, 테스트 인프라, 기술적 이력에 직접 연결할 수 있다. 타사 공급업체의 로드맵을 기다릴 필요가 없다.
그러나 이러한 통제는 책임도 집중시킨다. REX가 신뢰할 수 없는 워크플로우나 불충분한 안전장치를 만들어 낸다면 Capcom은 외부 엔진 제공업체를 탓할 수 없다. 회사가 아키텍처, 구현, 그리고 업무 환경상의 결과를 책임진다.
Capcom의 AI 게임 개발을 가장 신뢰성 있게 해석하면, 그것은 자율적 창작도 단순한 마케팅도 아니다. 이는 스튜디오의 기술 환경을 사람과 기계 모두가 이해할 수 있도록 만들기 위한 장기적 노력이다.
그 노력은 화려하지 않은 엔지니어링에서 시작된다. 표준화된 데이터, 읽기 쉬운 코드, 중앙화된 로그, 더 빠른 인터페이스, 반복 가능한 테스트가 그것이다. AI는 전체 기반이 아니라 그다음 계층이 된다.
개발자에게 당장의 질문은 모델이 완전한 게임을 만들 수 있는지가 아니다. AI가 소유권, 판단, 고용 조건을 약화시키지 않으면서 측정 가능한 마찰을 제거할 수 있는지가 핵심이다.
REX 출시, Capcom의 안전장치, 제작팀이 실제로 경험하는 결과를 지켜봐야 한다. 이러한 신호가 “함께 만든다”는 표현이 생산적인 협업을 뜻하는지, 아니면 사람에게서 일을 이전하는 과정을 부드럽게 표현한 말인지 결정할 것이다.



