이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 개인정보가 포함된 설문 데이터를 처리하는 시스템에 참여했습니다. 그때 처음으로 법적 요구사항이 기술 설계에 직접 영향을 준다는 것을 실감했습니다.
가장 신경 썼던 것은 수집 목적 이외의 용도로 사용하지 않도록 데이터 접근 권한을 역할별로 제한하는 것이었습니다. 전체 데이터를 모든 팀원이 볼 수 있는 구조를 분석 목적에 맞는 컬럼만 접근 가능하도록 뷰를 만들어서 분리했습니다.
처음에는 이 작업이 귀찮게 느껴졌습니다. 그러나 나중에 실제 감사 요청이 왔을 때 누가 언제 어떤 데이터에 접근했는지 로그로 확인할 수 있어 빠르게 대응할 수 있었습니다. 법적 요건이 추가 작업처럼 느껴지지만 결국 시스템의 신뢰성을 높이는 과정이라는 것을 그때 배웠습니다.
졸업 프로젝트에서 사용자 로그를 보존하는 시스템을 설계할 때 법적 보존 기간 요건을 처음 고려해봤어요. 단순히 데이터를 쌓는 게 아니라 언제 삭제해야 하는지까지 설계해야 한다는 걸 그때 알았습니다.
일정 기간이 지난 데이터를 자동으로 아카이빙하고, 보존 기한을 넘기면 삭제하는 배치 작업을 구현했는데, 처음엔 삭제 로직을 잘못 짜서 보존 기한이 지나지 않은 데이터가 지워지는 버그가 생겼어요. 테스트 환경에서 발견해서 다행이었지만 실제 운영이었으면 큰 문제가 됐을 거예요.
그 경험이 삭제·아카이빙 작업은 특히 드라이런을 먼저 해야 한다는 걸 몸으로 배우게 해줬어요. 법적 요구사항은 완성된 시스템에 덧붙이는 게 아니라 처음부터 설계에 넣어야 한다는 것도요.
법적 요구사항 중 하나가 데이터 접근 이력을 추적할 수 있어야 한다는 거예요. 인턴 프로젝트에서 이 요건을 처음 들었을 때 '로그만 남기면 되겠지'라고 생각했는데, 실제로 설계해보니 생각보다 복잡했어요.
모든 조회·수정·삭제 이벤트에 사용자 ID, 타임스탬프, 대상 레코드를 기록하는 구조를 만들었는데, 처음엔 로그 테이블이 너무 빠르게 커져서 성능 문제가 생겼어요. 전체 행이 아닌 변경된 필드만 기록하도록 수정하면서 해결했습니다.
감사 로그는 기능이 아니라 책임의 흔적이라는 걸 그때 처음 이해했어요. 시스템 오류가 생겼을 때도 이 로그가 원인을 찾는 데 결정적인 역할을 했거든요. 처음부터 추적 가능성을 설계에 넣는 것이 나중에 얼마나 유용한지를 직접 경험했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.