# 관련 소스는 여기에서 확인하실 수 있습니다.
어떡하지...?
문제점을 발견하고 다시 구글링을 시도했지만, 나의 구글링 숙련도 이슈로 인해서인지 logback을 이용해서는 문제를 해결할 수 없었고, 결국엔 다른 대안을 찾기에 이르렀다.
대안책
- 로그를 관리하는 싱글톤 객체를 만든다.
- 객체가 만들어지는 시점에 시간 값을 계산하여 로그 파일 생성 시점(5분 단위)을 기억한다.
- 로그를 출력하는 곳에서 해당 객체에 로그를 적재한다.
- 스케줄러를 이용하여 1분마다 로그 파일을 생성하는 시점인지 해당 객체에 물어본다
- 생성 시점이면 적재된 로그를 파일에 쓰고 생성한 뒤에 적재된 로그 값을 지우고 다음 로그 파일 생성 시간을 계산하여 기억한다.
또 다른 문제...!
위에서 생각한 대안을 실행에 옮기려고 했으나 곰곰이 생각해 보니 이 또한 문제가 있을 것 같다는 생각이 들었다. 생각한 문제는 다음과 같다.
대안책의 문제점
- 동시성 컨트롤
싱글톤 객체로 읽기/쓰기를 공유하다 보니 5분 단위로 적재된 로그를 파일로 생성하고 값을 비울 때, 시간이 지난 로그가 파일에 쓰이거나, 로그가 유실될 위험이 있다.- 관리의 문제
먼저, 로그를 관리하는 객체를 직접 생성하였으니, 객체의 관리 또한 직접 해주어야 한다. 로그 적재, 파일에 쓰고 생성하기 위한 파일 객체 관리, 더불어 1번에서 동시성 문제 해결을 위한 방안을 구상하고 관리 등등...
굳이 로그에 최적화된 logback을 대신해서 로그를 남기기 위해 대안책을 쓰고 거기서 발생하는 문제점들을 해결하기 위해 또 해결방안을 구상해야하는 상황이 올 것 같아 결국 생각한 대안은 실행하기에 어려움이 있다고 판단하여 다시 방법을 찾기 위해 고민을 거듭한 끝에 작은 실마리를 찾게 되는데... (다음 편에 계속)
-ing