Cloud Native blog

마이크로서비스를 어떻게 평가할 것인가?(문헌 연구를 기반으로) (1편)

이네디잇 — Tue, 7 May 2024 01:29:00 +0900

마이크로서비스 개발이 증가함에 따라 품질 평가에 대한 관심이 높아졌다. 국내에서도 마이크로서비스 개발이 보편적이지만, 마이크로서비스로 개발 이후 이에 대한 평가는 아직 미흡한 것이 현실이다. 이 글에서는 마이크로서비스 품질을 평가하기 위해 어떤 연구들이 있었는지 검토한 " Research Opportunities in Microservices Quality Assessment: A Systematic Literature Review" 논문을 통해 알아본다.

이 논문의 저자는 ‘Tapia V.C’, ‘Gaona C.M.’이며 ‘Journal of Advances in Information Technology’에 2023년 게재되었다. https://www.scopus.com/inward/record.uri?eid=2-s2.0-85175422540&doi=10.12720%2fjait.14.5.991-1002&partnerID=40&md5=ff58f786e939166769b9ae93be39129a

에서 확인할 수 있다.

이 논문에서는 2017년 이후 발표된 논문중에서 의미있는 논문을 조사하여 정리했다.

체계적인 문헌 검토(LRS)를 통해 5가지 연구 질문을 정의하고 이 대한 답을 제시하였다.

RQ1: 마이크로서비스에 적용할 수 있는 품질 속성은 무엇인가?
RQ2: 마이크로서비스에 적용할 수 있는 품질 지표에는 어떤 것이 있나?
RQ3: 마이크로서비스 품질 평가에서 어떤 문제가 확인되었나?
RQ4: 가장 많이 사용되는 마이크로서비스 평가 도구는 무엇인가?
RQ5: 그 도구에서는 어떤 메트릭을 사용하나?

본격적으로 들어가기 전에 개념에 대해 정리한다.

마이크로서비스 기반 애플리케이션

마이크로서비스 기반 애플리케이션은 소프트웨어 개발에 대한 아키텍처와 조직적 접근 방식으로, 애플리케이션이 RESTful 또는 RPC 기반 API와 경량 프로토콜을 통해 통신하는 소규모 독립 서비스로 구성된다.

마이크로서비스는 기능을 제공하기 위해 함께 작동하는 독립된 서비스들의 모음이다. 현재 마이크로서비스를 구축하는 데는 여러 가지 옵션이 있으며, 그 중 일부는 패턴을 기반으로 한다. 마이크로서비스 아키텍처는 독립적으로 작동하고 이상적으로는 낮은 결합 (마이크로서비스 간의 독립성, 즉 서로의 기능을 변경하지 않고 자율적으로 작동할 수 있는)을 가지며 가벼운 서비스를 제공하는 상호 관련된 애플리케이션을 만들기 위한 소프트웨어 개발 기법이다. 이런 애플리케이션 구성 방법은 각 서비스가 서로 다른 물리적 인프라에 속하는 서로 다른 실행 환경에서 구현되기 때문에 클라우드의 분산 아키텍처에 이상적으로 적합하다. 마이크로서비스 개념의 근거는 복잡성을 줄이기 위해 작은 작업을 수행하는 것입니다. 이 아키텍처에서는 여러 서비스가 서로 상호 작용한다. 마이크로서비스의 주요 특징으로는 유지보수성, 진화 가능성, 독립적인 배포, 단일 서비스로서의 저렴한 비용, 개선 및 시장 출시 시간 단축 등이 있다.

소프트웨어 품질

소프트웨어 품질은 제품 기능의 성능과 사용자의 명시적, 그리고 암묵적 요구를 충족하는 능력을 결정한다. 효과적인 개발 프로세스를 통해 유용한 제품을 얻을 수 있으며, 제품을 생산하고 관리하는 사람들에게 측정 가능한 가치를 제공한다.

품질 측정에는 SQuaRE(시스템 및 소프트웨어 품질 요구사항 및 평가)로 알려진 ISO/IEC 25000 표준 제품군이 사용된다. SQuaRE는 소프트웨어 제품의 품질을 평가하기 위한 공통 프레임워크를 만드는 것을 목표로 하는 일련의 규칙으로, 이전 표준, 특히 ISO/IEC 9126 및 ISO/IEC 14598의 발전에서 비롯된 것이다.

품질은 지속성을 평가하는 메트릭을 사용하여 품질 속성(성능, 테스트 가능성, 보안 및 가용성)으로 정의된다.

품질 속성

이는 시스템의 런타임 동작, 디자인 및 사용자 경험에 영향을 미치는 일반적인 요소이다. 이런 속성은 시스템이 구축된 환경에서 시스템의 목적을 설명한다. 기술적 관점에서 품질 속성은 중요한 아키텍처 및 디자인 결정을 내리는 데 영향을 미친다. 품질 속성은 두 가지 유형으로 분류되는데, 첫 번째 유형에서는 품질 속성이 몇 가지 특정 요구 사항에 매핑되고, 두 번째 유형에서는 품질 속성이 특정 기능 요구 사항에는 매핑되지 않지만 모든 기능 요구 사항에 영향을 준다.

ISO 25000은 기능성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성 등의 품질 속성을 의미한다.

품질 속성은 기능을 결정하지 않는 시스템의 속성을 나타낸다. 그렇지 않으면 시스템이 지원해야 하는 품질과 특성을 정의한다. 일반적으로 측정을 용이하게 하기 위해 하위 속성으로 나뉜다. 예를 들어, 접근성은 이해관계자의 요구 만족도와 시스템의 성공 정도를 파악하는 사용성의 하위 속성이다.

소프트웨어 엔지니어링에서 측정(measurement)은 품질 특성을 평가하고 목표를 설정하는 데 매우 중요하다. 측정은 특정 척도로 특성을 정량화하는 논리적 순서로 정의되며, 측정 함수 또는 알고리즘은 품질 측정 요소를 결합할 수 있다. 그러나 아키텍처 측정 프로세스에서는 몇 가지 중요한 설계 방법이 생략되어 왔다.

소프트웨어 품질 측정의 주요 목적은 경영진의 개발 및 유지 관리 모니터링 및 제어를 지원하고, 요구사항 준수 여부를 관찰하며, 개선을 위한 데이터 소스로 활용하는 것이다. 일부 품질 속성은 크기, 복잡성, 결합 및 응집력과 같은 아키텍처 특성을 사용하여 측정할 수 있다. 이러한 측정은 IEC 25023과 같은 표준에 의해 정의된다.

마이크로서비스의 품질 속성

아키텍처 패턴을 연구한 Valdivia 등에 따르면, 문헌에서 확인된 마이크로서비스의 품질 속성은 유지보수성, 신뢰성, 보안, 성능, 호환성 및 이식성이다. 이는 측정 가능한 비기능적 요구 사항으로, 사용자 만족 수준을 결정하는 데 목적이 있다. 마찬가지로 Richardson은 마이크로서비스는 유지보수가 가능하고, 테스트가 가능하며, 결합이 가능하고, 독립적으로 구현할 수 있어야 하며, 소규모 팀에서 개발할 수 있어야 한다고 말했다. 마지막으로 Osses 등은 체계적인 문헌 검토를 바탕으로 44개의 아키텍처 패턴과 5가지 품질 속성(확장성, 유연성, 테스트 가능성, 성능, 탄력성)을 도출한 탐색적 연구를 설명했는데, 이는 마이크로서비스의 아키텍처 패턴 및 전술(tactics) 대부분과 관련되어 있다.

품질 메트릭

메트릭은 품질 속성의 존재 정도를 평가하는 것으로, 소프트웨어 실행에 의존하지 않는 경우 내부(정적) 또는 실행 중인 소프트웨어에 적용되는 경우 외부(동적)일 수 있으며, 측정값으로 수치를 제공하여 속성을 정량화할 수 있다.

Selmadji 와 Seriai 등은 표 I에 제시된 정적 및 동적 분석에 따라 분류된 일련의 품질 평가 기준을 결정했다.

정적 분석	동적 분석
세분성	실행 비용
LOC	응답 시간
개방형 인터페이스	가용성
높은 응집력	Succ. Exec. Rate
느슨한 커플링	사용 빈도 확장성 독립성 유지 관리 가능성 배포 Health 관리 모듈화 관리 용이성 성능 재사용 가능성 기술. 이질성 민첩성 보안 로드 밸런싱 Org. 정렬

표 I. 분석 유형별 품질 평가 지표 [5]

다음 편에서는 위의 5가지 질문에 대한 답을 어떻게 했는지 정리해 본다.

클라우드 전문가 조직은 어떻게 구성해야 하나?

이네디잇 — Fri, 29 Mar 2024 11:38:01 +0900

기존 시스템을 클라우드로 전환한다는 것은 여정이라고 얘기할 만큼, 긴 호흡을 가지고 진행해야 한다. 새로운 기술을 도입한다는 개념을 넘어, 새로운 패러다임을 도입한다는 개념으로 이 여정을 맞이해야 한다. 특히 새로운 조직과 새로운 비즈니스를 하는 기업보다는 고도화된 IT시스템을 가지고 있는 기업에서 이는 더욱 중요하다. 왜냐하면 변화가 더 어렵기 때문이다. 이 어려운 변화를 잘 대응해 성공적으로 전환할 수 있는 좋은 방법은 클라우드 전문가 조직을 구성하는 것이다. 당연하게도 Microsoft, AWS, Google과 같은 대표적인 클라우드 서비스 프로바이더는 클라우드 전문가 조직의 중요성을 강조하고 있다. 방법론 측면에서는 조금은 다르지만, 궁극적인 목적은 같다.

클라우드 전문가 조직은 Cloud Center of Excellence(CCoE)라고 부르며, "클라우드 전문가 조직", "클라우드 혁신 센터"라고 말하기도 한다.

이 글에서는 각 클라우드 서비스 프로바이더가 CCoE에 대해 어떤 생각을 가지고 있는지 정리하고, 필자의 생각을 덧붙이고자 한다.

먼저, 마이크로소프트에서는 어떻게 클라우드 전문가 조직(CCoE)을 어떻게 얘기하고 있는지 확인해 본다. (https://learn.microsoft.com/ko-kr/azure/cloud-adoption-framework/organize/cloud-center-of-excellence)

CCoE에는 누가 참여해야 하나? (CCoE에 필요한 리소스)

클라우드 채택(솔루션 설계자) : 클라우드에서 기술 솔루션을 구현한다. 마이그레이션, 모더나이제이션 등 특성에 따라 유동적으로 구성한다.
클라우드 전략(프로그램 및 프로젝트 관리자) : 클라우드 채택을 위한 동기와 비즈니스 결과를 정의한다. 이후 비즈니스 우선순위와 클라우드 채택 노력 간의 조정을 검증하고 유지관리한다.
클라우드 거버넌스 : 위험(risk)와 위험 허용범위를 적절하게 평가하고 관리한다. 위험을 관리 정책으로 변환한다.
클라우드 플랫폼 : 클라우드 플랫폼이나 랜딩 존을 생성하고 지원한다.
클라우드 자동화 : 클라우드 자동화는 주로 DevOps와 각 영역에 대한 자동화를 구현하고 관리한다.

위와 같은 역할을 가진 사람은 모두 참여해야 한다.

CCoE를 도입하면 어떤 점에서 좋은가?

CCoE를 도입하면 비용절감과 비즈니스 민첩성에 대한 효과를 볼 수 있다. 또한 안정성, 성능 효율성, 보안, 유지관리, 고객 만족도 등의 품질지표도 개선된다. CCoE 모델을 도입하게 되면 IT 패러다임을 변화시킬 수 있다. 기존에는 IT가 제어와 중앙 책임에 집중하지만, CCoE 모델을 통해서는 자유와 위임된 책임에 초점을 맞춘다.

기존 IT 모델과 CCoE 모델의 차이

하지만, CCoE를 통해 현실적으로 이렇게 바꾸기는 어렵기 때문에 점차적으로 셀프서비스 모델로 전환하도록 유도하는 것이 좋을 것이다.

그럼 CCoE는 어떤 일을 하게 되나?

민첩한 접근 방식을 사용하여 비즈니스 요구 사항을 캡처하고 구현
보안, 규정 준수 및 관리 정책에 맞는 재사용 가능한 배포 패키지를 사용
운영 절차에 따라 Azure 플랫폼을 유지 관리
클라우드 네이티브 도구 사용을 검토하고 승인
시간이 지남에 따라 일반적으로 필요한 플랫폼 구성 요소 및 솔루션을 표준화하고 자동화

위의 내용을 보면 CCoE에서 클라우드와 관련된 모든 것을 하는 것처럼 되어 있지만, 유기적인 협업으로 공통 리포지토리나 솔루션 카탈로그를 통해서 협업의 효과는 최대로, 모임은 최소화한다.

CCoE의 성공을 위한 필수 조건은?

IT리더십은 가장 중요한 관련자이며, 이 모델을 구현하려면 CIO와 기타 경영진 수준의 IT리더의 지원이 필요하다. 비즈니스 관련자는 필수는 아니지만, CCoE를 만들기 위한 주요 동기이며 지원이 필요하다. 특히 CCoE의 활동의 대부분이 비즈니스 민첩성과 속도를 개선하는 데 중점을 두고 있기 때문에 현재 운영모델의 효과와 개선의 가치를 정의하는 것은 매우 중요하다.

위의 Link된 페이지에 많은 내용이 있지만, 주요 내용을 중심으로 간략하게 살펴보았다.

그럼, AWS에서는 CCoE에 대해 어떻게 얘기하고 있을까?

AWS의 블로그에는 엔터프라이즈 클라우드 혁신 센터(CCoE)를 만드는 방법에 대해 기술하고 있다. (https://aws.amazon.com/ko/blogs/korea/how-to-create-a-cloud-center-of-excellence-in-your-enterprise/)

Stephen Orban은 Stephen Orban의 엔터프라이즈 클라우드의 여정에서 CCoE와 관련된 본인의 경험을 적어놓았다. 전부 다 읽어 볼 만한 실무적인 내용들이며, 특히 본인의 경험을 기반으로 기술했기 때문에 더욱 마음에 다가오는 내용이 많다.

팀 구축

다양한 직업적 배경을 가진 3명에서 5명 정도의 팀을 꾸리는 것을 권고하며, 대상자는 개발자, 시스템 관리자, 네트워크 엔지니어, IT 운영 및 데이터베이스 관리자이다. 특히, 생각이 열려 있고 현대 기술과 클라우드 서비스를 활용하여 일하는 방식을 바꾸고 조직을 미래로 이끌 방법을 고민하는 사람들이어야 한다. 경험이 없는 직원이라도 태도가 능력만큼 중요할 수 있으며, 필요한 인재는 이미 조직에 있을 수 있다.

팀의 책임 범위 설정(및 확장)

CCoE는 조직의 나머지 부분이 클라우드에 시스템을 구현할 때 (또는 시스템을 이전할 때) 활용하는 모범 사례, 거버넌스, 프레임워크 구축을 책임져야 한다. 역할과 권한, 비용 거버넌스, 모니터링, 사고 관리, 하이브리드 아키텍처, 보안 모델 등 기본부터 시작해, 복수계정 관리, “골든” 이미지 관리, 자산 관리, 사업 단위 요금상환, 재사용 가능한 참조 아키텍처 등을 망라하는 수준까지 발전하도록 한다. 분석 불능(https://medium.com/aws-enterprise-collection/be-wary-of-analysis-paralysis-when-using-the-cloud-a24a5f8f2651) 상태에 빠지지 않도록 한다, 실무 경험이 쌓이면서 역량은 자연스럽게 발전시킬 수 있다.

팀을 다른 모범 사례에 연계

모든 모범 사례는 상호 의존적이다. CCoE가 성공하기 위해서는 경영진의 파격적 지원을 확보하고, CCoE 방법에 대해 조직을 교육하며, 경쟁력을 유지하기 위해 실험을 받아들이고, 환경에 가장 좋은 도구와 파트너를 늘 파악하며, 조직의 하이브리드 아키텍처를 소유하고, 클라우드 우선 전략에서 핵심 플레이어가 되어야 한다.

이 블로그는 Stephen Orban의 엔터프라이즈 기업의 클라우드 도입 모범 사례(https://aws.amazon.com/ko/blogs/korea/stepen-orban-an-e-book-of-cloud-best-practices-for-your-enterpr ise/)라는 시리즈 글의 일부이다. 전부 읽어보면 많은 도움이 될 수 있으니 읽기를 추천한다. (글이 길지 않다.)

GCP의 경우도 CCoE를 구축하는 방법에 대해 백서를 제공하고 있다. (https://services.google.com/fh/files/misc/cloud_center_of_excellence.pdf)

이 외에도 가트너에서도 CCoE에 대해 논하고 있다. 아래에 상세히 살펴본다.(https://www.gartner.com/en/conferences/hub/cloud-conferences/insights/how-to-build-a-cloud-center-of-excellence)

성공적으로 클라우드를 도입하기 위해서는 그에 맞는 기술과 구조가 있어야 하며, 최적의 방법은 중앙 집중식 CCoE를 세팅하는 것이다. CCoE는 조직의 중앙 집중식 거버넌스 기능을 하고, 비즈니스의 중앙 IT, 업무 단위 IT와 클라우드 서비스를 사용하는 이해관계자에게 자문 역할을 해야 한다. CCoE는 클라우드 IT 전환을 이끄는 핵심이다.

CCoE는 엔터프라이즈 아키텍처 역할을 한다. 클라우드 정책 설정, 프로바이더 선택, 솔루션 아키텍처 및 워크로드 배치 지원과 같은 역할을 하며, 일상적인 운영이나 프로젝트 관리는 하지 않는다. 또한 아웃소싱해서는 안된다. CCoE는 조직의 클라우드 프랙티스를 감독하고 비즈니스 전반에 기여를 적극적으로 요청해야 한다.

CCoE는 중앙 IT에 CIO의 클라우드 전략을 표현하고 정책과 클라우드 관리 도구를 통해 거버넌스를 제공하고 클라우드 모범 사례를 수집 전파하는 방법을 제공한다. 이는 모든 클라우드 서비스 모델에서 클라우드 채택을 주도하고 관리하기 위한 기본 수단이 되어야 한다.

CCoE에는 세 가지 핵심 역할(pillar)이 있다.

거버넌스: 크로스 펑셔널 팀과 협력하여 정책을 만들고 재무 및 위험 관리를 제공하는 거버넌스 도구를 선택한다.
중개(Brokerage) : 사용자가 클라우드 공급자를 선택하도록 지원하고, 클라우드 솔루션을 설계하고, 계약 협상 및 공급업체 관리를 위해 소싱 팀과 협력한다.
커뮤니티 (Community) : 조직의 클라우드 지식수준을 높이고 지식 기반, 소스 코드 리포지토리, 교육 이벤트, 조직 전체의 홍보 등을 통해 모범 사례를 캡처 및 전파한다.

여기에, 두 개의 추가 엔터티를 만들면 CCOE와 협력하여 성공적인 클라우드 채택을 촉진할 수 있다. 크로스 펑셔널 클라우드 컴퓨팅 자문 위원회(cross-functional cloud computing advisory council)는 클라우드 관련 정책을 형성 및 시행하고 조직 변화를 추진하는 데 도움을 줄 수 있다. 그리고 클라우드 컴퓨팅 채택에 관심을 갖고 참여하는 직원을 모으는 클라우드 실천 커뮤니티(cloud communities of practice)는 지식을 공유하고 비공식적으로 협업할 수 있다.

조금 더 자세한 내용은 다음의 페이지를 참고한다. https://www.gartner.com/smarterwithgartner/execute-your-cloud-strategy-with-a-cloud-center-of-excellence

지금까지 중요 CSP인 Azure, AWS, GCP에서의 CCoE와 가트너의 CCoE에 대한 내용을 살펴보았다.

그럼 이제 어떻게 시작해야 할까?

반드시 명심해야 할 사항을 알아보자.

클라우드를 성공적으로 도입하기 위해서는 CCoE가 필요하다.
CCoE에는 반드시 CIO와 경영진 수준의 IT리더의 지원이 필요하다.
내부 조직에서 생각이 열려 있고, 현대기술과 클라우드로 조직을 바꿀 고민하는 사람들을 골라 3~5명으로 꾸려서 시작한다.
CCoE는 비즈니스 요구사항을 캡처하고, 거버넌스를 수립하고, 기술을 선택 및 설계하고(일부는 검증을 위한 구현까지), 플랫폼 구축을 책임지고, 이와 관련된 것들을 표준화하고 자동화한다.
효과적인 방법을 찾아 클라우드 지식을 포함한 모범 사례를 수집 전파한다.

다음 글에서는 CCoE를 조직해서 적용했던 사례에 대해서 설명하겠다.

Google Cloud를 대기업에서 사용할 때 필요한 것 - 계정

골리어스 — Tue, 7 Mar 2023 22:14:46 +0900

여러분이 만약 네이버 카페를 통해 글을 작성하고 싶다고 가정해 봅시다. 그때 제일 먼저 필요한 것은 바로 네이버 아이디이고, 아이디 생성을 위해 회원 가입을 할 것입니다. 접근하는 사용자는 보통 아이디와 패스워드 입력을 통해 '나'라는 것을 인증(Authentication)하는 과정을 거치게 됩니다. 계정을 생성하고나서 바로 카페에 글을 작성할 수 있으면 좋겠지만, 처음부터 글을 작성할 수 있는 권한이 없기 때문에 바로 글을 쓸 수는 없습니다.

이처럼 Google Cloud를 사용하기 위해서는 계정 로그인을 통해 '지금 접근을 요청하는 사람은 누구누구이다.'라는 인증을 거쳐야 하고, 이후엔 접근할 수 있는 적절한 권한을 부여받아야 합니다. 이번 포스팅에서는 여러분이 기업 조직의 관리자라는 가정 하에, Google Cloud를 처음 사용할 때 필요한 '계정'을 만들어 조직의 사용자를 프로비저닝해보겠습니다.

먼저, Google Cloud에서 로그인할 수 있는 계정(Account)에는 크게 2가지 유형이 있습니다.

첫번째로, 일반 계정(Consumer Account)입니다.

일반 계정은 흔히 우리가 YouTube, Gmail 등의 Google 서비스를 쓸 때 사용하는 계정입니다. 비즈니스용 계정이라면 user@company.com으로 생성이 가능하고, 흔히 개인적인 용도로 사용하는 개인용 계정이라면 user@gmail.com으로 생성할 수 있습니다. 일반 계정을 이용해 Google Cloud를 사용할 수는 있지만, 조직의 계층 구조를 만들수 없고 사용자가 많다면 관리에 어려움이 있어 가급적이면 일반 계정은 추천하지 않습니다. (수명주기 제어 불가)

두번째는, 관리되는 사용자 계정(Managed User Account)입니다.

관리되는 사용자 계정은 일반 계정과는 다르게 관리자가 계정을 완전히 제어할 수 있는 계정을 말하며, ‘Google Workspace’와 ‘Cloud Identity’가 있습니다.

Google Workspace(구 G-Suite)는 Google에서 제공하는 업무용 소프트웨어 도구로, Gmail, Google 드라이브, Google 캘린더, Google Docs와 같은 문서 도구 등을 제공합니다. 기업에서 선택한 요금제에 따라(사용자당 월 $6 부터) 비용을 지불해야 합니다.

Cloud Identity(줄여서, Cloud ID)는 조직에서 사용자와 그룹을 중앙에서 관리할 수 있도록 제공하는 Identity 서비스입니다. Cloud ID를 사용하면, 사용자가 SSO(Single Sign On)로 쉽게 앱에 접근할 수 있으며, 다단계 인증을 제공받을 수 있습니다. 조직에서는 기업의 데이터를 안전하게 보호하는 정책을 ‘일관되게’ 적용할 수 있고, 리소스 및 사용자에 대한 ‘접근을 제어’할 수 있습니다. 또한 기존에 Microsoft Active Directory를 사용하고 있다면, 디렉터리 동기화가 가능하기 때문에 이를 통한 사용자 인증이 가능해집니다.

(참고로, Cloud ID는 Google Workspace를 구동하는 것과 동일하게 동작하는 ID 서비스 입니다.)

조직에서 Google Cloud를 사용하는 경우, 일반 계정보다는 관리되는 사용자 계정을 이용해 관리하는 것을 추천합니다. 만약, 일반 계정 사용자가 조직을 나가거나 팀이 변경되어 접근 권한을 바꾸어야 한다고 가정했을 때, 한두명이라면 관리가 가능하지만 일반 계정 사용자가 수십 명이 넘어간다면 아이디 한개씩 일일이 권한을 제어하기가 어렵기 때문입니다. 또한 Cloud ID가 아닌 일반 계정을 사용하면 Google Cloud의 리소스 계층 구조를 만들 수 없습니다. (리소스 계층 구조에 대한 내용은 다음 포스팅에서 설명합니다.) 하지만, Cloud ID를 이용하면 계정 수명 주기를 제어할 수 있으며 MFA 인증과 같은 보안 정책을 적용할 수 있어, 중앙에서 계정을 제어하고 정책을 관리하는데 있어 부담을 줄일 수가 있습니다.

다만, Cloud ID는 Free 버전과 Premium 버전 2가지(Premium 버전에서 추가 기능을 제공)를 제공하고 있어, 조직의 상황에 맞는 버전을 사용하기를 권고합니다.

여기서 질문!

Q. Cloud ID Free 버전과 Premium 버전의 차이는?
Free 버전은 무료로 사용이 가능하나 50명의 사용자까지 등록이 가능합니다. Premium 버전은 1 사용자당 추가로 지불해야하며 Free 버전에서 제공하는 기능 이외에 부가 기능들을 제공합니다.
세부적인 기능적인 차이에 대한 내용은 https://support.google.com/cloudidentity/answer/7431902?hl=ko 를 참고합니다.

Q. Cloud ID와 Google Workspace와의 차이는?
Cloud ID는 Google Workspace 없이 Google Cloud 리소스를 관리하기 위한 서비스이기 때문에, Gmail을 제외한 Google 드라이브, Google Meet 등의 Google Workspace 기능들을 이용할 수 없습니다.
기존에 Google Workspace를 사용하고 있다면 해당 도메인으로 Google Cloud 사용이 가능합니다. 다만, 기존에 사용하던 Google Workspace 정책과 Google Cloud의 정책을 분리해야한다면 새로 Cloud ID를 만들어야 합니다.

그렇다면 여러분이 Google Cloud를 처음 도입하려는 회사의 IT 관리자라고 가정하고, Cloud ID를 생성해 사용자를 프로비저닝하는 실습을 해보겠습니다. Cloud ID 만들기에 앞서 먼저 조직의 도메인이 필요합니다.

필자의 경우, 기존에 구매한 cloudnativeapp.best 라는 도메인이 있기 때문에 해당 도메인으로 Cloud ID를 만들어보겠습니다. Cloud ID 생성을 테스트하고 싶다면, 도메인을 무료로 발급해주는 사이트에서 도메인을 얻습니다. (참고 : https://www.freenom.com/en/index.html?lang=en)

도메인을 얻은 다음 아래 URL에 접속해 본격적으로 Cloud ID를 생성합니다.

https://workspace.google.com/signup/gcpidentity/welcome#0

Cloud ID 를 가입하는 새로운 창에서 회사 이름과 직원수를 선택합니다.

지금 생성하는 사용자는 Cloud ID를 관리하는 ID 관리자 역할을 수행하는 ‘최고 관리자’ 가 됩니다. 이를 고려하여 값을 입력합니다.

앞서 구매한 도메인 이름을 입력합니다. (다음 단계에서 도메인 인증을 거쳐야 하기 때문에 DNS 레코드 설정이 가능한, 실제 구매한 도메인 명을 입력해야 합니다.)

다음은 비즈니스 이메일 주소로 사용할 사용자 이름과 비밀번호를 설정하는 단계입니다.

클라우드 ID 계정이 생성되었다는 화면이 나타납니다.

설정으로 이동하여 아래와 같이 계정을 설정하는 단계를 시작합니다.

자동으로 Google Admin 콘솔로 이동하게 됩니다. 1단계 ‘보호’를 수행합니다.

위에서 기입한 도메인 이름이 실제로 내 도메인인지 인증이 필요하다는 안내창을 확인할 수 있습니다.

도메인 인증을 위해서는 구매한 도메인 등록기관에서 DNS 레코드 설정 변경이 필요합니다. 필자의 경우 도메인을 whois에서 구매했기 때문에, 해당 사이트에서 DNS 레코드 설정을 해보겠습니다.

인증 레코드를 추가한 후 Google Admin 콘솔로 돌아와 다음 단계로 넘어갑니다. 도메인 인증에는 최대 5분이 소요되며, 인증이 완료되면 아래와 같은 화면이 나타납니다.

계속해서 아래 ‘만들기’ 를 클릭해, 이제 cloudnative.best 조직에 신규 사용자를 생성하겠습니다.

앞으로 사용자를 새로 만들고 삭제하는 등 Cloud ID 프로비저닝과 관련한 설정은 해당 Google Admin 콘솔에서 진행합니다.

이제 홍길동 이라는 가상의 사용자를 팀에 추가해 보겠습니다. 사용자 이름과 사용자가 앞으로 Google Cloud 콘솔에 로그인 할 때 사용할 이메일 주소를 기입합니다. 신규 사용자에게 최초 로그인하기 위한 안내를 하려면 ‘보조 이메일’ 주소를 추가로 입력합니다.

새 사용자 추가 후 아래처럼 임의의 비밀번호가 자동으로 생성됩니다. 정상적으로 계정이 생성되었는지 테스트하기 위해 시크릿 창을 열어 로그인해보겠습니다.

정상적으로 hong 사용자 로그인이 되며, 보안을 위해 비밀번호를 변경하라는 문구가 나타납니다.

홍길동 계정으로 로그인하고나면, Google Admin 콘솔 창에서 마지막 로그인 시간이 업데이트된 것을 확인할 수 있습니다.

여기서 질문!

Q. Google Cloud 콘솔(https://console.cloud.google.com)과 Google Admin 콘솔(https://admin.google.com)은 다른 것인가요?

네, 두개는 각각 다른 콘솔입니다.

Google Admin 콘솔은 Google Workspace 서비스를 (Cloud ID 포함) 관리할 수 있는 중앙 공간이라고 할 수 있습니다. 사용자 계정을 관리하거나, 그룹을 만들거나, 관리자에 대한 설정을 할 수 있습니다.
Google Cloud 콘솔은 애플리케이션, 서비스를 개발, 배포하는 등 클라우드 애플리케이션 리소스에 대한 모든 것을 이곳에서 관리할 수 있습니다.

사용자 계정에 대한 설정은 Google Admin 콘솔에서 진행하면 되며, 사용자 계정이 실제 Google Cloud 리소스에 접근할 수 있도록 권한을 주기 위해서는 Google Cloud 콘솔에서 수행하게 됩니다.

여기까지 Google Cloud를 Enterprise 환경에서 처음 시작하는 데 필요한 ‘계정’ 설정을 마쳤습니다. 요약하면, Cloud ID를 사용하면 많은 사용자들을 일괄로 빠르게 업데이트하는 등 중앙에서 관리가 가능하다는 장점이 있다는 것인데요. 오늘 주제는 ‘계정’이다보니, Google Cloud 콘솔 보다는 Google Admin 콘솔에 익숙해졌을 것이라 생각합니다.

Google Cloud는 클라우드 리소스를 잘 관리하기 위해 ‘조직- 폴더- 프로젝트’ 와 같은 계층 구조를 가지고 있습니다. 다음 포스팅에서는 본격적으로 Google Cloud 콘솔을 훑어 보고, 기업에서 실제 클라우드 리소스를 어떻게 관리하는 지 ‘계층 구조’에 대해 알아보도록 하겠습니다.

DNS Forwarder VM 생성, 이제 그만! 완벽 대체 가능 PaaS 드드등장!

알 수 없는 사용자 — Fri, 3 Mar 2023 00:11:03 +0900

안녕하세요. 필스너 입니다.!

저는 Azure 신규 서비스들 위주로 조사해보고, POC 해보는 글을 2023년동안 작성해 보려고합니다~!

이 글이 새롭게 Azure에 서비스를 올리는 분들에게 도움이 되었으면 해요

오늘은 Azure에서 제공하는 서비스 중 하나인, DNS private resolver란 무엇인지, 그리고 또 어떻게 사용하는지에 대해서 설명해보려고 합니다.

* 본 내용은 Azure의 기본적인 리소스 구성을 알고 있음을 가정하여 작성하였습니다.

1. What is DNS?

신규 서비스인 DNS private Resolver를 설명하기에 앞서 DNS란 무엇일까요?

도메인 네임 시스템(Domain Name System, DNS)은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다고 하네요.

결국 서비스를 위한 호스트의 네트워크 주소를 우리가 흔히 URL에서 볼 수 있는, 도메인 주소로 바꾸어 주는 역할을 합니다. 예시로 네이버 홈페이지의 URL 주소를 통해 IP를 확인해 볼 수 있어요.

nslookup을 진행하여 확인한 www.naver.com의 서비스 IP

이러한 DNS는 외부적으로도 사용하지만, 내부적으로 사용하는 DNS들도 있어요.

아무래도 IP로만 통신을 하다보면, 해당 IP로는 직접적인 서버의 용도라던지, 서비스 이름을 예측하기 힘든 경우가 많아요.. 그래서 private DNS를 구성하는 경우가 많죠! 기업마다 DNS Server는 대부분 구성이 되어 있습니다.

기업의 규모가 큰 회사는 CLOUD를 사용하게 되면, 대부분 Hybrid Cloud(Onpremise와 Cloud 서비스를 모두 사용하며 연동하여 사용하는 클라우드 개념)를 구성하게 되는 경우가 많아요.

Hybrid Cloud를 구성하기 위해 VPN Gateway로 network 연동을 한 예시

Cloud서비스와 Onpremise 서비스간 연동은 데이터를 주고 받을 수 있는 네트워크의 연동이 핵심이죠. Express Route나 VPN과 같은 서비스를 생성하여 연동하게 됩니다. 이 때 Azure에서 특정 Paas 서비스를 사용하게 되고 외부의 노출을 막고 내부 통신만 가능하도록 Private Link를 PaaS서비스에 연동하여 서비스만의 고유의 Private IP와 Pirvate DNS를 할당받게됩니다.

물론 "IP"로의 통신이 가능해요. 하지만, 대부분의 기업에서는 DNS를 활용하여 쿼리문을 작성하는 것이 익숙하겠죠?

여기서 Azure와 On Premise간 이름 풀이를 위한 DNS Forwarder가 있습니다.

DNS 질의 워크플로우

해당 그림은 On Premise에서 Azure에 있는 SQL Database에 DNS 질의를 날렸을 때, 발생하는 워크플로우입니다.

On Premise의 Client VM에서 DNS 질의를 할 때 바라보는 대상은 Interal DNS 서버에요.

해당 Internal DNS는 조건부 전달에 등록되어 있는 database.windows.net을 Azure VM에 구성한 DNS Forwarder로 전달하죠. 해당 전달을 받은 Azure VM은 Azure DNS Nameserver로 이름 풀이를 하게 되고, 그 값을 받아 다시 Internal DNS 서버로 전달, Client VM이 SQL DB와 통신할 수 있게 되죠. 자세한 설명은 다음 링크를 참고하시면 됩니다.

https://learn.microsoft.com/en-us/azure/architecture/example-scenario/networking/azure-dns-private-resolver

해당 설정을 위해서는 Virtual Machine을 생성하고, DNS Forwarder 구성을 직접 해주어야 했어요. 바로 IaaS의 영역인 거죠. 특정 기능을 구현하기 위해서는 서버 담당자, DNS 담당자의 역할이 필요했어요.

결국 Azure에서는 DNS Forwarder를 대체 시킬 수 있는 PaaS 서비스를 제공하기 시작했습니다.

본론으로 들어가 볼까요?

2. What is DNS private Resolver Service?

DNS private resolver란, VM 기반 DNS 서버(앞서 설명한 DNS Forwarder)를 배포하지 않고 온-프레미스 환경에서 Azure DNS 프라이빗 영역을 쿼리하거나 그 반대로 쿼리할 수 있는 새로운 서비스입니다.

Hybrid Cloud를 위해 거의 필수적으로 필요한 서비스로, 직접 구성을 하다보니, Azure에서는 그 니즈를 캐치해서 PaaS서비스로 만들어 제공하고 있다고 보이네요.

GA는 2022년 10월 경 되었구요!

https://azure.microsoft.com/en-us/blog/announcing-azure-dns-private-resolver-general-availability/

Announcing Azure DNS Private Resolver general availability

We are excited to share that Azure DNS Private Resolver is now in general availability. We offer two types of Azure DNS Zones—private and public—for hosting your private DNS and public DNS records.

azure.microsoft.com

다음 아키텍처를 통해 새로운 PaaS인 DNS Private Resolver의 역할을 볼까요?

DNS Private Resolver를 구성시 생성되는 Inbound Endpoint VIP가 DNS Forwarder VM에서의 VM의 IP의 역할을 해요. On-Premise에서는 특정 DNS들을 검색시, 해당 VIP로 DNS forward를 진행하게 되고 해당 VM에서는 Azure의 DNS Zone으로 Lookup하여 얻은 값을 전달해주게 되죠.

3. DNS private resolver POC

해당 서비스를 테스트 해보기 위해 azure용 vnet, on premise용 vnet을 구성, 서로 peering을 맺었어요.

(On Premise처럼 동일한 구성을 위해 ER 구축을 하고싶으나,,, 현실적으로 불가능 하므로 peering = er 통신으로 가정하고 테스트 했어요 ㅎㅎ)

테스트는 private endpoint가 달린 storage account에 대해서, private dns로 nslookup이 가능한지, 테스트 해보았어요. 해당 테스트는 DNS Private Resolver의 Inbound Endpoint를 사용하는 테스트입니다.

전제 조건 : Spoke 내에 존재하는 VM NIC의 DNS Server를 1,2번은 DNS Forwarder로, 3번은 DNS Private Resolver의 Inbound Endpoint VIP로 각각 테스트 진행해 보았어요.

1. DNS Forwarder로 구성한 VM을 DNS Server로 지정, DNS Server 서비스를 START 한 뒤 테스트(성공)

DNS Forwarder로 구성한 VM은 DNS 질의가 오는 것에 대해 Azure Provided DNS인 168.63.129.16으로 전달하게 되고, 다음과 같이 Blob의 Private DNS를 얻을 수 있음을 확인할 수 있어요.

2. DNS Server를 기본 설정 그대로 두고 테스트(실패)

이번에는 DNS Server 설정을 VNET의 default 그대로 두고 테스트를 해 보았어요. vnet 두개가 peering이 되어 있지만 blob의 private dns zone에 nslookup 명령을 하는 VM이 존재하는 Vnet은 LINK가 되어 있지 않아요. 따라서 Private DNS를 lookup하지 못하고 Storage Account의 public 주소로 검색이 되게 되죠.

3. DNS Private Resolver로 DNS Server를 지정하여 테스트(성공)

1번과 똑같은 상황에서, DNS Server를 DNS Private Resolver의 Inbound Endpoint VIP로 넣었어요. DNS Private Resolver는 Azure Provided DNS에 질의하여 Private Blob을 조회가능하게 한 것이죠.

4. How much DNS private resolver Price?

다음으로 비용은 어느정도 나올지 측정해 보았습니다. DNS Forwarder 역할을 수행하는 Inbound Endpoint는 20만원의 가격이 소요됨을 확인할 수 있어요.

5. Conclusion

On-Premise와 통신하는 Cloud 환경을 만들면서, DNS Forwarder 구성은 DNS 검색을 위해서는 필수 불가결한 사항이였어요. 그러한 상황을 Azure는 인지하고, DNS Private Resolver 서비스를 출시함으로서 고객들의 니즈를 잘 파악하고 해당 서비스를 출시한 것으로 보여지네요.

신규 서비스 DNS Private Resolver 소개는 여기까지 입니다. 다음 서비스 소개에서 만나요~!

시작하는 사람의 머뭇거림 - 앞서가는 사람들에게 받는 혜택

알 수 없는 사용자 — Thu, 2 Mar 2023 22:52:41 +0900

이미 오래되고 커버린 시장

AWS는 S3와 EC2 제품을 통해 2006년 첫번째 클라우드 제품을 출시하였다. 그리고, 2년 뒤 구글... 그 이듬해 MS가 차례로 클라우드 서비스를 시작하였다.
IT산업에서 이미 20년 가까이 성장해온 클라우드 서비스로의 업무 전환이 뒤늦은 것은 아닌지 고민이 된다.
하지만, 클라우드 시장은 여전히 성장하고 있고 이전의 Lift & Shift 방식의 단순 플랫폼 전환만이 아니라 App Modernization, IoT, AI/ML 등 Digital Transformation을 위한 워크로드가 다양화하고 있으며 시장 규모도 매년 성장 추세에 있다.

그렇다면, 이미 성숙기에 올라섰을지도 모를 클라우드 환경에서 어떻게 해야 할까?

우선 클라우드를 떠나 누구나 공감할 수 있는 이미 성숙기에 접어든 시장에 뒤늦게 참여하게 되는 상황에 고찰해 보려 한다. 그런 후에 클라우드에서 성장해 가기 위한 방향으로 다시 한 번 고민해 보고, 다음 주제부터 진행하려고 하는 목표를 설정하려고 한다.

늦게 시장에 합류하는 것에 대한 두려움

남들보다 뒤늦게 시장이나 산업에 참여하는 것은 흥미진진하면서도 두려운 일이다. 시장에 늦게 참여함으로써 시장 참여가 너무 늦는 것에 대한 두려움, 앞서간 기술 또는 사람과의 경쟁에 대한 걱정, 앞서가는 사람들을 따라잡을 수 있을지에 대한 걱정 등 많은 도전과 걱정에 직면할 수 있다.

하지만, 성공과 실패를 겪으며 성장한 시장에 참여한다는 것은 여러 경험과 성공으로부터 배울 수 있는 이점이 있다. 또, 그 정보를 이용하여 나에게 적합한 성공 방정식을 찾아갈 수도 있다.

이번 글에서는 상대적으로 늦게 시작한 사람들에게 직면한 몇 가지 일반적인 우려 사항을 살펴보고, 그러한 두려움을 극복하고 직면한 현실에서 나름대로의 성공을 찾아가는 방법에 대해 적어보려 한다.

나아가 클라우드로의 여정이라는 커다란 흐름에서 나에게 맞는 학습 방향을 탐구하고 성장해 나가는 방식을 찾아보려고 한다.

나의 여정 첫번째: 너무 늦어버린 시간에 대한 두려움 <극복>

남들에 비해 시작이 늦은 상황에서 가장 큰 걱정 중 하나는 "너무 늦은 것"에 대한 두려움일 수 있다. 늦게 시작한 사람은 앞서가는 사람들에 비해 많은 기회를 잃어버리고 상대적으로 소외되었다고 느낄 수 있다. 많은 기회가 사라졌다고 하지만, 항상 새로운 기회는 우리 앞에 나타난다.

네이트온이 지고 카카오가 개인 메시징 선두 사업자로 떠오를지 누가 알았을까?

롯데, 신세계와 같은 대형 유통업체가 쿠팡에 밀릴거라는 것을 상상이나 했을까?

두려움과 위기는 극복해야 하는 대상으로, 여전히 존재하는 잠재적인 기회에 집중하면서 나만의 차별화를 찾고 시장에서 두각을 나타낼 방법을 찾아야 한다.

나의 여정 두번째. 따라잡기

시장에 늦게 참여한 사람은 앞서간 사람 또는 기술을 따라잡을 수 있고 잃어버린 시간을 만회할 수 있을지 걱정할 수 있다. 이러한 우려를 극복하기 위해 새롭게 시작한 사람은 먼저 앞서간 사람의 경험과 성공을 활용하고 해당 정보를 사용하여, 먼저 앞서간 사람이 많은 시행착오를 통해 얻어간 경험을 빠르게 자신의 것으로 만들 수 있는 기회를 얻을 수 있다.

처음 가보는 한적한 시골길 심야 도로에서 운전을 하고 있다고 생각을 해 보자. 가로등도 없는 시골길은 해가지면 차량의 헤드라이트만으로는 멀리 볼 수 없어 운전하는데 많은 어려움이 있다. 이 때, 주변 농가의 트럭이 도로를 달리고 있으면 그 뒤를 따라가면서 낯선 시골길을 어려움없이 운전할 수 있다.

하지만, 트럭의 뒤를 따라가기만 하면 저속으로 주행하는 트럭의 영향으로 목적지에 가는 시간은 당겨지지 않을 것이다. 이 때 우리는 트럭을 언제 추월할 것인가 고민하게 된다.

마찬가지로 무조건적인 따라하기(또는 카피, Copy)는 동일한 결과를 내는 것에 그칠 수 있는 약점이 있다.

이러한 약점을 극복하기 위해서는 유연하고 적응력이 있어야 하며 앞서 나가기 위해 필요에 따라 기꺼이 변화해야 한다.

나의 여정 세번째. 경쟁

일반적으로 마지막 관심사는 경쟁에서의 우위이다. 유리한 출발과 더 큰 시장 점유율을 가진 기존 플레이어와 경쟁하는 것에 대해 걱정할 수 있다. 이러한 우려를 극복하기 이해 뒤늦게 출발한 사람은 새롭고 혁신적인 솔루션을 찾는데 집중하고 자신을 차별화하고 고유한 가치를 만드는 방법을 찾아야 한다.

뒤늦게 시작함으로 인해 시장에 합류하는 것은 어려울 수 있지만, 올바른 접근 방식을 통해 두려움을 극복하고 성공할 수 있다. 여전히 존재하는 기회에 집중하고, 경쟁에서 차별화하고, 먼저 시작한 사람들의 경험과 성공을 활용하고, 유연하고 적응력을 유지함으로써 시장에서 강력한 위치를 확립하고 목표를 달성할 수 있다.

스티브 잡스는 “유능한 예술가는 모방하고 위대한 예술가는 훔친다(Good artists copy, great artists steal)”는 피카소의 말을 즐겨 인용한다. “인류가 지금껏 만들어놓은 최고의 것을 자신의 일에 접목하는 지혜가 필요하다”는 설명이다. 특히 세계 젊은이들에게 영감을 준 그의 명언이 있다. “갈망하라, 바보 짓을 두려워 말라(Stay hungry, stay foolish)”

- 중앙일보, 2011 -

클라우드

나의 클라우드 여정 첫번째: 어디서 시작할것인가?

클라우드 시장에 참여하여 다양한 자격증을 취득하였다. 하지만, 다양한 산업 환경 및 프로젝트에서 경험이 축적되지 않으면서 기껏 쌓아올린 이론은 그대로 기억 저편으로 멀어지고 있다. 클라우드 현장에서 프로젝트를 진행한다고 해도 수행 기간 등 물리적으로 필요한 부분이 있어 1년이 지나도 많은 경험을 할 수 없다.

이러한 현실에서 어떻게 해야 더욱 재미있고 흥미를 이끌 수 있는 일을 할 수 있을까 고민을 하며 내린 결론은 토이 프로젝트를 만들고 여기에 뼈대와 살을 붙여가며 클라우드의 여러 영역을 넣어보면 어떨까 하는 생각을 하게 되었다.

이렇게 내가 시작할 수 있는 출발점을 찾는 것에서 시작하였다.

하지만, 토이 프로젝트도 경험이 많거나 의지가 높은 사람에게나 효과가 있는 것이다. 어떤 성격에서는 토이 프로젝트를 만드는 것 자체가 큰 숙제이다.

나의 클라우드 여정 두번째: 시작을 위한 준비

한참의 고민과 검색 끝에 내 상황에 적합하면서도 지금 시작하기에 부담없는 방법을 찾았다. AWS는 업계 1위이면서 Pro-serve라는 좋은 조직을 운영하고 있다. AWS의 블로그를 탐색하니 여러 토이 프로젝트가 공유되고 있는 것을 확인했다.

앞서 있는 사람들에게 배울 수 있는 장점. 나는 그 대상을 찾은 것이다.

이제 여기서 내가 흥미를 가질만한 프로젝트를 선정하면 그게 내가 첫번째 진행할 목표가 되는 것이다.

첫번째 프로젝트: 드론 촬영 이미지를 ~~AWS~~ Azure 클라우드로 전송하기
https://aws.amazon.com/ko/blogs/tech/ingesting-drone-shot-images-into-aws/

나의 클라우드 여정 세번째: 경쟁

아직은 고민하기에는 너무 이른 것 같지만, 프로젝트를 진행하면서 충분히 이해하게 되면 나만의 차별점을 넣을 수 있는 기회가 있을 것으로 생각된다. 그것이 내가 나보다 앞서간 사람들의 창작물을 훔쳐가는 과정이라고 생각한다. 지금 생각나는 것은 DT 전환의 커다란 울타리 안에 포함할 수 있는 DevOps, 모니터링, 로깅 등이 떠오르지만, 이런 프로젝트 몇 개를 경험하다 보면 나만의 새로운 프로젝트를 만들어 갈 수 있을 것으로 기대한다.

IT초보가 들려주는 IT트렌드 뽀개기 1. ChatGPT

피스_트리 — Thu, 2 Mar 2023 22:35:27 +0900

ChatGPT.

IT 개발자라면, IT 업계에 종사하고 있다면, IT에 조금이라도 관심이 있다면 분명 들어봤을 만한 서비스라고 생각합니다.

그만큼 ChatGPT는 최근 들어 IT 업계에서 가장 큰 주목을 받고 있는데요.

왜 ChatGPT는 화제가 되었을까요?

ChatGPT의 등장에 왜 구글에서는 코드 레드를 선포했을까요?

ChatGPT에 대해 궁금해할 만한 부분을 모아모아 가려운 등 긁어주듯이 속시원하게 말해주고자 합니다.

IT초보인 피스트리가 들려주는 IT트렌드 뽀개기 시리즈 첫번째, ChatGPT에 대해 알아보자!

Q1. ChatGPT가 뭐야?

https://openai.com/blog/chatgpt/

ChatGPT는 미국 샌프란시스코에 소재한 OpenAI라는 회사가 2022년 12월 1일 공개한 AI 언어 모델, AI 챗봇 서비스입니다.

텍스트 기반의 프롬프트, 즉 우리가 흔히 사용하는 카카오톡과 같은 메신저로 친구에게 채팅을 하듯 질문을 입력하면 사람과 같이 대답을 하고, 대화가 가능한 거죠.

긴 글을 짧게 요약해주고, 영어로 된 글을 한국어로 번역해주기도 하며, 시, 짧은 소설까지 문학적인 내용부터 코드까지 작성해

줍니다.

미국 하원 의원인 제이크 오친클로스는 의회가 AI기술에 대해 관심을 가질 수 있도록 ChatGPT에 법안의 중요성을 소개하는

하원 연설문을 100단어로 작성하라고 입력해 뽑아낸 연설문을 읽기도 해 화제가 되기도 했는데요.

출시 두 달 만에 하루 이용자 천 만을 돌파한 ChatGPT는 현재 무료로 제공되고 있으며, 월 20달러의 유료 서비스인 “ChatGPT Plus”도 출시했습니다. 사용자가 많이 몰리게 되면 간혹 접속이 안되는 경우가 있는데 유료 요금제를 구독하면 이러한 문제가

해결될 것으로 보고 있으며, 앞으로 나올 신규 서비스를 미리 써볼 수 있습니다.

Q2. ChatGPT에서 Chat은 알겠어. 그런데 GPT는 뭐야?

GPT는 Generative Pre-trained Transformer의 약자입니다.

OpenAI 홈페이지 블로그 게시글을 보면, ChatGPT는 2022년 초반에 트레이닝을 완료한 GPT 3.5 시리즈 모델을 사용한다고

명시되어 있는데요.

2018년 처음 공개된 GPT-1을 시작으로 2019년 GPT-2를 거쳐 2020년 공개된 GPT-3은 1750억개의 매개변수를 활용한

것으로 알려져 있습니다.

GPT-3은 공개 당시 인간에 준하는 수준의 이해력과 문장력을 갖춘 글을 선보여 전세계를 놀라게 했는데 이 GPT-3의 여러

오류를 개선한 버전이 3.5입니다.

기존 GPT-3은 텍스트를 입력해서 뒤에 어떤 텍스트가 이어질지 예상하는 방식이었습니다.

쉽게 설명하면 우리가 네이버 검색창에 특정 단어를 입력하면, 해당 단어와 연관된 단어가 검색창 아래에 뜨게 만드는 기술인

겁니다. 3.5 버전은 여기에 텍스트에 대한 사람의 판단까지 가르친 것으로, 즉 성능 자체는 3과 유사하나 훨씬 자연스러운 대화가 가능해진 것이죠.

Q3. ChatGPT, 나도 써보고 싶은데 어떻게 쓰는 거야? 한국어로 질문해도 돼?

일반적인 챗봇 서비스와 사용 방법은 동일합니다. 별도로 PC에 설치해서 사용하는 서비스가 아니기 때문에 https://chat.openai.com/chat 에 접속해서 로그인 후 질문을 하면 됩니다.

회원가입을 해도 되지만 기존에 사용하던 구글, Microsoft 계정으로도 로그인이 가능합니다.

※ 참고!

크롬 브라우저에 ChatGPT for Google 확장 프로그램을 설치할 수도 있습니다.

이 확장 프로그램을 설치하면 구글에서 검색할 때 페이지 오른쪽에 ChatGPT가 해주는 답변도 함께 볼 수 있습니다.

(https://chrome.google.com/webstore/detail/chatgpt-for-google/jgjaeacdkonaoafenlfkkkmbaopkbilf?hl=ko)

물론 한국어로도 지원이 되고 있습니다. 하지만 영어로 질문하는 게 훨씬 속도가 빠릅니다.

ChatGPT에 ChatGPT가 뭔지 영어와 한국어로 각각 질문을 해보았습니다.

영어로 질문했을 땐 답변이 완료되기까지 단 15초밖에 걸리지 않았지만, 한국어로 질문을 하면 약간의 로딩이 생겼고 47초가

소요되었습니다.

나는 성질이 급해서 로딩 시간을 기다리기 싫고 빠른 답변을 원한다!

이럴 경우에는 현재로선 영어로 질문하는 게 낫습니다.

다른 답변을 원한다면 Regenerate response 버튼을 누르면 되고, 현재 답변에 대해 긍정 혹은 부정으로 평가할 수도 있습니다.

Q4. ChatGPT가 왜 이렇게 화제가 된거야?

https://www.independent.co.uk/tech/ai-chatbot-chatgpt-google-openai-b2237834.html

영국 일간지 인디펜던트는 ChatGPT가 공개된 다음날 “Google is done”(구글은 끝났다)라는 제목의 기사를 올렸습니다. Google과 ChatGPT의 응답을 다양한 쿼리와 비교한 앱 개발자 Josh Kelly의 트윗을 인용한 것으로 보이는데요. 자극적으로

보이기도 하는 저 문구가 바로 그 답입니다.

ChatGPT가 등장하면서 가장 큰 이슈가 되고 있는 건 바로 구글 검색 엔진을 대체할 수 있을 거라는 전망입니다. 기존에는 우리가 어떤 정보를 필요로 할 경우, 구글에 접속해 검색어로 검색을 시작해 기사도 보고, 관련 논문도 찾아보고, 블로그 글도 읽게

됩니다. 여러 사이트를 돌아다니며 가장 신뢰할 만한 정보를 찾는 거죠.

그런데 ChatGPT는 인터넷에 있는 정보를 학습하고 있기 때문에 이렇게 우리가 정보의 바다 속에서 정보를 찾아다닐 필요가 없이 질문만 하면 몇십초 만에 그 답을 얻어 낼 수가 있는 겁니다.

교육계에서도 ChatGPT는 혼란을 불러일으키고 있습니다. 기계가 쓴 것 같이 느껴지지 않을 수준으로 보고서 등을 작성할 수

있다보니 ChatGPT에 질문하는 것으로 숙제를 대신 하는 것으로 각광을 받게 된 겁니다. 학생들의 학업 평가 기준이 무너질 수

있으며, 레포트의 표절을 따지기가 더 어려워진 겁니다.

“제가 다닌 고등학교에 갔더니 영어 선생님이 학생들이 전부 ChatGPT를 쓰고 있는 게 분명하다고 하시더라고요.”라고 ChatGPT 제로 개발자인 에드워드 티안이 인터뷰할 정도입니다.

마이크로소프트의 투자도 한 몫 했습니다. 지난 2019년 마이크로소프트는 이미 OpenAI에 10억 달러를 투자했으며, OpenAI의 초거대 AI모델 고도화에 필요한 클라우드 자원도 공급하고 있습니다.

최근에는 수년 간 총 100억 달러에 이르는 새로운 투자 계획을 공식화했습니다. OpenAI를 이용해 마이크로소프트의 클라우드 서비스인 Azure 기능을 강화하고 MS가 보유한 소프트웨어에 적용할 계획인 것으로 알려졌습니다.

이미 지난 1월 ChatGPT 기반의 Bing 검색 엔진 버전을 올 3월 내에 출시할 예정인 것으로 구글에 도전장을 내밀었으며, 2월 1일 GPT 3.5를 접목한 마이크로소프트 팀즈 프리미엄을 정식 출시했습니다. Bing에서 ChatGPT는 ‘프론트 엔드’ 역할을 할 수 있을 거라는 의견이 있습니다. 즉 Bing에 검색어를 입력하면 기존 검색 엔진과 같이 검색 결과로 관련 링크들을 보는 대신 완성된 글의 형태로 답변을 얻을 수 있게 접목할 것으로 예상하고 있습니다.

솔트룩스 이경일 대표에 따르면 구글은 ChatGPT와 견줄만한 기술이 없는 건 아닐 것으로 전문가들은 보고 있다고 합니다. 다만 이미 ChatGPT가 AI 시장을 제일 처음으로 뒤흔들고 있기 때문에 2등으로 진입하는 기업은 고민하게 될 수 밖에 없겠죠.

과연 마이크로소프트의 Bing이 ChatGPT의 손을 잡고 92%의 압도적인 점유율을 자랑하는 구글을 따라잡을 수 있을지 그 귀추가 주목됩니다.

Q5. 그럼 ChatGPT가 가지고 있는 한계는 없는거야?

물론 한계가 있습니다.

현재 공개된 ChatGPT는 2021년까지의 데이터를 기반으로 학습되었기 때문에 그 이후 정보는 가지고 있지 않습니다. 훈련된 모델에서 답을 해주는 서비스이며 실시간으로 정보를 검색하는 것도 아니기 때문에 맛집 정보와 같이 계속해서 업데이트되는 정보를 찾기에는 아직 구글에 검색하는 것이 나은 것으로 평가됩니다.

정보의 신뢰도도 한계 중 하나입니다. 인터넷에 있는 데이터를 학습하는 AI 특성상 정보 자체가 잘못된 정보인지 신뢰할 만한 정보인지를 판별해내지 못하기 때문에 잘못된 답변을 내놓을 수 있다는 겁니다. 현재까지는 ChatGPT이 알려주는 정보가 완벽하게 정확하지는 않다고 합니다.

위에서 말했던 것처럼 한국어를 지원하기는 하나 오류가 발생하거나 내용이 빈약한 경우가 빈번하다고 합니다. 아무래도 한국어로 된 자료가 영어에 비해선 적기 때문이죠.

피스 트리의 총평.

오늘은 IT 업계에서 가장 핫한 키워드인 ChatGPT에 대해 간략하게 알아보았습니다.

ChatGPT를 한번쯤은 사용해 보셨을 분들도, 이 글을 보고 사용해볼 분들도 있을 것 같습니다.

사용해보면 너무나 편리하고, 무서울 정도로 똑똑하다는 생각이 듭니다.

AI 기술은 ChatGPT의 등장과 함께 점점 더 빠르게 발전할 것으로 보입니다.

이러한 AI 시대에 어떻게 살아가야 할지 ChatGPT의 등장은 많은 고민거리를 안겨주고 있습니다.

IT초보가 들려주는 IT트렌드 뽀개기 두번째도 기대해주세요!

Google Cloud에서 제공하는 Data Analytics 서비스 살펴보기

골리어스 — Wed, 14 Dec 2022 17:11:02 +0900