가끔 실패하는 테스트를 재시도로 덮지 않았습니다
혼자 돌리면 통과하고 전체를 돌리면 실패하는 테스트가 있었습니다. 재시도를 켜면 사라지는데, 켜지 않기로 했습니다.
혼자 돌리면 통과하고 전체를 돌리면 실패하는 테스트가 있었습니다. 재시도를 켜면 사라지는데, 켜지 않기로 했습니다.
두 번째 사례가 나오면 공통부로 올리겠다고 썼습니다. 막상 두 번째가 왔을 때 저희가 한 일은 복사해서 옮기는 것이었습니다.
설계 문서를 작성하면서 코드 주석을 근거로 삼았습니다. 검토 과정에서 그 주석 두 개가 사실이 아니라는 게 나왔고, 그 위에 세운 개선안을 접었습니다.
프록시니까 요청을 그대로 넘기면 되는 줄 알았습니다. 서비스 세 곳을 붙이자 세 가지 다른 방식으로 깨졌습니다.
고장 나면 막는다. 팀 전원이 동의했고 문서에도 적었습니다. 그런데 1년 동안 코드를 읽을 때마다 반대로 동작하는 자리가 나왔습니다.
입력과 응답을 검사하는 것으로 충분하다고 생각했습니다. AI가 답하는 대신 사내 시스템을 직접 실행하기 시작하면서 전제가 깨졌습니다.
단위 테스트 380건이 전부 통과했는데, 배포 전 curl 한 번에 500 오류와 200 + 로그인 HTML이 돌아왔습니다. 로직이 아니라 계약이 깨져 있었습니다.
민감정보가 보이면 막는다. 보안 기능이니 당연하다고 생각했습니다. 그런데 차단이 늘수록 통제가 약해지고 있었습니다.
생성형 AI 응답은 스트리밍으로 조금씩 도착합니다. 다 받은 뒤 검사하면 늦기 때문에 창 단위로 보류하며 검증했는데, 노출이 0이라는 가정이 실측에서 깨졌습니다.
입력창에 들어오는 글자에서 주민등록번호와 계좌번호를 찾으면 될 줄 알았습니다. 사용자가 파일을 올리기 시작하면서 그 전제가 깨졌습니다.
데이터베이스를 하나 더 지원하면서 쿼리를 바꿔 쓸 생각이었습니다. 문법은 통과하는데 결과가 다른 것들이 나왔고, 결국 쿼리를 두 벌로 나눠 들고 가기로 했습니다.
프레임워크, 데이터 접근 방식, 폴더 구조를 하나씩 바꾸려다 순서를 못 정했습니다. 결국 한꺼번에 바꿨고, 그 판단이 어디까지 맞았는지 적었습니다.
문제해결형
고쳐 쓰는 대신 복사해서 따로 만들기 시작했습니다. 두 달 뒤 원본에서 계속 작업하던 팀과 코드를 합쳐야 했고, 그때 무슨 일이 있었는지 적었습니다.
문제해결형
당사자에게 물어봐야 끝나는 일이 있었습니다. 메일 한 통이면 될 줄 알았는데, 답이 안 오는 경우를 전부 다뤄야 했습니다.
문제해결형
티켓 시스템은 여러 번 만들어봤습니다. 보안 업무도 결국 티켓이라고 생각했는데, 탐지 데이터를 받아보니 시작점부터 반대였습니다.
구축·사례형
제품이 늘어나면서 같은 코드를 계속 다시 쓰고 있었습니다. 무엇이 공통이고 무엇이 도메인인지 가르는 데 몇 년이 걸렸고, 보안 업무에서 그 기준이 처음으로 어긋났습니다.
구축·사례형
방법론을 걷어내고 쓰기 편한 업무 도구를 만들면 될 줄 알았습니다. 그런데 도구가 아무리 좋아도 일이 다른 곳에서 벌어지고 있으면 소용이 없었습니다.
구축·사례형
애자일 도구를 만들면 팀이 애자일해질 거라고 생각했습니다. 개인 능률을 퍼센트로 나란히 보여주는 화면을 만들고 나서야 무엇을 잘못했는지 알았습니다.