[Learner's High] 1주차 - 문제 정의

1주차 회고

 

러너스하이를 시작한지 어느덧 1주가 지났습니다.

이번 회고에서는 무엇을 만들었는지보다, 왜 이 문제를 선택했는지와 1주차 동안 어떤 작업을 진행했는지를 정리해 보려고 합니다.

 

 

문제 선택

 

Learner’s High는 단순히 “과제를 잘 수행했는가”를 평가하는 프로그램이 아니었습니다.
한 달이라는 제한된 시간 안에서,

• 어떤 문제를 선택했고
• 왜 그 문제였으며
• 어떻게 해답을 찾았고
• 그 결과 어떤 임팩트를 만들었는가

를 설명할 수 있는지를 보는 프로그램이라고 이해했습니다.

 

따라서 이번 프로젝트의 출발점은 기술 선택이나 구현 난이도가 아니라, "지금 환경에서 가장 의미 있는 병목은 무엇인가" 라는 질문이었습니다.

 

 

 

프로젝트 배경과 환경

 

제가 속한 조직에서는 기존의 사내망 중심 접근 제어 방식에서 제로 트러스트(Zero Trust) 기반 구조로의 전환을 시도하고 있습니다. 기존 시스템은 네트워크 경계를 기준으로 접근을 제어하는 구조를 전제로 설계되어 있었고, 한 번 신뢰된 영역에 진입하면 비교적 넓은 권한이 부여되는 방식이었습니다. 이러한 구조는 초기에는 단순하고 운영 효율성도 높았지만, 서비스 수가 증가하고 시스템 구조가 복잡해질수록 접근 제어의 한계가 점점 명확해졌습니다.

 

특히 접근 통제의 기준이 개별 요청이 아니라 네트워크 위치나 사전 신뢰 여부에 머물러 있다는 점이 문제였습니다. 이로 인해 특정 서비스에만 접근해야 하는 요청이 과도한 권한을 갖게 되거나, 사용자·시스템 단위의 세밀한 통제가 어려운 구조가 되었고, 요청이 왜 허용되거나 거부되었는지를 명확하게 설명하기도 쉽지 않았습니다. 또한 서비스가 늘어나고 내·외부 트래픽이 복잡해질수록, 네트워크 계층에서 모든 접근 제어를 처리하는 방식은 확장성과 운영 측면에서도 부담이 커졌습니다.

 

이러한 배경 속에서 조직은 접근 제어의 기준을 네트워크가 아닌 ‘요청’으로 옮기는 제로 트러스트 방향을 검토하게 되었습니다. 제로 트러스트는 네트워크 위치를 신뢰하지 않고, 모든 요청을 개별적으로 검증하며, 매 요청마다 인증과 인가를 수행하는 접근 방식입니다. 이는 보안 측면에서 명확한 기준을 제공하지만, 동시에 각 요청의 판단 근거를 설명할 수 있어야 하고, 정책 변경·적용·이력을 일관되게 관리할 수 있는 새로운 구조적 요구를 시스템에 만들어냈습니다.

 

제로 트러스트 환경에서는 모든 요청이 판단의 대상이 됩니다.

따라서 운영 관점에서는 단순히 허용/거부 결과만으로는 충분하지 않습니다.

• 어떤 요청이었고
• 어떤 조건이 적용되었으며
• 어떤 이유로 그 판단이 내려졌는지

를 요청 단위로 설명할 수 있어야 합니다.

 

바로 이 지점에서, 정책 기반 접근 제어와 함께 정책 결정 로그가 중요한 역할을 하게 됩니다.

하지만 실제로 POC를 진행하며 느낀 점은, 로그는 모두 저장되고 있지만, 디버깅이 어렵다는 것이었습니다.

 

문제는 로그의 양이 아니라, 로그가 요청 기준이 아니라 정책 판단 결과 기준으로 저장되고 있다는 점이었습니다. 하나의 요청에 대해 어떤 입력이 들어왔고, 어떤 정책들이 평가되었으며, 그 결과가 어떻게 누적되어 최종 판단이 내려졌는지가 하나의 단위로 묶여 있지 않은 구조였습니다.

 

이로 인해 “왜 이 요청이 거부되었는지”를 이해하기 위해서는 여러 정책 판단 결과를 각각 확인한 뒤, 사람이 다시 요청 단위로 재구성해야 했습니다. 결과적으로 로그는 풍부하지만, 요청 단위의 맥락은 보존되지 않은 상태였고, 이 점이 디버깅과 분석을 어렵게 만드는 가장 큰 원인이었습니다.

 

이러한 한계를 직접 경험하면서, 단순히 정책 결정 로그를 남기는 것이 아니라 정책 결정 로그를 어떤 단위와 관점으로 다뤄야 하는가가 더 중요하다는 문제의식에 이르게 되었습니다. 이 경험이 이번 Learner’s High 프로젝트에서 ‘정책 결정 로그를 어떻게 다뤄야 하는가’라는 문제를 선택하게 된 출발점이 되었습니다.

 

 

 

1주차 진행 작업

 

주차에 가장 먼저 진행한 작업은 문서화였습니다. 구현에 앞서, 이번 프로젝트에서 어떤 문제를 어떻게 풀 것인지에 대한 사고 과정과 설계 판단을 먼저 고정할 필요가 있다고 판단했기 때문입니다.

 

ADR(Architecture Decision Record)은 설계 과정에서 내려진 중요한 의사결정을 문서로 남기는 방식입니다.

어떤 문제가 있었고, 어떤 선택지들을 고려했으며, 그중 왜 이 선택을 했는지, 그리고 그 선택이 가져올 장단점은 무엇인지를 짧고 명확하게 기록합니다.

 

나중에 설계가 바뀌거나, 다른 선택이 더 나았다는 결론에 도달하더라도, 그때의 사고 과정이 남아 있다는 것 자체가 큰 가치가 있다고 생각했습니다.

 

이번 1주차에는, 문제 정의부터 저장 구조까지 이어지는 주요 판단들을 ADR로 정리했습니다.

• ADR000 – 문제 정의
• ADR001 – 요청 단위 디버깅이 필요한 이유
• ADR002 – 로그 저장 방식에 대한 선택
• ADR003 – Decision Context 개념 도입
• ADR004 – 정규화 전략에 대한 판단
• ADR005 – 요청 중심 저장 구조
• ADR006 – Decision Log 스키마 설계

 

ADR과는 별도로, 기술적인 선택과 구조를 조금 더 자세히 설명하기 위한 문서도 함께 작성했습니다.

• Decision Log Ingestion Notes
  • Spring Boot 4 + Jackson 3
  • Hibernate 7 JSONB
  • Gzip 압축

 

또한 품질 지표를 함께 확인하기 위한 환경도 구성했습니다.

단순히 기능을 구현하는 데 그치지 않고, 이 구조가 장기적으로 유지 가능한지를 함께 보려는 목적이었습니다.

• JaCoCo를 통해 테스트 커버리지 확인
• SonarQube를 통해 코드 스멜, 복잡도, 설계 위반 여부 점검

아직 프로젝트 초기 단계이지만, 이러한 도구들을 초반부터 도입함으로써, 그저 기능이 동작하는 코드가 아니라 유지보수와 변경에 유리한 코드를 만드는 기준점을 마련하고자 했습니다.

 

 

 

마무리하며

 

1주차는 기능 구현보다는, 어떤 문제를 풀 것인지와 그 문제를 어떤 관점에서 바라볼지를 정리하는 시간이었습니다. 2주차부터는 기본 조회를 ‘디버깅 가능한 조회’로 고도화하는 데 집중할 예정입니다.