소프트웨어 개발

Drupal 12는 2026년 12월 7일이 있는 주에 나올 예정이고, Drupal 10은 2026년 12월 9일에 지원이 끝납니다. 두 날짜는 Drupal 코어 릴리스 일정 같은 페이지에 두 줄 간격으로 나란히 적혀 있지만, Drupal 10 사이트를 운영하는 사람 대부분은 둘 다 알아차리지 못했습니다. 새 메이저의 첫 알파는 2026년 9월 2일에 태그되었으니, 이번 릴리스의 모양은 이제 추측이 아니라 기록의 문제입니다. 이 충돌이 이야기의 전부입니다. 메이저 버전이 나오는 일 자체는 보통 사이트 소유자에게 급하지 않습니다....

Salesforce 연동이 프로토콜 때문에 실패하는 일은 거의 없습니다. 인증은 이미 풀린 문제이고, 레코드 하나를 등록하는 것도 이미 풀린 문제입니다. 프로젝트를 끝장내는 것은 하루치 요청 할당량과 데이터 모델의 형태이며, 이 두 가지는 대개 가동 후 3주쯤 지나 야간 작업이 오류를 뱉기 시작하고 테스트에서는 왜 멀쩡했는지 아무도 설명하지 못하는 시점에 발견됩니다. 패턴은 예측이 가능할 만큼 일정합니다. 개발자가 Developer Edition 조직을 상대로 만들고, 전부 통과하고, 고객이 검수를 승인합니다....

대부분의 WordPress 플러그인 개발은 같은 곡선을 그립니다. 누군가에게 예약 양식이나 피드 수집기, 결제 화면의 추가 입력란이 필요해지고, 개발자가 그것을 작성하고, 잘 동작하고, 모두가 다음 일로 넘어갑니다. 2년 뒤 그 사이트는 오래된 버전의 WordPress에 묶여 있습니다. 업데이트를 해도 그 플러그인이 무사할지 아무도 확신하지 못하고, 그것을 작성한 사람은 이미 떠났기 때문입니다. 원인이 코어가 너무 빨리 움직이는 데 있는 경우는 드뭅니다. WordPress는 호환성을 깨뜨리는 일에 보수적이고, 5...

CMS 마이그레이션은 기술 작업이 완벽하게 굴러가도 결과는 재앙일 수 있는, 몇 안 되는 종류의 프로젝트입니다. 사이트는 일정에 맞춰 공개되고, 보기에 더 좋아지고, 더 빨리 뜨는데, 트래픽은 절반으로 떨어집니다. 수백 개의 주소가 모양을 바꾸었는데 아무도 그 대응표를 만들지 않았기 때문입니다. 트래픽 손실을 일으키는 것은 새 플랫폼이 아닙니다. 단절이 일으킵니다. 예전에는 응답하던 주소가 이제 응답하지 않고, 식별 가능하던 페이지가 새 페이지처럼 보이며, 옛 주소에 몇 년간 쌓여 있던 이력은 옮겨 갈 곳을 잃습니다. 그래서 순위는 공개 당일이 아니라 몇 주에 걸쳐 ...

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

비밀번호 저장은 소프트웨어에서 진짜 정답이 존재하는 몇 안 되는 영역이다. 그 정답은 이미 공개되어 있고, 꾸준히 갱신되며, 돈 한 푼 들지 않는다. 그런데도 가장 꾸준히 틀리는 영역이기도 하다. 틀린 답들이 한때는 옳은 답이었고, 그 뒤로 아무도 다시 들여다보지 않았기 때문이다. 실패는 좀처럼 특별하지 않다. 2012년에 통하던 조언을 따라 2016년에 만들어진 시스템이 여전히 돌아가고, 여전히 로그인을 받아들이고 있으며, 그 함수를 작성한 사람이 회사를 떠난 뒤로는 아무도 그 코드를 열어보지 않았을 뿐이다. 한 가지만 가져간다면: Argon2id를 쓰고,...

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

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

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

소프트웨어 임치는 소스코드를 중립적인 제3의 기관에 맡겨 두는 제도이며, 충분히 합리적인 두려움에 답하기 위해 존재합니다. 핵심 시스템을 만들고 운영해 온 공급업체가 사라지고, 여러분에게는 의존하고 있지만 스스로 유지보수할 수 없는 무언가만 남는 상황 말입니다. 임치 계약은 소스코드를 그 기관에 보관해 두었다가, 그런 일이 실제로 벌어지면 여러분에게 인도하도록 정해 둡니다. 두려움 자체는 정당합니다. 문제는 이 제도가 자주 오해된다는 점이고, 그 간극에서 매년 돈은 나가지만 정작 필요한 날에는 아무 도움이 되지 않는 계약이 생겨납니다....