블로그

일프로

[쿠버네티스] 컨테이너 한방 정리 #3

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy  기술의 흐름으로 이해하는 컨테이너 쿠버네티스는 이제 [컨테이너]랑 [가상화] 그리고 [데브옵스]속에 깊숙히 자리잡고 있습니다. 그래서 이 세 가지를 알아야 쿠버네티스를 더 잘 알 수 있게 되는데, 이 단어들은 정말 큰 개념이라서 그냥 용어 설명으로는 이해하기 힘들어요. 그래서 기술에 전반적인 배경을 이해하는 게 중요하다고 생각합니다.그래서 이번 강의는 [컨테이너 한방 정리]로, 쿠버네티스를 잘 이해하기 위해 컨테이너를 중심으로한 여러 배경 흐름 들을 이야기 해요. 1. Linux OS 흐름컨테이너를 잘 알기 위해서는 Linux에 대해서 먼저 알 필요가 있습니다. 최초에 OS로 unix가 있었고,  한참 시간이 지나고 linux가 나왔어요. 그리고 이 linux를 기반으로 현재까지도 엄청 많은 배포판들이 만들어지고 있습니다.하지만, 다행이도 우리는 이 두 가지 배포판만 알고 있어도 충분해요. debian이랑 redhat 계열인데, debian linux는 커뮤니티용이라고 해서 무료고요. redhat linux는 redhat 이라는 기업에서 만들었고, 유료에요.쿠버네티스를 설치할 때도 이렇게 이 두가지 배포판을 기준으로 설치 가이드를 제공합니다. 데비안과 레드햇 계열에 대한 자세한 얘기는 강의 중에 설명드리고, 여기선 기업용으로 쓰는 redhat에 대해 좀 얘기를 해볼께요. redhat에서 linux 배포판이 만들어지는 순서가 있어요. 최초에는 fedora linux라고 해서 새로운 기능을 개발하는 버전이 있고, 이건 무료고요. 이 기능들이 안정화되면 redhat linux로 이름을 바꿔서 릴리즈를 합니다. 기업은 이걸 설치하면 유지보수 비용을 내야되는 유료 버전이고, redhat enterprise linux 앞자만 따서 RHEL, 렐 이라고도 통상 불러요. 그래서 이걸로 기업들이 설치를 하면 유지보수 비용을 내야 되는 유료 버전 이고, 그리고 이걸 복사해서 만든 게 centOS 배포판 이예요. rhel이랑 똑같이 안정화 버전인데, 무료로 쓸 수 있습니다.기업에서는 주로 redhat 계열을 많이 쓰고, 특히 centOS의 점유율이 높은데 centOS 8은 2021년에 지원을 종료 했고, centOS 7은 2024년도에 지원이 종료가 되거든요. 이 centOS가 종료되는 배경을 좀 말씀을 드리면 시장 점유율이 ubuntu가 압도적이고. 다음은 centOS랑 debian이 2, 3위를 왔다갔다 해요. redhat은 2%지만, 이 수치가 그래도 기업 배포판 중에 1위고요. 이 1위가 된 배경에는 사람들한테 centOS를 무료로 쓰게 해주면서 자연스럽게 redhat을 선택하게 하는 그런 전략이 있었거든요. 근데 현재 redhat은 IBM에 인수가 된 상태예요. 그리고 IBM의 새로운 전략은 centOS에 점유율을 rhel로 당기려는거 같아요.왜나하면 현재 redhat 배포판을 만드는 순서가 이렇게 변경됐거든요.처음엔 마찬가지로 fedora를 통해서 기능 개발을 하고, centOS대신 centOS Stream이라고해서 이 기능들을 테스트하는 배포판이 생겼어요. 테스트 배포판(테스트베드)이라고 생각을 하면 되는데 여전히 무료지만, 이 배포판에서는 바이너리 호환성 보장 안될 수 있다는 얘기를 해요. 무슨 내용인지 몰라도 이제 쓰면 안되나 싶은 생각이 들죠?그리고 테스트 과정이 끝나면, 안정화 버전인 Redhat Linux가 됩니다. 이렇게 배포판을 만드는 프로세스가 바꿨어요. 그래서 기존에 centOS를 쓰던 기업들은 앞으로 고민을 좀 해봐야 되는 게 지금 상황이고요. 아래와 같이 4가지 방법이 있는데 아래와 같습니다.이렇게 4가지 선택지 중에 전 4번을 선택을 했고, 이 강의에 실습 환경으로 사용이 되요. 저도 어떤 linux를 선택할까 고민을 많이 했는데, 1, 2번은 기업의 상황이라 제외를 하고, 타 OS로 ubuntu를 고민을 하다가 그래도 제가 가장 오래 사용을 했고, 문제가 생겼을 때 잘 가이드를 해드릴 수 있어야 하니까 4번, 새로운 복제본을 선택을 했습니다.그리고 AlmaLinux와 RockyLinux 중에서 Rocky Linux를 선택한 이유는 아래와 같아요.구글 트렌드에서 키워드 검색량 확인 (link)CentOS 공동설립자 중 한명 만들었음 (link)클라우드 서비스에서 VM 생성을 Rocky Linux로 하는 사례들 확인Github Watch/Fork/Start 비교 (rocky link), (alma link)  2. Container 흐름자, 이제 컨테이너에 대해서 얘기를 해 볼꺼예요. 지금까지 봐듯이 linux는 꾸준히 발전을 했고, 내부적으로도 많은 코어 기술들이 개발이 됐는데 그중 하나가 격리 기술이예요.chroot라고 해서 사용자 격리를 시작으로 파일이나 네트워크를 분리하는 기술들이 만들어 졌고요. 한참 지난 후에 cgroup이라고해서 각각에 App마다 cpu나 memory를 할당을 할 수 있게 됐어요. namespace는 보통 App 하나가 하나의 프로세스를 차지하거든요. 이 프로세스를 격리 시켜주는 기술이 만들어 지면서 우리는 이제 각각의 App을 소위 말하는 [독립적인 환경]에서 실행을 시킬 수 있게 됩니다.그리고 다음으로 이 기술들을 집약해서 정리한게 LXC라고 해서 linux container에 줄임말 이예요. 이 컨테이너의 어머니이자, 최초의 컨테이너죠. 그리고 이 기술을 기반으로 만들어진 이번엔 컨테이너에 대명사죠. Docker, 요즘은 위세가 많이 죽긴 했어요. 이전까지 컨테이너 기술은 저 같은 평범한 개발자들이 쓰기엔 좀 어려웠다면 docker는 이걸 누구나 쓰기 쉬운 형태로 만들었습니다. 요즘 잘 정리된 블로그 몇 개만 봐도 대강 이해해서 내 OS에 컨테이너를 띄울 수 있죠.docker가 나오고 rkt라고 rocket이라는 컨테이너가 나와요. docker가 보안에 안 좋은 점이 좀 있는데, 이 부분을 공략을 하면서 더 안정적인 컨테이너를 강조를 했고 실제 docker보다 성능도 더 좋다고 해요. docker가 보안에 안 좋은 점은 root권한으로 설치하고 실행을 해야 되기 때문인데, 현재는 rootless 설치 모드가 생겨서 보안이 강화가 됐습니다.한편 쿠버네티스는 점점 표준으로 정착이 되고 있고, 현재는 컨테이너간의 싸움 중입니다. 초반에 docker가 보안에 약하다는 것 까지는 사실 docker 대세에 크게 문제가 없었거든요. 시간이 지나면 충분히 보완 될꺼라는 기대도 있었고 실제로 보완이 됐죠. 근데 docker 위세가 조금씩 꺽이기 시작한 이유가 뭐냐면, 쿠버네티스에서 docker가 빠진 다는 얘기가 계속 있었어서 그래요. 그 이유는 docker가 쿠버네티스와 인터페이스가 잘 안 맞아서 그렇거든요. 물론 처음엔 docker를 메인으로 쿠버네티스가 만들어졌죠. 근데 쿠버네티스가 표준화가 될 수록 docker가 걸림돌이 되고 있는 상황이예요. 이제 누가 쿠버네티스랑 호환성이 좋은지가 컨테이너를 선택하는 중요한 결정요소가 됐습니다.그 이후에 나온 대표적인 컨테이너가 containerd랑 cri-o고요. containerd는 docker에서 컨테이너를 만들어주는 기능이 분리된 거예요. docker가 설치할 땐 간단해 보여도 엄청 많은 기능들이 녹아진 엔진이거든요. 그 큰 엔진에서 containerd 프로젝트만 분리 되서 나왔고 CNCF에 기부 됩니다. 번외로, docker는 현재 mirantis라는 회사에 인수된 상태예요. docker를 정말 많이 쓰지만 기술 투자 대비해서 수익이 큰 편은 아니었던 거 같아요. 그래서 mirantis라는 회사에 인수가 됐고 이 mirantis는 openstack 프로젝트를 하고 있는 회사 거든요. 이 openstack이 뭐냐면, kubernetes 이전에, 가상화에 대세라고 하긴 좀 그렇고, 가장 큰 가능성으로 가상화 시장을 선도한게 openstack 이예요. 저도 개인적으로 한 3년 정도 openstack 관련된 일을 했었고, 그래서 다음 가상화를 설명하는 강의에서 최대한 재미있게 얘기를 해 드릴께요. 여튼 docker가 mirantis에 인수된 이후부터 이 kubernetes 인터페이스를 잘 맞추려고 하고 있기 때문에 쿠버네티스에서 docker는 빠지진 않게 됩니다. 3. Container Orchestration과 Container 흐름강의 영상에서 컨테이너 오케스트레이션(쿠버네티스)과 컨테이너(컨테이너 런타임) 간에 한 단계 더 깊은 흐름을 이야기 합니다.가장 핵심은 쿠버네티스의 kubelet 변화와 그리고 이에 따른 컨테이너 런타임들 간의 흐름이예요. 바로 CRI가 어떤 배경에서 만들어졌고, 쿠버네티스 버전이 올라가면서 CRI가 어떤 방향으로 바뀌는지, 그리고 그에 따른 컨테이너 런타임들 간의 변화를 설명드립니다. 그리고 컨테이너에서 절대 빼놓으면 안되는 OCI가 있습니다. 컨테이너 표준인데, 컨테이너 런타임들은 이걸 잘 지키고 있기 때문에, 우리는 런타임을 바꾸더라도 기존에 만들었던 이미지를 그대로 사용할 수 있어요  블로그는 여기까지고요. 강의가 오픈 되면 링크 걸어 놓을께요.좋은 하루되세요! 좋아요 ​♡는 저에게 큰 힘이 됩니다 :) 

데브옵스 · 인프라인프런쿠버네티스어나더클래스지상편일프로kubernetesdevopskubeopscontainer컨테이너한방정리

일프로

[kubernetes] 데브옵스 한방정리 #8

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 이번 블로그에서는 아래 DevOps를 구성하는 오픈소스들이라는 주제로 데브옵스를 설명을 드립니다. 내용의 수준은 비전공자가 데브옵스에 대한 전반적인 내용을 이해하기 좋은 정도인 점 참고 바래요.데브옵스를 구성하는 오픈소스들DevOps가 개발에서 운영까지 원할한 흐름을 만드는 건데, 중간에 가장 중요한 역할을 하는게 CI/CD죠. CI는 통합된 소스를 가지고 빌드/테스트를 자동화 시키는 기능을 만드는 거고, CD는 배포를 자동화 시키는 기능을 만드는 거예요.그래서 결국 개발을 해서 커밋을 하는 순간, 운영 환경에 App이 자동으로 배포가 되는 파이프라인이 만들어 지는데, 세부적으로 나누면 위 그림처럼 8가지 단계가 있습니다.계획/개발, 빌드/테스트, 릴리즈/배포, 그리고 운영/모니터링 인데, 이걸 각 단계를 대표적으로 사용하는 오픈소스를 가지고 얘기를 해보겠습니다.[계획] 단계부터 시작 할께요.제가 개발할 당시에는 redmine을 많이 쓰긴 했는데, 지금은 Jira나 notion을 많이 써요. 기능은 비슷한데, UI가 요즘 스타일로 많이 세련되 졌고요. 개발 일정을 공유하거나 이슈 사항들을 기록해야 되기 때문에 이런 툴을 사용하죠. 협업은 서로 메신저를 통해서 개발에 관련된 대화를 하는 걸 말하는데, 사실 카톡이나 사내 메신저를 써도 되는 부분이긴 하지만  그래도 슬렉을 쓰는 가장 큰 이유가 하나 있습니다. 그 이유는 가장 마지막에 설명 드릴께요. 다음으로 [개발]인데인텔리제이나, OpenJDK, 그리고 Spring Boot는 이전에 말씀 드렸고, 밑에 JUnit은 테스트 코드를 작성할 때 필요해요.보통 개발할때 if문 3~4개에 for문도 여러개 섞어서 복잡한 로직을 만들어 내죠. 이게 처음 만들 때는 집중해서 만들기 때문에 로직이 이해 되는데, 하루만 지나도 이 로직이 이해가 안되기 시작해요. 아무래 내가 짠 코드라도 다시 이해하는게 힘들어 지는데, 이럴때는 차라리 입력값을 넣어서 돌려보고, 결과값을 보는 게 로직을 이해하는 데 쉽거든요.그래서 바로 이런 테스트 코드를 만들어 놓는 게 좋고, 혹시라도 다른 사람이 이 로직을 수정하더라도, 테스트 코드를 돌려봐서 기대했던 값이 잘 나오면 안심을 할 수가 있죠. 그래서 코드를 개발할 때 조금만 고생해서 이렇게 테스트 코드도 같이 만들어 놓습니다. 다음으로 코드 분석 이라고 해서 FindBug나 PMD는 내가 짠 코드 패턴에 혹시 모를 버그가 있는지를 체크해줘요. 그래서 잘못된 로직을 짜지 않도록 도와주는데, 이런거 뿐만아니라 개발자간에 미리 코딩 스타일을 정해 놓거나, 개발 편의를 위해서 사용하는 툴 들은 엄청 많습니다. 다음으로 [빌드]를 볼께요.빌드 대상은 소스와 컨테이너고 Gradle과 도커가 사용됩니다. 소스 빌드로 현재 Maven보단 Gradle을 많이 쓰지만 저장소 자체는 메이븐 저장소에서 라이브러리를 가져 오는 거고요. 도커도 이전 [컨테이너 한방정리]에서 많이 얘기를 해서 이번엔 넘어 갈께요.  이제 다음으로 [테스트] 예요.테스트를 해야되는 요소에는 크게 3가지가 있는데, 기능이랑 성능 그리고 커버리지예요.각각 Junit, Jmeter, JACOCO라는 툴 들이 쓰이고. 각자 개발단계에서 테스트 코드를 만들고 실행을 해봤더라도 코드들이 병합되고 나서 또 다른 결과가 나올 수 있기 때문에, 빌드 단계에서 이 JUnit을 실행시켜서 자동으로 테스트를 한번 더 돌려 보는 거예요.그래서 위치는 이렇게 빌드에 연결되서 테스트가 같이 실행되는 거고, 테스트 이후에 Jacoco라는 툴을 돌리면 이 테스트를 돌렸을 때 사용된 로직들이, App 전체에서 어느정도 범위를 테스트 해본 건지, 커버리지를 결과를 알려줍니다.그래서 내가 돌려본 테스트 케이스들이 전체 로직에서 많은 부분을 차지할 수록, 이 App에 대한 신뢰도가 높다고 판단을 해요. 그리고 JMeter는 성능 테스트를 하는 툴 인데, 이건 자동화 기능은 아니고, 여기 개발환경이나 검증환경을 대상으로 진행 합니다. 통상 별도의 성능 테스트 전문 인력이 날잡아서 수동으로 진행하고요. 이제 다음으로 [릴리즈]와 [배포] 입니다.릴리즈는 배포 가능한 패키지를 만드는 과정이에요.도커 빌드를 하기 위해서는 Dockerfile이라는 스크립트를 작성해야 되고, 또 쿠버네티스에 배포를 하기 위해서 yaml 파일들을 사전에 만들어 놔야 되는데 이렇게 배포를 하기 위한 별도의 패키지를 만드는 게 릴리즈고, 이 파일들도 변경관리가 되야 하기 때문에 작성한 내용들을 이렇게 Github에 올려 놓습니다.그리고 배포할 때 사용을 하는데, 이 릴리즈와 이 배포 부분이 이번 Sprint2에서 다루게 될 주요 범위예요. 배포를 하기 위한 툴로는 대표적으로 kustomize와 helm 그리고 argoCD가 있고, 다 Sprint2 강의에서 배우게 됩니다. Sprint1 강의에서는 kubectl로 배포를 했지만, 이제 이런 도구들을 써서 쿠버네티스에 배포를 하게 되는 거죠. 이제 다음 단계로 [운영]입니다. 이건 실제 운영환경을 구성하는 요소와 툴 들이라고 보시면 되요. 여기서 Nginx와 Istio는 네트워크 트래픽 관리에 대한 도구고, 나머지 들은 [쿠버네티스 무겁게 설치하기]에서 나왔던 익숙한 그림일 거예요. 이외에도 운영을 구성하는 환경들은 다 표현하기 힘들 정도 많지만, 이정도로만 하고 이렇게 인프라 환경 안에서 설치되고, 운영자는 이 툴들이 정상적으로 잘 돌아가고 있는지 확인해야 하는 역할을 하죠.그리고 마지막으로 [모니터링]인데,모니터링 요소는 주로 자원 사용량이나 App로그 그리고 트래픽 흐름을 많이 봐요. Grafana 나 Loki 그리고 Prometheus는 Sprint1에서 사용을 해봤고. 이게 자원 사용량이랑 App로그를 보기 위한 툴이였죠?그리고 Jaeger랑 Zipkin은 트래픽 흐름을 보기 위한 도구예요. 이제 마이크로서비스 환경이 많아졌기 때문에 서비스들 간에 트래픽이 어떻게 흘러가는지 추적을 하는게 중요해 졌습니다. 그래서 이런 오픈소스들을 설치해야 되고위치는 운영과 똑같이 인프라 환경 내에 설치가 되요. 이 App들은 다 쿠버네티스 클러스터 위에서 Pod로 띄어 진다고 보시면 됩니다. 그럼 여기까지가 모니터링까지 다 설명을 드린거고,  아까 [Slack을 쓰는 이유]를 마지막에 말씀드린다고 했는데, 딴게 아니라 이렇게 연결되는 그림들이 있어야 되서 그래요. 이렇게 슬렉은 데브옵스에 중요 포인트 차지하고 있는 툴들이랑 연동이 할 수가 있거든요. 통상 메신저에는 개발자나, 데브옵스 엔지니어 혹은 운영자들이 모여 있는 방이 각각 있을 텐데, 슬렉을 쓰면 이 파이프라인에서 발생하는 알람들을 필요한 방에 울리도록 설정할 수가 있는거죠. 그래서 이게 협업을 위한 여러 메신저들 중에서, 그래도 슬렉을 쓰면 좋은 점 이었습니다. 자 그럼 여기까지가 데브옵스를 구성하는 오픈소스들에 대한 설명이였는데, 어떻게 데브옵스가 좀 실질적으로 와닿으시나요? 현재는 이렇게 데브옵스가 복잡해 졌습니다. 그래서 기업에서는 데브옵스 엔지니어를 별도로 뽑을 수 밖에 없는 거고요. 뭔가 많아 보이지만, 그래도 차근차근 하나씩 구성하다 보면 생각보다 금방 파이프라인이 만들어 지기도하고 여기 있는걸 한번에 다 만들 필요는 없어요. 배포를 한다고 처음부터 helm이나 argoCD를 적용할 필요는 없는 거고 Kubectl 배포부터 일단 연결을 해 놓은 다음에 하나씩 장비를 업그레이드 하는 마음으로 바꿔 나가면 되거든요.이번 강의도 그런 스탭으로 구성을 했으니까, 끝까지 잘 따라오시길 바라고요!아래 내용들은 강의에서 자세히 설명 드릴 내용들입니다. 쿠버네티스 어나더클래스 DevOps 전체 구성도 DevOps에서 가장 중요한 것 (개발->빌드->실행파일) DevOps에 엮인 IT 직군들 DevOps 외 다른 Ops들 ps. ♡ make me want to be a better man :)

데브옵스 · 인프라쿠버네티스어나더클래스지상편Sprint2일프로kubernetes데브옵스devops오픈소스

Inje Lee (소플)

인프런 단일 강의로 수강생 만 명을 넘기기까지 (6년간의 기록)

(이 글은 제 웹사이트에 작성한 글을 그대로 가져온 것입니다.)원문 링크: https://www.soaple.io/post/9/%EC%9D%B8%ED%94%84%EB%9F%B0%20%EB%8B%A8%EC%9D%BC%20%EA%B0%95%EC%9D%98%EB%A1%9C%20%EC%88%98%EA%B0%95%EC%83%9D%20%EB%A7%8C%20%EB%AA%85%EC%9D%84%20%EB%84%98%EA%B8%B0%EA%B8%B0%EA%B9%8C%EC%A7%80안녕하세요, 소플입니다.기존 티스토리 블로그를 제 웹사이트로 통합하고 처음으로 이렇게 글을 남기네요ㅎㅎ이번 글에서는 저에게는 꽤 의미있었던,인프런 단일 강의로 수강생 만 명을 넘기기까지 6년 동안의 과정을 한 번 적어보려고 합니다.글이 꽤 길지만 관심을 갖고 재미있게 읽어주셨으면 좋겠고,개발관련 강의 제작이나 소프트웨어 교육에 관심이 있는 분들에게 조금이라도 참고가 되길 바랍니다 😀 '소프트웨어 교육'이라는 꿈먼저 잠시 제 어릴 때 이야기를 해보려고 합니다.저는 어릴 때부터 컴퓨터에 관심이 많았고, 일찍부터 프로그래밍을 배우고 싶어했습니다.하지만 지방에 살았기 때문에 당시 다녔던 동네 컴퓨터 학원에서는 프로그래밍을 제대로 배울 수 없었습니다.학원에는 컴퓨터 자격증 반이 대부분이었고 프로그래밍을 배우려고 하는 학생이 거의 없었기 때문이죠.그래서 제대로 된 교육 과정도 없었고 가르쳐 줄 선생님도 턱없이 부족했습니다.저에게는 당시 배우고 싶었던 것을 배우지 못한 상실감이 꽤 컸습니다.그래서 제가 나중에 어른이 되면, 프로그래밍을 배우고 싶어하지만 여건이 안되는 학생들에게 양질의 소프트웨어 교육을 제공해주고 싶다는 생각을 하게 됐습니다.그렇게 시작된 생각은 저에게 소프트웨어 교육이라는 꿈을 갖게 만들었습니다.그리고 그 꿈은 점점 더 커져서 현재 제 인생의 최종 목표인 소프트웨어를 전문적으로 교육하는 학교를 설립하는 것이 되었습니다. 첫 오프라인 강의 (2017년, feat. Python)때는 바야흐로 2017년 말이었습니다.우연한 기회로 대전에서 3일 과정으로 파이썬 입문 강의를 하게 되었습니다.제 인생 첫 오프라인 강의였기 때문에 정말 두렵고 떨리는 마음으로 강의를 준비했습니다.그래서 아래와 같이 열심히 강의 자료를 만들었고, 저 때 지금의 제 강의 템플릿이 완성되었습니다.강의를 하기 전날 대전에 내려가서 숙소에서 계속해서 강의 연습을 했던게 아직도 기억납니다.강의 당일에는 너무 긴장해서 일찍 잠에서 깼고, 이른 시간에 강의장에 도착해서 기념 사진을 찍었습니다.당시 전체 수강생은 약 20명 정도였습니다.수강생중에는 흰 머리의 나이 지긋하신 아버님도 계셨고,재수를 해서 수능을 마치고 온 학생도 있었습니다.그렇게 제 인생의 첫 오프라인 강의를 시작하게 되었고,3일 동안 하루 8시간씩 정말 열심히 강의를 진행했던 기억이 납니다.강의가 끝나고 수강생 분들에게 메일로 실습 코드를 보내드렸는데,답장으로 좋은 말씀들을 너무 많이 해주셔서 정말 보람을 느꼈던 것 같습니다.그렇게 저는 교육이라는 것이 정말 보람찬 일이라는 것을 몸소 깨닫게 되었고,제 꿈에 더 확신을 가지게 되었습니다. 우연히 찾아온 기회 (2018년)2018년에는 제가 본격적으로 프리랜서 개발자로 활동하기 시작했습니다.프리랜서 프로젝트를 구하고 있던 와중에, 제가 병역특례를 했던 회사 대표님의 소개로 N사의 모바일 앱 개발 프로젝트를 수행하게 되었습니다.당시 N사의 CTO님과도 미팅을 할 기회가 생겼는데, 소프트웨어 교육이라는 공통 관심사로 많은 이야기를 나눌 수 있었습니다.그리고 CTO님께서는 구름 류성태 대표님을 소개해주셨습니다.소프트웨어 교육에 관심이 많으니 아마 서로 도움이 될 수 있을 거라고 하시면서 말이죠.그렇게 처음으로 구름과의 인연이 시작되었습니다.2018년 한 해 동안 저는 프리랜서 프로젝트를 주로 하면서,가끔 오프라인 강의도 하고 틈틈이 유튜브에 동영상 강의를 올리면서 보냈습니다.  첫 동영상 강의를 제작하다 (2019년, feat. 구름 에듀)당시 구름에서는 구름 에듀라는 강의 플랫폼을 만들어서 한창 키워나가고 있었습니다.강의 플랫폼의 초기에는 다양한 컨텐츠를 확보하는 것이 중요합니다.그래야 많은 사람들이 들어와서 강의도 듣고 결제도 할 것이기 때문이죠.그렇게 시간이 될 때 한 번씩 구름과 미팅을 하면서,먼저 AWS 강의와 리액트 강의를 제작해보기로 결정을 하게 되었습니다.AWS 강의는 기존에 제가 오프라인에서 강의를 할 때 만들어둔 자료가 있었기 때문에 그걸 사용해서 조금 빠르게 제작할 수 있었고,리액트 강의는 커리큘럼부터 강의자료까지 다 처음부터 만들어야 했습니다.기존에 유튜브 채널에 강의 동영상을 가끔 올리긴 했지만,제대로 된(?) 동영상 강의 제작은 처음이었기 때문에 설레기도 하고 걱정이 되기도 했습니다.당시 제가 프리랜서 프로젝트를 하느라 바빴기 때문에 남는 시간에 틈틈이 강의 내용을 구성했고,본격적인 강의 제작은 2019년 중순이 되어서야 할 수 있었습니다.그렇게 약 2달 동안 강의 자료를 만들고 녹음하고 편집하는 과정을 계속 반복했습니다.(참고로 제 모든 강의는 스튜디오가 아니라 조용한 시간에 집에서 녹음합니다🤣)그리고 2019년 6월, 구름 에듀에 제 인생 첫 동영상 강의인 처음 만난 AWS와 처음 만난 리액트가 출시되었습니다.보시는 것처럼 강의를 처음 출시 했을 때는 비싸진 않지만 유료로 판매했었습니다.플랫폼 입장에서 무료 컨텐츠는 초기에 사람들을 끌어모으는 역할은 하지만, 직접적인 수입원이 되지는 못합니다.그래서 결국은 컨텐츠를 유료로 판매해야 플랫폼은 수수료를 가져갈 수 있고, 강의자는 강의로 인한 수익을 창출하면서 공생할 수 있는 것이죠. 유료에서 무료로하지만 당시 저는 유료 강의에 대해 조금은 부정적인 생각을 갖고 있었습니다.어릴 때의 제 모습을 계속 떠올리면서, 어린 친구들이나 학생들은 돈이 별로 없기 때문에 단돈 1~2만원의 강의료도 부담이 될 것이라고 생각했기 때문입니다.또한 저 스스로도 아직 강의 컨텐츠에 대해서 돈을 받고 팔 정도의 자신은 없었습니다.수강생과 입장을 바꿔서 '내가 학생이라면 이 정도 강의를 이만큼의 돈을 내고 들을 것인가?' 라고 생각해봤을 때,당시 제 마음속의 대답은 '아니요' 였습니다.그래서 유료 강의를 출시한 이후에도 계속 저런 생각들이 들었고,고민 끝에 구름측에 양해를 구하고 강의를 무료로 전환하게 되었습니다.많지는 않았지만 당시에 무료로 전환하기 전까지 강의를 구매해주신 분들이 계셨습니다.규정상 따로 환불을 해드리지는 못했는데, 만약 이 글을 보고 계신다면 제 메일(inje@soaple.io)로 연락을 주시기 바랍니다.늦었지만 제 인프런 강의를 무료로 수강하실 수 있도록 쿠폰을 보내드리겠습니다🥹그렇게 구름 에듀에 출시한 강의를 모두 무료로 전환하고나니 몇 가지 변화가 생겼습니다.먼저 구름에서 주최하는 개발 프로그램에 참여하는 분들에게 제 강의를 무료로 제공할 수 있게 되었습니다.그리고 그런 프로그램에 참여하는 분들을 포함해서 수강생이 빠르게 늘기 시작했습니다.수강생이 늘면서 강의에 대한 평가도 늘기 시작했고,그 과정에서 강의에 대한 수강생 분들의 긍정적인 피드백을 받으면서 저도 힘을 받을 수 있었습니다.그렇게 시간이 흘러 현재까지 구름 에듀에서 처음 만난 AWS 1,233명, 처음 만난 리액트(v1) 2,040명, 처음 만난 리액트(v2) 328명의 누적 수강생을 달성할 수 있었습니다. 영어로 만들어서 달러를 벌어보자 (2020년, feat. Udemy)수강생도 꽤 늘어나고 강의에 대한 긍정적인 평가들을 받다보니 제 강의에 대해 조금 자신감이 생겼습니다.그리고 저도 지속적으로 강의를 제작하기 위해서는 강의로 수익을 창출하는 것이 필요하다는 생각을 하게 되었습니다.하지만 그때까지도 한국에서 유료 강의를 판매하는 것에 대해서는 제 마음이 내키지 않았고,영문판을 제작해서 유데미(Udemy)에 올려보면 어떨까? 라는 생각을 하게 되었습니다.당시 유데미는 영어로 된 강의가 대부분인 전세계를 대표하는 강의 플랫폼이었기 때문에,인기 강의의 수강생 수나 매출이 한국 플랫폼들과는 비교도 안 될 정도로 컸습니다.그래서 제 강의가 아주 조금만 어필이 되어도 꽤 큰 돈을 벌 수 있을 것이라고 생각했습니다.그렇게 달러를 벌어들이는 꿈을 꾸며 처음 만난 리액트 강의의 영문판을 제작하기 시작했습니다.영문판을 제작하면서 가장 힘들었던 점은 역시 언어의 장벽이었습니다.한글로는 쉽게 설명할 수 있는 부분들을 영어로는 어떻게 설명해야 할지 몰라서 참 어려웠던 것 같습니다.그래서 번역기와 영어권에서 많이 사용하는 표현들을 찾아가며 꽤 오랜 기간에 걸쳐 강의를 완성했습니다.그리고 2020년 7월, 유데미에 처음 만난 리액트의 영문판인 First met React 강의가 출시되었습니다.(당시 유데미에 출시된 강의 이미지를 분명 캡처해뒀는데 못찾겠네요ㅠ)강의를 출시하고 처음에 수강생을 모으기 위해 레딧에 홍보를 해보기로 했습니다.그래서 레딧의 리액트 서브레딧에 3일 동안만 등록 가능한 무료 쿠폰을 뿌렸습니다.그랬더니 운좋게 아래와 같이 Upvote를 많이 받아서 Hot에 올라가게 되었습니다.그렇게 레딧 홍보를 통해 초기 수강생을 꽤 모을 수 있었습니다.하지만 무료 쿠폰으로 등록한 수강생들이 대부분이었기 때문에 수익은 거의 없었습니다 😂그러다가 어느 날 자려고 누워서 유데미 수강생을 확인하는데, 갑자기 새로고침 할 때마다 수강생이 50~70명씩 늘어났습니다ㄷㄷ그래서 깜짝 놀라서 이게 도대체 무슨 일인지 확인해봤더니, 인도에서 수강생들이 엄청나게 몰려오고 있었습니다.누군가가 인도의 유데미 무료 쿠폰 코드를 공유하는 사이트에 제가 레딧에 올린 쿠폰 코드를 올린 것이었습니다.그렇게 강의가 출시된 7월에만 6,243명이 등록했는데,그들은 대부분 무료 쿠폰을 통해 유입된 수강생이었고 인도 사람들이 아주 큰 비중을 차지하고 있었습니다.아래 그림에서 인도에 그려진 큰 원이 보이시나요?ㅎㅎ이후로는 거의 수강생이 늘지 않았고 가끔씩 유료로 강의를 구매하는 수강생들이 있긴 했지만 절대적인 수는 얼마 되지 않았습니다.이후 한 동안 강의를 관리하지 못했더니 약 2년 전쯤 강의가 내려가게 되었고,누적 수강생 7,434명과 누적 수익 $46.18를 끝으로 달러를 벌기 위한 여정이 마무리 되었습니다. 처음으로 개발 서적을 집필하다 (2021년, feat. 한빛미디어)유데미에서의 뼈아픈 실패(?)를 경험하고, 2021년에 저는 1인 법인을 설립하게 됩니다.소프트웨어 교육과 관련된 활동을 꾸준히 해왔지만 그게 저의 본업은 아니었습니다.본업은 프리랜서 개발을 하면서 동시에 저만의 서비스를 개발하는 것이었죠.개인사업자로 4년 동안 프리랜서 개발을 해왔었는데, 2021년에 여러가지 상황이 겹치면서 법인을 설립하게 되었습니다.법인은 소프트웨어 교육과 관련된 것은 아니었고, 온전히 저만의 서비스를 위한 것이었습니다.(이 부분도 스토리가 길어서 기회가 된다면 나중에 다른 글에서 다뤄보도록 하겠습니다😃)법인을 설립하고 정신없이 서비스를 개발하던 중에 아래와 같이 출판사로부터 메일을 받게 되었습니다.당시 구름 에듀에 있던 제 리액트 강의를 꽤 많은 분들이 수강해주셨는데,출판사에서도 제 강의에 관심을 가지고 연락을 주신 것이었습니다.메일을 받고 나서 저는 정말 큰 고민에 빠졌습니다.개발자로서 개발 서적을 집필하는 것은 제가 언젠가는 꼭 이뤄보고 싶은 일 중에 하나였기 때문에 설레기도 했지만,법인을 설립하고 본격적으로 판을 벌려놓은 상태라서 '과연 책을 집필할 시간이 될까?'라는 고민이 들었습니다.당시 제가 책을 집필해본 적은 없었지만, 주변에서 책을 쓰는게 정말 힘들고 고통스럽다는 이야기들을 꽤 많이 들어왔기 때문에 더 고민을 했던 것 같습니다.하지만 정말 좋은 기회라는 생각이 계속 들었고, 처음 만난 리액트는 이미 강의로 제작되어 있는 상태였기 때문에 '책을 집필하는 과정도 조금은 수월하지 않을까?'라는 무식한(?) 생각으로 출판사와 계약을 하게 되었습니다.그렇게 1년 동안 개발도 하면서 틈틈이 책을 썼는데, 강의 컨텐츠가 어느정도 있었지만 책을 쓰는 과정은 전혀 수월하지 않았습니다😂마지막에는 정말 남은 힘을 다해서 꾸역꾸역 한 글자 한 글자씩 써내려갔던 것 같습니다.그렇게 해서 2022년 5월에, 소문난 명강의 시리즈로 소플의 처음 만난 리액트가 출간되었습니다.약 1년 동안 책을 집필하면서 느낀 점은,정말 힘든 과정이라는 것과 스스로 동기부여가 되어야만 할 수 있는 일이라는 것입니다.사실 개발 서적은 트렌드도 빨리 바뀌고 독자층도 한정되어 있기 때문에 책으로 인해 큰 수입을 얻기는 어렵습니다.하지만 저자의 이름을 알리거나 오프라인/온라인 강의를 하는 경우에는 꽤 도움이 되는 것 같습니다.그만큼 책을 출간한다는 것 자체가 스스로에게 큰 동기부여가 되지 않으면, 다른 데서 집필을 무사히 마칠 정도의 동기를 얻기가 어렵습니다.그래도 저는 오래 전부터 제가 꼭 이루고 싶은 일 중에 하나였기 때문에 무사히 책을 집필할 수 있었던 것 같습니다.그렇게 출간된 제 책은 나름대로 자리를 잘 잡고 꾸준히 판매가 되었습니다.처음에는 1쇄만이라도 다 팔려서 재고는 안 남았으면 좋겠다고 생각했는데,출간된 지 1년 반이 지난 현재 3쇄까지 거의 다 판매되었고 현재 개정판 출간을 앞두고 있습니다. 드디어 인프런에 첫 강의를 업로드하다 (2022년, feat. 인프런)제 책은 이미 강의로 제작된 내용을 기반으로 하는 책이었기 때문에,처음 출판사와 계약을 할 때부터 책이 출간되는 시점에 맞춰서 강의도 새롭게 리뉴얼 하는 것으로 정했었습니다.그래서 책을 거의 다 집필한 시점에 처음 만난 리액트 v2 강의를 제작하기 시작했습니다.기존 강의가 2019년에 제작되었기 때문에 그 사이 리액트에도 많은 변화가 생겼습니다.클래스 컴포넌트를 주로 사용하던 방식에서 훅과 함께 함수 컴포넌트를 사용하는 방식이 사실상 표준으로 자리잡게 되었습니다.그래서 새로운 버전의 강의에서는 기존 강의의 내용을 업데이트 하는 것과 동시에 책에 들어간 내용과 동일하게 새로운 내용들도 추가하게 되었습니다.그리고 제가 말하는 속도가 느린편이라서 강의가 졸리다는 의견도 꽤 있었기 때문에,새로운 버전에서는 말을 의도적으로 빠르게 하게 되었습니다🤣(지금 강의 속도가 조금 빠르다고 느끼는 분들도 간혹 계시지만 대부분 만족하시는 것 같습니다ㅎㅎ)그렇게 열심히 새로운 버전의 처음 만난 리액트 강의를 제작하게 되었고,구름 에듀, 인프런, 유튜브 등에 모두 업로드 하게 되었습니다.특히 제가 인프런에는 강의를 처음으로 올리는 것이었는데,강의를 올리면서 '드디어 이제서야 인프런에 강의를 올리는구나.' 라는 생각을 하게 됐습니다.왜냐하면 과거에 인프런에서 저에게 먼저 강의 제작을 제안한 적이 있었기 때문입니다.당시 인프런도 본격적인 성장세를 타고 있었던 시점이라 아마 다양한 강의 컨텐츠들이 필요했을 겁니다.그래서 저에게 처음에 리액트를 주제로 유료 강의 제작을 제안해주셨는데,그때까지도 저는 한국에서 유료 강의를 출시하는 것에 대해 마음의 결정을 내리지 못한 상태였습니다.그래서 MD님께 그러한 제 가치관에 대해서 잘 말씀드리고,향후 기회가 된다면 무료 강의를 제작해보겠다로 말씀드렸습니다.그리고 당시 위 이메일 내용처럼 지식공유자 신청만 미리 해두었습니다.그렇게 시간이 흐르고 흘러 2년 가까이 지나서야 인프런에 첫 강의를 출시하게 된 것이죠.어찌됐든 늦었지만 인프런과의 약속은 지켰다고 생각합니다😀그렇게 인프런에 강의를 출시하고 메인 페이지에 꽤 여러번 노출이 되었습니다.그 덕분에 수강생 수도 굉장히 빠르게 증가하였고, 2022년 말에는 아낌없이 주는 나무상까지 수상하게 되었습니다.제 리액트 강의가 2022년에 수강신청 수가 가장 많은 무료 강의였다고 합니다.그렇게 책도 출간하고 강의도 많은 분들에게 사랑을 받으면서 정말 뿌듯하게 2022년을 마무리했던 기억이 납니다. 수강생 10,000명을 달성하다 (2023년, 현재)어느덧 시간이 흘러 인프런에 리액트 강의를 출시한지 거의 1년 반이 다 되었습니다.그 사이 제 책과 강의는 더 많은 분들에게 관심을 받게 되었습니다.그래서인지 구글과 네이버에서 '리액트 강의'라고 검색하면 제 강의가 가장 먼저 나오게 되었습니다.그리고 강의 컨텐츠가 여기저기 수출(?)되기 시작했습니다.특히 프론트엔드 개발에 입문하는 분들이 제 리액트 강의를 학습하면서 개인 블로그에 많이 정리하셨던 것 같습니다.(붕어빵 그림은 제가 정말 한땀한땀 그렸는데 수출되어서 뿌듯하네요ㅎㅎ)아무튼 그렇게 책을 통해서도 제 강의를 접하고 검색을 통해서도 제 강의를 접하는 분들이 늘어나면서,최근에 드디어 단일 강의로 수강생 10,000명을 달성하게 되었습니다 🎉당시 스스로 기념하기 위해서 화면을 캡처해두었습니다 😎어떤 분들에게는 별거 아닐 수도 있지만,저에게는 첫 오프라인 강의를 시작하고 지난 6년 동안의 노력이 점점 결실을 맺어가는 것 같아서 굉장히 큰 의미가 있었습니다.그리고 많은 수강생 분들께서 남겨주신 소중한 수강평 또한 큰 힘이 되었습니다.이 글을 통해서 수강생 분들에게 다시 한 번 감사의 말씀을 전합니다!😀(정말 재미있게 리뷰를 남겨주신 휴식중인 오리님ㅎㅎ 혹시 휴식 끝나셨나요?) 유료 강의를 출시하다책도 어느 정도 팔리고 무료 강의로도 꽤 많은 수강생을 달성하고 나니,제 강의 컨텐츠에 대한 자신감이 어느정도 생기게 되었습니다.그리고 무료 강의를 운영하면서 느꼈던 여러가지 장단점으로 인해,올해에는 유료 강의를 한 번 출시해보기로 결정했습니다.그래서 현재 처음 만난 리덕스와 엊그제 공개 된 따끈따끈한 처음 만난 AWS까지 총 2개의 유료 강의를 제작하게 되었습니다.강의가 아주 많이 판매되지는 않고 있지만,구매해주시는 분들이 있다는 사실에 감사함과 뿌듯함을 동시에 느끼고 있습니다 😀 강의를 제작하면서 얻은 것들이렇게 지난 6년 동안의 이야기를 한 번 정리해보았습니다.저는 교육에 꿈이 있었기 때문에 시작한 것이지만,전체 개발자 분들 중에서 교육에 관심을 갖고 뛰어드는 비율은 현저하게 낮은 것 같습니다.회사일만 제대로 하기에도 바쁘기도 하고, 강의를 제작하는 것이 생각보다 어렵고 시간이 많이 걸리기 때문입니다.제가 강의를 제작하면서 얻은 것들은 다음과 같습니다.흩어져 있던 지식들을 체계화 할 수 있는 기회헷갈렸던 개발 관련 지식을 다시 한 번 복습하며 이해할 수 있는 기회코드 리뷰를 하거나 다른 개발자에게 설명을 할 때 더 쉽게 설명할 수 있게 됨돈으로는 살 수 없는 아주 큰 보람과 성취감저는 기억력이 그리 좋지 않아서 정리를 하면서 지식을 익히는 타입인데,그래서인지 강의를 제작하는 과정이 저에게는 개발 지식을 습득하는데 큰 도움이 되었던 것 같습니다.앞으로 강의를 제작할 계획이 있거나 소프트웨어 교육에 관심이 있는 분들은 참고하셨으면 좋겠습니다😀 앞으로의 계획 (2024년 ~)이제 2023년이 2달도 채 남지 않았습니다.저는 내년 계획을 아직 제대로 세우진 않았지만,아마도 새로운 강의를 적어도 하나 정도는 제작하고 오프라인 강의도 한 번은 하지 않을까 싶습니다.그리고 무엇보다도 제가 개발하고 있는 서비스가 어느정도 자리를 잡았으면 좋겠네요ㅎㅎ여러분들도 내년에 어떤 걸 공부하고 어떻게 성장할 것인지,어떤 새로운 일들을 해볼지 지금부터 계획을 세워보시면 좋을 것 같습니다!👏긴 글을 모두 읽어주셔서 감사드리며, 마지막으로 강의 쿠폰과 약간의 홍보를 하면서 마무리 짓겠습니다ㅎㅎ 광고 (AD)강의 50% 할인 쿠폰 (~ 2023년 12월 31일 까지만 유효)처음 만난 리덕스 🔗쿠폰 코드: 13533-912257c568a9처음 만난 AWS 🔗쿠폰 코드: 13534-3be05f545ba4소플이 만든 프론트엔드 지식 포털 FrontOverflow 🔗소플 웹사이트 🔗 그리고 개발 공부를 하고 싶지만 어려운 환경에 있는 분들은,주저하지 마시고 언제든지 아래 제 이메일 주소로 연락주세요.제가 도움을 드릴 수 있는 부분이 있다면 적극적으로 도와드리겠습니다! 😀inje@soaple.io

기타인프런지식공유10K강의리액트소프트웨어교육

일프로

[kubernetes] 손쉽게 데브옵스 환경을 구축하는 방법 #9

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 이번 강의에서 손쉽게 데브옵스 환경을 구축하는 방법으로 CI/CD 서버를 만들어 볼 건데, 먼저 간략하게 Sprint 2 범위에 실습 환경에 대해서 설명을 드릴께요.[지상편] 실습 환경 (전체범위)[지상편] 최종 실습환경 구성은 여기 보이는 환경들을 모두 설치하는 건데, 각 Sprint 마다 하나씩 환경을 구성해요. 이런 흐름이 내 PC에서 모두 이뤄지는 거고 Sprint1 때는 CI/CD환경이 없기 때문에 인프라 환경만 구성해서, 아래와 같이 실습을 해봤었죠?이제 Sprint2에서 CI/CD 환경을 구성 할 건데, Sprint2 환경 구성 범위먼저 인프라 환경때와 마찬가지로, Virtualbox랑 Vagrant를 이용하면, Guest OS가 만들어 지고, 스크립트를 통해서 이런 프로그램들이 모두 설치 됩니다. 뒤에서 설치 내용은 자세히 설명 드릴 거고요.설치가 다 완료 됐으면, 이제 내 PC에 브라우저에서 Jenkins dashboard를 접속을 할 수가 있게 되요. 그래서 빌드를 실행하면, 저에 Github에서 소스를 다운받아서 빌드가 실행 됩니다. 이 소스는 Sprint1에서 제가 실습을 위해서 만들었던 App에 소스고요.다음으로 컨테이너 빌드를 하면, 소스빌드를 해서 만들어진 Jar 파일이 사용되서 컨테이너 이미지가 만들어지고 Dockerhub로 업로드를 하게 되는데, 직접 도커허브에 가입해서, 내 도커 저장소에 이미지를 올릴 거예요. 그래서 지금까지 이렇게 제 도커 허브 username이 들어간 이미지를 사용했다면, 이제부터 자신이 가입한 username 으로 이미지 이름이 변경됩니다.그리고 도커빌드를 할때 필요한 도커파일이랑 배포를 할때 필요한 yaml 파일들을 저장할 용도로 Github가 필요한데, 기존에 있으신 분들은 그대로 쓰시면 되고요. 없으신 분들은 여기도 가입을 하셔야 되요. 그래서 컨테이너 빌드나 배포를 하면, 제 Github가 아닌, 본인에 Github에서 릴리즈 파일들을 다운 받아서 배포를 하게 되는데여기서 중요한건, 이 배포되는 yaml 파일에 들어가는 image 명에 내 도커허브 username이 있어야 여기서 이미지를 가져 올수 있어요. 이게 이번 Sprint2에 실습 구성과 진행 흐름인데 만약에 좀 헷갈려도 걱정하지 마세요. 한번 더 설명 드릴 꺼에요.단계별 설치 시작먼저 Sprint1에서 했던 것 처럼, 제가 올려놓은 Vagrant 설치 스크립트를 실행하면, 이렇게 CI/CD  서버가 한번에 구성되는데, 이 설치 스크립트에서 일어나는 일을 설명 드릴께요.Vagrantfile로 설치되는 내용먼저, 자원 할당을 보면, CPU 2 core에 Memory 2Gi, Disk 30기가를 줬어요. 그리고 Sprint2 부터는 실습할 때 이 두 환경이 모두 띄어져 있어야 되니까. 내 pc에 자원이 충분한지 확인을 해보시고요.그리고 네트워크 설정을 보시면, IP는 인프라 환경이 30번이었고, CI/CD 서버는 20번 이예요. Host-Only Network는  VM간에 통신을 하거나 내 호스트 PC에서 VM을 접속하기 위한 네트워크라서 IP가 같으면 안되고 근데 이 네트워크는 외부 인터넷에 접속은 안되거든요.그래서 NAT를 추가로 쓰는거고, IP는 자동할당  되는데, 이 IP가 인프라 환경이랑 같지만 인터넷만 쓰기 위한 용도라 문제는 안됩니다.다음으로 여기서 부터가 본격적으로 설치 스크립트에 해당하는 부분인데, 첫번째로 리눅스 기본 설정에 대한 내용들이고 이건 인프라 환경에 쿠버네티스를 설치할 때도 했던 내용이예요.그리고 kubectl을 설치 합니다. 이건 젠킨스에서 배포할때 쓸 용도고여 NAT를 설정해놨기 때문에 이렇게 외부 저장소에서 이 kubectl 패키지를 다운 받아서 설치할 수 있는 거죠. 그리고 마찬가지로 Docker 설치가 있어요. 이걸로 젠킨스에서 컨테이너 빌드를 하고, dockerhub로 이미지를 올리게 되고 다음으로 소스 빌드를 해야되니까 OpenJdk랑 Gradle 설치가 있습니다.그리고 Git도 설치를 해서, 빌드에 쓸 소스 코드랑  릴리즈 파일들을 가져와요.마지막으로 Jenkins를 설치하는데, 이때 OpenJDK를 11 버전으로 하나더 설치해요. 그 이유는 젠킨스가 11버전에 돌아가기 때문에 Jenkins 설치용으로 필요한거고 이건 제가 만든 소스코드가 17버전으로 만들었기 때문에 소스코드 빌드용으로 필요한 거에요. 다시 여길로 돌아와서, 이렇게 Vagrant로 CI/CD 서버가 만들어 졌으면 원격접속 툴로 접속을 해놓고요.그리고 이제 Jenkins 대시보드에도 접속해볼 수 있는데, 여기에 접속하면 최초 젠킨스 초기 세팅을 한번 하게되요. 사용자 생성하고 권장 플러그인들을 다운받는 그런 과정들이 있고 다음으로 전역 설정이라는 걸 하는데, 이게 뭐냐면 이 직접 설치한 버전에 Gradle이랑 OpenJdk를 젠킨스에서 빌드를 할 때 사용하겠다고 등록 하는거예요. 그리고 다음으로 이제 자신에 dockerhub를 써야 되니까 도커허브에 가입하는 단계가 있고요.다음으로 dockerhub 사용 설정이라고 해서, 두 가지가 있는데 첫 번째는 내 CI/CD 서버에서 내 도커허브로 이미지를 올릴 수 있도록 로그인을 해 놓는 거랑 두 번째로 젠킨스에서 docker를 사용할 수 있도록 권한을 부여 해야 합니다.그리고 다음으로 인프라 환경에 있는 인증서를 이 CI/CD 환경에 복사 해줘야 돼요. 그래야 젠킨스에서 kubectl로 배포를 할 때 쿠버네티스에 API를 날릴 수 있습니다.그리고 다음으로 내 Github에 가입을 하고, 설정이 있는데, 설정이 뭐냐면, 제 Github에 Dockerfile이랑 yaml파일들이 있거든요. 이걸 본인이 가입한 Github로 복사해 가는거예요. 그리고 복사하면, Deployment 파일 image 부분에 제 Dockerhub username이 있을 텐데, 이 부분을 수정하는 내용이 있고.마지막으로 젠킨스에서 빌드/배포를 하기위한 프로젝트 설정이 있습니다. 실행버튼을 누르게 되면 쿠버네티스에서 리소스가 생성되고요. 그중에서 Pod를 만들 때 이미지는 이젠 내 도커허브에서 가져가는 거죠.그래서 이렇게가 전체적인 설치 순서고, 이제 두번 정도 설명드릴 셈인데, 어떻게 이해가 잘 되셔나요?뭔가 많아 보일 수는 있는데, 제가 까페에 올려놓는 설치 가이드를 따라하다보면 정말 금방이고 근데 이것도 CI/CD가 흘러가기 위한 최소한에 기능만 쓴거에요. 이 흐름을 시작으로 배포강의가 진행되면서 점점 더 고도화가 됩니다.아래 자세한 설치 가이드가 있는 링크를 걸어 놓을께요.https://cafe.naver.com/kubeops/84만약, 해당 내용으로 설치가 힘드시다면 제 강의에서 설치 실습 영상을 추천 드립니다 :) ps. ♡ make me want to be a better man :)

데브옵스 · 인프라쿠버네티스어나더클래스지상편Sprint2일프로kubernetes데브옵스인프런devopsjenkins

인프런 셰리

인프런 유저는 어떤 사람들일까? 직접 만나봤습니다 🏃

인프런 유저가 벌써 120만 명을 앞두고 있습니다! 👏인프런은 항상 여러분들이 어떤 사람인지, 인프런을 어떻게 이용하고 있는지 항상 궁금했는데요.그래서! 여러분의 서비스 경험을 책임지는 CX 파트에서 인프런을 가장 꾸준히, 활발하게 이용하시는 유저 186분을 만나봤습니다.오늘은 그중 재밌는 내용 몇 가지를 여러분께 소개해 드릴게요. 🙂간단 요약! 인프런 유저 특징 인프런에서 가장 만족하는 부분1) 강의 2) 기능 (질문 & 답변 게시판 / 로드맵)질문 & 답변 게시판은 강의 수강생 누구나 지식공유자에게 질문을 남길 수 있는 게시판입니다. 서비스 상단 [커뮤니티]를 통하거나, 수강 중인 강의 페이지의 [커뮤니티]를 통해 진입할 수 있어요. 강의 수강 중 이해가 안 되는 부분이 생겼을 때, 질문 & 답변 게시판을 적극적으로 활용해 보세요! 실제로 입문자 혹은 독학하시는 분들이 많은 도움을 받은 기능이라고 합니다.질문 & 답변 게시판 구경하기 >>로드맵은 다양한 강의를 엮어 이상적인 학습 순서를 제안하는 기능입니다. 지식공유자 혹은 인프런이 직접 제작하는 로드맵은 학습의 방향성을 확인할 수 있다는 점에서 인프러너분들의 만족도가 높았다고 해요. 로드맵에만 쓸 수 있는 할인 쿠폰도 있답니다!로드맵 구경하기 >>CX 파트에서는 인터뷰를 통해 유저분들의 생각을 직접 들어볼 수 있어 의미 있었다고 말씀해 주셨는데요.인프런을 꾸준히, 열심히 이용해 주신 유저분들을 직접 인터뷰한 CX 파트의 간단한 소감을 들어볼까요? 💌 인프런을 열심히 그리고 꾸준히 이용하시고 애정해 주시는 유저들을 직접 만나보니 서비스 운영자로서 뿌듯함을 많이 느꼈고, 앞으로 인프런을 더 성장시키는 방향성을 알 수 있는 계기가 되었어요.특히나 평소 CS 업무를 하다 보면 불편하거나 아쉬운 부분에 대한 VOC를 많이 듣는 편인데, 이번 유저 인터뷰에선 전반적으로 서비스를 매우 만족스러워하시는 분들의 의견을 듣다 보니 서비스에 대한 중립적인 시야를 가질 수 있게 되었고요.또, 유저분들과 직접 많은 이야기들을 나누다 보니 콘텐츠, 기능 개선 등 인프런이 앞으로 나아가야 할 방향에 대해 더 구체적으로 고민해 볼 수 있는 시간이 되었던 것 같습니다.유저분들이 저희 서비스에 보여주신 애정과 관심만큼 앞으로도 인프런에서 유익한 시간을 보내실 수 있도록 노력하겠습니다. 앞으로도 인프런 서비스에 많은 사랑 부탁드립니다. 감사합니다 🥰 앞으로도 인프런 기능이나 강의 관련해서 새로운 제안이나 요청 사항이 있으시다면 언제든 알려주세요. 인프런은 여러분의 소중한 의견을 귀 기울여 듣겠습니다.인프런에 바란다 >>

인프런인프러너유저강의지식공유자로드맵질문답변

일프로

[쿠버네티스 어나더클래스] 배포를 시작하기 전에 반드시 알아야 할 것들 #10

Sprint2 추가 강의가 업로드 됐어요! (https://inf.run/NzKy)이번 강의에서는 배포를 하기전에 반드시 알아야 될 것들 이라는 주제로 설명을 드릴 건데, 배포에 관련된 툴 공부를 바로 시작하는 것보단, 어떤 걸 써야 되는지, 왜 써야 되는지를 아는 게 더 중요하다고 생각해서 준비한 강의 입니다.저는 예전에 최신 솔루션을 많이 알고, 신규 업데이트 된 기능을 빨리 쓰는 사람이 능력 있어 보였고, 저도 그렇게 되고 싶었는데 여러 프로젝트를 해보니 프로젝트 상황에 따라 적합한 기술을 쓰는 게 더 중요하더라고요. 신규 기술이라고 빨리 도입했다가 레퍼런스가 별로 없어서 프로젝트 내내 구글링하고 이슈 수정 요청을 하느라 고생했던 적도 있고, 원대한 포부를 가지고 한번에 많은 툴 들을 적용 하려고 했다가, 운영이 시작되면서 예상하지 못한 문제 때문에 장애처리에 시달리는 경험도 해보면서 진취적인 성향에서 일을 단계적으로 하려는 성향으로 바꼈는데, 결국 이렇게 일을 하는 게 월급을 높이는데도 효과가 더 좋았다고 말씀드릴 수 있습니다.부디 적재적소에 맞는 도구를 사용할 줄 아는 사람이 되길 바라면서 이번 블로그도 시작해 볼께요. CI/CD 파이프라인을 구성할 때 고려해야 하는 요소첫번째로, 파이프라인을 구성 할 때 [관리 담당]에 대한 부분을 고려해야 합니다.이 그림상으로만 보면 굳이 작업을 분리할 필요가 없이 젠킨스 파이프라인을 쓰는게 깔끔해 보이죠? 수정할 일이 생겼을 때, 세 군데 들어가서 보는 것보다 한 곳에서 보는 게 편하기도 하고요. 그래서 일반적으로는 젠킨스 파이프 라인을 선택하는 게 기능적으로는 좋다고 볼 수 있습니다.근데, 실무에서 일하다 보면 기능적인 구분 보다 보다 담당하는 사람에 따라 구성을 분리를 하는 게 좋을 때도 많아요. 각각 역할을 구성하는 관리 담당자가 다를 수가 있거든요. 실제 프로젝트에서는 기능이 만들어져 있고, 그에 따라 담당자를 정하는 게 아니고, 담당자가 먼저 정해지고, 함께 기능을 만들어가기 때문에 그래요.그리고 내가 이런 큰 그림을 그리는 위치라면, 기능보다 이렇게 관리 담당자 별로 구성을 나누는 게 업무 분장 측면이나 관리 책임적으로 더 효율적입니다.그래서 배포 파이프라인을 구성할 때, 기능적인 측면과 관리적인 측면을 고려해서 현재 뭘 중시하는 게 효율적인 지를 고민해 볼 필요가 있는 요소에요. 다음으로 [운영정책]인데, 젠킨스에서는 소스 빌드랑 컨테이너 빌드만 하고요.  ArgoCD라는 쿠버네티스 전용 배포툴을 이용하면 각각에 쿠버네티스 환경에 배포를 할 수 가 있어요. 그럼 이때 이 배포 툴들은 이제 젠킨스가 아닌 argoCD를 통해서 사용 되는 겁니다. 그리고 밑에 아래 그림 처럼 배포 영역을 빌드와 구분해서도 많이 쓰기도 해요. 근데 여기서 제가 얘기 하려는 부분은 배포와 인프라 환경의 관계를 이렇게 1대 다로 구성할 수도 있고, 이렇게 각 환경마다 ArgoCD를 둬서 1대 1로 구축 할 수도 있다는 거죠. (후자 방식을 더 많이 쓰긴 하지만)이런 구성에 장단점은 명확 합니다. 위 구성은 ArgoCD를 이중 관리 해야되는 부담감은 있지만, 개발환경에서 뭘 하던 장애가 나도 운영환경에는 영향이 없죠. 반대로 아래 구성은 하나만 관리해서 편의성은 좋은데, 개발 환경 때문에 장애가 나면, 운영환경도 배포를 못하는 거고요. 지금은 배포와 argoCD를 가지고 말씀 드리는 거지만, 이런 구조적인 상황에 따른 장단점은 IT 전반에서 시스템을 설계를 할 때 흔히 볼 수 있는 상황이예요.그럼 이때, 그래도 실무에서는 운영환경에 영향도가 중요할 텐데, 관리가 불편하더라도 당연히 이 방식을 선택해야 하지 않을까?라고 생각 할 수 있을 것 같아요. 근데 이건 정말 회사마다 운영 방침에 따라 관리 편의를 중시할 꺼냐, 장애 영향도를 중시할 꺼냐에 따라 다릅니다. 하지만 관리 편의를 중시한다는 게 장애가 나도 된다는 말은 아니고, 이 배포 부분이나 CI/CD 전체 서버가 죽더라도, 새로운 배포를 못할 뿐이지, 현재 돌아가고 있는 서비스에 문제가 되는거 아니잖아요? 그래서 좀 유연한 운영 정책을 가지고 있는 곳에서는 이렇게 서비스에 지장이 없는 경우라면, 이렇게 중앙 구성을 하고, 심지어 이 구성에 이중화를 안 시키기도 해요. 왜냐면 그만큼 안전을 중시하기 위해 들어가는 비용도 만만치가 않거든요.그래서 배포를 단일 구성으로 갈지, 분리 구성으로 갈지에 대한 고민도 필요하다는 말씀을 드립니다. 다음으로 [제품 선정]이에요.온라인 용 CI/CD 툴로는 GitHub Actions가 있고, 오프라인 용으로는 Jenkins랑, jenkinsX, 그리고 TEKTON이란 게 있어요. 온라인은 인터넷 환경에 연결해서 쓰기 때문에,  당연히  CI/CD 서버를 별도로 만들 필요가 없다는 장점이 있죠.그리고 오프라인으로 JenkinsX는 젠킨스에서 컨테이너 환경에 맞춰서 새롭게 만든거고, Tekton 역시 컨테이너 환경에 최적화된 CI/CD를 목적으로 만들어진 도구이에요. 그럼 이제 여기서 CI/CD 제품을 선정할 때, 큰 기준이 되는 게 온라인이랑 오프라인인데 대체로 Github와 같은 글로벌한 제품들은 보안이 잘 되기 때문에, 기업에서 인터넷 환경에 접속해서 쓴다고 문제 될 건 없어요. 기업이라고 해서 무조건 내부에 서버실을 만들어서 내 서비스를 운영할 필요는 없다는 거죠. 지금은 클라우드 서비스에 내 시스템을 다 올려서 많이들 쓰고 있으니까 잘 공감이 되리라 생각 됩니다.근데 그럼에도 불구하고 자사에 시스템이 인터넷 상에 있으면 안되는 기업도 많아요.  금융권 내지는 의료기관이나 공공기관들이 대표적이고, 그 밖에도 많은데 정확히는 시스템에 대한 제한이 아니라, 그 시스템이 다루는 데이터가 중요하기 때문에 인터넷 영역으로 올리면 안되는 거죠.이 CI/CD 서버 역시 개발 소스나 릴리즈 파일들에서 중요한 정보들이 많거든요. 그래서 이럴 때는 오프라인 툴을 쓸 수 밖에 없는거고 추가적으로 CI 전용 Tool에는 이런게 있고, CD 전용 툴로 이렇게 ArgoCD랑 Spinnaker라는 툴도 있어요. 다 컨테이너 환경에 최적화 된 툴 들인데 이렇게 오프라인을 써야 한다고 하더라도  비슷한 기능에 툴 들이 참 많죠.이전 에도 말씀드렸지만, 이럴 땐 레퍼런스가  많이 쓰는 걸 선택하는 게 가장 후회가 적습니다. 이렇게 제품 선정에 있어서, 데이터 보안 상황에 따른 온라인과 오프라인 제품의 선택 그리고 레퍼런스가 많은 제품 인지를 보는 게 좋은데 한 가지 더 추가를 하면,제품을 도입하고, 계속 유지보수로 계약할 수 있는 업체가 있냐 없냐의 유무도 중요합니다. 이건 레퍼런스를 떠나서, 어차피 회사 내부에 해당 제품을 직접 다루는 사람이 없거나, 아니면 유지보수 인원에 비해서 엄청 많은 제품들을 사용하고 있는 상태인 회사에서 한번 설치한 이후에 잦은 관리가 필요 없는 제품일 경우, 최소한에 유지보수 비용만 들여서 필요할 때 해당 제품에 전문가를 부르는 게 나으니까요.그리고 다음으로 도커 대체가 있습니다. 이게 뭐냐면, 컨테이너 빌드를 할 때, 도커말고 다른 제품을 쓰려고 하는 이유가 있어요. 처음 도커가 나오고 대중적인 인기를 끌다 보니, 안 좋은 점도 많이 부각됐죠. 물론 단점은 꾸준히 보완 돼 왔고, 여전히 편하게 쓰고 있긴 하지만 그래도 개선되기 힘든 두 가지를 말씀드리면 "Docker가 무겁다는거"랑, "Daemon이 필요하다는 거"예요. 도커가 기능이 많기 때문에 새로 만들지 않는 이상 가벼워지기 힘든 부분이고, 그러다보니 자원을 많이 사용하긴 해요.  근데 다행이도 빌드 속도가 느리다는 건 아닙니다. 오해하시면 안되고 또 하나가, 도커 Daemon이 항상 띄어져 있어야지, 컨테이너가 돌아간다는 거예요.이 Daemon이라는 게 리눅스에 백그라운드로 항상 돌아가고 있어야지, 실행 가능한 제품이라는 거예요. 우리가 kubectl을 쓸 때는, 별도로 kubectl을 띄어 놓지 놓지 않아도 그냥 명령어를 칠 때만 실행하고 쓰고 끝나잖아요? 이런건 daemon-less app 이라고 말하고, 반면에 도커는 daemon이 필요한 app 이라는 거죠.그래서 도커로 컨테이너를 여러게 띄었는데, 도커 데몬이 죽으면 모든 컨테이너가 같이 다운됩니다. 좀 치명적인 단점이긴 한데, 근데 이건 도커를 CI/CD 빌드용으로 고민할 땐 그리 문제 되진 않아요. 빌드할 때 도커가 내려가져 있으면, 올리고 빌드하면 되는거고, ci/cd 서버에 컨테이너를 띄어 놓을 일은 없기 때문에 도커가 갑자기 죽는 상황에 대한 문제는 없습니다. 그래서 저는 그래도 도커를 아직 까진 선호하는 입장이지만, 자원 활용에 중시 한다면, 혹은 상황에 따라 다른 솔루션 들을 쓰게 될 수도 있는 거고요. 그럼 이 상태에서, 컨테이너 빌드로 빌다라는게 있습니다. 근데 이걸 쓸 경우, 함께 써야하는 친구들이 있어요. 각각에 역할을 보면, 먼저 podman을 이용해서 도커 로그인을 하고, 이미지를 가져오는 기능이 있어서 openjdk 같은 베이스이미지를 가져 옵니다. 그리고 buildah로 컨테이너 빌드하고, 이미지가 만들어지면, skepo가 이미지 푸시 기능이 있어서, 도커 허브로 이미지를 업로드 해요. 그리고 앞에서 처럼 argoCD를 통해서 쿠버네티스 배포가 되는 구성 되고요.좀 복잡해 보이긴 하지만,  도커보다 자원 사용률은 낮고요.  또 이 자원 사용률을 무시할 순 없는 게, 젠킨스에서 소스빌드랑 컨테이너 빌드가 갑자기 많아 졌을 때 가끔씩 도커빌드를 하다가 메모리가 부족하다는 에러를 낼 때도 있거든요. 그리고 buildah는 백그라운드 실행이 필요 없는, Daemon-less App 입니다. 그래서 이젠 컨테이너 빌드에 대한 선택의 폭이 생겼고, 추가적으로 하나 더 말씀드리면, 쿠버네티스 위에서만 돌아가는 제품도 있어요. Kaniko라고 해서 컨테이너 환경에서 돌아가도록 만들어 졌는데, 이건 다행이 하나만 있으면 되니까 도커 대체로 시도해 볼 만 하겠죠? 이 후 내용은 해당 강의에서 추가적으로 다루는 내용들입니다. 배포 전략을 세울 때 고려해야 하는 요소단계별로 구축해보는 배포 파이프라인 ps. 뒤로가기 함부로 누르지마라. 너는 누구에게 한 번이라도 좋아요♡를 준 사람이었느냐 :)

데브옵스 · 인프라쿠버네티스어나더클래스지상편Sprint2일프로데브옵스인프런kubeops

인프런 셰리

IT 업계 회고 문화 겉핥기 🍉

'뒤를 돌아본다'는 의미의 회고. 1~4주 정도의 짧은 주기(스프린트) 안에 결과물을 구현, 배포한 뒤 빠르게 제품을 개선하는 루틴을 반복하는 애자일(Agile) 프로세스와 관련이 깊다고 해요.오늘은 직장인들에게, 특히 IT 업계 종사자에겐 일상과도 같은 회고 문화를 빠르게 훑어보려고 합니다. 회고에 대한 인프런 팀원의 생각도 담겨 있으니 끝까지 읽어보세요! 😆회고는 왜 해야 할까?회고는 지나온 프로젝트 과정에서의 문제를 찾고 발전하기 위해 진행한다고 해요. 반복적인 문제 상황을 줄이고 효율적인 업무 방식을 찾기 위한 과정인 것이죠.비케이(Product Designer) ⚒️회고의 목적은 'Better'라고 생각해요. 문제 상황을 공유하면서 피드백이나 개선점을 찾고, 잘한 부분은 칭찬하고. 그러면서 프로젝트를 통해 무엇을 얻었는지 확인할 수 있는 것 같아요.프로젝트를 함께한 팀원과의 회고는 서로의 감정을 공유하는 자리이기도 해요. 함께 일하는 팀원의 생각을 조금 더 이해하고 팀워크를 다지는 계기가 되기도 하죠.보니(Product Mananger) 🦊스프린트 회고와 최종 회고의 역할이 조금 다르다고 생각해요. 스프린트 회고(주간 회고)는 프로젝트 자체가 잘 운영되기 위한 회고에 가까워요.최종 회고는 팀이나 개인 차원에서의 장기적인 발전을 위한 회고인 것 같아요. 서로의 생각을 공유하고 앞으로 더 잘하기 위한 반성이 포함된 느낌?출처: MBC 무한도전  회고를 '잘' 하려면?1. 팀이나 개인에 맞는 회고 방식을 모색하는 시간이 필요해요.인프랩은 보통 KPT 방식으로 회고를 진행해요.빠삐코(Front-end Engineer) 🍦회고를 잘하기 위해서 개인적으로 여러 시도를 해봤는데요. 매일 업무 일지를 작성하는 게 도움이 많이 됐어요. 간단하게만 작성해둬도 나중에 전체 회고를 할 때 도움이 되는 경우가 많았어요. 프로젝트 과정에서 발생했던 문제를 시간이 지나면 잊기도 하는데, 업무 일지가 그런 것들까지 떠올리게 해줬습니다. 2. 프로젝트의 목표를 명확하게 정해두는 게 좋아요.엠제이(Product Designer) Ⓜ️처음에 프로젝트의 목표를 명확하게 정해두는 게 꼭 필요하다고 생각해요. 목표가 명확해야 회고할 때의 기준이 생기고, 업무에 대한 동기부여가 되는 것 같아요. 프로젝트가 목표에 맞게 잘 진행이 되었는지를 중심으로 이야기하니까 회고하기도 수월했어요.중요한 점은 목표를 반드시 팀원 다같이 논의해서 정하는 거예요. 3. 프로젝트에 대한 설계나 계획이 잘 되어 있어야 해요.보니(Product Mananger) 🦊프로젝트 동안 팀원 각자 역할에 대한 계획을 세우는데, 그 계획을 잘 세워두면 좋은 회고가 가능한 것 같아요. 프로젝트 동안 팀원 개개인이 매일 어떤 일을 했는지 스스로 알고 있어야 회고할 거리가 생기더라고요. 그렇지 않으면 느낌이나 기억에 의존한 감정적인 회고에만 그칠 수 있다고 생각해요. 4. 프로젝트를 함께한 팀원에 대한 존중과 배려가 필요해요.비케이(Product Designer) ⚒️회고할 때 감정이 아닌 행동 중심으로 이야기하라는 말에 공감해요.빠삐코(Front-end Engineer) 🍦서로를 존중하되, 솔직하게 말하는 태도가 필요하다고 생각해요. 서로를 존중하느라 진짜 하고 싶은 이야기를 놓치면 안되니까요.출처: MBC 아빠! 어디가?회고에 대한 정답이 정해져 있는 건 아니지만, 회고의 목적이 업무의 효율성과 앞으로의 성장에 있다는 점은 누구나 공감할 것 같아요.여러분은 회고를 해야 하는 이유가 무엇이라고 생각하시나요? 회고를 잘하기 위한 방법은 뭐라고 생각하시나요? 회고에 대한 다양한 의견을 댓글로 남겨주세요! 회고 문화를 더 깊게 다룬 글을 읽어보고 싶다면?[개발자의 공유 문화 이모저모 (2) 회고 문화] 읽어보기 >> 인프랩 팀원이 작성한 다양한 회고록을 살펴보고 싶다면?[인프랩 실Log] 읽어보기 >>

교양 · 기타회고회고문화애자일

일프로

[쿠어클#11] Jenkins Pipeline 기초부터 Blue-Green까지

Sprint2 추가 강의가 업로드 됐어요!이번 강의에서는 Jenkins Pipeline 기초부터 Blue/Green까지라는 주제 입니다. Step 1. Jenkins Pipeline 기본 구성 만들기Step1으로 Jenkins Pipeline에 대한 기본 구성을 만들어 볼거고, Github에서 릴리즈 파일들을 가져와서 빌드/배포하는 구성을 이번에는 젠킨스 파이프라인으로 만들어 보겠습니다. Step 2. Github 연결 및 파이프라인 세분화두 번째 Step은 Github 연결과 파이프라인 세분화인데, Jenknis Pipeline을 쓰는 이유인 파이프라인 스크립트를 Github에서 가져오고, 파이프라인을 좀더 세분화 시켜볼꺼예요. 이렇게 세분화 하면 좋은 점이 각 구간별로 시간이 얼마나 걸리는지 바로 보이기 때문에 이전 배포보다 왜 느려졌는지 눈에 잘 뛰기도 하고, 생각보다 오래 걸리는 구간이 있으면 개선 포인트로 잡기도 좋아요. Step 3, 4. Blue/Green 배포 만들기 및 특징 실습다음으로 Blue/Green 배포를 만듭니다. 처음 Blue가 배포된 상태에서, Green 배포를 하고, V2 버전에 Deployment가 생성이 되면, 트래픽을 V2로 전환 합니다. Service의 Selector를 변경할 거고요. 그런 다음 v1 Deployment를 삭제하면, 이 Blue 배포가 없어지는 거죠. 근데 이 과정 중에서 유즈케이스로 말씀드렸던 운영에서만 테스트 가능한 경우를 하나 해볼 거고, 다음으로 수동 배포시 롤백이 빠르다는 것도 해볼 거예요. 그래서 여기까지가 수동으로 Blue/Green 배포를 할 때 해볼 수 있는 실습들입니다. 다음으로 Step4로는 버튼 한번으로 자동 배포가 되는 Script를 만들고, V2에 과도한 트래픽을 유입 시켰을 때 V2 Pod에 문제가 발생할 수 있는 부분은 실습 환경을 구성하기가 쉽지 않게 때문에 별도로 실습을 해보진 않지만 꼭 주의하시길 바랍니다. 실습 내용은 강의에서 다루고 있어요. (https://inf.run/NzKy)   Blue/Green 시 고려해야 하는 요소다음으로, Blue/Green시 필요한 요소라고 해서 yaml을 만들 때 어떤 걸 고려해야 되는지를 설명 드리겠습니다. 먼저 왼쪽은 Blue 배포에 대한 yaml 파일이고, 이건 이전 부터 계속 봤왔 던 내용이에요. 그리고 오른쪽은 Green 배포를 위한 Deployment yaml 파일 내용 입니다. 뭐가 다른지 보이시나요? deployment 이름 뒤에 추가적으로 시퀀스가 붙어 있죠? 바로 Blue/Green 배포를 고려한 Deployment에 네이밍이 필요한건데, Blue/Green은 기존배포와 나중배포에 대한 상징적인 표현이고, 배포 할 때마다 계속 새 Deployment를 만들 줘어야 되기 때문에 이렇게 네이밍에 신경을 써줘야 합니다. 다음으로 블루/그린 배포를 위한 추가 레이블 및 셀렉터가 필요해요. 현재 이 레이블 상태라면 Green을 만들자마자 Service가 Green Pod에도 연결을 하겠죠. 그래서 블루/그린 배포를 위한 Selector와 Label을 추가적으로 만들어야 되요. 그리고 Green에는 이렇게 값을 다르게 만들어야 되는 거고요.  그래서 여기까지가 Blue/Green 배포를 한다고 했을 때, 미리 고민해서 구성 해놔야 되는 yaml 파일에 내용 입니다. 이번 강의는 실습이 많은 강의라 블로그에는 이정도까지만 정리하겠습니다 ^^그럼 강의에서 만나요!ps. 뒤로가기 함부로 누르지마라. 너는 누구에게 한 번이라도 좋아요♡를 준 사람이었느냐 :)

데브옵스 · 인프라쿠버네티스어나더클래스지상편Sprint2일프로데브옵스인프런젠킨스blue/green

인프런 아셀

한국인에게 딱 맞는 AI, 클로바 X 체험기

ChatGPT가 출시된 이후로, 계속해서 대화형 AI가 기하급수적으로 늘고 있는데요. 그중 최근 주목할 만한 새로운 AI가 등장했습니다. 네이버에서 출시한 CLOVA X! 다른 AI와 어떤 게 비슷하고 무엇이 다른지, 그리고 우리는 클로바 X를 어떻게 활용할 수 있을지 알아보기 위해 직접 사용해 봤습니다!클로바 X, 그것이 알고 싶다!CLOVA X는 네이버에서 대형 언어 모델(LLM)*을 활용해서 만든 대화형 인공지능 서비스입니다. 약 두 달 전 출시되었으며 한국을 대상으로 하여 한국어 버전으로만 출시되었어요. (추후 다른 언어를 추가할 가능성도 있다고 해요.) 오픈AI의 GPT-3.5와 비교했을 때 한국어를 6,500배 더 많이 학습했다고 해요! 아직까지는 서비스 안정성을 위해 대화 횟수에 제한을 두고 있으며, 3시간에 최대 30개까지 질문이 가능하다고 합니다.대형 언어 모델(Large Language Model)*이란?대규모의 데이터에서 얻은 지식을 기반으로 다양한 콘텐츠를 인식하여 요약, 번역, 예측, 생성 등을 할 수 있는 딥러닝 알고리즘입니다. 대규모라고 불리는 만큼, 오랜 기간 동안 인터넷에 작성된 거의 모든 것을 데이터로 훈련합니다. 네이버가 만든 서비스이기 때문에 네이버 계정으로 로그인하면 누구나 바로 사용이 가능하고, 사용법은 다른 대화형 AI 모델들과 비슷해서 사용하기에 어렵지 않았어요. 기존 생성형 AI와 다른 점은 skill이라는 부분인데, 사용할 스킬을 선택한 후 질문을 입력하면 선택한 스킬을 활용하여 최적의 답변을 제공해 줍니다. 현재까지는 스킬에 '네이버 쇼핑'과 '네이버 여행'이 추가되어 있으며 지속적으로 업데이트될 예정이라고 합니다.  (▲ '블라우스 추천해 줘.' 라는 질문에 네이버 쇼핑과 연동하여 링크를 보여줘요.)예를 들어, '네이버 쇼핑' 스킬을 선택 후 '블라우스 추천해 줘.' 등과 같이 쇼핑과 관련된 질문을 입력하면 네이버 쇼핑의 최신 정보를 연동해서 최저가나 상품 정보에 대한 추천 등을 답변으로 받을 수 있어요. 직접 써보면서 느꼈을 때는 네이버와의 연동성이 좋은 것 같았어요.국내 정보는 꽉 잡고 있다구! (▲ 유행했던 도도독 밈에 대해서 물어봤는데, 정확하게 파악하고 있어서 놀랐습니다.)클로바 X는 한국 특화형 AI이기 때문에 한국에서만 쓰이는 줄임말이나 유행어, 사투리, 근처 맛집이나 카페 등에 대한 질문을 했을 때 정확도가 높은 편이에요. 네이버의 방대한 한국어 자료를 학습하여 우리들이 일상생활에서 클로바 X를 자연스럽게 사용할 수 있는 부분이 장점으로 꼽히기도 해요. 출처: MBC 무한도전전반적인 평가는요CLOVA X에 대한 평가는 아직 많이 나뉘는 중입니다. 검색, 맛집 찾기 등에 대해 엉뚱한 답을 내놓는 다른 AI 서비스들에 비해서는 긍정적인 부분도 있지만, 아쉬운 부분들이 있다는 평가도 있어요. 문장을 직접 만들어 내거나, 전문적인 내용에 대해 물어봤을 때 나오는 답변이 상당히 부정확한 경우가 많기 때문이에요.그럼에도 나름 최신 정보들을 위주로 알려준다는 점, 답변을 주면서 정보의 출처까지 알려준다는 점, 할루시네이션*이 적은 AI라는 점들이 클로바 X만의 장점으로 꼽히기도 합니다. 할루시네이션(Hallucination)*이란?AI가 정보를 처리하는 과정에서 발생하는 오류를 뜻합니다. 정확하지 않거나 사실이 아닌, 조작된 정보를 생성하는 것을 의미해요. 원래의 뜻은 환각, 환영, 환청 등으로 사용됩니다.그 외 이런 것들도 있어요큐 (생성형 AI)생성 AI를 검색에 접목함복잡한 질의 의도를 빠르게 파악하여 검색 편의를 제고함네이버 검색에 축적된 다양한 콘텐츠 통해 풍성한 검색 결과를 보여줌클로바 스튜디오 (비즈니스 도구)사용자의 목적에 맞는 AI 모델을 노코드로 작업할 수 있음기업이 보유한 데이터를 하이퍼 클로바 X에 결합하여 자체적인 AI 모델 제작 가능프로젝트 커넥트 X (기업 업무 생산성 도구) 기업에서 사용하는 협업툴에 AI를 접목한 서비스문서 자료를 기반으로 일정 관리, 초안 작성, 이메일 답장 제안 등 업무 생산성을 높이는 것에 주목직접 사용해 본 결과 클로바 X는 전문적인 내용을 배우기 위해 사용하기보다는, 일상에서 편하게 사용할 수 있는 느낌인 것 같았어요. 실제로 네이버 쇼핑이나 네이버 여행 등의 스킬을 활용하고, 근처 맛집이나 실생활 정보를 물어보는 등 다양한 부분에서 편하게 잘 사용할 수 있을 것 같아요!

마케팅클로바X네이버AI채팅생성형LLM클로바스튜디오프로젝트커넥트x할루시네이션

woozoobro

앱스토어 출시 후 무료로 마케팅하기

출시한 앱을 마케팅하려면 어떻게 해야할까요?마케팅을 1도 모르는 상태로 단순히 홍보를 해야한다고 하니 당장 떠오르는 건 블로그 포스팅말고는 없더라구요. 그렇다고 다짜고짜 앱 좀 다운 받아주십쇼! 부탁하기는 또 거부감이 생기고… 저도 그런 홍보글들을 읽을 때 경험했던 것들이 있으니 무지성으로 글을 퍼나르고 싶진 않았습니다.어느 정도 콘텐츠로 느껴질 수 있으면서 은근히 만다린이라는 앱을 노출할 수 있게 만드는 글이 필요하겠다는 생각이 들었어요.먼저 앱을 개발하게 됐던 이유를 바탕으로 “지속 가능한 개발 스터디를 통해 성장하기”라는 미디엄 포스트를 발행했습니다. 이 포스팅을 첨부해서 링크드인, okky에 다시 한번 게시물을 작성했구요! 총 3일 동안 유의미한 통계를 볼 수 있게 되었는데요. 불특정 다수의 500명 중 10% 정도는 미디엄 글을 확인했고, 이 미디엄 글을 확인한 사람의 대부분이 앱스토어 페이지까지 랜딩, 이 중 실제 다운로드까지 이어진 경우는 4건이었어요.(28일에 3건이 더 추가되서 합계는 총 7건이 됐어요!)우선 미디엄 글 자체는 흥미로웠다는 걸 알 수 있었구요. 앱 스토어에서 앱을 다운받고 싶다는 마음이 들게 하려면 지금보다 더 많은 노력이 필요하겠다는 생각이 드네요. 어떻게 하면 다운로드를 늘릴 수 있을까?미디엄까지 확인한 분들이 앱 스토어 프리뷰에 도달을 했지만 다운로드 수가 생각보다 적게 나온 게 너무너무 아쉽더라구요. 지금보다는 조금 더 유저분들을 설득할만한 근거가 필요하다는 생각이 들었고 한달 전쯤 애플에서 진행한 전문가와의 만남 세션이 기억 났습니다. 앱을 마케팅하기 좋은 방법들을 여러가지 추천해주셨는데 세션의 내용 자체는 애플의 TechTalks 영상과 거의 유사해서 아래 영상을 참고해보셔도 좋을 것 같아요.(한국어 자막 지원 됩니다!!)애플 Tech Talks 영상이 영상에서 추천해준 여러가지 방법 중 제가 시도해 본건 총 3가지입니다. 1. Product Page 최적화급하게 출시를 서두르다 보니 제일 신경을 많이 쓰지 못했던 부분이었어요. 기존의 프리뷰 페이지는 아래처럼 되어 있었습니다.아쉽지만 리소스를 많이 투자할 시간이 없어서 우선은 아래처럼 변경을 해줬구요. 그 결과는~!~!프로덕트 페이지 View 수가 늘어났고, 다운로드 수도 증가했습니다! 2. 그리고 키워드 최적화앱 스토어에서 마케팅을 성공적으로 이끌어가려면 제일 중요한 건 Organic 트래픽의 증가, 유저가 검색엔진을 통해 직접 검색하여 자연스럽게 유입된 트래픽을 늘려야 합니다! 이걸 위해선 앱스토어에서 앱을 검색할 때 서치 키워드에 대한 최적화가 필요하겠네요.기존엔 Mandarin이라는 영어 타이틀이었는데-> 만다린 — 개발 스터디 모집 이라는 타이틀로 변경해줬구요개발 스터디와 관련된 서치 키워드 위주의 단어들에서-> 조금 더 확장된 코딩 공부, 커뮤니티 등의 키워드들을 추가해줬습니다.키워드를 추가할 때 구글 트렌드와 같은 키워드 리서치를 위한 도구들을 사용하는 것도 하나의 방법이 될 것 같네요. 3. 앱스토어 커넥트 마케팅 리소스마지막으로 마케팅 리소스를 자동으로 만들어주는 페이지가 있습니다.앱 스토어 Promote Tool 고정된 키워드이긴 하지만 앱을 홍보할 때 애플이 추천해주는 방향으로 이미지 배너들 생성을 해주더라구요.이외에도 짧은 링크 생성도 가능하고 https://apple.co/3RlbVcNQR코드 제작도 가능했습니다.이렇게 총 3가지의 방법들을 현재 시도해보고 있어요. 다음주의 지표는 또 어떻게 될지 궁금하네요:) 어제 잠깐 외국 개발자님이랑 대화를 나누게 됐는데 Quora나 Reddit 같은 게시판들에 올라오는 질문들에 답변을 하면서 은근슬쩍 홍보하는 방법도 종종 활용한다고 알려주셨어요. 글로벌로 배포를 고려해볼 땐 저렇게 시작해보는 것도 좋을 것 같습니다.개발이 사실 제일 쉬운 거였구, 이제 제일 어려운 부분만 남은 것 같네요🥹무료로 앱 마케팅을 할 수 있는 방법들은 이 정도가 되지 않을까... 또 좋은 방법이 있다면 언제든 알려주세요!읽으신 내용이 도움이 되셨다면~아 만다린 다운 좀 한번 해주십쇼!만다린 앱 스토어

모바일 앱 개발마케팅ios앱스토어앱개발

Jason

파이썬 왈러스 연산자 소개(필요성, 사용 예시)

이번 글에서는 왈러스 연산자에 대해 알아보겠습니다.왈러스 연산자는 아무래도 새로운 기능을 위한 개념이라기 보다는 짧고 직관적인 코드 작성에 사용되는 개념이다보니 직접 예제를 보며 설명하겠습니다.왈러스 연산자는 비교적 최근인 3.8 버전에서 등장한 개념입니다.한 줄에서 변수에 값을 할당하면서 동시에 이 값을 표현식의 일부로 사용할 수 있습니다.바다코끼리 연산자를 통해 파이썬에서 할당 표현식을 가능하게 합니다.여러분이 오랜만에 소비를 좀 하려고 합니다. 우선 그래픽 카드도 좀 사고 싶고,,, 그 다음 순위로 책(2권 사야됨), 그 다음 순위로 키보드, 그 다음 순위로 만년필을 선호한다고 가정하겠습니다.이제 온라인 쇼핑몰 속을 돌아다니며 현재 예산에서 무엇을 살 수 있을 지 봅니다!예산 내에서 그래픽 카드를 살 수 있으면 사고, 아니면 책 2권 값을 낼 수 있는 지 확인합니다. 그래도 안 되면 순서대로 키보드, 만년필을 살 수 있는지 확인해야 합니다.능숙한 프로그래머인 여러분들은 이정도는 파이썬으로 자동화하실 수 있죠?my_budget = 1000000 gift_value = { # 그래픽 카드는 품절이랍니다 'gc': 1300000, 'book': 50000, 'keyboard': 55000, 'pen': 80000 } # 99999999 정도면 품절 상품도 구매할 수 있다고 칩시다. value = gift_value.get('gc', 99999999) if value <= my_budget: print('그래픽카드 구매') else: value = gift_value.get('book', 99999999) if value*2 <= my_budget: print('책 주문!') else: value = gift_value.get('keyboard', 99999999) if value <= my_budget: print('키보드 구매') else: value = gift_value.get('pen', 99999999) if value <= my_budget: print('만년필 구매') else: print('살 수 있는 게 없습니다.') print(f'{my_budget}에서 {value}만큼 사용하셨습니다.')의도대로 동작하지만;; 너무 복잡해보이는 코드입니다. 제가 코드를 잘못 짰다고요?elif 사용을 통해 직관적으로 보이게 만들 수 있지만, 그렇게 쉽게 줄여지지 않습니다. 항상 동일 환경 조건에서 비교를 하는 것이 아니며(book 같은 경우에는 *2 후 비교) 각 상품마다 나오는 메시지가 다르기 때문입니다.이제 왈러스 연산자가 나올 시간입니다. 이 코드에 왈러스 연산자를 적용해보겠습니다.my_budget = 1000000 gift_value = { # 그래픽 카드는 품절이랍니다 'gc': 1300000, 'book': 50000, 'keyboard': 55000, 'pen': 80000 } if (value := gift_value.get('gc', 99999999)) <= my_budget: print('그래픽카드 구매') elif (value := gift_value.get('book', 99999999) * 2) <= my_budget: print('책 주문!') elif (value := gift_value.get('keyboard', 99999999)) <= my_budget: print('키보드 구매') elif (value := gift_value.get('pen', 99999999)) <= my_budget: print('만년필 구매') else: print('살 수 있는 게 없습니다.') print(f'{my_budget}에서 {value}만큼 사용하셨습니다')위아래 코드의 차이가 잘 느껴지셨으면 좋겠습니다.지금 본 사례처럼 왈러스 연산자를 사용하면 코드를 더 직관적이게 만들 수 있습니다.조건문 내에서 값을 할당하고 바로 검사, 블록 안밖에서 사용까지 할 수 있으니 정말 편리하다고 느낍니다.다른 사용 예시를 보며 마무리하겠습니다.# 입력값을 받아서 검사하고 처리 if (n := int(input("Enter a number: "))) > 10: print("10보다 큰 수를 입력했군")# 튜플 언패킹을 사용한 예 a, b = (1, 2) print(a, b) # 출력: 1 2 # 튜플 타입에서 왈러스 연산자를 사용하려면 반드시 명시적으로 괄호를 해주거나 따로 언패킹, 패킹해야 됩니다. (a := 1, b := 2) print(a, b) # 출력: 1 2 원문: https://pinstella.com/writer/articles/7

프로그래밍 언어파이썬pythonwalruscleancode

써니라이더

게임기획자란?

게임기획자는 게임을 제작하기 위해 게임의 구조를 설계하고, UI 구성을 설계하고,게임 규칙을 만들며, 컨텐츠를 구성하고, 각 수치 테이블 작성/ 수치가 적절히 동작할 수 있게밸런싱을 하는 직업입니다. 또한 게임의 컨셉과 세계관, 시나리오를 구성하기도 합니다. [1] 게임기획자의 분류대표적인 게임기획자의 분류로는 플랫폼 별로 온라인게임 기획자와스마트폰 게임 기획자 로 크게 나눌 수가 있습니다.(한국 시장에서 콘솔은 적으므로 일단 제외)게임 기획자의 파트 별로는 다음과 같이 분류하기도 합니다. (1)게임시스템 기획자: 전체적인 게임 시스템을 짜고, 게임 규칙과 UI를 만듭니다. (2)게임 컨텐츠 기획자: 게임내 설정을 잡고, 안에 들어가는 컨텐츠를 기획하고,데이터 테이블 구조를 잡고,수치와 내용을 구성합니다. (3)레벨디자이너: RPG나 FPS에서 맵툴을 가지고 난이도를조정하고,맵과 레벨을 만듭니다. (4)밸런싱 기획자: 전체 수치 밸런스의 기준을 잡고, 아군 적군 전투 밸런싱/캐릭터 클래스 밸런싱/그리고,성장 밸런싱, 재화 밸런싱을 잡습니다. [2] 게임 제작에서의 게임기획자의 업무게임 기획자의 업무는 크게 게임출시 전과 출시 후로 나뉩니다. (1)출시전 업무1)장르결정/시장조사: 게임출시 전에는 가장 먼저 어떤 게임을 만들 것인지장르를 결정하고, 해당 장르에 맞춰서 시장 조사를 동시에진행합니다. 2)게임기획: 시장조사가 끝나면 경쟁게임에 비해 어떤 경쟁우위를 가질 것인지, 게임의핵심 컨셉과 게임 플레이의 재미 부분을 결정하고, 게임 시스템과 UI기획, 컨텐츠 기획과 데이터 테이블 기획을 진행합니다. 아트팀에 기획서를전달하여 디자인이 제작되면, 개발팀에 전달되어 게임이제작이 이루어지게 되고, 기획자는 자신이 기획한 대로 게임이 제대로 제작되었는지 체크하고, 플레이를해보면서 개선의견을 아트팀과 개발팀에 전달합니다. (2)출시후 업무 1)업데이트 기획: 게임 출시 후 라이브 서비스가 진행되게 되면, 게임 기획자는 업데이트계획을 수립하고,업데이트 게임 컨텐츠를 기획하며, 주 단위또는 월 단위로 업데이트가 이루어질 수 있도록 새롭게 게임을 개선하는 작업을 진행합니다.이때 사용자 분석을 통해서 현재 게임이 어떤 상태인지 분석하고 ,그것에 맞춰서 전략적인 업데이트를 준비해야 합니다. [인프런 강의 통합본-게임기획 강의 모음 로드맵]https://www.inflearn.com/roadmaps/452[SNG게임기획하기 강의]https://inf.run/1Vw3[따라하면 취업되는 게임기획 강의-기본]https://inf.run/cb5P[따라하면 취업되는 게임기획 강의-클릭커,퍼즐,RPG]https://inf.run/rpSY[따라하면 취업되는 게임기획 강의-역기획서/이벤트기획서/운영툴]https://inf.run/vEFb[따라하면 취업되는 게임기획 강의-역기획서/BM분석과 개선제안서/창작기획서]https://inf.run/YZJK[RPG게임 밸런스 기획 강의]https://inf.run/Pb8j[사업PM강의]https://www.inflearn.com/course/게임-사업-pm-준비

게임 기획게임기획게임기획자게임기획서게임개발

써니라이더

액션 MORPG 게임의 밸런스 기획-1 아군타수 기준

 액션 MORPG 게임의 밸런스 기획-1 이제 부터 액션 MORPG 게임의 밸런스 기획에 대해서 알아보겠습니다.액션RPG 게임의 전투 부터 재미있게 밸런스를 잡고, 그 이후에 그에 맞춰 성장 밸런스를 맞추고, 성장 밸런스에 맞게 보상과 경제 밸런스를 맞추는 순서로 진행하겠습니다. [전투 밸런스] > [성장밸런스] > [보상과 경제밸런스] 우선 전투 밸런스를 하기 위해서는 아군과 적군에 관해 이해해야 합니다.아군이 1명 밖에 없고, 칼을 휘둘러서 화려한 액션으로 몬스터들을 물리치고, 몬스터들을 물리치면 보스를 만나 전투를 하고, 보스를 잡으면 한 스테이지가 끝나는 게임이라고 가정을 해 봅시다. [액션 버튼을 터치해서 공격] > [몬스터들과 전투] > [보스와 전투] > [스테이지 클리어] 전투가 재미있게 되려면 몇가지를 정해야 합니다.우선 적을 조우하게 되면, 몬스터가 플레이어의 공격을 몇 번 맞고 죽어야 플레이어는 재미를 느낄 까요? 예를들어 봅시다. [몬스터가 플레이어의 기본 공격을 몇 번 맞고 죽어야 재미 있나요?] 1) 1대2) 4대3) 30대4) 100대 많은 경험에서 눈치채셨겠지만, 몬스터가 플레이어의 공격을 1번만 맞고 죽어 버린다면, 너무 허무하게 게임이 끝나서 재미가 없을 것이고, 반대로 30번이나 100번을 맞고 죽는다면, 몬스터 한 명에 너무 지루할 수 있다고 생각이 되실 것입니다.다른 상용화된 액션 RPG 들을 조사해 보면 경험적으로 3번~10번 정도가 적당한 몬스터의 피격 횟수라고 짐작할 수 있을 것입니다. 지금 왜 이런 이야기를 하고 있는가 하면, 밸런스를 잡을 때는 무엇을 기준으로 할 것인지가 중요해서 입니다.여러가지의 요소들을 기준으로 잡을 수 있지만, 우선 게임을 재미있게 만든 다음에 성장과 보상 지급을 맞춰 나가는게 자연스럽습니다. 때문에 전투에서 재미있을 만한 수치의 기준을 먼저 잡아 놓고 나머지를 그것에 맞추어 봅시다.만약 몬스터를 때려서, 몬스터가 4대 맞으면 죽는 것이 자연스럽게 생각된다면, 일단 그 기준으로 전투의 기준을 잡아 봅시다. 나중에 이 기준은 바뀔 수 있고 전체를 조율하면서 바꾸면 되므로, 일단 이 기준을 잡는 것에 대해 두려워 하지 맙시다. [전투 밸런싱 – 첫번째 기준] 1)    몬스터가 플레이어의 기본 공격을 몇 번 맞고 죽어야 재미 있나요?정답 : 우리는 “4번” 을 기준으로 잡겠습니다. [인프런 강의 통합본-게임기획 강의 모음 로드맵]https://www.inflearn.com/roadmaps/452[SNG게임기획하기 강의]https://inf.run/1Vw3[따라하면 취업되는 게임기획 강의-기본]https://inf.run/cb5P[따라하면 취업되는 게임기획 강의-클릭커,퍼즐,RPG]https://inf.run/rpSY[따라하면 취업되는 게임기획 강의-역기획서/이벤트기획서/운영툴]https://inf.run/vEFb[따라하면 취업되는 게임기획 강의-역기획서/BM분석과 개선제안서/창작기획서]https://inf.run/YZJK[RPG게임 밸런스 기획 강의]https://inf.run/Pb8j[사업PM강의]https://www.inflearn.com/course/게임-사업-pm-준비

게임 기획게임기획게임밸런스게임기획자게임개발

써니라이더

액션 MORPG 게임의 밸런스 기획-2 아군적군기준

[액션 MORPG 게임의 밸런스 기획-2] 앞서서 몬스터를 한번 때리면 4타에 죽는다.를 1차 기준으로 세웠습니다.이제 다른 기준도 정해 봅시다. 이 게임은 플레이어 혼자서 기본 공격 버튼을 터치 하면, 3-4타 의 기본 공격을 하고, 스킬 버튼을 터치 하면 스킬이 시전되는 게임이라고 합시다. 스킬 같은 경우는 한번 사용하면 몇초의 쿨타임이 생깁니다. 이런 상태일 때, 일반 몬스터와 보스 처치까지 전투 한판의 적당한 시간은 어느 정도가 적당할까요? [플레이어가 전투 한 판을 플레이 하는데 평균 시간이 얼마나 되면 좋을까요?] 1)30초2)1분3)3분4)30분5)1시간 이렇게 선택지가 주어졌을 때, 우리는 실제 유저가 플레이 하는 것처럼 생각해서, 적절한 경험의 기준을 만들어야 합니다.다른 MORPG 게임의 사례를 보면 초반 스테이지에서 1분~2분 정도의 클리어 시간이 걸리고, 후반 스테이지에서는 약 7~8분 정도의 클리어 시간이 걸리는 것을 확인했습니다.우리는 지금 기준을 정하려는 것이므로 평균적으로 3분의 클리어 시간이 걸리면 좋겠다고 설정합시다. 기준 스테이지 클리어 시간 : 3분 몬스터를 4대 때린다고 하면, 몬스터를 4대 때리는데 몇초가 걸릴까요?1초 또는 2초가 걸릴 수 있습니다. 플레이어의 이동 시간까지 고려해서 2초라고 생각해 봅시다.그렇다면 일반 몬스터 30명을 처치 하는데 1분이 걸릴 것입니다.평타로만 상대한다고 했을 때, 그렇게 계산이 되죠.그렇다면 스킬을 20초마다 쓸 수 있고, 스킬을 한번 쓰면 3명의 몬스터를 물리칠 수 있다고 하면 어떨까요? 1분 동안에 몬스터를 추가로 9명을 물리칠 수 있을 것입니다. 이런 식으로 플레이어가 1분 동안에 기본공격으로 줄 수 있는 대미지와, 스킬 공격으로 줄 수 있는 대미지를 계산해 봅시다. 이전에 기본공격과 스킬공격으로 발현되는 대미지의 기준을 정해봅시다. 적 일반 몬스터 : 체력 100 을 가지고 있다. 기본공격 : 2초에,  4타 공격을 하고, 1타마다 대미지 25씩 들어간다.          따라서 1초에는 50 대미지를 주는 셈이다. 기본공격의 대미지를 더미 데이터로 정해보았습니다.이 때 1초당 들어가는 대미지를 DPS(Damage Per Second)라고 하며, 여러 대미지 계산의 기준이 됩니다. 스킬 공격 : 20초의 쿨타임을 가지는 마법 스킬이며,한번 공격할 때미다 유도되는 매직 미사일을 날려 3명을 공격한다.매직 미사일 1개는 100대미지를 가진다.따라서 20초마다 총 300대미지를 준다.이것을 1초로 계산하면 15 대미지를 주는 셈이다.  여기까지 정리하면 1초당 플레이어가 줄 수 있는 대미지의 총량이 나올 수 있습니다.기본 공격과 스킬 공격을 동시에 쓸 수 있다고 가정합시다. 플레이어가 1초에 줄 수 있는 총 대미지 : 기본공격(50) + 스킬 공격 (15) = 총 대미지 (65) 이와 같이 나올 것입니다. 그렇다면 아까 정했던 기준시간인 3분 동안 플레이어가 줄 수 있는 총 대미지를 구해 볼까요? 3분 동안 플레이어가 줄 수 있는 총 대미지 = 1초 당 총 대미지(65) X 180 = 11700 자 이렇게 역산해 보면 3분 동안 적이 받는 총 대미지가 나옵니다.여기서는 방어력을 빼고, 플레이어의 대미지를 적이 모두 받는다고 가정하면, 3분 동안의 적의 총 체력은 11700이 됩니다. 그렇다면, 이것을 일반 몬스터와 보스 몬스터로 나눠 볼까요? 플레이 시간 3분 동안 50%인 1분 30초는 일반 몬스터를 사냥하고, 나머지 50%인 1분 30초는 보스전을 한다고 가정해 봅시다. [1차 체력 배분]일반 몬스터 무리의 총 체력 : 5850보스 몬스터의 총 체력 : 5850 여기서, 이전에 일반 몬스터의 체력이 100이라고 했으니, 보스 몬스터에게 체력 50을 이동해서 맞춰 줍시다. [2차 체력 배분]일반 몬스터 무리의 총 체력 : 5800일반 몬스터 는 총 58명이 등장, 일반 몬스터 1명당 체력은 100보스 몬스터의 총 체력 : 5900 이렇게 기준을 맞추면 몇가지 기준에 의한 수치 조정이 이루어 졌습니다. [수치 조정 1차 정리]몬스터는 4대 맞으면 죽는다.기본 공격은 2초에 4타 발현되고, 1타마다 25대미지스킬 공격은 20초에 한번 3개의 매직미사일이 나가고 1개 발사체 마다 100대미지일반 몬스터의 체력은 100일반 몬스터의 숫자는 58명보스 몬스터의 체력은 5850플레이어가 1초에 줄 수 있는 총 대미지 65플레이어가 3분에 줄 수 있는 총 대미지 11700한판의 전투가 끝나는 시간 3분 이렇게 기준을 잡을 수 있습니다. 만약 이 게임의 전투 규칙이 턴제 전투라면 이동과 액션이라는 변수가 없기 때문에 상당히 비슷하게 맞아 떨어질 수 있을 것입니다.하지만 이 게임은 액션 RPG이기 때문에 플레이어의 이동, 회피, 기본 공격을 한번 휘두를 때 대미지를 받는 몬스터 수(몬스터의 배치 간격에 따라 달라진다) 등 여러 변수가 많습니다.이런 변수 때문에 플레이어가 1분당 줄 수 있는 총 대미지와, 몬스터가 동시에 피격을 받는 조건 등이 달라질 수 있습니다. 하지만 아무 기준도 없다면, 초기 밸런스를 맞출 수 없으므로 처음에 이런 식으로 기준을 맞춰보는 것은 중요합니다. 조작에 따라 결과가 달라지는 액션 RPG 이므로, 아주 조작을 잘 하는 유저와, 아주 조작을 못하는 유저 중 중간 정도 조작을 할 수 있는 유저를 가정하여 자동전투 AI를 만듭니다. 자동전투 AI가 완성되면, 1차 로 정리한 수치를 플레이어와 몬스터의 스탯에 반영하여, 가정한 수치와 실제 수치가 얼마나 차이가 있는지 검증합니다. “우리가 설정했던 몬스터는 4대 맞으면 죽는다.”와 “한판의 전투가 끝나는 시간은 3분”의 기준을 그대로 두고 나머지 수치를 맞춰 나갑니다. 그렇게 다시 조정을 하면, 어디에서 변화가 생겼는지 원인을 파악할 수 있고, 처음에 세웠던 가정을 수정 할 수 있습니다.예를들어 플레이어가 3분에 줄 수 있는 총 대미지가 실제로는 몬스터를 동시에 때려서 15200 수준이라고 합시다. 다음번에 밸런스 계산할때는 총 대미지를 구하는 계산식에 1.3의 계수를 곱해서 계산하면, 차이가 난 부분을 보정하여 보다 정확한 계산식을 만들어 낼 수 있습니다. 여기까지 전투밸런스에서 아군 공격력과 적군 체력에 관한 기준을 세우고 계산하는 방법의 예시 설명이었습니다. [인프런 강의 통합본-게임기획 강의 모음 로드맵]https://www.inflearn.com/roadmaps/452[SNG게임기획하기 강의]https://inf.run/1Vw3[따라하면 취업되는 게임기획 강의-기본]https://inf.run/cb5P[따라하면 취업되는 게임기획 강의-클릭커,퍼즐,RPG]https://inf.run/rpSY[따라하면 취업되는 게임기획 강의-역기획서/이벤트기획서/운영툴]https://inf.run/vEFb[따라하면 취업되는 게임기획 강의-역기획서/BM분석과 개선제안서/창작기획서]https://inf.run/YZJK[RPG게임 밸런스 기획 강의]https://inf.run/Pb8j[사업PM강의]https://www.inflearn.com/course/게임-사업-pm-준비

게임 기획게임기획게임밸런스게임기획자게임개발

써니라이더

정확히 사업 PM이라면 무슨업무까지 하는건가요??

질문 : 정확히 사업 PM이라면 무슨업무까지 하는건가요??답변 : 써니라이더 작성 >  사업PM은 런칭에 필요한 마케팅 준비하고 이벤트 준비하고 웹 준비하고 운영툴 준비하고 지표 남길거 준비하고 그리고 CS 정책 체크하고, 운영계획 만들고 이벤트 집행 하고 운영하고. 공지 올리고 전화 받고..마케팅 하고 이벤트 하고..커뮤니티 관리하고..유저 간담회 하고..개발사 가서 빌드 달라고 하고, 유료 아이템 기획해서 넣고, 지표 분석해서 업데이트 방향과 이벤트 방향 정해서 개발사와..협의해서 다음 업데이트와 패치 준비하고..운영팀 서비스 리포트 받아서 분석해서 개발팀에게 이거 다음에 고쳐달라고 하고..QA팀과 협의해서 빌드 나올때 괜찮은지 체크하고..새벽에 나와서 빌드 올리고..업데이트 하고 하죠 ^^ 써니라이더가 경험해 봤고 할 수 있는 업무[게임기획]1.시스템,컨텐츠,전투,레벨디자인,밸런싱,유료아이템 기획2.개발팀 일정표 작성과 일정 관리 / 사운드 기획 3.카카오나 라인등 플랫폼에 게임 마이그레이션 기획[사업PM/운영업무]1.지표설계,데이터 분석 할 수 있는 웹 기획2.운영툴 기획(웹)3.이벤트 기획 / 이벤트 웹페이지 기획(모바일,웹)4.사업팀이 하는 기본적인 데이터 분석5.오프라인 행사 진행-지스타 6.소싱 업무[QA]1.QA에 필요한 테스트 케이스 작성 [인프런 강의 통합본-게임기획 강의 모음 로드맵]https://www.inflearn.com/roadmaps/452[SNG게임기획하기 강의]https://inf.run/1Vw3[따라하면 취업되는 게임기획 강의-기본]https://inf.run/cb5P[따라하면 취업되는 게임기획 강의-클릭커,퍼즐,RPG]https://inf.run/rpSY[따라하면 취업되는 게임기획 강의-역기획서/이벤트기획서/운영툴]https://inf.run/vEFb[따라하면 취업되는 게임기획 강의-역기획서/BM분석과 개선제안서/창작기획서]https://inf.run/YZJK[RPG게임 밸런스 기획 강의]https://inf.run/Pb8j[사업PM강의]https://www.inflearn.com/course/게임-사업-pm-준비

기획 · 전략 · PM사업pmpm게임사업게임사업pm게임기획게임기획자게임개발

Devvy

Java의 실행원리 Deep Dive

Java는 다양한 운영체제에서 동일한 소스코드를 실행할 수 있는 "write once, run anywhere"의 철학을 지닌 프로그래밍 언어입니다. 국내에서 가장 활발히 사용되는 언어이며 제가 현업에서도 주로 사용하는 언어입니다. 이번 포스팅을 통해서 자바가 실행되는 원리에 대해 살펴보겠습니다. 블로그 원본 링크: https://code-run.tistory.com/61 프로그래밍 언어가 특정 운영체제 위에서 실행되기 위해서는 해당 운영체제가 이해할 수 있도록 코드가 작성돼야 합니다. 하지만 자바 개발을 하신 분들은 동일한. java 파일을 맥 OS, 윈도우 또는 Linux에서 실행한 경험이 있으실 겁니다. 정확히는 javac(자바 컴파일러)에 의해 컴파일된 .class 코드가 동일하더라도 해당 코드는 서로 다른 운영체제 위에서 실행될 수 있습니다. 이는 JVM 내부의 interpreter가 운영체제가 이해할 수 있는 코드로 변환해 주기 때문입니다. 즉 java는 운영체제가 이해할 수 있는 코드를 작성하는 책임을 프로그래머로부터 JVM으로 전이한 것으로 볼 수 있습니다. 운영체제별로 다운로드 받을 Java가 구분됨JDK, JRE, JVMJava 프로그램을 실행하기 위해서는 보통 JDK를 다운로드합니다. JDK와 항상 함께 등장하는 JRE 그리고 위에서 소개한 JVM에 대해 알아보겠습니다. JVM은 Java의 .class 파일이 실행될 수 있는 환경입니다. .class 파일의 bytecode를 host 운영체제 위에서 실행될 수 있는 환경을 제공합니다. JRE는 Java Runtime Environment의 약자로 자바 프로그램이 실행될 수 있는 최소환의 환경입니다. JRE는 JVM뿐 아니라 java 프로그램을 실행시키는데 필요한 라이브러리와 소스를 포함합니다. JDK는 Java Development Kit의 약자로 JRE를 포함합니다. 즉 JDK는 JRE와 JVM을 모두 포함하는 구조입니다. JDK는 javac, debugger 등 개발을 위한 도구를 포함합니다. JRE librariesJdk 설치와 함께 javac 등 설치Java의 실행 원리 .java 파일의 실행 흐름다음으로는 우리가 작성한 .java 파일이 어떻게 동작하는지 살펴보겠습니다. 우리가 작성한 .java 파일은 javac에 의해 .class 파일로 컴파일됩니다. 컴파일된 .class 파일은 JVM의 class loader에 의해 JVM의 메모리 영역에 로딩됩니다. JVM 메모리에 로딩된 후 execution engine의 interpreter에 의해 코드가 운영체제가 이해할 수 있는 기계어로 변환되고 이는 운영체제의 적절한 함수를 호출하여 필요한 로직을 수행합니다. 그럼 컴파일된 .class 파일이 어떻게 JVM 메모리에 로드되는지 상세히 살펴보겠습니다. Class Loader Subsystem Class loader subsystem의 주목적은 자바 프로그램을 실행시키기 위해 필요한 class를 찾아서 JVM의 메모리에 로드하고 연결(link) 하기 위함입니다. 필요한 class를 로드하고 연결하는 것 이외에 class variable을 초기화하는 역할도 수행합니다.Class loader subsystemLoad (Class Loaders) Java 프로그램 실행에 필요한 class를 jvm에 로드하기 위해서 class loader를 활용합니다. Class loader는 다음과 같이 목적에 맞게 역할이 나뉘어있습니다. Bootstrap class loader: JVM이 실행될 때 해당 java 프로그램 실행에 필요한 기본적인 class들을 로드합니다(rt.jar 파일 내의 java.lang 등). Extension class loader: Extension class들을 로드합니다(주로 jre/lib/ext에 위치). Extension class는 JDK가 추가적으로 제공하는 라이브러리입니다. Application class loader: classpath에 설정된 class를 로드합니다. 프로그래머는 실행시키고자 하는 java 프로그램의 classpath를 명시할 수 있습니다. // classpath를 직접 명시하는 방법 java -cp /path/to/classes:/path/to/jarfile MyMainClass java -classpath /path/to/classes:/path/to/jarfile MyMainClass // environment variable를 설정해서 classpath를 명시하는 방법 export CLASSPATH=/path/to/classes:/path/to/jarfile // system variable을 설정해서 classpath를 명시하는 방법 java -Djava.class.path=/path/to/classes:/path/to/jarfile MyMainClassLink Link 단계에서는 .class 파일 내의 symbolic references를 실제 메모리 주소로 변환하는 작업을 수행합니다. 단계별로 다음과 같은 작업을 수행합니다. Verify: .class 파일이 java 스펙에 맞는지 검증합니다. Bytecode format, version number 등을 확인하는 단계입니다. Prepare: 클래스와 static variable을 위한 메모리를 할당합니다. 중요한 점은 static variable이 default 값으로 초기화된다는 점입니다. 예를 들어 boolean 타입의 static 변수를 true로 설정하더라도 prepare 단계에서는 해당 변수는 false로 초기화됩니다. Resolve: symbolic reference를 실제 메모리 주소로 변환합니다.Symbolic reference란 우리가 코드를 작성하면서 사용한 class, field, method의 이름을 지칭합니다. Resolve 단계는 class, field, method 그리고 constant pool의 symbolic references를 실제 메모리 주소로 변환합니다. InitializeStatic initializer block을 실행합니다. 위 link의 prepare 단계에서는 static 변수가 default 값으로만 초기화됐지만 initialize 단계에서는 프로그래머가 지정한 값으로 static 변수가 설정됩니다. Initialize가 완료된 이후 main 메서드가 실행됩니다. Runtime Data Areas 다음으로는 JVM 메모리 구조에 대해 살펴보겠습니다.JVM runtime data area의 구조Method Area (Metaspace)Class level 정보를 저장하는 영역입니다. Class 정보, method 정보, static variable과 constant pool 정보를 저장합니다. Java 8부터는 기존의 method area의 한계를 극복하기 위해 method area가 제거되고 metaspace가 도입됐습니다. 기존의 method area의 경우 실행하고자 하는 java 프로그램에 클래스의 수가 너무 많을 때 "java.lang.OutOfMemoryError: PermGenspace" 에러를 발생할 확률이 컸습니다. 이는 method area가 heap의 일부 영역이었고 JVM에 할당된 메모리에 의해 최대 크기가 제한됐기 때문입니다. Metaspace는 JVM에 할당된 메모리가 아닌 system의 native 메모리를 활용하기 때문에 system의 가용 메모리에 제한을 받습니다. 따라서 method area를 활용하는 것보다 OutOfMemoryError가 발생할 확률이 낮아졌습니다. HeapRuntime에 생성된 object 또는 array를 저장하는 메모리 영역입니다. 모든 스레드에 의해 공유되는 영역으로 JVM 생성 시 할당됩니다. 자바 프로그램을 개발하면서 가장 많이 신경 쓰는 메모리 영역이기도 합니다. Managed 언어인 java이지만 memory leak이 발생할 수 있기 때문에 개발자는 사용하지 않는 객체의 참조가 정상적으로 해제되는지 신경 써야 합니다. 중요한 만큼 heap의 구조에 대해 상세히 살펴보겠습니다.VisualVM을 활용한 heap 분석Java의 heap 영역은 young과 old 영역으로 구분됩니다. Young은 말 그대로 최근에 생성된 객체들이 위치하는 영역이고 old 영역은 특정 threshold 이상의 기간 동안 살아남은 객체가 위치하는 영역입니다.  Young 영역은 또다시 eden, s0과 s1으로 구분됩니다. s0과 s1은 survivor의 약자입니다. 객체가 새로 생성될 때 해당 객체는 eden 영역에 할당됩니다. 그리고 eden 영역이 더 이상 객체를 저장할 수 없는 경우 minor gc(garbage collection)을 거쳐 s0 또는 s1의 영역으로 살아남은 객체를 이동시킵니다. 위 사진에서 보시면 s1에 저장된 객체가 없는 것을 확인할 수 있습니다. 다음 minor gc 때 eden과 s0 영역에서 살아남은 객체가 s1으로 이동하는데 이와 같은 플로우를 지니게 된 이유는 데이터 파편화(fragmentation)를 압축(compaction) 없이 해결하기 위해서입니다. 만약 s0과 s1이 동시에 사용된다면 gc에 의해 객체가 제거되면서 메모리 영역 중간중간이 비어 파편화 현상이 발생합니다. 이를 해결하기 위해서는 일정한 간격으로 압축이 필요하지만 JVM의 경우 s0 또는 s1 중 단 하나의 영역만 사용하기 때문에 별도의 압축과정이 필요하지 않습니다. Minor gc로 인해 s0과 eden에서 살아남은 객체가 s1으로 이동Young 영역에서 일정기간 이상 생존한 객체는 old 영역으로 승진(promote)됩니다. 만약 old 영역에 더 이상의 객체가 저장될 수 없는 경우 major gc(garbage collection) 수행합니다. 이때 application이 순간적으로 정지하는 stop the world 현상이 발생합니다. 사용하는 garbage collector의 특성에 따라 stop the world 현상이 상이할 수 있습니다. Heap과 관련돼서 중요한 설정으로는 -Xmx와 -Xms가 있습니다. Xmx 설정을 통해 heap의 최대 크기를 제한할 수 있고 Xms 설정을 통해 heap의 초기(최소) 크기를 설정할 수 있습니다. Xmx 값을 시스템 메모리보다 크게 설정하면 swap이 발생하여 시스템 전체적인 성능이 악화되거나 시스템이 다운될 수 있습니다. 따라서 Xmx값을 시스템 메모리보다 작게 설정하는 게 권고됩니다. 두 번째 권고 사항으로는 Xmx와 Xms 값을 동일하게 설정하는 것인데 이는 만약 두 설정값이 다른 경우 힙의 크기가 Xms에 도달했을 때 운영체제에게 추가 메모리를 요청함으로써 발생하는 오버헤드를 줄이기 위함입니다. 프로덕션 환경에서 운영해 보면 결국 JVM이 사용하는 메모리는 Xms를 넘어 Xmx를 향해 증가하기 때문에 Xms와 Xmx를 동일한 값으로 설정하는 것은 성능적인 관점에서 효율적일 수 있습니다.https://developer.jboss.org/thread/149559Why to set -Xms and -Xmx to the same value?| JBoss.org Content Archive (Read Only)In a production environment, if you monitor the GC data, you will notice that is a relatively short period of time (usually less than an hour), the JVM will eventually increase the heap size to the -Xmx setting. Each time the JVM increases the heap size itdeveloper.jboss.orgJava Stacks 메서드 실행 시 생성되는 function call frame을 저장하기 위해 사용됩니다. Function call frame에는 해당 메서드에서 생성된 지역 변수 등이 저장됩니다. Thread별로 stack 영역이 할당됩니다. 만약 이 영역에 너무 많은 데이터가 저장되는 경우 stack overflow error가 발생할 수 있습니다. 또한 JVM의 -Xss 옵션을 활용해서 stack의 최대 깊이를 제한할 수 있습니다. PC Registers Program counter을 저장하기 위해 사용되는 영역입니다. 특정 thread의 실행 위치를 표시하므로 각각의 thread별로 pc register가 생성됩니다. Native Method Stacks Thread에서 native method를 호출하는 경우, 즉 java 이외의 언어로 작성된 코드를 호출하는 경우 사용됩니다. Thread별로 생성됩니다. Execution Engine Execution engine은 JNI를 활용해 운영체제의 함수를 호출합니다. 이 과정에서 사용되는 각각의 컴포넌트에 대해 살펴보겠습니다. JNI(Java Native Interface)는 JVM에서 실행 중인 java 코드에서 다른 언어(C/C++)로 작성된 코드를 호출할 수 있도록 도와주는 프레임워크입니다. 자바의 기능만으로 수행할 수 없는 로직 또는 성능적인 측면에서 다른 언어를 사용하는 게 효율적일 때 사용됩니다. Execution engineInterpreter Bytecode를 읽어 native code(machin code)로 변환하는 역할을 담당합니다. 자주 실행되는 코드가 실행될 때마다 매번 interpreter에 의해 변환되면 비효율적입니다. 이러한 단점을 극복하기 위해 JVM은 JIT compiler을 활용합니다. JIT Compiler JIT은 just-in-time의 약자입니다. 즉 적절한 시기에 bytecode를 캐싱하고 최적화함으로써 자주 호출되는 코드가 interpreter에 의해 여러 번 변환되는 작업의 수를 줄일 수 있습니다. JIT compiler는 tiered compilation을 활용함으로써 단계별로 최적화하는 정도가 다릅니다. 현업에서 발생할 수 있는 문제 중 하나는 java 애플리케이션이 시작한 지 얼마 되지 않았을 때 코드가 충분히 캐싱 또는 최적화되지 않아 응답지연이 발생하는 점입니다. 이는 JVM warmup을 통해 해결할 수 있습니다. 카카오에서 JVM warmup을 통해 응답지연 현상을 어떻게 해결했는지 좋은 영상이 있어 공유드립니다. https://www.youtube.com/watch?v=CQi3SS2YspY&t=1sProfilerInterpreter에 의해 자주 변환되는 코드를 파악하는 데 사용됩니다. Garbage Collector 사용되지 않는 객체에 할당한 메모리를 해제하지 않으면 언젠가는 OutOfMemoryError에 의해 프로세스가 종료될 수 있습니다. 자바의 경우 참조되지 않는 객체에 할당된 메모리를 garbage collector을 활용해 해제합니다. 그럼 garbage collector은 어떻게 동작하는지 살펴보겠습니다. "Mark and Sweep"은 다양한 garbage collector들의 동작원리입니다. Mark 단계에서는 live 스레드에서 참조하는 객체들을 표시하고 sweep 단계에서 참조되지 않는 객체의 메모리를 해제합니다. Garbage collector의 특성에 따라 garbage collection 중에 애플리케이션이 동작하는 방식이 달라집니다. 다음으로는 어떤 garbage collector가 존재하는지 살펴보겠습니다. Serial GC Serial GC단일 스레드로 mark and sweep을 통해 garbage collection을 수행합니다. Parallel GC Parallel GCSerial collector와 동작원리는 유사하지만 여러 스레드를 활용해서 mark and sweep을 수행합니다. CMS(Concurrent Mark and Sweep) GC 애플리케이션의 중단 없이 mark and sweep이 가능한 garbage collector입니다. 애플리케이션 중단을 최소화하기 위해 사용됩니다. 물론 CMS라고 stop the world 현상이 없지는 않습니다. Initial mark 단계와 remark 단계에서는 stop the world 현상이 발생합니다.  CMS는 다음 순서로 동작합니다. 1. Initial mark: Old 영역의 참조되고 있는 객체를 표시합니다. 짧게나마 stop the world 현상이 발생할 수 있습니다. 2. Concurrent marking: 자바 애플리케이션 중단 없이 참조되는 객체들을 표시합니다. 3. Remark: concurrent marking 단계에서 놓친 참조되는 객체들을 표시합니다. Stop the world 현상이 발생할 수 있습니다. 4. Concurrent sweep: 참조되지 않는 객체의 메모리를 해제합니다. G1(Garbage First) GC G1 GCJava 9 이상부터는 기본 설정되는 GC로 큰 heap에서도 garbage collection에 소요되는 시간을 최소화하기 위해 개발된 garbage collector입니다. G1 GC는 heap을 작은 영역으로 나눠 각 영역에 대해 독립적인 garbage collection을 수행합니다. 여러 영역 중 garbage가 가장 많은 영역을 골라 우선적으로 garbage collection을 수행합니다. 추가로 G1 GC는 "Garbage-First Virtual Space"라는 자료구조를 활용해서 heap의 어떤 영역이 가장 많은 garbage를 가졌는지 추적합니다.  G1 GC는 다음 순서로 동작합니다. 1. Initial mark: 애플리케이션 중단 없이 현재 스레드에서 참조되고 있는 객체를 표시합니다. 2. Concurrent marking: Live  스레드로부터 참조되는 객체를 추가로 찾아 marking 하는 단계입니다. 3. Remark: 짧은 stop the world 현상이 발생할 수 있습니다. 이는 remark 단계에서 live 스레드로부터 참조되는 객체를 정확히 표시하기 위함입니다.4. Garbage collection: Heap에서 가장 많은 garbage를 가진 영역들에 대해 우선적으로 garbage collection을 수행합니다. 애플리케이션 중단 없이 수행됩니다. 5. Clean up: 파편화를 제거하기 위한 압축 등 garbage collection 이후 수행돼야 하는 작업을 수행합니다. 마무리 이번 포스팅을 통해 우리가 작성한 java가 어떻게 실행되고 java를 실행하는데 필요한 다양한 소프트웨어에 대해 살펴봤습니다. JVM은 자바뿐 아니라 Kotlin, Scala 등 다양한 언어의 실행환경이기 때문에 그 내부원리를 잘 이해하는 게 중요하다고 생각합니다. 

프로그래밍 언어JavaJVM

모두의연구소

코딩 테스트 대비까지 완벽한 백엔드 기초 가이드

위니브, 제주코딩베이스캠프 대표 이호준 대표가 말하는 백엔드 개발자가 되기 위한 첫 걸음부터 완벽한 코딩 테스트 대비까지! 국가에서 지원하는 많은 부트캠프가 있습니다. 여러분도 비교 분석을 해보셨을 것이고요. 만약 비교 분석을 하지 않으셨다면 비교 분석을 해보시길 권해드립니다. 이 글에서는 이 과정이 어떠한 부분에서 특별한지를 설명해 드리고자 합니다. 1. 실무 경험 많은 강사진부트캠프마다 한 강사가 처음부터 끝까지 끌고 가는 강의가 있고, 챕터마다 강사가 나뉘는 강의도 있습니다. 둘 다 장단점이 있습니다. 저희는 각 분야의 전문성은 해당 분야 근무와 실무 경험이 있으신 분이 가장 잘 알고 있다고 판단했기 때문에 후자를 선택했습니다.파이썬과 인공지능은 국민은행 등에서 데이터 분석을 하셨던 김진환 님이, 프론트엔드는 다음 포털 검색 FE 개발 등을 하셨던 한재현 님이, 인프라는 반도체 회사에서 IT 담당하셨던 김승주 님이, 백엔드는 위니브의 대표인 제가(이호준) 이끌고 있습니다. 모두 위니브라는 조직에 속해있어 유기적으로 커뮤니케이션하고 있습니다. 자신이 맡은 분야 강의가 끝나도 채팅방을 나가거나 사라지지 않고요.또한 실무 경험과 더불어 가장 큰 것은 강의 경험이라고 생각합니다. 모두 아래 보이는 다양한 콘텐츠 제작과 대학, 대기업 등에 강의 경험, 출판 경험이 있는 분들입니다.저희는 다양한 콘텐츠 제작(책과 강의 제작) 경험과 다수의 부트캠프 운영 경험이 있습니다. 다양한 곳에 콘텐츠를 공급하고 있지만, 그중에서도 인프런에서는 57개 강의, 7만여 명 수강생, 평점 4.8점을 달성하고 있어요. 제주코딩베이스캠프라는 Django 부트캠프를 제주에서 진행하고 있기도 합니다. 카카오와 함께하는 알고리즘 산책 등 다양한 프로그램 운영 경험도 가지고 있습니다. 유튜브 채널은 제주코딩베이스캠프라는 채널을 운영하고 있고요.이렇게 쌓인 노하우를 통해 여러분의 드라마틱한 성장을 돕겠습니다.  2. 개별 학습 욕구에 맞춘 학습 방식많은 학생이 모여 수업을 듣는 만큼 다양한 학습 경험치를 가지고 있습니다. 컴퓨터공학과를 졸업한 분, 이제 막 시작하신 분, 이미 다른 기업에서 실무를 하다 오신 분 등이요. 다양한 분들이 들어오는 만큼 학습 방법에서도 차이가 있습니다.이제 막 시작하신 분은 모든 수업에 집중해서 들을 수 있도록 구성이 되어 있고, 관련 학과를 졸업하신 분들은 부족한 부분만 학습할 수 있도록 강의자료와 월별 영상 강의가 나갑니다. 이미 실무를 하신 분들은 책 출판이나 오픈소스 프로젝트 등 다양한 커리어를 쌓을 수 있도록 구성되어 있습니다. 이밖에도 수준별 스터디 그룹 구성, 개발 실무진의 멘토링 등을 통하여 가능하면 여러분의 다양한 학습 욕구가 해소될 수 있도록 진행하고 있습니다.공통 교육은 줌을 통한 온라인 라이브로 진행이 되고, 디스코드를 통해 실시간 질문을 받습니다. 진도는 중위 진도로 조정해가며 나가고, 어렵거나 쉬우신 분들을 위해 공부할 수 있는 학습자료나 자신의 실력을 가늠할 수 있는 과제를 드립니다.강사와 수강생의 시간이 꼭 동기화 될 필요는 없습니다. 이미 해당 과목이나 당일 나가는 진도에 대해 충분한 이해를 하고 있다면 더 높은 수준으로 넘어갈 수 있도록 학습 자료를 제공합니다. 부족한 부분 2%를 채우러 오신 분 같은 경우 과제로 바로 넘어가거나 오픈소스나 책 출판 프로젝트에 좀 더 몰입하는 분도 있으십니다.다만 이 경우에도 필수 과제는 꼭 해주셔야 합니다. 선택 과제와 필수 과제가 주어지는데요. 이 과제를 통해 여러분이 해당 과정에 꼭 필요한 학습 개념을 이해하고 있는지 판단합니다. 3. 책 출판과 오픈소스 프로젝트여러분을 좀 더 밀도 있는 개발자로 성장 시키고, 이력서에 한 줄 넣어 취업의 험난한 허들을 넘을 수 있도록 캠프 외 프로젝트로 책 출판 프로젝트와 오픈소스 프로젝트를 진행합니다.책 출판 프로젝트는 항상 무료책으로만 출판을 하고 있으며 반기나 분기별로 출판하고 있습니다. 이러한 프로젝트는 여러분의 이력서에 오랫동안 남을 것입니다. 지금 취업뿐만 아니라 여러분이 다음에 이직을 하실 때도 많은 도움이 될 것이고요.다만 이 프로젝트는 자율 프로젝트입니다. 출판이 쉬운 작업은 아니기 때문에 의지가 있어야 합니다. 책 출판은 의지가 있는 분들을 모으고, 브레인스토밍을 통해 주제를 선정한 다음 그 주제를 집필할 분들을 모아 팀끼리 집필하게 됩니다. 필수로 참여해야 하는 프로그램은 아닙니다. 한 권의 책을 출판한다는 것은 쉬운 일은 아닙니다. 쉽지 않기 때문에 가치가 있습니다. 이를 통해 여러분들은 좀 더 밀도 있는 개발자가 되실 수 있습니다.오늘 자(2023/11/22) 리디북스 컴퓨터/IT 전체 무료 책 인기순으로 보았을 때 첫 페이지에 있는 책 대부분이 저희가 집필한 책이거나 캠프에 참여한 학생들이 집필한 책입니다. 출판사 사도출판으로 확인하시면 됩니다.오픈소스 프로젝트는 관련된 주제가 있을 때 진행하고, 관련된 주제가 없을 경우 진행하지 않습니다. 보통 반기에 한 건씩 진행하고 있습니다. 대표적인 프로젝트로 제주특별자치도 상황판으로도 사용했었던 라이브 코로나(https://livecorona.co.kr/)가 있고, 스탑워(https://stopwar.co.kr/), 플랙스엔그리드(https://flexngrid.com/), 에스큐엘스쿨(https://sqlschool.co.kr/) 등을 진행했었습니다. 오픈소스 프로젝트는 실무에 계신 분 중 뜻이 있는 분들이 합류해 함께 개발합니다. 4. 반복학습과 코드 리뷰, 코딩 테스트처음 하는 분에게 가장 두렵고 힘든 것은 ‘익숙하지 않음’ 입니다. 12번의 반복을 통해 Django를 학습할 수 있도록 다양한 프로젝트가 준비되어 있고, 실무에 대한 막연한 두려움도 이겨내실 수 있도록 실제 실무에서 하는 것과 유사한 프로젝트가 준비되어 있습니다.각 프로젝트에는 발표회가 준비되어 있습니다. 이 발표회와 프로젝트 시트(sheet)를 통해 서로가 서로의 프로젝트를 공유할 수 있는 구성으로 동반성장 할 수 있도록 구성이 되어 있습니다. 발표마다 상장이 준비되어 있습니다. 발표가 있는 프로젝트는 총 3개이고 별개로 대상, 최우수상, 우수상이 나가게 됩니다.이러한 경험과 과제가 쌓여갈 때마다 할 수 있다는 자신감이 생기실 것입니다. 쉬우니까 할 수 있다는 자신감이 아니고 어렵지만 할 수 있다는 자신감입니다. 모두 구현하지 못하더라도, 일부라도 발표를 할 수 있도록 합니다. 부담감도 성장의 동력으로 쓸 수 있도록 여러분을 이끌겠습니다.또한 막연하게 여러분에게 어떤 결과물을 요구하는 것이 아니라 명확한 가이드를 통해 여러분이 갖춰야 될 구성 요소에 대해 예시를 통해 말씀드립니다. 예를 들어 발표는 대부분 Readme 파일로 진행을 하는데요. 아래 샘플 레포를 통해 어떤 식으로 구성하는지 감을 잡을 수 있습니다.링크 : https://github.com/weniv/project_sample_repo과제 발표와 동시에 코드 리뷰를 진행합니다. 실제 실무에서 받는 코드 리뷰 절차 등에 대해서도 설명해드리고 어떤 코드가 좋은 코드인지에 대해서도 여러 사례를 기반으로 얘기해드립니다. 코딩 테스트는 현재 출제되는 문제의 유형 분석, 문제의 출제 빈도, 기업별로 분석해둔 코딩 테스트 유형 등 다양한 데이터 기반 자료를 토대로 여러분들에게 명확한 가이드와 전략을 드리도록 하겠습니다.위니브에서는 그동안 여러 권의 알고리즘 책을 출판했으며, 제주 알고리즘 베이스캠프(https://jejualcam.co.kr/), 카카오와 함께하는 알고리즘 산책 등 다양한 행사를 진행해 왔습니다. 또한 알고리즘 테스트 서비스(https://pyalgo.co.kr/)도 운영하고 있는데요. 이러한 경험을 기반으로 여러분이 알고리즘에 보다 쉽게 다가갈 수 있도록 돕겠습니다.다만 코딩 테스트는 아쉽게도 왕도가 없습니다. 여러분이 매일매일 훈련하셔야 합니다.  4. 이력서 템플릿 제공과 리뷰, 코딩 테스트 대비저희가 한 해에 리뷰하는 이력서는 500건에서 700건 정도 됩니다. 이력서 검토 경험을 ‘신입개발자 이력서 작성 가이드’라는 책으로 집필하기도 했습니다.리뷰를 했던 데이터를 기반으로 희망 연봉에 따라 이력서를 검토해드립니다. 또한 희망 연봉에 따라 준비해야 하는 요건이 다를 수 있습니다. 예를 들어 고액 연봉을 희망한다면 코딩 테스트를 준비해야 하지만 연봉 3200 미만에서는 코딩 테스트가 거의 없습니다. 전략적으로 어떤 포지션을 취해야 하는지도 함께 알려드립니다.이력서를 노션으로 많이 작성하는데요. 실무자가 어떤 것을 선호하는지 모르기 때문에 다양한 양식을 준비해둘 필요가 있습니다. 생각보다 Notion 이력서를 좋아하지 않는 곳도 많습니다. 저희는 PDF양식과 노션 양식을 모두 제공해드립니다. PDF 양식은 아래 링크에서 무료로 확인하실 수 있습니다.https://paullabworkspace.notion.site/Figma-bfa32213fc244db9b31bb8486a479ee6?pvs=4 5. ICT 교육에 대한 치열한 고민캠프를 진행하게 되면 우리끼리 간혹 하는 얘기가 있습니다. ‘이 교육은 우리밖에 못한다’라는 얘기인데요. 이유는 우리는 ICT 교육에 대해, 한 과목 한 과목에 대해 치열하게 파고들고 회의하여 적재적소에 학습요소를 배치할 수 있는 그룹이기 때문입니다. 또한 단순히 교육의 퀄리티를 고민하는 것이 아니라 교육을 넘어 여러분에 이력에 무엇이 들어가야 좋을지, 이력서는 어떻게 써야 하는지 실질적인 컨설팅을 병행할 수 있는 그룹이기 때문에 그렇습니다. 우리는 여러분의 취업과 성장에 진심인 그룹입니다.우리의 방식이 모든 사람에게 맞는다는 생각은 가지고 있지 않습니다. 비교해보시고, 분석해보시고 선택해주시길 바랍니다.

백엔드백엔드웹개발파이썬장고PythonDjangoAI서비스인공지능머신러닝프레임워크

모두의연구소

데이터 사이언스 통계 기초(1) : 가설검증 이해하기

통계를 공부할 때 추론통계에서 제일 먼저 만나는 큰 산이 가설검증에 대한 이해입니다. 용어도 낯설고 매우 헷갈립니다. 가설검증의 절차에 대한 설명은 훌륭하게 정리된 정보를 많이 찾을 수 있습니다. 하지만 왜 그리고, 어떠한 관점으로 가설검증을 이해해야 하는가에 대한 글은 부족해 보여, 통계와 함께 데이터 사이언스 공부를 시작하시는 분들에게 도움이 되고자 가설검증의 논리에 대해 정리해 봅니다.이 글은 연세대학교 경영학과 양혁승 교수님의 저서인 <비전공자를 위한 통계방법론>을 참고하여 정리했음을 알립니다. (강추합니다.)연구 가설의 설정과 검증데이터를 이용한 실증연구의 구성은 이론과 방법론으로 나뉩니다. 이론 부분은 검증하고자 하는 가설(Hypothesis)을 제시하고 방법론 부분은 검증기법을 통해 합당한 가설인지 판정하는 작업을 합니다.진행하기 전에 확인해야 할 점이 있습니다. 가설이라 함은 이론에 근거하여 모집단에서 성립할 것이라 주장하는 내용이고, 이 가설이 합당한지를 판단하는 가설검증은 표본데이터를 활용하여 이루어진다는 점입니다. 이렇게 표본된 샘플을 토대로 가설을 이용해 모집단을 추정하는 방법을 통계적 추정(Statistical inference)이라 합니다.대립가설과 귀무가설하나의 가설을 예로 들어봅니다,가설 : 학습시간은 학업성취도와 유의한 관계를 가질 것이다.이 가설의 모집단은 대한민국의 대학생이라 가정해 봅니다. 변수는 학습시간과, 학업성취도가 될 것이고, 이 가설에서 관심을 가지게 되는 모수는 두 변수의 연관성을 나타내는 상관계수가 됩니다. 여기서 검증하기 원하는 바는 두 변수가 유의미한 관계 존재할 것이라는 주장의 진위 여부가 됩니다. 참고로 상관계수란 서로 다른 변수의 연관도를 표현하는 지표로 0에 가까울 수록 연관관계가 없다고 판단하게 됩니다.위와 같이 주장하고자 하는 바를 대립가설로 설정하고, 대립가설의 여집합을 귀무가설로 설정합니다. 위의 가설을 대립가설과 귀무가설로 정리해 보면 아래와 같습니다. (수식과 기호는 가능한 피해 봅니다.)대립가설 : 학습시간과 학업성취도 사이의 상관계수는 0이 아닐 것이다.귀무가설 : 학습시간과 학업성취도 사이의 상관계수는 0이다.가설검증에서 귀무가설의 역할귀무가설은 가설검증 과정에서 기각하려는 대상입니다. 대립가설의 여집합인 귀무가설을 기각함으로써 주장하고자 하는 대립가설이 옳다는 결론에 도달하려는 것입니다. 높은 확신을 가지고 귀무가설이 옳지 않다는 주장을 할 수 있다면, 같은 수준으로 대립가설이 옳다고 주장할 수 있습니다. 또한 귀무가설이 옳지 않다는 주장의 근거가 없다면, 대립가설이 옳다는 주장을 할 수 없습니다. 결국 본인의 가설(대립가설)이 맞다는 것을 입증하기 위해서 반대되는 가설(귀무가설)을 세우고 이것이 잘못되었다는 근거를 찾는 것이 가설검증의 논법입니다.가설검증에서 통계적 접근위의 검증을 간편하게 하기 위해 표본통계량을 표준화합니다. 표본통계량으로 부터 표준화 된 것을 검증통계량이라 합니다. 대부분의 이론적인 공식 속에는 모집단의 통계량이 변수로 포함되어 있습니다. 하지만, 우리는 이 모집단의 실제 통계량을 알 수 있는 방법이 없습니다. 그래서 이 모집단의 통계량 대신에 샘플링해서 얻은 표본통계치를 대신 대입하여 계산하게 됩니다. 이렇게 구한 통계치는 이론적인 모집단의 통계치와 같을 수 없으며 일정한 오차(error)가 개입됩니다. 표본의 수가 늘어날 수록 이 오차는 줄어들 것이라 예상할 수 있습니다. 따라서 오차가 개입되어 구해진 검증통계량은 표준정규분포에서 약간 벗어난 t-분포를 따르게 되고, 대부분의 가설검증에서는 이 t-분포를 사용하게 됩니다.유의수준과 기각영역위에서 설정한 귀무가설이 옳다면, 표본분포에서 무작위로 뽑은 값들은 표본분포의 중앙값(상관계수가 0)에 근접한 값일 확률이 높을 겁니다. 그리고, 중앙값에서 멀리 떨어진 값일 수록 뽑일 확률은 작아집니다. 따라서 하나의 표본에서 얻은 표본상관계수 값이 중앙에서 어느정도 멀리 떨어진 값이 아니라면 귀무가설을 기각할 수 없게 됩니다.반대로 0에서 멀리 떨어진 값(확률적으로 발생가능성이 매우 낮은 값)이라면 귀무가설을 기각할 수 있게 됩니다. 왜냐하면 해당 표본상관계수 값이 귀무가설이 옳다는 가정 하에 설정한 표본분포에서 무작위로 뽑아 나온 값이라고 보기에는 확률적으로 가 가능성이 매우 낮기 때문입니다.그렇다면, 표준화한 검증통계량이 가지는 t-분포에서 얼마나 떨어진 값인 경우에 귀무가설을 기각할 지 판단할 기준이 필요합니다. 이 기준치를 기각영역의 경계값이라 하고, 표본상에서 나온 값으로 받아들일 수 없는 기준확률을 유의수준(α)이라 합니다. 위의 확률분포에서 우리가 얻은 검증통계치가 나올 확률이 유의수준보다 작다면 우리는 귀무가설을 기각할 수 있습니다.p-value의 중요성과 해석귀무가설을 기각할 지 여부를 판단하는 방법 중 유의확률(p-value)를 활용하는 방법도 있습니다. 가장 널리 쓰이는 방법이고, 많은 분석 라이브러리에서 분석결과에 포함되는 값입니다.유의확률이란 귀무가설이 옳다는 가정하에 얻은 표본분포에서 이 분포로 부터 얻은 표본통계치보다 같거나 더 극단적인 값이 나올 확률을 이야기 합니다. 다시 이야기하면, 표준화된 표본분포량의 중앙값에서 가능한 멀리 떨어진 값이 나오는 확률입니다. 이 확률이 유의수준 보다 작다면 귀무가설을 기각할 수 있는 근거를 얻고, 대립가설을 채택하게 됩니다. (양측검정과 단측검정의 차이가 있지만, 이 글에서는 다루지 않습니다.)마무리가설검증에서의 대립가설과 귀무가설이 무엇인지 살펴보았습니다. 또한, 어떤 논리에 의해 귀무가설을 기각하고 대립가설을 채택하는 전반적인 가설검증의 논리를 정리해 보았습니다.

데이터 사이언스데이터데이터분석데이터사이언스데이터사이언티스트인공지능데이터시각화데이터수집데이터통계

모두의연구소

AI학교 아이펠 : 설립부터 운영까지의 비하인드 스토리 [아이펠 스토리 #01]

AI 부트캠프들의 효시 <딥러닝 컬리지> (2017)AI 스타트업들을 발굴 육성하고 지원하는 서울시 AI 양재허브가 2017년 개관했습니다. 이때 모두의연구소는 카이스트와 함께 공동운영사로 선정되었어요. 서울에서도 약간 외진 곳에 있는 양재허브를 많은 AI 개발자들이 방문하는 곳으로 만들자는 목표로 다양한 세미나와 네트워크 모임들을 운영했습니다. 그중에서 가장 핵심이 되었던 것이 AI 인재양성을 위해 ‘딥러닝 컬리지 Deep Learning College, DLC‘라는 1년짜리 교육 프로그램을 만든 것인데요. 2017년 딥러닝 컬리지 1기를 시작으로 2019년 4기(이때는 규모를 확장하면서 ‘AI 컬리지’로 이름이 변경됨)까지 운영하면서 인공지능이라는 것이 꼭 대학교나 대학원에서만 배울 수 있는 게 아니라는 것을 입증했습니다.여기에는 아트센터 나비, 삼성SDS, 왓챠, 네오사피엔스, SI Analytics, 펄스나인 등 다양한 협력 기업들이 공동 프로젝트에 참여하는 등 큰 관심을 받았습니다. 그림 1. 모두의연구소 딥러닝 컬리지와 공동프로젝트를 진행한 기업들 특히 딥러닝컬리지 졸업생들은 ‘뉴립스 NeurIPS‘ 학회 발표 2건, ‘한국전자공학회’ 우수논문상 2건, ‘ICGHIT’ 국제학회 발표, 단독 전시회 개최 등 대외적으로 인정받는 좋은 결과를 보여주었어요. 그 노력에 보답하듯이 졸업생들은 현재 구글, 카카오브레인, 업스테이지, SK C&C 등 많은 기업에서 활발하게 활동하고 있습니다. 그림 2. 뉴립스 2019 발표 당시 영상 1. ‘WHAT-IF : Can AI Be Creative?’ 딥러닝 컬리지 전시회 그러나 정말 안타깝게도 이런 제대로 된 AI 교육을 받을 수 있는 곳은 서울밖에 없었어요. 아래 그림은 2021년 기준 전국의 AI 교육 프로그램 분포를 보여주고 있습니다. 인구의 20%만이 서울에 사는데, AI 교육 프로그램의 80%가 서울에 몰려있죠. 2020년 아이펠 설립 당시에는 정말 지방의 청년들은 AI를 배우고 싶어도 배울 곳 자체가 없었습니다. 그림 3. 서울에만 몰려있는 AI 교육▶︎ [김승일 칼럼] AI 리터러시 (1) : 서울에만 몰려있는 인공지능 교육  에꼴42, TUMO 방문 : 웃음이 끊이지 않는 교실을 경험하다 (2019)2019년, 저는 두 곳의 혁신학교를 경험하게 됩니다. 하나는 프랑스에 위치한 IT 교육기관 ‘에꼴42 Ecole 42‘와 아르메니아에서 시작된 청소년을 위한 STEAM 교육기관 ‘투모 TUMO‘인데요. 이 곳을 방문하면서 저의 교육에 대한 생각과 가치관이 많이 정립되었습니다. 특히 투모는 저에게 깊은 감명을 주어서 이후 제가 설립한 AI 학교 ‘아이펠’에 많은 영향을 미치게 되었습니다. 그림 4. 아르메니아에 위치한 IT 교육기관 : 투모 에꼴42와 투모, 두 기관은 공통점이 상당히 많습니다. 먼저 두 기관은 모두 비영리 재단이 운영합니다. 또한 두 기관 모두 ‘강사 없이’ 운영됩니다. 비영리 재단의 특성상 운영비가 넉넉하지 못함에도 최대한 많은 학생에게 교육의 기회를 주어야 하기에 강사 없는 학교를 생각한 것이 아닐까 싶습니다. 글로벌하게 진출하고 있어서 에꼴42는 2023년 현재 전세계 43개 캠퍼스를, 투모는 13개 캠퍼스로 확장되어 운영 중입니다. 놀라운 성과가 아닐 수 없지요.비영리 재단의 특성상 운영비가 넉넉하지 못할 것입니다. 유명한 교수님을 모셔와서 라이브 강의를 통해 수천~수만명의 학생들을 가르치는 것은 비용 효율적이지 못합니다. 그래서 두 기관 모두 강사가 없는 대신 매우 훌륭한 자체 교육 콘텐츠와 학습 관리 시스템 Learning Management System 및 교육 운영 시스템을 가지고 있었습니다.무엇보다 가장 놀랐던 점은 두 학교 모두 학생들이 교실에서 끊임없이 웃으면서 활동을 한다는 것인데요. 이렇게 밝은 표정의 학생들을 본 적이 없었습니다. 조용한 교실이 아닌 시끄러운 교실. 그들은 서로 대화하고 질문하고 함께 무언가를 만드는 것을 즐기는 표정이었습니다.  AI 혁신학교 아이펠 런칭 (2020)제가 에꼴42와 투모를 경험하고 돌아온 후, “기존의 주입식 교육을 탈피한, 시끄러운 교실을 지닌 AI 학교 설립”으로 회사의 방향성을 정립하고 총력을 기울이게 됩니다. 2019년 8월부터 2020년 7월까지 약 1년 간 전문 콘텐츠, 학습 관리 시스템, 교육 운영 시스템을 설계하고 구현하며 매일 밤새 만들게 되는데요.1) 아이펠 전문 콘텐츠에꼴42와 투모는 많은 공통점이 있지만, 서로 다른 점도 있습니다. 그 중 하나가 ‘콘텐츠’인데요. 에꼴42는 학생들에게 문제를 제시해 주는 ‘과제 제시형’ 콘텐츠를 가지고 있습니다. 자유도가 굉장히 높으며, 학교를 다니는 동안 계속 제공되는 과제를 풀면서 실력을 향상시키기 때문에 방탈출 게임같은 재미와 도전의식을 심어줄 수 있습니다.투모는 콘텐츠 팀이 있지만, 모든 콘텐츠를 직접 만들지 않습니다. 저는 이것을 ‘큐레이티드 커리큘럼 Curated Curriculum‘이라고 부르는데요. 웹, 유튜브 등 기존에 있는 정보를 잘 큐레이션해서 보여주는 것만으로도 많은 부분 해결됩니다. 그림 5. 투모의 ‘큐레이티드 커리큘럼’ 방식의 교재 저는 우리의 교육이 주입식/사교육에 의존해서 자라왔기 때문에 아직 우리가 에꼴42 정도의 자유도 높은 콘텐츠를 받아들일 준비가 되어 있지 않다고 판단했습니다. 모두의연구소 아이펠 콘텐츠 팀은 투모처럼 큐레이션과 직접 만드는 것을 적절히 혼합하여 최신의 AI 기술을 전달하려고 노력합니다. 대신 에꼴42의 ‘게이미피케이션 Gamification‘을 가미하기 위해 각 노드*마다 해당 노드에서 학습한 내용을 적절히 응용하여 결과를 만들어 내는 미니 프로젝트를 두도록 설계하였습니다.*노드(Node): 아이펠 내 학습의 최소 단위 그림 6. 아이펠 미니 프로젝트 예 : AI로 애니메이션 프사 만들기 2) Active learning(강사가 아닌 퍼실리테이션)아이펠 설립 당시 지방에는 AI 교육을 진행하는 교육 기관이 없었어요. AI를 가르쳐 줄 개발자/강사가 없기 때문이었죠. 지역의 청년들에게도 AI를 배울 수 있는 기회를 주기 위해 모두의연구소 아이펠은 강사가 없는 교육 시스템을 개발하는 데 도전하게 됩니다. 강사가 주입식으로 지식을 알려주는 형태는 단기간에 빠르게 배울 수 있는 반면 기억에 많이 남지는 않습니다. 들을 때는 아는 것 같지만, 나중에 보면 아는 게 별로 없죠. 물론 이걸 방지하기 위해 시험도 보지만, 그것도 시험을 볼 때 뿐.. 시험이 끝나고 한 달이 지나면 대부분 잊어버립니다. 이런 경험 다들 있으시죠? 그림 7. 러닝 피라미드(Learning pyramid) : 강의식의 수동적 학습보다 토론과 체험 위주의 액티브 러닝의 학습 효과가 훨씬 더 뛰어남 그래서 아이펠은 처음부터 강사가 아닌 ‘퍼실리테이션 Facilitation‘에 초점을 두고 만들었어요. 질문을 던져주고 서로 토론하게 만드는, 바로 그것이 퍼실리테이터의 역할입니다.모두의연구소는 사실 아이펠이라는 교육기관 설립 이전부터 연구모임 ‘LAB’과 스터디모임 ‘풀잎스쿨’을 운영하던 커뮤니티 기업이기도 합니다. 커뮤니티는 기본적으로 강사가 아닌 퍼실리테이팅 기반으로 운영되는 곳이고, 그 어떤 기업보다 모두의연구소가 자신있어 하는 부분이기에 적극적으로 설계에 반영이 되었죠. 3) 아이펠 운영비를 어디서 충당할 것인가?모두의연구소는 에꼴42나 투모처럼 어느 재력가가 재단을 세운 곳이 아닌, 영리 기업입니다. 영리 기업임에도 교육 기회의 제공이라는 사회적 가치를 중요시 하는 곳이기에, 학생들에게 직접 고가의 등록금을 받는 것에 큰 망설임이 있었습니다. 그래서 모두의연구소는 정부, 지자체, 기업들이 펀딩을 해 줄 수 있는지 발로 뛰며 찾아보게 되었죠. 그 중 저희의 방향성을 믿고 지지해 준 곳이 바로 ‘고용노동부’였습니다. 요즘 많이들 보이는 고용노동부의 ‘K-디지털 트레이닝 K-Digital Training‘ 사업 이전에 고용노동부에서는 아이펠에 큰 관심을 보이며 지원이 이루어졌고, 이것이 K-디지털 트레이닝 사업까지 연계되어 지금까지 학교를 잘 운영 중에 있습니다.저는 모두의연구소 아이펠이 다른 AI 부트캠프와 가장 큰 차이점은 교육에 대한 ‘진정성’이라고 생각합니다. 대부분의 교육기관들이 ‘K-디지털 트레이닝이라는 정부 펀드가 있는데 우리도 들어가 볼까?’ 라는 접근이라면, 모두의연구소는 그런 정부지원사업이 있기 2년 전부터 준비해서 만든 교육 프로그램이라는 것입니다. 그림 8. 2018년 아이펠 설립 전 수행했던, AI 혁신학교에 대한 기업 및 학생 인터뷰 설문 결과 예 4) 이루지 못한 꿈, 학습의 개인화 : 기존 교육의 파괴수십, 수백명의 학생을 한 교실에서 가르치면 공부를 잘하는 학생을 기준으로 진도를 나가야 할까요? 못하는 학생을 기준으로 진도를 나가야 할까요? 둘 다 좋은 방법이 아닙니다. 공부를 잘하는 사람을 기준으로 가르치면 아직 미처 이해하지 못한 학생은 공부를 포기하게 되구요. 공부를 못하는 사람을 기준으로 가르치면 잘하는 학생은 자기가 알아서 하겠다며 수업을 듣지 않습니다. 이 모든 것이 학습이 개인화되지 않았기 때문입니다.내가 이번에 배워야 할 부분을 빠르게 배웠다면 먼저 다음 ‘노드 Node‘를 배울 수 있고, 아직 이해가 부족하다면 같은 노드라도 두 번 세 번 복습할 수 있게 하는 교육 설계. 이것이 저는 너무 필요한 ‘학습의 개인화’라고 생각해요. 즉, 입학은 같이 했어도 졸업을 모두가 같이 할 필요가 없다는 뜻입니다. 그러나 우리의 모든 교육은 입학과 졸업의 타이밍이 천편일률적으로 정해져 있습니다.또 다른 학습의 개인화의 예는 ‘수업 시간’과 ‘쉬는 시간’입니다. 왜 이게 분리되어야 할까요? 잘 생각해 보면 수업 시간에는 조용하고 쉬는 시간에는 왁자지껄 합니다. 저는 위에서 말씀드렸듯이 교실은 시끄러워야 한다고 생각해요. 왜 배움이 있는 수업 시간이 아닌 오히려 쉬는 시간에 시끄러워질까요? 저는 모두가 같은 시간에 배우고 같은 시간에 쉬는 시스템에 의문을 제기하고 싶습니다. 왜 모두가 같이 배우고 같이 쉬어야 할까요? 알아서 배우고 쉼이 필요할 때는 알아서 쉬면 안될까요? 쉬는 시간 같은 수업 시간, 수업 시간 같은 쉬는 시간이 시끄럽고 질문 많은 교실의 원동력이 되지는 않을까요?강사 없이 퍼실리테이션에 의존한 꿈의 AI 학교 아이펠을 적극 지원해준 고용노동부에 정말 큰 감사를 드리는 한편, 아무래도 외부 펀딩에 의존하다보니 교육 설계에 제약이 생길 수 밖에 없는데요. 아직은 AI 학교 아이펠이 이 정도의 학습의 개인화를 제공해주고 있지는 못합니다. 하지만 저는 학습의 개인화 부분에서 조금 더 교육을 파괴해 보고 싶다는 욕심이 있습니다.  아이펠, 퀘스트 시스템으로 더욱 강력해지다 (2023)2019년 시작된 코로나 바이러스로 인한 피해가 장기화되면서 우리 삶에서의 행동 자체가 변하게 됩니다. 오프라인이 아닌 온라인에서 만나는 것이 일상화 되고, 더 이상 오프라인으로 사람들이 나오기를 꺼려하게 되죠. 아이펠 역시 그에 맞추어 2022년 하반기부터 전국 8개의 오프라인 캠퍼스를 전면 온라인화 합니다.일반적으로 온라인에서 교육이 이루어지면, 집중도가 떨어지고 혼자 고립되어 있는 느낌이 강해지게 됩니다. 기존의 교육 방식을 그대로 고수해서는 적절한 학습효과를 얻을 수 없어요. 그래서 아이펠은 배움에 더 집중할 수 있도록, 함께 하는 친구와 같이 배워나갈 수 있도록 아이펠만의 퀘스트 시스템을 설계・도입하여 더욱 강력해졌습니다. 퀘스트 시스템의 핵심은 혼자 공부하는 것이 아닌, 커뮤니티형 교육이 무엇인지 체험하면서 활동 점수를 받고 실력을 성장시키는 것입니다. 아이펠의 퀘스트 시스템은 저희 PO Product Owner가 직접 소개한 글이 곧이어 공개될 예정입니다. 이제 퀘스트 시스템으로 한 층 더 강력해진 AI 혁신학교 아이펠에 여러분을 초대합니다! 

인공지능AI인공지능AI학교아이펠모두의연구소데이터사이언티스트AI부트캠프부트캠프딥러닝머신러닝