⌨️ 유연한 사고?
유연하게 사고하는 것은 생각보다 문제 해결에 있어서 중요하다고 생각합니다.
생각보다 사고는 더욱 경직되어 있어서 유연한가? 싶어도 돌아보면 딱딱한 상태더군요.
🤔 불필요한 데이터를 삭제하는 일
요구사항을 구현하기 위해 만든 기능에서, 불필요한 데이터가 남는 상황을 발견했습니다.
이 외에도 간간히 이런 것들에 대해 고민을 한 적이 있습니다.
예를 들어 이미 올라온 파일(이미지나 동영상) 등의 참조가 변경되어 더 이상 사용하지 않는 자료가 되어 버린다든지
어찌 됐든 나의 저장소로 차지하는 것에 있어서 해결을 하고 싶었던 적이 있었습니다.
✅ 지연 처리가 나쁜 건 아니잖아?
제가 꽤 자주 하는 실수 중 하나가 바로 '즉각성'에 너무 과몰입하는 것입니다.
즉각적으로 요청과 응답이 주고받아지고 그 데이터가 명확히 반영돼야 한다는 것이죠.
저 외에도 꽤 많이들 저연차에 그런 경우가 많지 않을까 합니다.
시간이 지나고 그냥 컴퓨터를 하고 있었습니다. 어느날 컴퓨터를 정리하고 싶어서 몰아서 안 쓰는 프로그램들을 쭉 삭제를 했습니다.
이때 갑자기 예전에 했던 고민이 생각나더군요?
아 그때도 안 쓰는 파일을 몰아서 한 번에 처리해도 됐겠구나 하고요
제 말은 이게 좋은 방법이다 정답이다라는 건 아닙니다. 그냥 다른 방법이 당시에는 안 떠올랐다가 떠올랐음을 말씀드리고 싶은 겁니다.
✅ 즉각처리와 지연처리에 대한 고민
이제 둘의 방식에 대해 고민하기 시작했습니다.
1. 즉각 처리
// 즉각처리
public void update() {
... 게시물을 가져온다.
... 게시물을 업데이트 한다.
... 게시물에 원래 있던 파일을 삭제한다.
... 게시물에 새로운 파일을 업데이트 한다.
}
코드의 복잡도는 매번 달라질 수 있으나, 저는 이런 방식으로 처리를 했었습니다.
여기서 이제
2. 지연 처리
//지연처리
public void update() {
...게시물을 가져온다.
...게시물을 업데이트한다.
...새로운 파일을 매핑한다.
}
@Scheduled(cron= ...)
public void garbage() {
...주기적으로 파일을 정리한다.
}
이런 식의 방식이 떠오른 겁니다.
둘 다 적용해 봤으나.
막상 적용하니 또 생각지 못한 변수가 있었습니다.
✅ 주기적으로 파일 정리?
참 신기합니다 A를 다르게 해보고 싶어서 B를 했으나 B의 단점을 커버하기 위해 다시 A를 사용하고..
이런 일이 이쪽에선 꽤 비일비재한 것 같습니다.
요는 결국 몰아서 처리인데,
게시물이 많아지고 파일이 많아질수록 gabage()가 탐색하는 양이 점점 많아진다는 것이었습니다.
물론 일정 부분 캐싱이나 이런 걸 통해 중복작업을 없앨 순 있으나,
어찌 1년 전 2년 전 글에 파일 변경이 없을 거라고 장담할 수 있겠습니까..
다방면으로 고민하다 다시 즉각 처리하는 것으로 돌아갔습니다 :)
⭐️ 중요한 것은 그럼에도 다양하게 생각하는 것
저는 다양하게 생각하는 것이 중요하다고 판단합니다.
비록 그게 효율적이지 못하고 잘못된 방식이라 하더라도 방법적인 것에 대해서부터 폐쇄적이고 싶진 않습니다.
예전엔 지구평평이들이 정론이었으나 지금은 지구둥글이들이 정론입니다.
그러나 또 어떻게 될지는 모르는 일입니다.
내가 옳다고 믿고 아니라고 반론하는 것들이 나를 지구평평이로 만드는 게 아닐까 고민해볼 필요가 있지 않을까요?
