log 2022-01-11
blog
생각해보니, 스크린샷이 문제다. 회사 계정으로 깃랩을 따로 파서 올릴까? 깃헙 이슈처럼 올릴 수 있긴 할까? 게다가 그런 주소로 올려도 공개 포스트에서는 볼 수가 없다. 흠… 그냥 언젠가 git secret 써서 private 포스트도 올리도록 하는 쪽이 나을 듯하다.
잡생각
카페에서 스벅 사이렌 오더로 팀원분이 주문을 하셨는데, 갑자기 주문 취소가 되었다. 왜인가 하고 결국 매장 주문을 했는데, 처음엔 내가 주문한 메뉴 때문인가 했더니 아니고 오렌지가 없어서라고 한다(여전히 확실하지 않음). 그런데 문득 든 생각은, 결국 이런 온라인 주문, 이러한 시스템들은 현실의 시스템을 추상화해놓은 것인데, 현실에서 일어나는 온갖 크고 작은 예외들은 도저히 코드로는 전부 표현하기가 어려울 것이라는 생각이 들었다.
이러한 유연한 상황을 대처하는 방법은 머신러닝 밖에는 없는 것일까??
어쨌든, 그럼에도 불구하고 현실에는 현실의 시스템을 추상화시키는 수많은 소프트웨어들이 있고 동작한다. 배민도 주문했다가 무슨 일이 나면 전화로 해결하듯이 이런 fallback처리로 가능한 것일까.
또 생각해보면, 물리적 공간에서 실현될 수 없는 부분이 소프트웨어 시스템에서 구현되기도 한다. 거래소가 그렇다. 수많은 사람들이 동시에 사고 파는 상황은 너무나 복잡해서 정확하고 빠르게 실행될 수 없다. 그런데 거래소는 그러한 작업을 가능하게 해준다.
이 물리적 현실과 소프트웨어 세계 사이의 위상 차이란 흥미로운 것 같다.
study
rxjs 공부 7 - scheduler
지난번에 이어서 scheduler 예제를 추가 및 실행했고, 설명 읽었지만, 적절한 예제를 생각해보고싶은데, 이걸 왜 쓰는거고 어떻게 쓰는건지 잘 이해가 되질 않는다. 그냥 이름으로 생각하면 스케줄러로 뭔가 cron job같은 작업 처리를 만들거나 할 수 있을 듯한데, 예시나 설명을 보면 그런 개념이 아닌 듯 하다.
일단은 이렇게만 해 두고, 먼저 rxjs를 활용한 순수 대기 시스템을 만들어서 연습해보는게 어떨까 싶다. 그렇게 하고 나서, 다중화에 대한 특성 확인 또는 기존 api 사용법 공유받아서 실행해보고 진행 등..
클린 아키텍처 읽기
생산성에 관한 지표: (시간/릴리즈에 따른)
- 개발자 수
- 라인 수
- 라인당 비용 (시간이라던가?)
- 생산성 (정확히 어떻게 측정?)
이런 지표를 현재 시스템에서 볼 수 있나??
job
GOP-14062
대기 상태와 같은 정보를 추가해야 하므로, db에도 변경이 필요할까? redis만 쓴다고 한다면 굳이 필요없을수도. 만약 db 스키마 변경같은 작업을 한다면 flyway 문서를 참고해야 한다.
https://develop.sbsvc.online/1/onlineDocList.do 위 api 문서를 보면, ST41(서비스 용량초과) 또는 ST42(SYSTEM BUSY)를 보고 그에 따라 동작해도 될듯도 한데.
추가 고려사항에 따라 흐름 재설계가 필요
- api별 제한이 아닌, 전체 계좌 등록 프로세스에 대한 인원수 제한 쪽으로 고려
- 대기 상태에 대한 실시간 정보 (client polling 또는 server push) (서버 푸시가 더 나을 것. 어떻게 하는지 알아봐야함.)
- 다중 연결 또는 ars와 같은 외부 앱 전환에 따른 연결 끊김 등의 케이스 고려
- 대기 종료에 따른 진행
GOP-14062 작업 - 기존 api 테스트
못함.
Comments