OPENSOFTLAB

문제해결형

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

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

구축·사례형

두 번째 사례가 나왔는데, 공통부로 올리지 않았습니다

두 번째 사례가 나오면 공통부로 올리겠다고 썼습니다. 막상 두 번째가 왔을 때 저희가 한 일은 복사해서 옮기는 것이었습니다.

문제해결형

주석을 믿고 설계했습니다

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

문제해결형

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

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

기술설명형

통제 장치가 고장 나면, 열어야 할까 닫아야 할까

고장 나면 막는다. 팀 전원이 동의했고 문서에도 적었습니다. 그런데 1년 동안 코드를 읽을 때마다 반대로 동작하는 자리가 나왔습니다.

문제해결형

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

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

문제해결형

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

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

문제해결형

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

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

문제해결형

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

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

문제해결형

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

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

구축·사례형

레거시를 옮기며 (2) 쿼리를 두 벌로 나눴습니다

데이터베이스를 하나 더 지원하면서 쿼리를 바꿔 쓸 생각이었습니다. 문법은 통과하는데 결과가 다른 것들이 나왔고, 결국 쿼리를 두 벌로 나눠 들고 가기로 했습니다.

구축·사례형

레거시를 옮기며 (1) 하나씩 바꾸려다 순서를 못 정했습니다

프레임워크, 데이터 접근 방식, 폴더 구조를 하나씩 바꾸려다 순서를 못 정했습니다. 결국 한꺼번에 바꿨고, 그 판단이 어디까지 맞았는지 적었습니다.