블로그

일프로

[kubernetes] 쿠버네티스 첫 오브젝트 잘 끼우기 #6

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 오늘 공부할 내용이 쿠버네티스에서 사용되는 오브젝트들의 한 20% 정도가 되지 않을까 싶어요. 그동안 공부한 양이 적지도 않았고언제 쿠버네티스를 다 배우나 무거운 마음일 수도 있는데 제가 좀 안심이 되는 얘기를 드리면..혹시 파레토의 법칙 이라고 들어보셨나요? 예를들어, 우리나라의 20% 인구가 80%의 땅을 갖고 있다던가, 회사에 100명이 일하고 있는데 20명이 사실 그 회사에 80% 일을 하고 있다는 거죠. 수학적으로도 증명 가능한 말이라고 하고요.결국 원인의 20%가 80%의 결과를 만들어낸다는 뜻인데 저는 이번 강의를 이렇게 말씀드릴 수 있을 것 같아요. 오늘 배울 20%의 오브젝트들이 앞으로 쿠버네티스에서 자주 쓰는 오브젝트의 80% 입니다. 그렇기 때문에 오늘 강의가 정말 중요하고 이번 블로그도 끝까지 잘 읽어 주시길 부탁 드릴게요.   이번 강의는 제가 오랜 시간 걸려서 쿠버네티스를 이해했던 단계들을 바탕으로 구성을 한 거고요. 오브젝트를 잘 이해하는 방법으로 세 가지 단계를 준비를 했습니다.쿠버네티스의 어떤 기능은 그림을 그려볼 때 이해가 쉽고, 어떤 기능은 실제 App이랑 동작을 하는 걸 봐야지 이해가 정확해요. 그리고 어떤 기능은 쿠버네티스 내부 동작을 아는 게 중요한데, 이번 수업에서는 [Object 그려보며 이해하기]만 다룰 거고요. Object 그려보며 이해하기카페 실습 자료실 링크 (link) 이 단계에서는 위 강의 자료실에 실습으로 사용될 yaml 파일을 읽어보면서 오브젝트들을 하나씩 그려보고, 각 오브젝트들에 대한 역할이나 기능들을 살펴보겠습니다.이제 Object들을 하나씩 그려 보면서 역할이나 기능들을 간략하게 설명을 드릴게요.Namespace를 보면 Namespace는 Object들을 그룹핑 해주는 역할이에요. 그리고 metadata에 name이랑 label이 있는데 일단 그림만 그려놓고 넘어갈게요.그리고 다음으로 Deployment는 Pod를 만들고 업그레이드를 해주는 역할이구요. 여기에 namespace로 위에서 만들었던 이름이 있죠? 이렇게 하면 이 Deployment는 이 Namespace에 소속이 됩니다. 그리고 여기 이름이 있는데 한 namespace 안에서 이 이름은 중복이 되면 안되요. 그리고 label이랑 이 selector는 앞으로 계속 나올텐데 한번에 정리를 해서 설명을 드릴 거라 일단 이런 게 있다고만 알고 넘어가고요.그리고 replicas는 pod를 2개를 만들라는거고 strategy의 RollingUpdate는 deployment 기능의 핵심인데, 이 업데이트 방식에 대해서는 다음 강의에서 실습으로 해볼거에요. 그리고 template 부터가 이 내용대로 pod가 만들어진다고 보면 되는데, nodeSelector는 pod를 띄울 노드를 선택하는 거고 containers라는 속성이 있고 그 밑에 옵션들이 쭉 있는데 이 image는 제가 DockerHub에 이 이름으로 컨테이너 이미지를 올려놨기 때문에 여러분들이 이 image에 이렇게 넣으면 다운을 받아서 쓸 수 있는 거예요.  그리고 밑에 envFrom가 있고 configmap과 연결이 되어 있는데, Application에 환경 변수랑 관련된 부분이고 configmap은 그 값을 제공해 주는 역할을 해요.그 밑에 프로브들이 3개가 있는데 startupProbe는 App이 잘 기동이 됐는지 체크를 하고 있다가 기동이 안 되면 App을 재기동시키고요. 잘 됐으면 이 밑에 readinessProbe랑 livenessProbe를 시작 시켜요. 그래서 readinessProbe는 App에 트래픽을 연결 할 건지를 결정하는 속성이고 이 livenessProbe는 App이 정상이 아니면 재시작을 시킬 건지 판단하는 속성이에요. 정말 중요한 속성이고 이건 실제 App기능을 보면서 자세히 이해를 해 볼 거고요.다음으로 resources는 pod에 CPU랑 memory를 할당을 시킬 거고 최대 limit까지 쓸 수 있다는 설정이 있는데 이걸 설정하지 않으면 pod가 노드의 자원들을 모두 써버리게 됩니다.그리고 volumeMounts가 있는데 이 mountPath는 pod 내부에 만들어지는 디렉토리이구요. 이 이름이랑 volumes에 이 이름이 매칭이 되서 실제 persistentVolumeClaim이라는 object랑 연결이 되는 거에요. 그리고 secret-datasource도 이렇게 name으로 연결이 되면서 secret object랑 연결이 됩니다.  다음으로 Service고요. 이렇게 metadata 3세트는 자주 나올 거예요. namespace에 속한 object고 name이랑 labels이 있죠. 그리고 밑에 selector랑 ports, type이 있는데, 이 Service의 역할은 pod한테 트래픽을 연결시켜 주는거에요. 근데 이름을 보면 한 namespace안에는 이름이 중복되면 안 된다고 했잖아요? 정확히는 같은 종류의 object끼리 이름이 같으면 안 되는 거예요. 그래서 Service랑 Deployment는 서로 다른 object라 이름이 같아도 되고요.이제 ConfigMap을 보면 pod의 환경변수 값을 제공하는 역할이고요. 이렇게 metadata 3세트랑 그리고 data가 있는데 이게 아까 말했던 환경변수로 들어갈 값의 내용이에요. 그리고 밑에 Secret도 ConfigMap이랑 비슷한데 pod에 좀 더 중요한 값을 제공하는 역할로 쓰여요. 다음 강의에서 App기능을 실습을 해보면서 좀 더 이해를 해 볼게요. 여기서는 data가 아니고 stringData가 있는데 좀 다르죠? 이렇게 쓰면 stringData 내용들이 pod 안에 파일로 만들어집니다.  그리고 PersistentVolumeClaim이 있고 pod에서 pv를 지정할 때 사용을 하는데, 밑에 저장 공간을 얼마나 사용할지 그리고 이 저장 공간의 accessModes로 읽기/쓰기가 가능하다는 옵션이 있는데, 이 내용은 이번 실습에서는 동작하지 않고요. 그냥 필수값이라서 넣어둔 거라 다음번에 Volume만 다루는 강의에서 다시 설명을 드릴게요. 이번 실습에서는 selector만 쓰입니다.그리고 다음으로 PersistentVolume인데, 실제 Volume을 지정하는 역할을 하고요. 근데 여기에는 namespace가 없죠? 이 object들의 가장 큰 범위가 Cluster거든요. Namespace도 Cluster 안에 속해 있는 object고요. PV도 여기에 만들어지는데,object들은 크게 두 분류로 나뉘어요. Namespace랑 PersistentVolume은 Cluster Level의 Object라고 하고요. Deployment랑 Service들은 Namespace Level에 Object라고 해요. 그리고 각 object들은 자신의 level이 있기 때문에 Deployment는 PV처럼 Cluster level에 만들어 질 수가 없습니다.다시 PV로 돌아와서 마찬가지로 이런 내용들은 일단 넘어가고, local이 중요한데 path를 volume으로 사용하겠다는 내용이에요. 그리고 그 대상 노드는 밑에 nodeAffinity가 있는데, 좀 복잡해 보이지만, nodeSelector랑 똑같이 결국 Master Node를 지정한다는 내용입니다. 그래서 여기에 path가 사전에 없으면 PV를 만들 때 문제가 생기기 때문에 디렉토리를 미리 만들어 준 거고요.  그리고 이제 마지막으로 HPA인데, 부하에 따라 pod를 늘려주고 줄여주는 스케일링 역할을 하구요. scaleTargetRef로 그 스켈링 대상을 지정을 하고, min/maxReplicas는 최소 두 개의 pod를 유지를 하고 있다가 부하가 생기면 최대 4개까지 늘어나도록 설정을 한 거예요. 그리고 metrics라는 설정은 pod의 cpu가 평균 40%가 늘어나면 스케일 아웃을 하라고 설정을 한 겁니다. 그리고 밑에 behavior는 pod가 한번 증가를 한 후에 600초, 그러니까 10분 동안 또 pod가 추가적으로 늘어나지 않게 하는 설정인데, pod가 2개에서 3개로 늘어나자마자 부하가 더 증가한다고 해서 바로 4개로 늘리고 싶진 않을 때 이런 설정을 해요.그리고 마지막으로 namespace에 대한 기능을 하나 더 말씀드리면, namespace를 삭제하면 이 안으로 만든 모든 object가 같이 삭제가 되거든요. 그래서 실습을 하고 강의에서 배포한 object를 모두 삭제를 할 때는 이 namespace를 삭제하는 명령 하나만 날리면 되구요. PV는 namespace에 속하지 않기 때문에 별도로 한번 더 삭제를 해 줘야 되요.그럼 여기까지 오브젝트들을 봤는데 지금 좀 혼란스럽고 이해가 안되는 상황이라면 그게 맞아요. 현재까지는 각 object들이 어떤 역할을 하는지 대략적인 느낌만 이해를 하면 됩니다 :)  Object 그려보며 이해하기 - (label/selector/naming) (1)제가 대리 때, 팀에 차장님 한 분이 새로 들어오셨는데, 같이 일 한지 한 두 달이 넘었을 때였어요. 옆팀 부장님이 저한테 새로 온 차장님 이름을 물어보시더라고요. 근데 저는 평소 강차장님이라고만 불러서 이름은 처음 인사를 할 때 듣고 까먹은 상태였거든요. 나중에 확인해 봐야지 하면서 차일피일 미루고 있었는데, 다행히도 이 부장님께서는 제 대답에 딜레이를 느끼시고 바로 다른 분한테 물어봤습니다. 근데 저는 이 상황이 많이 부끄러웠어요.여러분도 이렇게 시간이 어느 정도 지났을 때 모르고 있으면 부끄러워지는 상황들이 있지 않나요?지금부터 배울 이 내용이 바로 그런 느낌이에요. 저도 실제로 쿠버네티스를 시작하고 2년 정도가 지나서야 이 부분을 신경쓰기 시작했는데, 해당 내용은 강의 영상에서 잘 설명을 드릴 예정이고 여러분들은 부디 저와 같은 실수를 하지마시고 잘 챙기시길 당부 드릴께요. Object 그려보며 이해하기 - (label/selector/naming) (2)여기까지 읽으시느라 정말 수고하셨고요. 처음 이런 내용을 들으시는 분께는 뭔가 많은 내용처럼 보일 수도 있지만 정말 자주 쓰는 기능들이고, 조금만 쓰다 보면 금방 익숙해지는 부분들이니까 너무 부담 갖지 마세요.그럼 오늘 블로그는 여기까지 마치겠습니다. ps. 뒤로가기 함부로 누르지마라. 너는 누구에게 한 번이라도 좋아요♡를 준 사람이었느냐 :)

데브옵스 · 인프라인프런쿠버네티스어나더클래스지상편일프로kubernetesdevopskubeops첫오브젝트잘끼우기

일프로

[쿠버네티스] 컨테이너 한방 정리 #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] 실무에서 느껴본 쿠버네티스가 정말 편한 이유 #5

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 저는 개발자로써 SI 프로젝트를 많이 했습니다. 그리고 제가 겪은 SI에 대해서 얘기 드리면..일단 개발에만 몰두할 수 있는 시간은 별로 없어요. 제안서 쓰고, 업무 프로세스 분석하고, 단계별 문서를 만들고 상황에 따라 인프라 구축도 하고, DB부터 Web Front까지.. 프로젝트 오픈에 필요한 많은 걸 경험해 봤어요.물론 이것도 하다 보면 익숙해지는 부분도 있지만 그래도 매번 SI프로젝트를 힘들게 만드는 요인이 뭐냐면하나는 매번 다른 업무 프로세스에요. 고객사마다 업무 프로세스가 다르니까 매번 새 업무를 분석하느라 고생을 하게 되고요. 그리고 변화가 빠른 웹 기술이에요. 웹 분야는 발전 속도가 빠르고 신 기술이 많아서 프로젝트를 할 때마다 같은 기술로 웹 페이지를 만들어 본 적이 별로 없었던 것 같아요. 그래서 매번 새로운 기술을 공부해야 됐고. 마지막으로 다양한 기술 솔루션 적용인데, 모니터링이나 로깅, 암호와 같은 솔루션이 고객사마다 쓰는 제품들이 다르고요. 비용 절약 때문에 개발자가 직접 해야 되는 경우도 비일비재해요. 그래서 이것도 매번 새 솔루션을 적용하는 법을 익혀야 됐습니다.더 많지만 이렇게 이번 프로젝트에서 고생을 해서 기술을 익혀도 다음 프로젝트는 또 고생을 하게 되더군요.하지만, 개발자가 아닌 쿠버네티스 엔지니어로서 SI프로젝트는 할만 했습니다.무엇보다 프로젝트가 반복될 수록 일은 더욱 쉬워졌는데, 이번 강의에서 [쿠버네티스 표준 생태계로 편해진 IT인프라 구축], [쿠버네티스 기능으로 편해진 서비스 안정화], [인프라 환경 관리의 코드화]를 주제로 그 이유를 자세히 설명 드려요.쿠버네티스 표준 생태계로 편해진 IT인프라 구축쿠버네티스가 나온 지 10 년도 안 됐는데, 현재 이렇게 많은 제품들이 쿠버네티스 생태계 위에서 돌아가요.IT에 관련된 모든 회사가 쿠버네티스와 컨테이너에 진입을 했다고 해도 과언이 아닐 정도인데, 이미 많은 회사들은 컨테이너가 미래에 인프라가 될 거라는 걸 예상했고 너도나도 이 시장의 넘버원이 되려고 뛰어 들었어요. 그 결과 정말 짧은 시간만에 쿠버네티스 기반의 IT 생태계가 이렇게 폭발적으로 커졌습니다.여러분 지금 기업에서 대부분 자바로 개발을 하잖아요. 자바가 95년도에 처음 만들어졌고 10년 뒤에 이걸로 스프링이 나왔어요. 그리고 또 5년이 지나서야 확산이 되기 시작한 건데, 그에 비해 쿠버네티스는 정말 이례적이라고 할 수가 있죠.근데 이 그림을 보면, 아 이제 늦었나? 쿠버네티스를 하려면 이렇게 많이 알아야 돼? 라고 오해를 할 수가 있을 것 같아요. 뭔가 많아 보일 순 있는데 점점 제가 단순화를 시킬 거니까 걱정 마시고요.CNCF에서 이 클라우드 생태계를 영역별로 카테고리화 시켰는데,[개발]은 기존부터 해왔던 App 개발에서 배포까지 써야되는 기술들 이고요. [오케스트레이션 / 매니징]은 이 App을 마이크로 서비스로 만들 때 쓰면 좋은 기술들이에요. 그리고 [플랫폼과 런타임]은 이 App을 클라우드로 올릴 때 주로 사용되는 기술들이 많고요. 그리고 [프로비저닝이랑 분석]은 실제 프로젝트에서 써야 되는 기술들이 있어요.만약에 프로젝트에서 App을 마이크로 서비스로 개발하고 클라우드까지 올린다면 여기 있는 카테고리를 다 알아야 되고 근데 요즘은 이런 프로젝트가 대부분이죠 :)그나마 불필요하다고 생각하는 부분은 그리고 밑에 [스페셜]은 쿠버네티스 관련 업체들이랑 교육 파트너고요. [서비스]랑 분석 쪽에 [카오스 엔지니어링]이랑 [최적화]부분은 메인 영역은 아니라서 과감히 빼버리겠습니다. 그리고 전체 그림을 다시 보면..아까보단 좀 나아진 거 같나요?이미지들이 살짝 눈에 보이는 거 같기도 하고요. 그래도 아직 쿠버네티스를 하기 싫어지는 그림이에요. 여기서 이제 디테일하게 줄여나가 보겠습니다. CNCF에 기여된 프로젝트는 성숙도에 따라서 이렇게 4가지 종류가 있는데, Sandbox는 아직 실험 단계라서 우리가 안 쓰게 될 확률이 커요. 그리고 그 밑에 Archived는 프로젝트가 비활성화 된 거에요. 그래서 더 이상 기술 지원이 없는 프로젝트니까 이 두 가지를 빼고요.CNCF에서 성숙도가 높다고 우리가 많이 쓰고 있는 건 아니거든요. 그래서 Graduated지만  Github에 Stars 수가 낮은 건 제외를 하고 Incubating 이지만 Stars 수가 높은 건 포함해서 보면..이정도가 있네요. 그리고 CNCF에 기여된 프로젝트 외에 CNCF 멤버와 비멤버 제품들도 있어요. 멤버와 비멤버의 차이는 CNCF에 회비를 내면서 제품 홍보나 등급별로 혜택을 받을 수 있나없나의 차이일뿐이고, 그래서 비멤버라도 표준 생태계에 영향력 있는 제품들이 많습니다.그래서 CNCF 멤버/비멤버 제품들 중 Github에 Stars 수가 높은 걸 골라보면.. 이 정도로 정리가 돼요. 이제 이렇게 추린 내용을 다시 이쁘게 정리해보겠습니다. 참고로 제가 짬으로 몇 개 추가/삭제한 것도 있어요.CNCF landscape 중 선별 기준CNCF 프로젝트 : Graduated Projects (Github Stars 낮음 제외), Incubating Projects (Github Stars 높음 추가), Sandbox Projects (X), Archived Projects (X)CNCF 멤버/비멤버 제품 : 깃허브 Stars 높음 추가, 일프로 임의 추가참고 링크 : CNCF (link), CNCF landscape (link) 이제 좀 그림이 보이기도 하고, 안구 정화가 되죠?눈에 잡히는 IT생태계를 보여 드리려고 이렇게 정리를 해 봤는데, 사실 CNCF를 졸업했고 멤버가 어떻고는 중요하지 않아요. 그리고 제가 이 정리된 그림을 먼저 보여 드려도 되는데 이런 선별 과정까지 보여 드린 이유가 있습니다.이 오픈 소스들을 공부하게 될 때 이것만 잘 깊이 있게 보면 좋은데 갑자기 누가 요즘 뭐가 좋다더라 이런 얘기를 하면 자기가 모르는 게 있으면 괜히 그게 커보이고 해야될 것 같은 기분이 들죠? 그래서 지금 공부에 집중력이 떨어질 수가 있어요. 그렇기 때문에 여기 이 제품들은 정말 많은 오픈 소스들 중에 대표이고 일단 처음엔 여기에만 집중해도 충분하다는 것을 보여 드리려고 이렇게 선별과정을 보여 드린거에요.물론 이것도 적지않죠?그리고 강의 영상 마지막에 쿠버네티스 엔지니어가 되려면 이 많은 내용들을 어떻게 공부해야 되는지 이 그림으로 설명드릴께요.   쿠버네티스 기능으로 편해진 서비스 안정화 강의에서는 쿠버네티스가 편한 이유 중 두 번째로 기존 VM 환경과 쿠버네티스 환경의 차이를 얘기드려요. 기존 환경에서 여러 담당자들이 수동으로 설정해야 했던 일들을 쿠버네티스 환경에서는 쿠버네티스 엔지니어 한명이 한번에 할 수 있게 되거든요.  모니터링 설치이젠 모니터링 설치하는 방법도 너무 쉽죠?카페 설치 링크 (link)참고 링크 : grafana docs (link) / dashboard (link), prometheus install (link) / docs (link), loki-stack install (link) / docs (link)기능 실습그리고 강의영상에서 쿠버네티스 대표 기능들을 실습해 봅니다.카페 실습 링크 (link)인프라 환경 관리의 코드화마지막으로 쿠버네티스 관리 환경의 코드화인데, 인프라 설정을 수동으로 하는 거랑 파드에 인프라 설정이 코드로 들어가서 자동으로 되는 건 엄청난 차이고요. 이 차이가 인프라 환경 관리를 정말 편하게 해줍니다.쿠버네티스, 인프라 환경 관리의 장점인프라에 대한 History 관리가 편해짐인프라 작업 추적 가능인프라 환경별 파일 생성 (시간 있을 때 미리 구성 가능, 작업은 Copy & Paste)인프라 반복 작업 x, 퀄리티 향상에 집중새 인프라 작업시 이전 경험을 녹인 코드 활용블로그는 여기까지고 강의가 오픈 되면 링크 걸어 놓을게요^^굿나잇! ps. 매너가 좋아요♡를 만든다 :)

데브옵스 · 인프라인프런쿠버네티스어나더클래스지상편일프로kubernetesdevopskubeopscontainer쿠버네티스편한이유

일프로

Application 기능으로 이해하기-Configmap, Secret #7-2

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy전 처음 이 개념을 공부할 때, 책에서 설명을 읽으면서 "아 이거 알지", "이번 챕터는 거저 먹었네" 하고 챕터를 넘겼었거든요. App의 값을 넘겨주는 방법으로 환경변수를 사용하고 민감한 데이터일 경우, 암호화를 시켜서 파일에 담는 건 기존에 또 사용했던 방법이고 쿠버네티스의 Configmap과 Secret이 그 역할을 해준다는 거니깐요.근데 의외로 이 개념을 실무에서 쓰면서 목소리가 커질 일이 종종 생겼습니다일단 제가 처음 알았던 만큼만 설명을 드려볼게요 Configmap, Secret 개념 설명 Configmap과 Secret은 Pod에 바로 연결되고요. Object에 속성들을 보면 둘 다 데이터를 담을 수 있어요. 그래서 사용자가 데이터를 넣고 Pod에 값을 주입 시킬 수가 있는데, Pod에 연결되는 속성 이름을 보면 어떤 방식으로 들어가는지 알 수 있습니다.envFrom은 Pod안에 환경변수로 들어가게 하는 속성이고, 그래서 Configmap을 연결하고 Pod 안에 들어가서 env라는 명령을 쳐보면, 이 Configmap의 data가 주입 된 걸 볼 수가 있어요.Volume은 Pod와 특정 저장소를 연결하는 속성이고, Secret을 연결하고 Pod 안에 들어가서 마운팅 된 Path를 조회해보면, 이 Secret의 stringData가 있는 걸 볼 수가 있고요.특별히 어려운 내용은 없죠?아무리 처음 쿠버네티스를 공부하시는 분이더라도 환경변수와 마운팅의 개념은 기존에도 써왔기 때문에 쉽게 이해할 수 있어요. 그리고 Secret은 이름 부터가 뭔가 비밀스럽게 데이터를 처리해 줄 것 같은 느낌이 있으니까. 쿠버네티스에서 데이터에 어느 정도 보안을 적용해주는 가보다 생각할 수 있죠. Configmap 기능 설명Configmap의 데이터가  Pod에 환경변수로 들어간다고 얘기했는데, 환경변수에 들어가는 값은 다양하고요. Data에 내용을 보면 Key, Value 형식으로 spring-profiles-active에 dev가 있죠? 환경 변수로 흔히 들어가는 값인데, 인프라에 다양한 환경 개발/검증/운영 등에 환경이 있고, 이 App이 어느 환경에서 돌아가는 건지 App이 기동되는 시점에 알려주기 위한 변수에요.다음 환경변수에는 Application Role이라는게 있고. 말 그대로 이 App에 역할을 지정하는 건데, 예를 들어 한 App에 3가지 기능이 있는데, App 하나만 띄어서 모든 기능을 다 쓰기도 하고요. 스케일링 모드라고 해서 이 App을 기능별로 3개를 띄우고 부하가 많은 기능만 별도로 더 띄워요. 요즘은 마이크로 서비스 아케텍쳐를 반영해서 이렇게 만들어진 오픈소스도 많습니다.밑에 postgresql-filepath는 또 다른 예인데, 이건 여기 Secret 데이터로 연결할 파일에 경로에요. 이 경로는 Pod에 mountPath에서 정하거든요. 그리고 이 경로 DB 정보를 환경변수로 주면, App은 기동 될 때 이걸 읽어서 DB에 접속할 수 있도록 로직이 되있는데, 이 경로를 이렇게 환경변수로 입력해야 Pod에서 이 경로를 바꾸게 됐을 때 App을 다시 빌드해서 새 이미지를 만들지 않고, Configmap만 수정해서 App이 변경된 경로를 인식할 수 있도록 할 수 있겠죠?이렇게 외부에 변경되는 환경이 생길 때, 그걸 App에 전달해 주기 위한 값들도 있는거고, App 내부적으로 기동되는 시점에 이 환경변수 값에 따라 다르게 처리되는 로직이 있어야 되요.자 그럼 이제 이 내용을 Pod랑 연결을 하고 Pod가 생성됐을 때 상황을 얘기 해볼께요. 처음에 Configmap에 있는 data의 모든 내용이 컨테이너 내부 환경에 환경변수로 주입이 됩니다. 그리고 이 이미지를 만들 때 이런 자바파일 실행 명령을 넣어놨거든요. 이미지를 만드는건 sprint2에서 배울꺼고 이 명령이 컨테이너 생성 후에 자동으로 동작하게 되고, 이때 환경변수 값이 들어가는데, 만약에 환경변수로 spring-profiles-active가 없었다면 null값이 들어가게 되요. 밑에 Secret의 기능 설명과 두 기능에 대한 동작 확인은 강의 영상으로 설명 드리고요. Secret 기능 설명동작 확인영역 파괴의 주범 ConfigMap기존 VM환경이랑 쿠버네티스 환경의 배포 차이를 보면서 영역 파괴의 주범인 ConfigMap에 대한 얘기를 해볼께요. 각 환경마다 Pod가 만들어지고, 이 Pod에 들어가는 컨테이너는 dockerhub에서 모두 같은 이미지를 다운 받았어요. 하지만 환경마다 다른 값을 주려고 각각에 Configmap을 만들죠. 그리고 이미지 안에 변수값을 받아서 실행하는 명령어가 들어 있어요.이제 개발환경을 보면 이렇게 spring으로 개발을 하고 여기서 [개발자]가 Properties 파일들이 만들고 관리를 해요. 그리고 Github로 소스를 커밋하면, 여기서부터는 [데브옵스 엔지니어]가 Jenkins에서 이 소스를 받아서 파이프라인을 구성하는데, 소스 빌드와 컨테이너 빌드 과정에서 컨테이너 이미지가 도커 허브로 올라가요. 그리고 컨테이너 빌드 후에 개발환경을 바로 이어서 배포를 할 수 있고, qa와 prod는 필요할 때 배포 버튼을 따로 누르게 구성해 놨다고 해보겠습니다.그럼 VM 환경의 배포는 어떤지 보겠습니다.개발 환경과 CI/CD 환경은 비슷하고, [인프라 담당자]가 환경별로 서버를 세팅해 놓습니다. 각 환경별로 OpenJDK도 설치해 놓고요. 이 과정에서 VM 내부에서 사용할 환경변수들을 관리를 하죠. 그리고 배포는 이렇게 되는데, Jar 패키지 파일을 VM 환경에 복사 해놓고, 실행 명령을 직접 날리는데 이때 [데브옵스 관리자]이 App에 환경이나 목적에 맞는 변수를 넣어요. 그리고 환경이나 목적에 맞게 변수값이 채워진 스크립트를 실행시킵니다.그래서 여기까지 보면 쿠버네티스 환경 이전에는 각자의 영역에서 담당자들이 관리하는 환경변수들이 있었는데, 쿠버네티스가 나오고 이 ConfigMap에서 모든 역할을 다 할 수가 있게 된 거죠. 그래서 ConfigMap을 담당하는 사람이 다른 영역을 넘나들 수 있게 되고 이런 소지를 주는 Configmap을 좀 과격한 표현으로 영역 파괴의 주범이라고 표현을 한 건데.물론 이 전체를 혼자 다하는 슈퍼 개발자도 있겠지만, 프로젝트가 클 수록 각 영역에 담당자들이 있고요. 현재 이 모두가 쿠버네티스를 다 다룰 줄 아는게 아니기 때문에 만약 개발자가 쿠버네티스를 잘하면, 이 Properties 값들 중에 Pod를 재생성하기만 하면, 다시 빌드하지 않고 바로 반영될 수 있는 값들을 많이 집어넣겠죠? 그러다가 다른 영역에 있는 값들도 넣으면서 일을 주도하게 될꺼예요.하지만 다른 담당자 입장에서는 본인의 영역을 침범 당한다고 생각할 수 있는데, 참 별거 아닌 기능이지만, 여러 영역에 걸쳐 있는 기능이기 때문에 의견을 잘 조율을 해서 써야 되는 점 주의하시길 바랄께요. 이름 때문에 기대가 너무 컸던 Secret이 부분은 강의 영상을 확인해 주시고, 강의에서 만나요! ps. 좋아요♡는 준 만큼 받는다 :)

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

일프로

[쿠어클#4] 쿠버네티스 무게감 있게 설치하기

안녕하세요. 쿠버네티스 제대로 시작하기 첫 강의로 쿠버네티스 환경 구축을 해보겠습니다.아래 정말 쉽고 빠르게 쿠버네티스를 설치하는 방법이 있어요! 쿠버네티스(v.1.27.2) 쉽고 빠르게 설치하는 방법Virtualbox 설치 (link)Vagrant 설치 (link)Vagrant 스크립트 실행 (윈도우 > 실행 > cmd > 확인)# Vagrant 폴더 생성 C:\Users\사용자> mkdir k8s C:\Users\사용자> cd k8s # Vagrant 스크립트 다운로드 C:\Users\사용자\k8s> curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/Vagrantfile # Rocky Linux Repo 세팅 C:\Users\사용자\k8s> curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/rockylinux-repo.json C:\Users\사용자\k8s> vagrant box add rockylinux-repo.json # Vagrant Disk 설정 Plugin 설치 C:\Users\사용자\k8s> vagrant plugin install vagrant-disksize # Vagrant 실행 (VM생성) C:\Users\사용자\k8s> vagrant upMobaXterm 설치 (link)Master 원격 접속 : 192.168.56.30:22 (root/vagrant)Pod 확인kubectl get pods -A대시보드 접속 URI : https://192.168.56.30:30000/#/login FAQ : virtualbox 설치 안될 때 (link), vagrant up 안될 때 (link), dashboard 관련 (link), virtualbox Host-Only Network cidr 변경 (link)Cafe : 쿠버네티스 빠른 설치 카페 참조 (link)  정말 쉽죠?하지만 저는 쿠버네티스 설치를 쉽고 빠르게 한다고 해서 좋은 건 아니라고 생각합니다. 쿠버네티스 오브젝트들, Pod나 Service를 공부하면서 개념이나 기능만으로 이 기술을 이해하는데는 한계가 있거든요. 쿠버네티스 자체 구성을 조금은 알고 이 개념들을 공부하는게  더 잘 이해가 잘 되요. 그리고 쿠버네티스 구성에 대한 부분들은 쿠버네티스를 설치할 때 가장 배우기 좋은 내용입니다.그렇기 때문에 Pod를 빨리 만들어보고 싶은 마음도 이해하지만 쿠버네티스를 제대로 공부하고 싶으신 분이시라면, 이번 설치 강의를 통해서 쿠버네티스 구성을 꼭 이해하고 넘어가길 권해드려요. 아니 꼭 이렇게 하셔야되요! 쿠버네티스 무게감 있게 설치하는 방법 1/2먼저 설명에 시작은 내 PC에 Virtaulbox랑 Vagrant를 설치한 상태고요. 제가 만든 Vagrant 설치 스크립트를 받으면 위에 내용이 나와요. 그리고 이 스크립트는 크게 [Virtualbox로 Rocky Linux를 생성]하는 파트랑 [kubernetes를 설치]하는 파트로 구분되는데 먼저 Virtualbox로 VM을 생성하는 걸 설명 드릴께요. 우측 스크립트를 위에서 부터 보면, OS를  [rocky linux 8]버전으로 설치하라는 내용이고, 처음 설치할 때는 이 이미지를 다운 받는데 시간이 좀 걸려요. 그리고 [master-node]는 Virtualbox 입장에서 생성된 VM에 이름을 붙여주는 부분인데, Virtualbox UI 상으로 봤을 때 보이는 이름 이예요. 그리고 밑에 hostname 을 지정하는 부분이 있고, [k8s-master] 라고 넣으면, 나중에 원격접속으로, 리눅스에 들어 갔을 때, 나오는 호스트 이름입니다.  그리고 밑에 [private_network]는 virtualbox에 Host-Only Network 라고 해서, 내 PC 에서만 사용할 수 있는 네트워크망을 만들어 주고, 스크립트에서 IP를 주면 내 Linux에 그 IP가 할당됩니다. 그래서 우리는 내 PC에서 이 IP로 원격 접속을 하면 Linux OS에 들어갈 수 있게 되는 거고. 브라우저를 통해서 kubernetes dashboard에 접속 할 수도 있게 되요. 이렇게 이 스크립트 한 줄로 Host-Only Network가 만들어지고 IP가 할당 되는데, 스크립트에 넣지 않아도 Vagrant가 기본적으로 만들어주는 네트워크가 있어요.바로 NAT 라는 네트워크고 입니다. IP도 알아서  할당 돼요. 이 NAT의 역할은 내 VM을 외부 인터넷이랑 연결 시켜줍니다. 그래서 이따가 쿠버네티스를 설치할 때 필요한 패키지들을 받는데 사용하고요 실제 내 PC에 할당된 Network는 공유기에서 할당 받은 상태죠. 제 PC의 경우 [192.168.219.100]의 주소를 할당 받았고요. 제 공유기는 192.168.219까지는 고정이고, 뒤에 4번째 자리는 1~255까지 만들 수 있는데 자동으로 100이 할당 된 거예요.근데 Host-Only Network를 보면 디폴트로 192.168.56까지 고정이고, 네 번째는 1~255까지 만들 수 있는 네트워크 입니다.네트워크를 생성할 때 cidr 을 정하면, 이렇게 지정한 범위 내에서 IP가 할당 되는데, 네트워크 원리는 잘 몰라도, 최소한 대역들이 겹치면 안된다는 건 알고 계셔야 돼요. 겹치게 되면 내 공유기랑 Virtualbox가 똑같은 IP 를 만들 수 있게 돼서 IP 충돌이 나요. 근데 이 공유기 환경이 개인 마다 다른 부분이라서 혹시 원격 접속이 안되시는 분은 본인에 Network 대역을 확인해 보시고요. 부득이한 경우 Host-Only Network에 cidr 을 수정해 주면 돼요. 제가 카페에 방법을 올려 놓을께요. 여기까지 네트워크에 대한 설명이 이었습니다.이번엔 자원(resource)을 볼께요.스크립트를 보면 VM에는 Memory는 4G고 CPU는 4Core를 잡았어요. 제 PC에 자원을 보면 제 PC는 4Core, 16G Memory거든요. 여기서 분명 Memroy는 내 자원에서 나눠 주는 거라 VM에 자원 할당한 게 이해 되는데, CPU를 이렇게 다 줘버리면 내 PC는 괜찮을까 걱정되는 분이 계실 거예요.근데 이 두 자원의 속성을 보면 Memory는 서로 할당된 공간을 침범하면 안돼요. A프로그램이 쓴 메모리 공간에 B프로그램이 침범해서 내용을 바꿔버리면 안되잖아요? 그래서 꼭 자원을 철저하게 분할해서 써야 되는 성격이라면, CPU는 필요로 하는 순간에 서로 나눠 쓰는 자원이예요. 그래서 현재 이 CPU 할당에 의미는 내 PC CPU가 필요할 때는 4 Core를 다 쓸 수도 있고. VM에서도 필요할 때도 최대 4Core를 다 쓸 수 있도록 설정 한 건데, 만약 둘 다 CPU가 필요한 상황이라면 이 4core 자원을 나눠쓰고요. 대신 처리속도는 좀 느려지지만 문제는 없어요.참고로 쿠버네티스 설치 문서에 권고하는 CPU는 2Core 이상입니다.이 CPU와 Memory에 대해서 제가 4 Core를 준 이유와 각자가 작업 유형에 맞게 변경을 하시라고 자세히 설명 드렸지만, 이 두 자원에 대한 성격은 쿠버네티스에도 Pod에 자원을 할당하거나 Pod가 늘어나는 설정을 할 때, 정말 중요하게 고려해야 되는 포인트라서 이 자원에 성격을 자세히 얘기 해봤어요. 쿠버네티스 무게감 있게 설치하는 방법 1/2 [구간별상태확인]카페(아직 공사중)에 들어가보면 각 포인트에 대해서 잘 설치됐는지 확인 볼 수 있어요. (link)  쿠버네티스 무게감 있게 설치하는 방법 2/2위 내용은 강의의 메인으로 쿠버네티스 설치인데 강의에서 자세히 설명 드립니다. 지금까지 설명 드린 강도랑 내용보다 좀 더 깊어지는 점 주의 드려요.쿠버네티스 설치는 확실히 쿠버네티스 문서(link)를 보는게 좋습니다. 내가 설치하려는 버전이 있는데 블로그에서 다른 버전이나 최신버전 설치를 보게 되면, 미묘하게 잘 안되는 부분들이 생기거든요. 그래서 그 원인을 찾는데 시간을 더 쓰는 경우도 생기는데, 쿠버네티스는 컨테이너 한방 정리에서 히스토리로 봤듯이 내부적인 변경사항들이 많아서 그래요. 그래서 쿠버네티스 문서에서 필요한 버전별로 설치 가이드를 보는 게 좋고 쿠버네티스 문서가 한글화도 잘 되있거든요. 전 이 한글화 된 문서를 정말 열심히 보고 있고 이 한글화 작업하시는 분들께 항상 감사 드리는 마음입니다. 이 강의 설명의 목적은 쿠버네티스 설치 문서를 함께 공부하면서, 수강생 분들이 이 강의를 잘 들으면 이 강의에 설치 뿐만 아니라 다른 버전으로 쿠버네티스를 설치하거나 컨테이너 런타임을 바꿔보고 싶을 때 스스로 찾아서 할 수 있는 능력을 길러 드리는 거예요. 쿠버네티스 무게감 있게 설치하는 방법 2/2 [구간별상태확인]마찬가지로 카페(아직 공사중)에 들어가보면 각 포인트에 대해서 잘 설치됐는지 확인 볼 수 있어요 (link) 나중에 다른 사람과 똑같이 쉽게 쿠버네티스를 설치하더라도 이렇게 공부하면 한번에 클릭이 좀 더 무게감 있는 사람이 됩니다. 가끔 보면 그냥 빨리빨리 버튼 누르고 진행할 수 있는 상황에도 버튼 하나 누를때마다 한참 생각했다가 누르는 사람이 주변에 있지 않나요? 그 사람이 아는 게 많을 수록 이 버튼 누르는 속도는 더 느려져요. 이 사람은 겉으로는 답답해 보일 수 있는데, 머릿속에는 엄청 많은 정보들이 스쳐 지나가고 있는 겁니다.여러분도 이렇게 되시길 응원 드려요! 그럼 이번 블로그는  여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT  좋아요 ​♡는 저에게 큰 힘이 됩니다 :)   

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

일프로

[kubernetes] 강의 소개 #1

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요! 강의 링크 : https://inf.run/NzKy 제가 이전 쿠버네티스 강의를 만든 지 벌써 4년 정도가 지났는데, 그동안 저는 현업에서 계속 프로젝트를 하느라 바쁘게 지내고 있었어요. 최근 여유가 생겨서 이렇게 다시 강의 만들 기회를 가질 수 있게 됐고, 제일 먼저, 어떤 강의를 만들지 고민을 많이 했습니다.​쿠버네티스가 나온 지 적지 않은 시간이 지났고, 인터넷이나 많은 책들을 통해서 필요한 내용을 쉽게 찾아볼 수 있게 됐죠. 그리고 그 내용들을 보면 이제 정말 쿠버네티스를 잘 아는 사람들이 많아 졌구나를 느끼는데 막상 프로젝트를 하다보면 주변에 쿠버네티스를 생소하게 생각하는 분들이 아직도 훨씬 많습니다.그리고 시도를 했다가 포기를 하시는 분들도 더러 봤는데 정보는 많지만 여전히 쿠버네티스가 새로 시작하는 사람들에게 큰 진입 장벽이 있는 것 같아요.​그래서 저는 기존보다 더 난이도 있는 강의를 만드는 것보다 입문자가 더 쉽고 재미있게 쿠버네티스를 시작할 수 있는 강의를 만드는 게 더 의미 있는 일이라고 생각을 했고, 처음엔 저도 쿠버네티스를 시작하면서 새로운 개념들을 이해한 다음 다 중요하고 써먹어야 할 것 같아서 프로젝트에 적용을 했다가 다시 걷어내는 일들을 반복을 했는데 이건 쿠버네티스 기술이 워낙에 광범위하기 때문에 누구나 겪게 되는 문제이자 반면에 쿠버네티스를 포기하게 만드는 원인인 것 같아요.​전 이제 그동안의 경험으로 어떤게 중요하고, 어떤 건 적당히만 알면 되고, 또 어떤 건 잘 안 써서 몰라도 되는 건지에 대한 감이 좀 생겼는데, 이 강의는 기존 A~Z식의 얇고 넓은 범위의 강의가 아닌 하나를 공부를 하더라도 그 개념에 대한 배경 지식을 충분히 이해하고 깊이 있는 실력을 만들어 주는 강의를 만들어 보려고 해요.그래서 강의 제목에 이전 강의와는 또 다른 방식의 강의라는 의미로 어나더 클래스라는 이름을 붙여 봤습니다.​ 강의 주제먼저 강의 주제로 전체적인 제 강의의 컨셉을 설명 드리면, 쿠버네티스 어나더 클래스는 총 3개의 Sprint로 나눠져 있고 각각의 Sprint는 다른 주제를 가지고, 새 강의로 만들어져요.​그래서 결국 모든 강의를 다 들으시려면 세 번의 수강 신청을 하셔야 하는 건데, 이렇게 나누는 이유는 앞에서도 말씀드렸다시피 이제 쿠버네티스를 어느 정도 잘 아는 분들이 많아졌기 때문에 제 강의에서 필요한 부분만 듣고 싶은 분들도 분명히 계실 거예요. 그래서 강의 설명을 잘 보시고 내가 필요한 내용 인지를 판단해서 조금이라도 낮은 가격으로 필요한 내용을 수강할 수 있게 하기 위해서 입니다.​저도 각 강의에 어떤 내용들이 담겨져 있는지에 대해서 최대한 알려 드리도록 노력을 할게요. 그리고 Sprint가 보통 2주를 얘기를 하는데 여러분들이 Sprint 강의 하나를 들을 때 최소 2주는 잡고 공부를 했으면 해요. 5시간 정도의 강의 분량을 2주 동안 듣는 방법은 바로 복습을 해야 된다는 거구요. 강의 내용 중에도 제가 계속 복습을 강조를 할 건데 그 방법에 대해서는 강의를 통해서 더 말씀을 드릴게요.​그리고 Sprint마다 이름이 있어요. 모두 북극에 사는 귀여운 동물들인데 사실 제 입장에서는 이 Sprint 하나를 제작하는데 두 달에서 세 달 정도 걸리는 소규모 프로젝트거든요. 그래서 제가 강의 하나하나에 의미를 부여하기 위해서 이렇게 이름을 지어 봤습니다. ​현재 여러분께서는 Sprint1의 Polar Rabbit의 강의 소개를 보고 계십니다.​다음으로 이 강의에 수강 대상이 좀 많죠? 절대로 아무 생각 없이 제가 아는 IT직군을 모두 때려 넣은 건 아니구요. 이 분들이 수강을 하셔야 되는 이유는 뒤에서 별도로 말씀을 드릴 건데, 일단 대상군이 많다는 건 입문자가 들을 수 있는 난이도 라고 보시면 되고, 이 세 개의 Sprint 전체가 그렇고 저는 이 전체에 대한 난이도를 [지상편]이라고 붙였습니다. 그럼 이제 다음편으로 조금 더 높은 수준의 난이도가 있겠죠? ​​점점 깊게 들어가는 의미로 [해수편]과 [심해편] 그리고 [해연편]까지 생각을 하고 있구요. 각각에 수강 대상은 다른데, 저는 최근까지 큰 프로젝트에서 쿠버네티스 파트에 아키텍트 역할을 해왔고요. 최대한 제가 했던 일까지 모두 강의로 만드는 게 최종 목표입니다. ​강의 소개​이제 수강 대상과 이 대상들이 쿠버네티스를 왜 알아야 되는지 얘기를 해볼게요. ​채용 우대사항에 항목들은 점점 많아지고 있습니다. 이 우대사항은 그 팀에서 주로 쓰는 개발환경을 나열해 놓기 마련인데, 그만큼 IT시스템이 나날이 복잡해지고 있다는 거죠. 그리고 여기에 쿠버네티스가 직군을 막론하고 한 자리를 차지하고 있는 걸 볼 수 있고요. 그래서 이젠 구직할 때 쿠버네티스도 알아야 하는데, 우대사항까지 이렇게 챙겨야 되나 싶겠지만, 요즘은 고스펙 경쟁 시대라 구직자 분들께 부담을 드리는 것 같아 죄송하지만 어느정도는 알아야 한다고 말씀드릴께요. 이들에게는 각자의 영역이 있지만 쿠버네티스는 어느 특정 영역에 한정되지 않아요. IT 전체에 퍼져서 매력적인 기능들을 제공하고 있는데요. 그래서 개발자가 쿠버네티스에 한번 발 담구다 보면 어느새 인프라의 스토리지를 밤새 공부하고 있는 자신을 발견하기도 합니다.​그래서 저는 쿠버네티스가 영역 파괴자라고 불러도 과언이 아니라고 생각하고 각 영역에 대한 경계를 많이 모호해지게 만들었다고 보는데, 그만큼 쿠버네티스를 잘 모르면 누군가에 의해서 내 영역이 흔들릴 수가 있게 된다는 거죠. 그래서 쿠버네티스를 더 잘 알아야 각자의 입지를 더 튼튼하게 다질 수 있다고 말씀드리고요.기존 환경을 쿠버네티스 환경으로 전환하는 큰 프로젝트들이 많아지고 있고, 물론 쿠버네티스 환경이 구축되면 장애에 대해 좀 더 여유가 생기는 건 사실이지만, Container나 Pod 등 새로운 용어나 기술사용 들이 기존 시스템과 많이 다르긴 합니다.​그렇기 때문에 이런 새로운 환경을 갑자기 받아들이는데 부담이 있을 수 밖에 없어요. 근데 구축팀 입장에서 프로젝트 오픈에 허덕이다 보면 중간중간 운영팀에 교육을 하기 힘든 경우가 많은데, 이때 운영팀에 팀원들은 이 시스템을 받는 것에 대한 걱정이 많아지면서 조금씩 이직에 대한 고민을 합니다. 하지만 이직은 선택을 지연시킬 뿐이예요. 어차피 쿠버네티스 환경은 계속 많아질 것이기 때문에 나중에 또 같은 상황으로 이직을 고민하게 될 수 있습니다.​그래서 가장 좋은 건 부담이 생기기 전에 미리미리 쿠버네티스를 공부해 놓고, 프로젝트가 진행되는 걸 편하게 지켜보면서 내 입맛에 맞는 요구사항들을 쏟아내는 거겠죠? ​이미 쿠버네티스를 도입해서 비용을 절감했다는 입소문이 퍼지기 시작했고, 너도나도 쿠버네티스를 적용해보려는 시도들이 많아 졌습니다. 근데 자사에 운영 인력이 부족한 기업에 경우 솔루션 업체에 도움을 구해야 되는데, 문제는 솔루션 업체들도 현재 인력이 많이 없는 상황이예요. 그래서 쿠버네티스 전문 인력을 새로 뽑으려는 업체도 많고요.분명 기존 솔루션 엔지니어 분들은 회사에서 쿠버네티스를 공부하라는 압박이 있을 거에요. 이때 억지로 떠밀려서 공부하면 정말 재미가 없는데, 앞으로 또 10년 더 직장생활이라는 안정적인 먹거리를 위해서 지금 한번 고생을 해본다는 마음을 먹으시길 바라고, 몇년이 지난 후에는 이때의 선택을 잘했다고 생각하게 될 날이 분명히 올 겁니다. 쿠버네티스를 선택하면 따라오는 오픈소스들이 너무 많아요. 그리고 이 오픈소스들은 각각에 장단점이 있는데, 그 장단점이 대중적으로 정해졌다기 보단, 프로젝트 규모와 상황, 그리고 쓰는 사람들의 수준에 따라 다르거든요. 그래서 쿠버네티스 담당자는 제안서를 쓸 때부터 오픈을 할 때 까지 내가 이 오픈소스를 잘 선택한건지 계속 의문을 품게 되요.​정답은 없고, 이 프로젝트에서 이게 가장 효율적인 선택이었다라는 평가를 해줘야하는데, 그걸 최종적으로 해 주는 사람이 바로 PM/PL입니다. 새로운 기술에는 항상 반발이 있기 때문에 이분들이 기둥을 잘 잡아줘야 되요.​그래서 리더는 프로젝트를 하는 동안 담당자 얘기를 계속 경청하고 의견을 줘야겠지만, 최소한 누군가의 말에 휘둘리지 않는 정도의 지식은 있어야 겠죠? ​강의 특징먼저 이 강의를 위해서 네이버 카페(링크)를 만들었는데, 용도는 첫 번째로 강의 자료실 입니다. 앞에서 설명 드렸다시피 제 강의는 여러 Sprint로 나눠져서 만들 예정이라 이렇게 카페가 중심이 되서 저는 자료들을 통합적으로 관리 할거구요. 그러면 여러분들도 이 한곳에서 필요한 정보를 빠르게 캐치할 수 있게 되실 거예요.​두번째로, 여러분들의 복습 진도를 체크하려고 하는 건데 이 부분은 강의 중에 별도로 영상을 만들었으니까 수강 후에 보시기 바랍니다. 그리고 이 강의가 어떤 느낌의 강의인지는 강의 중간중간을 편집한 영상을 유튜브(링크)에 올려놨는데, 직접 보고 판단하시길 바랄게요. 제가 앞에서 어떤 강의를 만들어야겠다는 목표를 얘기를 했지만 영상 제작과 교육 기법에 대한 부분은 또 별개인 것 같아요. 그리고 저는 전문 강사는 아니기 때문에 그런 부분들은 직접 보시고 내가 수강하기에 편한 형태인지는 직접 판단을 해 보세요.​참고로 저는 이전에 만든 강의에서 들었던 단점을 보완하려고 노력을 했고, 인프런의 전체 강의의 별점이 1~2점인 수강평들을 쭉 보면서 나는 이런 실수는 하지 말아야지에 대해서 집중을 했습니다. 근데 제가 얼굴을 띄워 놓고 영상 강의를 하는 건 또 처음이라 표정이 좀 어색하더라도 이해를 부탁 드릴게요. 앞으로 점점 부드러워지지 않을까 싶어요 :) ​학습 내용[강의설명]에 이렇게 강의에 대한 주요 이미지들을 올려놨기 때문에 어떤 내용을 다루는 건지 알 수가 있어요! 만약 위 그림들로 부족하면 제가 강의를 만들면서 블로그(link)로 강의의 일부 내용을 올려놨습니다. 이 내용들을 보시고 충분히 판단을 한 다음에 강의를 수강 하세요. ​실습 환경​지상편 전체 실습 환경으로 개발 환경과 CI/CD 환경 그리고 인프라 환경을 구성할건데, 각 Sprint 마다 하나씩 구성이 될 예정이에요. 그래서 Sprint1 에서는 인프라 환경만 구성을 해서 실습이 진행된다고 보면 됩니다. ​최종적으로는 이 전체 환경을 직접 구성하고 활용할 수 있게 되는데, 이게 컨테이너 환경의 전체 파이프라인 입니다. [지상편]을 모두 잘 수강하면 이 내용들이 모두 내 PC위에서 돌아간다고 보시면 돼요. 이 흐름에 대한 내용은 강의 중에서 자세히 설명을 드릴께요.​​그래서 현재 Sprint1 에서는 이런 환경을 구성할 건데, 내 PC에 VirtualBox와 Vagrant를 이용해서 Guest OS를 띄우고 설치 스크립트로 인프라 환경을 쭉 만듭니다. 그리고 쿠버네티스를 다룰 때는 원격 접속 툴을 이용해서 서버에 들어가면 kubectl이라는 툴이 있고, 이걸로 쿠버네티스 명령을 날리면서 실습을 하고 브라우저로 대시보드에 접속을 해서 쿠버네티스를 조작하기도 해요. ​학습 자료는 인프런에 기본 수업자료를 다운받는 곳을 보면 PDF로 제공을 하고 있어요. ​그리고 수강평을 작성하신 분에 한에서 강의 자료실에서 원본 PPT를 받을 수 있으니까, 필요하신 분께서는 (링크)로 들어가서 방법을 읽어보세요. 그럼 여기까지 강의 소개를 마치며,이 강의가 여러분께 쿠버네티스를 쉽고 재미있게 시작하는데 도움이 됐으면 좋겠습니다.

데브옵스 · 인프라인프런쿠버네티스어나더클래스지상편일프로kubernetesdevopskubeopscontainer강의소개

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강의리액트소프트웨어교육

hjoo

스타트업 투자 재무적 Log 4 (Series A)

13. Series A 투자 라운드 시작 – 2021.02지표가 좋은 편이어서, 이땐 IR 자료 들이밀면 돈다발 들고 줄 설줄 알았다. 당연히 그런일은 없었다.ㅋㅋㅋㅋㅋ 게다가 난 정형화된 발표에 매우 취약해서 본엔젤스에게서 IR에 맞는 팀을 꾸리는게 좋겠다는 조언도 받았다. 쉽게 말해서 발표 너가 하지 말라는 말씀이었다. 😂😂😂 그래서 우리팀의 고트(goat)와 팀을 짜서 같이 IR 을 준비했다. 고트는 실제로 이해력과 유연성, 전달력이 모두 좋아서 내가 만든 IR 자료와 비전을 정확하게 이해하고 잘 전달해 줬다.50억을 모을 생각이었다. 2020년도에 만난 KB가 긍정적인 신호를 보내면서 기다리고 있어서 20억정도가 확보된 느낌적인 느낌이었고, Seed 라운드에 투자해 이미 주주인 본엔젤스도 10~20억 정도 후속투자 해주신다고 해서, 남은 10~20억을 펀딩하기 위해서 미팅들을 진행했다. 근데 의외로 미팅들마다 광탈했다.ㅋㅋ 수치도 나쁘진 않고 회사 소개도 좋았는데, 그걸 표현하는 방식이 많이 서툴렀다. 만나는 VC 마다 시장 사이즈나 앞으로도 잘 할 수 있는지에 대한 확신이 없다고들 했다.역시 난 보통 VC 들이 좋아하는 스타일이 아니라고 생각했고, 그래서 세상이 잘못보는 거라며 아이유 ‘셀레브리티’많이 들으며 위로받았다. Series A 라운딩 동안 수백만번 들은듯. 아이유님한테 밥 사주고 싶다. 아이유가 거부하겠지만.ㅋㅋ14. 본격 Series A IR본격적으로 투자 IR을 시작했다.아래 인프랩은 아래 세 회사에서 투자 받았다.미래에셋만나는 VC 들이 시큰둥하니까 슬슬 짜증게이지가 올라가던 참에 미래에셋 김경모 본부장님과 미팅이 잡혔다. 2020년 초중순에 전태연 파트너님 소개받은적 있는데, 그땐 바쁘셔서 만나보지도 못했었다. 그래서 사실 별 기대 없이 갔다.근데 그 짧은 미팅 시간에 많은 인사이트를 얻었다. 온라인 플랫폼에 대해서 투자를 많이 하신 분이라 그런지 이해도도 높았고, 던지는 질문에서 공부가 많이 됐다. 그래서 그 미팅 시간에 ‘아! 이사람한테는 받아야겠다!!’ 하는 생각이 들었다. 근데 그건 내 생각이고, 시큰둥해 하신다는 생각이 들었다. 미래에셋의 질문은 날카로웠지만 우리가 제공하는 대답과 자료들은 물렁했다. 그래서 추가로 우리 서비스에서 뽑을 수 있는 임팩트 있을만한 수치들을 분석해서 이메일로 보냈다. 근데 이 수치를 보내드리고 엄청 빨리 답장이 왔다.“매우 좋은 수치인 것 같습니다. 혹시 이걸 월별로 볼 수 있을까요?”이 답장을 보고 이 지표가 엄청 좋은 지표고 투자자들이 좋아하는 것이라는걸 알게됐다. 그래서 데이터 좀 더 디벨롭해서 IR 자료에 추가하고 새로운 VC 만날때마다 이 자료에 대해서 이야기를 했다. 실제로 그 이후로 만난 모든 VC에게서 관심을 받았다. 유저 리텐션에 관한 데이터였다. 리텐션 데이터를 아래 쿠팡꺼처럼 생기게 만들었었다. 우리껀 아니지만, 인프런 유저 리텐션 데이터를 이런 형태로 만들어서 전달드렸다. 쿠팡 리텐션 데이터는 지금봐도 경이롭다.ㅋ 근데 우리꺼도 대따 좋음.이후로 계속 자료들을 검토하고 인터뷰도 하고 하다가 정식 IR 하기로 결정됐다. 이 과정에서 이진우 심사역님이 엄청 많이 도와줘서 엄청 감사하다.IR 당일에 생각보다 편안하게 진행했고, 다른 분들도 많이 들어오셨는데 엄청 다들 친절하셨다. 분위기도 나름 좋았고.한국투자파트너스한투파의 정화목 이사님을 샤플 이준승 대표님 께서 소개해줬다. 이때쯤 50억이 내정적으로는 모인 시점이라 별 생각없었는데, 이준승 대표님이 벨류 왤케 낮게 하냐고. 투자 생태계 망치는거 아니냐고, 그리고 그럴수록 많이 만나봐야 된다고 하시면서 반 강제적으로 한투파와 TBT 를 소개해 주셨다. 진짜 초 귀인..정화목 이사님은 엄청 강렬했다. 우와 나랑 동갑인데, 엄청 똑똑하고 젠틀한데 적극적이고 해서 자극이 많이 됐다. 경험이 무척 좋았다. 그리고 추진력도 장난 아니고. 고트랑 둘이 첫 미팅하고 딤섬 먹으면서 꼭 이사람에게 받고 싶다고 얘기했던 기억이 난다.3월에 IR 을 진행했는데 생각보다 분위기가 편해서 놀랐다. 한투파가 IR 분위기가 무겁고 엄숙하다고 스타트업 사이에 도는 소문을 들었는데, 상상하던 그것보다는 훨씬 부드럽고 편안했다. 우리를 많이 배려해 주신거 같았다. 결국 이번 투자는 한국투자파트너스 정화목 이사님이 리드하에 진행됐다.본엔젤스새 라운드에서 후속투자를 받기위해 IR 시간을 가지게 되니, 여러 감정이 섞여 들었다. Seed 투자때 우리를 믿어준것에 대해 의리를 지키고, 보답을 하는거 같은 느낌도 들었다. 그래서 감사함과 뿌듯함의 감정이 특히나 크게 다가왔다. 딴 예기지만 본엔젤스는 원래 Seed 단계에서의 투자가 주로 있었는데, 시리즈A 단계에서 후속투자를 하는 경우는 이전까지는 별로 없었다고 한다. 앞으론 많이 하실거라고 하네.IR 시간에 크래프톤 김창한 대표님도 계셨는데, IR 시간이라 사적으로 궁금했던거 못물어봐서 아쉽다..15. 실사 및 투심위 등등 후 60억 투자 확정 💰🎉시드투자 때와는 다르게 돈의 규모가 달라지니까 절차도 좀 많아졌다. 근데 이건 VC(투자사) 마다 절차가 다르다. 한투파, 미래 같이 규모가 큰 회사들은 보통 IR → 투심위1 → 투심위2 → 회계실사 → 계약 → 주금납입이런 순서가 많은거 같다. 투심위는 해당 VC의 담당자가 VC내부에서 동의를 이끌어내는 과정이다. 그래서 이때 VC의 담당자가 잘 준비할 수 있게 투자받는 회사도 자료들을 충실하게 지원해 줘야된다.이때 사실 엄청 일이 많다. 요청 자료들은 보통 없었던 형식이 대부분이라 데이터 뽑고 새로 만들고 검증하고, 질문들에 답해주고 하는것들이 이어진다. 그렇게 만들어진 자료들을 토대로 VC 내부에서 토론을 거치고 최종 진행 여부가 결정된다.그리고 OK 되면 VC가 선정한 회계법인이 회계 실사를 진행하게 된다. 그동안의 모든 입출금 내역, 매출, 채무 등의 건전성 적합성 등을 확인한다. 그리고 문제 없으면 계약서 도장찍고 얼마후에 주금이 납입된다. Series A 라운드 프로젝트를 준비했던 궁예방. 실사 서류로 지저분하다.결론적으로 인프랩은 4월 22일한국투자파트너스, 미래에셋캐피탈, 본엔젤스각 20억씩 총 60억원 Series A 투자 유치에 성공했다. 💰💰💰💰💰💰 🎉16. 협상과정에 대한 감상시원하고 후다닥 60억이 통장에 들어온거 같지만 완전 그렇진 않았다.가장 처음에 투자를 희망한 VC 한곳과 미래에셋 두곳에서 IR 을 가장 먼저 진행했고, 뭔가 일사천리로 슉슉 진행되는거 같았다. 근데 처음 호감을 주던 VC 에서 일이 지지부진 해졌다. 정확히 왜때문인지 모르겠는데, 큰 VC 하우스다 보니까 내부 의사결정 과정에서 시간이 지체되는거 같았다. 문제는 리딩을 하는곳이 그렇게 지체되니까 전체 일정이 다 멈춰버렸다. 그렇게 근 한달이 걍 지나가 버렸다. 원래 연초는 주주총회 시즌이니까 바뻐서 좀 딜레이 될 수도 있다고는 알고 있었는데, 이건 좀 심한데? 싶었다. 나의 마음은 갈대니까 이 과정에서 다시 투자를 받기 싫어졌다.ㅋㅋㅋ 투자 준비도 재미없고, 내가 이렇게 까지 해서 무슨 부귀영화를 누리나 싶고, 다른 더 재밌는 일을 하고 싶었다. 본엔젤스 전태연 파트너님이 뒤에 없었으면, 아마도 투자 진작에 엎어버렸을거다. 본엔젤스 내부에 인프랩에 대한 후속투자를 설득해 놓으셨다는걸 알아서 실망시킬 순 없었다. 그래서 진짜 꾹 참고 지지부진한 투자상황을 이어나갔다. 벨류 조정 협상이렇게 느리게 일이 진행되는 와중에 벨류 조정 협상까지 들어왔다. 벨류가 상대적인 거라지만 우리딴에는 벨류를 많이 낮춰서 펀딩을 하고 있었다. ‘빠른 마무리’ 와 ‘좋은 VC’. 이번 라운드는 이 두조건을 총족하는게 최우선 이라고 모토를 잡아서 벨류는 아쉬움 없이 낮게 잡았다. 이 상황에서 벨류 협상이 들어오니까 신뢰가 깨져버렸다. 이 벨류를 못받아들여져서 계속 늦어지고 있던건가? 싶기도 했고.스타트업 입장에서 생각해보면, 투자는 앞으로의 믿어야할 파트너를 정하는 것이기도 하다. 그런 관점에서 우리가 이렇게 적절한 기업가치를 잡았는데도 이런 협상이 들어왔다는것은 앞으로 파트너로서 믿어도 되는걸까 하는 원론적인 의심이 들었다.원래 뭐든 빠르게 결정하는 편인데, 이때 진짜 머리가 넘 복잡해서 혼자 양평에 다녀왔다. 주말이틀 하루종일 걸으면서 계속 생각했다. 결론짓고 돌아와서 월요일에 IR 을 같이 준비하던 고트한테 지금까지 진행된 투자 상황 모두 드랍하고 다시 시작한다고 선언했다. 그때 고트 표정이 아직도 생생히 기억난다.ㅋㅋㅋㅋㅋㅋㅋㅋ다행히 감사하게도 완전 드랍되는 일은 일어나지 않았고, 투자자의 구성이 약간 바뀌어 투자가 성공적으로 마무리 됐다.음.. VC 가 투자전 기업 벨류를 낮게 조정하는걸 나쁘게 생각하지 않는다. 오히려 VC 입장에선 당연하다고 생각한다. 원래 가격보다 싼 가격으로 물건을 사면 그만큼 실적이고 보상이 커질테니까. 자신의 이득을 위해서 당연히 시도해볼만한 일이다. 하지만 때에 따라서는 상대방의 신뢰를 깰 수 있는거라 어려운 일 같다.이때 우리가 좀 더 압도적인 설득력을 보여줬으면 어땠을까.. 하는 생각이 든다. 얼마전에 만난 이미리 대표님이 투자 협상은 ‘자본주의의 예술’ 이라고 말씀하셨는데, 난 그런점에서 예술은 잘 못하는거 같다. 🥲

창업 · 부업창업인프랩인프런스타트업투자인프랩재무적기록시리즈A

일프로

[쿠어클#7-1] Application 기능으로 이해하기-Pod (probe)

 쿠버네티스를 공부 하다보면 경계를 해야 되는 상황이 있어요. 내가 어떤 개념을 힘들게 공부하고 사용법을 익혔을 때, 그 기능을 내가 하는 프로젝트에 적용 시키고 싶은 마음이 생기죠?여기까진 좋은데.그 기능을 적용함으로써 "운영에 불편한 관리 요소가 생기진 않을지?", "오히려 시스템에 복잡도만 증가 시키는 건 아닐지?" 는 충분히 고민하지 않는 경우가 있습니다.예를 들어, 쿠버네티스에는 NetworkPolicy 라는 object가 있는데, 쉽게 말해 Pod들 간에 방화벽 역할을 하는 는 기능 이예요. 보통 큰 프로젝트 환경을 보면 별도로 보안을  담당하는 사람이  있고, 내부 시스템을 외부에서 연결할 수 있도록 하거나 시스템 간에 통신을 해야 할 때 이 담당자한테 방화벽 오픈 신청을 먼저 하죠. 이렇게 전체적인 시스템에 대해서 방화벽이 관리되고 있는데, 쿠버네티스 클러스터 안에 NetworkPolicy를 적용하고 별도에 내부 방화벽 정책을 또 사용 할지에 대해서는 꼭 그렇게 해야 되는 이유를 충분히 고민 해봐야돼요.근데 오늘 배울 이 쿠버네티스의 기능은 백퍼센트 사용을 해야되지만 내 Application에 대한 충분한 이해가 없으면 생각지도 못한 장애를 만날 수가 있습니다.바로 Pod에 probe라는 기능인데요.실제로 저도 Pod가 내가 의도하지 않은 상황에서 죽었을 때, 원인을 분석하다 보면 이 기능을 잘못 사용해서 그랬던 적이 있을 만큼 정확하게 이해하고 적용 시켜야 되는 기술입니다. Pod (probe) - 프로브 기본 개념 3가지 종류가 있고 모두 /ready라는 url을 8080포트에 10초 간격으로 날리는데, 각각 성공이랑 실패에 대한 수치는 위 그림처럼 되어 있다고 해볼게요.컨테이너 안에 있는  App에서는 /ready라는 url이 사전에 만들어져 있어야 되고 Pod가 만들어지자마자 이 probe 기능들은 동작합니다.App은 처음 기동 중인 상태가 있고, 이때 쿠버네티스가 startupProbe 기능을 동작 시키면서  오브젝트 속성에 있는 대로 10초에 한 번씩 /ready라는 api를 App에 날려요. 기동 중일 때는 응답을 받을 수 없으니까 계속 실패가 될꺼고 10번 실패하기 전에 한번이라도 응답이 오면 성공으로 간주합니다. startupProbe 가 성공하면, 쿠버네티스는 startupProbe 기능을 중지 시키고 livenessProbe랑 readinessProbe기능을  동작 시킵니다. 그리고 또 설정 한대로 두 probe는 /ready라는 api를 10초 간격으로 반복해서 날리는데 App이 살아있는 동안에는 계속 200 OK 결과를 리턴 해주면서 이 두 probe 동작은 반복됩니다.각각의 역할은 다른데요.readinessProbe는 성공했을 때 외부 트래픽을  Pod가 받을 수 있는 상태로 만들어 주면서  서비스가 활성화 되고요. livenessProbe는 app이 살아 있는지를 계속 체크하는 역할 이예요. livenessProbe는 만약 App에 장애가 발생하게 되면, API는 실패를 하게 되고 설정에 따라 두 번을 실패하게 되면 쿠버네티스는 App을 재기동 시킵니다.이게 쿠버네티스에 프로브에 대한 기능이고, 일반적으로 자신에 App 기동 시간에 따라 startupProbe에 실패 횟수만 조정해서 쓰는 게 대부분인데 처음엔 이렇게 쓰더라도 어느 순간 이런 생각이 들 때가 있을 거예요. "왜 probe 마다 귀찮게  api들을 기입하는 항목이 각각 있을까?" 어차피 모두 같은 url을 지정해서 쓰는데, 그리고 또 한가지가 "어차피 장애가 나면 livenessProbe랑 readinessProbe는 같이 실패를 할 텐데, 굳이 readinessProbe도 계속 호출될 필요가 있을까?"쿠버네티스가 괜히 이렇게 해놓지는 않았을 텐데 "혹시 내가 이 프로브들을 제대로 쓰고 있는 게 아닌가?"이 프로브들을 간단하게만 써도 나쁘진 않지만 오늘은 이런 의문이 생기는 사람들을 위해서 probe에 대해서 좀 더 깊게 공부를 해보겠습니다. Pod (probe) - 실습카페 자료실 링크 (link)강의 영상에서는 실습이 함께 진행됩니다. Pod (probe) - 실습 로그 분석이제부터 실습 후 로그를 함께 분석해 볼게요. 먼저 App이 초기화 되기 시작했고, Spring이랑 Servlet을 초기화 과정이 있어요. 다음으로 Database를 연결하는데 실제 DB가 있는 건 아니고 그냥 제가 코드에 로그만 찍어 놓은거예요. 그리고 이렇게 App이 기동되는 동안 startupProbe는 계속 실패하고요. startupProbe가 찍히는 주기는 설정 해놓은대로 5초 간격이죠. 그리고 기동이 완료되면 startupProbe는 성공을 합니다. 근데 이 로그들은 startupProbe가 찍히는 걸 보여드리기 위해서 제가 임의로 코드를 구성했기 때문에 로그가 보이는 거예요. 무슨 말이냐면, 실제 App 상황에서는 쿠버네티스는 Pod가 생성되자마자 startupProbe를 작동 시키기 때문에 사실 처음부터 API는 실패 되고 있었거든요.이렇게 App이 기동 되기 전에는 API를 받지 못하기 때문에 실제로는 startupProbe에 로그가 찍힐 수가 없고, 만약에 Was로 tomcat을 썼다면 startupprobe가 찍히는 건 access.log 에서만 볼 수 있게 돼요.그래서 이 로그는 제가 임의로 코드를 구성한 학습적인 상황이라고 말씀드리는 거고요. 이제 기동이 완료가 됐고, [ConfigMap data is loading]은 사용자가 App이 기동 된 후에 외부에 데이터를 가져와서 추가적으로 시스템을 초기화 시키려는 상황 이예요. 그리고 밑에 livenessProbe랑 readinessProbe도 찍히기 시작했고요. 이때 readinessProbe는 실패했고, livenessProbe만 성공을 했네요. 그리고 추가적인 데이터 작업은 끝났고요.그림 제일 하단에 livenessProbe랑 readinessProbe는 계속 찍히고 있는데, 이제 둘 다 성공을 했네요. 그리고 호출 주기는 10초고요.근데 여기 보면 readinessProbe가 한번 실패를 했죠?이건 사용자 초기화 구간에는 readinessProbe가 실패 하도록 일부러 만든 거예요. 그래서 의도 한대로 현재 기능이 정확하게 동작을 해준 건데, 일단 이런 사실만 기억하고 다음으로 넘어가서 강의 영상에서 Application 동작 중심에 프로브를 다시한 번 설명 드립니다. 밑에 내용들을 강의 영상에서 설명 드릴 내용들 입니다. Pod (probe) - Application 동작 중심의 프로브 이해해당 내용은 근본적으로 쿠버네티스에서 왜 프로브라는 기능이 생겼는지 생각해봅니다.Pod (probe) - API 날려보며 프로브 동작 확인하기그리고 API를 날려보면서 앞에 설명한 기능들을 확인해보고요. Pod (probe) - 일시적 장애 상황에서의 프로브 활용마지막으로 일시적인 장애 상황에서 프로브를 좀 더 활용하는 방법을 얘기 해볼께요. 이렇게 강의를 모두 들으면 앞으로는 쿠버네티스에 프로브를 보게 될 때,내 app을 주의 깊게 관찰하게 되면서 어떻게 프로브를 잘 적용 시킬지 심각한 고민에 빠질 수 있게 되는 점 주의 바라며오늘 블로그는 여기까지 마치겠습니다. 해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다.강의 링크 : https://inf.run/NzKyps. 한번도 좋아요♡를 안 준 사람은 있어도, 한번만 좋아요♡를 준 사람은 없다. 당신은 어떤 사람인가요? :)

데브옵스 · 인프라인프런쿠버네티스어나더클래스지상편일프로kubernetesdevopskubeopsApplication기능으로이해하기Pod(probe)

셰리

애사심 뿜뿜! 입사 웰컴 키트 살펴보기

입사 첫 날, 걱정 반 설렘 반의 마음으로 회사에 들어섰을 때 날 반기는 웰컴 키트가 있다면? 함께할 회사에 대한 애정은 더 커지고, 환영 받는 기분에 열심히 일하고 싶은 의욕이 불타오르겠죠.웰컴 키트, 웰컴 굿즈, 그리팅 키트 등으로 불리는 이것은 신규 입사자에 대한 감사와 환영의 마음을 담은 기업의 선물이에요. 동시에 기업의 철학이나 가치를 담아 알리는 브랜딩 효과도 있습니다. 오늘은 다양한 기업의 웰컴 키트를 유형별로 살펴보려고 합니다. (인프런 웰컴 굿즈도 소개해드릴게요.) 얼른 읽어볼까요? (。•̀ᴗ-)✧1. 오래오래 쓸 수 있도록! 실용성을 고려한 웰컴 굿즈입사 후 가장 오랜 시간을 보낼 사무실. 직접 일해보기 전까지 필요성을 느끼지 못하는 사무실 필수템을 회사에서 웰컴 굿즈로 제공하는 경우가 많다고 해요. 매일 쓰는 굿즈에 큼직하게 들어간 기업 로고로 느끼는 소속감은 덤. 실용성과 소속감 모두 챙긴 센스 있는 굿즈라고 할 수 있죠.쿠팡 페이의 웰컴 키트 안엔 슬리퍼와 3단 노트북 거치대도 있다고 해요.토스의 웰컴 키트에는 슬리퍼, 후드집업, 티셔츠가 포함되어 있어요. 2. 우리 회사는 무슨 색? 브랜드 색이 가득한 웰컴 굿즈오직 우리 회사 사람만 받을 수 있는 굿즈가 있다면 회사에 대한 애정이 더 커지겠죠. '우리' 회사의 서비스와 색을 더 잘 이해할 수 있는 계기가 되어주기도 하는 굿즈를 제공하는 회사도 있어요.라인의 웰컴 키트 구성품 중 라인 스토어 바우처와 라인 로고가 박힌 마그넷이 있는데요. 라인 특유의 쨍한 초록색 덕분에 존재감이 확실한 것 같아요. 레드닷 어워드 2019 Best of Best와 iF 어워드를 수상한 웰컴 키트이기도 해요. 3. 이런 굿즈는 또 없을걸? 개성만점 독특한 굿즈다양한 웰컴 키트가 쏟아지는 가운데, 어딘가 독특하면서도 재밌는 굿즈를 제공하는 회사도 있어요. 우리 회사는 이런 것까지 챙겨준다! 하고 자랑할 수 있는 굿즈가 있다면 괜히 뿌듯해질 것 같지 않나요?배민의 웰컴 키트에는 수저 세트와 칫솔, 치약, 살균기 세트까지 들어있어요. 입사자의 입속 건강(?)까지 챙겨주는 굿즈라니, 굉장히 특별한 것 같아요. +) 인프런의 웰컴 키트지금까지 다양한 회사의 웰컴 굿즈를 소개해드렸는데요. 이쯤 되면 인프런의 웰컴 굿즈도 궁금해지지 않으신가요? 지금까지 여러 번 진화했고, 앞으로도 쭉 진화할 인프런의 웰컴 키트도 소개해드릴게요.최근 인프런의 웰컴 키트는 흰색과 검정색 티셔츠, 에코백, 머그컵, 볼펜으로 구성되어 있어요.그중 가장 핫한 반응을 얻은 건 바로 이 머그컵인데요! 무려 보온이 가능하답니다. 신규 입사자에겐 실용적인 굿즈이면서 기존 팀원들의 부러움을 받은 굿즈예요. 인프런 웰컴 키트도 계속 성장할 예정이니 많은 관심 부탁드려요. 😁 취준생에겐 의지와 동기를, 입사자에겐 애사심을 심어주는 웰컴 키트! 혹시 갖고 싶은 웰컴 굿즈나 자랑하고 싶은 우리 회사의 굿즈가 있다면 댓글로도 공유해주세요.

취업 · 이직웰컴키트입사브랜딩인프런

운영팀

인프런 굿즈 준비 후기

바빴던 1월, 배송만을 앞두고 작성해보는 6주년 사랑주간 굿즈(선물) 준비 후기 지난 2020년 사랑주간에는 후드티 300장과 작은 미니 굿즈 700개를 선물해드렸고, 올해는 뭘하지 하던... 바야흐로 때는 2021년 11월 말. . . 연말이면 돌아오는 인프런 사랑주간을 맞이하여 이번에는 어떤 선물로 감사함을 전하는 게 좋을까? 하고 정말 오랜 시간 고민했습니다. 인프런 수강생 특성과 학습 환경을 여러모로 고려해 선물 구성을 기획했는데 다들 마음에 드셨으면 좋겠습니다 (ㅎㅎㅎㅎㅎ)nn번의 토론 끝에 나왔던 다양한 후보 군 ∙ 폴더블 텀블러 (제가 갖고 싶어요)∙ 무선충전 마우스패드∙ 노트북 거치대∙ 피규어 레고∙ 태블릿에서 쓸 수 있는 학습 미션노트∙ 먹을게 제일 좋아  커피, 치킨, 아이스크림∙ 아이패드∙ 후드집업∙ 역시 후드티인가∙ 진짜 후드티인가∙ 스티커 등등 .... 의 치열한 경쟁 끝에최대한 많은 분들에게 드리고 싶어 이번 6주년 사랑주간에는 아이패드, 팜레스트(키보드 손목받침대) 그리고 커피 로 600개선물이 결정되었습니다. 지난 1월 7일 당첨자 발표가 났고, 곧 순차적으로 배송될 예정입니다. 조금만 기다려주세요!!! 🚚 🚛 (배송 막바지 작업 중이니, 안내드린 일정에 받으실 수 있도록 준비할게요!) ✼ 21년도 사랑주간 이벤트 보기아이패드는 별도의 준비 과정이 없지만, 팜레스트 (키보드 손목 받침대)는 각인 제작이 필요했기 때문에 이곳 저곳 견적을 받고 마음에 드는 공방을 컨택해 진행했어요. 저는 팜레스트 세계가 처음이라 입문하기 전 회사에서 팀원들이 가장 많이 사용하는 사이즈를 재보고, 빌려서 테스트해봤는데요. 여러 번 테스트 끝에 상용화된 표준 사이즈로 제작했습니다. 소재는 향과 색이 예쁜 느티나무로.제작 중간에 테스트 샘플 받아서 옆 자리 콘텐츠 파트 팀원이 직접 베타테스터처럼 실사용도 해보고... 회사 조커 회의실에서 핀조명 켜고 팀원들 키보드 잠시 빌려서 제품 사진도 찍어가며 사랑주간 선물을 열심히 준비했어요.  인프런에서만 만날 수 있는 상품으로 고민하여 준비했으니, 선물 받으시면 다들 잘 이용해주셨으면 좋겠습니다.후기도 많이 많이 남겨주세요. 커피 받으신 분들도 공부하면서 지치는 날 맛있는 커피 한 잔하며 잠시 쉬어가시구요. ☕️ 이번 '사랑주간 설문'에 남겨주신 굿즈 요청도 차곡차곡 정리해서 다음 번에도 좋은 선물로 찾아올게요!!! 다들 새해 복 많이 받으시고, 항상 건강하고 행복합시다!감사합니다. ✼ ✼ ✼ P.S. 지난 2021년 연말어워드 선물로 준비했던 인프런 레고 도 슬쩍 - 공개합니다.다음 번에도 더욱 재밌는 선물로 돌아올게요. 👋✼인프랩 팀 소식이 궁금하다면?https://instagram.com/inflab_people

사랑주간인프런인프런굿즈인프런선물후기내년에는또뭐하지진짜...뭐하지

hjoo

스타트업 인프랩 재무적 Log - 1 (Found ~ Angel)

개인 블로그에 작성한 글인데 인프런 유저들도 보시면 좋을거 같아서 인프런 블로그에도 공유합니다!원글: https://www.hyungjoo.me/인프랩-재무적-log-1/ ========== 지난 4월(2021년 4월) 시리즈A 60억 투자를 완료했다. 남의돈 몇십억 받는것이 쉬운일이 아니기도 하고, 이런 경험이 흔한것도 아니어서 그동안의 자금적 흐름을 기록으로 남기고 싶었다. 근데.. 우리가 받고나서 막 몇백억씩 받는 곳들이 많아서 좀 멋쩍어 져서 안했다.ㅋㅋㅋㅋㅋㅋ (좀 더 많이 받을껄)하지만 역시나 스타트업 성장 경험이 단편적인 ‘카더라’ 로 전해지고, 전해지더라도 엄청 성공한 곳들의 사례 뿐이다. 그래서 아직 성장중인 인프랩의 사례가 긴 호흡으로 하나의 데이터로 도 남으면 좋겠다고 생각했다. 스타트업의 발전은 여러 관점으로 바라볼 수 있지만, 이 글은 ‘재무적’ 관점에 집중해서 연대기적으로 작성한다.(참고 : 프로덕트적 관점글 https://www.hyungjoo.me/4년을-기다린-인프런-서비스-리뉴얼-오픈/) 1. 창업 및 서비스 런칭 (2015년 4월 ~ 2015년 12월) 첫 사업자 등록을 5월인가 했는데, 이 당시 자산은 -900만원 = 마통 -800만원 + 월세보증금 200만원 + 카드빚 -300만원정도 였다. 일반적으론 창업이고 자시고 직장 착실히 다니면서 빚 매꾸는게 먼저일텐데, -900만 이나 0원이나 어차피 똑같이 X됐다고 생각했다. 그도 그럴것이대학 중퇴 + 34살 개발 신입(잘 못함) + 말 + 미래 없어보이는 회사 유일한 개발자4콤보라 아껴서 빚 갚는다고 해도 뭔가 달라지거나 할거 같지 않았다. 그래서 어차피 X된거 빚갚는건 생각에서 지우기로 했고, 내 성장이든 프로젝트든 사업이든 뭐라도 해야겠다 싶어서 프로젝트를 시작했다. 사실 당시엔 사업을 한다 이런거보다 프로젝트성 재능기부 느낌이 더 컸다. 물론 잘되면 부자되는 상상은 당연히 하긴 했지만.. (김연아랑 데이트하는 그런 정도의 공상) 개인사업자 등록은 고맙게도 돈이 안들었다. 홈텍스에서 사업자등록을 하고 같이할 팀을 생각해봤는데, 나 + 대기업 다니는 고등학교때 친구 + 같은 직장 다니던 친구 셋이 하면 좋겠다고 생각했다. (특히 난 전세계 스타텁 대표중에 가장 발표를 못하는 사람일거라 외부 미팅을 할 스마트한 팀원이 꼭 필요하다고 느끼기도 했다.)하지만 돈도 없는 상태에서 첨부터 팀만들어서 간다면 시간제한이 생길것이고, 오픈플랫폼을 생각했기 때문에 최소한의 시간 확보가 무엇보다 중요하다고 느꼈다. 글고 회의하면서 힘빼는것도 낭비같았고. 그래서 걍 혼자 하기로 하고 서비스 개발을 시작해서 2015년 12월에 인프런을 런칭했다. *참고 : 예전에 발표한적 있는 인프런 시작 사례 (링크) 2. 인프런 런칭 및 빚 모으기 – (2015년 12월 ~ 2016년 여름) 서비스 런칭하면서 다니던 직장에서도 나오게됐다. 사실 계속 다니고 싶었는데 회사 상황이 안 좋아진건지 엄청 외진 아파트촌 안의 상가로 이사를 하게 되어 출퇴근도 빡쌔지고, 회사 사람들도 내게 어떤 즐거움이나 자극이 되어주질 못했다. 인프런 런칭후 조금씩 매출이 있긴 했지만 아주 작은 금액이라 그 돈은 항상 마케팅에 사용했다. 그렇다고 생활비를 더 아낄 수도 없는 상황이었고, 수입은 0 이니 빚은 2016년 여름쯤 되니 빚이 벌써 3000만원이 됐다. 돈이 없으니까 투자를 받아보려고 정부의 창업지원프로그램 등에 지원도 하고, 스타트업 액셀러레이터들 – 프라이머나 스파크 등 – 에 지원을 했는데 모두 광탈했다.ㅠㅠ 근데 엄청 운이 좋게, ‘소상공인정책자금’ 이라는것을 알게 되서 신청했다. 당시 내가 사용하던 사무실은 판교 경기창조혁신센터 안의 ‘문화창조허브’ 라는 무료 오픈스페이스 였는데, 여기 사업에 도움이 될 만한 여러 정보들을 알려주는 게시물이 많았다. 운 좋게도 그걸 보게됐다. 필요서류를 준비해서 소상공인정책자금 을 신청했는데, 의외로 엄청 쉽게 됐다. 이때 7천만원 대출이 나왔다. 1억까지 해준다고 했는데, 내가 이미 빚이 3000천만원이 있어서 7천까지밖에 안된다고 했다. 솔찍히 7천만원 도 넘 큰 액수여서 담당자 분께 감사하다고 100번은 했던 기억이 난다. … 현금7천만원이 생겼지만, 우짜든 빚이 1억인 사람이 됐다. 😂 3. 귀인1 (2016년 가을 ~ 2017년 2월) 2016년 가을에 당시의 여자친구랑 헤어지고, 맨날 질질짜던 도중에 ‘제주도 한달살기’ 공고를 봤다. 제주 경제창조혁신센터 에서 운영하는 프로그램인데, 한달동안 제주도의 숙소비용과 아침식사비용을 지원해주는 프로그램이다. 스타트업이나 IT 업계 사람들을 제주도로 유치하는게 목적 이었던거 같다. 이게 왠 떡이냐 싶어서 마지막날 신청서를 작성했고, 선정되서 바로 다음날 제주도로 향했다. 10월의 제주도는 완전 짱 이어서 아무 생각없이 즐겁게만 지내고 있다가, 전정환 제주혁신센터 센터장님한테 연락이 왔다. 1:1 티타임을 하고 싶다고 하셨다. 센터장 같이 높은 사람이 왜 날 보고 싶다고 하지? 하는 궁금증이 들었지만 별 생각없이 티타임 시간을 가졌는데 이런저런 이야기를 하시다가 ‘앤젤투자를 하고 싶다’ 고 하셨다. 사실 처음엔 ‘읭?’ 싶었다. 나의 어떤 면을 보고 몇천만원 이라는 큰 돈을 투자를 하고 싶다고 하셨을까 싶었다. 그날도 역시 엄청 버벅거리고 더듬 거리며 서비스를 소개했기 때문에 그런 기대는 전혀 없었다. 근데 전정환 센터장님은 나의 좋은 면을 봐주셨고, 앤젤투자를 꼭 하고 싶으니 그 순간이 오면 꼭 얘기해달라고 하셨다.  지금 생각해보면 완전 귀인 이시다. 실제로 이후 전정환 센터장님은 이노베이션 아카데미 이민석 학장님 등 좋은 분들을 소개해 주시기도 하고 계속적으로 애정어린 시선으로 인프랩을 지켜봐 주고 계시다. 4. 법인설립 + 앤젤투자 (2017년 3월 ~ 4월) 2017년 시작하면서 때가 됐다고 생각했다. 다행이 서비스는 계속 성장했고, 기능은 계속 추가됐다. 여전히 1인 기업으로 혼자 서비스를 만들고, 홍보하고, 지식공유자를 만나고 했는데 어느순간 때가 됐다고 느꼈다. 오픈플랫폼으로서 생태계를 만들기 위한 최소한의 동력이 만들어졌다고 판단이 됐고, 팀을 만들때라는 생각이 들어 법인을 만들고 앤젤투자를 진행하기로 했다. 팀을 만들기 시작함과 동시에 전정환 센터장(귀인 1) 님께 앤젤투자 때가 됐다고 전해 드렸고, 6천만원을 모을 생각이라고 말씀드렸다. 그때까지는 개인사업자여서, 법인을 새롭게 설립하는 작업을 했다. ‘자비스’ 라는 세무 서비스를 알게되서 법인 설립 작업을 했고 자본금 1000만원 넣고 2017년 3월 16일 (주)인프랩 을 설립했다. 개인사업자 인프랩엔 융자도 있고, 그땐 절차와 주식회사 개념도 잘 모르기도 해서 개인사업자 → 법인 전환이 아니고 새로 법인을 설립하는 형식으로 해서 개인사업자, 법인 둘다 존재하는 형태가 됐었다. 개인사업자 인프랩은 2017년 11월에 남아있던 융자를 모두 상환하고 서비스, 상표권 등을 법인으로 모두 넘기고 폐업했다. 이 과정이 엄청 빡쌨다.ㅠㅠ 이제 다 아니까 그때로 돌아간다면 당연히 법인전환 형태로 할꺼다.ㅋ 다시 돌아와서 2017년 4월 앤젤투자가 진행됐고, 전정환 센터장님 + 이민석 교수님 + 이종관 대표님 이렇게 세분이 투자해 주셨다. 원래 전정환 센터장님이 이민석 교수님과 김성훈 교수님을 소개해 주셨고 이렇게 세분으로 앤젤투자를 모시고 싶었는데, 아쉽게도 김성훈 교수님이 네이버에 들어가시면서 불가능하게 되었다. 그래서 그전에 업무 제휴를 한 적 있는 이종관 대표님께 부탁을 드려서 세분 6천만원이 모아지게 됐다.  * 참고로 엔젤투자는 상황따라 다르지만 보통 기업벨류를 1억~10억 안에서 한다. 인프랩은 서비스가 이미 워킹되고 유저들도 계속 확보되고 있었기 때문에 저 벤드 내에서 거의 최상위로 벨류로 받았다. 앤젤투자는 2017년 4월 진행 및 완료가 됐고, 같은 시간에 최초 팀원이 생겨 정식적으로 회사 모습을 갖추기 시작했다.   자금 및 팀원 수 (201601~201710)

창업 · 부업인프랩재무적기록인프랩인프런창업투자

일프로

[쿠버네티스 어나더클래스] 배포를 시작하기 전에 반드시 알아야 할 것들 #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

윤선미

인프런 수강생은 이런 데이터가 궁금해요!

안녕하세요. 커뮤니티 데이터리안의 윤선미입니다.  오늘도 애정을 가지고 인프런에 대해서 얘기를 해보려고 합니다. 세계관 여기에는 다 인프런과 친하신 분들이니까 굳이 설명할 필요는 없지만, 용어를 정리하는 의미에서 간단하게 인프런의 세계관에 대해서 얘기해볼게요. 이곳에는 두 종류의 사람이 있습니다. 강의를 만들어 업로드 하는 사람: 지식공유자 강의를 수강하는 사람: 현재는 학생 또는 수강생이라고 부릅니다. 데이터리안은 강의를 제작하면서, 종종 다른 지식공유자분들의 강의를 수강하기도 하니까 분류하자면 둘 다에 속합니다. 지식 공유자 입장에서 지식공유자 활동을 하면서 인프런이 제공해주고 있는 데이터 이외에 다른 데이터들을 알고싶다는 생각을 꾸준히 해왔는데요. 예를 들면 이런겁니다. 우리 강의에 어떤 경로로 유입되었을까? 강의를 완강하지 않았다면 이탈 지점은 어디일까? 기초 SQL 강의를 들은 수강생이 중급 SQL 강의도 결제했을까? 글로 정리된 내용은 <인프런 지식 공유자는 이런 데이터가 궁금해요!>에 있습니다. 지식공유자 입장의 데이터가 더 궁금하신 분들은 위에 링크를 클릭해주세요. 수강생의 입장에서 오늘은 수강생의 입장에서 제공받고 있는 여러 데이터들에 대해서 얘기를 해보려고 합니다. 인프런에 수강생이 볼 수 있는 다양한 화면이 있지만, 수강생 학습 대시보드와 강의 소개 페이지를 중심으로 얘기를 해보겠습니다. 아이디에이션은 @S, @북북, @민주, @leebom, 그리고 @선미 가 함께했습니다. ... 더 읽어보기: https://velog.io/@datarian/inflearn-student

데이터 분석인프런데이터분석데이터리안

셰리

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

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

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

hjoo

스타트업 투자 재무적 Log 3 (팀빌딩 + 1차 리뉴얼)

8. 재무적 컨셉 난 계획적인 편이 아니라 디테일한 재무 계획을 세운적은 없지만, 컨셉이 확실하긴 했다. 딴 얘기지만 주위 좋은 대표라고 생각되는 분들은 대부분 어정쩡한 중간 없이다음 둘중 하나였던거 같다.1. 엄청 꼼꼼하고 치밀해서 디테일한 계획을 철저하게 세우는 부류2. 에고(Ego) 가 강해 계획은 없지만 컨셉이 잡혀있는 부류난 좋은 대표인지는 모르겠지만 후자였다. 돌아와서 재무적 컨셉을 얘기해보자면. 서비스는 급진적으로. 🏃🏻돈과 팀은 보수적으로. 💰 이같이 정한 이유가 몇가지 있는데 가장 큰 이유는 걍 나의 성향이다.말 울렁증이 심하다는 핸디캡을 알고 있어서 반 강제적으로 투자 없이 자생하는 것을 컨셉으로 해왔다. 인사이트 있는 투자자라면 알아서 우릴 알아봐 줄테지만 보통 사람 투자자은 발표 울렁증이 있는 대표가 있는 회사를 신뢰하진 못할 테니까.그래서 언제나 인프랩은 BEP(손익분기점) 을 맞춰가면서 성장하는것을 컨셉으로 해왔다. 팀원 뽑으면 좀 기다려서 BEP 맞추고. 그럼 또 팀원 뽑고. 또 BEP 맞추고 하는 식으로.. 선 투자 후 뒤돌아보지 않고 불태우면서 하는 공격적인 성장이 있고, 우리 인프랩 같이 BEP 맞추면서 하는 성장이 있을텐데 뭐가 맞다 그런건 없는거 같다. 보통 스타텁은 전자고, 우린 후자를 선택했다. 9. 서비스 리뉴얼 – 2018.11 ~ 2020.04 2018년 여름 본엔젤스에게 시드투자 5억을 받으니, 명확하게 남아있던 과제를 진행하기로 결정했다. 바로 서비스 리뉴얼인데, 초기버전 인프런 서비스는 나 혼자 만든거라 기술적으로 구멍이 정말 많았다. 당시 유저 수 가 5만 정도 됐었는데, 유지보수와 트래픽이 감당이 안되기 시작했다. 막 페이지 로딩이 8초~10초씩 걸렸다..😱 이때 팀이 딱 6명 이었다. CEO겸 개발자 1명(접니다 🙋🏻) + 개발자 2명 + 운영3명.6명 있는 회사에서 절반의 인원이 유저 수가 몇만명이 되는 서비스를 단지 기술적인 문제로 리뉴얼 하는건 어떻게보면 진짜 미친짓 으로 보일 수도 있었다. 게다가 대표가 개발에 참여한다니!? 그래도 본능적으로 지금보다 더 늦으면 끝이다 싶었다. 그래서 앤트맨 프로젝트를 고고씽 했다. 나 + 개발자 두명(후리, 댄) 셋이서 근 5개월동안 서비스 DB 부터 HTML 까지 다 뒤집어서 새로 만들었다. 이때 지금 생각해보면 진짜 너무 힘들었다.매일 10시 반쯤 출근해서 6시까지는 대표가 해야되는 이런저런 일 하고 6시부터 새벽 3~4시까지 개발하다 신해철의 ‘민물장어의 꿈’ 들으면서 집가고..(백만번 들었다.) 집 도착해서 옷 입은체로 드라마 미생 15분 정도 보다가 나도 모르게 잠들고.. 한 5개월간 이랬다. 다행이 개발하는 우리 셋다 미쳐버리기 전에 서비스 리뉴얼이 완료됐다. ㅋ(서비스 제품 관점에서의 회고글 링크) 우측 점선이 리뉴얼 완료 시점!! 실제로 리뉴얼 순간부터 좀 더 폭발적으로 성장을 시작했다. 10. 팀빌딩 잠깐 팀빌딩에 대해서 간단히 얘기해보자면난 1인기업으로 시작한데다 일반적인 시선으로는 말을 유창하게 하는것도 아니고, 카리스마 있게 생기지도 않아서(하지만 호감형이라 주장한다!!), 게다가 학벌등 인맥도 없었어서 팀 빌딩에 대한 우려를 주변에서 많이 했던거 같다. Seed 투자 라운드에서 투자 조건이 C레벨을 뽑을것, 좋은 팀을 만들것 이기도 했다.ㅎㅎ Angel 투자 라운드에도 전정환 센터장님도 팀빌딩에 대한 걱정을 은근히 많이 하셨다.솔직히 나도 걱정됐다.ㅎㅎㅎㅎㅎ 안해본데다가 막막하니까. 최초 팀원은 나랑 정반대의 성향을 가진 쑤를 총무,행정 역할로 뽑았다. 이때 다들 미쳤다고 했다. 초기 팀은 총무, 행정일은 대표가 하는거라고, 영업이나 다른 역할을 뽑으라고들 조언들 해줬다. 음.. 내 생각은 달랐다. 초기 팀일수록 대표는 루틴한 일에서 벗어나서 뾰족하게 경계선을 계속 뚫어내야 된다고 생각했다. 그래서 그때 내가 하기 싫고, 힘들어하는 일들을 나보다 더 잘할 수 있는 사람을 뽑았다. 지금 와서 생각해봐도 그땐 내가 맞았던거 같다. 이후로도 개성이 뚜렷하고 팀의 구멍을 매꿔줄 능력치를 가진 것에 초점을 두고 뽑았다. 초기팀에서 인맥이나 돈이 받쳐주는게 아니면, 경험많고 모든면에서 훌륭한 사람은 애초에 뽑기 어렵기 때문에 한쪽으로 뾰족한 사람을 파티원으로 모시는게 현명한 선택이다. 그리고 태도를 정말 중요하게 봤다. 태도라는게 공손하게 손모으고 인사하고 그런게 아니라 얼마나 이쁘고 부드럽게 자기 주장을 강하게 전달하는지?? 좀 이런거? 말이 좀 이상한데 우쨌든 그런걸 중요하게 생각했다. 이거는 지금도 2차 면접에서 내가 많이 보는 부분중 하나다. 팀은 보통 발전할수록 경험이 많고, 고른 부분에서 능력이 좋은 사람들이 새롭게 들어오게 된다. 그 과정에서 뾰족한 초기 팀원들이 성장하지 못하면 슬픈 상황이 많이 연출되는데, 감사하게도 아직까지 우리 팀원들은 균형있게 잘 성장중인거 같아서 좋은거 같다. 계속 잘 이어가면 좋겠다. 11. 투자 받을까 말까 – 2019년 ~ 2021년 1월 서비스 리뉴얼을 통해 골든타임을 지켜냈고, 이후로 다시 순조롭게 성장을 시작했다. 그 밖에도 여러 일이 있었는데, 창업 초기부터 계속 있었던 분당 판교를 떠나서 강남역에도 잠깐 갔다가 출퇴근 빡쌔고 산책할데 없어서 판교로 다시 내려왔다. 판교로 다시 내려올때가 딱 10명이었다. 재무적으로는 인프랩 재무 컨셉에 맞게 BEP 를 계속 맞추고 있었다. 해외로 워크샵 가고, 팀과 서비스가 성장하는 동안에도 사용한 투자금보다 통장 잔고가 더 늘었다. 투자 받지 말자. 🙅🏻 투자에 대해서 고민이 좀 많았다. 우짜든 우리는 스타트업씬에 있기 때문에 투자유치에 대한 생각이나 사례가 항상 가까이 있다. 주위에서도 넘 많이 들리고, 소개받고, 연락이 온다. 실제로 대교인베, HB 인베, 에이티넘 등이랑은 꽤 진지하게 이야기도 오가고 IR 이나 벨류 협상까지도 진행했었다. 근데 투자까진 이어지지 않았다.  이때 본엔젤스에게 받은 Seed 투자금도 하나도 사용하지 않고 오히려 두배는 늘어 있는 상황이었고, 앞으로도 충분히 자신이 있었다. 투자 받지 않더라도 100억씩 투자 받은 다른 회사들보다 더 잘할 자신이 있었다. 그래서 “누가 와서 돈다발 던져주면 받고 아님 받지 말자.” 로 기조를 정했다. 근데 그러니까 당연히 못받았다.ㅋㅋ 종종 연락오고 소개받는 VC들과 미팅이 있었고, 특히 에이티넘과는 2020년 연말에 투자관련 미팅이 진지하게 있고 자료 검토도 있었는데 아주 쿨하게 까이고 상처받아서 걍 투자 따위 안받고 가자고 마음먹었다.  투자 받자. 🙆🏻 2021년 1월 중순쯤? 갑자기 투자를 받아야겠다고 생각했다.팀이 20명이 넘어가고, 문화가 견고해 지는 것을 느꼈다. 계속 좋은 사람들이 들어왔다. 이들은 아직 사회적으로 스스로를 증명하진 않았지만, 내가 보기엔 단단한 코어와 열정을 갖고 있는 + 게다가 선한 사람들이 모였다. 이런 팀원들에게 좋은 시니어, 그리고 엄청나게 성장하는 회사의 모습을 보여주고 각자 스스로 주인공이 될 수 있는 기회를 주고 싶었다. 물론 나도 포함이고.  그래서! 투자를 받기로 결정했다. 💰 살짝 고민은 있었다. 이때 개인적으로는 투자를 받지 않는다면 미디엄레어 부자가 되는게 확실했다. 몇억씩 영업이익도 나면서 계속 성장하고 있었고, 종종 좋은 제안도 왔었으니까. 팀적으로봐도 뭉쳐 일하는것도 재밌었다. 팀원들도 만족도가 높은거 같았고.하지만 투자를 받는다면 이 모든게 불확실성이 확 올라가 버리는 것이다. 그래서 투자 받는 여부가 나름대로는 결정을 해야되는 사안이었다.  그래도 역시. 이 인프랩 사람들과 훨씬 더 높은 곳으로 올라가보고 싶다는 생각이 들었고, 진행하기로 결정했다. 그동안 연락이 닿았던 VC 분들께 투자 라운드 시작한다고 연락을 드리고, 본엔젤스 전태연 파트너님에게도 VC 들을 소개해 달라고 부탁했다. 이때 즘이 26명이 됐다. 현금보유고는 11억 정도가 있었다.Seed 투자 5억 받을때와 비교하면 팀은 4배가 되고, 현금은 2배가 되고, 매출은 10배가 됐다.  

창업 · 부업인프랩인프런스타트업창업투자인프랩재무적기록

솔 (Sol)

IT 개발 용어 뜻, 잘 모른다면? (API, 기술부채, 컴파일, 마이그레이션...)

혹시 내 얘기 아닌가요? 그렇다면 주목! IT 회사 들어왔는데, 다들 무슨 말 하는지 모르겠다! 개발자랑 농담 주고받고 싶다! 개발 용어, 뭔진 알겠는데... ‘느낌적인 느낌’만 안다! 프로그래밍에 관심있는데 진짜 아무것도 모른다...! 이게 대체 뭐람... 👉 그렇다면, 지금 인프런 공식 SNS 팔로우하고 매주 올라오는 인프런 단어짱을 읽어보세요!페이스북 | 인스타그램 | 트위터  오늘은... (두둥) 인프런이 전.격.홍.보! 안녕하세요! 인프런 콘텐츠 마케터 솔🌞입니다. 인프런 뉴스레터 및 ‘인프메이션’ (구: 주간 인프런) 발행을 맡고 있는데요.인프런 공식 SNS 채널 삼대장, 페이스북 + 인스타그램 + 트위터에서만 볼 수 있는 스페셜 콘텐츠(!)의 존재를 모르고 계셨던 인프러너 분들께 깜짝 소식을 전하러 왔습니다.바로... 2022~2023년 동안 인프런 공식 뉴스레터로 보내드리던 ‘인프런 단어짱’ 코너가 올해 3월부터 공식 SNS에서 재개되었어요.  인프런 단어짱이 뭔데? IT 용어에 대한, 왕초보도 알 수 있는 (중요!) 쉬운 해설이 필요하다는 건 저 역시도 인프런에서 일하면서 직접 뼈저리게 느끼곤 했는데요.(nn년 전 IT와 아~무 상관없는 전공 + 구)스타트업 깡신입의 대환장 조합...! 🥲)그래서인지, 그동안 인프런에서 발행했던 수많은 콘텐츠 중에서도2020년 ‘뉴비를 위한 개발 용어 사전’2022년 ‘소소한 IT 용어 모음집 - 인프런 단어짱’에 반응을 보내주셨던 분들이 유독 많아 놀랐던 기억이 있어요. 아무튼, 이번에 다시 부활한 인프런 단어짱은 더 자주 + 더 쉽게 더 많은 분들께 IT 개발 용어 뜻을 철저히 뉴비, 개발 왕초보 관점에서 알려드리는 걸 포부(?)로 삼고 있답니다! 담당자의 과한 드립 욕심(...)은 보너스 오늘까지 API, 기술 부채, 컴파일/인터프리트, 백도어, 마이그레이션 등 여러 IT 용어에 대한 해설과 에피소드가 공개되었으니 뜻이 알쏭달쏭하셨거나, 인프런이 하고 있는 무언가(?)가 궁금하신 분들이라면 언제든 인프런 공식 페이스북 / 인스타그램 / 트위터를 찾아와주세요! 여러분의 팔로우와 좋아요❤가 인프런 담당자를 춤추게 합니다...! 덩실덩실 항상 인프런과 함께해주시는 많은 분들께 감사드립니다. (Hoxy... 인프런이 초면이라면, 이것도 인연인데 앞으로 더 자주 만나요! 🫂)우리 함께 배우고 나누고 성장해요! 🍀인프런 마케터 솔 드림

개발 · 프로그래밍 기타기술부채컴파일백도어마이그레이션IT인스타그램페이스북트위터API인프런

일프로

[쿠어클#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

일프로

[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

셰리

알아두면 좋은 웹 용어! GNB, LNB, SNB, FNB (feat. 인프런)

웹사이트에서 유저의 서비스 탐색을 도와주는 카테고리. 서비스를 찾은 유저가 원하는 것을 쉽게 찾아낼 수 있게 직관적인 UI 구성이 필요한데요. 내비게이션 바라고 불리는 이 카테고리 영역은 위치와 역할에 따라 GNB, LNB, SNB, FNB 등으로 나눌 수 있어요. 인프런 사이트에서 GNB, LNB, SNB, FNB를 찾아볼까요?1. GNB (Global Navigation Bar)웹사이트 전체에 똑같이 적용되는 내비게이션 바이며, 어떤 페이지를 클릭해도 공통으로 쓸 수 있는 메뉴입니다. 보통 웹사이트 최상단에 위치하고 있어 메인 메뉴라고도 불러요. GNB의 Global 역시 웹사이트 모든 영역에 해당된다는 의미를 내포하고 있어요. 인프런 사이트에선 상단의 '강의', '로드맵', '멘토링' 등의 메뉴가 GNB 영역입니다. 2. LNB (Local Navigation Bar)GNB를 클릭하거나 마우스를 호버했을 때 노출되는 하위 메뉴입니다. LNB의 Local은 웹사이트 중 특정 영역으로 한정한다는 의미가 있어, LNB 영역을 서브 메뉴라고도 해요. 인프런 사이트에선 GNB 영역에 마우스를 호버했을 때 LNB가 노출돼요. 3. SNB (Side Navigation Bar)보통 메인 메뉴와 서브 메뉴를 제외한 나머지 메뉴를 SNB라고 해요. 보통 왼쪽이나 오른쪽에 위치하고 있어 Side라고 표현합니다. 인프런에서 GNB 영역의 '강의'나 '로드맵'을 클릭해서 이동했을 때 왼쪽에 SNB가 노출됩니다. 4. FNB (Foot Navigator Bar)웹사이트 가장 하단에 위치하는 메뉴입니다. GNB처럼 사이트 내 모든 페이지에 공통으로 노출되는 메뉴입니다. 가장 하단에 위치하고 있어 Foot이라고 표현하며, 해당 영역을 푸터(Footer)라고도 해요. 보통 기업 정보 등 사이트의 정보가 위치하는 영역이에요. 인프런의 FNB에는 기업 정보, 코드 등록, 고객센터 등이 있어요. 

웹 개발인프런GNBLNBSNBFNBinflearn

hjoo

스타트업 투자 재무적 Log 2 (Angel ~ Seed)

5. 신용보증기금 대출 (2017년 8월) 법인화 하고 앤젤투자를 통해 7천만원이 생기고 문화창조허브에서 사무실 지원프로그램에 합격해 첫 사무실도 얻게됐다. 근데 자금적으로 7천만원은 모멘텀을 만들기엔 아쉬운 금액이다. 그 정도 자금은 서비스를 만들고 워킹시키는 정도고, 그당시 인프런은 서비스 워킹이 되던 시기라 가속도와 지속성을 줄 광고비용과 6명 이상의 팀이 필요했고 당연히 자금도 더 필요했다. 그러던 와중에 옆사무실 이준승 대표님께서 신용보증기금(이하 신보)에서 꽤 큰 자금을 대출받은 이야기를 해주셨다. 아마 10억이었던거 같은데 잘 생각이 안나네. 그얘기 전해듣고 이거다! 라고 하면서 신보로 달려갔다. 문화창조허브 센터장님 추천서가 있으면 더 잘 받을 수 있다고 해서 추천서를 부탁해서 받기도 했다. 근데 결과적으로 우린 10억이 아닌 1.5억 밖에 못받았다.ㅋㅋㅋ 심사 단계에서 대표와 팀원들 이력, 학력 등을 보는데 그런 점수가 거의 바닥 뚫고 지하실이라 추천서와 매출이 있더라도 그 이상의 자금을 받을 순 없었다. 그래도 그거라도 받는게 좋겠다 싶어서 일단 신보 대출을 진행하고 마음의 평화를 조금 얻었다. 신용보증기금, 기술보증기금 등에서 대출을 받을 수 있다면, 무조건 받아두는게 좋은거 같다. 게다가 마이너스통장으로 대출금을 받으면 쓰기 전까지 이자도 안나가니까. 실제로 우리는 대출금을 사용한적은 없었다. 그래도 마음의 평화를 얻을 수 있어, 자금적으로 선택지가 넓어지게 된다. 6. 추가 앤젤투자 (2017년 8월~) 앤젤투자가 이후 두번 더 있었다. 카이스트 창투의 정재호 이사님이 찾아오셨는데, 오셔서 투자 이야기보다 나에게 스타트업 발전 과정과 팀 성장에 대한 강의를 해주셨다.ㅋㅋㅋ 비닐같은 흰 판에 사인팬으로 그림 그려가면서 이런 저런 설명을 해주시던게 생생히 기억난다. 그때 들을 설명들이 팀빌딩과 이후 투자 그림을 그리는데 도움이 많이 됐다. 결국 카이스트 창투와 투자 연은 없었고, 정재호 이사님 부부께서 2017년 12월에 앤젤투자로 주주로 들어오시게 됐다. 최성철 교수님도 앤젤투자자가 되주셨다. 첨 인연은 최성철 교수님이 인프런을 먼저 알고 연락을 주셨는데, 같이 와디즈에서 크라우드펀딩으로 강의를 만들기로 했다. 나이도 동갑이고 하고 사람도 무척 좋다. 역시 앤젤투자 하고 싶다고 하셔서 마지막 앤젤투자자이자 친구가 됐다. 결과적으로 인프랩은 약 8000천만원을 앤젤투자 자금으로 모았다.8천만원이 개인에게는 무척 큰 금액이지만, 사업할때는 진짜 순식간에 사라지는 정도의 금액이다. 그래서 어쩄든 VC에게 Seed 투자를 받아야 겠다고 생각했다. 6. 귀인2 (2017.9) 시드 투자를 받는다고 하면 엄청 유명한데서 받고 싶었다. 왜냐면 정말 어쩌다가 VC 만날일 들이 있었는데 그때마다 이사람들이 아무도 우리 회사와 서비스를 몰랐다. ㅋㅋㅋㅋ 우리랑 비슷하면서 실적이 잘 안나오는 다른 회사들은 알면서 인프런에 대해서 소개하면, “뭐? 인포론?? 오 이런것도 있었군요. 근데 이게 되요??” 이런 식이었다. 화딱지 났다. 그래서 엄청 유명한 VC 에게 투자받으면 이쪽 업계에서 소문나서 알겠지 하는 마음에 무조건 유명한데서만 받기로 마음먹었다. 그래서 초기 투자사중 최고로 유명한 몇개 정도 회사에 콜드메일을 보냈다. 나중에 안 사실이지만 콜드메일은 잘 답장 안한단다.ㅋㅋㅋ 어떻게든 인맥 만들어서 누구에게 소개해 달라고 해서 만나야된다. 당연히 다 응답없었고 감사하게도 본엔젤스만 전태연 파트너님(귀인2)이 답장을 주셨다. 전태연 파트너님은 지금 인프랩의 사외이사 시고, 시리즈A 투자도 도와주시고 참여해 주셨다. 많은 수의 투자자를 만나보지 않았지만, 정말 진정성 있으시고 좋은 투자자라고 생각한다. 게다가 창업 경험도 있으시고, 나랑은 많이 다른 성향이신데 그래서 해주시는 조언이 내가 가진 선택지를 객관적으로 보는데 도움이 많이 된다. 7. Seed 투자 유치 (2017.09 ~ 2018. 07) 콜드메일 보낸곳들중 본엔젤스에서만 답장이 왔고, 전태연 파트너님과 인연이 시작됐다. 1차 처음 미팅 – 2017.09첫 미팅은 콜드메일 보낸 직후 2017년 9월에 했는데, 강남역 좀 올라가서 알베르? 좀 이쁘고 큰 카페에서 만났다. 그때는 내가 투자자 만나는 개념이 너무 없었다. IR 자료는 커녕 매출 그래프 그려진 종이 2장 들고갔다. 그래도 풀컬러로 인쇄했다. 지금 와서 생각해보면 전파트너님 입장에선 좀 황당했을거 같다. 실제로 부실한 자료에 첫 미팅이 금방 끝났다. 그때 정확히 기억이 안나는데 투자 받기위해선 투자자에게 어떤 자료를 보여줘야 되는지 친절하게 설명을 해주셨던거 같다.우짜든 만난지 15분정도만에 미팅이 파했다. 2차 투자 협상 및 불발 – 2017.12 몇개월 지나면서 나도 다른 몇명의 투자회사와 만나보면서 어느정도 투자자 만나는 예의와 기본 센스를 갖추게 됐다.IR 자료도 그럴듯하게 만들고(지금보면 끔찍하지만) 전태연 파트너께 미팅 요청을 했다. 이때는 팀이 4명이 된 상황이고 인프런 서비스도 꾸준하게 성장하고 있어서 전태연 파트너님도 긍정적 이었다. 이야기가 잘 진행되긴 했는데, 본엔젤스에서 제시한 투자액수가 내가 제안한 것보다 적었다. 그래서 아쉽지만 더이상 진행하지 않기로 했다. 사실 초기에 벨류나 투자액수가 그리 중요하진 않다. 그때도 그렇게 생각하고 있었고..근데 가치를 존중받지 못한다는 느낌이 들었다. 어려운 문젠데 기분 문제가 아니고, 창업자에게는 투자 파트너를 가늠하는 기준이 되기 때문에 아쉽지만 드랍하는게 맞다고 생각했었다. 그래도 본엔젤스한테 무지 받고 싶었어서 너무너무 아쉬웠다. 😭 휴식기본엔젤스랑 협상 결렬되고 2018년 상반기에 블루포인트, 매쉬업, 스프링캠프 등을 만났었는데 다 만나기만 하고 안됐다. 그래서 “걍 투자 없이 가자!” 하고 꾸역꾸역 서비스 개선하고 발전시켰다. 3차 – 다시 우연히 만남 – 2018.05회사 자금 기조를 “투자 누가 와서 해주면 받고 안해주면 우리끼리 걍 가자. 😂” 로 정하고 서비스 개발이랑 사업적인 제휴 등의 일에만 신경썼다. 근데 일이 될라니까 신기하게 다시 연결이 되더라. 우리 앤젤투자자중 정재호 이사님이 카이스트창투 에서 퇴사를 하셨는데 퇴사하시면서 ‘퇴사파티’ 를 열었다.ㅋㅋㅋㅋㅋ 사람들 모이고 소개하고 인사하고 이런거 힘들어해서 진짜 잘 안가는데, 정재호 이사님 ‘퇴사파티’ 니까 재밌기도 하고 신기해서 참석했다.일기로도 썼었네. (https://www.hyungjoo.me/퇴직-축하-파티/) 근데 이 ‘퇴사파티’ 에서 전태연 파트너님을 다시 만났다. 난 우형의 김봉진 대표님처럼 알토스한테 차이고 매달 자료 업데이트 해서 결국엔 투자 받아내고 그런 아름다운 일화의 스타일은 아니어서, 저번 투자 드랍 이후에 본엔젤스와 소통이 없었다. 근데 우연히 여기서 다시 만나게 된거다. 정재호 이사님 퇴사 덕분에!! 뒤돌아 생각해 보면 진짜 넘 신기하고 감사하네.ㅋㅋㅋ 이때 다시 만나 안부 묻고 자연스럽게 다시 투자 이야기로 이어졌다. Seed 라운드로 투자 금액과 벨류를 협상하고 정식으로 IR 을 하기로 했다. 이번엔 잘 협상이 됐다. 사실 이때는 인프런이 VC 들에게도 막 알려지기 시작할때라 갑자기 오퍼들이 들어왔다. 그래서 본엔젤스보다 훨씬 좋은 조건을 제시한 곳들도 있었는데, 난 그냥 본엔젤스에만 단독으로 5억을 받기로 마음먹었다. 이번 라운드가 중요한게 아니라 앞으로가 중요한거라, 본엔젤스에게 단독으로 5억 투자 유치 라는 타이틀이 이후 시리즈A 투자 받을때 좋을거 같았다. 💰 Seed 투자 5억 유치 – 2018.08극초기 투자의 일반적인 절차는 정해진 날짜에 회사가 투자사에 가서 IR(투자설명회)를 하고, 결과를 받고, OK 됐다면 실사를 진행해 진짜 투자 적합성을 한번 더 검증한다. IR 하러간 날이 완전 한 여름 이었다. 본엔젤스 대표님 두분이랑 파트너들과 심사역들이 좌르르 앉아있었다. 늘 하던것처럼 버벅대면서 IR 발표를 30분정도 진행했고, 20분정도 질의응답이 있고 끝났다. 발표자가 나가면 파트너들과 심사역들이 토론으로 투자 여부를 결정한다. 판교 사무실 도착하고 더위 식할때쯤 전태연파트너님에게서 전화가 왔다. 투자 진행하자고.사실 안될수도 있다고 생각했다. 팀창업 에만 투자해온 본엔젤스에게 1인 창업 기업인 인프랩은 특이 케이스였고, IR 발표하는거 보면 이후 투자 가능 여부에 대해서도 걱정이 있을테니까. 실제로 그런 걱정이 있었는데 전파트너님이 설득 하셨다고 들었다. 역시 귀인2 이후로 실사 절차가 있었는데, 그동안 은행 자금출처 내역이랑, 계약서들, 세금납부여부, 대표 신뢰성 등등.. 을 검토한다. 결과적으로 인프랩은 2018년 8월에 본엔젤스로부터 5억원을 투자 유치했다.이 즈음에 팀원들도 한명한명 늘어나 6명이 됐고, 서비스 리뉴얼을 준비하기 시작했다.   *참고로 이글을 보는 초기팀이 있다면, 본엔젤스 초 강추합니다.대표님 두분, 파트너님들이 훌륭한 분들이 많고, 그동안의 평판도 정말 좋아요. 경험해본 사람 입장에서 초강추 할 수 있는 좋은 VC 인거 같습니다.글고 뭣보다 본엔젤스에서 투자받으면 다른 VC들이 그 회사에 대해 알게됩니다!

창업 · 부업인프런인프랩인프랩재무적기록스타트업창업

kamser

인프런 워밍업 클럽 백엔드 0기 수료식 후기

인프런 워밍업 클럽 0기 후기 인프런 강의는 회사 업무를 빠르게 적응하려고 듣는 강의가 있고,회사 로직에 추가로 적용시키고 싶은 기술이거나 혹은 미래를 위해서 듣는 강의도 있습니다. 전자의 학습 방법은 예제 코드로 학습을 한 후에 회사에 작성된 다른 선배 개발자 분들의 실무 코드를 보면서 학습할 수 있습니다. 후자 방식으로 듣는 강의는 대부분 예제 코드로 학습을 하고 본인이 작성한 코드만 보게 됩니다.그러다보니 전자의 방식보다 아쉬운 부분이 생깁니다.실무 수준까지는 아니더라도 파일럿 프로젝트 수준의 코드나 다른 개발자 분들이 작성한 코드를 보기 어렵습니다.저는 다른 개발자 분들이 작성한 코드를 보는 것도 하나의 좋은 학습 방법이라 생각하는데 그걸 하지 못합니다. 인프런 워밍업 클럽 스터디는 저에겐 후자의 방식이지만 아쉬운 부분을 채워줬습니다.다른 러너분들이 제출한 과제를 보고 비교하며 학습할 수 있었고,과제의 응용 버전인 미니 프로젝트를 진행하면서 단순히 코드비교 뿐만 아니라 데이터 구조를 어떻게 설계를 했는지 볼 수 있었습니다.혼자서 듣는 강의였다면 이런 좋은 경험을 하지 못했을거라 생각합니다. 결론은 너무 좋은 경험이였고, 다음 1기도 시작하신다면 꼭 신청하려고 합니다. 감사인사존경하는 최태현 지식 공유자님 감사합니다.정규 라이브는 제공된 일정보다 더 길었고, 일정엔 없던 긴급 라이브까지 진행하시느라 목이 쉬시는 열정적인 강사님 모습에 제가 오히려 힘을 받았습니다.특히 과제 리팩토링과 코드 리뷰 라이브 덕분에 제가 헷갈렸던 테스트 개념과 작성하지 못했던 구현 코드까지 수정 했습니다.그외에 Live Q&A와 수료식 Q&A에 답변해주셨던 내용은 잊으면 안될거같아서 따로 정리까지 했습니다.3주간 열정적으로 스터디 진행해주셔서 감사합니다. 이 스터디를 기획하신 담당자분들과 준비해주신 담당자분들에게 모두 감사합니다.담당자분들께서 많은 러너분들 관리해주시고, 음식 준비해주시고, 나누어 주시고,야근까지 하시느라 힘드셨으텐데 친절하게 맞이해주셔서 감사합니다.덕분에 스터디를 진행하면서 처음 자바로 크레이지 아케이드를 만들면서 행복했던 그 때 감정을 다시 느꼈습니다. 그리고 수료식 마지막 시간이였던 네트워킹 시간에 대화를 리드해주신 조성륜 개발자분에게도 감사인사를 전하고 싶습니다.요즘 블로그 글을 쓸때 업데이트를 어떻게 해야할지 고민이 있었는데 위키처럼 작성하신다는 걸 알려주셔서 고민이 해결되었습니다 감사합니다.

인프런인프런워밍업클럽스터디0기

양성빈

[인프런 워밍업 스터디 클럽] 0기 백엔드 미션 - 어노테이션(Day1)

어노테이션 서론드디어 '인프런 워밍업 스터디 클럽 0기' 첫 날이 밝아왔다. 강의를 듣고 미션을 보니 어노테이션에 관련한 내용이었다.나는 이 미션을 보고 오히려 기쁜 마음이 들었다. 😆 내가 강의를 들으면서 어노테이션 부분이 많이 궁금하였는데 이렇게 공부하게 될 계기가 생긴 것 같아서 미션도 완성시키고 나 스스로 깊게 공부도 할 겸 미션을 시작할려고 한다. 미션 내용은 아래와 같다.진도표 1일차와 연결됩니다우리는 최초로 API를 만들어 보았습니다. GET API를 만들기 위해 사용했던 어노테이션에 익숙하지 않다면 자바 어노테이션에 대해서 몇 가지 블로그 글을 찾아보세요! 다음 질문을 생각하며 공부해보면 좋습니다! 😊 [질문]어노테이션을 사용하는 이유 (효과) 는 무엇일까?나만의 어노테이션은 어떻게 만들 수 있을까?내가 알아본 어노테이션의 정의나는 강의의 실습을 통하여 스프링 부트 프로젝트를 생성하고, GET API를 만들어보고 포스트맨을 통하여 테스트 작업도 해보았다. 나는 여기서 다양한 어노테이션들을 볼 수 있었다. @SpringBootApplication, @RestController, @GetMapping 등 여러 어노테이션들을 볼 수 있었다. 여기서 나는 어노테이션이 무엇일까 고민을 해보았다. 단순히 어노테이션은 @ 붙인거라고만 알고 있었기에 이번 기회에 미션도 수행할 겸 깊게 알아보는 것도 좋다 생각하여 공부해보기로 하겠다.먼저 어노테이션이 대체 어떤 정의가 있는지 구글링을 해보기로 하였다. 구글링을 해보니, 다양한 블로그들이 나왔지만 정의가 수록된 위키백과를 먼저 참조해보기로 하였다. 위키백과는 다음과 같이 정의를 내렸다. 자바 어노테이션은 자바 소스 코드에 추가하여 사용할 수 있는 메타데이터의 일종이다. 보통 @ 기호를 앞에 붙여서 사용한다. JDK 1.5 버전 이상에서 사용 가능하다. 자바 어노테이션은 클래스 파일에 임베디드되어 컴파일러에 의해 생성된 후 자바 가상머신에 포함되어 작동한다. 그리고 강의 중에 코치님께서도 어노테이션에 대해 아래와 같이 언급해주셨다. 어노테이션은 어노테이션마다 너무 다양한 역할을 한다. 또한 마법같은 일을 자동으로 해준다는 것이다.예를 들어서, @SpringBootApplication 어노테이션은 스프링을 실행시킬 때 다양한 설정이 필요한데 이 설정을 모두 자동으로 해준다. 또한 이런것이 가장 핵심적인 마법같은 일이다.위키사전, 코치님의 설명을 통해 어노테이션의 정의를 알 수 있었다. 좀 더 내가 설명한 식으로 풀어보자면 다음과 같다.자바의 어노테이션은 코드에 추가 정보를 제공하는 데 사용되며, 컴파일 시간, 배포 시간, 또는 실행 시간에 해당 정보를 활용할 수 있습니다. 이를 통해 개발자는 코드에 메타데이터를 추가하여 코드의 가독성, 유지 보수성을 향상시키고, 다양한 도구와 프레임워크에서 활용될 수 있는 정보를 제공할 수 있습니다.좀 더 자세히 풀어보자.어노테이션은 자바 5부터 도입된 기능으로, 코드에 대한 메타데이터를 제공하는 방법입니다. 어노테이션은 주석과 비슷하지만, 실제로 코드에 영향을 줄 수 있으며, 컴파일러에게 정보를 제공하거나 실행 시간에 특정 동작을 하도록 할 수 있습니다. 어노테이션은 선언적 형태로 코드 안에 포함되어, 클래스, 메소드, 변수 등 다양한 요소에 적용될 수 있습니다.이제 위의 내용을 좀 더 정리해보겠다. 어노테이션이란?자바를 개발한 사람들은 소스코드에 대한 문서를 따로 만들기보다 소스코드와 문서를 하나의 파일로 관리하는 것이 낫다고 생각했다. 그래서 소스코드의 주석에 소스코드에 대한 정보를 저장하고, 소스코드의 주석으로부터 HTML 문서를 생성해내는 프로그램(javadoc.exe)를 만들어 사용했다. 그런데 여기서 의문점이 하나 든다. 🙋🏻 왜 어노테이션이라는 것을 살펴보려 하는데 주석이라는 내용이 먼저 나올까? 프로그램의 소스코드 안에 다른 프로그램을 위한 정보를 미리 약속된 형식으로 포함시킨 것이 바로 어노테이션이다.어노테이션은 주석(comment)처럼 프로그래밍 언어에 영향을 미치지 않으면서도 다른 프로그램에게 유용한 정보를 제공할 수 있다는 장점이 있다. 📚 어노테이션(annotation)의 뜻은 주석, 주해, 메모이다.package org.example; public @interface SampleAnnotation { }위의 코드는 인텔리제이로 나의 어노테이션을 만든 코드이다.그럼 인텔리제이로 어노테이션을 만드는 것도 끝났으니 이제 끝인가? 나는 여기서 더 나아가서 이 어노테이션 코드가 .class파일로 컴파일 되었을 때 어떻게 나오는지 보고 싶어서 터미널로 컴파일을 해보았다. 컴파일 결과는 다음과 같다.public interface org.example.SampleAnnotation extends java.lang.annotation.Annotation { }컴파일 시점에 extends 한적 없는 java.lang.annotation.Annotation 이 extends 되어 있다. 이제 좀 더 자세한 어노테이션의 내용과 활용법을 알아가보자. 어노테이션은 JDK에서 기본적으로 제공하는 것과 다른 프로그램에서 제공하는 것들이 있는데, 어느 것이든 그저 약속된 형식의 정보를 제공하기만 하면 될 뿐이다.JDK에서 제공하는 표준 어노테이션은 주로 컴파일러를 위한 것으로 컴파일러에게 유용한 정보를 제공한다. 📚 JDK에서 제공하는 어노테이션은 'java.lang.annotation' 패키지에 포함되어 있다.어노테이션은 코드에 넣는 주석이다. 완전히 주석같지는 않지만 그 비슷한 부류이다.주석이기 때문에, 실행되는 코드라고 생각하면 안된다. 어노테이션은 기능을 가지고 있는 것이라 착각을 할 수 있지만 어노테이션은 마크, 표시 해놓는 주석이다. 어노테이션은 다이나믹하게 실행되는 코드는 들어가지 않는다.즉, 런타임에 알아내야 하는 것들은 못 들어간다.위의 내용을 좀 더 풀어쓰면 컴파일러 수준에서 해석이 되야 하거나, 완전히 정적이어야 한다는 말이다.이유를 아래 코드로 보여주겠다. package me.sungbin.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloController { private static final String hello = "/hello"; @GetMapping(hello) public String hello() { return "hello"; } }위와 같이 hello 변수는 정적 변수이므로 @GetMapping 어노테이션에 사용할 수 있다.하지만. hello 변수가 동적인 변수라면 컴파일 에러가 발생한다.아래의 코드를 보자. 컴파일 에러가 발생하는 것을 볼 수 있을 것이다. 간략한 어노테이션 정의 방법새로운 어노테이션을 정의하는 방법은 아래와 같다.'@'기호를 붙이는 것을 제외하면 인터페이스 정의와 동일하다. package me.sungbin; public @interface SampleAnnotation { 타입요소이름(); } 📚 타입요소등, 어노테이션 정의에 대한 자세한 정의방법과 내용들은 구체적인 내용들을 확인 후, 살펴보자.자바의 표준 어노테이션자바에서 기본적으로 제공하는 어노테이션들은 몇 개 없다.그나마 이들의 일부는 '메타 어노테이션(meta annotation)' 으로 어노테이션을 정의하는데 사용되는 어노테이션의 어노테이션이다. 표준 어노테이션과 메타 어노테이션@Override: 컴파일러에게 오바리이딩하는 메서드라는 것을 알린다.@Deprecated: 앞으로 사용하지 않을 것을 권장하는 대상에 붙인다.@SuppressWarnings: 컴파일러의 특정 경고메시지가 나타나지 않게 해준다.@SafeVarags: 제네릭스 타입의 가변인자에 사용한다. (JDK 1.7)@FunctionalInterface: 함수형 인터페이스라는 것을 알린다. (JDK 1.8)@Native: native 메서드에서 참조되는 상수 앞에 붙인다. (JDK 1.8)@Target*: 어노테이션이 적용가능한 대상을 지정하는데 사용한다.@Documented*: 어노테이션 정보가 javadoc으로 작성된 문서에 포함되게 한다.@Inherited*: 어노테이션이 자손 클래스에 상속되도록 한다.@Retention*: 어노테이션이 유지되는 범위를 지정하는데 사용한다.@Repeatable*: 어노테이션을 반복해서 사용할 수 있게 한다. (JDK 1.8)*이 붙은 것이 메타 어노네이션이다.📚 메타 어노테이션: 어노테이션을 정의하는데 사용하는 어노테이션의 어노테이션 @Override현재 메서드가 슈퍼 클래스의 메서드를 오버라이드한 것임을 컴파일러에게 명시해준다.메서드가 슈퍼클래스에 없다면 에러를 발생시기 때문에 오타와 같은 실수도 잡을 수 있다. @Deprecated마커 어노테이션으로 다음 버전에 지원되지 않을 수도 있기 때문에 앞으로 사용하지 말라고 경고를 알린다.@Deprecated를 붙인 메서드는 인텔리제이에서 아래의 사진과 같이 표시해준다. @SuppressWarning경고를 제거하는 어노테이션으로 개발자가 의도를 가지고 설계를 했는데 컴파일은 이를 알지 못하고 컴파일 경고를 띄울 수 있기 때문에 이를 제거하는 목적이다. @SafeVarargsJava 7이상에서 사용가능하고 제네릭같은 가변인자 매개변수 사용시 경고를 무시한다제네릭사용할 클래스,메서드 내부에서의 데이터타입을 외부에서 지정하는 기법 @FunctionalInterfaceJava 8이상에서 사용가능하고 컴파일러에게 함수형 인터페이스라는 것을 알리는 어노테이션이다.메타 어노테이션'어노테이션을 위한 어노테이션' 쯕, 어노테이션에 붙이는 어노테이션으로 어노테이션을 정의할 때 어노테이션의 적용대상(target) 이나 유지기간(retention)등을 지정하는데 사용된다. 📚 메타 어노테이션은 java.lang.annotation 패키지에 포함되어 있다. @Target어노테이션이 적용가능한 대상을 지정하는데 사용한다.아래 예제는 '@SuppressWarnings' 를 정의한 것인데, 이 어노테이션에 적용할 수 있는 대상을 '@Target' 으로 지정한다.여러 개의 값을 지정할 때는 배열처럼 괄호{} 를 이용하여 지정할 수 있다.package me.sungbin; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) @Retention(RetentionPolicy.SOURCE) public @interface SuppressWarnings { String[] value(); } @Target으로 지정할 수 있는 어노테이션 적용대상의 종류ANNOTATION_TYPE: 어노테이션CONSTRUCTOR: 생성자FIELD: 필드(멤버 변수, ENUM 상수)LOCAL_VARIABLE: 지역변수METHOD: 메서드PACKAGE: 패키지PARAMETER: 매개변수TYPE: 타입(클래스, 인터페이스, ENUM)TYPE_PARAMETER: 타입 매개변수(JDK1.8)TYPE_USE: 타입이 사용되는 모든 곳(JDK1.8)📚 java.lang.annotation.ElementType 이라는 열거형에 정의되어 있다. static import문을 사용하면 ElementType.TYPE 이 아니라 TYPE 과 같이 간략히 사용할 수 있다. TYPE은 타입을 선언할 때 어노테이션을 붙일 수 있다는 뜻TYPE_USE는 해당 타입의 변수를 선언할 때 붙일 수 있다는 뜻이다.FIELD 는 기본형에 사용할 수 있고, TYPE_USE는 참조형에 사용된다는 점을 주의한다.타입 선언부제네릭 타입, 변수 타입, 매개변수 타입, 예외 타입...타입에 사용할 수 있으려면TYPE_PARAMETER : 타입 변수에만 사용할 수 있다.TYPE_USE : 타입 변수를 포함해서 모든 타입 선언부에 사용할 수 있다.package me.sungbin; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; @Target({FIELD, TYPE, TYPE_USE}) public @interface MyAnnotation { } package me.sungbin; import me.sungbin.controller.HelloController; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication @MyAnnotation public class AnnotationTestApplication { @MyAnnotation int i; @MyAnnotation HelloController helloController; public static void main(String[] args) { SpringApplication.run(AnnotationTestApplication.class, args); } } @Retention어노테이션 유지되는 기간을 지정하는데 사용한다. 어노테이션 유지정책의 종류SOURCE: 소스 파일에만 존재. 클래스파일에는 존재하지 않는다.CLASS: 클래스 파일에 존재. 실행 시에 사용 불가능하다. (기본값)RUNTIME: 클래스 파일에 존재하며 실행시에 사용 가능하다.SOURCE -> CLASS -> RUNTIMESOURCE는 소스코드만 유지하겠다.컴파일 시에만 사용하겠다는 것!컴파일하고 나면 어노테이션은 없어진다. -> 바이트코드에도 남아있지 않다.CLASS애노테이션에 대한 정보를 클래스 파일까지, 즉 바이트 코드에도 남겨 두겠다.클래스 정보를 읽어들이는 방법(바이트 코드를 읽어들이는)을 바탕으로 애노테이션 정보를 읽어와서 처리할 수 있다.예) BYTE BUDDY, ASM 활용바이트 코드엔 남아 있지만, 이 클래스파일을 JVM이 실행할 때 클래스에 대한 정보를 클래스로더가 읽어서 메모리에 적재하게되고, 이후 사용 시점에 메모리에서 읽어올 때 애노테이션 정보를 제외하고 읽어옴RUNTIME위 CLASS와 동일하지만, 메모리에 적재된 클래스 정보를 읽어올 때 애노테이션 정보를 그대로 포함하는 것이다.바이트코드에서 읽어오는게 빠를까?RetentionPolicy를 CLASS로 한 이후, 바이트코드를 읽어 처리하는 라이브러리를 활용?리플렉션으로 읽어오는게 빠를까?RetentionPolicy를 CLASS로 한 이후, 바이트코드를 읽어 처리하는 라이브러리를 활용? -> 리플렉션 자체가 부하가 존재한다.-> 바이트 코드의 양에 영향을 끼친다.-> 리플렉션은 메모리에 이미 올라와 있는 정보를 읽는다. 클래스 로더가 읽고 메모리에 적재시킨 후 읽어온다. 📚 커스텀하게 만든 애노테이션이 정말로 RUNTIME 까지 필요한 정보인가? RUNTIME 까지 사용할 필요가 없다면, CLASS 레벨로 내려가거나 SOURCE 레벨로 내려갈 수도 있을 것이다. 그냥, 의례적으로 RUNTIME으로 작성하는 경우가 있었다면? 그 역할을 다시 살펴보고 명확한 Retention Policy 를 정의하자. 표준 어노테이션 중 '@Override' 나 '@SuppressWarnings' 처럼 컴파일러가 사용하는 어노테이션은 유지 정책이 'SOURCE' 이다. -> 컴파일러를 직접 작성할 것이 아니면, SOURCE 이상의 유지정책을 가질 필요가 없다. 유지 정책을 RUNTIME 으로 한다면,실행 시에 리플렉션(Reflection) 을 통해 클래스 파일에 저장된 어노테이션의 정보를 읽어서 처리 할 수 있다.Retention 정책은 RUNTIME 으로 정의하고Target은 TYPE과 FIELD로 정의한다.package me.sungbin; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; @Target({TYPE, FIELD}) @Retention(RetentionPolicy.RUNTIME) public @interface MyAnnotation { } Target이 TYPE과 FIELD 임으로 클래스에도 애노테이션을 선언할 수 있고클래스 내부의 필드에도 애노테이션을 선언할 수 있다.package me.sungbin; @MyAnnotation public class TestClass { @MyAnnotation private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } TestClass 클래스에 선언된 Annotation을 리플렉션을 이용해 확인할 수 있다.package me.sungbin; import java.lang.reflect.Field; import java.util.Arrays; public class App { public static void main(String[] args) { Arrays.stream(TestClass.class.getAnnotations()).forEach(System.out::println); Field[] declaredFields = TestClass.class.getDeclaredFields(); for (Field declaredField : declaredFields) { Arrays.stream(declaredField.getAnnotations()).forEach(System.out::println); } } }  표준 어노테이션 중 '@FunctionalInterface' 는 '@Override' 처럼 컴파일러가 체크해주는 어노테이션이지만, 실행 시에도 사용되므로 유지 정책이 "RUNTIME"으로 되어 있다. @Documented @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public @interface FunctionalInterface {} 유지 정책을 "CLASS" 으로 한다면컴파일러가 어노테이션의 정보를 클래스 파일에 저장할 수 있게 하지만,클래스 파일이 JVM에 로딩 될 때는 어노테이션의 정보가 무시되어 실행 시에 어노테이션에 대한 정보를 얻을 수 없다.→ CLASS 가 유지정책의 기본값임에도 불구하고 잘 사용되지 않는 이유 지역 변수에 붙은 어노테이션은 컴파일러만 인식할 수 있으므로, 유지 정책이 RUNTIME인 어노테이션을 지역변수에 붙여도 실행 시에는 인식되지 않는다. @Documented어노테이션에 대한 정보가 javadoc으로 작성한 문서에 포함되도록 한다.표준 어노테이션 중 Override와 SuppressWarnings를 제외하고 모두 Documented 메타 어노테이션이 붙어 있다. @Documented애노테이션 정보가 javadoc으로 작성된 문서에 포함된다고 한다. 이것이 무슨말일까? 내 코드가 자바docs에 올라간다는 말일까?정확히 말하면 자바docs에 올라간다는 말이 아니라,직접 javadoc을 만들 수 있다는 뜻이다.이런식으로 만들 수 있는데, Local 지역입력 ko_KRother command line arguments : 한글깨짐 방지-encoding UTF-8 -charset UTF-8 -docencoding UTF-8적절하게 내용을 채운뒤 output directory에 경로를 입력해주면 끝이다.그러면 @Documented를 붙인거와 안 붙인것을 비교해보자. 코드public class Korea implements Great{ @Override @Make public String country() { return "한국"; } } 없는거 있는거JavaDoc애노테이션을 알기 전에 JavaDoc에 대해 알아보자.JavaDoc은 Java코드에서 API문서를 HTML 형식으로 생성해주는 도구이다.HTML 형식이기 때문에 다른 API를 하이퍼 링크를 통해 접근이 가능하다. JavaDoc TagsJavaDoc은 여러 Tag를 작성하여 문서를 완성한다.Java 코드에서 애노테이션으로 추가한다.IDE에서 /** 입력 후 엔터를 치면 자동으로 형식이 생성된다.Javadoc Tags의 종류들@author@deprecated@exception@param@return@see@serial@serialData@serialField@since@throws@since@throws@version@Inherited어노테이션이 자손 클래스에 상속되도록 한다.'@Inherited' 가 붙은 어노테이션을 조상 클래스에 붙이면, 자손 클래스도 이 어노테이션이 붙은 것과 같이 인식된다.MyAnnotation은 Inherited 애노테이션을 통해 자손 클래스에도 인식되도록 정의한다.package me.sungbin; import java.lang.annotation.Inherited; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; @Retention(RetentionPolicy.RUNTIME) @Target({TYPE, FIELD}) @Inherited public @interface MyAnnotation { } 부모클래스인 Sungbin클래스에 MyAnnotation을 정의package me.sungbin; @MyAnnotation("hi") public class Sungbin { @MyAnnotation("yang sung bin") private String name; }  Sungbin 클래스의 자식 클래스인 Child 클래스에는 별도의 어노테이션 정의가 없다.package me.sungbin; public class Child extends Sungbin { } 리플렉션을 이용해 Child 클래스의 어노테이션을 확인해보자.→ ChildSson 클래스에는 정의한 애노테이션이 없지만,→ 부모 클래스인 Sson 클래스에 정의한 애노테이션이 확인됨을 볼 수 있다.→ Inherited 애노테이션을 통해 자식 클래스까지 전파될 수 있음을 확인할 수 있다. Inherited 애노테이션을 바탕으로 리플렉션을 활용해 자식클래스에서부모클래스에 정의되어 있는 Inherited 애노테이션을 확인할 수 있다. 📚 리플랙션의 getDeclaredFields(); 를 하면 클래스에 정의된(선언된) 것들을 가져와서 조작할 수 있다. public이던, private 이던,, Getter와 Setter에 대해 논의를 하며 큰 비용을 소모하는 것이 크게 가치가 없다.. 객체지향을 얘기하며 Getter, Setter의 정의 관련한 내용으로 얘기할 수 있겠지만, Getter와 Setter가 없더라도 리플랙션을 이용하면 충분히 가져오고 수정할 수 있기 때문이다. 중요한건 Getter, Setter 가 아닌것 같다. @Repeatable보통은 하나의 대상에 한 종류의 어노테이션을 붙이게 되는데,'@Repeatable'이 붙은 어노테이션은 여러 번 붙일 수 있다. 일반적인 어노테이션과 달리 같은 이름의 어노테이션이 어러 개가 하나의 대상에 적용될 수 있기 때문에, 이 어노테이션들을 하나로 묶어서 다룰 수 있는 어노테이션도 추가로 정의해야 한다. @Native네티이브 메서드(native method)에 의해 참조되는 '상수 필드(constant field)'에 붙이는 어노테이션이다.여기서, 네이티브 메서드는 JVM이 설치된 OS의 메서드를 말한다.네이티브 메서드는 보통 C언어로 작성되어 있는데, 자바에서는 메서드의 선언부만 정의하고 구현하지 않는다.그래서 추상 메서드처럼 선언부만 있고 구현부가 없다. 어노테이션 타입 정의어노테이션의 요소어노테이션 내에 선언된 메서드를 어노테이션의 요소라고 한다. 📚 어노테이션에도 인터페이스처럼 상수를 정의할 수 있지만, 디폴트 메서드는 정의할 수 있다. 어노테이션의 요소는 반환 값이 있고 매개변수는 없는 추상 메서드의 형태를 가진다.다만, 어노테이션을 적용할 때 이 요소들의 값을 빠짐없이 지정해주어야 한다.각 요소들은 기본값을 가질 수 있으며, 기본값이 있는 요소들은 어노테이션을 적용할 때 값을 지정하지 않으면 기본값이 사용된다.어노테이션의 요소가 오직 하나 뿐이고 이름이 value 인 경우, 어노테이션을 적용할 때 요소의 이름을 생략하고 값만 적어도 된다.요소 타입이 배열인 경우, 괄호{} 를 사용해 여러 개의 값을 지정할 수 있다.하나인 경우는 괄호{} 를 생략할 수 있다.java.lang.annotation.Annotation모든 어노테이션의 조상은 Annotation이다.그러나 어노테이션은 상속이 허용되지 않으므로 아래와 같이 명시적으로 Annotation을 조상으로 지정할 수 없다. @interface TestInfo extends Annotation{ // 에러. 허용되지 않는 표현이다. int count(); String testedBy(); ... } Annotation 을 살펴보면Annotation은 어노테이션이 아니라 일반적인 인터페이스로 정의되어 있다. 모든 어노테이션의 조상인 Annotation 인터페이스가 위와 같이 정의되어 있기 때문에모든 어노테이션 객체에 대해 equals(), hashCode(), toString() 과 같은 메서드를 호출하는 것이 가능하다.리플랙션(Reflection)을 이용해 특정 클래스에 선언된 애노테이션들을 조회하여 equals, hashCode, toString 메서드를 호출해본다.어노테이션 요소의 규칙어노테이션의 요소를 선언할 때 반드시 지켜야 하는 규칙요소 타입은 기본형, String, Enum, 어노테이션, Class 만 허용() 안에 매개변수를 선언할 수 없다.예외를 선언할 수 없다.요소를 타입 매개변수로 정의할 수 없다.마커 어노테이션 Marker Annotation값을 지정할 필요가 없는 경우,어노테이션의 요소를 하나도 정의하지 않을 수 있다.Serializable 이나 Cloneable 인터페이스처럼, 요소가 하나도 정의되지 않은 어노테이션을 마커 어노테이션이라 한다. 🙋🏻 이런 마커 어노테이션은 왜 사용될까? 글을 찾아보니 아래의 내용이 있었다.마커 어노테이션을 통해 코드 작성 시점, 컴파일 시점, 러타임 시점에 부가적인 작업을 추가할 수 있을 것이다.코드 작성 시점에 어노테이션 정보를 통해 부가적인 정보를 check 하여 컴파일에러를 발생시킬 수 있을 것이며컴파일하는 과정에서 어노테이션 정보를 바탕으로 부가적인 정보를 포함하여 컴파일된 결과를 내보낼 수도 있을 것이다.또한, 런타임 시점에 리플랙션을 이용하여 애노테이션 정보를 바탕으로 부가적인 작업을 할 수 있을 것이다.Java8 어노테이션 변화 애노테이션 관련 큰 변화 두가지자바 8 부터 애노테이션을 타입 선언부에도 사용할 수 있게 되었다.자바 8 부터 애노테이션을 중복해서 사용할 수 있게 되었다.타입 선언부제네릭 타입변수 타입매개변수 타입예외 타입...타입에 사용할 수 있으려면TYPE_PARAMETER : 타입 변수에만 사용할 수 있다.TYPE_USE : 타입 변수를 포함해서 모든 타입 선언부에 사용할 수 있다.중복 사용할 수 있는 애노테이션을 만들기@Repeatable애노테이션들을 감싸고 있을 컨테이너 애노테이션을 선언해야 한다.중복 사용할 애노테이션 만들기컨테이너 애노테이션은 중복 애노테이션과 @Retention 및 @Target 이 같거나 더 넓어야 한다.컨테이너이기 떄문에 , 이것은 접근 지시자의 범위와 유사한 개념이라고 볼 수 있다.@Retention : 애노테이션을 언제까지 유지할 것이냐?@Target : 애노테이션을 어디에 사용할 것이냐?애노테이션 프로세서애노테이션 프로세서는 소스코드 레벨에서 소스코드에 붙어있는애노테이션을 읽어서 컴파일러가 컴파일 하는 중에 새로은 소스코드를 생성하거나 기존 소스코드를 바꿀 수 있다.또는, 클래스(바이트코드) 도 생성할 수 있고 별개의 리소스파일을 생성할 수 있는 강력한 기능이다. 애노테이션 프로세서 사용 예롬복 (기존코드를 변경한다)AutoService (리소스 파일을 생성해준다.)java.util.ServiceLoader 용 파일 생성 유틸리티@Override애노테이션 프로세서 장점바이트코드에 대한 조작은 런타임에 발생되는 조작임으로 런타임에 대한 비용이 발생한다.but. 애노테이션 프로세서는 애플리케이션을 구동하는 런타임 시점이 아니라,컴파일 시점에 조작하여 사용함으로 런타임에 대한 비용이 제로가 된다.단점은 기존의 코드를 고치는 방법은 현재로써는 public 한 API 가 없다.롬복 같은 경우.. 기존 코드를 변경하는 방법이지만 public 한 api를 이용한 것이 아님으로 해킹이라고 할 수 도 있다.롬복(Lombok)의 동작원리Lombok@Getter @Setter, @Builder 등의 애노테이션과애노테이션 프로세서를 제공하여 표준적으로 작성해야 할 코드를 개발자 대신 생성해주는 라이브러리이다.사용하기의존성 추가IntelliJ Lombok 플로그인 설치Intellij Annotation Processing 옵션 활성화동작원리컴파일 시점에 "애노테이션 프로세서"를 사용하여 (자바가 제공하는 애노테이션 프로세서)소스코드의 AST(Abstract Syntax Tree) 를 조작한다.AST에 대한 참고 사이트 (아래 참조 참고)javax.annotation.processing || Interfaec Processor⇒ 소스코드의 AST를 원래는 참조만 할 수 있다. // 수정하지 못한다. 그리고 하면 안된다!⇒ 그러나 수정이 됬음을 알 수 있다.(컴파일 이후 바이트코드 확인)⇒ 참조만 해야 하는 것을 내부 클래스를 사용하여 기존 코드를 조작하는 것임으로 "해킹" 이라고 얘기하기도 한다. 논란 거리공개된 API가 아닌 컴파일러 내부 클래스를 사용하여 기존 소스 코드를 조작한다.특히 이클립스의 경우에는 Java Agent를 사용하여 컴파일러 클래스까지 조작하여 사용한다.해당 클래스들 역시 공개된 API가 아니다보니 버전 호환성에 문제가 생길 수도 있고 언제라도 그런 문제가 발생해도 이상하지 않다.그럼에도 불구하고 엄청난 편리함 때문에 널리 쓰이고 있으며, 대안이 몇가지 있지만 롬복의 모든 기능과 편의성을 대체하지 못하는 상황이다.AutoValueImmutables기존 Getter, Setter, equals, hasCode 등의 메소드를 생성하는 순간?해당 클래스는 이미 방대해진 모습을 볼 수 있다.해당 클래스를 위한 메소드들이 선언이 되어 있더라도 위 메소드들 사이에 파묻혀 있다면?개발자 입장에서 놓칠 수도 있다. (그래서 boilerplat 코드라는 개념도 나온다.)⇒ 롬복을 이용하여 쉽게, 그리고 가독성 높게 클래스를 구현할 수 있다. package me.sungbin; import lombok.Getter; import lombok.Setter; @Getter @Setter public class Member { private String name; private int age; }  위의 롬복이 적용된 코드를 컴파일하면 아래와 같이 나온다. package me.sungbin; public class Member { private String name; private int age; public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } } 결론위에서 미션에 대해 다 애기한 듯 하다. 결론을 내보겠다.어노테이션을 사용하는 이유는 단순하다.코드의 가독성과 유지보수성 향상: 어노테이션을 사용하면 개발자가 코드의 의도를 더 명확하게 표현할 수 있습니다. 예를 들어, @Override 어노테이션은 메소드가 상위 클래스의 메소드를 오버라이드한다는 것을 명시합니다.컴파일 시간 검사: 어노테이션을 통해 코드에 대한 추가적인 검사를 수행할 수 있어, 잠재적인 오류를 컴파일 시간에 발견하고 수정할 수 있습니다.런타임 처리: 특정 어노테이션이 적용된 요소를 런타임에 검사하고 처리할 수 있어, 리플렉션을 사용한 동적 처리가 가능해집니다. 이는 프레임워크와 라이브러리에서 많이 활용됩니다.이런 이유로 사용이 되며 이로인하여 코드문서화, 컴파일러에 특정처리를 지시, 코드분석 도구 지원, 런타임처리등이 가능해지게 된다. 우리가 스프링의 의존성 주입을 할 때 @Autowired도 이런 기능처리를 해준다. 컴파일러에서의 처리:코드 검증: 컴파일러는 어노테이션을 사용하여 코드에 대한 추가적인 검증을 수행합니다. 예를 들어, @Override 어노테이션은 메서드가 실제로 상위 클래스나 인터페이스의 메서드를 오버라이드하는지 확인하는 데 사용됩니다. 만약 오버라이드하는 메서드가 없다면, 컴파일러는 에러를 발생시킵니다.정책 적용: 일부 어노테이션은 컴파일러에 특정 정책을 적용하도록 지시합니다. 예를 들어, @Deprecated 어노테이션이 적용된 요소를 사용하는 코드는 컴파일러 경고를 발생시키며, 이는 개발자에게 해당 요소가 더 이상 사용되지 않아야 함을 알립니다.소스 코드 변환: 어노테이션 프로세서를 사용하여 컴파일 시점에 소스 코드를 자동으로 생성하거나 수정할 수 있습니다. 이는 코드 생성 라이브러리나 프레임워크에서 흔히 사용되는 기법입니다.런타임에서의 처리:리플렉션을 통한 접근: 런타임에는 리플렉션 API를 사용하여 어노테이션 정보에 접근할 수 있습니다. 이를 통해 개발자는 실행 중인 프로그램에서 클래스, 메서드, 필드 등에 적용된 어노테이션을 검사하고, 해당 어노테이션에 지정된 정보를 바탕으로 동적인 처리를 수행할 수 있습니다.동적 처리: 런타임에 어노테이션을 기반으로 동적 처리를 하는 예로, Java EE와 Spring 프레임워크에서 의존성 주입을 구현하는 방법을 들 수 있습니다. 이러한 프레임워크는 특정 어노테이션(@EJB, @Autowired)이 붙은 필드나 메서드를 찾아, 런타임에 자동으로 의존성을 주입합니다.구성 관리: 어플리케이션의 구성 정보를 어노테이션을 통해 관리할 수 있습니다. 예를 들어, 웹 어플리케이션에서 서블릿이나 REST 엔드포인트를 정의할 때 사용되는 어노테이션들은 런타임에 웹 서버가 해당 구성 정보를 읽어들여 서비스를 구동하는 데 사용됩니다.이러한 방식으로 어노테이션은 컴파일 시점과 런타임에 다양한 목적으로 활용됩니다. 컴파일 시점에는 코드의 정확성을 보장하고, 런타임에는 코드의 동적인 행위를 제어하는 데 중요한 역할을 합니다.커스텀 어노테이션이것 또한 위에서 예제로 많이 보여드렸으므로 어노테이션 예제를 보여줌으로 이 글을 마치려고 한다. 정말 단순히 어노테이션부터 시작해서 리플렉션까지 갔는데 정말 험난한 여정이였지만 보람찬 공부가 되었다. package me.sungbin; import java.lang.annotation.Inherited; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; @Retention(RetentionPolicy.RUNTIME) @Target({TYPE, FIELD}) @Inherited public @interface MyAnnotation { String value(); }  📚 참조https://b-programmer.tistory.com/264http://javaparser.org/inspecting-an-ast/

백엔드인프런워킹업스터디클럽백엔드미션어노테이션

채널톡 아이콘