오랜만에 글을 작성해 보는데요로봇이 등장할 시대를 준비하는게 이제 필요할 것 같습니다.이번 포스트에서는Open AI 샘 올트먼이 진행했던 로봇과 사람을 구별하는 프로젝트 World Coin에 대한 내용을 소개해 볼려고 합니다대학교 3학년- 4학년 차선인식이라는 프로젝트를 진행했습니다.라떼는 저용량의 이미지로부터 차선에 대한 특징을 어떻게 찾아낼까를 고민을 했더랬죠지금의 딥러닝이 하는 과정을 사람들이 했습니다. 차를 타고 차선이탈을 테스트하면서 정말 즐거웠던 기억이 납니다.지금은 LLM이란 막강한 모델들이 나오고, 정교한 추론을 하면서이제는 사람보다 더 뛰어납니다. 곧 자율주행의 상용화도 멀지 않았습니다.더 나아가 생각해 본다면 하드웨어가 발전이 되면 로봇이 나오고 곧사람인지 사람이 아닌지를 구분해야할 시대가 올 것 같습니다. 이 시대를 먼저 예측? 고민?한 사람이 있는데요..바로 샘 올트먼 입니다. OpenAI 창립자이죠. 올트먼은 Chat GPT 로 세상을 놀라게 하고는뜬금없이 Web3에 World Coin 프로젝트를 진행합니다.World Coin은 어마어마한 관심속에 여러 거래소에 빠르게 상장되고.. 가격이 급등을 하게 됩니다.사실 많은 사람들은 코인의 가격에 관심이 있죠.. (전 월코코인을 가지고 있지 않습니다)그런데 가격을 빼고 World Coin의 내용을 보면 흥미롭기는 합니다.문제의 시작은 언젠가는 사람과 로봇을 구별해야 한다이고, 그 것을 푸는 열쇠를 홍채로 가닥을 잡았습니다.Orb라는 기계로 홍채를 인식해서 홍채 해시를 만든 다음 블록체인으로 연결해서 월드ID를 생성합니다.홍채 코드는 개인의 홍채를 숫자화 한 것으로 작은 변수에도 값이 달라지는 단순한 해시가 아닌 2D 가보르 필터를 홍채 질감에 적용하여 복소수 응답값을 얻고, 그 위상 정보만을 2비트로 양자화하여 생성한다.해밍 거리가 특정 임계값 이하이면 동일 홍채로 간주한다.지금 이 Orb 매장들이 국내에 대략 50군데 있구요. Orb는 100달러에 주문이 가능합니다. (저도 주문을 해 볼 생각)그리고 SKT타워 근처이죠 을지로 하이드미프리즈에서 월드ID를 생성할 수 있습니다. (다른 말로 홍채정보를 등록한다)하이드미프리즈는 제가 처음으로 오프라인에서 NFT를 구매했던 곳이기도 합니다.무언가 모르게 점점 현실 세상으로 다가 오는 것 같은데요.. 얼마전에 기사가 하나 났습니다.• None 현재 월드코인은 전 세계적으로 1200만 명 이상의 인증 사용자와 3억 2000만 건 이상의 거래를 기록 중이다.규모의 경제라고 많은 사람들이 사용하면 그게 대세가 되어가는데..현재는 각국의 정보보호법에 의해서 활성화가 안되고 있습니다.홍채 수집이라는 걸림돌..그런데 정말 로봇과 사람의 구분이 필요한 시기가 온다면..지금의 캡차 (CAPTCHA)가 무용지물이 된다면 신원인증에서는 월드ID가 표준이 될지도 모르겠다는 생각을 해 봅니다.로봇과 구분하거나 신원인증의 가장 좋은 방법이 홍채가 정답인지는 모르겠는데어떻게 생각하시나요? 다른 분들의 생각도 궁금합니다.다음에는 조금 더 Tech에 관련

안녕하세요 현대오토에버 디지털채널시스템팀 장준용 책임입니다.저는 약 3년 전 쯤에 기아닷컴 운영 업무를 맡게 되면서 처음으로 쿠버네티스 기반의 MSA 서비스 운영 환경을 접하게 됐습니다.클러스터가 뭔지, 파드가 뭔지도 모르던 쿠버초보가 어느새 모든 쿠버네티스 자격증을 따서 Kubestronaut 이 된 후기를 공유하려고 합니다. 쿠버네티스 관련 공부를 어떻게 시작해야 할지 고민하는 분들께 조금이나마 도움이 되면 좋겠습니다~!0. 먼저, Kubestronaut이란?Kubestronaut은 쿠버네티스(Kubernetes)와 우주비행사(Astronaut)의 합성어로, CNCF에서 제공하는 아래 5가지 자격증을 모두 취득한 사람을 일컫는 비공식적인 용어입니다. 현재 CNCF의 공식 자격증은 다음과 같습니다:CKA (Certified Kubernetes Administrator): 쿠버네티스 관리자 자격증CKAD (Certified Kubernetes Application Developer): 쿠버네티스 애플리케이션 개발자 자격증CKS (Certified Kubernetes Security Specialist): 쿠버네티스 보안 전문가 자격증KCNA (Kubernetes and Cloud Native Associate): 쿠버네티스 및 클라우드 네이티브 입문 자격증KCSA (Kubernetes and Cloud Native Security Associate): 쿠버네티스 및 클라우드 네이티브 보안 입문 자격증저는 먼저 실무에 필요했던 CKA, CKAD, CKS를 취득했고, 이후 KCNA와 KCSA가 새롭게 출시되었을 때 "이왕 여기까지 했는데 다 따볼까?" 하는 마음으로 추가로 취득했습니다. 지금부터 각 자격증 도전기를 하나씩 풀어보겠습니다.1. CKA (Certified Kubernetes Administrator)"???" 제가 처음 쿠버네티스를 마주했을 때 든 생각이었습니다. 혼란스러웠던 저는 가장 기초적인 CKA부터 공부하기로 했습니다.처음에는 컨테이너에 대한 이해도 부족하고 kubectl create pod도 못하는 수준이었는데, CKA를 공부하며 개념들을 하나씩 배우다 보니 점점 재미가 붙었던 것 같습니다. CKA는 가장 기본이 되는 자격증이면서도 쿠버네티스의 핵심을 다루기 때문에 모든 자격증의 기반이 되는 지식과 실습 경험을 얻을 수 있었습니다.시험은 100% 실습 위주로, 주어진 시간 내에 다양한 태스크를 수행해야 합니다. 클러스터 설정부터 네트워킹, 문제 해결까지 폭넓은 내용을 다루죠. 특히 etcd 백업 및 복구, 클러스터 업그레이드 같은 관리 작업이 중요한 부분이었습니다.시험 시간은 2시간인데, 막상 모의고사와 연습문제에 익숙해지니 약 1시간 정도에 모든 문제를 풀 수 있었고, 남은 시간은 검수하는 데 썼습니다.특히 Udemy의 Mumshad 강의는 Kodekloud에서의 실습 환경을 제공하기 때문에 사실 상 CKA 필수 강의라고 생각합니다.학습 팁실습 환경: KodeKloud에서 제공하는 실습 문제/환경을 통해 다양한 클러스터 문제 해결 시나리오를 연습했습니다. 이 환경이 실제 시험과 유사하기 때문에 모의고사 같은 느낌으로 여러 번 풀어 보는 것이 좋습니다. 집에서도 minikube로 연습해봤지만, 귀찮기도 하고 문제까지 제공해주는 KodeKloud 환경이 편하면서도 실질적 도움이 됐던 것 같습니다.학습 기간: 저는 약 1.5개월을 틈틈히 공부하여 합격했습니다. 주로 퇴근 후 남는 시간에 공부하고, 주말에는 4~5시간씩 공부했었습니다.핵심 포인트: 문제 유형에 익숙해지는게 제일 중요합니다. 비슷한 문제나 명령어가 반복적으로 나오기 때문에 문제를 보고 빠르게 판단하여 해결하는 능력이 중요합니다. 시험 전날에는 반드시 Kodekloud 모의고사를 한번 더 풀어보는 것을 추천합니다.2. CKAD (Certified Kubernetes Application Developer)CKA 합격 메일을 받자마자 "이왕 하나 땄으니 CKAD도 따볼까?" 하는 생각이 들었습니다. CKA에서 배운 지식을 개발자 관점에서 활용하는 자격증이라, 실제로 앱을 쿠버네티스에 배포하는 내용이 포함됩니다.CKA를 제대로 공부했다면, CKAD는 별도의 강의를 수강하지 않고 CKAD 고유 시험 범위(Ingress, Job, CronJob 등)에 대한 추가 문서 학습만으로도 합격할 수 있습니다.학습 팁학습 자료: CKA 준비 과정에서 사용한 자료와 쿠버네티스 공식 문서를 참고했습니다. 특히 공식 문서에서 CKAD와 관련된 내용을 중점적으로 살펴봤어요. 이미 Mumshad 강의를 한번 들었기 때문에, 이번에는 CKAD 부분만 복습했습니다.실습 환경: 강의를 다 듣지는 않았지만, CKAD 강의자료에서 제공하는 KodeKloud 실습 문제와 모의고사는 적극적으로 활용하여 준비하였습니다.학습 기간: CKA 지식을 바탕으로 약 1-2주 정도의 추가 학습( 문제 풀이 포함 ) 만 필요했습니다.핵심 포인트: CKA와 마찬가지로 kubectl 명령어를 자유자재로 사용할 수 있어야 하며, 실수하지 않는 꼼꼼함( 예를 들면 YAML 파일 들여쓰기와 같은..) 이 중요합니다.3. CKS (Certified Kubernetes Security Specialist)당시로서는 마지막 남은 자격증이었던 CKS. 막연하게 따고 싶다는 생각이 들어 도전하게 되었지만 앞선 CKA/CKAD와는 달리 쉽게 접근했다가 큰 코 다쳤던 자격증입니다.Kubestronaut을 취득하기 위한 5개 자격증 중 압도적으로 가장 어려웠습니다. 처음 시험을 봤을 때는 "이게 대체 뭐지?" 싶을 정도로 처음 보는 낯선 내용들이 많았고, 결국 불합격했습니다. 그리고 불합격했던 첫 번째 시험에서 나왔던 문제들에 대해서 추가로 공부한 끝에 2번째 시도에서 합격할 수 있었습니다.CKS는 쿠버네티스 보안 설정, 취약점 분석, 런타임 보안 등 다양한 보안 측면을 다룹니다. 특히 NetworkPolicy, 보안 컨텍스트, 감사 로깅 등이 가장 까다로웠고, CKA/CKAD와 달리 시험 시간(2시간)이 매우 빠듯했습니다. 모든 문제를 풀었는데도 검토할 시간이 거의

글. 김선일(Nathan) / Core UX Team Lead1년 전, 처음 이 글을 쓰며 ‘3P(Purpose, Person, Process)’를 바탕으로 팀을 리딩하기 시작했어요. 팀의 비전과 미션을 수립하고, 핏이 맞는 좋은 분을 채용하고, 부족했던 프로세스와 프레임워크를 도입하여 팀의 중심을 세워갔어요. 그렇게 저는 ‘K-팀장’을 졸업하고 ‘진짜 팀장’으로 조금씩 성장하고 있었습니다. 아니, 그런 줄 알았죠. 그런데 팀의 구조가 안정될수록, 또 다른 벽이 보이기 시작했어요.“우리 팀은 회사와, 나는 리더와, 팀원은 나와… 잘 연결되어 있을까?”이런 생각, 해본 적 있으신가요?“우리 팀은 어떤 팀보다 빠르게 성장하고 성과를 보여주고 있는데, 부족하다는 평가를 받지?”“A 팀원을 리딩한 지 어느덧 2년이 돼 가는데, 준비해 온 결과물이 내 생각과 같은 적이 없지?”“B 팀원이 이 시니어로써 다른 역할까지 하기를 바라는데, 왜 성장이 뎌딜까?”“옆 팀 리드와 나는 협업에 있어 왜 이렇게 어긋나지?”실무자로서, 매니저로서, 어떤 직책에 있든 조직에서 리딩 경험이 있다면 누구나 한 번쯤은 떠올렸을 고민일 거예요. 이런 고민들은 단순한 개인의 퍼포먼스로 인해 발생하는 것이 아닙니다.리더, 동료, 팀원과 Align이 안 된 상태, 즉 내 리더와는 팀 목표와 우선순위, 내 역량/역할에 대한 기대치를 맞추고(Expectation Alignment), 팀원들과는 각자의 역할과 기여 가치를 명확히 정의하며(Value Alignment), 동료들과는 협업 과정에서 공감대를 형성(Consensus Alignment) 하지 못하고 있다는 신호인 거죠.또다시 질문이 생겼어요.“나는 지금 누구와 Align 되어 있는가?” “우리 팀은 회사와, 나는 리더와, 팀원은 나와… 과연 잘 연결되어 있을까?”그때부터 저는 Managing Up / Down / Sideways라는 조직 내 Alignment의 세 방향을 탐색하기 시작했습니다.Managing Up: 리더를 리딩하는 Alignment의 기술조직 리더와의 관계에서 가장 어려운 점은 기대와 현실의 간극입니다.특히 팀장 역할을 하다 보면, 명확하지 않은 기대와 주도적이지 못한 대화가 반복되기 쉬워요. 저도 처음에는 리더가 제시하는 방향을 최대한 따르려 했지만, 시간이 갈수록 멘탈이 흔들리는 상황들이 자주 생기더라고요. 때로는 의도치 않게 충돌도 일어나고요.수많은 시행착오와 고민 끝에, 문득 이런 생각이 들었어요.“문제의 출발은 나였구나.”예를 들어, 리더가 A~D를 해보라고 오더를 준다고 가정해볼게요. 이전에는 그게 다소 주먹구구식이더라도 일단 따라가보려 했어요. 그리고 일부는 “A~C는 가능하지만, D는 어렵습니다”라고 단순하게 대응했죠.하지만 지금은 이렇게 말합니다“D는 어려울 것 같아요. 대신 E로 접근해보면 어떨까요?”이건 단순히 할 수 있는 것만 말하는 게 아니라, 내가 주도적으로 목표를 재정의하고, 리더가 기대해야할 방향을 설계하는 것이에요.이 한마디로 리더와의 커뮤니케이션이 훨씬 명확해졌고, 저는 ‘시

안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니 다.저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '실상과 허상'입니다.다음 는 를 통해 조회한 사용자 ID와 이름을 관리합니다. 조회하려는 데이터는 한 번에 모두 가져올 수 없고, '청크(chunk)'로 구분해서 가져올 수 있습니다.여기서 논의를 단순화하기 위해 다음과 같이 가정하겠습니다.• 해당 코드는 특정 스레드에서만 실행된다(스레드 안전성은 고려하지 않아도 됨).• 조회할 수 있는 데이터는 변하지 않으며, 청크는 별로 정렬되어 있다(시간 경과에 따른 청크 불일치는 고려하지 않아도 됨).이 코드에 개선해야 할 점이 있나요?돌은 제멋대로 굴러간다다음 코드를 실행하면 과 의 값에 일관성이 없는 것처럼 보입니다.세 로컬 변수는 또는 이므로 모두 읽기 전용(unmodifiable/readonly)입니다. 하지만 가변성(mutability)에는 차이가 있습니다.• : 원본 에 대한 참조. 에 의해 변경될 수 있음.• : 원본 의 키에 대한 뷰(view). 에 의해 변경될 수 있음.• : 속성 접근 시 생성된 복사본. 가 어떠한 작업을 하더라도 변경되지 않음.이 문제를 해결하기 위한 옵션이 몇 가지 있습니다.옵션 1: 요소에 대한 접근만 허용이나 을 반환하지 않고 개별 에 대해 이름을 반환하도록 하면, 이후 진행되는 업데이트에 신경 쓰지 않아도 됩니다.다만 이를 구현하려면 목록을 별도로 관리해야 하며, 를 로 변경해야 합니다.경우에 따라 후속 처리를 위해 컬렉션을 반환하고 싶을 때도 있습니다. 이런 경우에는 반드시 복사본을 반환하도록 하는 것도 하나의 방법입니다.함수 이름에 "create", "snapshot", "copy", "clone", "newInstance" 등을 추가하면 복사본이 반환된다는 것을 명확하게 나타낼 수 있습니다. 또한, 이나 에 주석을 달면 다른 개발자가 실수로 복사본 생성 코드를 삭제하는 것을 방지할 수 있습니다.다만, 이 방법은 성능에 영향을 미칠 수 있으므로 주의해야 합니다(Swift의 와 같은 카피 온 라이트(copy-on-write) 메커니즘이 있다면 이를 활용하는 것이 좋습니다).다른 옵션을 적용할 수 없는 경우에는 원본 컬렉션에 대한 참조를 그대로 반환해야 할 때도 있습니다. 다만, (가령 단일 스레드일지라도) 컬렉션이 처리되는 동안 해당 컬렉션이 변경될 수 있다는 점에 유의해야 합니다. 따라서

안녕하세요, 데이터분석플랫폼 조직의 루이스입니다.시리즈의 마지막 글을 쓰게 되었습니다. 첫 번째 글에서는 아파치 플링크로 CDC(Change Data Capture)를 수행하여 MySQL 테이블을 다른 MySQL 테이블로 연동하는 내용을, 두 번째 글에서는 MySQL 테이블을 아파치 아이스버그(Apache Iceberg)로 CDC를 수행하고 운영하면서 얻은 경험을 공유했는데요. 이번 글에서는 수집하는 로그 형태에 따라 아이스버그 테이블의 파티션 및 최적화 방식을 어떻게 수행하면하면 좋을지, 현재 운영 방식과 테스트해본 내용을 공유하고자 합니다.먼저 저희 팀의 미션을 간략하게 말씀드리면, 서비스 팀들의 데이터를 취합하여 일단위의 지표를 추출하고 제공하는 것이라고 할 수 있습니다. 아파치 카프카(Apache Kafka)와 데이터베이스(Database) 등 다양한 소스에서 데이터를 수집하고 있으며, 그 과정에서 서비스 팀의 데이터베이스를 활용해야 하는 경우도 있습니다. 그러나 서비스 팀의 데이터베이스에 접근하여 데이터를 가져오는 방식은 서비스 운영에 부담을 줄 수 있기에, 앞서 첫 번째 글에서 보여드린 것처럼 CDC를 통해 데이터 레이크하우스 기술 중 하나인 아이스버그로 연동하여 지표 추출 파이프라인을 개선했습니다.본 글은 두 유형의 로그를 아이스버그 테이블로 적재 시 필요한 설정 및 최적의 운영 방법을 공유하는 것을 목표로 합니다. 먼저 지표 추출을 위해 수집하는 로그를 유형과 특성에 따라 아이스버그 테이블에 적재하는 방식을 소개합니다. 그리고 적재된 데이터 및 조회 패턴을 고려한 아이스버그 테이블의 파티션 전략과 최적화 방식에 대한 경험을 공유합니다. 마지막으로, 아이스버그 관련 지표 모니터링을 어떻게 하면 좋을지 정리하면서 글을 마무리합니다.만약 아파치 플링크(Apache Flink)와 아이스버그 관련 배경 지식이 없으신 경우 본 글을 이해하기 어려울 수 있으니, 아이스버그 관련 기본적인 내용을 다루는 두 번째 블로그 글을 먼저 읽으시는 것을 권장드립니다.저희 팀은 지표 계산을 위해 다음과 같은 유형의 로그를 활용합니다:• 클라이언트 로그• 데이터베이스 변경 로그(이하 DB 로그)이 중 서버 로그와 DB 로그는 팀에서 직접 수집하여 지표를 계산하는데 활용됩니다. 이번 파트에서는 DB 로그에 대해서는 현 운영 방식에 대한 소개를, 그리고 서버 로그에 대해서는 현 수집 상황과 어떻게 개선해 나갈 예정인지 테스트한 내용을 공유하겠습니다.다만, DB 로그는 현재 실제 운영 환경에서 적용 중인 방식이고, 서버 로그는 테스트 중인 방향성임을 미리 밝히며, 이 글에서 다루는 설정이나 방식은 사용 목적과 환경에 따라 더 최적의 설정이나 방식이 있음을 참고해주시기 바랍니다.DB 로그는 앞선 블로그에서 설명한 것처럼, 각 서비스 조직들의 MySQL 테이블들을 아파치 플링크를 활용하여 팀 내 하둡 파일 시스템의 아이스버그 테이블로 CDC 연동하고 있습니다. 현재 운영 중인 아이스버그 테이블의 적재 모드, 파티션 전략, 그리고 커밋(commit) 주기에 대해

Hi, I am SeungMin Lee from the Data Analytics Platform team at Kakao.This is the last article in the series. In the first article, we shared performing CDC (Change Data Capture) using Apache Flink to synchronize a MySQL table with another MySQL table, an...

얼마전 주변에서 cursor cursor해서.. Cursor IDE가 뭐지? 하고, 궁금함에 cursor.com에 가서 툴을 다운로드 하였습니다.월 $20 유료 버전이 있지만, 우선 Free로 2주간, 2,000개 completions가 가능하다고 하니, 무슨 툴인지 알아볼 수는 있겠군. 하며 설치를 하였습니다.설치했더니 덩그러니, open project만 표시되고.. 음 뭐지.. 이게 뭐야하는 실망감.IDE 인데.. chat이 있는 ide인가.. 이걸로 뭘 할 수 있지.그래서, 그냥 처음이니, 테트리스를 한번 만들어 볼까 하고" tetris 폴더를 만들고, 그 안에 테트리스 만들어줘" 라고 했습니다.cursor가 작업을 하기 시작합니다.그리고는 금방 브라우저에서 즐길 수 있는 테트리스가 만들어졌습니다. (요청할 때, 브라우저에서 할 수 있도록 javascript로 만들어줘 라고 하면 더 정확하게 나옵니다.)이 부분에서도 깜짝 놀랐습니다. 직접 일부 코드를 수정해 보려고 index.html에 P-tag만 넣었는데..바로 title에 수정한 이름이 자동 입력이 됩니다. ... 머지... 내가 이걸 넣을 지 어떻게 알고... (전뇌가 연결된 줄).... 추천이 나올 때 tap 버튼을 누르면 입력이 됩니다.하지만, 수정이 잘못 되었죠... ㅠㅠ 그래서, 제목을 테트리스 위에 넣어 달라고 하고..또, 테트리스 한줄, 두줄 사라질 때마가 차별화해서 점수도 주고, 점수를 최대 10명까지 높은 순서로 기록해서 브라우저 local storage에 저장해 달라고 해 봤습니다.제가 수정한 코드 및 요구사항까지 모두 반영을 하였습니다. 그리고 다음 괕이 과정도 보여줍니다.이제 JavaScript 파일을 수정하여 요청하신 기능들을 추가하겠습니다:Local Storage를 이용한 점수 저장 및 로딩요청하신 모든 기능이 성공적으로 추가되었습니다! 이제 테트리스 게임에 다음과 같은 새로운 기능들이 포함되었습니다:제목 표시: "Timjoo's Tetris" 제목이 게임 보드 위에 표시됩니다.게임 종료 시 이름을 입력하여 점수를 저장할 수 있습니다.최대 10개의 고득점이 저장됩니다.고득점자 목록은 화면 좌측에 표시됩니다.이름, 날짜, 점수 정보가 포함됩니다.고득점자 목록은 브라우저의 로컬 스토리지에 저장됩니다.브라우저를 닫았다가 다시 열어도 기록이 유지됩니다.최종 점수와 이름 입력 필드가 포함됩니다.게임을 실행하려면 tetris 폴더의 index.html 파일을 웹 브라우저에서 열어주세요. 별도의 설치나 설정이 필요하지 않습니다.즐거운 게임 되세요! 추가적인 기능이나 수정이 필요하시다면 말씀해 주세요... 근데, 직접 접수를 올리면서, 테스트 하기가 귀찮아졌습니다. 그래서, 테트리스 자동으로 수행하는 기능을 추가 요청했습니다.두둥!! 바로 자동 플레이 기능이 추가됩니다.현재는 신규 개발화는 화면 기획, 설계에 활용을 시도 중인데, 정말 이런 자동 코딩 ide를 사용하는 이와 사용하지 않는 이의 생산성 차이는 점점 크게 벌어질 것 같습니다.PS.) cursor로 간단하

현재 제가 진행 중인 프로젝트의 IT 환경에서 컨테이너 기술은 매일 사용되는 필수적인 요소가 되었습니다.특히 Kubernetes(K8s)와 같은 오케스트레이션 도구를 통해 클라우드 네이티브 애플리케이션의 배포와 관리를 정말 편리하고 신속하게 수행할 수 있게 되었죠.과거에는 Kubernetes 설치를 위해 Docker 기반으로 복잡한 설정 과정을 거쳐야 했지만,containerd와 같은 경량화된 컨테이너 런타임의 발전으로 설치 과정이 간소화되어 온프레미스 환경에서도 보다 효율적이고 안정적인 구축이 가능해졌습니다.이번 글에서는 컨테이너 런타임의 개념과 발전, 그리고 이를 통해 클라우드 네이티브 Kubernetes 설치가 얼마나 간편해졌는지를 실무 사례와 함께 소개해 드리겠습니다.컨테이너 런타임의 개념과 의의컨테이너 런타임(Container Runtime)은 컨테이너의 생성, 실행, 관리를 담당하는 핵심 소프트웨어로, 클라우드 네이티브 환경에서 중추적인 역할을 수행합니다.여기서 "런타임"은 단순한 실행 시간을 넘어 컨테이너의 전체 생명 주기 관리, 리소스 할당(CPU, 메모리, I/O 등), 격리 환경 유지, 호스트 운영 체제와의 상호작용을 아우르는 포괄적인 개념입니다.이러한 포괄적인 기능을 통해 컨테이너는 안정적이고 효율적인 방식으로 애플리케이션을 구동할 수 있습니다.컨테이너 런타임의 본격적인 발전은 2013년 Docker의 등장과 함께 시작되었습니다.Docker는 컨테이너 기술을 대중화하고 개발자 친화적인 도구와 생태계를 구축했지만, 그 복잡한 아키텍처로 인해 경량화된 런타임이 필요했습니다.관련해서 Docker는 2016년 containerd를 오픈소스로 분리하여 보다 가볍고 간결한 런타임을 제공했고, Kubernetes와의 긴밀한 통합을 통해 클라우드 네이티브 환경의 사실상 표준으로 자리 잡았습니다.컨테이너 런타임은 클라우드 네이티브 애플리케이션의 효율적인 배포와 관리를 가능하게 합니다.특히 OCI(Open Container Initiative)와 CRI(Container Runtime Interface) 표준은 런타임 간 호환성과 상호 운용성을 높여 컨테이너 생태계의 표준화와 유연성을 강화했습니다.containerd와 같은 경량 런타임은 자원 활용의 효율성과 성능 최적화를 통해 대규모 분산 시스템에서 뛰어난 안정성과 확장성을 제공합니다.컨테이너 런타임의 표준화 OCI와 CRI• None OCI(Open Container Initiative): 2015년 Docker와 주요 업체들이 설립한 오픈소스 프로젝트로, 컨테이너 형식과 런타임에 대한 표준을 정의합니다. OCI 이미지 스펙과 OCI 런타임 스펙을 통해 Docker, containerd, CRI-O 등 다양한 런타임에서 동일한 이미지를 실행할 수 있습니다.• None CRI(Container Runtime Interface): Kubernetes가 컨테이너 런타임과 통신하기 위한 표준 인터페이스로, containerd와 CRI-O는 CRI를 구현하여 Kubernetes와 원활히 통합

안녕하세요. 현대자동차 모바일 앱과 커넥트 문구 담당자 UX 라이터 김무성 연구원입니다.안녕하세요. 2025년 UX 라이팅에 대해 글을 작성할 인포테인먼트UX개발팀 국문 UX 라이터 김무성 연구원입니다. 올해는 UX 라이팅의 개념을 파헤친다는 목표를 가지고 글을 올리고자 합니다. UX 라이팅의 기초를 파헤치기 위한 목적으로 작성하는 것이니, 편안한 마음을 지니고 읽어주시면 됩니다. UX 라이터의 본분에 따라 최대한 이해하기 쉬운 표현으로 변경하여 작성할 예정이니, 가벼운 마음을 지니고 읽어주세요. :D정확한 호명, UX 라이팅을 위한 첫 걸음현대문학, <김춘수 시 전집>내가 그의 이름을 불러 주기 전에는 그는 다만하나의 몸집에 지나지 않았다.내가 그의 이름을 불러 주었을 때그는 나에게로 와서꽃이 되었다.김춘수 <꽃>위에 인용한 시는 한국의 정규과정을 거쳤다면 누구나 다 아는 시예요. 바로 김춘수 시인의 <꽃>이죠. 그러면 대중적인 시, <꽃>을 UX 라이팅 설명하는데, 사용하는 이유는 무엇일까요? 간단해요. '호명'이라는 측면에서 직무적 역할이 어떻게 정의되느냐를 살펴보고 싶어서죠. 간단하게 말하면 직무를  '어떻게 호명' 하냐에 따라서 'R&R'이 적용된다는 측면으로 접근하자는 거죠. 무언가를 명명한다는 것은 중요한 일이에요. 한 회사에서 특정한 직무를 부르는 용어가 없다면? 회사는 그 직무 담당자를 채용하지 않을 거예요. 이런 측면에서 '직무'가 명명 또는 호명되기 이전에는 특별한 의미를 갖지 못하게 돼요. 하지만 직무에 이름이 부여되고, 그 이름이 불리기 시작할 때, 회사라는 공간에 '새로운 직무'가 탄생하죠.몸짓에서 꽃으로 - Google I/O '17'탄생'이라는 거창한 단어를 바꿔보자면, 내부 구성원이 '의식'한다고 할 수 있어요.UX 라이팅은 2017년 Google I/O에서 공식적으로 명명되면서 가시화되었고,'게슈탈트 붕괴'처럼 호명을 통해 실재하지 않던 개념이 현실화되는 과정을 거쳤어요.Google I/O 2017UX 라이팅 또한 동일하게 탄생했어요. 해외에서는 2017년 Google I/O 에서 'UX 라이팅'이라는 이름이 명명되기 이전에는 UX에서 라이팅이라는 존재는 부각되지 않았어요. 누구나 다 할 수 있는 '글쓰기의 영역'에 속하게 된 거죠. 국내에서는 '토스'가 본격적으로 등장하기 전까지는 UX 라이팅은 누구도 관심을 주지 않았던 직무예요.이러한 의식이 발산하기 전까지는, <꽃>을 예로 들자면 회사 내에서 공공연하게 행해지던 UX 라이팅은 "하나의 몸짓에 지나지 않았"던 거죠.김춘수 시인의 <꽃>처럼, 2017년 Google I/O에서 행해진 UX 라이팅 호명은 가시적인 직무 세계 안으로 끌어들이는 역할을 하게 된 거예요. 또한, 낯설었던 것을 익숙하게, 친숙하게 만드는 효과도 있었요. UX가 널리 알려진 업무 세계에서 이제 UX 라이팅은 익숙한 정서와 관념의 등가물로 의미화되기 때문이죠. 하나의 예를 들어볼까요?"게슈탈트 붕괴(Gestaltzerfall)"요즘에도 대화를 나눠보면 게슈탈트 붕괴가 실존하는 이론이라고 생각하는 분들이 많아요. 하지만 게슈탈트 붕괴는 사실 심리학적 용어가 아니에요. 이론도 아니죠. 게슈탈트 붕괴는 일종의 '도시괴담'인데요. 일본 인터넷 커뮤니티에서 원래 게슈탈트(Gestalt)라는 독일의 명사, 심리학에서 게슈탈트라는 용어가 가진 의미를 확대해석해 창조된 은어예요. 현대적으로 설명하면 '신조어'라고 보는 것이 맞죠. 그럼에도 한 번 통용되기 시작하자 많은 사람들이 실재하는 용어처럼 사용하기 시작했어요. 지금도 네이버에 해당 용어를 검색하면 무수히 많은 자료가 나와요. 마치, 이것이 실존하는 이론처럼 말이죠. 이처럼 친숙한 용어가 되는 시점부터, 우리는 비가시화된 대상을 가시화시키는 효과를 가지게 되죠. 게슈탈트 붕괴는 호명의 대표적인 사례라 할 수 있어요.국내에서의 첫 호명 - Toss UX 라이팅"그러면 왜 이렇게 UX 라이팅을 말하려고 애쓰는 걸까요?"토스가 국내에서 UX 라이터를 공식적으로 호명하고 채용함으로써 UX 라이팅의 선두주자가 되었고,이는 국내 UX 라이팅의 직무 정체성과 R&R을 명확히 하는 계기가 됐어요.Waldo Carr의 "Who Is the UX Writer?"앞서 말했던 호명과 이어지는 데요. 게슈탈트 붕괴 사례처럼 잘못된 호명은 어느 덧 우리 인지 속에 자리하고, 반복해서 사용하게 될 지도 몰라요. 그러다보면 어느 새 인지적 일관성이 생겨, 올바른 개념을 주입하려할 때, 받아들이지 않는 현상도 발생하게 되는 거죠. 그만큼 호명이 개념적 작동이라는 측면에서 중요한 요소라는 거죠.호명은 단순히 직무적 명명만 의미하지 많아요. 인지적 차원에서 살펴보면, 개인에게 특정한 자극이 전달되면 관련된 정체성이 명확해지고, 그것을 기준으로 내집단과 외집단을 구분하게 돼요. 결과적으로 UX 라이팅을 하는 집단과 하지 않는 집단으로 나뉘어지게 되고, 강렬한 소속감이 생기게 돼요."그렇게 토스가 국내에서는 UX 라이팅의 선두주자로 탄생하게 됐어요."토스가 대표 사례라 할 수 있고, 토스는 UX 라이터라는 직무를 채용함으로써, 우리는 타 금융사와 다르게 사용자를 우선하는 문구를 작성하고 있다는 내집단에 대한 소속감을 증가시킬 수 있었어요. 또한, 외집단과의 구별짓기를 통해, 토스는 'UX 라이팅을 하는 집단', '유일하게 할 수 있는 집단'이라는 타이틀을 거머쥐게 되는 거죠."즉, 국내는 토스가 UX 라이터의 R&R을 호명하기 시작했다."그러면 토스가 호명하기 이전까지 국내에 UX 라이터는 없었을까요? 아니에요. 우리가 흔히 하는 대기업들은 UX 라이터의 역할을 하는 직무가 있었어요. 다만, UX 라이터로 호명하지 않았을 뿐이죠. 그리고 호명하지 않았기 때문에, 여전히 그들의 R&R은 혼란스러운 상태로 남아있죠.여전한 UX 라이팅 가치 인식의 부재"이 혼란스러움이 국내 시장에 UX 라이팅이 자리하지 못하게 만들었다."토스가 UX 라이팅의 선도적 역할을 하고 있지만,여전히 국내에서는 UX 라이팅의 정확한 범주와 중요성 그리고 UX 라이터의 역할과 가치에 대한 인식 개선이 필요해요.UX 라이팅과 혼동하는 직무토스는

안녕하세요. 모바일실 iOS팀에서 iOS Engineer로 일하고 있는 Elon이에요.제가 속한 모바일실은 당근에 전사적으로 필요한 기능을 개발해요. CI/CD, 애널리틱스, 실험 플랫폼, 딥링크 시스템 등을 직접 개발 및 관리하며, 앱 개발에 필요한 플랫폼 엔지니어링을 담당하고 있어요. 이러한 플랫폼 엔지니어링에는 iOS 엔지니어분들의 개발 생산성을 높이기 위한 Swift Macro를 개발하는 것도 포함되는데요.이 글에서는 Curosr와 함께 TDD를 통해 Swift Macro를 구현해 보면서, 실제 프로덕션에 적용할 수 있는 신뢰도 높은 코드를 작성하는 방법에 대해 이야기하려고 해요.TDD에 들어가기에 앞서당근 앱의 토대를 쌓아 올리셨던 iOS 엔지니어분들은 모두 당근 초기부터 TDD(Test Driven Development)를 진행했어요. 그래서 단순 View를 제외하면 현재까지도 iOS 당근 앱에선 테스트 코드가 없는 곳을 찾아보기 어렵죠. 기존 개발 환경이 이러하다 보니 iOS 챕터에 합류한 엔지니어분들도 모두 테스트 코드를 작성하는 걸 당연하게 생각해요. 테스트 코드가 없으면 Pull Reqeust를 올리지 않을 정도예요. 전 당근에 입사하기 전까지는 iOS 앱 개발에서는 테스트 코드를 작성해 본 경험이 없었는데요. 그랬던 저도 지금은 테스트 코드를 수월하게 작성해요. Swift Macro와 같이 처음 접하는 기술을 도입할 때도 자연스럽게 TDD로 시작해보고 있죠.Swift Macro는 Swift로 작성된 코드를 SwiftSyntax로 파싱한 후, Swift Syntax Tree에서 원하는 코드를 탐색해 가져와 사용하는 방식이에요. 그래서 매크로를 만들기 위해서는 먼저 원하는 형태의 매크로 인터페이스와 매크로 적용 후 생성될 코드 형태를 미리 설계해야 하는데요. 테스트 작성 시 일반적으로 사용하는 패턴인 Given-When-Then 패턴에서 매크로 인터페이스는 Given, 매크로가 적용되어 생성된 코드는 Then에 해당돼요. 따라서 자연스럽게 테스트코드를 먼저 작성하고 구현을 개발하는 TDD 방식에 적합하다고 볼 수 있어요.TDD는 아래와 같은 세 단계를 하나의 사이클로 반복하면서 기능을 완성해 나가요. Swift Macro의 경우, 일반적으로 iOS 앱 개발에서 접할 일이 거의 없는 SwiftSyntax API를 사용해야 해요. 그래서 SwiftSyntax 레퍼런스 문서와 Swift AST Explorer 사이트를 오가며 필요한 Syntax를 찾는데 많은 시간을 소비하게 되는데, 이 과정을 Cursor와 함께 한다면 많은 시간을 절약할 수 있어요.🔴 Red: 원하는 기능의 테스트 코드를 작성하고 테스트를 실행하여 실패하는 것을 확인해요.🟢 Green: 테스트를 통과할 수 있도록 최대한 빠르게 동작할 수 있는 코드를 구현해요.🟡 Refactor: 빠르게 작성한 코드에서 중복된 코드 등을 제거하고 유지보수하기 쉽도록 가독성 좋게 리팩토링해요.이번 글에서는 예시로 Swift에서 JSON 파싱을 위해 Codable의 CodingK