교통사고 과실 비율 손해액 계산 구글시트

최근에 교통사고가 발생했습니다.
교차로에서 발생한 사고인데요, 작은 도로에서 우회전으로 나가려는 중이었고, 상대는 큰 도로에서 좌회전으로 제가 있던 도로로 들어오려는 상황에 두 차의 정면의 구석부분이 부딪쳤습니다. 동네에서 벌어진, 작은 사고 였습니다.

찾아보니 비슷한 상황은 비정형으로 분류되어 있습니다. https://accident.knia.or.kr/special-content?chartNo=C6

과실 비율을 따지는 일은 서로 의견이 다른 상황입니다.
저는 제가 먼저 들어와 있는 상황에 중앙선을 물고 들어왔으니 중앙선 침범 또는 교차로 통행방법 위반, 전방주의 소홀, 교차로에서 서행 또는 일시정지 위반 등을 들어 상대 100%를 주장하고 있습니다. 상대는 대로에서 운행중인 차와 소로에서 운행중인 차가 부딪친 상황이니 저에게 과실이 크다고 주장하는 상황입니다. 따라서 이 사건은 분쟁심의위원회(자동차사고 과실비율 분쟁심의위원회, https://accident.knia.or.kr/) 에 판단을 구하려고 합니다.

교통사고 합의시에 과실 비율에 따른 대물보상과 대인손해보상의 룰이 조금 복잡하여 다음과 같은 시트를 작성했습니다. 필요하시다면 복제해서 사용하시면 되겠습니다.

이 시트에 적용된 룰은 다음과 같습니다.

  1. 대물보상은 서로의 총 대물손해를 합하여 과실비율로 나눈다.
  2. 대인보상 부분은 합의하에 각자 또는 서로 처리할 수 있다. (시트 내 체크박스)
  3. 대인보상을 서로 처리하기로 동의한 경우 과실이 100%인 사람은 모든 대인보상을 담당한다. 과실 100%가 아니라면 서로 다른 사람의 대인손해에 대해 100% 보상한다.

참고로 2023년에는 경상이라면 각자의 대인보상은 과실비율대로 나뉜다(https://www.fnnews.com/news/202109301020597876) 고 하니 미래에서 오신 분들은 이 시트를 그대로 사용하시면 안됩니다.

https://docs.google.com/spreadsheets/d/1utMv-gbjnaxlaWVwtJfjEZdtioNQUxkp63vH1GnQVhc/edit#gid=0

AWS Certified Solutions Architect – Associate 자격 취득

꾸준히 AWS관련 업무를 맡아왔다. 업무로 다뤄 본 영역은 잘 알지만 다른 영역들은 전혀 모르는 부분들이 많았다. 매뉴얼을 읽을 때마다 전체를 조망하는데 어려움을 느꼈고 한번쯤은 몰입해 살펴봐야겠다고 생각해왔다.

2020년 11월 쯤 되니 한 해가 가는 것에 대한 조바심이 들었다. 가시적인, 스스로를 위한 성과가 필요하다고 생각했다. 그래서 미뤄뒀던 AWS SAA자격 취득을 준비했다.

학습자료

우선 예전 할인 때 사놓은 Udemy의 관련강의를 들었다. 다만 PPT를 읽는 수준에 그쳤기 때문에 만족도는 생각보다 크지 않았다. 대신 AWS SAA-C02 Study Guide라는 Github리포를 프린트해서 자주 읽었다. 이 요약본보다 더 깊은 공부가 필요한 경우는 AWS 공식 블로그와 매뉴얼, 예전에 받아놓은 AWS 관련 EBook을 함께 읽었다.

시험

2021년 1월 2일에 시험을 봤다. 사실 2020년을 마무리하면서 보려고 했는데 정리가 좀 덜되어서 연초로 옮겨 본 것이었다. 주로 영어자료를 참고했기 때문에 시험은 영어로 쳤다.

시험은 비대면으로 진행했다. 내 방에서 진행하는 비대면 시험은 처음이어서 이런 저런 절차를 처리하는데 시간이 걸렸다. 우선 책상의 모든 물건을 치워야 했다. 덕분에 새해맞이 책상정리를 하게 됐다. 또 감독관과 영어로 채팅을 하는 것은 예상하지 못해서 좀 당황했다. 신원확인은 여권을 카메라에 보는 방식으로 진행했고 책상위의 “모든” 물건은 바닥으로 옮겼다. 방이 좀 지저분했는데 노트북을 들고 방의 모든 구석구석을 보여줘야 해서 부끄러웠다. 또 예상치 못한 잡음을 방지하기 위해 창문을 닫았다. 긴장 때문에 시험 전부터 식은 땀이 났다.

시험문제는 어려웠다. 실은 공부가 많이 모자란 탓 이었다. 푸는 도중에 ‘떨어질 수도 있겠다’ 생각을 두어번 했다. 역시나 점수는 그다지 만족스럽지 않았다.

결과

793/720 으로 합격했다. 크게 더 떨어지는 부분은 없이 전체적으로 못본 것..으로 나왔다.

회고

영어가 어려웠다기 보다는 시나리오 위주의 문제를 풀기에 스터디 가이드를 외우는 것으로는 부족했다고 생각한다. 대신 AWS공식블로그의 사례연구가 큰 도움이 되었다. 비슷하지만 조금 다른 특성들에 대해서는 차이점에 대해 정확하게 아는 것이 중요하고 이게 문제로는 어떻게 나올지 상상해보는 것이 좋겠다는 생각이 들었다.

사용하지 못한 기술들이 있기 때문에 다시 공부하지 않으면 잊혀지기 쉬울 듯 하다. 다음 단계의 시험을 조만간 준비해야 공부가 수월할 것 같다.

ECS – API애플리케이션 – S3 웹리소스 고정아이피 구성

ECS로 구성된 애플리케이션의 웹 리소스의 고정아이피 구성이 필요했다. 가끔 유용하게 활용할 수 있는 사례라 구성도를 따로 그려봤다.

문제정의

  • 애플리케이션 서버는 ECS – Fargate – ALB 환경으로 구축
  • S3에 웹 리소스가 배포됨.
  • 애플리케이션 서버와 웹리소스에 고정아이피 주소 필요
  • 백엔드와의 연결은 HTTP만 사용해도 됨.

해결

  • Network Load Balancer에 고정아이피를 설정
  • NLB는 포트라우팅만 지원하므로 Nginx의 virtual server 설정으로 애플리케이션과 웹리소스 라우팅
  • Task Definition상 Nginx와 애플리케이션 서버를 하나에 둠
  • Nginx는 리버스프록시(localhost)로 애플리케이션 연결, S3와의 연결도 리모트 리버스프록시 사용.
  • S3는 Bucket Policy를 이용해 VPC고정으로 연결

구성도

참고

AWS ALB Target Group의 Draining 이 너무 길다면

최근 ECS를 도입하면서 Rolling Deploy 를 적용했다. 이전에는 EC2인스턴스마다 방문하면서 배포를 했다면 이제는 새로운 Fargate기반 태스크가 생성되면서 기존 태스크는 없애는 방식으로 배포된다.

테스트를 진행하다보니 ALB Target Group에 등록된 아이템이 Draining에 걸리는 시간이 긴 것이 눈에 들어왔다. 기본값으로 이 값은 300초가 주어지기 때문에 트래픽이 많지 않거나 커넥션을 오래 유지할 필요가 없다면 이 시간만큼 Fargate인스턴스를 더 사용하는 셈이다.

타겟그룹의 Draining에 걸리는 시간은 “Deregistration delay”항목에서 수정할 수 있다.

참고: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay

Docker Entrypoint와 쉘 함수의 사용

Docker 컨테이너는 Entrypoint를 가지고 있어서, 컨테이너를 하나의 실행파일처럼 동작할 수 있게 해준다.

An ENTRYPOINT allows you to configure a container that will run as an executable.

https://docs.docker.com/engine/reference/builder/#entrypoint

이를 이용해 때때로 활용하는 기법이 있는데, Entrypoint를 쉘 함수로 엮어 사용하는 방법이다.

최근 Jenkins에 AWSCLI v2를 사용해야할 일이 있었다. 이미 aws v1이 시스템 전체에 설치되어 운영되고 있기 때문에 명령어 충돌을 피하기 위해 이 방법을 사용했다.

#!/bin/env bash -x 

docker pull amazon/aws-cli
aws () { docker run --rm amazon/aws-cli $@ }

참고로 Interactive Shell에서는 alias를 사용해도 되지만, Non-Interactive 쉘에서 alias를 사용하려면 shopt 설정이 필요하다.