소프트웨어 개발

고정가 계약과 투입 정산 계약 가운데 무엇을 고를 것인가 하는 문제는 대개 리스크에 관한 선택으로 설명됩니다. 그 설명 자체는 옳지만, 바로 다음 단계에서 잘못 다뤄집니다. 발주사와 수행사 모두 리스크가 자리를 옮길 뿐이라는 사실을 잊고, 어느 한쪽을 고르면 리스크가 사라진다고 가정하기 때문입니다. 리스크는 사라지지 않습니다. 고정가 방식에서는 견적이 틀릴 위험을 공급사가 떠안고, 그 위험을 제시 금액 안에 미리 얹어 둡니다. 투입 정산 방식에서는 같은 위험을 발주사가 떠안습니다. 질문은 어느 쪽이 불확실성을 없애 주느냐가 아닙니다. 어느 쪽이 그 불확실성을 더 잘 ...

API 버전 관리 논쟁은 대개 엉뚱한 쪽에서 시작됩니다. 버전 번호를 어디에 둘 것인가 하는 문제 말입니다. 이 주제 전체에서 결과에 가장 영향이 작은 결정이 바로 그것입니다. 정작 중요한 것은 어떤 변경이 애초에 새 버전을 요구하는가이며, 대부분의 팀은 이 지점에서 안이한 쪽으로 판단을 그르칩니다. 순수하게 추가만 했다고 믿는 것을 배포했는데, 어느 클라이언트가 깨집니다. 쓸 만한 사고 모형은 이렇습니다. 여러분의 API는 호출자가 무엇에 기댈 수 있는지에 대한 약속입니다. 합리적인 호출자가 기대고 있던 무언가를 무효로 만든다면 그 변경은 호환성을 깨는 변경입니다....

소프트웨어 제안요청서, 즉 RFP는 원래 여러 공급업체를 나란히 놓고 비교할 수 있게 만드는 문서입니다. 그런데 실제로 오가는 문서 대부분은 정반대의 결과를 냅니다. 해법을 지나치게 자세히 지정해 답변의 폭을 묶어 놓으면서, 정작 가격을 산출하는 데 누구에게나 필요한 정보는 빠뜨리기 때문입니다. 그 결과 자릿수가 하나 차이 나는 다섯 개의 견적이 나란히 도착하고, 형식상으로는 모두 요구에 응답했지만 같은 것을 재고 있는 견적은 하나도 없습니다. 흔한 진단은 공급업체가 말을 흐린다는 것입니다. 가끔은 사실입니다. 그러나 훨씬 더 자주 벌어지는 일은, 문서가 그 안에 담...

소프트웨어 유지보수 비용은 성공한 프로젝트를 열여덟 달 뒤 껄끄러운 대화로 바꿔 놓는 숫자입니다. 구축은 예산이 잡혔고 승인이 났고 납품까지 끝났습니다. 그런데 서비스가 가동된 다음에 벌어지는 일은 그냥 “지원"이라는 한마디로 정리되었고, 누군가 감으로 찍은 금액이 붙었으며, 그 금액은 거의 언제나 너무 적었습니다. 이유는 부주의가 아니라 구조에 있습니다. 구축에는 값을 매길 수 있는 범위가 있습니다. 유지보수에는 범위가 없습니다. 아직 일어나지 않은 일들이 그 범위를 정하기 때문입니다. 취약점이 발견되는 라이브러리, API를 바꾸는 공급업체, 아무도 예상하지 못한 ...

기술 실사는 코드 품질을 겨루는 대회가 아니며, 실사를 준비하는 팀은 대개 엉뚱한 곳에 시간을 쏟습니다. 회사를 인수하려는 사람 중에 당신이 만든 추상화에 점수를 매기려는 사람은 없습니다. 인수자는 이 시스템을 소유하는 데 얼마가 들지, 그리고 돈이 오간 뒤에 상황이 얼마나 나빠질 수 있는지를 계산하려는 것입니다. 이렇게 질문을 다시 세우는 일이 중요한 이유는, 무엇부터 손봐야 하는지가 달라지기 때문입니다. 보기에 지저분해도 돌아가고, 팀이 이해하고 있으며, 안전하게 바꿀 수 있는 코드는 사소한 지적에 그칩니다....

데이터베이스 성능 작업은 보통 누군가 더 큰 인스턴스를 제안하는 것으로 시작해서, 페이지를 열 때마다 쿼리 하나가 400만 행을 순차 스캔하고 있었다는 발견으로 끝납니다. 제약은 처음부터 하드웨어가 아니었습니다. 제약은 실행 계획이었습니다. 이 패턴은 충분히 일관되게 반복되므로 기본 가정으로 삼을 만합니다. 애플리케이션이 느리고 데이터베이스가 바쁘다면, 원인은 거의 언제나 소수의 특정 쿼리이지 전반적인 용량 부족이 아닙니다. 그리고 서버를 키우는 일은 테이블이 다시 커지는 데 걸리는 시간만큼만 문제를 가려 줍니다. 무엇이든 바꾸기 전에 먼저 측정하십시오. 짐작으로 고...

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

핀테크 소프트웨어 개발은 누군가 돈을 보유할 권한이 누구에게 있는지 묻기 전까지는 일반 소프트웨어 개발과 똑같이 견적되고 일정이 잡힙니다. 그 질문이 나오는 순간부터 프로젝트는 엔지니어링 과제이기를 멈추고 엔지니어링 요소가 딸린 규제 과제가 되며, 머릿속에 그려두었던 일정은 더 이상 달성 가능한 것이 아니게 됩니다. 기술은 어려운 부분인 경우가 드뭅니다. 돈을 옮기는 일은 이미 해결된 문제이고, 성숙한 제공업체와 문서화된 인터페이스, 첫날부터 쓸 수 있는 테스트 환경이 갖춰져 있습니다. 핀테크 구축 기간을 늘리는 것은 인가 지위, 감사에 대응할 증적 의무, 그리고 여...

MVP 소프트웨어 개발이 어긋나는 지점은 구현 단계가 아니라 범위를 정하는 회의입니다. 누군가 “최소 기능 제품"이라고 말하면 모두가 고개를 끄덕이고, 그다음에 도착한 기능 목록에는 사용자 계정과 관리자 화면, 결제, 알림, 대시보드, 그리고 모바일 앱까지 들어 있습니다. 그것은 최소 기능 제품이 아닙니다. 그것은 이미 완성된 제품이고, 머릿속에 떠올린 숫자보다 세 배는 더 오래 걸립니다. 정작 문제를 일으키는 단어는 “기능하는”, 즉 뒤에 붙는 viable입니다. 대부분의 팀은 이 말을 “누구에게나 팔 수 있을 만큼 좋은 상태"로 읽지만, 실제 의미는 “...

대부분의 팀은 API 보안을 인증 문제로 다룹니다. 토큰을 발급하고, 모든 경로에서 그것을 검사하고, 할 일은 끝났다고 생각합니다. 그러다 어느 날 테스터가 URL의 숫자 하나를 바꾸고 다른 고객의 청구서를 읽어냅니다. 인증된 상태와 인가된 상태 사이의 그 틈이 실제 API 침해의 대부분이 살고 있는 곳이며, 스캐너가 안정적으로 찾아내는 종류의 문제도 아닙니다. 자동화 도구는 유효한 토큰과 200 응답을 보고 성공이라고 보고합니다. 그 응답 안에 남의 데이터가 들어 있었다는 사실은, 여러분의 업무 규칙을 이해하는 사람만 알아차립니다. 핵심 구분: 인증은 누가 호출하는...