팀플) 혜성 예측 로직 구상.

뭐 코드를 작성하고 그런게 아니고 계획을 좀 제대로 짜고 데이터의 흐름이나 계산 로직의 계획? 같은거다.

혜성 예측

• 데이터 요청 및 계산: 혜성의 예측 데이터를 계산하기 위해 필요한 모든 데이터를 특정 기간 동안 요청하고, 필요한 모든 요소(혜성의 궤도 요소, 접근 거리, S-O-T 등)를 고려해서 계산 시작.
• 시간이 오래 걸리더라도 전체 예측 진행: 이 단계에서 계산이 조금 오래 걸리더라도 괜찮음. 왜냐하면 계산은 주기적으로(예: 1년마다, 혹은 짧은 혜성 주기마다) 이루어지고, 사용자 요청이 들어오는 순간 빠르게 제공할 수 있는 게 핵심.
• 계산 결과를 데이터베이스에 저장: 계산이 끝난 예측 결과를 데이터베이스에 저장해둬. 이렇게 하면, 사용자들이 특정 혜성의 접근 이벤트를 요청할 때 이미 계산된 예측 데이터를 빠르게 제공할 수 있음.
• 사용자 요청에 빠르게 응답: 사용자가 특정 혜성 이벤트 예측을 요청할 경우, 데이터베이스에 저장된 예측 데이터를 빠르게 찾아서 제공하면 돼. 이렇게 하면 사용자 응답 시간이 훨씬 줄어들고 시스템의 부담이 덜함.

혜성이 내가 생각한 것 보다 훨씬 기간이 길어서, 행성처럼 DB에 로우데이터로 저장하는 식으로의 접근은 좀 아닌 것 같다는 생각이 들었다.

그래서 앞서 언급한 것 처럼. 제일 좋은 계산을 하기 위해서 제일 양질의 데이터를 찾아야하고(이 때문에 1년씩 API요청하거나 혜성주기만큼의 요청이 필요함.), 그 양질의 데이터로 정밀한 계산 로직이 필요하다. 그렇다면 필연적으로 시간이 오래 걸릴 것이다. 왜? 계산 로직이 상당히 복잡할 것 같으니까. 그럼 사용자는 기다리는 시간이 길어질거고 짜증날거다. 그러니까 미리 계산을 해두고 DB에 저장을 해두고 요청시 바로바로 보여주는 방식이 좋을 것 같다.

그리고 에측에도 평가를 해두는게 좋을듯 하다. 혜성의 주기가 긴 경우에는 정밀하게 계산을 하려면 (혜성 주기 ex.60)년의 데이터가 있어야하는데 이건 현실적으로 DB 저장도 내 상황에서는 부담스럽고 API 요청도 불가능하다. 그래서 DB에 게산 결과를 저장할 때, 평가하는 계산 로직도 넣어서 정밀도 낮음, 보통, 높음을 표기하는게 좋을 것 같다.

다른 로직들을 구상하면서 경험치가 많이 쌓였으니 혜성은 좀 시간이 덜 걸렸으면 좋겠다는 소박한 희망을 안고 밥 먹어야지.

---

우리 팀원은 잘 하고 있을까. 슬슬 걱정된다. 백엔드를 다 떠맡게 되어서 화면을 그리고 있으라고 했는데 4명중 두명이 거의 손을 놓고 있다. 내 할 것만 잘하면 된다는 식으로 열심히는 하고 있는데 걱정이 슬슬된다..