[3주차] 클라우드에서의 리소스와 엑세스
학습목표
1. IAM의 목적과 사용 사례를 정의하기
2. 구글 클라우드와의 상호 작용 방법을 나열하기
3. 클라우드 마켓플레이스를 사용하여 구글 클라우드와 상호 작용하기
4. 구글 클라우드에서 프로젝트의 목적을 파악하기
[3-1] 구글 클라우드 리소스 계층
이번 섹션에서는 구글 클라우드의 기능 구조에 대해 살펴 본다. 구글 클라우드의 리소스 계층에는 4가지 레벨이 존재한다. 제일 아래인 리소스부터, 프로젝트, 폴더, 조직 노드에 이르기까지 4개가 존재하는 것이다. 첫 번째 레벨인 리소스는 가상 머신, 클라우드 스토리지 버킷, 빅쿼리의 테이블, 또는 그밖의 구글 클라우드 안의 모든 것을 나타낸다. 리소스는 2번째 레벨에 있는 프로젝트로 정리된다. 프로젝트는 폴더 또는 심지어 하위 폴더로 정리될 수도 있다. 이것들은 3번째 레벨에 존재한다. 그리고 가장 높은 레벨에는 조직 노드가 있는데, 이는 조직 안의 모든 프로젝트, 폴더, 리소스를 포함한다. 이러한 리소스 계층을 이해하는 것은 우리가 구글 클라우드를 사용할 때 어떤 정책들이 관리되고 적용되는지와 직접적인 연관이 있기에 매우 중요하다. 정책이라 함은 프로젝트, 폴더, 그리고 조직 노드 수준에서 정의될 수 있다.
일부 구글 클라우드 서비스는 정책들이 개별 리소스에도 적용되는 것을 허용한다. 여기서 정책들은 아래로 상속된다. 즉, 만약 우리가 폴더에 정책을 적용하면, 그건 폴더 내에 있는 프로젝트에도 적용된다는 것이다. 한편, 리소스 계층의 2번째 계층인 프로젝트에 대해 조금 더 자세히 살펴보면, 프로젝트는 API 관리, 빌링 작업, 공동작업자 추가 및 제거, 다른 구글 서비스를 활성화하는 것과 같은 구글 클라우드 서비스를 사용하고 활성하기 위한 기반이라 할 수 있다. 각 프로젝트는 조직 노드 아래에 있는 별도의 엔티티이고, 각 리소스는 정확하게 하나의 프로젝트에 속한다. 프로젝트에는 각각의 소유자와 사용자가 존재하며, 왜냐하면 그것들은 각각 분리되어 청구되고 관리되기 때문이다.
각 구글 클라우드 프로젝트는 3가지의 식별 속성이 있다. 프로젝트 ID, 프로젝트 이름, 프로젝트 숫자. 프로젝트 ID는 구글에서 할당한 글로벌 고유 식별자로, 생성 후에는 변경할 수 없다. 이른바 불변인 개념인 것이다. 프로젝트 ID들은 작업할 정확한 프로젝트를 구글 클라우드에 알리기 위해 다양한 컨텍스트에서 사용된다. 그런데 ID와 달리 프로젝트 이름은 사용자가 직접 만든다. 그것들은 고유할 필요가 없고, 언제든 변경도 가능하므로 불변과는 거리가 멀다. 구글 클라우드는 또한 각 프로젝트에 고유한 프로젝트 숫자를 할당한다. 이러한 구글에서 생성한 숫자가 존재한다는 것을 알면 도움이 되긴 하지만, 이 과정에서는 이 정도로 알고 있으면 충분하다. 그 숫자는 주로 구글 클라우드가 리소스를 추적하기 위해 내부적으로 사용된다.
구글 클라우드의 리소스 매니저 도구는 우리가 프로젝트를 관리할 수 있도록 프로그램적으로 설계되었다. 이것은 계정과 관련된 모든 프로젝트 목록을 모으고, 새로운 프로젝트를 생성하고, 기존 프로젝트를 업데이트하고, 삭제할 수 있는 API이다. 이것은 심지어 이전에 삭제되었던 프로젝트도 복구할 수 있으며, RPC API와 REST API를 통해 엑세스될 수 있다. 구글 클라우드 리소스 계층의 3번째 레벨은 폴더다. 폴더를 사용하면 우리가 선택한 세분화 수준의 리소스에 정책을 할당할 수 있다. 폴더 안에 있는 리소스는 해당 폴더에 할당된 정책과 권한을 그대로 물려받는다. 폴더에는 프로젝트나 다른 폴더, 또는 이 둘의 조합이 포함될 수 있다.
우리는 폴더를 사용하여 계층의 조직 아래에서 프로젝트를 그룹화할 수 있다. 예를 들어, 조직에는 다양한 부서가 존재할 것이고, 각 부서는 고유한 구글 클라우드 리소스를 갖고 있을 것이다. 이때 폴더를 사용하면, 이러한 리소스를 부서에 따라 그룹화할 수 있다는 것이다. 폴더는 또한 팀이 독립적으로 작업할 수 있도록 관리 권한을 위임할 수 있는 기능을 제공한다. 앞서 말했듯, 폴더 안의 리소스는 그 폴더에 있는 정책과 권한을 상속한다. 예를 들어, 동일한 팀에서 관리하는 2개의 프로젝트가 있다고 하자. 그러면 공통 폴더에 정책을 넣을 수 있고, 그럼 동일한 권한을 갖게 할 수 있다. 두 프로젝트 모두에 해당 정책의 복사본을 넣는 등의 방식으로 처리하는 경우, 괜히 장황해지고 오류가 발생하기 쉽다. 두 리소스 모두에 대한 권한을 변경해야 하는 경우, 이제 한 곳이 아닌 두 곳에서 변경을 해야 한다. 폴더를 사용하려면 반드시 구글 클라우드 계층에서 최상위 리소스인 조직 노드가 있어야 한다. 해당 계정에 연결된 다른 모든 것은 폴더, 프로젝트, 기타 리소스를 포함하는 이 노드 아래에 있다.
한편, 이 최상위 조직 노드와 관련된 몇 가지 특별한 역할이 존재한다. 예를 들어, 우리는 조직 정책 관리자를 지정하여 권한이 있는 사용자만 정책을 변경하도록 만들 수 있다. 또한, 프로젝트 생성자 역할도 할당해줄 수 있다. 이는 프로젝트를 생성할 수 있는 사용자를 제어할 수 있는 훌륭한 방법이며, 결과적으로 돈을 절약할 수도 있다.
새로운 조직 노드를 만드는 방법은 그 회사가 구글 워크스페이스의 고객인지 여부에 따라 달라진다. 워크스페이스 도메인이 있는 경우, 구글 클라우드 프로젝트는 자동적으로 조직 노드에 속할 것이다. 그렇지 않으면, 우리는 구글 ID, 엑세스, 애플리케이션, 엔드포인트 관리 플랫폼인 클라우드 ID를 통해 그것을 생성할 수 있다. 한 번 새로운 조직 노드가 생성되면, 이전과 마찬가지로 도메인 안에 있는 누구나 프로젝트를 생성하고, 과금 계정을 만들 수 있다.
그러면 폴더를 그 안에 배치하고, 또 프로젝트를 그 안에 배치한다. 폴더와 프로젝트는 모두 조직 노드의 자식으로 간주된다.
[3-2] ID 및 엑세스 관리(IAM)
조직 노드에 폴더, 프로젝트, 리소스가 많이 포함될 경우, 작업자는 엑세스 권한이 있는 사람을 제한해야 할 수도 있다. 이 작업을 돕기 위해 관리자는 ID 및 엑세스 관리, 즉 IAM을 사용할 수 있다. IAM을 사용하면, 관리자는 누가(who) 무엇을 수행하는지(can do what), 어떤 리소스에 수행할 수 있는지를 정의하는 정책을 적용할 수 있다. IAM 정책의 'who' 부분은 구글 계정, 구글 그룹, 서비스 계정 또는 클라우드 ID 도메인이 될 수 있다. 이 who는 principal이라고도 불린다. 각 principal은 일반적으로 이메일 주소와 같은 고유한 식별자를 보유하고 있다. 그리고 IAM 정책의 'can do what'은 역할에 의해 정의된다. IAM 역할은 일종의 권한 모음이다. 우리가 principal에게 역할을 부여할 때, 우리는 그 역할에 포함된 권한도 모두 부여하게 된다. 예를 들어, 프로젝트에서 가상 머신 인스턴스를 관리하기 위해 우리는 가상 머신을 생성하고, 제거하고, 시작하고, 중지하고, 변경할 수 있어야 한다. 따라서 이러한 권한은 역할에 따라 그룹화되어 있기 때문에 이해하기도 쉽고, 관리하기도 수월하다. principal에게 리소스 계층의 특정 요소에 대한 역할이 주어지면, 결과 정책은 그 선택된 요소와 계층에서 그것의 아래에 있는 모든 요소에 적용된다. 그리고 특정 principal에게 부여된 역할에 관계없이, 특정 권한을 사용하지 못하도록 하는 거부 규칙을 정의할 수 있다. 이것은 IAM이 언제나 관련된 허용 정책을 확인하기 전에 관련 거부 정책을 확인하기 때문이다. 허용 정책과 마찬가지로, 거부 정책도 리소스 계층을 통해 상속된다.
IAM에는 '베이직', '사전 정의', '사용자 정의'의 3가지 역할이 존재한다.
첫 번째 역할 타입은 베이직이다. 베이직 역할은 상당히 범위가 넓다. 구글 클라우드 프로젝트에 적용하면, 그들은 그 프로젝트 내의 모든 리소스에 영향을 미친다. 베이직 역할에는 소유자, 에디터, 뷰어, 빌링 관리자가 포함된다. 이러한 베이직 역할에 대해 조금 더 살펴 보자. 프로젝트 뷰어는 리소스에 엑세스할 수 있지만, 그것을 변경할 수는 없다. 그저 view일 뿐이다. 프로젝트 에디터는 이름에서도 알 수 있듯, 리소스에 엑세스하고, 그것을 변경할 수도 있다. 그리고 프로젝트 소유자도 리소스에 엑세스, 변경할 수 있다. 게다가 프로젝트 소유자는 관련 역할과 권한을 관리하고, 빌링을 설정할 수 있다. 종종 기업들은 누군가가 특정 프로젝트에 대한 빌링을 제어하길 원하지만, 그 프로젝트 안에 있는 리소스는 변경할 수 없다. 이 권한은 빌링 관리자를 통해 가능해진다. 한편, 한 가지 주의할 점이 있는데, 민감한 데이터가 포함된 프로젝트를 여러 사람이 함께 작업하고 있는 경우, 베이직 역할은 지나치게 광범위할 수 있다. 다행스럽게도, IAM은 일반적인 직무 역할의 요구에 맞게 더욱 구체적으로 맞춤화된 권한을 할당할 수 있는 다른 방법을 제공한다.
이를 통해 우리는 2번째 역할인 '사전 정의' 역할로 이동할 수 있다. 특정 구글 클라우드 서비스는 사전에 정의된 역할 셋을 제공하고, 그러한 역할이 적용될 수 있는 위치도 정의한다. 예시로, 가상 머신을 서비스로 제공하는 구글 클라우드 제품과 같은 컴퓨트 엔진에 대해 살펴 보자. 컴퓨트 엔진을 사용하면, InstanceAdmin과 같은 사전에 정의된 역할을 주어진 프로젝트나 폴더, 혹은 전체 조직 안에 있는 컴퓨트 엔진 리소스에 적용할 수 있다. 그러면 이러한 역할을 지닌 사용자가 사전에 정의된 액션의 특정 셋을 수행할 수 있게 된다.
그런데 그럼 만약 더욱 구체적인 권한이 있는 역할을 할당할 필요가 있을 때는 어떻게 해야 할까? 그때 등장하는 것이 바로 '사용자 정의' 역할이다. 많은 회사에서 '최소 권한' 모델을 사용하고 있다. 이 모델은 직원들의 업무 수행에 있어서 필요한 최소한의 권한만을 부여한다. 그러니까 예를 들어, 우리는 일부 사용자가 가상 머신을 시작하고 중지할 수 있도록 InstanceOperator 역할을 정의하길 원하고, 재구성은 원치 않을 수 있다. 사용자 정의 역할은 그런 정확한 권한을 정의할 수 있게 해준다. 그런데 사용자 정의 역할을 만들기 전에, 우리는 2가지 세부사항에 대해 확실히 알고 있어야 한다. 첫째로, 우리는 우리가 생성한 사용자 정의 역할을 정의하는 권한을 관리해야 한다. 이것 때문에 몇몇 조직에서는 사전 정의 역할을 사용하기로 결정하기도 한다. 둘째로, 사용자 정의 역할은 프로젝트 또는 조직 레벨에만 적용할 수 있다. 폴더 수준에는 정의할 수 없다는 것이다.
[3-3] 서비스 계정
사용자가 아닌 컴퓨터 엔진 가상 머신에 사용 권한을 부여하려면 어떻게 해야 할까? 그것이 바로 서비스 계정의 존재 의의다. 예시로, 클라우드 스토리지 안에 데이터를 저장해야 하는 가상 머신에서 실행 중인 애플리케이션이 있다고 하자. 그런데 우리는 인터넷 상에서 그 누구도 데이터에 접근하길 원치 않는 것이다. 서비스 계정을 만들면 해당 가상 머신을 클라우드 스토리지에 인증할 수 있다. 서비스 계정은 이메일 주소로 명칭이 지정되지만, 패스워드를 대신하여 암호 키를 사용하여 리소스에 접근한다.
따라서 만약 서비스 계정에 컴퓨트 엔진의 Instance Admin 역할이 부여되면, 해당 서비스 계정이 있는 가상 머신에서 실행 중인 애플리케이션이 다른 가상 머신을 생성, 수정, 삭제할 수 있게 된다. 서비스 계정은 관리되어야 할 필요가 있다. 예를 들어, 앨리스가 서비스 계정으로써 작동할 수 있는 구글 계정을 관리해야 하는 반면, 밥은 그저 서비스 계정 목록을 볼 수 있으면 된다.
다행스럽게도, 서비스 계정은 ID일 뿐만 아니라 리소스이기도 하기 때문에, 거기엔 고유의 IAM 정책이 부착될 수 있다.
이것의 의미는 앨리스가 서비스 계정에 에디터 역할을 갖고, 밥이 뷰어 역할을 가질 수 있다는 것이다. 이는 다른 구글 클라우드 리소스에 대해 역할을 부여하는 것과 같다.
[3-4] 클라우드 ID
새로운 구글 클라우드 고객이 플랫폼을 사용하면, 지메일 계정으로 구글 클라우드 콘솔에 로그인한 후 비슷한 역할이 주어진 동료들과 협업하기 위해 구글 그룹을 사용하는 것이 일반적이다. 이런 접근 방식은 매우 쉽지만, 팀의 ID가 중앙에서 관리되지 않기 때문에 추후에 문제가 발생할 여지가 있다. 예를 들어, 조직 안에 있던 누군가가 그곳을 떠나게 될 경우 문제가 생길 수 있다. 앞서 말한 방식을 사용하면, 팀의 클라우드 리소스에 대해 사용자의 접근을 즉시 제거할 수 있는 쉬운 방법이 없게 된다. 그런데 클라우드 ID라는 도구를 사용하면, 조직은 정책을 정의하고, 구글 어드민 콘솔을 사용하는 사용자와 그룹을 관리할 수 있다. 관리자는 기존의 Active Directory나 LDAP 시스템에서 이미 사용한 것과 동일한 사용자 명칭과 암호를 사용하여 구글 클라우드 리소스에 로그인하고 관리할 수 있다. 클라우드 ID를 사용한다는 것은 또한 누군가가 조직을 떠날 때, 관리자가 구글 어드민 콘솔을 사용하여 해당 계정을 비활성화하고 그룹에서 제거할 수 있다는 것을 의미한다. 클라우드 ID는 무료 에디션과 모바일 장치 관리 기능을 제공하는 프리미엄 에디션으로 이용할 수 있다. 만일 구글 클라우드 고객이면서 구글 워크스페이스 고객이라면, 구글 어드민 콘솔을 통해 이미 이 기능을 사용할 수 있다.
[3-5] 구글 클라우드와의 상호작용
구글 클라우드에 엑세스하여 상호작용하는 방법에는 총 4가지가 있다. 클라우드 콘솔, 클라우드 SDK와 클라우드 셸, API, 구글 클라우드 앱이 있다. 이것들에 대해 각각 살펴 보자. 첫 번째, 구글 클라우드 콘솔이다. 이것은 구글 클라우드의 그래픽 사용자 인터페이스, 이른바 GUI로, 간단한 웹 기반 인터페이스에서 배포하고, 확장하고, 프로덕션 문제를 진단할 수 있도록 도와준다. 구글 클라우드 콘솔을 사용하면 리소스를 쉽게 찾을 수 있고, 그것의 상태를 확인할 수 있으며, 그들에 대한 완전한 관리 제어를 갖고, 예산을 설정하여 리소스에 대한 사용을 제어할 수 있다. 또한, 클라우드 콘솔은 브라우저에서 SSH를 통해 빠르게 리소스를 찾고 인스턴스에 연결할 수 있는 검색 기능을 제공한다. 두 번째는 클라우드 SDK와 클라우드 셸을 통한 것이다. 클라우드 SDK는 구글 클라우드에서 호스트되는 리소스와 애플리케이션을 관리하는 데 사용할 수 있는 도구 세트다. 여기에는 구글 클라우드 제품과 서비스를 메인 커맨드 라인 인터페이스를 제공하는 구글 클라우드 CLI와 빅쿼리의 커맨드 라인 도구인 bq가 포함된다. 설치가 되면, 클라우드 SDK 내의 모든 도구는 bin 디렉터리 아래에 위치하게 된다. 클라우드 셸은 브라우저로부터 클라우드 리소스에 대한 커맨드 라인 엑세스를 직접적으로 제공한다. 클라우드 셸은 Debian 기반의 가상 머신으로, 5GB의 영구적인 홈 디렉터리를 갖추고 있어 구글 클라우드의 프로젝트와 리소스를 쉽게 관리할 수 있다. 클라우드 셸을 사용하면, 클라우드 SDK gcloud 명령과 다른 유틸리티가 항상 설치되고, 사용 가능하며, 최신 상태로 되며, 완전히 인증된다. 이제 세번째로, 애플리케이션 프로그래밍 인터페이스(API)다. 구글 클라우드를 구성하는 서비스는 API를 제공하여 사용자가 작성한 코드를 제어할 수 있게 한다. 클라우드 콘솔에는 구글 API 익스플로러라는 도구가 포함되어 있으며, 그것은 어떤 API가 사용 가능한지, 어떤 버전으로 사용할 수 있는지를 보여준다. 심지어 사용자 인증이 요구되는 API도 대화식으로 시도할 수 있다. 그렇다면 API를 탐색하고, 이를 사용하는 애플리케이션을 구축할 준비가 되어 있다고 가정해 보자. 그럼 우리는 맨 처음부터 코딩을 시작해야 할까? 물론, 아니다. 구글은 많은 인기있는 언어에서 클라우드 클라이언트 라이브러리와 구글 API 클라이언트를 제공한다. 이를 통해 우리의 코드로부터 구글 클라우드를 호출하는 작업에서 상당수의 번거로움을 덜어준다. 현재 이러한 라이브러리에 표현되는 언어로는 자바, 파이썬, PHP, C#, Go, Node.js, 루비, C++등이다. 그리고 마지막인 네번째로, 구글 클라우드 앱이 있다. 그 앱은 시작, 중지할 수 있고, SSH를 사용하여 컴퓨트 엔진 인스턴스에 연결하고, 각 인스턴스의 로그를 볼 수 있다. 또한, 클라우드 SQL 인스턴스를 시작하고 중지할 수 있다. 추가적으로, 에러 보기, 배포 롤백, 트래픽 분할 변경을 통해 앱 엔진에 배포된 애플리케이션을 관리할 수 있다. 구글 클라우드 앱은 프로젝트에 대한 최신 빌링 정보와 예산을 초과하는 프로젝트에 대한 빌링 경고를 제공한다. 우리는 CPU 사용량, 네트워크 사용량, 초당 요청, 서버 오류와 같은 주요 지표를 보여주는 사용자 정의 가능한 그래프를 설정할 수 있다. 그 앱은 또한 경고와 사고 관리를 제공한다. 구글 클라우드 앱은 cloud.google.com/app에서 다운로드할 수 있다.
[3-6] Coursera: 구글 클라우드 플랫폼과 Qwiklabs 시작하기
구글 클라우드의 일부인 Qwiklabs라는 대화식의 체험형 랩 플랫폼에 대한 튜토리얼을 시작한다. Qwiklabs를 사용하면 구글 클라우드에 대한 실용적인 경험을 얻을 수 있으며, 무료로 클라우드 콘솔에 엑세스할 수 있도록 하는 구글 계정 자격 증명을 제공한다.
첫 번째 단계는 익명 윈도우 창에서 Coursera에 로그인하는 것이다. 이건 프라이빗 브라우징이라 불리기도 한다. 내 경우에는 시크릿 창이 되겠다. 아무튼 프라이빗 윈도우 창에서 Coursera에 로그인하면, 클라우드 콘솔에 엑세스하는 동안 실수로 우리의 구글 계정을 사용하는 일이 없다. 이것은 월말에 예상치 못한 청구서가 날아오는 것을 미연에 방지하기 위함이다. Coursera에 로그인을 했으면, 코스로 돌아가서 lab activity 페이지로 이동한다. 메시지가 표시되면, honor code를 수락하고, 이름을 입력한다. 그런 다음 open tool을 클릭하여 해당 랩을 새 탭에서 실행한다. 그 새 탭에서 start lab을 클릭하고, 연결 세부정보가 좌측에 표시될 때까지 기다린다. 각 lab에는 쉽게 확인할 수 있는 남은 엑세스 시간과 타이머가 존재한다. 타이머가 종료되면 자동으로 lab이 종료되는 것이다. 이제 open google console을 클릭하고, 연결의 세부정보 페이지에 제공된 사용자 이름과 암호로 로그인한다.
여기에서 사용자 이름을 복사 붙여넣기 하고, 이것은 각 lab마다 다를 것이다. 그리고 나서 마찬가지로 패스워드도 잡아서 붙여넣기 해준다. 이제 Qwiklabs는 우리가 lab을 시작할 때마다 새로운 계정을 생성하게 된다. 그러므로 초기 계정 설정인 windows를 클릭해야 한다. 새 계정이 있다고 하면 수락하면 되고, 백업을 요청하게 되면 그저 확인하면 된다.
일단 클라우드 콘솔에 들어가면, 약관 및 서비스를 수락한다. 그다음 로드될 때까지 기다렸다가, 계정에 들어가면 올바른 프로젝트를 사용하고 있는지 확인한다. 사용하고 있는 프로젝트 ID를 볼 수 있기 때문에 이것이 실제로 Qwiklabs에 있는 것과 일치하는지 다시 한 번 확인하는 것이 좋다. 여기서 이것이 동일한 프로젝트 ID 임을 확인하는 것이다. 몇몇 lab에서는 실제로 여러 프로젝트 ID를 갖고 있으며, 심지어 사용자들 간에 특정 공유를 수행하거나, 권한을 추가 혹은 제거하는 등의 작업을 수행하는 경우 여러 사용자가 존재할 수도 있다. 이제 우리는 여기에 있는 사용자 이름이 실제 우리의 계정이 아니라는 것을 안다. 이것은 그저 Qwiklabs가 생성한 계정이다. 자신의 실제 계정을 사용하지 않도록 여기에 있는 자격 증명과 일치하는지 확인하는 것이 매우 중요하다. 이제 몇몇 lab에서는 구글 클라우드 프로젝트를 제공하는 Qwiklabs 내에서 우리의 작업을 추적한다. 이 기능이 활성화되면, Qwiklabs 창의 우측 상단 모서리에서 점수가 표시된다. 이제 그 점수는 우리가 목표를 달성할 때마다 늘어나며, 점수를 클릭하여 점수를 매기는 각각 단계를 볼 수도 있다. 그것들을 완료하면 점수가 업데이트된 것을 확인할 수 있고, end lab과 이어서 okay를 눌러 나갈 수 있다. 이제 우리는 피드백을 제공받을 수 있다. 우리가 한 번 end lab을 클릭하면, Qwiklabs에서 제공한 프로젝트와 해당 프로젝트 내의 리소스는 삭제될 것이다. 이제 Qwiklabs의 lab 페이지를 닫을 수 있다. 스크롤을 올리면 lab을 성공적으로 마쳤음을 알 수 있게 된다. 이 과정의 grades 섹션에 가면 이 lab에 대해 어떤 점수를 받았는지 확인할 수 있다.
그런데 실제 사용을 해보니, 나만 그런 건지는 모르겠으나 매우 속도가 느리고, 오류도 툭하면 발생했다. 클릭 하나하나 할 때마다 한 세월 잡아먹는다. 심지어 Bitnami package for LAMP는 한 20번을 클릭해도 도통 실행될 기미가 보이지 않고, 실패했다는 메세지만 떴다. 그러던 중 내 노트북이 문제인가 싶어서 PC 방로 향했다.
[3-7] 퀴즈
PC방에 오니 이렇게 빠른 것을.. 노트북이 오래된 친구라는 것을 내가 너무 간과했던 모양이다. 이걸로 3주차를 마친다.