개발 갈무리

1. 이슈: config로 쓰고 있던 google sheet 문서가 손상되어 접근이 불가능한 상태. 사본 만들기 및 import range 함수를 통한 불러오기도 내부 에러로 실패. 중요한 hourly dag였기 때문에 바로 fix하고 배치가 돌아야 하는 상황.

2. 추정 원인: 구글 내부 에러(잦은 api 호출 등으로 막히는 상황도 고려했으나 그 정도의 대량 호출은 없었음. 구글 드라이브 인스턴스가 죽었다고 하기에는 소유자의 다른 문서들은 잘 열리는 상황. 저장중 모종의 이유로 인해 손상된 것으로 보임.)

3. 해결: daily로 google sheet로 된 모든 config를 S3로 xlsx로 백업하는 dag가 있어 해당 파일을 통해 복원. 권한 등의 적절한 복원을 위해 '편집자'는 confluence 등에 별도 작성할 필요가 있음

교훈: 외부화된 config는 손상되거나 접근이 불가능해질 경우 대처가 안 되므로 항상 백업을 진행하는 것이 좋음

cf) google sheet에 대한 api 접근은 은근히 많이 실패하는 편이다. queue limit과도 별 상관없고 짧은 기간 동안 특정 region에 할당된 인스턴스가 죽으면서 발생하는 것으로 보였다. N mins 단위로 도는 배치에서는 이중삼중으로 retry를 할 필요가 있다. 현재 진행하는 프로젝트에서는 여러 gcp project의 service account를 통해 retry를 할 수 있게 구성했다. 그럼에도 불구하고 문서 자체가 손상되면 어쩔 수가 없다. 원본 문서는 다음날 복구 되었으나, deprecated 처리했다.

1. 내가 할 수 있는 일과 내가 해야 되는 일의 범주 차이

  일의 주체가 고민되는 이유는 궁극적으로 R&R이 명확하지 않아서이다. R&R이 명확하지 않다는 것은 다음과 같은 케이스로 나눠보자.

i) 업무 프로세스 자체가 실적, 책임 소재의 회색 영역에 있는 경우

ii) 업무 프로세스는 명확하지만, 각 프로세스별 R&R이 없는 경우

iii) 업무 프로세스가 명확하지 않은 경우

  i의 경우엔 일의 임팩트가 강하지 않기 때문에 어디로든 배정되지 않았을 확률이 높다. 내가 목마른 사람이 아니라면 굳이 우물을 팔 필요가 없는 일이다. ii의 경우 R&R을 정할만한 윗 사람을 찾아서 issue raise를 해야 한다. R&R이 의도대로 정리되길 원한다면 명확한 프로세스라도 issue raise를 할 때, 내가 의도하고 이해하는 형태로 정리할 필요가 있다. iii의 경우는 서순에 따른 task를 정리하고 각 Role의 자리를 대략적으로라도 만들면서 이해당사자들과 각 role의 이해도를 맞춰야 한다. ii, iii의 경우 결국 process가 정리되는데 이때 내가 해야 되는 일인지에 더 초점을 맞춰야 한다.

  개발자(실무 수행자)에 빌붙는 중간자가 많은 이유는, 할 수 있기 때문에 해줬는데 그 공을 다른 사람이 가져가기 때문이다. 결국 실무 수행자는 실제 생산해내는 가치에 비해 과소평가 되기 십상인데, 이렇게 되는 본질적인 이유는 '내가 할 수 있기 때문에 해줘서'라고 본다. 할 수 있기 때문에 해주는 순간 그 process의 책임자는 개발자가 되고 performance는 process를 관리했던 사람이 내는 것으로 인식되는 경향이 있기 때문이다.

2. 할 수 있지만 해서는 안 되는 일

  따라서 개발자는 할 수 있는 것과 해야 되는 일을 명확히 구분해야만, 덜 괴로울 수 있다. 이것을 위해 문서를 정리해야 한다면 기꺼이 정리해야만 공을 뺏기고 과를 뒤집어 씌워지는 경우를 피할 수 있다. 특히 할 수 있지만 해서는 안 되는 일은, 프로세스 자체가 장기적인 변화 관리가 필요한데 내가 해야 되는 일은 아닌 경우이다. 생각보다 이런 프로세스들의 변화 관리는 한번에 찾아오고, 이를 소화하기 위한 리소스는 매번 내가 해야 할 일이 급할 때 한번에 온다. 이 일이 내가 해야 되는 일인지 파악되기 전에 무작정 하게 되면, 피라미들에게만 유명한 만능 잡부가 된다.

  만능 잡부가 되는 게 좋지 않은 이유는, '잡'일만 그렇게 찾아오기 때문이다. 그게 진정 실적이 되는 일이라면, 여기로 넘어오지 않을 확률이 높다. 리소스는 많이 드는데 실적은 잘 안 되는, 하지만 소소하게 피라미들에게는 그럭저럭 먹을만한 정도의 귀찮은 일들은 많이 한다고 스스로에게 도움이 되지는 않는다.

3. 사일로 완화를 위한 프로세스 관리

  이런 일들을 많이 해주면 개인적인 보람이 있을지도 모르겠다. 다만 조직의 관점에서는 생산성 없는 앵무새들에게 유인을 제공하는 행위가 될 수 있다. 성과가 없는 사람이 self-manage를 하지 않으면, 그 사람은 도태되도록 두어야 마땅하다. 이것이 실력주의나 공리주의처럼 들릴 수도 있다. 하지만 대부분 장기적인 성과는 일에 재능이 있느냐 보다도, 일에 얼마나 몰입하느냐에 더 의존한다. 조직은 그어놓은 선때문에 흥하고 그 선에 의해 쪼개진다. 쪼개지는 것을 막기 위해선, 더 몰입하고 실제 생산성을 추구할 수 있게 유인을 제공해야 한다.

   실제 생산성을 관찰하기 위해서는 업무 방향성을 관찰할 수 있는 도구가 필요하다. 또한 그 도구는 업무 투명성의 '비용'을 효과적으로 낮출 수 있어야 한다. 누가 어떤 일을 했는지, 그 일의 결과를 통해 어떤 것들을 할 수 있는지, 나는 왜 이 일을 해야 하는지 쉽게 알 수 있어야 한다. 그래야 협력 단계에서 각자의 할 일과 성과를 공정하게, 기꺼이 지게 할 수 있기 때문이다. Jira, confluence, redmine 등등 업무 관리 툴은 그런 방향성을 가지고 관리, 업데이트 될 필요가 있다.

날짜별 변환. 날짜 형식은 yyyyMMdd에서 조절

TODAY: TIME_FORMAT(TIMESTAMPADD(HOUR, 9, CURRENT_TIMESTAMP), 'yyyyMMdd')
D-1: TIME_FORMAT(TIMESTAMPADD(DAY, -1, TIMESTAMPADD(HOUR, 9, CURRENT_TIMESTAMP)), 'yyyyMMdd')
D-7: TIME_FORMAT(TIMESTAMPADD(DAY, -7, TIMESTAMPADD(HOUR, 9, CURRENT_TIMESTAMP)), 'yyyyMMdd')
M-1: TIME_FORMAT(TIMESTAMPADD(MONTH, -1, TIMESTAMPADD(HOUR, 9, CURRENT_TIMESTAMP)), 'yyyyMMdd')

https://backlog.com/git-tutorial/kr/

기업 관련

1. 기업의 최종 미션이 명확해야 한다.
2. 사람을 잘 뽑는 것도 중요하지만 뽑은 사람을 성공으로 이끌 수 있어야 한다.
 - 안 되는 대부분의 이유는 원래 있던 사람이 기득권을 유지하려고 하기 때문
 - stage마다 필요한 사람이 다르다는 것을 이해하고 인지의 제약을 벗어나야 한다.
 - 내가 키워놓은 열매를 신규 인원이 와서 따먹는다는 생각 X
 - 내가 성장해야 회사가 성장하고, 회사가 성장해야 내가 성장한다.

업무 관련

1. 사람은 심리적인 상처를 과장하게 마련. 그런 부분을 주의하고 객관적으로 볼 수 있어야 한다.

 - 클라우드 비용으로 해고된 사람은 다른 회사에 가서도 클라우드 도입 시 비용이 커서 안 된다고 말한다.

2. 문제를 해결 할 때 솔루션에 집중하지 말고 얼마나 중요한 문제인지를 먼저 봐야 한다.

 - 주어진 문제만 솔루션을 내는 수동적인 자세가 아닌 문제 자체가 어떤 히스토리를 갖고 얼마나 중요한지를 먼저 체크

for /f “skip=1 tokens=3” %%s in (‘query user %username%’) do ( %windir%\System32\tscon.exe %%s /dest:console /password:password )

bat파일로 저장 후 관리자 권한 실행 => RDP로 붙은 세션 날려버림

다시 잠그려는 경우

Rundll32.exe user32.dll, LockWorkStation

https://docs.microsoft.com/ko-kr/windows-server/administration/windows-commands/tscon

VNC를 사용하지 않는 사이트에서는 프레임워크에 포함하여 사고를 미연에 방지할 수 있을 듯

Input 데이터들을 받다보면, 주소를 매핑해야 되는 케이스가 생기는데

주소는 input이 일정하지 않은 편이다.

서울시 강남구 홍길동7로 3-1 식으로 도로명으로 쓰거나

그냥 서울을 빼고 강남구 홍길동7로 이렇게 써있을 때도 있고

지번주소로 적힐 때도 있다.

특히 영어로 적히게 되면 순서까지 바뀌게 된다.

그래서 차라리 검색 API로 keyword를 보내고 거기서 return되는 값으로 일원화 하는 게 편하다.

https://www.juso.go.kr/addrlink/addrEngApi.do?confmKey={승인키}&currentPage=1&countPerPage=10&keyword=

나같은 경우는 외국의 호텔 정보와 비교해야 되는 케이스가 있어서

마스터의 한글 주소가 있으면 영어로 변환하여 사용했다.

API 정보 링크

https://www.juso.go.kr/addrlink/devAddrLinkRequestGuide.do?menu=roadApi 

----------------------------------------------------------------------------------------------------

세계주소를 체크하고 싶다면 Google Map API를 써보자[2022-06-14 기준 1000건당 17달러가 과금됨. 너무 비싸다 ㅠ]

https://maps.googleapis.com/maps/api/place/findplacefromtext/json
  ?fields=formatted_address%2Cname%2Crating%2Copening_hours%2Cgeometry
  &input={KEYWORD}
  &inputtype=textquery
  &key={API_KEY}

--------------------------------------------

결과 SAMPLE

{
   "candidates" : [
      {
         "formatted_address" : "대한민국 서울특별시 중구 청계천로 100 시그니쳐타워 서관 9층",
         "geometry" : {
            "location" : {
               "lat" : 37.5674863,
               "lng" : 126.9884026
            },
            "viewport" : {
               "northeast" : {
                  "lat" : 37.56883612989273,
                  "lng" : 126.9897524298927
               },
               "southwest" : {
                  "lat" : 37.56613647010728,
                  "lng" : 126.9870527701073
               }
            }
         },
         "name" : "시그니쳐 타워",
         "opening_hours" : {
            "open_now" : false
         },
         "rating" : 4.2
      }
   ],
   "status" : "OK"
}