지난 글에서는 서버에 데이터를 모으는 구조를 접고 로컬 설치형으로 바꾼 이야기를 했습니다.

장애 유형과 등급 같은 민감한 정보를 개발자 서버에 보관하는 문제, 그 데이터를 맡는 책임이 걸렸습니다. 그래서 기관 PC에 원본을 두기로 했고, PostgreSQL을 SQLite로 바꾸면서 RLS도 걷어냈습니다.

그런데 그 뒤에, 결국 다시 서버로 돌아왔습니다.

지난 글만 읽으면 지금도 로컬 설치형으로 개발하고 있다고 생각하실 것 같아, 이번에는 그 이후 이야기를 적습니다.

1. 지난 글의 마지막이 최종 구조는 아니었습니다

처음에는 Next.js와 NestJS, PostgreSQL을 쓰는 서버형이었습니다. 기관별 데이터 격리는 RLS로 처리했고요.

이후에는 Electron을 사용하는 로컬 설치형으로 바꿨습니다. 두 구성을 계속 유지하지 않으려고 기존 디렉터리도 정리했습니다. 여기까지가 지난 글의 이야기입니다.

그리고 다시 서버형으로 방향을 바꿨습니다.

그렇다고 처음 지웠던 구성을 전부 그대로 복구했다는 뜻은 아닙니다. 서버에서 운영한다는 결정과 어떤 프레임워크나 DB를 사용한다는 것은 구분해야 합니다. RLS도 서버로 돌아왔다는 이유만으로 다시 적용됐다고 설명할 수는 없습니다.

2. 지금은 서버에 배포해서 확인하고 있습니다

10월 5일 기준으로 NCP와 Nginx를 사용하는 서버 배포를 확인했습니다. 공개 홈과 샘플 화면, 인증되지 않은 요청을 거부하는 보호 API, 기관 승인 후 기관과 사용자 계정이 활성화되는 흐름도 확인했습니다.

다만 여기서 확인한 것은 그 범위까지입니다.

로그인하지 않은 요청에 401이 나온다는 것과, 로그인한 사람이 다른 기관의 데이터를 볼 수 없다는 것은 서로 다른 검증입니다. 기관 승인이 있다는 것과 같은 기관 직원들의 권한이 적절하게 나뉘어 있다는 것도 다르고요.

배포가 됐다는 설명에 이런 것들을 한꺼번에 묶으면 안 됩니다.

3. 처음 서버를 접었던 이유는 없어지지 않았습니다

서버로 돌아왔다고 민감한 정보를 다루는 부담까지 없어지는 것은 아닙니다.

어떤 데이터를 꼭 저장해야 하는지. 기관 사이의 경계는 어디에서 확인하는지. 같은 기관 안에서는 누가 무엇을 볼 수 있는지. 운영 중 문제가 생겼을 때 개발자는 어디까지 접근하는지.

처음 로컬 설치형을 선택하면서 고민했던 질문들입니다. 서버형에서도 여전히 답이 필요한 질문들이고요.

암호화를 쓴다는 한마디로 보관과 접근 문제가 전부 설명되지도 않습니다. 무엇을 암호화하는지, 누가 복호화할 수 있는지, 백업과 복원은 어떻게 처리하는지가 함께 있어야 합니다.

이번 글에서 그 부분까지 모두 해결됐다고 말하려는 것은 아닙니다. 현재 구조와 실제로 확인한 범위를 나눠 적으려는 것입니다.

4. 로컬과 서버 중 하나를 고르면 끝나는 줄 알기 쉽습니다

로컬에서는 기관 PC와 파일, 설치 버전과 업데이트를 챙겨야 합니다. 서버에서는 여러 기관의 접근 권한과 데이터 보관, 운영을 챙겨야 합니다.

데이터를 놓는 위치에 따라 관리할 곳이 달라집니다. 어느 쪽을 골랐다는 사실 자체가 안전하다는 증명은 아닙니다.

종이 결재와 엑셀 근태·급여, 담당자 머릿속에 흩어진 이용자 정보를 정리하려고 시작한 작업입니다. 그 문제는 그대로인데, 구현하는 구조는 한 번 더 바뀌었습니다.

마치며

1편에서는 결정을 미룬 시간이 비쌌다고 적었습니다.

그 글을 쓰고도 결정이 다시 바뀌었습니다. 그래서 로컬로 바꿨다는 기록 옆에, 다시 서버로 돌아왔다는 기록도 남깁니다.

지금은 서버형으로 진행하고 있습니다. 다만 서버에 올린 것, 기능이 동작하는 것, 데이터가 적절하게 보호되는 것은 각각 확인해야 할 일입니다.

다음 기록에서는 방향을 바꿨다는 설명보다 실제로 무엇을 확인했고 무엇이 남았는지를 더 구체적으로 적어보려고 합니다.