(2주 스프린트라는 굴레에 갇혀 발버둥 치는 IT업계의 모든 동지들을 생각하며….. 💪)스크럼 개발 프로세스에서 반복되는 짧은 개발 주기마다 지속적인 품질과 생산성을 유지하기 위해서는 모든 프로세스 단계가 그에 맞게 최적화되어 있어야 합니다.정말 군더더기 없이 잘 준비된 아이템을 한 치의 오차와 지연 없이 거뜬하게 해낼 때야 다다를 수 있는 경지가 2주가 아닌가 생각합니다.대부분의 IT 조직이 맹목적으로 지키다시피 하지만, 정작 스크럼 가이드에서는 스프린트 기간이 꼭 2주여야 한다고 언급하진 않습니다. 대신, 스프린트 주기가 짧을수록 다음과 같은 이점이 있다고 얘기합니다.데모를 더 자주 실시하여 솔루션이 실제 요구 사항에 부합하는지 확인할 수 있는 기회를 더 많이 가질 수 있다.더 자주 회고하여 애자일 프로세스를 실험하고 개선할 수 있는 더 많은 학습 기회를 얻을 수 있다.프러덕 목표 대비 진척을 점검하고 지표를 통해서 추세를 더 빨리 확인하고 시정 조치를 취할 수 있다.짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다.이론적으론(그리고 이상적으론) 맞는 말이지만, 실무를 보다 보면 마냥 짧은 스프린트 기간은 다음과 같은 문제를 초래하는 경우가 많습니다.시간에 대한 압박이 너무 강해진다.스프린트가 잦아질수록 스프린트의 이벤트(스프린트 플래닝, 회고, 데모)들을 위한 비용(시간)이 증가한다.이벤트가 빈번하다고 느껴지면 식상해지고 결국 이벤트들이 갖는 의미가 퇴색될 수 있다. (학습 기회 X)일부분만으로는 의미 있는 지표를 관찰하기 힘든 경우가 많다.미완료 작업, 기술의 부채, 품질의 부채가 발생할 가능성이 높아지고, 결국 이에 대한 비용이 전가된다.재작업의 가능성도 커진다.결국, 조직 전체가 하나의 일률적인 스프린트 기간을 따르기보다는, 자기조직화 된 팀이 팀의 정황을 고려해서 가장 적합한 기간을 선택할 수 있어야 합니다. 더욱이 스크럼 방식을 이제 막 도입한 팀이라면 스프린트 기간을 조금은 여유 있게 가져가시고, 체력을 키우면서 조금씩 줄여가는 과정이 필요합니다.스프린트 개선점은 Lean 개발 방법론의 ‘7가지 낭비’를 통해 점검해 볼 수 있습니다.Work in progress미완성 작업 (완료 기준을 만족하지 않은 스토리)배포되지 않은 코드Over engineering특정 결과를 달성하기 위해 필요한 것보다 더 많은 작업을 수행하는 것고객이 필요로 하지 않는 기능을 추가하는 행동Hand-offs업무 이관, 정보의 전달전달 과정에서 누락 발생Task switching작업수행 중 다른 작업으로 전환할 경우 집중력 분산 및 시간 소모Delays작업의 지연, 대기 시간Relearning한동안 살피지 않았던 시스템의 일부분에 대한 재학습Task swtching, hand-off, 요구사항의 변경 시에도 발Defects/Rework결함은 서비스의 가치를 떨어뜨리는 요소결함을 수정, 확인, 배포하는 추가 작업 시간 필요재작업(rework)는 요구사항의 변경 시에도 발생우리 팀의 개발 스프린트 동안 위와 같은 낭비 요소들이 얼마나

Kubernetes를 설치하면, kubeconfig 라는 Kubernetes 접근에 대한 설정이 Home Directory 및 .kube라는 Directory 및에 config란 이름으로 저장되어 있는 것을 발견 할 수 있습니다.kubeadm 으로 Kubernetes를 설치한 후 아래와 같은 메시지를 확인하실 수 있습니다.config 파일을 보면, 아래와 같은 정보로 구성되어 있습니다.kubectl 이란 CLI는 Kube API Server에 접속하는 Client 입니다. 통상 K8S API Server는 통상 Private CA를 구성하여 사용함으로, Client에게 Private CA(K8S CA)정보와 Client가 사용할 Client인증서/Key정보를 전달해 주는 것 입니다.좀더 자세히 탐색해 보겠습니다. Client 인증서에는 Client가 누구인지를 나타내는 항목이 있습니다. K8S는 인증서의 Subject(인증대상) 중 CN항목을 User, O항목을 Group으로 판단합니다.config 파일의 client-certificate-data 의 값을 Decoding하면 다음과 같은 Subject를 가지고 있습니다.이름만 봐도, Admin 권한인 것을 유추 할 수 있습니다. 탐색해 보는 김에 K8S의 ClutserRoleBinding과 ClusterRole을 확인합니다. 뒤에 말씀드리겠지만, K8S는 RBAC를 제공합니다. ClusterRole이란 권한이고, ClusterRoleBinding은 권한과 특정 대상과의 Mapping을 정의 한 것 입니다.먼저 ClusterRoleBinding을 탐색해 봅시다. 아래와 같이 kubectl client가 속한 group인 kubeadm:cluster-admins이 cluster-admin이라는 ClusterRole를 갖습니다.그럼 cluster-admin 이란 ClusterRole이 어떤 권한을 갖는지 알아봅시다.모든 자원에 대한 모든 권한을 가진 Role 입니다. 우리가 추측했듯이 Admin(Super User)권한입니다.우리는 이번 탐험으로 K8S는 X509 인증서 기준 상호인증을 제공하고, User/Group별 RBAC을 제공하는 것을 확인 했습니다. 그렇다면 User/Group은 어떻게 관리해야 할 까요? user별 config 파일은 누가 어떻게 전달해야 할 까요?조금 찾아 보니 K8S 자체는 User, Group이란 자원을 별도로 관리하지 않습니다. 뭘 어찌하라는 것 일까요?본 기고를 통해 차근차근 알아보도록 하겠습니다.Kubernetes 사용자 관리에 대해서 알아 가기전에 Kubernetes의 구조에 대해서 복습해 보겠습니다.아래는 간단하게 도식화된 Kubernetes의 구조 입니다. Kubernetes는 API Server를 통해 Resource를 변경하는 시스템입니다. 즉 공용 게시판에 할일을 적으면 그림의 스폰츠밥(Client)들이 알아서 할일을 하고, 일을 마무리한 후, 작업명세서(리소스)의 상태를 변화 시키는 것 입니다. 결국은 어떤 Task를 행한다는 건 결국 중앙의

이 글은 IDG의 아티클을 전재하여 제공합니다. [원문보기] : https://www.cio.com/article/2088578 보험 기업 내셔널 라이프그룹(National Life Group)의 수석부사장이자 최고 정보 및 전략 책임자(Chief Information and Strategy Officer)인 니메쉬 메타는 소셜 미디어에서 수백만 명의 팔로워를 보유하지는 않지만, 스스로를 ‘인플루언서’라고 표현합니다. 회사에서 그만큼 강력한 영향을 줄 수 있는 위치에 서 있기 때문입니다. 니메쉬는 수년간 보험회사를 현대화하기 위한 기술 로드맵을 실행해 왔습니다. 최근에는 조직의 비즈니스 전략 수립을 돕고 175년 역사를 지닌 내셔널 라이프를 디지털 선구자로 재탄생시키기 위한 방향을 주도하는 역할도 함께 맡고 있습니다. 니메쉬 같은 IT 리더에게는 IT 외에도 비즈니스를 올바르게 이끄는 것이 중요합니다. 실제로 니메쉬를 비롯한 많은 CIO가 비즈니스팀이 요구하는 사항을 수동적으로 실행하는 것을 넘어 유망한 전략적 이니셔티브로 조직을 이끄는 일에 더 깊이 관여하고 있습니다. 덕분에 오늘날의 IT 리더는 더 넓은 시야를 가지고 더 큰 영향력을 행사하고 있습니다. 예를 들어, 니메쉬는 현재 내셔널 라이프의 3개년 기업 전략을 개발하고 있습니다. 니메쉬는 과거에 CIO는 가능한 것에 대해 조언만 해주고 최종 결정은 비즈니스 부서가 내렸지만, 이제 CIO는 변화를 주도하는 영향력 있는 리더가 되었으며, 기술뿐만 아니라 비즈니스에 변화를 가져와야 한다고 강조합니다. IT 미디어 CIO닷컴이 공개한 2024 CIO 현황 보고서에 따르면, IT 리더는 비즈니스 영역에서 더욱 중요해지고 있는 것으로 나타났습니다. 875명의 IT 리더와 251명의 핵심 부서(line of business, LOB) 담당자를 대상으로 실시한 이 설문조사에 따르면, 많은 CIO가 전통적인 IT 지원 및 혁신 추진 업무를 수행하지만, 최근에는 비즈니스 전략을 개선하고 변화를 주도하는 일도 적극 맡고 있었습니다. 데이터, 분석, 새로운 AI 기술의 융합으로 비즈니스가 변화하는 상황을 대비하는 의무가 생긴 것입니다. 2024 CIO 현황 보고서 응답자의 35%는 현재 자신을 전략적 CIO라고 묘사했으며, 절반 가까이(49%)가 3~5년간 전략 구상 역할을 수행할 것으로 예상했습니다. 전반적으로 CIO는 비즈니스 전략 조언자로서 위상이 계속 높아지고 있으며, IT 리더의 4분의 3과 LOB 응답자의 78%가 CIO가 대규모 조직에서 존재감 높아졌다고 답했습니다. IT 리더의 약 절반(48%)과 LOB 응답자의 41%가 기술 및 공급업체 추천뿐만 아니라 비즈니스 기회를 선제적으로 파악하기 위해 CIO를 찾고 있다고 답했습니다. 소수의 응답자(IT 리더 중 16%, LOB 중 11%)는 위험 관리 또는 거버넌스 렌즈를 사용하여 선택 사항을 평가하고 조언을 구하기 위해 CIO의 컨설팅을 구한다고 답했습니다.또한 이번 보고서에선 IT 조직 전체가 비즈니스 중심으로 재편되고 있는 상황을 엿볼

네이버 통합 검색의 성능이라는 말을 들으면 어떤 것이 떠오르나요? 검색 결과가 내가 찾던 내용과 얼마나 일치하는가를 떠올릴 수도 있고, 검색 결과가 얼마나 빨리 표시되는가를 떠올릴 수도 있습니다. 또 검색 결과 페이지를 얼마나 즐겁게 탐색할 수 있는가를 떠올릴 수도 있습니다. 이렇게 네이버 통합 검색의 성능은 여러 가지 측면에서 바라볼 수 있습니다.이런 여러 가지 측면 중 웹 성능 측면에서 네이버 통합 검색의 성능을 파악하고 개선한 내용을 "네이버 통합 검색의 웹 성능" 시리즈에서 공유합니다. 첫 번째 글에서는 네이버 통합 검색의 웹 성능 측정을 위한 데이터의 수집과 웹 성능의 시각화에 대한 내용을 다룹니다.웹에는 수많은 서비스가 있으며, 이 서비스는 각자 자신만이 제공하는 기능과 가치를 가지고 있습니다. 그러나 어떤 서비스든 그것이 웹 플랫폼에서 작동하는 서비스인 이상 서비스의 사용자는 다음과 같은 공통적인 경험을 하게 됩니다.• 브라우저를 이용해서 페이지에 진입합니다.• 페이지의 콘텐츠가 표시될 때까지 기다립니다.• 페이지의 콘텐츠가 표시되면 클릭, 스크롤 등의 인터랙션을 통해 서비스를 사용합니다.서비스 내용과 독립적으로 웹 플랫폼 자체가 가진 이런 사용자 경험 요소를 웹 성능(web performance)이라고 합니다.웹 성능과 관련해 사용자는 여러 가지 부정적인 경험을 겪을 수 있습니다. 예를 들어 페이지에 진입했는데 콘텐츠가 표시되는 속도가 너무 느린 경우가 있을 수 있습니다. 또는 콘텐츠가 다 표시된 줄 알고 특정 부분을 클릭하려고 하는데 갑자기 다른 콘텐츠가 추가로 표시되는 바람에 엉뚱한 부분을 클릭하는 경우도 있을 것입니다. 이런 상황이 발생하면 아무리 서비스의 기능이나 내용이 훌륭해도 사용자가 서비스를 부정적으로 인식하게 될 확률이 높습니다. 따라서 사용자에게 서비스의 기능과 가치를 잘 전달하기 위해서는 웹 성능과 관련된 경험을 좋게 유지하는 것이 필수입니다.어떤 것을 좋게 유지하기 위한 가장 간단한 방법은 그것을 정량 지표로 측정하고 관리하는 것입니다. 웹 성능을 측정할 수 있도록 만들어진 정량 지표로 웹 바이털이 있습니다. 웹 바이털은 여러 가지 지표 세트로 이루어져 있습니다. 대표적인 예로는 LCP(Largest Contentful Paint)와 INP(Interaction to Next Paint), CLS(Cumulative Layout Shift), FCP(First Contentful Paint) 등이 있습니다.• LCP: 화면에서 가장 큰 요소가 표시될 때까지 걸리는 시간을 측정합니다.• INP: 화면에서 사용자가 여러 인터랙션을 수행했을 때 그중 가장 느렸던 반응 시간을 측정합니다.• CLS: 화면에서 예상치 못한 레이아웃 이동이 얼마나 발생했는지를 측정합니다.• FCP: 화면에서 처음으로 그려진 요소가 표시될 때까지 걸린 시간을 측정합니다.네이버 통합 검색 역시 웹 서비스이기 때문에 웹 성능을 적절히 관리하는 것이 중요합니다. 네이버 통합 검색의 웹 성능 관리를 위해 네이버 통합 검색 결과 페이지의 웹

🥑CJ온스타일에는 ‘아보카도’가 있습니다아보카도는 온스타일의 Developer Relations 활동을 함께하는 멤버에요. 지지한다는 뜻의 ‘Advocate’와 철자가 비슷하여 지어진 이름이랍니다.흔히 PR (Public Relations)은 ‘대중’과의 관계를 유지하는 홍보 활동이라면, DevRel도 같은 맥락으로, ‘개발자’들과의 관계를 통해 장기적으로 기술적 우위를 점할 수 있는 생태계를 만드는 개념이에요.CJ온스타일의 DevRel은, IT 기술 조직을 알리고 성장하는 활동을 해요.회사마다 DevRel 목적과 활동의 유형이 달라요. 채용이 주 목적일 수도 있고, 외부 개발자가 고객인 경우도 있구요. 온스타일의 DevRel 소개는 추후 더 자세한 이야기로 찾아뵙겠습니다.🥑CJ온스타일 DevRel을 함께하는 아보카도!아보카도는 개발자, 기획자, 전략, 인프라 등 각기 다른 영역에서 모여 현장 이야기를 공유하고 우리의 일하는 방식과 성장할 수 있는 방법을 고민합니다.아보카도는 이런 활동을 했어요. (‘23년 1기)

Python에서 음성 파일을 만들고 작성하는 것은 재미있고 유용한 기술이 될 수 있습니다.특히 오디오 피드백이 필요한 앱을 구축하거나 프로젝트의 접근성을 높이는 데 더욱 그렇습니다.이를 달성하는 가장 쉬운 방법 중 하나는 gTTS(Google Text-to-Speech) 라이브러리를 사용하는 것입니다.수행 방법에 대한 초보자 친화적인 가이드는 다음과 같습니다.파이썬이 설치되어 있다는 가정하에, 먼저 gTTS 라이브러리를 설치해야 합니다. 터미널이나 명령 프롬프트를 열고 다음 명령을 입력하십시오.이제 텍스트를 음성으로 변환하고 MP3 파일로 저장하는 간단한 스크립트를 작성해 보겠습니다.함수를 이용하려면 아래와 같이 작성합니다.• None gTTS 가져오기: gtts 모듈에서 gTTS 클래스를 가져오는 것부터 시작합니다. 을 넣지 않으면 외국인이 한국말을 하는 것처럼 들리니 반드시 추가해야 합니다.• None 함수 정의: 함수는 ** **와 ** **을 인수로 사용합니다. 입력된 텍스트는 음성으로 변환됩니다.• None 음성 생성 및 저장: 함수 내에서 텍스트를 전달하여 gTTS 인스턴스를 생성합니다. 그런 다음 메소드를 사용하여 ** **으로 지정된 MP3 파일로 음성을 출력합니다.IDE를 통해 또는 터미널에서 다음을 입력하여 Python 스크립트를 실행합니다.이렇게 하면 스크립트에 작성한 텍스트를 재생하는 MP3 파일이 디렉토리에 생성됩니다.이러한 단계를 통해 Python 및 gTTS를 사용하여 간단한 텍스트 음성 변환 애플리케이션을 만들었습니다.이는 텍스트 파일 읽기 또는 다른 응용 프로그램과의 통합과 같은 더 복잡한 기능으로 확장될 수 있습니다.다음에는 5분이상 길이의 스크립트를 음성으로 만든다면 어떻게 해야 할까요?기존에는 웹스크랩핑으로 텍스트를 긁어와서 파일을 만들었다면 이제는 ChatGPT에게 요청하여 만들 수 있습니다.ChatGPT를 이용하면 스크립트의 주제나 내용을 구체적으로 요청할 수 있는 장점이 있습니다.요청에 결과는 아래처럼 파일로 작성되었습니다. (버전 4로 만든내용입니다.)이제 만들어진 'Shampoo_Advertisement_Conversation.txt' 파일을 읽어서 mp3로 만들어봅니다.Python에서 MP3 파일을 재생하려면 'playsound' 모듈을 사용하면 됩니다.이는 오디오 재생을 처리하는 간단하고 직접적인 방법입니다. 방법은 다음과 같습니다.만약 설치할때 오류가 발생한다면 아래 2개도 함께 설치합니다.위의 코드에 playsound를 추가합니다.이렇게 하면 음성파일을 만들어서 매번 만들어졌는지 실행할 필요없이 바로 확인이 가능합니다.play를 종료하고자 한다면 실행 터미널에서 crtl +C 를 누릅니다.chatGPT를 이용하여 다시 코드로 복귀하는 불편함은 바로 api key를 이용하여 openai api 를 사용할 수 있습니다.그런데 chatgpt 비용과 platform 비용이 별도라 비용이 두배로 든다는 것은 참고해야 합니다.이렇게 하면 바로 mp3 파일이 생성되고 실행도 됩니다. 여기에 스크립트