안녕하세요! 그로스로그 입니다!😊 🌱
PR을 올리면 AI가 알아서 리뷰를 달아주고, 코드 분석은 다른 AI에게 통째로 맡기고, Dockerfile 없이도 컨테이너가 빌드됩니다. 4기 3회차 세 편입니다.
4기 3회차는 2025년 10월 말입니다. 세 편 모두 사람이 하던 일을 도구에 넘기는 이야기인데, 재미있는 건 셋 다 어디까지 넘기고 어디부터는 남겨둘지를 함께 적었다는 점이에요.
01
🐰 코드리뷰 AI 툴 코드래빗(CodeRabbit)
이지현 님
저장소에 연결해두면 PR이 올라올 때마다 자동으로 리뷰 코멘트를 달아주는 도구를 써본 기록입니다.
설정 파일 하나로 한국어 리뷰와 말투까지 정할 수 있다는 걸 실제 설정값으로 보여줍니다.
받은 결과를 세 장면으로 나눠 캡처했어요. 코드 요약 / 파일별 요약 / 흐름 시각화요.
이 글이 왜 필요했는지가 첫 문장에 있습니다.
혼자 하면 리뷰해줄 사람이 없다는 문제요. 팀에서는 당연하게 받는 것이 혼자일 때는 통째로 사라집니다. 그 빈자리를 도구로 메운 기록입니다.
조금 더 들어가 보면
👀 코드 리뷰가 실제로 하는 일은 넷입니다
자동화 이야기를 하려면 먼저 원래 무엇을 하던 일인지 나눠봐야 합니다. 코드 리뷰는 한 덩어리처럼 보이지만 안에 성격이 다른 네 가지가 섞여 있어요.
· 규칙 검사 — 이름 규칙, 들여쓰기, 안 쓰는 변수. 기계가 훨씬 잘합니다
· 결함 탐지 — null 가능성, 경계값, 예외 처리 누락. 기계가 꽤 잘합니다
· 설계 판단 — 이 책임이 여기 있는 게 맞는가. 기계가 어려워합니다
· 맥락 공유 — 이 코드가 왜 이렇게 됐는지 팀이 알게 되는 것. 기계가 못 합니다
앞의 두 개는 넘기고, 뒤의 두 개는 남기는 것이 지금 도구들의 현실적인 자리입니다. 그리고 그렇게 나누면 사람이 뒤의 두 개에 시간을 더 쓸 수 있게 되죠.
혼자 하는 프로젝트라면 앞의 두 개만 받아도 큰 이득입니다. 사실 혼자일 때 가장 많이 놓치는 게 그 둘이거든요.
⚙️ 설정 파일 한 장이 하는 일
이 글에서 실용적인 대목이 설정 파일입니다. 특히 두 줄이요.
language: "ko-KR" — 리뷰를 한국어로 받겠다는 것입니다. 사소해 보이는데, 실제로는 도입 여부를 가르는 항목입니다. 영어로 오는 코멘트는 읽는 데 시간이 더 들고, 시간이 더 들면 결국 안 읽게 되거든요. 읽히지 않는 리뷰는 없는 것과 같습니다.
profile: "chill" — 말투를 부드럽게 하겠다는 설정입니다. 이것도 생각보다 중요합니다. 자동 리뷰는 모든 PR에 빠짐없이 달립니다. 지적이 강한 어조로 매번 쌓이면 사람이 지쳐요. 결국 코멘트를 안 보게 되고, 도구는 켜져 있는데 아무도 안 읽는 상태가 됩니다.
auto_review: enabled: true 아래의 drafts: false도 짚어둘 만합니다. 아직 작업 중인 초안 PR에는 리뷰를 안 달겠다는 뜻이에요. 완성되지 않은 코드에 지적이 쏟아지면 소음만 늘어납니다.
설정 파일 한 장이 사실은 "언제, 어떤 톤으로, 무엇에 대해 말을 걸 것인가"를 정하는 문서인 셈입니다.
🔁 자동 리뷰가 흔히 실패하는 자리
써본 사람들이 공통으로 겪는 지점을 하나 붙이겠습니다. 코멘트가 너무 많아지는 것이요.
기계는 지치지 않아서, 파일 50개짜리 PR에 코멘트 80개를 답니다. 그중 진짜 중요한 건 서너 개인데, 나머지에 묻힙니다. 그러면 사람은 전부 훑기를 포기하고, 결국 아무것도 안 고칩니다.
그래서 실무에서는 이렇게 다룹니다.
· PR을 작게 유지합니다 — 리뷰 도구 문제가 아니라 원래 좋은 습관입니다. 작은 PR은 사람도 기계도 잘 봅니다
· 심각도로 거릅니다 — 대부분의 도구가 제안의 등급을 나눠 표시합니다. 낮은 등급은 접어두고 봅니다
· 반복되는 지적은 규칙으로 내립니다 — 같은 지적이 매번 나오면 그건 리뷰가 아니라 린터 규칙으로 고정할 일입니다
세 번째가 특히 중요합니다. 같은 말을 반복해서 듣는 상태는 자동화가 덜 된 상태예요.
🧭 그래서 남는 건 판단입니다
저자가 마지막 문단에 정확히 적어뒀습니다.
"대신 체크" 와 "도우미" 라는 단어 선택이 정확합니다. 결정을 대신한다고 쓰지 않았어요.
AI 리뷰는 제안을 만들 뿐 머지 버튼을 누르지 않습니다. 어떤 제안을 받고 어떤 제안을 무시할지는 여전히 사람 몫이고, 그 판단이 곧 그 코드베이스의 기준이 됩니다. 자동화가 늘어날수록 남은 판단의 밀도가 높아지는 것이죠.
🔒 붙이기 전에 확인할 것 하나
이런 도구를 저장소에 연결할 때 한 번은 짚고 넘어가야 하는 게 있습니다. 코드가 밖으로 나간다는 것이요.
저장소에 앱을 설치하고 PR 권한을 주면, 바뀐 코드가 그 서비스로 전송돼 분석됩니다. 개인 학습용 저장소라면 대개 문제가 없지만, 상황에 따라 확인해야 할 것이 생깁니다.
· 저장소에 비밀값이 들어 있지 않은지 — 키나 토큰이 코드에 섞여 있으면 그것도 같이 나갑니다. 사실 이건 도구를 붙이든 안 붙이든 정리해야 할 문제고요
· 비공개 저장소에 붙일 때의 정책 — 소속이 있는 프로젝트라면 외부 서비스에 소스를 보내도 되는지가 먼저입니다
· 권한 범위 — 읽기만 필요한지, 코멘트를 달기 위해 쓰기까지 필요한지 설치할 때 나옵니다
저자가 개인 프로젝트에서 쓴 기록이라는 점이 여기서 중요합니다. 도입 조건이 명확한 자리에서 써본 것이라, 읽는 사람도 자기 상황이 그 조건에 맞는지 바로 판단할 수 있어요.
🧩 PR을 리뷰 단위로 만드는 일
이 도구를 붙이고 나면 자연스럽게 생기는 변화가 하나 있습니다. PR을 의식하게 된다는 것이요.
혼자 하는 프로젝트에서는 대개 브랜치를 안 나눕니다. 바로 커밋하고 바로 올려요. 그런데 리뷰를 받으려면 PR을 열어야 하고, PR을 열려면 "여기까지가 한 덩어리" 를 정해야 합니다.
이게 생각보다 큰 습관입니다.
· 작업 단위가 생깁니다 — "로그인 기능"처럼 묶이니 나중에 되돌리기도 쉬워집니다
· 설명을 쓰게 됩니다 — 무엇을 왜 바꿨는지 한 줄이라도 적게 되고, 그게 그대로 기록이 됩니다
· 자기 코드를 다시 봅니다 — PR 화면의 변경 목록을 보면 커밋할 때 안 보이던 게 보입니다
리뷰 도구가 주는 이득의 절반이 사실 여기서 나옵니다. 코멘트를 받기 전에, PR을 만드느라 자기 작업을 정리하게 되거든요.
혼자 하는 프로젝트에서 팀의 습관을 하나 들여오는 셈입니다. 저자가 "이게 맞는건지 의구심이 든다"고 쓴 그 자리에, 리뷰 코멘트만이 아니라 이 습관도 같이 들어옵니다.
📉 AI 리뷰가 못 보는 것
균형을 위해 한계도 짚어두겠습니다. 이런 도구가 구조적으로 못 보는 게 있습니다.
바뀐 부분만 봅니다. PR에 담긴 변경 사항이 입력이니까요. 그래서 "이 기능을 여기에 두는 게 맞나", "이미 비슷한 게 저쪽에 있는데 중복 아닌가" 같은 판단은 어렵습니다. 프로젝트 전체를 알아야 나오는 이야기거든요.
지금 안 한 것을 못 봅니다. 빠진 예외 처리는 잡아도, 아예 안 만든 기능이나 안 쓴 테스트는 지적할 대상이 없습니다.
왜 이렇게 했는지 모릅니다. 일부러 그렇게 짠 코드에도 똑같이 지적이 붙습니다. 그래서 반복적으로 무시하게 되는 제안이 생기고, 그건 설정으로 걸러두는 게 맞아요.
그래서 이 도구는 "빠진 것 찾기"에 강하고 "방향 정하기"에 약합니다. 저자가 "도우미"라고 부른 자리가 정확히 그 범위입니다.
📝 원문에서는 이렇게 씁니다
프로젝트 루트에 이 파일 하나를 두는 것으로 시작합니다.
language: "ko-KR" # 한국어 설정 reviews: profile: "chill" # 부드러운 말투 설정 high_level_summary: true # PR 전체 요약 review_status: true auto_review: enabled: true drafts: false # 초안 PR에는 달지 않음 chat: auto_reply: true
그리고 받은 결과를 셋으로 나눠 보여줍니다. 코드 요약, 파일별 요약, 그리고 흐름 시각화요.
세 번째가 흥미롭습니다. 함수 호출 관계와 모듈 간 관계를 그림으로 보여주는 건데, 바뀐 코드를 읽는 게 아니라 바뀐 구조를 보는 것이거든요. 리뷰어가 가장 먼저 알고 싶은 것이 대개 그것입니다.
큐레이터 노트
혼자 하는 프로젝트에서 사라지는 것을 도구로 메운 기록이라 뽑았습니다. "이게 맞는건지 의구심이 든다"는 첫 문장이 이 글의 이유를 다 설명해요.
무엇보다 설정 파일을 실제 값으로 보여준 것이 좋았습니다. 도구를 소개하는 글은 많은데, 붙이고 나서 무엇을 정해야 하는지까지 알려주는 글은 드뭅니다. 읽는 사람이 그대로 복사해 쓸 수 있어요.
02
🤝 Claude Skills 을 활용한 Codex 코드 리뷰
강단 님
코드 분석을 다른 AI에게 통째로 위임하고, 자기는 명령만 실행하는 구조를 만든 기록입니다.
목적이 두 줄로 적혀 있어요. "AI 코드 리뷰 자동화, 토큰 효율 극대화" 요.
숫자가 전부 붙어 있습니다. 토큰 10,000 → 700, 리뷰 시간 30분 → 5분.
그리고 마지막에 실사용 후기로 한계도 적었습니다. "여기서 병렬의 이점을 상실"이라고요.
앞의 글이 도구를 붙이는 이야기였다면, 이 글은 일을 어떻게 나눌지 설계한 이야기입니다.
한 도구가 다 하게 두지 않고, 분석은 A에게, 실행은 B에게, 실제 파일 수정은 C에게 맡겼어요. 그리고 그 사이마다 사람이 볼 수 있는 지점을 남겼습니다.
조금 더 들어가 보면
🧮 왜 분석을 밖으로 내보냈는가
문제 상황을 저자는 이렇게 적었습니다.
여기서 비용이 어디서 나는지 짚어야 합니다. 파일을 읽는 데서 납니다. 분석하려면 코드를 다 봐야 하고, 본 만큼 값이 붙어요.
그래서 이 구조는 읽는 일 자체를 밖으로 내보냅니다. 밖에 있는 도구가 파일을 읽고 분석하고 결과만 돌려주면, 안쪽은 "이걸 시켜라"와 "결과를 받아라"만 하면 됩니다. 저자의 계산이 이겁니다.
| 직접 분석 | 위임 | |
|---|---|---|
| 파일 읽기 | 5,000 | 0 (밖에서) |
| 분석 | 3,000 | 0 (밖에서) |
| 제안 | 2,000 | — |
| 명령 실행 | — | 100 |
| 결과 읽기 | — | 500 |
| 합계 | 10,000 | 600~700 |
94% 절감입니다. 그리고 여기서 더 큰 이득이 하나 붙어요. 기다리는 동안 다른 일을 할 수 있다는 것입니다. 밖에서 도는 작업이니 안쪽은 놀지 않아도 됩니다.
이건 2회차에서 본 작업 큐와 정확히 같은 발상입니다. 오래 걸리는 일을 다른 프로세스로 보내고 즉시 다음 일을 하는 것이요.
🛡️ 세 단계로 나눈 안전장치
이 글에서 가장 값어치 있는 부분은 사실 효율이 아니라 안전 설계입니다.
저자는 세 단계를 명시적으로 그었습니다.
1. 분석하는 쪽은 파일을 고치지 않습니다. 변경안을 diff 파일로만 남깁니다
2. 사람이 그 파일을 열어 볼 수 있습니다. 무엇을 어떻게 바꾸겠다는 것인지 그대로 나옵니다
3. "적용해줘"라고 해야 적용됩니다. 그리고 적용은 git apply가 합니다
왜 이렇게까지 나눴을까요. AI에게 코드 수정을 맡길 때 가장 무서운 건 "뭘 바꿨는지 모르게 바뀌는 것"이기 때문입니다. 파일을 직접 고치게 두면 변경 범위를 사람이 통제할 수 없어요.
diff를 중간 산출물로 두면 세 가지가 동시에 해결됩니다.
· 범위가 눈에 보입니다 — 어느 파일 몇 줄이 바뀌는지 목록으로 나옵니다
· 부분 적용이 가능합니다 — 마음에 드는 것만 골라 적용할 수 있습니다
· 되돌리기가 쉽습니다 — 적용 뒤에도 버전 관리 도구로 즉시 원복됩니다
"제안과 적용을 분리한다." 이건 AI 도구에만 해당하는 원칙이 아닙니다. 자동화된 마이그레이션, 일괄 수정 스크립트, 코드 생성기 전부 같습니다. 바로 고치게 두지 말고 고칠 내용을 먼저 내놓게 하는 것이요.
📉 그리고 한계를 적었습니다
이 글을 소개 글에서 판단 자료로 바꾸는 부분이 마지막의 "실사용 후기"입니다.
앞에서 자랑한 이점 두 개를 스스로 반박한 것입니다. 병렬성이 이점이라고 해놓고, 실제로는 중간에 확인을 요구해 멈추더라고요.
이게 자동화 일반의 오래된 문제와 닿아 있습니다. 사람을 완전히 빼지 않고 "가끔 확인만 하는" 자리에 두면, 그 사람은 계속 대기해야 합니다. 붙어 있어야 하는데 할 일은 없는 상태요. 그리고 문맥을 왔다 갔다 옮기는 데 드는 비용이 생각보다 큽니다. 저자가 "프롬프트 스위칭 비용"이라고 부른 게 그것이고요.
94% 절감이라는 숫자와 이 후기를 같이 읽어야 이 글이 완성됩니다. 토큰은 줄었는데 사람의 주의는 줄지 않았다는 것이니까요.
🔧 설명을 다시 쓴 것도 기록에 남겼습니다
또 하나 눈에 띄는 게 도구 정의를 개선한 대목입니다. 처음엔 설명이 "코덱스 실행" 한 줄이었는데, 나중엔 어떤 말을 들었을 때 이걸 써야 하는지를 예시로 적어뒀어요.
description: | 사용자가 다음을 요청할 때 사용: - "코덱스로 분석", "codex 실행" - "코드 리뷰", "버그 찾기"
"무엇을 하는가"가 아니라 "언제 쓰는가"로 바꾼 것입니다. 이건 함수 이름을 짓거나 API 문서를 쓸 때와 똑같은 문제예요. 읽는 쪽은 "이게 뭐 하는 건가"보다 "지금 이게 필요한가"를 먼저 판단하니까요.
작업 유형별로 모델과 강도를 나눈 표를 덧붙인 것도 같은 맥락입니다. 선택지를 주는 대신 고르는 기준을 함께 준 것이요.
👁️ 다른 눈으로 보게 하는 것의 값어치
이 구조에는 저자가 명시하지 않은 이점이 하나 더 있습니다. 리뷰하는 쪽과 코드를 쓴 쪽이 다르다는 것이요.
사람 리뷰에서도 같은 이야기를 합니다. 자기 코드는 자기가 못 봅니다. 방금 짠 논리는 머릿속에 그대로 남아 있어서, 읽을 때 코드가 아니라 기억을 읽게 되거든요. 그래서 빠진 조건이 안 보입니다.
AI도 비슷한 일이 일어납니다. 코드를 만든 쪽에게 그 코드를 검토시키면, 만들 때 쓴 전제를 그대로 들고 봅니다. 그 전제가 틀렸으면 검토에서도 안 걸려요.
그래서 만든 쪽과 보는 쪽을 다르게 두는 것 자체가 검토의 질을 올립니다. 저자가 토큰 절감을 이유로 택한 구조인데, 결과적으로 리뷰의 독립성까지 얻은 셈이에요.
이건 사람 팀에도 그대로 적용됩니다. 짠 사람이 스스로 검토 항목을 만들면 자기가 이미 신경 쓴 것들이 목록에 오릅니다. 체크리스트는 짠 사람이 아닌 쪽이 만드는 게 낫습니다.
📐 무엇을 기준으로 리뷰할지 미리 적어둡니다
이 기록에서 실무적으로 가장 바로 쓸 수 있는 부분이 리뷰를 시킬 때 넘긴 지시입니다.
저자는 그냥 "리뷰해줘"라고 하지 않았어요. 확인할 항목을 다섯 개로 적어 넘겼습니다. 타입 안정성, 이름 규칙, 코드 구조와 일관성, 잠재적 버그, 그리고 프로젝트 규칙 준수 여부요.
다섯 번째가 핵심입니다. 프로젝트 가이드라인 문서를 근거로 삼으라고 지시했거든요.
이게 왜 중요하냐면, 일반적인 기준으로만 보면 "우리 팀에서는 그렇게 안 하는데"가 나오기 때문입니다. 들여쓰기든 폴더 구조든 팀마다 다르고, 일반론으로 지적하면 매번 무시하게 됩니다.
프로젝트 규칙을 문서로 적어두고 그걸 근거로 검토하게 하면 그 문제가 사라집니다. 그리고 부수 효과가 하나 더 있어요. 규칙 문서를 실제로 관리하게 됩니다. 안 쓰면 낡는 문서인데, 리뷰가 그걸 계속 참조하니 갱신할 이유가 생기거든요.
앞서 이야기한 "자동화는 판단을 앞으로 옮긴다"가 여기서 구체적으로 나타납니다. 나중에 리뷰에서 할 지적을 미리 규칙으로 적어두는 것이요.
⏸️ "멈추고 물어보는" 자동화의 어려움
마지막 후기에서 저자가 짚은 문제를 조금 더 보겠습니다. 작업 중간에 계속 진행할지 확인을 받느라 병렬의 이점이 사라졌다는 대목이요.
이건 자동화 설계에서 오래된 딜레마입니다. 어디까지 물어보고 어디부터 알아서 할 것인가.
· 다 물어보면 — 안전한데 사람이 계속 붙어 있어야 합니다. 저자가 겪은 상황이요
· 안 물어보면 — 자리를 비울 수 있는데, 잘못된 방향으로 멀리 가버릴 수 있습니다
그래서 실무에서 쓰는 절충이 "되돌릴 수 있으면 묻지 않는다" 입니다. 파일을 고치는 일은 되돌릴 수 있으니 알아서 하게 두고, 되돌리기 어려운 일 — 원격에 밀거나, 배포하거나, 지우는 일 — 만 확인을 받는 것이죠.
저자가 만든 3단계 안전장치가 사실 그 방향으로 가는 길목에 있습니다. 변경안을 파일로 남겨두면, 적용은 나중에 몰아서 한 번에 검토할 수 있으니까요. 매 단계 묻는 대신 끝에서 한 번 보는 구조가 됩니다.
📝 원문에서는 이렇게 나눕니다
누가 무엇을 하는지 표로 정리했습니다.
명령 실행 — Claude :
codex apply 명령 실행파일 수정 — git apply : diff 파일을 실제 파일에 패치
검증 — Claude : 타입 체크, 결과 리포트
그리고 실제로 받은 리뷰 결과 중 하나가 이랬습니다.
타입 강화 제안 세 건과 나란히 오타 하나가 들어 있는 게 이 도구의 성격을 잘 보여줍니다. 큰 것과 작은 것을 가리지 않고 다 잡아주는 대신, 무엇이 중요한지는 사람이 정해야 합니다.
큐레이터 노트
효율을 숫자로 재고, 그 숫자를 스스로 반박한 기록이라 뽑았습니다. 토큰 10,000 → 700, 리뷰 시간 30분 → 5분이라는 수치가 있고, 그 아래에 "여기서 병렬의 이점을 상실"이라는 후기가 붙어 있어요.
「숫자로 확인했다」와 「단점이나 한계까지 적었다」가 한 글에 같이 있는 경우가 흔치 않습니다. 그리고 제안과 적용을 분리한 3단계 안전장치는 AI 도구를 붙이는 다른 자리에도 그대로 가져다 쓸 수 있는 설계예요.
03
📦 [CI/CD Study 1주차] 컨테이너를 빌드하는 다양한 방법
김경보 님
컨테이너 이미지를 만드는 방법을 다섯 갈래로 나눠 하나씩 직접 돌려본 기록입니다. Docker, Jib, Buildah, Buildpack, 그리고 Shipwright·Kaniko요.
왜 방법이 여러 개인지부터 짚습니다. 컨테이너 포맷이 개방형 표준이라 만드는 방법도 여럿일 수 있다는 것이요.
실습 환경의 제약까지 적었습니다. "빌다는 리눅스 커널 기능에 의존하기 때문에 mac 에서는 실습이 불가" 라고요.
앞의 두 편이 리뷰를 넘기는 이야기였다면, 이 글은 빌드 방식 자체를 갈아치우는 이야기입니다. 그리고 규모가 다릅니다. 스터디 1주차 분량인데 도구 다섯 개를 실제로 돌렸어요.
조금 더 들어가 보면
🧱 레이어를 알아야 나머지가 이해됩니다
이 글이 Docker부터 시작하면서 레이어를 먼저 설명한 게 순서상 정확합니다. 뒤의 도구들이 전부 이 개념 위에서 차별화하거든요.
컨테이너 이미지는 통짜 파일이 아니라 변경분을 쌓아 올린 층입니다. 기본 이미지 위에 패키지를 깔면 한 층, 소스를 복사하면 또 한 층이요.
여기서 두 가지가 따라옵니다.
· 캐시가 됩니다 — 저자가 짚은 대로, 두 번째 빌드부터는 안 바뀐 층을 그대로 재사용합니다
· 순서가 성능을 정합니다 — 위층이 하나 바뀌면 그 아래 전부 다시 만들어야 합니다
두 번째가 실무에서 크게 작용합니다. Dockerfile에서 소스 복사를 위에 두고 의존성 설치를 아래에 두면, 코드 한 줄만 고쳐도 라이브러리를 매번 다시 깝니다. 반대로 두면 의존성 층이 캐시에 남아 빌드가 몇 배 빨라져요.
"자주 바뀌는 것을 뒤에 둔다." 레이어 구조를 알면 저절로 나오는 규칙이고, 모르면 절대 안 나오는 규칙입니다.
☕ Dockerfile을 안 쓰는 길 — Jib
Jib이 흥미로운 이유는 Dockerfile도, Docker 데몬도 없이 이미지를 만든다는 데 있습니다. 빌드 도구의 플러그인으로 들어가서, 프로젝트를 빌드하는 김에 이미지까지 만들어 저장소로 바로 올려요.
저자가 그린 두 흐름의 차이가 이겁니다.
· Docker — 도커파일 작성 → 이미지 빌드 → 저장소에 푸시 (세 단계)
· Jib — 프로젝트 빌드와 동시에 이미지 생성·푸시 (한 단계)
이게 왜 이득이냐면, 자바 애플리케이션의 구조를 도구가 이미 알고 있기 때문입니다. 의존 라이브러리, 리소스, 내가 짠 클래스를 각각 다른 층으로 나눠 담습니다.
여기서 캐시 효과가 극대화됩니다. 라이브러리는 거의 안 바뀌고 내 코드는 매번 바뀌는데, 층이 나뉘어 있으면 바뀐 층만 다시 올라갑니다. 통짜로 담았다면 매번 수백 MB를 다시 밀어야 했을 거예요.
그리고 Docker 데몬이 필요 없다는 점이 CI 환경에서 큽니다. 빌드 서버 안에서 컨테이너를 만들려면 보통 데몬에 접근할 권한을 줘야 하는데, 그 권한이 사실상 그 기계 전체에 대한 권한이라 보안상 꺼려지는 자리거든요.
🔓 권한을 줄이는 길 — Buildah와 Podman
저자가 Docker와 대비해 정리한 대목이 이 글에서 가장 실무적입니다.
Podman, Buildah — 각각 특화된 프로젝트로 분리. 루트 권한 및 데몬이 필요 없음
Docker는 백그라운드에 항상 떠 있는 데몬이 루트 권한으로 돌면서 모든 일을 합니다. 편한 구조인데, 그 데몬과 대화할 수 있으면 사실상 그 기계의 주인이 됩니다.
Podman과 Buildah는 이걸 데몬 없이, 일반 사용자 권한으로 하도록 나눴습니다. 명령을 내리면 그 명령이 직접 일을 하고 끝나요. 그리고 실행·빌드·전송이 각각 다른 도구로 분리돼 있습니다.
하나가 다 하는 구조에서 나눠서 하는 구조로 간 것입니다. 이번 회차의 앞 두 편이 한 일과 같은 방향이에요. 강단 님이 분석·실행·적용을 셋으로 나눈 것처럼요.
저자가 실습 제약을 적어둔 것도 이 맥락에서 나옵니다. Buildah는 리눅스 커널 기능에 직접 기대기 때문에 다른 운영체제에서는 그대로 안 돌아갑니다. 데몬이라는 중간층을 없앤 대가예요. 중간층은 비용이면서 동시에 이식성이기도 합니다.
⚖️ 다섯 갈래를 한 표로 보면
글 전체를 정리하면 이렇게 됩니다. 무엇을 없애고 무엇을 남기느냐로 갈립니다.
| 방법 | 사람이 쓰는 것 | 없애는 것 | 잘 맞는 자리 |
|---|---|---|---|
| Docker | Dockerfile | — | 표준·자료가 가장 많음 |
| Jib | 빌드 설정 | Dockerfile·데몬 | 자바 프로젝트, CI |
| Buildah | 셸 명령 | 데몬·루트 권한 | 권한 제약이 있는 환경 |
| Buildpack | (없음) | Dockerfile 전체 | 언어 표준 구성을 따르는 앱 |
| Kaniko 등 | 클러스터 설정 | 로컬 빌드 환경 | 클러스터 안에서 빌드 |
아래로 갈수록 사람이 적게 쓰고, 대신 도구의 규칙을 따라야 합니다. Buildpack은 아예 아무것도 안 써도 되는 대신, 프로젝트가 그 도구가 아는 형태여야 해요.
이건 자동화의 일반적인 맞교환입니다. 손을 덜 대는 만큼 통제를 내놓습니다. 어느 쪽이 맞는지는 그 프로젝트가 얼마나 표준적인가에 달려 있고요.
🧾 Buildpack — 아무것도 안 쓰는 쪽 끝
표의 아래쪽 두 개를 조금 더 보겠습니다. 방향이 선명해지거든요.
Buildpack은 프로젝트를 들여다보고 무슨 언어로 만든 무엇인지 스스로 알아냅니다. package.json이 있으면 노드 프로젝트로, pom.xml이 있으면 자바 프로젝트로 보고 필요한 런타임과 의존성을 알아서 담아요. 사람은 아무것도 안 씁니다.
편의만 있는 건 아닙니다. 진짜 이득은 보안 갱신에 있어요. Dockerfile로 기본 이미지를 고정해두면 그 이미지에 취약점이 나왔을 때 프로젝트마다 찾아다니며 고쳐야 합니다. Buildpack 방식은 기반을 갈아 끼우고 다시 빌드하면 되니까, 수백 개 서비스의 기반을 한 번에 올릴 수 있습니다.
대가는 명확합니다. 표준에서 벗어난 프로젝트는 인식이 안 됩니다. 특이한 빌드 절차가 있거나 시스템 패키지를 따로 깔아야 하면 결국 Dockerfile로 돌아가야 해요.
🏗️ Kaniko — 빌드를 클러스터 안으로
마지막 갈래는 문제의 성격이 조금 다릅니다. 어디서 빌드할 것인가요.
CI 파이프라인이 쿠버네티스 위에서 돈다면, 이미지를 만드는 일도 그 안에서 일어나야 합니다. 그런데 앞에서 짚었듯 컨테이너 안에서 컨테이너를 만들려면 보통 호스트의 데몬을 빌려야 하고, 그건 격리를 스스로 뚫는 일입니다.
Kaniko 계열은 이 문제를 특권 없이, 사용자 공간에서 레이어를 직접 만들어 푸는 쪽입니다. Dockerfile은 그대로 쓰면서 만드는 방식만 바꾸는 것이죠.
그래서 다섯 갈래가 각각 다른 제약에서 나왔다는 게 드러납니다. 자바 프로젝트라서(Jib), 루트 권한을 못 줘서(Buildah), 표준 구성이라서(Buildpack), 클러스터 안이라서(Kaniko)요. 도구가 여러 개인 건 취향 문제가 아니라 제약이 여러 개이기 때문입니다.
🧭 표준이 있어서 갈아탈 수 있습니다
이 글이 맨 앞에 개방형 표준 이야기를 놓은 게 사실 전체의 전제입니다.
만드는 방법이 다섯 가지인데도 결과물은 서로 호환됩니다. Jib으로 만든 이미지를 Buildah가 만든 것과 같은 저장소에 올리고, 같은 클러스터에서 돌릴 수 있어요.
이게 가능한 이유는 "컨테이너 이미지가 무엇인가"가 규격으로 정해져 있기 때문입니다. 층을 어떻게 쌓고 설정을 어떻게 적는지가 문서화돼 있으니, 그 규격만 지키면 누가 만들었든 상관없어요.
그래서 이 다섯 개는 서로 대체 가능한 선택지가 됩니다. 지금 Docker를 쓰다가 CI에서 권한 문제가 생기면 그 부분만 다른 도구로 바꾸면 되고, 이미 만들어둔 이미지는 그대로 씁니다.
표준이 없었다면 도구를 바꾸는 일이 곧 전부를 다시 만드는 일이 됐을 겁니다. 선택지가 여럿이라는 것 자체가 표준이 있다는 증거예요.
그리고 이 관점에서 보면 이 글의 구성이 다시 읽힙니다. 저자가 개념(표준) → 방법 다섯 개 순으로 배치한 게, 왜 갈아탈 수 있는지를 먼저 깔고 갈아탈 방법들을 늘어놓은 것이거든요.
📝 원문에서는 이렇게 씁니다
레이어를 눈으로 확인하는 명령을 그대로 남겨뒀습니다.
# 베이스 이미지 레이어 docker inspect registry.access.redhat.com/ubi8/python-39:latest | jq | grep -e "Layers" -A5 # 빌드 이미지 레이어 docker inspect $MYUSER/pythonapp:latest | jq | grep -e "Layers" -A9
기본 이미지의 층과 내가 빌드한 이미지의 층을 나란히 찍어보는 것입니다. 앞의 층이 그대로 있고 뒤에 몇 개가 더 붙었다는 걸 눈으로 보게 되죠. 설명으로 읽는 것과 직접 찍어보는 것은 남는 게 다릅니다.
Buildah 쪽은 아예 Dockerfile 없이 명령만으로 층을 쌓습니다.
buildah from --arch arm64 quay.io/centos/centos:latest buildah run centos-working-container yum install httpd -y
Dockerfile의 FROM과 RUN이 파일이 아니라 명령으로 나타난 것입니다. 도커파일이 결국 이 명령들의 목록이었다는 게 여기서 드러나요.
큐레이터 노트
한 가지 일을 하는 다섯 가지 방법을 실제로 다 돌려본 기록이라 뽑았습니다. 소개만 하고 넘어가지 않고, 환경 제약에 막힌 지점까지 적었어요. "맥에서는 실습 불가라 리눅스 컨테이너를 따로 띄웠다"는 대목이요.
「자료가 드문 영역이다」에 해당합니다. Docker 자료는 넘치는데 Jib·Buildah·Buildpack을 한자리에서 비교한 한국어 기록은 흔하지 않아요. 그리고 이건 스터디 1주차 정리라 연재로 이어집니다.
💡 세 편을 겹쳐 읽으며
넘기는 대신 중간 산출물을 남깁니다
세 편이 다 자동화 이야기인데, 셋 다 기계가 곧바로 결과를 만들게 두지 않습니다.
CodeRabbit은 코드를 고치지 않고 코멘트를 답니다. Codex는 파일을 고치지 않고 diff를 만듭니다. Buildah는 이미지를 바로 만들지만 그 전에 층 단위로 명령이 남습니다.
중간에 사람이 볼 수 있는 물건을 하나 놓는 것. 이게 세 편의 공통 설계입니다.
이렇게 하면 두 가지가 가능해집니다. 부분만 받아들일 수 있고, 틀렸을 때 어디서 틀렸는지 볼 수 있습니다. 결과만 나오는 자동화는 잘 돌 때는 편한데, 한 번 어긋나면 처음부터 다시 봐야 합니다.
없애는 만큼 규칙을 따라야 합니다
김경보 님의 다섯 갈래가 이걸 가장 선명하게 보여줍니다. Dockerfile을 안 써도 되는 도구일수록 프로젝트가 그 도구가 아는 모양이어야 합니다.
앞의 두 편도 같습니다. CodeRabbit이 잘 리뷰하려면 PR이 작고 목적이 분명해야 하고, Codex에게 리뷰를 맡기려면 프로젝트 규칙이 문서로 적혀 있어야 합니다. 강단 님이 실제로 CLAUDE.md를 근거로 리뷰하라고 시켰던 것처럼요.
자동화는 사람의 일을 없애는 게 아니라 앞으로 옮깁니다. 나중에 하던 판단을 미리 규칙으로 적어두는 쪽으로요.
숫자와 한계를 같이 적으면 판단 자료가 됩니다
강단 님은 94% 절감을 재고 나서 "여기서 병렬의 이점을 상실"이라고 덧붙였습니다. 김경보 님은 다섯 도구를 소개하면서 "맥에서는 실습 불가"라고 적었습니다. 이지현 님은 "도우미"라는 단어로 도구의 자리를 한정했습니다.
셋 다 자기 글의 주장을 스스로 좁혔습니다. 그리고 좁혔기 때문에 읽는 사람이 자기 상황에 맞는지 판단할 수 있게 됐어요.
2회차 박나은 님의 "단점은 하나다, 구조가 복잡해진다"와 같은 자리입니다. 4기 기록에서 반복해 보이는 결이에요.
이번 회차에서 가져갈 것
1. 자동 리뷰는 톤과 범위부터 설정하기.
언어, 말투, 초안 제외 여부를 먼저 정하세요. 읽히지 않는 리뷰는 없는 것과 같고, 매번 강한 어조로 쌓이면 사람이 먼저 지칩니다.
2. 같은 지적이 반복되면 규칙으로 내리기.
리뷰에서 매번 나오는 지적은 리뷰할 일이 아니라 린터 규칙으로 고정할 일입니다. 반복해 듣고 있다면 자동화가 덜 된 상태입니다.
3. AI에게 수정을 맡길 때는 제안과 적용을 분리하기.
파일을 직접 고치게 두지 말고 변경안을 먼저 내놓게 하세요. 범위가 보이고, 골라 받을 수 있고, 되돌리기 쉬워집니다.
4. Dockerfile은 자주 바뀌는 것을 뒤에 두기.
의존성 설치를 위에, 소스 복사를 아래에 두면 코드를 고쳐도 라이브러리 층이 캐시에 남습니다. 빌드 시간이 몇 배 달라집니다.
5. CI에서 이미지를 만든다면 데몬 없는 방식을 검토하기.
빌드 서버에 도커 데몬 접근 권한을 주는 건 사실상 그 기계 전체를 여는 일입니다. Jib이나 Buildah 계열이 그 권한을 요구하지 않습니다.
4기 3회차는 2025년 10월 말이었습니다.
혼자 하는 프로젝트와 AI 도구 조합과 컨테이너 스터디라는 서로 다른 자리에서, 세 분이 나란히 기계에 넘기면서 무엇을 남겨둘지 정하는 기록을 남겼습니다. 도구 이야기인데 결국 판단 이야기였어요.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
좋은 글 남겨주신 이지현 님, 강단 님, 김경보 님께 감사드립니다. 그리고 4기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.