자동화

자동화에 관한 기사, 가이드 및 튜토리얼. 개발자와 기업을 위한 실용적인 정보를 제공합니다.

실제로 무언가를 바꾸는 포스트모템

포스트모템은 열기는 쉽고 쓸모 있게 만들기는 어렵습니다. 회의가 열리고, 문서가 작성되고, 액션 아이템 네 개가 기록되고, 그리고 여섯 달 뒤에 똑같은 장애가 다시 일어납니다. 그 무렵 누군가가 전혀 다른 것을 찾다가 그 오래된 문서를 우연히 발견하게 됩니다. 이 주제를 이야기할 때 관심은 대부분 무비난이라는 단어에 쏠립니다. 그 원칙은 실제로 중요하지만, 실패가 일어나는 지점은 거기가 아닙니다. 아주 철저하게 무비난 원칙을 지키면서도 아무것도 바꾸지 못하는 회고를 돌리는 조직이 대단히 많습니다. 회고 자체를 결과물로 취급했고,...

소규모 팀을 위한 소프트웨어 공급망 보안

소프트웨어 공급망 보안은 전담 보안 조직을 갖춘 회사만의 문제처럼 들리지만, 그런 구도 자체가 오해를 부릅니다. 서비스 몇 개를 운영하는 소규모 팀도 보통 수백 개의 패키지에 의존하며, 그중 어느 것도 팀원이 직접 읽어 본 적이 없습니다. 이 패키지들은 빌드 시점에 팀이 통제하지 못하는 레지스트리에서 내려받아지고, 배포 자격 증명이 들어 있는 장비 위에서 설치 스크립트를 실행합니다. 노출 정도는 회사 규모에 비례하지 않습니다. 의존성의 개수와 빌드 자동화 수준에 비례하며, 소규모 팀은 이 문제를 공개적으로 걱정하는 큰 조직보다 앞의 것은 더 많이 가지고 있고 뒤의 것...

읽히는 기술 문서

기술 문서는 아주 구체적이고 예측 가능한 방식으로 실패합니다. 누군가 한가한 2주 동안 아주 많은 양을 써 놓고, 그러는 사이 시스템이 바뀌고, 아무도 갱신하지 않고, 1년이 지나면 그 문서는 확신에 찬 어조로 틀린 내용을 말하고 있습니다. 그 시점부터는 없느니만 못합니다. 문서를 믿은 사람이 이미 성립하지 않는 정보에 근거해 움직이기 때문입니다. 흔한 대응은 더 많이 쓰자는 압박이고, 그것은 같은 실패를 더 빨리 불러올 뿐입니다. 쓸모 있는 대응은 더 적게 쓰고 무엇을 쓸지 고르는 것입니다. 병목은 쓰는 노력이 아니라 유지하는 노력이기 때문입니다. 어떤 문서가 존재...

첫 주에 성과를 내는 개발자 온보딩

개발자 온보딩은 보통 입사 교육이 며칠 걸렸는지로 측정되는데, 그것은 문제의 잘못된 쪽 끝을 보는 일입니다. 정작 중요한 숫자는 따로 있습니다. 새로 온 엔지니어가 무언가를 고치면서 다른 것을 망가뜨리지 않았다고 확신하기까지 얼마나 걸리는가입니다. 대부분의 팀에서 이 값은 며칠이 아니라 몇 달 단위로 측정됩니다. 지연의 원인이 사람인 경우는 드뭅니다. 원인은 시스템의 얼마나 많은 부분이 다른 사람들의 머릿속에만 존재하는지, 그리고 첫 두 주의 얼마나 많은 시간이 그것을 한 번에 하나씩 질문으로 꺼내오는 데 쓰이는지에 있습니다. 추적할 가치가 있는 단 하나의 지표는, ...

의미 있는 가동률 SLA

가동률 SLA는 약속처럼 보이지만 환불 규정처럼 작동합니다. 공급자는 이 점을 잘 알고 있습니다. 고객은 그렇지 못한 경우가 많아서, 가용성을 샀다고 믿으며 서비스 수준 협약에 서명합니다. 그러나 실제로 산 것은 가용성이 아니라, 그것을 받지 못했을 때 돌려받는 작은 할인입니다. 그것이 반드시 나쁜 거래라는 뜻은 아닙니다. 다만 대부분의 사람이 맺고 있다고 생각하는 거래와는 다른 거래이고, 그 차이는 시스템이 멈추고 누군가 계약서에 뭐라고 적혀 있는지 묻는 순간에 드러납니다. 쓰리 나인은 거의 완벽하게 들리지만 한 달에 43분의 다운타임을 허용합니다. 포 나인은 4분...

소규모 소프트웨어 팀을 위한 재해 복구

소규모 팀에서 재해 복구는 대개 아무도 열어 본 적 없는 문서 안의 한 줄로 끝납니다. 백업은 켜져 있습니다, 라는 문장입니다. 그 문장은 사실이지만 어떤 질문에도 답이 되지 못합니다. 되찾은 데이터가 얼마나 오래된 것인지, 복원에 얼마나 걸리는지, 지금까지 누가 한 번이라도 끝까지 복원을 해 본 적이 있는지에 대해 아무것도 말해 주지 않기 때문입니다. 백업을 가지고 있다는 사실과 실제로 복구할 수 있다는 사실 사이의 간격에서 대부분의 장애는 심각한 사고로 바뀝니다. 존재하고, 최신이며, 한 번도 복원해 본 적 없는 백업은 아직 가설일 뿐입니다. 그리고 그 가설을 처...

실제 사용자를 견뎌내는 소프트웨어 테스트 전략

소프트웨어 테스트 전략은 대개 커버리지라는 숫자로 설명되지만, 커버리지는 이 분야 전체에서 정보량이 가장 적은 숫자입니다. 커버리지가 구십 퍼센트인 코드베이스도 가장 많이 쓰이는 경로에서 버그를 그대로 배포할 수 있습니다. 커버리지는 테스트가 도는 동안 어떤 줄이 실행되었는지를 측정할 뿐, 그 줄에 대해 의미 있는 검증이 이루어졌는지는 전혀 측정하지 않기 때문입니다. 자기 테스트 스위트를 신뢰하는 팀은 퍼센트가 가장 높은 팀이 아닙니다. 무언가가 정말로 망가졌을 때 테스트가 빨간불을 켜고, 그 외의 순간에는 조용히 있는 팀입니다....

Cloudflare Queues: 엣지의 백그라운드 작업

Cloudflare Queues는 모든 서버리스 애플리케이션이 언젠가는 마주치는 문제를 해결합니다. 사용자가 기다릴 이유가 없는 작업을 유발하는 요청이 들어온다는 문제입니다. 확인 메일 발송, 업로드된 이미지 리사이즈, 레코드를 외부 서비스로 동기화하는 처리 같은 것들입니다. 전통적인 서버라면 그 일을 백그라운드 워커 프로세스에 넘기면 됩니다. 그런데 Workers에는 넘길 프로세스 자체가 없습니다. 흔히 쓰이는 우회책들은 보기보다 나쁩니다. 요청 안에서 그대로 처리하면 사용자가 메일 발송 업체의 응답을 기다리게 됩니다. 다른 Worker로 요청만 던지고 기다리지 않...

비즈니스 AI 에이전트: 비용과 실패 지점

비즈니스 AI 에이전트는 익숙한 이야기의 현재 판본입니다. 십 분 만에 훌륭하게 돌아가는 데모가 있고, 그다음 그것을 사람이 지켜보지 않아도 될 만큼 믿을 수 있게 만들려는 여섯 달이 이어집니다. 이 두 상태 사이가 예산이 거의 전부 사라지는 곳이고, 그 간극을 설명하는 마케팅 자료는 거의 없습니다. 에이전트는 상업적으로 중요한 한 가지 점에서 챗봇과 다릅니다. 챗봇은 글을 만들고 사람이 그것으로 무엇을 할지 정합니다. 에이전트는 스스로 행동합니다. 시스템을 호출하고, 레코드를 쓰고, 메시지를 보냅니다. 그 차이가 위험을 민망함에서 결과로 옮기고, 그래서 필요한 엔지...

CRM·ERP 통합: 비용과 방식, 함정

CRM과 ERP 통합은 거의 언제나 연결 문제로 설명되지만, 실제로 연결 문제인 경우는 거의 없습니다. 두 시스템 모두 문서화된 인터페이스가 있고, 가져다 쓸 커넥터도 나와 있습니다. 어려운 것은 영업과 재무가 몇 년에 걸쳐 같은 사업을 서로 다른 두 어휘로 서술해 왔다는 사실이고, 통합이란 그 두 어휘가 억지로 합의해야 하는 자리입니다. 두 번 전환된 리드가 거래처를 하나 만들어야 하는지 둘을 만들어야 하는지 누군가 묻는 순간, 이 프로젝트는 기술 문제이기를 그만둡니다. 같은 대화를 서른 개 필드에 걸쳐 반복하는 것, 그것이 이 일의 실체입니다. 먼저 할 일: 커넥...