<p>뭔가 매 달 회고를 쓰고 싶은 마음이었지만, 그게 처음부터 바로 할 수 있을만큼 쉬운 일은 아니었음을 깨달았다. 아무튼 이것도 배움이라고 생각해버리기… (머쓱)</p>
<h2>돈 버는 프로덕트</h2>
<p>컨텐츠 크루에서 커리어 크루로 옮기고 가장 달라진 것 중에 하나는 프로덕트가 회사의 매출에 큰 비중을 차지하고 있었다는 것. 그리고 모든 사용자가 유료 사용자라는 것. 때문에 모든 의사결정이 매출에 영향을 주고받을 수 밖에 없다는 것이다. 컨텐츠에서 커리어로 옮긴 이유는 하나의 제품을 애정을 갖고 만들고 싶었던 마음이 컸기 때문인데 커리어 제품은… 뭔가 내가 만드는 느낌은 전혀 아니었다. 뭔가… 다양한 이해관계가 한 곳에 모여져서 만들어지는 하나의 집합체(?) 같은 느낌으로 다가왔고 그래서 처음에는 적응하기 어려웠다. 그동안 매출과 관련없는 제품을 만드는 것이 얼마나 온실안의 화초같은 느낌으로 일하고 있었는지도 느꼈다. 이게 당연히 좋고 나쁘고의 문제는 아니고 일하는 지금까지와는 다른 방식으로 일함에 있어 적응이 필요했다는 이야기이다.</p>
<p>같은 회사 내에서 제품의 성격이 이렇게 다를 수 있다는 것도 재미있고 막상 이제 이런 특징을 받아들이고 나니 이런 비즈니스적인 의존성이 강한 제품을 만들어나감에 있어 다른 팀과의 커뮤니케이션이 얼마나 중요한지 등 좀더 사업적인 영역을 생각 해 볼 수 있어서 나에게는 너무 좋은 경험이 되고있다. 아무튼 뭐든 피할 수 없다면 즐기는 거다…! 이런 챌린지가 오히려 좋다는 것도 느끼는 중. 개발자가 성장하는 방법중에 하나라고 생각하고 이해를 기반으로 좋은 제품을 만들고 문제를 찾고 해결하는 사이클을 온전히 경험할 수 있음에 감사한다.</p>
<p>아쉬운 것이라면 내가 아직 맡은 제품의 도메인에 대한 이해가 부족하기 때문에 의견을 말할 때 조금씩 머뭇거림이 생기기는 한다. 구직자와 구인자, 그리고 그 와중에도 헤드헌터와 리크루터 적극적 구직자와 소극적 구직자에 대한 persona를 형성해냄에 있어 경험이 부족하기 때문인 것도 클 것 같다. 요런 부분들은 내가 이직을 많이 해보지 않으면, 혹은 채용에 직간접적으로 개입하지 않으면 경험해보기 어려운 부분이기 때문에 어떻게 채워야 할 지 고민해봐야 할 것같다. (커뮤니티는 내가 커뮤니티 이용자 입장에서 생각해 보기가 쉬웠기 때문에 좀 더 적극적이고 자신감 있게 의견을 낼 수 있어서 좋았다) 일단은 기획단에서 사용자 인터뷰를 진행하고 있기 때문에 해당 인터뷰들을 참고하며 노력중.</p>
<h2>메시지 기능</h2>
<p>10월부터의 가장 큰 이슈는 메시지 기능 개선이었는데, 우리가 채팅 서버를 만들기에는 리소스도 부족하고 시행착오가 쉽게 용납되지 않는 프로덕트이다 보니까 안전하게 외부 채팅 SDK를 사용해서 구현하기로 했다. 다행히 UIKit도 함께 제공했기 때문에 조금 빠르게 만들 수 있을거라고 기대했는데, 전혀 아니었다. 물론 UIKit 덕분에 적은 시행착오로 태스크를 진행할 수 있었지만 UIKit 자체가 유연하지 못하게 설계된 부분이 많았고 (우리가 기능을 거의 다 커스텀해서 사용했기 때문에 더 힘들었다.) 솔루션의 정책상 구현하기 어려운 부분들을 온갖 수단을 동원해서(?) 돌아갈 수 있도록 하는 일들이 많았다. 정말정말 다양한 문제들에 부딪혔었는데 다행히 모두 방법을 찾았다. 정말 '문제 해결 능력’을 최대한 발휘했던 태스크… 그리고 다양한 묘수들을 내가 찾아내기도 했어서 더 뿌듯했다.</p>
<p>곧 해당 태스크에 대한 회고를 진행할 예정인데 할 이야기가 많을 것 같다. 먼저 개발적으로 POC를 너무 얕게 하고 시작했다. 워낙 유명한 채팅 SDK이다 보니까 당연히 다 될 것이라고 생각했던 기능들이 제한되는 경우도 많았고, 문서에 숨겨놓은 듯이 존재하는 제약조건들을 개발 중간에 발견하면서 개발일정이나 방향에 계속해서 변수가 생겼었다. 또 구현에 앞서 SDK 공급업체와도 충분한 논의를 거쳐서 좀 더 SDK에 이해가 깊은 사람들과 이야기 해 볼수 있었는데 개발일정이 급하다는 이유로 해당 과정을 생략했던 부분 (이 부분도 개발 막바지 쯤에 깨달았다)도 아쉬움이 크다. 마지막으로는 예외처리에 대해서 크게 신경쓰지 못한 부분도 배포 이후 CS이슈 해결을 힘들게 만들었다. 유료로 제공하는 프로덕트인 부분에서 기능 장애 CS는 치명적이고 빠르게 해결해야 한다. 하지만 SDK쪽 디버깅에 대한 대비를 제대로 하지 못해서 (모니터링 솔루션이 있었지만 내가 잘 파악하지 못했기 때문에 활용을 잘 못했던 것도 너무 아쉽다) 장애 대응을 빠르게 하지 못했다. 그리고 이게 경험의 차이라는 것도 다시금 느꼈다. 만약 내가 다음에 이런 CS이슈가 예상되는 태스크를 한다면 예외처리와 디버깅에 있어서 좀 더 신경을 쓰지 않을까…</p>
<p>그럼에도 스스로 잘 했다고 생각한 건, view영역을 최대한 UIKit의 의존성을 제거하기 위해 새롭게 개발했던 부분이 나중에 개발 효율성에 긍정적으로 작용했다는 점 정도… 사실 아쉬움이 너무 많은 태스크이기도 했지만 그만큼 배울 게 많았던 태스크라고 생각하려고 한다.</p>
<h2>yarn berry</h2>
<p>팀원중에 한 분이 yarn berry를 다양한 레포에 적용하기 시작했다. 나는 솔직히 yarn berry에 대해서 긍정적으로 생각하지는 않는다. 아직 생태계가 정착한 느낌이 들지는 않고, 기존에 node_modules를 통한 의존성 관리 방식에 분명 문제가 있기는 하지만 그게 생산성에 크게 치명적인가를 생각 해 보면 그렇지도 않은 것 같고 오히려 yarn berry를 사용하면서 생기는 문제들에 대한 트러블슈팅에 리소스를 할애해야 한다면 생산성에 악영향이 있을 것 같기 때문이다. 특히 <code>'토스에서 쓰니까 좋은 것 아니야?'</code> 라는 느낌의 접근은 정말 경계해야 한다고 생각했다. 아무튼 그런 생각을 갖고 있는 상황에서 해당 팀원분께서 yarn berry 관련해서 발표하는 자리를 만들어주셔서 이야기를 들어봤는데 현재 패키지 매니저의 문제점 부터 이런 것들을 yarn berry가 어떻게 해결했는지 등을 상세히 설명해 주셨고 몇 프로젝트에서는 확실히 유의미하게 빌드속도가 빨라진 것을 볼 수는 있었다. 그래서 나도 생각이 조금 변한 부분이 있었는데 그럼에도 아직까지는 위험요소들이 있다고 생각이 들었고 커리어 제품군에서는 조금 더 시간을 들여 지켜본 이후에 적용해 보기로 했다.</p>
<p>개발자라면 새로운 기술에 계속해서 열린마음(?)으로 받아들이고 빠르게 적용해봐야 한다고는 하지만, 나는 그게 프로덕션 레벨이라면 너무 보수적으로 접근하게 되는 것 같다. 이제 2년차 완전 주니어인데 벌써 이렇게 소극적으로 신기술을 대하는 게 안좋은 것 같으면서도 제품을 만드는 입장에서는 이런 새로운 기술의 도입이 염려스러운 건 또 어쩔 수 없는 것 같다.</p>
<h2>1년</h2>
<p>11월 22일은 입사 1주년이었다. 처음 입사할 때는 사실 아주 큰 기대는 하지 않았었는데 다니면서 느끼는 건 우리 회사가 외부에 알려진 것에 비해 굉장히 좋은 조직문화를 갖고 있고 정말 전망이 좋은 제품을 정말 좋은 사람들과 만들고 있다는 것들을 느낀다. 최근에는 동료분 중에 한 분이 밖에서 회사 얘기를 하면서 회사나 대표 욕을 하지 않는 회사는 여기가 처음이라는 말을 듣고는 더 그렇게 느끼기 시작한 것 같다. 물론 사람마다 다르겠지만 일단 나에게는 굉장히 잘 맞는 회사라는 것은 확실하다. 원래는 개발자가 되면 1~2년 정도씩 다니면서 회사를 옮겨서 다양한 곳에서 일해보려 했었는데, 드라마앤컴퍼니 내에서도 충분히 다양한 경험들을 쌓으면서 개발자로서, 제품을 만드는 사람으로서 두 마리 토끼를 잡으면서 성장할 기회가 많다는 것을 느꼈다. 또 정말 최고의 복지는 좋은 동료들 이라는 것도 실감중… 인간이 5명 이상이 모이면 반드시 한 명은 쓰레기라는 말이 있는데, 그게 맞는 말이라면 아무래도 내가 그 쓰레기를 담당하고 있는 게 분명한 것 같다. 나도 이전보다 회사에서 많이 밝아진 부분이 있어서 (물론 내가 스스로 노력한 부분도 많았지만) 인간적인 성장도 함께 할 수 있는 듯 하다.</p>
<p>회사 사람들과는 취미활동도 많이 공유하고 퇴근하고는 클라이밍, 주말에는 등산이나 배드민턴도 자주 치러 다녀서 주변에서 <code>'회사 사람들이랑 정말 잘 지내는 것 같다'</code>는 이야기를 많이 듣는다. 아무튼 나는 지금 회사 대만족하면서 다니는 중. 혹시 나랑 같이 클라이밍 가고 싶으면 <a href="https://hello.remember.co.kr/">여기</a>서 지원하길 ^^</p>
<hr>
<p>아무튼 이렇게 11월까지의 밀린 회고를 해봤다. 곧 연말이고 해서 또 2022년의 회고를 작성할 <strong>예정</strong>이다. 또 그전에 Drag and Drop으로 파일 첨부하기 기능을 만들면서 겪은 트러블 슈팅들을 포스팅 해볼 생각이다.</p>


22년 9월 ~ 11월 회고

<blockquote>
<p><strong>* 2023. 2. 12 이 포스팅은 잘못된 정보를 다루고 있습니다. 올바른 내용을 별도로 첨부해두겠습니다.</strong></p>
</blockquote>
<p>최근 iOS 웹뷰에서 파일 다운로드를 동작시키기 위한 태스크를 진행하면서 막혔던 부분이 있었다. 웹뷰에서는 파일 다운로드가 열리지 않기 때문에 사파리 창을 띄워서 다운로드를 발생시켜야 했었는데 아무리 다운로드 버튼을 눌러도 새 창이 뜨지 않는 문제가 있었다. 고민하다가 사파리 브라우저에서 해당 페이지의 버튼을 눌러보니 팝업 차단으로 막히고 있었던 것… 웹뷰에서는 팝업이 차단 될 뿐 차단 안내가 되지 않아서 몰랐던 것이었다.</p>
<h3>왜 차단될까?</h3>
<p>브라우저에서 click 이벤트를 통해서 동작하는 open메서드는 신뢰할 수 있는 이벤트로 판단하고 팝업차단 없이 동작한다고 알고있었다. 그런데 찾아보니, 해당 이벤트 핸들러가 콜스택에서 사라진 이후에 비동기적으로 동작하게 되면 팝업 차단이 일어날 수 있다는 내용을 발견했다.그래서 바로 <code>setTimeout</code> 메서드를 사용해서 콜스택이 비워진 다음 <code>window.open</code>메서드를 호출했지만 문제없이 동작했다. 테스트로 사용한 코드들은 아래와 같았고 모두 문제없이 동작했다. 그렇다면 비동기 호출이 문제가 아닌건데…</p>
<blockquote>
<p>콜스택과 관계없이 AJAX응답 이후 비동기로 실행될 때 차단되는 걸로 확인했다. 글을 작성할 당시에는 브라우저에서 AJAX통신을 인식하고 차단할 거라고 예상을 못했었나보다.</p>
</blockquote>
<pre><code class="language-js"><span class="hljs-comment">// 태스크큐에 전달</span>
<span class="hljs-keyword">const</span> <span class="hljs-title function_">openNaverSite</span> = (<span class="hljs-params"></span>) =&gt; {
  <span class="hljs-built_in">setTimeout</span>(<span class="hljs-function">() =&gt;</span> <span class="hljs-variable language_">window</span>.<span class="hljs-title function_">open</span>(<span class="hljs-string">&#x27;https://www.naver.com&#x27;</span>, <span class="hljs-string">&#x27;_blank&#x27;</span>), <span class="hljs-number">0</span>);
};
<span class="hljs-keyword">const</span> btn = <span class="hljs-variable language_">document</span>.<span class="hljs-title function_">querySelector</span>(<span class="hljs-string">&#x27;#btn&#x27;</span>);
btn.<span class="hljs-title function_">addEventListener</span>(<span class="hljs-string">&#x27;click&#x27;</span>, <span class="hljs-function">() =&gt;</span> {
  <span class="hljs-variable language_">window</span>.<span class="hljs-built_in">setTimeout</span>(<span class="hljs-function">() =&gt;</span> <span class="hljs-title function_">openNaverSite</span>(), <span class="hljs-number">0</span>);
});

<span class="hljs-comment">// 마이크로 태스크큐에 전달</span>
<span class="hljs-keyword">const</span> <span class="hljs-title function_">openNaverSite</span> = (<span class="hljs-params"></span>) =&gt; {
  <span class="hljs-keyword">return</span> <span class="hljs-keyword">new</span> <span class="hljs-title class_">Promise</span>(<span class="hljs-function"><span class="hljs-params">res</span> =&gt;</span> {
    <span class="hljs-variable language_">window</span>.<span class="hljs-title function_">open</span>(<span class="hljs-string">&#x27;https://www.naver.com&#x27;</span>, <span class="hljs-string">&#x27;_blank&#x27;</span>);
    <span class="hljs-title function_">res</span>(<span class="hljs-literal">true</span>);
  });
};
<span class="hljs-keyword">const</span> btn = <span class="hljs-variable language_">document</span>.<span class="hljs-title function_">querySelector</span>(<span class="hljs-string">&#x27;#btn&#x27;</span>);
btn.<span class="hljs-title function_">addEventListener</span>(<span class="hljs-string">&#x27;click&#x27;</span>, <span class="hljs-function">() =&gt;</span> {
  <span class="hljs-title function_">openNaverSite</span>().<span class="hljs-title function_">then</span>(<span class="hljs-function">() =&gt;</span> {
    <span class="hljs-variable language_">window</span>.<span class="hljs-title function_">open</span>(<span class="hljs-string">&#x27;https://www.naver.com&#x27;</span>, <span class="hljs-string">&#x27;_blank&#x27;</span>);
    <span class="hljs-comment">// 네이버 창이 두 개 연속으로 뜬다</span>
  });
});
</code></pre>
<h3>원인</h3>
<p>이런저런 케이스를 테스트하다가 발견한 것은 click이벤트 이후 <code>1000ms</code> 이후에 발생하는 <code>window.open</code>메서드에 대해서 팝업 차단이 된다는 사실이었다. 때문에 비동기 로직이 <code>1000ms</code>이내에 완료된다면 <code>window.open</code>메서드가 정상적으로 동작하는 것이었다. 특이한 것은 크롬에서는 제한시간이 <code>5000ms</code>정도로 더 넉넉했다. 구글링해서 찾은 국내 자료들은 대부분이 비동기로 호출한 함수 내에서 <code>window.open</code>메서드가 호출되면 차단된다고 설명하고 있는데 실제로는 그렇지 않았다. 아마 비동기 로직의 처리 속도가 대부분 1000ms를 넘기 때문인지 아니면 이후에 정책이 바뀐건지는 알 수 없다. 아무튼 결론적은 아래와 같다.</p>
<blockquote>
<p>반은 맞고 반은 틀린데, 사파리는 비동기 로직과는 상관없이 AJAX응답 이후 로직이 실행되는가 여부에 따라 팝업 차단을 하게 된다. (XHR, fetch 모두 동일) 클릭 이벤트 이후 일정 시간이 지나고 window.open이 팝업 차단으로 막히는 것은 맞다.</p>
</blockquote>
<h3>결론</h3>
<ul>
<li>사파리에서는 click이벤트 발생한지 1000ms이후에 <code>window.open</code>메서드가 호출되면 팝업차단이 된다.
<ul>
<li>크롬에서는 시간제한이 5000ms로 훨씬 넉넉하다.</li>
</ul>
</li>
</ul>
<blockquote>
<p>실제 결론은 window.open 이벤트는 클릭액션 이후 사파리는 <code>1000ms</code>, 크롬에선 이후 <code>5000ms</code>가 지나면 팝업차단이 이뤄지고, 사파리의 경우 클릭액션을 통한 호출이라고 하더라도 AJAX요청을 거치면 팝업차단이 된다. 비동기와는 전혀 관련이 없다.</p>
</blockquote>
<h3>나의 해결방법</h3>
<p>대부분의 솔루션은 비동기 로직 이전에 <code>window.open</code>을 통해 새창을 열고 메서드가 반환한 객체를 통해 새 창의 <code>window</code>객체에 접근해서 <code>location.href</code>의 setter를 사용해서 주소를 변경하는 식으로 안내하고 있지만 아쉽게도 웹뷰에서 새 창을 띄웠을 때 정상적으로 연결이 되지 않는 듯 했다. 다운로드 전용 페이지를 만들고 해당 페이지에 다운받을 파일의 정보를 넘긴 뒤 해당 페이지에서 비동기 로직을 처리한 뒤 자동으로 다운받게 만드는 방식으로 해결할 수 있었다.</p>
<blockquote>
<p>제대로 파악을 하지 않고 글을 작성했었던 것이 아쉬운 글이다. SEO에도 적지만 노출되고 있었는데 혹시나 피해가 가지 않았을까도 걱정된다. 블로그에 댓글 기능을 켜두지 않아서 잘못된 정보를 정정받을 수 있는 기회도 놓쳤다고 생각하니 더욱 아쉽다. 댓글기능을 추가해야겠다.</p>
</blockquote>


window.open과 팝업차단

<p>작년 11월 개발자가 된 이후로 회사에서도 많은 일들이 있었다. 투자 받은 이후 사무실을 굉장히 좋은 곳으로 옮기기도 했고, 팀 리더분이 퇴사해서 팀에 리더자리가 공석이 되었다. (지금은 임시 리더분이 계신다) 또 최근에는 조직개편이 되어서 정들었던 컨텐츠 크루를 <strong>잠시</strong> 떠나게 되었다. 뭔가 앞으로도 꽤 많은 변화가 있지 않을까 싶다.</p>
<p>블로그에는 기술적인 트러블 슈팅이나, 새롭게 알게 된 것들을 많이 적고 싶었는데 그러지는 못해서 아쉽다. 기대하기로는 이번 달 부터는 매월 회고록을 작성하면서 그 달의 생각과 기술적으로 새롭게 알게 된 것들을 정리해볼까 한다. 일단 계획은… 아무튼 이런 기록을 남기는 습관을 만들기 위해서 일단 지금까지의 회고를 간단하게 작성해보려고 한다. 첫 회고이니 만큼 좀 넓은 범위의 이야기를 해볼 생각이다.</p>
<h3>제품에 애정을 갖는 것</h3>
<p>이번에 조직개편을 하면서 새삼 놀랐던 것은 내가 만들던 제품에 얼마나 큰 애정이 있었는지 알게 되었다는 것이다. 만약 진정성 없이 그저 개발만 했었다면 동기부여도 잘 되지 않았을거고 사용자에게 어떻게 하면 더 좋은 경험을 줄 수 있을지 이렇게까지 고민해보지 못했을 것 같다. 기술적인 역량은 당연한 것이고 그걸 뛰어넘어 더 '좋은 제품을 만드는 개발자’가 되려면 진정성을 갖고 제품을 사랑하는 것이라는 것도 배울 수 있는 기회였다. 그대로 새롭게 이동한 커리어 크루에서도 잘 해보자!</p>
<h3>누군가 짠 코드</h3>
<p>취업 이후 가장 많이한 것은 누군가가 짠 코드를 수정하는 일이었다. 물론 새롭게 작성한 코드도 많았지만 그 와중에도 내가 작성하지 않은 코드를 수정하는 것은 불가피했다. 그러면서 솔직히 불만이 없었다면 거짓말이었을 것 같다. 입사 초반에는 대놓고 불만을 토로했는데, 지금와서는 어리석은 짓이었다고 생각한다. 이미 작성 된 코드는 이미 일어난 일이다. 그리고 그때는 그게 옳았을 수도 있고, 더 좋은 코드를 생각할 수 있는 여건이 되지 않았을 수도 있다. 지금 당장 내가 짠 코드를 봐도 못마땅한 것들이 계속 보이는데 어쩔 수 없지 않았을까… 막상 내가 '못마땅한 코드’를 짜는 당사자가 될 수도 있다고 생각하니까 간사하게도 누군가 짠 코드에 대해서 이해심을 가지려고 노력하는 모습이 웃긴다.</p>
<p>누군가 짠 코드를 보면서도 성장할 수 있는 방법은 두가지 정도가 있는 것 같다. 첫 번째로 왜 이렇게 짰을까? 를 생각해보면서 코드 당사자(?)의 사고를 생각해 본다. 그러다 보면, '이래서 이렇게 할 수 밖에 없었구나’를 알게 되고 그걸 넘어서 '이렇게 했다면 어땠을까?'까지 간다면 베스트다. 두 번째로는 왜 이 코드가 못마땅한지 정확하게 파악해 보는 것이다. 보통 코드가 못마땅한 건 컨벤션이나 네이밍같은 것 보다는 기능의 수정이 어렵고 이해하기 어려운 경우가 대부분이다. 결국에는 설계의 문제인 경우가 많다. 그렇다면 어떻게 했으면 좋았을까를 내가 다시 생각해보는 것이다. 여건이 된다면 직접 리팩터링도 하면 베스트다.</p>
<p>아무튼 앞으로도 계속해서 개발을 한다면 대부분이 누군가 짠 코드를 수정하는 일이 될 텐데 여기에 불평 불만을 갖는 건 좋을 게 전혀 없다.</p>
<h3>앞으로</h3>
<p>개발자로서 성장하는 건 뭘까? 예전에는 지식을 많이 쌓는 일이라고 생각했었다. 자바스크립트에 대한 동작원리나 다양한 API를 더 많이 알게 되는 것이 성장인 줄 알았는데 이건 그냥 배움인 것 같다. 미시적으로 느끼는 건 하나의 기능을 설계하더라도 축적된 경험을 통해서 다양한 케이스에 대한 대응을 할 수 있는 설계를 할 수 있는 것에 대한 중요성을 느끼고 있다. 결국 <strong>올바른 경험의 축적</strong>이 성장과 가장 가까운 정의가 아닐까 싶다. 성장과 배움은 비슷하면서도 분리되기 때문에 이 두가지를 확실히 구분해서 이끌어가는 방향으로 나아갈 생각이다. 배움 측면에서는 네트워크와 인프라에 지속적으로 관심을 가져야 할 것 같다.</p>
<hr>
<p>앞으로는 트러블슈팅이 있을 때 마다 기록하려고 더 노력해 보려고 한다. 최근에는 <code>window.open</code> 메서드가 실행될 때 어떨 때 파업차단으로 처리되고 어떨 때 그냥 열리는지에 대해서 고민한 적이 있었는데 이 부분도 확실히 정리해서 포스팅 해보고 싶다.</p>


22년 8월 회고

<h2>인스턴스</h2>
<ul>
<li>클라우딩 컴퓨팅의 단위</li>
<li>하나의 인스턴스는 격리된 컴퓨팅 공간으로 동작한다</li>
<li>인스턴스는 유형별로 성능이 모두 다르며, 성능이나 목적에 맞는 유형을 선택해서 만들어야 한다</li>
<li>인스턴스의 네트워크 정책은 보안그룹을 통해 결정된다</li>
<li>사용자 데이터를 통해서 인스턴스가 실행될 때 자동으로 동작할 스크립트를 지정할 수 있다</li>
</ul>
<h3>온디멘드 인스턴스</h3>
<ul>
<li>사용한 만큼 초 단위로 요금을 내는 인스턴스, 가장 기본적인 방식이다.</li>
<li>가장 유연하게 운용이 가능하다</li>
</ul>
<h3>예약 인스턴스</h3>
<ul>
<li>1년, 3년 단위로 계약해서 사용하는 인스턴스</li>
<li>최대 75% 저렴하다 (온디멘드 대비)</li>
</ul>
<h3>스팟 인스턴스</h3>
<ul>
<li>싯가로 책정된 여분의 인스턴스를 사용하는 방식</li>
<li>요금은 인스턴스중 가장 저렴 (최대 90%)</li>
<li>하지만 지정한 요금 이상으로 인스턴스의 삿가가 올라가면 해당 인스턴스는 2분의 유예기간 이후 자동으로 중단됨</li>
<li>때문에 진행 상황을 잃으면 안되는 작업에는 적합하지 않음</li>
</ul>
<h4>스팟 요청</h4>
<ul>
<li>하나의 작업을 위해 스팟 인스턴스를 유지할 수 있도록 하는 서비스</li>
<li>스팟 요청에서는 설정한 예산에 맞춰서 최적의 스팟 인스턴스를 계속 요청해서 작업을 유지해줌</li>
<li>인스턴스가 계속해서 지속적으로 중단되고 재실행 될 수 있기 때문에 복구가 보장되는 작업에 적합</li>
<li>더 이상 작업이 불필요 하게 되면 반드시 스팟 요청을 철회하고 스팟 인스턴스를 직접 종료해줘야 함
<ul>
<li>만약 스팟 요청이 실행되고 있고 스팟 인스턴스만 종료하면 스팟 요청은 다시 스팟 인스턴스를 만들어서 실행시킴</li>
</ul>
</li>
</ul>
<h3>전용 호스트</h3>
<ul>
<li>AWS 데이터 센터의 물리적인 서버를 렌탈하는 방식</li>
<li>클라이언트 정책에 따라 물리적인 서버가 필요하거나 라이센스 관련 제한이 있을 때 사용</li>
<li>요금은 온디멘드와 예약 방식중에 선택해서 지불할 수 있다
<ul>
<li>마찬가지로 예약이 최대 75% 저렴하다</li>
</ul>
</li>
</ul>
<h3>전용 인스턴스</h3>
<ul>
<li>전용 호스트 같이 물리적으로 격리된 공간에 EC2 인스턴스를 제공받는 방식</li>
<li>동일한 AWS계정 내의 다른 인스턴스와 하드웨어 공유가 가능</li>
</ul>
<h3>Hibernate (절전 모드)</h3>
<ul>
<li>EC2 인스턴스를 절전 모드로 들어가게 해준다.</li>
<li>기존의 인스턴스 중단을 하게 되면 작업 내역과 루트 EBS불륨의 모든 데이터를 잃게 되고, 인스턴스를 재시동할 때 사용자 데이터의 스크립트를 다시 시작하여 비효율적일 수 있다.</li>
<li>절전 모드에서는 인스턴스의 메모리를 모두 저장한 채로 중단하고 저장한 메모리를 복구하여 인스턴스를 재시작하기 때문에 상태를 유지하면서 빠르게 인스턴스를 재시작 시킬 수 있다.
<ul>
<li>메모리 전체를 루트 EBS볼륨에 덤프하여 보관하고 해당 EBS볼륨을 암호화 처리 해야한다</li>
</ul>
</li>
<li>모든 인스턴스 유형에서 지원하지 않음</li>
<li>인스턴스의 램은 최대 150GB까지만 지원하며 EBS불륨의 사이즈는 램의 데이터를 모두 덤프할 수 있을만큼 충분히 여유있어야 한다</li>
<li>스팟 인스턴스에서는 사용이 불가능</li>
<li>절전 모드로는 60일까지만 유지 가능</li>
</ul>
<h3>EC2 Nitro</h3>
<ul>
<li>EC2의 개선된 가상화 기술을 도입한 차세대 플랫폼</li>
<li>고성능 컴퓨팅과 네트워킹을 제공하고 더 빠른 속도의 EBS볼륨을 제공
<ul>
<li>최대 64,000 IOPS의 속도를 제공</li>
<li>기존에는 최대 32,000 IOPS의 속도로 제공</li>
</ul>
</li>
<li>더 나은 보안 제공</li>
<li>A1, T3, C5, C6, D3, M5 등의 인스턴스 패밀리에서 제공</li>
</ul>
<h3>vCPU 최적화</h3>
<ul>
<li>인스턴스는 컴퓨팅을 담당하는 코어와 스레드를 제공한다</li>
<li>만약 4코어 2스레드라면 총 8개의 스레드가 제공되며 각 스레드 하나를 vCPU로 일컫는다.</li>
<li>상황에 따라 코어의 갯수, 코어당 스레드의 갯수를 축소하여 비용을 절감할 수 있다
<ul>
<li>컴퓨팅 성능이 필요 이상으로 부여되는 경우</li>
<li>코어당 라이센스를 지불해야 하는 경우</li>
<li>코어당 하나의 스레드가 성능에 더 좋은 경우</li>
</ul>
</li>
</ul>
<h3>용량 예약</h3>
<ul>
<li>AZ내에서 원하는 인스턴스의 공간을 미리 할당하여 확보할 수 있다.</li>
<li>해당 인스턴스가 당장 필요하지는 않지만 공간을 미리 확보하여 필요할 때 동작을 보장받을 수 있어야 할 때 사용한다</li>
</ul>
<h2>보안그룹</h2>
<ul>
<li>하나 이상의 인스턴스의 네트워크 인/아웃바운드 규칙을 지정해 줄 수 있음</li>
<li>인스턴스 역시 하나 이상의 보안규칙을 가질 수 있음</li>
<li>각 포트별로 들어오고 나갈 수 있는 포트와 IP주소를 지정해 줄 수 있음</li>
<li>IP주소 뿐만 아니라 다른 보안그룹을 예외 규칙에 추가하여 인스턴스 사이의 네트워크 규칙을 쉽게 지정해 줄 수 있다.</li>
</ul>
<h2>SSH</h2>
<ul>
<li>외부에서 인스턴스 내부로 터미널을 통해서 접속할수 있다. 인스턴스에 지정한 키 페어를 통해 자격증명을 해야 접속할 수 있다.</li>
<li>키 페어는 생성할 때 한 번 컴퓨터에 저장할 수 있고 그 이후에는 절대 재발급이 안되기 때문에 잘 보관해야 한다.</li>
</ul>
<h2>IP</h2>
<ul>
<li>하나의 인스턴스는 퍼블릭IP와 프라이빗IP를 갖는데 퍼블릭IP를 통해 외부와 통신할 수 있다.</li>
<li>프라이빗IP를 통해서는 AWS서비스 내에서 통신할 수 있다.</li>
<li>퍼블릭IP는 인스턴스를 실행할 때 마다 변경된다.</li>
<li>탄력적IP를 통해서 인스턴스가 재실행되어도 퍼블릭IP를 유지할 수 있고 계정별로 5개를 기본으로 사용할 수 있다
<ul>
<li>탄력적IP는 발급받고 인스턴스에 바인딩 하지 않고 보관하게 되면 요금이 발생</li>
<li>로드밸런서 등을 이용해서 외부와 연결하는 게 더 좋기 때문에 사용을 지양하는 게 좋다</li>
</ul>
</li>
</ul>
<h2>배치 그룹</h2>
<ul>
<li>다수의 인스턴스를 다양한 방법으로 AZ(Availability Zone)에 배치할 수 있다.</li>
<li>작업에 따라 적절한 배치 전략을 선택할 수 있다.</li>
</ul>
<h3>클러스터 배치 그룹</h3>
<ul>
<li>같은 AZ내에 같은 클러스터 내에 인스턴스들을 배치하는 방식으로 동작한다.</li>
<li>물리적으로 같은 랙 내부에 인스턴스들이 동작하므로 인스턴스간의 통신에서 초저지연을 기대할 수 있다.</li>
<li>단 클러스터가 포함된 랙이 이슈가 생기면 모든 인스턴스가 영향을 받기 때문에 위험도가 높다.</li>
</ul>
<h3>분산형 배치 그룹</h3>
<ul>
<li>모든 인스턴스를 AZ내에 모두 다른 랙에 배치한다</li>
<li>하나의 배치그룹 당 최대 7개의 인스턴스를 포함할 수 있으며 각 인스턴스는 모두 다른 랙에 배치되기 때문에, 모든 인스턴스가 예상치 못한 하드웨어 이슈에 영향을 받을 확률이 거의 없다.</li>
</ul>
<h3>파티션 배치 그룹</h3>
<ul>
<li>인스턴스를 파티션이라는 논리 구조로 묶어서 배치한다.</li>
<li>하나의 파티션은 같은 랙에서 동작하며 스프레드 방식과 동일하게 같은 AZ내에서 최대 7개까지 관리할 수 있다.</li>
<li>인스턴스 별로 파티션을 지정해주거나 자동으로 배치할 수 있다.</li>
<li>하나의 랙에 이슈가 생기면 해당하는 파티션에 포함된 인스턴스들만 영향을 받게 된다.</li>
</ul>
<h2>네트워크</h2>
<h3>ENI</h3>
<ul>
<li>가상 네트워크 인터페이스</li>
<li>하나의 ENI는 하나의 사설 아이피를 할당받는다.</li>
<li>하나의 EC2 인스턴스는 다수의 ENI가 바인딩 될 수 있다.</li>
<li>인스턴스간의 ENI는 이동 및 교체가 가능하다</li>
</ul>
<h2>스토리지</h2>
<h3>EBS</h3>
<ul>
<li>Elastic Block Store</li>
<li>인스턴스가 실행되는 동안 연결 가능한 네트워크 드라이브</li>
<li>네트워크를 통해 연결되기 때문에 지연이 발생할 수 있음</li>
<li>인스턴스 종료 이후에도 데이터를 유지할 수 있다.</li>
<li>CCP 레벨에서는 하나의 EBS는 하나의 EC2 인스턴스에 마운트 가능하며, 어소시어에트 레벨에서는 일부 EBS는 다중연결을 지원한다</li>
<li>동일 AZ내에 있는 인스턴스간의 마운트/언마운트가 가능하다</li>
<li>인스턴스를 생성할 때 Root에 마운트된 EBS볼륨은 기본적으로 인스턴스가 종료되면 삭제되도록 설정되어 있다
<ul>
<li>해당 속성을 비활성화 하여 인스턴스가 종료되어도 Root EBS볼륨을 유지할 수 있다</li>
</ul>
</li>
</ul>
<h4>EBS 볼륨 유형</h4>
<p><strong>일반 목적 SSD</strong></p>
<ul>
<li>일반적인 애플리케이션에 적합, 가성비가 좋음</li>
<li>시스템의 부트 볼륨 등으로 사용된다.</li>
<li>1GiB - 16TiB까지 제공</li>
<li><strong>gp3</strong>
<ul>
<li>기본으로 3,000 IOPS의 성능과 초당 125MiB/s 처리속도</li>
<li>최대 16,000 IOPS, 1,000MiB/s 처리 속도까지 증가 가능</li>
</ul>
</li>
<li><strong>gp2</strong>
<ul>
<li>이전 버전의 볼륨으로 최대 3,000 IOPS의 성능</li>
<li>GiB당 3IOPS를 제공하도록 설정되어 있음 5,334 GiB에서 3,000 IOPS이 성능 제공</li>
</ul>
</li>
</ul>
<p><strong>프로비저닝 된 IOPS의 SSD</strong></p>
<ul>
<li>IOPS 성능을 유지해야 하는 중요한 비즈니스 애플리케이션에 적합</li>
<li>DB 워크로드에 적합</li>
<li><strong>io1/io2</strong>
<ul>
<li>4GiB - 16TiB까지 제공</li>
<li>io2는 io1보다 높은 성능을 같은 비용으로 사용할 수 있기 때문에 io2를 선택할 수 있으면 io2를 선택하는 게 좋음</li>
<li>최대 32,000 IOPS의 성능</li>
<li>Nitor EC2 인스턴스에서는 최대 64,000 IOPS까지 가능</li>
</ul>
</li>
<li><strong>io2 Block Express</strong>
<ul>
<li>4GiB - 64TiB까지 제공</li>
<li>밀리초 미만의 지연속도</li>
<li>최대 256,000 IOPS의 성능 (IOPS:GiB의 비율이 1,000:1)</li>
</ul>
</li>
</ul>
<p><strong>HDD</strong></p>
<ul>
<li>부트 볼륨으로 사용할 수 없음</li>
<li>125MiB - 16TiB까지 제공</li>
<li><strong>st1</strong>
<ul>
<li>처리량에 최적화되어 있음</li>
<li>빅데이터, 데이터 웨어하우징, 로그 처리에 적합</li>
<li>최대 처리량 500MiB/s, 최대 성능 500 IOPS</li>
</ul>
</li>
<li><strong>sc1</strong>
<ul>
<li>아카이브에 최적화되어 있음</li>
<li>접근 빈도가 낮은 고용량 데이터에 적합</li>
<li>최저 비용으로 데이터를 저장할 수 있음</li>
<li>최대 처리량 250MiB/s, 최대 성능 250 IOPS</li>
</ul>
</li>
</ul>
<h4>EBS 다중연결</h4>
<ul>
<li>io1/io2 에서만 사용 가능</li>
<li>같은 AZ내에 여러 인스턴스에 연결해서 사용할 수 있음</li>
<li>클러스트 인식 파일 시스템 에서만 사용가능
<ul>
<li>XFS, EX4 등은 사용 불가</li>
</ul>
</li>
</ul>
<h4>EBS 암호화</h4>
<ul>
<li>EBS볼륨을 생성할 때 암호화를 활성화 할 수 있음</li>
<li>암호화된 볼륨과 인스턴스간의 모든 데이터 전송이 암호화됨</li>
<li>스냅샷을 생성할 때 암호화되어 생성됨
<ul>
<li>스냅샷에서 생성된 모든 볼륨은 암호화됨</li>
</ul>
</li>
<li>암호화 방식은 투명하게 공개되어 AWS에서 처리됨</li>
<li>성능상의 영향이 거의 없음</li>
<li>KMS(AES-256)를 활용</li>
<li>암호화 되지 않은 스냅샷을 암호화하여 사용할 수 있음</li>
<li>이에 따라 암호화 되지 않은 볼륨도 스냅샷 복사를 통해 암호화 할 수 있음
<ul>
<li>먼저 암호화되지 않은 볼륨의 스냅샷을 생성</li>
<li>생성된 스냅샷을 암호화
<ul>
<li>해당 과정을 생략하고 암호화 되지 않은 스냅샷을 통해 바로 암호화된 볼륨을 생성할 수도 있음</li>
</ul>
</li>
<li>암호화된 스냅샷을 사용해서 새로운 볼륨 생성
→ <strong>암호화된 볼륨으로 생성됨</strong></li>
</ul>
</li>
</ul>
<h4>스냅샷</h4>
<ul>
<li>EBS 볼륨을 백업하는 것</li>
<li>스냅샷을 이용해 EBS볼륨을 복원할 수 있다.</li>
<li>스냅샷은 서로 다른 리전이나 AZ에 복사하여 이동할 수 있다.</li>
</ul>
<h3>EFS</h3>
<ul>
<li>Elastic File System</li>
<li>EC2 인스턴스에 마운트 되는 NFS(Network File System)를 관리하는 서비스</li>
<li>EBS와 다르게 다중 AZ에서 사용할 수 있음</li>
<li>가용성과 확장성이 EBS에 비해 높으며, 비용도 많이 듬</li>
<li>gp3 기준으로 3배 정도 비싸지만, 데이터를 사용한 만큼만 지불하기 때문에 많은 양을 저장하는 게 아니라면 EFS가 더 저렴할 수도 있음</li>
<li>NFSv4.1 프로토콜로 동작</li>
<li>리눅스에서만 마운트 가능</li>
<li>보안 그룹을 이용해서 컨트롤한다</li>
<li>1000개의 클라이언트, 초당 최대 10GB의 처리량을 지원</li>
<li>용량은 최대 페타바이트 급으로 사용량에 따라 자동으로 확장되기 때문에 따로 용량을 지정하지 않아도 됨 (사용한 만큼만 지불)</li>
<li><strong>성능 모드</strong>
<ul>
<li>웹서버와 같이 지연시간에 민감할 경우 범용 성능 모드를 사용
<ul>
<li>작은 파일에 신속하게 접근해야 할 때</li>
</ul>
</li>
<li>대규모 워크플로우를 처리해야 할 때는 Max I/O 성능 모드를 사용
<ul>
<li>지연 시간은 조금 더 걸리지만 높은 처리량</li>
</ul>
</li>
</ul>
</li>
<li><strong>처리량 모드</strong>
<ul>
<li>버스팅 처리량 모드
<ul>
<li>1TB당 50MiB/s → 최대 100MiB/s까지 확장 가능</li>
</ul>
</li>
<li>프로비저닝 된 처리량 모드
<ul>
<li>크기에 상관없이 1GiB/s 까지 지정 가능</li>
</ul>
</li>
</ul>
</li>
<li>스토리지 계층
<ul>
<li>파일에 대한 수명주기 관리 기능</li>
<li>일정 주기에 한 번씩 접근 빈도에 따라 다른 계층으로 파일을 이동시킴</li>
<li>접근 빈도가 낮은 파일은 EFS-IA라고 부르는 저비용의 계층으로 이동시킴
<ul>
<li>단 해당 계층에 있는 파일을 이동시킬 때 추가 비용이 발생하기 때문에 빈도가 낮은 파일만 위치시켜야 효율적인 비용 전략이 가능</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>AMI</h3>
<ul>
<li>Amazon Machine Image</li>
<li>인스턴스의 운영체제의 설정과 기본 환경 설정을 사전에 정의해 패키징한 이미지</li>
<li>사용자가 만든 AMI는 리전에 종속된다</li>
<li>다양한 AMI를 선택하여 인스턴스를 생성할 수 있다
<ul>
<li>공개 AMI : AWS에서 제공하는 AMI</li>
<li>사용자 AMI : 사용자가 직접 정의한 AMI</li>
<li>마켓플레이스 AMI : 사용자, 기관에서 유/무료로 제공하는 AMI</li>
</ul>
</li>
</ul>
<h3>인스턴스 스토어</h3>
<ul>
<li>인스턴스의 물리 서버에 연결된 하드웨어 드라이브를 제공한다.</li>
<li>물리적으로 연결되어 있기 때문에 네트워크로 연결된 EBS보다 빠른 응답속도와 I/O성능을 보장한다.</li>
<li>단 인스턴스를 종료하면 데이터가 손실된다
<ul>
<li>때문에 장기적인 데이터 보다는 버퍼, 캐시, 스크래치 데이터 등을 저장하는데 적합하다.</li>
</ul>
</li>
<li>EC2 서버에 장애가 발생하면 영향을 받는다.</li>
</ul>


[AWS] EC2

<h2>간단정리</h2>
<ul>
<li>AWS서비스 내의 모든 정책과 권한에 대한 설정을 담당</li>
<li>최소 권한 부여를 원칙으로 설계해야 한다.</li>
</ul>
<h4>정책</h4>
<ul>
<li>AWS 서비스 내의 각 <strong>기능에 대한 권한</strong>의 벌크를 지정한 JSON</li>
<li>어떤 서비스 내의 읽기, 쓰기, 지우기 등의 권한을 지정해 줄 수 있다.</li>
<li>AWS에서 기본적으로 정의된 것이 있고 사용자가 임의로 추가할 수 있다.</li>
</ul>
<h4>사용자</h4>
<ul>
<li>root 계정이 아닌 계정들, 임의로 추가 및 삭제가 가능</li>
<li>사용자별로 액세스 키를 통해 AWS콘솔에 접근할 수 있다.</li>
<li>사용자는 사용자 그룹, 직접 설정을 통해 정책의 영향을 받을 수 있다.</li>
<li>사용자는 하나 이상의 사용자 그룹에 포함될 수 있다.</li>
</ul>
<h4>사용자 그룹</h4>
<ul>
<li>사용자 그룹을 통해 다수의 사용자가 정책을 공유할 수 있도록 할 수 있음</li>
<li>하나 이상의 사용자를 그룹에 포함시킬 수 있으며, 이미 다른 그룹에 있는 사용자도 포함시킬 수 있다.</li>
</ul>
<h4>역할</h4>
<ul>
<li>AWS 서비스 내에 접근할 수 있는 권한을 부여할 수 있는 자격 증명</li>
<li>AWS 서비스(대표적으로 EC2 인스턴스), 다른 AWS 계정, 그 외 에서 해당 AWS의 서비스 내에 접근할 수 있도록 하고 권한을 부여한다.</li>
<li>역할의 권한은 정책을 통해서 지정할 수 있다.</li>
<li>역할은 생성할 때 유형을 지정하고 해당 유형에만 역할을 부여할 수 있다.</li>
</ul>


22년 9월 ~ 11월 회고

window.open과 팝업차단

22년 8월 회고

[AWS] EC2

[AWS] IAM