본문 바로가기

전체 글81

뒤처진다는 불안을, 매주 듣는 팟캐스트로 바꿨다 회사 AX TF 활동을 하면서 "나만 AI 동향을 모른다"는 불안이 계속 따라다녔다. DevOps 쪽도 매주 새 릴리스가 쏟아지는데 따라가지 못하고 있었다. 의지로 풀면 오래 못 간다는 걸 알기에 이번에는 구조로 풀기로 했다. 내 습관에 맞춰 동향을 알아서 모아 주고, 요약하고, 들려주는 개인 파이프라인 tech-digest 를 만든 기록이다. 만들다 보니 비용을 0원으로 묶는 설계와, AI 를 실제로 굴려 보며 "아, 그래서 다들 그 말을 했구나" 싶었던 순간들이 덤으로 남았다.Intro정보원을 하나하나 찾아 들어가지 않는다. 피드 25개를 주 1회 수집해 Gemini 로 서술형 한국어 다이제스트를 만들고, NotebookLM 이 바라보는 Google Docs 를 갱신해 오디오 오버뷰(팟캐스트)로 듣는.. 2026. 10. 22.
내가 만든 이미지 tar 는 무슨 포맷일까? docker, podman, skopeo 를 직접 돌려보며 정리한 노트 CKAD를 살며시 준비하다가 "이미지를 OCI 또는 Docker 포맷으로 저장하라" 는 한 줄에서 멈칫했다. docker save 는 수없이 쳐봤는데, 그 결과물이 어느 포맷인지 설명하라고 하면 말이 막혔다. 그래서 세 도구를 로컬에서 직접 돌려 tar 를 하나씩 까봤고, 그 과정에서 예상과 다른 결과를 세 번 만났다. 이 글은 그 실험 기록과, 이후 실무에서 꺼내 쓰려고 모아둔 명령어 노트다.Introdocker 는 상주 데몬 위에서 빌드, 실행, 전송, 네트워크, 볼륨까지 다 하는 올인원 도구다. podman 은 거의 같은 CLI 를 데몬 없이 사용자 권한으로 돌린다. skopeo 는 이미지를 실행하지 않고 옮기고 변환만 한다.포맷은 도구 이름이 아니라 tar 안의 파일로 판단한다. oci-layou.. 2026. 10. 12.
함께 자라기에 나도 포함하기 얼마 전, 좋은 동료와 좋은 어른이 되고 싶다는 회고를 썼다. 팀에 마음을 쓰고 사람들과 함께 자라는 일이 왜 내게 중요한지 정리한 글이었다. 그런데 쓰고 나서야 돌아보게 됐다. 그동안 나는 정작 나 자신을 얼마나 돌봤을까.지난 금요일부터 주말까지 많이 힘들었다. 솔직히 나도 모르게 번아웃이 온 것 같았다. 내가 더 뛰어야지, 내가 다 알고 있어야지. 애써 마음 쓴 프로젝트가 잘못되는 걸 보기 힘들어서, 괜찮은 척 웃으면서 계속 달렸다. 믿고 의지할 사람들이 생겼는데도 혼자 책임지던 습관은 그대로였다. 솔직히 혼자 해결할 때의 쾌감도 있었다.금요일 퇴근 전, 라이언과 단둘이 이야기하다 처음으로 울었다. 갑자기 눈물이 나서 두서없이 말을 꺼냈는데, 오래전부터 혼자 얼마나 고생했을지 말하지 않아도 느껴진다고.. 2026. 10. 5.
좋은 어른이 되어간다는 것 요즘 팀에 이런저런 이슈가 많았다. 나는 나대로 고민이 많았고, 그 고민을 한 번은 글로 정리해두고 싶었다. 거창한 리더십 이야기는 아니다. 감투도 없는 내가 왜 자꾸 팀의 일에 마음을 쓰는지, 그게 과한 건 아닌지에 대한 생각 정리에 가깝다.시 한 편에서 시작한 생각자신 안에 자리한 악의 능력을끊임없이 상기시키는 자가 있다자신 안에 커오는 선의 능력을쉬임 없이 고무시키는 자가 있다그는 어느 쪽인가나는 어느 쪽인가악은 선을 삼켜야만 연명할 수 있으니선은 악에 맞서야만 커나갈 수 있으니그러니 선한 이여악에게 자신을 내어주지 마라위선을 떨치고 선함을 지켜라진실로 선한 사람은 나쁜 사회에서도자기 영혼을 잃지 않고 좋은 삶을 사는 사람아무리 작아도 선한 존재는그 자체로 어두운 세상의 등불이니아무리 무력한 듯해도.. 2026. 10. 1.
앱은 살아 있는데 서비스 간 호출만 401: OpenBao 가 발급하는 서비스 신원 JWT 를 따라가 보니 앞 글에서는 사람과 ESO 가 OpenBao 에 들어오는 문(인증)과 들어와서 닿는 범위(정책)를 봤다. 팀 책임님과 공통 인증 게이트웨이와 공통 프레임워크를 설계하면서 가장 오래 붙잡은 질문은 따로 있었다. "서비스가 서비스를 부를 때 무엇으로 자기를 증명하나." 사람 로그인은 Keycloak JWT 를 게이트웨이에서 검증하면 됐지만, 서비스 간 호출에는 별도의 신원이 필요했다. 우리는 그 신원 JWT 를 OpenBao 가 발급하게 하고, 받는 쪽은 공통 프레임워크의 Resource Server 설정으로 검증하게 했다. 그 JWT 한 장이 만들어지기까지 AppRole, Identity, Agent 가 차례로 등장한다. 이 글은 함께 설계한 그 길을 다시 따라가며, 적용하고 나서 보인 빈틈까지 적는다.함.. 2026. 9. 27.
시크릿을 KV 에 넣었다고 끝이 아니었다: OpenBao 의 경계는 인증과 정책이 정한다 기존 프로젝트에서 OpenBao 는 나한테 "KV v2 에 값을 넣고 읽는 곳" 이었다. 토큰 하나를 설정 파일에 두고 HTTP 로 부르면 끝이었다. 팀을 옮기고 팀 내 책임님과 함께 여러 제품이 같이 쓰는 공통 인증 게이트웨이와 백엔드 공통 프레임워크를 만들게 됐다. 제품마다 시크릿을 같은 방식으로 받아 가고, 서비스 간 호출에서 "누가 보냈는가" 를 같은 규칙으로 증명하려면 그 밑단에 공용 OpenBao 를 두어야 했다. 그래서 KV 말고도 인증 방식과 제품별 정책, AppRole 과 Agent 까지 책임님과 같이 설계하고 bootstrap 스크립트로 적용했다. 적용한 뒤에는 설계대로 올라갔는지 kubectl 과 스크립트를 한 줄씩 다시 읽으며 점검했고, 그때 멈칫한 곳도 함께 적는다. 이 글은 그중.. 2026. 9. 27.