Two-Rabbits

UI 표준

UI 표준은 디자인적인 철학과 기본 원칙에 따라 시스템에 적용하도록 만드는 화면 이동과 화면 구성 등 UI에대한 규약입니다.

구체적인 UI표준의 구성 요소에 대해서 자세히 알아보겠습니다.

- 전체적인 UX원칙: 표준은 사용자의 관점에서 효율적인 업무를 진행할 수 있도록 UX원칙을 정의합니다.

- 정책 및 철학: 조직의 목표와 조직 정체성을 포함하는 정책과 철학을 표준으로 설정해야 합니다.

- UI 스타일 가이드: UI의 구동환경과 레이아웃 등을 정의하고 가이드를 정리한걸 UI스타일 가이드라합니다.

- UI 패턴모델 정의 : CRUD 방식(Create, Read, Updete, Delete)을 기반으로한 입출력의 패턴모델을 정의합니다.

- UI 표준 수립을 위한 조직 구성: UI의 핵심인 UI팀 과 표준개발팀 두 팀을 주축으로 표준 수립을 위한 추진 조직을 구성합니다.

UI 지침

UI 표준에 따라서 사용자 인터페이스 설계와 같이 개발에 지켜야하는 세부적인 사항을 규정한 가이드 라인을 UI 지침이라 합니다. 

UI 지침을 이용해 사용자 트렌드 분석을 할 수 있습니다. 또한 기능과 설계 분석을 이용해 UI 표준을 적용할 환경을 분석하는데 이용합니다.

UI 개발을 위한 주요 기법

UI 개발을 위한 주요 기법에 대해서 알아보겠습니다.

처음으로 설명한 분석 기법은 3C 분석입니다. 3C는 고객(Customer)과 자사(Company), 경쟁사(Competitor)의 앞글자인 C를 의미합니다.

3C를 비교 분석을 통해 어떤 차별화를 두어야 고객의 마음을 얻을지, 경쟁에서 자사가 이길지 분석하는 기법을 말합니다.  

다음으로 소개할 기법은 SWOT 분석입니다. SWOT도 3C와 마찬가지로 강점(Strength), 약점(Weakness), 기회(Opportunity), 위협(Threat) 4가지 단어의 앞글자를 따서 지어진 이름입니다.

SWOT는 기업의 내부 환경과 외부 환경을 분석을 통해 강점, 약점, 기회, 위협 요인을 규정합니다. 이를 토대로 경영전략을 수립하는 분석기법입니다.

다음은 시나리오 플래닝입니다. 시나리오 플래닝은 간단하게 말하면 앞으로 일어날 일에 대해 예측하는 기법입니다.

확실한 해답이 없는 상황에서 앞으로 일어날 변화를 예측해 다양한 시나리오를 설계합니다. 이 시나리오를 기반으로 불확실성을 제거하는 경영전략 기법입니다.

다음으로 이야기할 분석기법은 사용성 테스트(Usability Test)입니다. 샤용성 테스트는 사용자에게 미리 작성된 시나리오를주고 지시를 따라가며 직접 제품을 사용하게 합니다. 그 이후 질문에 답을 하는 테스트 방법입니다.

이 방법을 통해서 지시에 따라가면 어떤 불편한점을 사용자가 겪게 되는지 알수 있고 해결 방법을 제품 출시 전에 찾을 수 있습니다.

마지막 분석 기법은 워크숍(Workshop)입니다. 워크숍은 집단이 어떤 문제에 대해 자신이 가진 지식과 기술, 아이디어를 서로 교환합니다. 이 과정을 통해 문제점과 해결방안을 검토하는 연구회 및 세미나입니다.

사용자 요구사항 도출

다음으로는 사용자 요구사항을 도출하는 기법에 대해서 알아보겠습니다.

첫번째로 소개할 페르소나(Persona)정의는 가상의 사용자를 이용한 요구사항 도출 방법입니다. 잠재적 사용자의 목적과 행동 패턴을 응집시켜 놓은 가상의 사용자를 사용한 기법입니다.

콘셉트 모델 정의는 여러가지 콘셉트의 관계를 보여주는 다이어그램입니다. 다양한 아이디어를 시각화를 통해 이야기 함으로 전달력이 증가하고 구성원들의 생각을 효율적으로 이끌도록 도와줍니다.

사용자 요구사항 정의는 리서치와 페르소나에서 나온 결과물을 이용하는 방법입니다. 두 분석 기법에서 나온 요구사항을 도출하고 우선순위를 정하는 과정입니다.

UI 컨셉션은 정리된 요구사항을 구체화 하는 단계입니다. 화면 디자인 전에 대표 화면 설계를 진행하는 단계입니다. 

UI 화면 설계

- 와이어 프레임 (Wireframe)

와이어 프레임은 이해관계자들과 화면 구성을 협의나 서비스의 대략적인 흐름을 이해하는데 필요한 설계방법입니다.

정적인 화면 단위의 레이아웃을 설계를 통해 이해관계자 들은 서비스의 흐름에 대해 더 명확하게 이해할 수 있습니다.

- 스토리보드 (Storyboard)

스토리보드는 서비스 구축을 위한 모든 정보가 담긴 설계 산출물입니다.

스토리보드에 들어갈 내용으로는 정책, 프로세스, 콘텐츠 구성, 와이어 프레임(UI, UX), 기능 정의, 데이터 베이스 연동 등이 있습니다.

- 프로토타입 (Prototype)

프로토타입은 실제 구현된 것 처럼 시뮬레이션입니다.

정적 화면으로 설계 된 와이어 프레임과 스토리 보드에 동적인 효과를 적용시켜 더욱 구체적인 화면설계와 동작방법들을 보고 이해하도록 구성된 모형입니다.

UI 요구사항 확인

UI(User Interface)는 넓은 의미로 이해했을 때와 좁은 의미로 이해했을 때의 개념이 달라집니다. 넓은 의미로 UI는 사용자와 시스템 사이 의사소통을 위해서 만들어진 물리적이거나 가상적인 매계체입니다. 좁은 의미의 UI는 사용자가 소프트웨어를 사용하며 접하며 마주하게 되는 화면을 의미합니다.

UI와 함께 이야기가 나오는 개념으로는 UX(User experience)가 있습니다. 직역하면 사용자의 경험이라는 뜻의 UX는 어떤 시스템이나 서비스를 이용하며 느끼거나 생각하는 모든 경험을 이야기합니다. UI보다 더 큰 개념이 되므로 UI도 UX에 포함됩니다.

UI 유형

UI의 의미를 이해했으니 이제 접근 기반에 따라 달라지는 UI의 각 유형에 대해서 설명하겠습니다. UI는 총 4가지 유형이 있습니다.

CLI(Command Line Interface)은 정적인 텍스트 기반의 인터페이스입니다. 명령어를 텍스트로 입력하여 조작하게 됩니다.

CLI의 예시로는 우리가 자주보는 가상 터미널이나 텍스트 터미널이 있습니다.

다음은 GUI(Graphical User Interface)입니다. GUI는 그래픽 반응 기반 인터페이스입니다. 그래픽을 기반으로 마우스나 전자펜을 이용해 사용자는 조작이 가능합니다.

GUI는 우리가 실생활에서 많이보는 UI입니다. window에서 아이콘을 마우스로 클릭하거나 게임 내부에서 마우스로 각종 창을 열고 닫는 조작방법이 전부 GUI에 속합니다.

세번째로 이야기할 유형은 NUI(Natural User Interface)입니다. NUI는 신체부위를 이용하는 사용자 반응 기반 인터페이스입니다. 키보드나 마우스를 사용하지 않더라도 터치나 음성 등을 통해 시스템을 조작합니다.

NUI가 사용되는 예시로는 현대인의 필수품인 스마트폰과 좀 더 나아가 SF영화에서 자주보이는 빔 프로젝트로 띄운 스크린을 터치하는 방식 또한 예시가 됩니다. 

OUI(Organic User Interface)은 현실에 존재하고 있는 모든 사물을 입출력 장치로 보는유기적 상호작용 기반의 인터페이스입니다.  

OUI의 경우 이해하기 어려울 수 있습니다. 하지만 NUI를 기반으로하고 모든 사물과 소통한다는 것만을 이해하면 OUI에 대해 좀더 이해하기 쉬워질 것입니다. 

UI 설계원칙

UI는 설계시 반드시 지켜야할 4가지 원칙에 대해 알아보겠습니다.

- 직관성(Intuitiveness): UI의 직관성은 어떤 사람이 이용해도 이해와 사용이 쉬워야 합니다.

- 유효성(Efficiency): 유효성의 의미는 사용자의 목표가 완벽하게 달성될 수 있도록 UI를 제작해야 되는 것을 말합니다.

- 학습성(Learnability): 누구나 이 UI를 쉽게 배우고 사용하도록 만들어져야 한다는 걸 학습성이라 합니다.

- 유연성(Flexibility): 유연성은 사용자와 기기의 의사소통이 최대한 원할하고 유연하게 이뤄져야하는걸 말합니다. 반드시 의사소통 과정에서 실수가 없도록 제작되어야 합니다.

UI 설계지침

UI는 또한 설계시 지키면 좋을 지침이 있습니다. 여기서 이야기하는 지침을 모두 완벽하게 외우려는 것 보다는 이해하도록 노력하는게 좋습니다.

- 사용자 중심

사용자가 중심의 UI설계를 통해 사용자가 이해하기 쉽고 편리하도록 만들어야합니다. 직관적인 환경을 기반으로 실제 사용자에 대한 파악을 하고 UI를 설계하도록 합니다.

- 일관성

버튼과 조작이 일관성을 가지고 있어 사용자가 기억하기 쉽게 UI를 설계하면 좋습니다. 일관성을 가지게 되면 사용자는 UI를 빠르게 습득할 수 있습니다.

- 단순성

너무 복잡한 UI 구성보다는 간단한 조작 방법으로 시스템이 작동하도록 설계하면 좋습니다.

- 결과 예측 가능

작동할 기능에 대해서 사용자가 결과를 예측할 수 있는 UI를 설계해야 합니다.

- 가시성

UI를 설계할 때 주요 기능을 가장 잘보이는 메인화면에 노출해 사용자가 알기 쉽고 쉬운 조작을 하도록 도와줍니다.

- 표준화

디자인 표준화를 통해 기능 구조를 선행 학습하게 되면 이후 조작이 전에 비해 월등하게 사용이 쉬워집니다.

- 접근성

특정한 사용자 층만을 배려해서 UI를 설계하는 것이 아닌 다양한 직무와 나이, 성별 등을 고려해 다양한 계층을 수용할 수 있는 UI를 설계해야 합니다.

- 명확성

사용자가 UI에 대해서 개념적으로 쉽게 인지하고 프로그램을 사용해야 합니다.

- 오류 발생 해결

프로그램을 사용하는 사용자가 오류에 대해 정확하게 인지할 수 있도록 UI를 설계해야합 합니다.

UI 요구사항 확인

사용자가 얻고자 하는 최종 목표를 UI 요구사항이라 합니다. UI 요구사항은 시스템이 개발되는 과정의 기준이 됩니다. 시스템이 개발 종료되면 이후 검수의 기준이 되기도 합니다. 

UI 요구사항은 시스템이 어떤 동작을 하는지 설명하는 기능적 요구사항과 개발 과정에서 지켜야하는 제약조건을 설명하는 비기능적 요구사항 두 가지로 분류됩니다.

기능적 요구사항은 시스템이 제공하는 기능과 더불어 입출력과 데이터, 연산 등 서비스에 대한 전반적인 요구사항을 담고 있습니다. 

비기능적 요구사항은 사용성과 유지보수성, 재사용성 등 품질에 관련된 요구사항이나 비용, 일정 등 전반적인 프로젝트에 대해서 다루는 요구사항입니다.

비기능적 요구사항도 시스템에 대해서도 다루고 있지만 시스템이 무엇을 제공하는지에 초점을 맞춘 기능적 요구사항과는 달리 시스템이 어떤 기술을 사용하고 플랫폼은 무엇인지 등 전반적인 시스템 환경을 중심으로 요구사항을 정리해 두었습니다. 

인터페이스에는 다양한 보안 취약점이 존재합니다. 인터페이스를 위해 송 · 수신 시스템 사이의 데이터 통신이 일어날때 데이터 전송 내역을 엿듣는 스니핑을 이용하여 데이터를 탈취할 수 있습니다. 

즉, 인터페이스에는 데이터 통신 시 데이터 탈취 위협이 있고, 데이터 통신 시 데이터 위 · 변조위협이 있을 수 있습니다. 이런 위협에서 벗어나기 위해서는 안전한 코딩 수칙을 준수해야합니다.

시큐어 코딩 가이드

위에서 말한 것과 같이 인터페이스 개발 시 보안 취약점을 방지해야만 합니다. 안전한 서비스를 만들기 위해서 개발자가 따라야하는 시큐어 코딩 가이드가 있습니다.

시큐어 코딩가이드는 7가지의 적용 범위가 존재합니다.

- 입력데이터 검증 및 표현

입력데이터 검증 및 표현은 프로그램의 입력 값에 대해서 검증이 누락되거나 부적절한 검증, 잘못된 형식 지정이 있을 경우 보안에 취약해집니다.

이를 대응하기 위해서는 검증된 사용자와 프로그램 입력 데이터에 대해 유효성 검증 체계를 수립해야합니다. 또한 잘못된 형식이 들어올 경우에 대한 처리 기능을 설계하고 구현해야 합니다.

- 보안 기능

보안기능이 부적절하게 구현되있는지도 확인해야합니다. 보안기능에는 인증과 접근제어, 기밀성, 암호화, 권한 관리 등이 들어갑니다.

보안기능에 대한 안전성을 높이기 위해서는 인증과 접근 통제가 이뤄 져야하며 권한 관리, 비밀번호 등의 정책이 적절하게 수립되고 반영되도록 프로그램을 설계하고 구현해야합니다.

- 시간 및 상태

시간 및 상태는 병렬 시스템의 경우 거의 동시에 수행 지원할 경우와 여러개의 프로세스가 동작하는 환경 등에서 시간이나 상태가 관리가 안될 경우에 생길 수 있는 문제가 있습니다.

이 문제를 해결하기 위해서 공유되고 있는 자원의 접근을 직렬화하거나 병렬 수행가능 프레임워크 사용합니다. 그 외에도 블록문을 이용하며 블록문 내부에서만 재귀함수 호출하도록 해야합니다.

- 에러 처리 

에러를 처리 안하거나 불충분한 처리할 경우 에러 메시지가 나오게 되는데 이 에러 메세지에 중요 정보가 포함되면 보안에 취약해집니다. 

이런 문제점을 해결하기 위해서 에러 상황을 최대한 없애고 불충분하게 처리되어 중요 정보 유출되는 약점이 발생하지 않도록 에러 메세지를 숨기는 프로그램을 구현해야합니다.

- 코드 오류

코드오류는 그저 개발자가 만들어 내는 코딩에 대한 오류를 말합니다.

이 경우 코딩 규칙을 도출 하고 검증 가능한 스크립트를 구성합니다. 또한 경고 순위를 최상향으로 조정한 뒤 경고 메시지 코드를 제거해서 막습니다.

- 캡슐화

캡슐화에서 생기는 문제점은 기능성이 불충분한 캡슐화에서 발생합니다. 이 경우 숨겨야하는 데이터도 사용자에게 노출 됩니다. 

이를 막기 위해서는 디버거 코드 제거해야하며 필수 정보 외에도 클래스 내의 프라이빗 접근자를 지정해야합니다.

- API 오용

API의 의도에 맞지 않는 방법으로 사용하거나 보안에 취약하도록 만들어진 API사용한 경우도 위협에 노출됩니다.

이를 막기 위해 개발 언어별로 취약 API 확보하고 취약 API 검출 프로그램 사용해야합니다.

데이터베이스 보안 적용

데이터베이스의 기밀성을 유지하기 위해서는 인터페이스에 활용되는 중요 데이터에 보안 요구사항을 적용해야합니다.

데이터베이스 암호화 알고리즘에는 대칭 키 암호화 알고리즘, 비대칭 키 암호화 알고리즘, 해시 암호화 알고리즘이 있습니다.

첫번째로 대칭 키 암호화 알고리즘은 암호화 알고리즘의 한 종류로 암 · 복호화에 사용되는 암호가 같은 알고리즘입니다.

ARIA 128/192/256과 SEED 등이 암 · 복호화에 같은 키를 사용하는 대칭 키 암호화 알고리즘입니다.

두번째로 비대칭 키 암호화 알고리즘입니다. 비대칭 키 암호화 알고리즘은 모두에게 공개되어 있는 공개키와 이와 대응되는 소유자만 알수 있는 비밀키를 사용하는 암 · 복호화키가 다른 알고리즘 입니다.

RSA, ECC, ECDSA 등이 비대칭 키 암호화 알고리즘의 대표적인 예 입니다.

마지막 암호화 알고리즘은 해시 암호화 알고리즘입니다. 해시값을 이용해 원래의 입력값을 찾아낼수 없도록 만든 일방향성의 특성을 가진 알고리즘입니다.

대표적인 예로는  SHA-256/384/512, HAS-160 등이 있습니다.

데이터베이스 암호화 기법으로는 API 방식, Plug-In 방식, Hybrid 방식이 있습니다.

- API 방식은 애플리케이션 레벨에서 암호 모듈 API를 적용하는 방식입니다. 암호화는 가능하지만 이 방법을 이용하게 되면 애플리케이션 서버에 암 · 복호화와 정책 관리, 키 관리 등에서 부하가 발생합니다.

- Plug-In 방식은 DB레벨의 확장성과 프로시저 기능을 이용해 DBMS에 Plug-In 모듈로 동작하는 방식입니다. 그러나 이 방식도 DB서버에 암 · 복호화와 정책 관리, 키 관리 등에서 부하가 발생합니다.

- Hybrid 방식은 API 방식과 Plug-In 방식을 결합시킨 방법입니다. 두 방식 모두 부하가 발생하므로 Hybrid방식을 통해서 DB서버와 애플리케이션 서버로 부하를 분산시켜 단독으로 사용했을 때보다 안정적입니다. 

인터페이스 구현 검증

인터페이스의 세부 기능을 기능 단위로 테스트하는 단위 테스트와 전체 인터페이스 흐름을 확인하는 시나리오를 통한 통합 테스트를 통해서 인터페이스 구현 검증을 할수 있습니다.

구현 검증을 확인하기 위해서 인터페이스 구현 검증 도구를 이용하면 테스트의 효율성을 높일 수있습니다. 인터페이스 구현 검증 도구는 구현되어 있는 인터페이스의 동작을 검증하는 도구입니다. 인터페이스 구현 및 감시 도구를 통해서 인터페이스 동작 상태를 검증하며 모니터링합니다.

인터페이스 구현 검증 도구에 대해 자세히 알아보겠습니다.

처음으로 소개할 구현 검증 도구는 xUnit입니다. xUnit은 자바(Junit), C++(Cppunit), .Net(Nunit) 등 다양한 언어를 지원하는 단위테스트 프레임워크입니다.
소프트웨어의 함수나 클래스 같이 서로 다른 구성 단위를 테스트 할 수 있게 해주는 도구입니다.

다음은 STAF입니다. STAF는 서비스 호출과 컴포넌트 재사용 등 다양한 환경을 지원하고 있는 테스트 프레임워크입니다.
각 테스트 대상 분산 환경에서 데몬을 사용하여 테스트 프로그램을 통해서 테스트 후 통합과 자동화를 진행하는 검증도구입니다.

FitNesse는 웹 기반 테스트 케이스의 설계,실행와 결과 확인 등을 지원하는 테스트 프레임워크입니다.
사용자가 테스트 케이스 테이블을 작성하면 별다른 동작없이도 빠르고 편하게 원하는 값을 테스트 할 수 있다는 장점이 있습니다.

다음은 Selenium입니다. Selenium은 다양한 브라우저 지원 및 개발언어를 지원하는 웹 애플리케이션 테스트 프레임워크입니다. 테스트 스크립트 언어를 학습안해도 되는 기능 테스트를 위한 도구를 제공합니다.

마지막으로 소개할 구현 검증 도구는 watir입니다. 루비(Ruby)기반의 웹 애플리케이션 테스트 프레임워크로  모든 언어 기반의 웹 애플리케이션 테스트와 브라우저 호환성 테스팅 가능하다는 특징을 가지고 있습니다.

인터페이스 설계서에는 시스템 사이에서 교환되고 있는 데이터와 업무 등이 정의되어 있습니다. 

즉, 인터페이스 목록과 인터페이스의 상세 데이터에 대한 명세내역, 기능의 세부 인터페이스 정보들에 대해서도 상세히 정의되어 있는  문서입니다.

우리는 이 인터페이스 설계서를 이용하여 시스템 사이의 데이터 교환 및 처리를 확인할 수 있으며 시스템 인터페이스의 현황 파악을 할 수 있습니다. 

외부 및 내부 모듈 연계

인터페이스를 이용하면 기업이나 공공 서비스 사이의 정보를 전달하고 교환할 수 있습니다. 이때 외부 및 내부 모듈을 연계하기 위해서 사용되는 기술이 있는데 수행의 목적과 적용되는 영역에 따라 EAI방식과 ESB방식으로 나눠집니다.   

 EAI(Enterprise Application Intergration)방식에 대해 이야기 하겠습니다. EAI방식은 기업 내부에서 서로 다른 플랫폼이나 애플리케이션의 사이에서 정보를 전달하고 연계, 통합을 가능하게 하는 솔루션입니다.

EAI 방식의 장점은 각 비즈니스간의 통합과 연계성이 높아져 더불어 효율성이 높아집니다. 그 결과 각 시스템간의 확장성도 높아집니다.

EAI의 구축유형을 자세하게 나눠보면 4가지 방식이 있습니다.  

포인트 투 포인트(Point-to-Point)구축 유형에 대해 이야기 해보겠습니다. 포인트 투 포인트는 말 그대로 가장 기초적인 1:1 애플리케이션 통합 방법입니다.

포인트 투 포인트의 장점은 단순한 구조 때문에 특별한 솔루션이 없어도 개발자 간의 커뮤니케이션을 거치면 통합이 가능합니다.

다음으로는 허브 앤 스포크(Hub & Spoke)입니다. 중앙에 있는 하나의 허브 시스템을 통해 데이터를 주고받는 중앙 집중 방식으로 구성되어 있습니다.

허브 앤 스포크는 중앙 집중 방식이기 때문에 만약 허브에 문제가 생긴다면 전체 모듈의 연계에 문제가 생긴다는 단점이 있습니다.

다음으로 이야기 할 유형은 메세지 버스(Message Bus)입니다. 메세지 버스는 애플리케이션 사이에 미들웨어 즉, 버스를 두어 모듈을 연계하는 미들웨어 통합 방식입니다.

미들웨어 통합 방식으로 뛰어난 확장성을 가지고 있으며 큰 용량의 데이터 처리도 가능한 연계 기술입니다. 

하이브리드(Hybrid)유형은 허브 앤 스포크와 메세지 버스을 결합한 방식입니다. 허브 앤 스포크 방식을 이용해 그룹 내부를 연계하고 그룹사이에는 메세지 버스 방식을 이용해 그룹끼리 연계합니다.
하이브리드 방식은 두 연계 방식의 장점처럼 큰 용량의 데이터 처리가 가능해지며 통합을 통해 각 그룹 내부의 환경에 맞춰 작업이 가능합니다.

다음의 사진은 EAI 연계 방식의 구축유형에 대한 모양입니다.

정보처리기사 시험에서 EAI와 관련된 문제가 빈번하게 나오니 개념을 꼭 익히고 가시는 걸 추천드립니다. 

이제 ESB(Enterprise Service Bus)방식에 대해 이야기 하겠니다. ESB방식은 기업에서 운영되는 다른 플랫폼이나 애플리케이션을 하나의 시스템으로 관리하고 운영할 수 있도록하는 서비스 중심의 통합 아키텍처입니다.

ESB는 가운데 버스를 두고 느슨한 결합을 통해 프로토콜이 호환되도록 애플리케이션의 통합하는 방식입니다.

EAI와 ESB는 이름이 비슷해 헷깔리지만 서로 확연히 다른 기능을 수행하고 있습니다. 

마지막으로 두 방식에 대해 확실하게 구분하기 위해 비교하여 이야기 하겠습니다.

수행목적이 EAI는 기업 내부의 모듈 간의 통합이지만 ESB는 기업 간의 서비스를 교환하도록 하는 표준 API입니다.

또한 EAI의 경우 포인트 투 포인트, 허브 앤 스포크, 메세지 버스, 하이브리드의 구축 유형이 있습니다. 

EAI의 핵심 기술은 어댑터와 브로커, 메시지 큐이며 ESB는 웹 서비스와 지능형 라우터, 포맷변환과 개방형 표준입니다.

ESB는 기업 외부에서 다른 기업과 통합하기 때문에 느슨한 서비스 사이의 통합입니다. 그렇지만 EAI의 경우 기업 내부망에서 동작하고 있기 때문에 단단한 통합을 지원하고 있습니다.