요즘에 자주 들리는 뉴스, 아니 어찌보면 몇해전부터 듣고 왔던 이야기들… 유리지갑 직장인들, 장시간 노동에 업계에 몇년을 있어도 실소득이 오르지 않는 기이한 현상. 이러다보니 너도나도 주머니에 들어도는 돈을 중요시하는 시점에서 살게된다.
이왕이면 연봉이나 복지에 안정적인 직장인 보다는, 아니 ‘안정적인 직장’ 이라는 개념이 없어진지 오래고 복지라는 것도 기껏해야 돈 몇푼 더 지원해주는 정도이다 보니 너도나도 이제는 실질적인 손에 쥐는 돈에 눈이 돌아갈 수밖에 없는 세상.
그런데, 문제는 그렇게 실질적인 손에 쥐는 돈을 얻기 위해서 지켜야하는 것들은 안중에도 없고 좋은 것만 가지고 갈려고하는 인간들이 넘쳐나는데 문제가 있다. 이러한 기이한 현상에는 돈에 미친 정신병력 보다는 ‘남보다 우월적 지위’를 획득하거나 그것을 남에게 증명함으로써 과거 조선시대의 양반/상놈 계급화를 해야지만 자신의 존재감을 드러낼수 있다는 또 다른 정신병력 증상들…
그것을 앞세우는 이들이 바로 한국의 IT 개발자들이다.
IT 프리 개발자 등급 = 몇년 됐냐..
한국의 IT 프리 개발자들이 가지는 관심은 오직 하나다.
한국 IT 프리 개발자들의 병폐중에 하나가 바로 ‘등급’ 이다. 등급의 기준은 프리랜서로서 얼마만큼의 시간을 보냈냐하는 것이다. 이것을 IT 프리 개발자들은 ‘경력’ 이라고 떠들지만 경력이라는 건 그만큼의 능력이 뒷받침되어야 한다는 것을 전재로 함으로 IT 프리 개발자들이 말하는 등급과는 거리가 있다.
초급/중급/고급/특급… 이건 곧 IT 프리 개발자로서 몇년차 정도의 의미일 뿐이다. 문제는 이렇게 몇년정도 됐는에 따라서 돈의 지급량을 결정하는 산업은 그 어디에도 없다.
한국 사회는 경쟁사회다. 거기다 자본주의와 결합해 ‘능력 경쟁 사회’ 다. 능력이 좋으면 더 많은 부를 얻는 것이 당연한 공식이다. 한 분야에서 몇년 일을 하였다고 해서 그것 곧 능력을 보장하지 않는다. 이력서가 아무리 화려하다고 해도 회사에 입사하기 위해서는 면접을 봐야 한다. 기술적인 시험을 본다거나 아니면 대면 상담면접을 한다거나 뭐가 어떻게 되었든 간에 그 사람이 과연 그만한 경력을 가지고 있는지를 테스트 받는다.
하지만 한국의 IT 프리 프리랜서는 그걸 하지 않는다. 초급 500, 중급 700, 고급 900, 특급 1200. 10년이상했으니 고급 정도는 될듯하고 그러니 나는 900은 받아야 한다는 사고 방식. 그 어떤 산업분야에도 없는 이런 해괴하기 짝없는 돈 계산법…
프리 개발자 = 노동자??
그 어떤 산업에도 없는 해괴한 기준의 돈 계산 방법. 그러다보니 너도나도 뭐가 뭔지 모르는 사람들이 업계에 유입되고, 그렇게 몇년 있다보니 ‘나도 개발자’라고 하지만 정작 본질은 ‘코더’ 를 못 벗어나는 인간들이 허다 한 현실. 더 웃긴건 ‘코더’ 라고 부르면 득달같이 ‘어디 개발자에게 코더라고 하냐’ 하면서 눈에 불을 키는데, 정작 세상 돌아가는 건 몰라도 IT 기술 발전이 어떻게 되고 있는지, 더 좁게는 Java 가 어떻게 바뀌고 있는지 조차도 모르는채 ‘금융권 플젝 10년’ 만 외치면서 개발자다라고 우기는게 전부인데다 뭐가 됐던 ‘화면만 나오면 됐다’ 를 외치는 그들에게 ‘코더’ 라고 그 누구도 알려주지 않는 짬짜미까지…
이제 이들은 능력이고 뭐고는 둘째고 고급에 900을 외치면서, 이제는 법마져 내게 유리한대로 해석하고 그래서 불쌍하고 억울한 인간으로 둔갑하는데 주저함이 없는 저렬함마져 보여주기에 이른다.
프리랜서는 법적으로 ‘도급계약자’ 에 속한다. 더 넗게는 ‘용역계약’ 인데, 용역계약에는 노동계약과 도급계약으로 분류된다. 노동계약은 다 알고 있듯이 정규직이라고 보면 된다. 노동법에 적용를 받으며 4대보험을 납부해야한다. 대부분 연봉계약자, 직장인들이 여기에 속한다. 하지만 도급계약은 노동계약과는 달리 ‘민사합의계약’으로 분류된다. 프리랜서는 기본적으로 도급계약에 속한다. 따라서 노동자가 될 수가 없다.
노동자와 도급계약자, 즉 프리랜서와 가장 큰 차이는 세법에 있다. 세금관련해서 다르다. 노동자는 4대보험이 의무가입이다. 사용자가 절반을 내고 노동자가 절반을 내는 형식으로해서 세금을 낸다. 연봉계약에는 4대보험까지 포함되어 있기 때문에 월급명세서에는 4대보험 공제가 되어 실수령액이 결정된다. 하지만 프리랜서는 도급계약자, 세법상으로는 ‘개인사업자’ 속한다. 계약금액의 3.3%만 공제하고 지급 받는다. 별도의 세금을 내는 건 없다. (정확하게 몇년전에 법이 바뀌어서 고용보험, 산재보험을 납부해야하나 안할 수도 있다.)
프리랜서는 도급계약자이다. 세법 외에도 한가지 더 있다. 도급계약은 민사합의 계약이기 때문에 프리랜서가 만들어낸 결과물에 대해서 책임을져야 한다. 이것은 마치 인터넷을 통해서 물건을 구매했는데, 하자가 있어서 환불이 되어야 하는 것과 같다. 결과물이 문제가 있다고 한다면 이에 대한 책임, 민사적으로는 배상책임이 존재한다.
노동자가 받는 돈을 월급이라고 하지만 프리랜서는 ‘단가’ 라고 한다.
또 있다. 노동자는 종속관계 계약이라고 한다. 상급자의 지시에 따라야 한다. 하지만 프리랜서는 그런게 없다. 오히려 상급자가 지시를 하면 안된다. 이것을 한마디로 정의하면 ‘노무를 제공하지 아니 한다’ 로 규정된다. 프리랜서는 노무를 제공하지 않는다. 따라서 출퇴근, 근무장소등을 지정할 수가 없게 된다.
그런데….
돈은 단가로 받고 권리는 노동자… 배상책임도 안지고 9시~6시 칼퇴근 보장..
여기에 ‘거머리 같은’ 인간들의 이면이 나온다. 단지 몇년 일했다고 해서 800, 900 따지면서도 그 결과물에 대해서는 절대로 책임은 안지겠다, 더나가 근무시간을 설정해서 그 시간외에는 절대로 일을 안하겠다. 프리랜서들에게 근무시간이라는 개념도 없지만 그들이 말하는 것은 ‘나는 노동자다’ 라는 거다.
IT 프리 개발자들이다. 더군다나 오래된 프리 개발자들 일수록 이런 인식이 강하다. 얼마간 잇었으니까 단가는 이정도로 받아야하고 자신이 짠 프로그램 개발 소스에 대한 책임은 없고 대충 시간 때우다 퇴근하고…대부분의 SI 프로젝트가 이런 인간들로 다 채워져 있다고 생각하면 맞다. 적어도 대한민국에서는…
얼마나 거머리 같은 인간들인가… 대한민국이 세계에서 사기 범죄가 많다고 하는데, 사기 범죄의 기본이 일은 안하고 남을 등쳐먹는 것인데, 여기에는 내가 일은 안하고 돈은 내가 가지고 간다는 개념이 존재한다. IT 프리 개발자들도 이와 다르지 않다.
자… 잘 생각해보라… 경쟁을 하지 않아도 된다. java 문법을 약간 공부하고 스프링 프레임을 조금 할줄 알면 된다. DTO 구조를 죽어도 못 벗어나는 틀을 가지고 있으니 Controller, Service, Repository 등 나누고 데이터베이스에 쿼리하고 보여주면 된다. 그걸 대충 한 1 ~ 2년 정도면 뭐가 뭔지 대충 알게되고 그때부터는 대충 화면에 나오게만 짜면 그만이다.
코드의 성숙이나 하다못해 유닛 테스트 코드는 작성해서 프로덕트의 품질을 보증하는 일따위는 없어도 된다.
대충 일하면서 돈은 많이 받고 싶은가? 그러면 IT 프리 개발자가 되어라… 사회에 거머리로서 신나게 한 평생을 살 수 있다.
워드프레스(WordPress) 를 사용하고 있는데, 갑자기 화면을 통한 플러그인(Plugin), 코어(Core) 업데이트가 되지 않았다. 보통은 문제 없이 이것이 수행되었는데, 뭔가 문제가 있는건지 파악해봤지만 찾지지는 못했고 그냥 포기해야 하나 하는 찰라에 wp-cli 를 이용하면 업데이트를 모두 할 수 있다는 사실을 알게 됐다.
wp-cli.phar
워드프레스에서 정식으로 배포하는 것 같지는 않다. github 에서 배포 받을 수 있는데, 간단하게 wp-cli.phar 파일을 다운로드 받으면 된다.
MySQL 에서는 각종 지표등을 제공하는데, 이러한 지표를 얻기 위해서는 MySQL 계정이 있어야 한다. 대부분 MySQL 계정을 생성하고 권한을 주는데, 습관처럼 “ALL PRIVLEGES” 를 주는 경우가 많다. 하지만 모든 시스템에서 계정은 최소한의 필요한 권한만 주도록 하는 것이 보안의 시작이다.
오랫동안 민트 리눅스(Mint Linux) 를 데스크탑 운영체제로 사용해왔다. 정확하게는 데스크탑 PC 를 새로 맞춤과 동시에 설치해서 써왔는데, 이번에 데스크탑 PC 를 교체하게 되면서 민트 리눅스를 재설치해야하는 상황이 되어 그 동안 써왔던 민트 리눅스 설정을 기록으로 남긴다.
XFCE 데스크탑
민트 리눅스 데스크탑은 세가지가 존재하는데, 그중에서 XFCE 데스크탑을 사용했다. 이 XFCE 를 만진지도 거의 20년이 넘었다. 솔라리스의 CDE 를 닮아서 쓰기 시작해서 지금까지 쓰고 있다. XFCE 는 가벼우면서도 복잡하지 않는 데스크탑이다. 그러다보니 별로 설정할게 존재하지 않는다. 데스크탑이라는 것이 어짜피 설치하고 나면 쓰는 것만 쓰게 되어 있어서 뭔가 많은 것을 만져야하고 존재하는 것 부터가 거추장스러운 것이다. 단순하면서도 필요한 것만 있는 XFCE 를 그래서 20년 넘게 사용했다.
설치 후 화면
설치 후에 처음 화면은 다음과 같다.
그냥 윈도우처럼 보인다. 이 겉모양은 XFCE 의 본래 모습이 아니다.
XFCE 는 솔라리스의 CDE 를 모티브로 만들어졌다. 그래서 초창기때부터 솔라리스 CDE 의 겉모양을 본떠서 데스크탑을 꾸미기 시작했다. 이 글을 쓰는 목적도 대충이나마 솔라리스CDE 겉모양을 꾸미는 과정을 기록으로 남기기 위서다.
패널 기본 설정
화면 아래 길게 늘어진 바가 패널(Pannel) 이다. 이 패널을 약간 손질해서 기본적인 CDE 모양으로 만들어보자. 패널에 마우스 오른쪽 버튼을 클릭하고 ‘패널 -> 패널 기본 설정’ 으로 들어간다.
패널 기본 설정
첫번째로 해야하는 것은 패널을 추가는 것이다. 설정 창에 맨 위 ‘패널1’ 글자 옆에 + 버튼을 클릭하면 ‘패널2’ 라고 바뀌고 화면 어딘가에 패널 바가 생성된다. 한 화면에 패널을 두개 사용할 것인데, 하나는 화면 위에 올려두고 시작메뉴와 태스크바로 사용하 다른 하나는 솔라리스CDE 처럼 일종의 런처로 사용할 것이다.
‘패널1’ 을 설정창에서 선택하고 ‘표시탭->일반’ 에서 ‘패널 고정’ 체크를 해제해 준다. 그러면 패널 양쪽에 마우스를 올리고 잡을 수 있는 상태가 표시된다. 마우스로 잡은 다음에 화면 위쪽으로 옮겨준다. 다 옮겨 줬으면 ‘패널 고정’ 체크를 해 패널1을 고정 시켜준다.
‘패널 기본 설정’ 창에서 ‘패널2’를 선택하면 화면 어딘가에 패널이 보인다. 이 패널2도 ‘표시탭->일반’ 에서 ‘패널 고정’ 체크를 해제해준다. ‘패널1’ 과는 달리 아무것도 없다보니 패널 가로길이가 작다. 솔라리스CDE 의 런쳐처럼 사용할 것이기에 화면 중앙에 놓는다. 그리고 ‘표시탭->일반’ 에서 길이(%) 를 44 로 조정하고 열 높이(S) 를 59 로 변경한다.
패널2 설정
대충 런쳐로 쓰일 패널이 만들어졌다. 이 패널2에 쓸만한 항목들을 추가해준다.
패널2 항목 추가
대략 왼쪽부터 ‘프로그램 메뉴’, ‘위치’, ‘파이어폭스’,’Xfce터미널’,’작업공간전환기’,’눈동자’,’스크린샷’,’로그아웃’,’휴지통’,’날짜와시간’ 이다.
여기서 중요한 것은 ‘파이어폭’,’Xfce터미널’,’로그아웃’ 은 항목추가에서 ‘실행기’ 추가를 하고 난 다음 ‘실행기’ 설정에서 애플리케이션을 선택해준 것이다. 모든 것이 패널 항목으로만 넣을 수는 없다. 패널 항목 수보다 패널이 길이가 길다면 ‘패널 기본 설정’에서 패널의 가로 길이를 조정해 주면 된다.
모양새
모양새는 ‘설정->모양새’ 에서 찾을 수 있는데, 데스크탑에 기본 페인팅을 바꿀 수 있게 해준다. 과거 솔라리스CDE 와 비슷한 느낌의 페인팅은 회색 바탕에 핑크 창틀이였다. 인터넷에서 XFCE 에 CDE 테마를 검색해서 찾아본 결과 Soaris-9-2.0 이 잘 동작했다.
모양새 많은 페인팅들은 테마(Theme) 라고 하는데, /usr/share/themes 디렉토리에 테마 이름의 디렉토리로 존재한다. 첨부된 파일을 다운받아 압축해제하면 사용할 수 있다.
Solaris-9.2.0 모양새 적용
과거 솔라리스CDE 의 모양새 그대로다. 만일 이 모양새가 맘에 들지 않는다면, 그것이 리눅스와 좀 다른 맛(?) 을 느끼 싶다면 적어도 과거 솔라리스CDE 의 전체 테마와 잘 어울릴만한 것을 찾는다면 기본으로 제공되는 모양새중에 ‘Mint-Y-Legacy-Dark-Pink’ 를 추천해 본다.
Mint-Y-Legacy-Dark-Pink 모양새 테마
기본으로 제공해 주는 모양새 테마가 많기 때문에 원하는 취향에 맞춰 선택해주면 된다.
창 관리자
창 관리자는 창 틀의 모양과 최소,최대,없애기 버튼의 위치등을 변경할 수 있도록 해준다. 창 관리자 역시 테마 리스트들이 있고 원하는 창 모양의 테마를 선택하면 적용 된다. 인터넷을 통해 cdetheme-solaris 를 얻게 되었고 이를 통해서 과거 솔라리스CDE 창틀 모양을 얻을 수 있었다.
솔라리스CDE 테마
cdetheme-solaris 를 맨 처음 적용하면 최소,최대,없애기 버튼의 배치가 위와같지 않다. 그럴땐, 창 관리자에 ‘단추 배치’ 부분에 나온대로 단추를 배치 시켜주면 된다. 필요없는 단추는 숨김으로 옮겨놓으면 된다.
아이콘 테마
아이콘 역시 바꿀 수 있다. 이 아이콘 테마들은 모양새에 있다. 모양새에서 ‘아이콘’ 탭을 클릭하면 다양한 아이콘 테마들을 선택할 수 있다. 물론 인터넷을 통해서 다운로드 받을 수 있다.
자주 사용하는 테마는 GNUStep, McMuse-pink-dark 다.
아이콘 테마
마무리
XFCE 는 경량 데스크탑으로 불리운다. GTK 기반으로 제작되었기 때문에 GTK 테마라면 호환이되어 사용할 수 있다. 하지만 xfce-looks 에서도 구할 수 있다. 벌써 20년이나 지났지만 CDE 테마를 고집하는건 그 특유의 레트릭한 모양의 데스크탑 그래픽을 잊을 수 없었기 때문이다.
이전 글에서 AWS 의 Athena 를 이용한 VPC Flow Log 를 어떻게 분석하는지에 대해서 이야기 했다. VPC Flow Log 생성부터, S3 버킷 생성, Athena 데이터베이스와 테이블 그리고 Lambda 를 이용한 파티션 추가까지 비교적 많은 부분을 손봐야 했다.
이 방법은 파티션 작업을 Lambda 를 이용하는 방법으로 하루에 한번 실행시키도록 하고 있다. 하지만, AWS 에서는 이마져도 필요 없는 방법을 제공하는데, 그것이 바로 파티션 프로젝션(Partition Projection) 이다.
AWS 메뉴얼 주의사항
파티션 프로젝션을 하기 위해서 AWS 메뉴얼을 보고 따라했는데 되지 않는다. 정확히는 테이블 생성이 되지만 Athena 에서는 보이지 않는다.
Athena 의 데이터베이스는 Glue 를 이용한다. AWS Glue 가 가보면 Athena 의 테이블을 볼 수 있는데, AWS 메뉴얼대로 파티션 프로젝션을 생성하면 Glue 에는 나오지만 Athena 에는 안나온다. 이는 Glue 에서 S3 저장소를 인식하지 못해 나오는 문제다.
AWS Athena 는 로그 분석 서비스로 Hive 와 같다. 가장 많이 쓰이는 부분이 VPC Flow Log 를 분석하는데에 Athena 를 이용하는 방법이다. 이 글에서는 어떻게 VPC Flow Log 를 Athena 를 통해서 분석하는 알아 본다.
VPC Flow Log 설정
VPC Flow Log 설정은 간단하다. VPC 에서 Flow logs 탭에서 설정하면 그만인데, 다음과 같은 파라메터를 필요로 한다.
Destination Type: S3
Destination Name: S3 로 지정했을 시에 S3 Bucket 이름.
Log record format: AWS default format
Log file format: Text (default)
Partition logs by time: Every 24 hours (default)
여기서 중요한 것은 밑에서 3가지 정도다. Log record format 을 바꿀 경우에 Athena 테이블 생성시에 맞춰야 한다. Partition logs by time 을 24 시간으로 하면 S3 버킷 안에서 2022/08/29 형식으로 폴더가 생성되면서 VPC 로그가 전송 된다. 하루에 한번 폴더를 생성하면서 로그가 쌓인다는 뜻이다. 만일 Every 1 hours (60 minutes) 으로 할 경우에 2022/08/29/09 폴더가 생성되면서 로그가 쌓인다. 이 폴더의 구조는 나중에 Athena 에서 파티션 프포젝션(Partition Projection) 을 설정할때에 참고하게 된다.
또, S3 버킷으로 전송할 경우에 S3 의 암호화를 SSE_S3 로 할 것을 권장한다. CMK 로 할 경우에 로그가 쌓이지 않을 가능성이 있다. 또, 향후에 권한지정에서 CMK 권한을 함께 줘야하는 복잡함이 있을 수 있다.
S3 버킷 확인
필자의 VPC Log 설정으로 인해서 S3 에는 다음과 같은 형태로 S3 에 로그가 쌓이고 있다.
버킷 이름만 지정해주면 그 안에 AWSLogs/계정ID/vpclfowlogs/ap-northeast-2/ 가 자동으로 생성되며 그 안으로 year/month/day 순으로 생성된다.
앞에서 VPC Flow Logs 설정할때에 Partition logs by time 에서 Every 24 hours (default) 로 지정했기 때문에 날짜별로 생성된다.
Athena 작업
작업그룹(Workgroups) 생성
먼저 Athena 에서 필요한 것이 작업그룹(Workgroups) 이다. 기본적으로 Primary 가 기본 생성되어 있지만 하나 생성한다. 생성할때에 필요한 것은 다음과 같다.
쿼리 결과를 받을 S3 를 지정해야 한다. 만일 암호화가 필요하다면 SSE_S3 를 권장한다. CMK 도 가능하지만 Role 설정을 잘 해줘야 한다.
데이터 사용량을 적절하게 조절해 주길 권장한다. 덮어놓고 좋다고 No limit 로 하는 순간 돈이 술술 나갈 것이다. 이 데이터 사용량은 얼마든지 설정을 변경할 수 있다.
Database 생성
Query Editor 로 이동해 화면 오른쪽 상단에서 앞에서 생성한 작업그룹(Workgroup) 으로 변경해 준다.
그러면 Workgroup 이 변경 된다. 이제 다음과 같이 Database 를 생성해 준다.
Create Database vpcflowlogs
PgSQL
1
CREATEDATABASEvpcflowlogs
위 쿼리문은 화면안에 쿼리입력창에 입력하고 ‘Run’ 을 클릭해주면 된다.
이렇게 하면 데이터베이스가 생성이 된다. 그리고 왼쪽에 Database 부분에서 새로 생성한 데이터베이스를 선택해 준다.
위와같은 상태가 된다면 이제 테이블을 생성해야 한다.
Table 생성
이제 Table 을 생성해야 한다. 테이블을 생성할때에 중요한 것이 VPC Flow Log 의 S3 저장소와 데이터 컬럼들이다. 다음과 같다.
테이블을 생성할때에 컬럼을 지정해 줘야 하는데, VPC Flow Log 설정할때에 record format 을 AWS Default Format 을 지정했는데, 그 포맷은 위와 같다. 이 컬럼들은 S3 에 저장된 파일을 열었을 때에 맨 처음 나오는 행에 컬럼헤더 값들이다. 정확히는 ‘_’ 가 ‘-‘ 로 보면 정확하다. Athena 테이블은 ‘-‘ 를 ‘_’ 로 변환된다.
중요한 것은 Partitioned BY 부분에 date 부분이다. 테이블을 파티셔닝을 하기 위한 기준이 되는 컬럼을 추가하는 것이다. 이 파티션 컬럼은 S3 에 저장되는 VPC Flow Log 에는 없는데 파티셔닝 테이블을 생성할때에 이름처럼 생성된다.
위 쿼리문을 실행해 테이블을 생성한다.
파티션 생성
만일 파티션이 없다면 쿼리 시간이 길어진다. VPC Flow Log 의 경우 날짜로별로(yyyy/MM/dd) 쌓이는 것에 창안해 파티션을 날짜별로 생성하도록 할 것이다. 다음과 같이 파티션을 생성해준다.
파티션을 생성하면 문제가 하나 있다. 날짜별로 하나하나 다 생성해 줘야 한다. 시간은 흐르고 날짜는 변경될 것이다. 내일이 되면 다른 날짜로 S3 에 폴더가 만들어지고 거기에 데이터가 쌓일 것이다. 그러면 Athena 에서 그 날짜에 맞는 S3 저장소의 파티션을 생성해줘야 한다.
매일매일 하루에 한번 이것을 해야 한다고 생각하면 힘들다.
이것을 자동으로 하는 방법은 존재한다. Lambda 를 이용하는 것이다.
Lambda 작성하기
Lambda 실행을 위한 Role 생성
Lambda 를 작성해 자동으로 매일매일 하루에 한번 파티션을 생성하도록 해보자. Lambda 를 실행하기 위해서는 먼저 Lambda 실행을 위한 Role 이 필요하다.
Create Roles
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
## Role Name: ServiceRoleForVPCFlowLogsAthenaIntegrated
이제는 vpc_flow_logs_kst 뷰(view) 에 질의를 하면 start, end 컬럼의 데이터가 KST 시간으로 표신된다.
결론
지금까지 VPC Flow Log 생성에서부터 Athena 를 이용하는 방법, 더 나가 자동으로 파티션을 생성하도록 Lambda 까지 작성해봤다.
하지만, Lambda 작성도 필요없는 방법이 있다. 파티션 프로젝션(Partition Projection) 이라고 불리는 방법인데, 이것은 처음 테이블을 생성할때에 S3 의 날짜 폴더 구조를 기반으로 자동으로 파티션을 인식시키는 방법이다. 이렇게 하면 Lambda 를 이용해 파티션을 수동으로 생성해줄 필요가 없게된다.
