문제해결형

문제해결형

가끔 실패하는 테스트를 재시도로 덮지 않았습니다

혼자 돌리면 통과하고 전체를 돌리면 실패하는 테스트가 있었습니다. 재시도를 켜면 사라지는데, 켜지 않기로 했습니다.

문제해결형

주석을 믿고 설계했습니다

설계 문서를 작성하면서 코드 주석을 근거로 삼았습니다. 검토 과정에서 그 주석 두 개가 사실이 아니라는 게 나왔고, 그 위에 세운 개선안을 접었습니다.

문제해결형

프록시니까 그대로 넘기면 되는 줄 알았습니다

프록시니까 요청을 그대로 넘기면 되는 줄 알았습니다. 서비스 세 곳을 붙이자 세 가지 다른 방식으로 깨졌습니다.

문제해결형

AI 정보보호 설계 (3) AI가 답하지 않고 실행하기 시작했습니다

입력과 응답을 검사하는 것으로 충분하다고 생각했습니다. AI가 답하는 대신 사내 시스템을 직접 실행하기 시작하면서 전제가 깨졌습니다.

문제해결형

단위 테스트 400건이 전부 통과하는데, 서비스는 깨져 있었습니다

단위 테스트 380건이 전부 통과했는데, 배포 전 curl 한 번에 500 오류와 200 + 로그인 HTML이 돌아왔습니다. 로직이 아니라 계약이 깨져 있었습니다.

문제해결형

AI 정보보호 설계 (2) 차단과 허용 사이에 칸을 더 뒀습니다

민감정보가 보이면 막는다. 보안 기능이니 당연하다고 생각했습니다. 그런데 차단이 늘수록 통제가 약해지고 있었습니다.

문제해결형

스트리밍으로 흘러나오는 AI 답변을 중간에 끊어 보았습니다

생성형 AI 응답은 스트리밍으로 조금씩 도착합니다. 다 받은 뒤 검사하면 늦기 때문에 창 단위로 보류하며 검증했는데, 노출이 0이라는 가정이 실측에서 깨졌습니다.

문제해결형

AI 정보보호 설계 (1) 프롬프트만 막으면 될 줄 알았습니다

입력창에 들어오는 글자에서 주민등록번호와 계좌번호를 찾으면 될 줄 알았습니다. 사용자가 파일을 올리기 시작하면서 그 전제가 깨졌습니다.

문제해결형

보안 포탈 설계 (3) 복사해서 따로 만들고 다시 합쳤습니다

고쳐 쓰는 대신 복사해서 따로 만들기 시작했습니다. 두 달 뒤 원본에서 계속 작업하던 팀과 코드를 합쳐야 했고, 그때 무슨 일이 있었는지 적었습니다.

문제해결형

보안 포탈 설계 (2) 물어보고 기다리는 절차를 만들었습니다

당사자에게 물어봐야 끝나는 일이 있었습니다. 메일 한 통이면 될 줄 알았는데, 답이 안 오는 경우를 전부 다뤄야 했습니다.

문제해결형

보안 포탈 설계 (1) 업무 티켓으로 보안 이벤트를 받아봤습니다

티켓 시스템은 여러 번 만들어봤습니다. 보안 업무도 결국 티켓이라고 생각했는데, 탐지 데이터를 받아보니 시작점부터 반대였습니다.