공공·금융
소스 수정 전에 락을 겁니다만 — 락 기반 형상관리에서 동시 개발로 넘어간다는 것
공공기관 미팅에서 반복해서 받는 질문이 있다. 지금은 파일에 락을 걸고 수정하는데, 이 솔루션은 어떤 형태냐는 것. 락 모델과 브랜치·머지 모델의 차이, 락 없이 사고를 막는 방법, 그리고 기존 이력을 잃지 않는 전환 경로까지.
백재민
블로그
CollabOps 블로그
엔지니어링·제품·공공섹터에서 본 DevOps 실행 레이어
- 공공·금융
GPU가 없는데 PoC가 되나요 — AI를 옵션 레이어로 설계한 이유
PoC 를 하려는데 GPU 가 없다는 기관에게 하는 답. 에이전트만 GPU 를 요구하고 플랫폼의 나머지는 전부 CPU 서버에서 돈다. 30일 PoC 가 실제로 어떻게 진행되는지, 문서 자동 생성은 어디까지 자동인지, 그리고 검증하고 쓰는 게 맞다는 기관의 말이 왜 옳은지.
백재민
- 공공·금융
SVN 잘 쓰고 있는데 왜 바꿔야 하나요 — 그때 제대로 못한 답변을 다시
미팅에서 나는 "협업이 좀 더 들어가 있다"고 답했다. 틀린 말은 아닌데 부족한 답이었다. SVN 과 TortoiseSVN 이 실제로 괜찮은 지점을 먼저 인정하고, 형상관리 관점에서 정확히 무엇이 다른지, 그리고 우리가 파는 게 기능이 아니라 속성이라는 이야기까지.
백재민
- 공공·금융
공공기관은 왜 SVN을 계속 쓰는가, 안정성이 곧 레퍼런스라는 말
어느 공공기관 실장님이 말했다. SVN 왜 쓰냐고? 내부에서 힘들다고 해도 안정적이라 쓰는 거다. 안정성이 제일 중요하다. 그것이 레퍼런스다. 공공 도입의 실제 의사결정 구조와, 벤더가 그 앞에서 해야 할 일에 대해.
백재민
- 공공·금융
작은 팀의 ISO 27001 — 인증 프로젝트가 *조직 변형 프로젝트* 인 이유
ISO 27001 인증을 *문서 작업* 으로 보고 시작하면 6개월 후 좌절. 인증은 *조직 운영 자체* 를 바꾼다. 작은 팀의 *현실적* 도입 가이드.
백재민
- 공공·금융
폐쇄망에서 Zero Trust 가 *의미하는 것* — 모순처럼 보이는 답
Zero Trust 는 *경계 없음* 을 가정하고, 폐쇄망은 *경계 있음* 을 전제. 둘이 충돌하는 게 아니라 *경계 안에서도 zero trust* 가 답이다.
백재민
- 공공·금융
어떤 온프레 환경이든 들어가기 — CollabOps 가 보는 5가지 환경 분류
고객이 *k8s 가 없어도, 인프라 전문성이 없어도*, *기존 시스템이 무엇이든* 들어갈 수 있어야 한다. 17개 PoC 에서 본 온프레 환경 5분류와 각각의 도입 경로.
백재민
- 공공·금융
FIPS 140-3 컴플라이언스의 *엔지니어링* 비용 — 한 고객을 위해 6개월
한 미국 연방 고객을 위해 *FIPS 140-3 검증된 암호화* 만 쓰도록 시스템 전체를 다시 짠 6개월. 그 작업의 시간·돈·정치 비용.
백재민
- 공공·금융
금융권 4-eyes 배포 — 이론과 *실제로 작동하는* 패턴 사이의 갭
금융 IT 통제의 *4-eyes* 원칙을 *그대로* 구현하면 *배포 파이프라인이 멈춘다*. 6개 은행에서 본 *실제 작동* 패턴 4가지.
백재민
- 공공·금융
K-ISMS 와 GitOps 가 충돌하는 6 지점 — 한국 공공기관에서 GitOps 가 실패하는 진짜 이유
GitOps 가 *git 이 진실의 단일 출처* 라는 명제 위에 서 있다. K-ISMS 인증의 일부 통제는 *그 명제* 와 직접 충돌한다. 6 지점과 우회 패턴.
백재민
- 공공·금융
공공 클라우드 전환에서 부서지는 5가지 — 19개 프로젝트의 같은 순서
공공·금융섹터 클라우드 전환 19개 프로젝트를 가까이서 봤다. 6개는 일정대로, 5개는 끝나지 않았고, 8개는 가운데. 그 8개에서 *같은 5가지가 같은 순서로* 부서졌다.
백재민