설계 원칙

구축·사례형

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

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

문제해결형

주석을 믿고 설계했습니다

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

기술설명형

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

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

문제해결형

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

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

구축·사례형

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

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

구축·사례형

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

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

문제해결형

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

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

문제해결형

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

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

문제해결형

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

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

구축·사례형

업무 시스템 다시 만들기 (3) 뼈대는 같고 도메인만 달랐습니다

제품이 늘어나면서 같은 코드를 계속 다시 쓰고 있었습니다. 무엇이 공통이고 무엇이 도메인인지 가르는 데 몇 년이 걸렸고, 보안 업무에서 그 기준이 처음으로 어긋났습니다.

구축·사례형

업무 시스템 다시 만들기 (2) 도구 하나만으로는 안 쓰이더군요

방법론을 걷어내고 쓰기 편한 업무 도구를 만들면 될 줄 알았습니다. 그런데 도구가 아무리 좋아도 일이 다른 곳에서 벌어지고 있으면 소용이 없었습니다.

구축·사례형

업무 시스템 다시 만들기 (1) 칸반보드로 시작했습니다

애자일 도구를 만들면 팀이 애자일해질 거라고 생각했습니다. 개인 능률을 퍼센트로 나란히 보여주는 화면을 만들고 나서야 무엇을 잘못했는지 알았습니다.