시간과 공간 그리고 진실의 방

컨테이너화를 위해서 Docker 를 설치하고 재시작하면, WSL 2로 업데이트가 필요하다는 알림이 뜬다. 이 경우 무시하고 싶지만, 망할놈의 무시를 할 수도 없고, 무적권 설치를 해야하는 상황이 벌어진다.

WSL 2로 업데이트 해보자

1. Windows 에서 Linux 배포판이 설치 가능하도록 쌈박하게 입력

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

1.1 Virtual Machine Platform 옵션을 사용하도록 설정한다.

Powershell 을 관리자권한으로 실행시킨 이후에 Command 를 상큼하게 입력한다.

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

2. WSL 최신 패키지를 쌈박하게 다운로드 한다.

• x64 머신용 최신 WSL2 Linux 커널 업데이트 패키지

3. PowerShell 에서 WSL 기본 버전을 쌈박하게 변경

wsl --set-default-version 2

이제 Windows Store 에서 Linux 배포판 이미지를 받아서 윈도우에 설치할 수 있다지만 에러가 나서 안된다

(이래서 내가 윈도우를 싫어함.)

그래서 리눅스로 건너가고 다음 포스팅에는 도커에 대해서 학습한걸 포스팅 하려한다

서두

일단 시작하기전에 Slack API 를 연동할 방법을 곰곰히 생각해보았다. 킹치만 우리에게는 구글신이라는 것이 있기에 굳이 삽질을 할 필요가 없다.

1. Slack Api 에 들어간 다음 Sign in 을 한다 

 - 여기서 당연히 Account 가 없으면 가입을 해야되는 부분이고, 나는 일단 프로젝트를 위해서 그냥 만들어줬다.

2. Create App 을 한다

타입이 2가지가 있는데, (제 배에는 구멍이 2개죠..)  Slack 에서 만들어놓은 Basic UI 방식이 있고, 그 이외에 매니페스트 방식이 있다. 기본적으로 구글신에서 안내하는것은 Basic UI 를 따르니까 보고 쓱싹 생성하자.

manifest  쓰면 앱에 관한 설정의 대부분을 관리할 수 있따는 겁니다. 근데 YAML 이랑 JSON 을 때려잡아야 하죠

Part2

여기서 Slack 을 일종의 Bot 용도로 써서 알리미 용도로 쓸거니까 추가 Method 기능에서 Bot을 얌채같이 클릭해준다.

여기서 Install App 을 해서 상호작용을 하려면, 기본적으로 Permission 이 있어야 한다. (리눅스 기반에서는 다 그렇잖아? 서버도 그렇구)

이렇게 OAuth & Permission 탭에서 하단부로 들어가면 Bot 에 대한 Permission Scope 를 정할 수 있는 곳이 보인다.

이게 100% 맞는지는 모르겠지만, 니가 Bot 을 무슨 용도로 쓰고, Bot에 어떤 권한을 줄꺼니로 느낌이 든다

"Add an OAuth Scope" 를 클릭하면 콤보박스가 하나 뜨는데, 거기서 필요한 Permission 을 골라주면 되겠다.

내 경우는 채널에 대한 메세지를 알람처럼 보낼 것이기 때문에 chat:write 을 부여했다.

그러면 위와 같이 Bot 이랑 Permission 에 설정했다고 체크박스와 함께 화려한 불빛이 나를 감싼다.

하단부의 Install your app 에서 workspace 에 설치를 진행했다.

이제 Slack API 에서 내가 만든 App 에 메세지를 보낼 수 있다. (물론 메세지 이외에 다른 짓도 하고싶다면, API 의 사용 용도에 따라서 삽질을 진행하면 되겟다.)

Part3

Incomming Webhooks 활성화 하기

일반적으로 Bot 토큰이나 등등에 대해서 안뜬다면 그냥 Incomming Webhook 에 들어와서 저기 위에 있는 Off를 On으로 바꿔주면 나같이 위에서 삽질을 했다면 퍼미션 변경한다고 뜬다. 진행해보자

그리고 번외의 채널 리스트 불러오기도 구현해보자

이 부분에는 Scope 에서 channels:read 퍼미션이 필요하다.

Admin 페이지에서 작동하는 부분중에, Comment 에 대한 부분에서 Reporting 된 처리를 하는 것은 정상적으로 작동했지만, Posting 에 대해서는 정상적으로 작동하지 않는 사태가 벌어졌다.

Log 를 살펴본 결과, SQL statement Error 로 보고 있는데, Update 구문에서 Entity 를 정상적으로 인식하지 못하고 있다.

예를 들어보면

UPDATE report_posting rp SET rp.report_status = 2 Where rp.relation.posting.id = xxxxxx

인 부분에서 앞에 표시한 부분을 정상적으로 인식하지 못하고 있다.

일단 이 부분에서 Error Code 기반으로 추적해보자면, 예약어나 SQL 문을 잘못 썼거나 하는 등의 상황에서 발생한다고 하는데, 아무리 봐도 구문상 틀린건 잘 보이지 않는다.

그래서 이걸 Native Query 로 바꿔볼까 하다가, 그러면 JPA 의 맛을 잃어버리니까 또 고민중이다.

확실한건 로그 기반으로 추적해서 봣을 때에, Entity 에서 약간의 다른 점이 있다면 

report_posting 의 경우는 Enum 기반의 posting_type 필드를 가지고 있다는 것이고

report_comment 의 경우는 posting_type 따위는 개나줘버리긴 했는데 사실 그게 문제가 아니라

만약 네이밍이 문제가 될려면 네이밍 부분을 잡아서 찍어줘야 하는데 뭐가 문제인지 고민중이다.

음 일단 대충 요약하자면

서류 전형  - 코딩테스트 - 1차 전형 - 2차 전형 - 연봉협상  

이 단계로 이뤄질꺼고, 서류단계에서 합격한 상태에서 코딩테스트를 진행했다.

일단 코딩테스트에 응한 바를 살펴보면 난이도는 지금까지 봣던 코딩테스트중에 최상을 자랑했다.

문제 유출하면 안된다고 해서 언급할 수는 없지만, 일반적으로  골드 찍을 정도면 충분히 풀겠지? 라고 했다가는 큰코가 날아가버린다.

내 경우는 클라우드인프라팀에 Backend Engineer 직군이였고, 

자격요건은 Java 개발 경험 5년에 해당하거나 준하는 경력 이상 등과

등을 요구하는 포지션이다.

정확하게는 야놀자에 서류썻다가 광탈당한게 5번은 넘었던 것 같은데, 

LinkedIn 을 통해서 HR 담당자님과의 별도의 커피챗 이후에 2 포지션으로 지원해서 합격했다.

사실 가장 해보고싶던 것은 DevOps 계열이긴 한데,

JPA 에 클라우드 인프라가 합쳐진것도 너무 끌려서 결코 놓치고 싶지 않았다. (사실 여기가 난이도가 더 빡세보여서 기피하려던건 안비밀이다)

코딩테스트가 합격할진 모르겟는데 2문제가 주어졌고 90분인가 95분이 주어졌었다

첫번째 문제 푸느라 진짜 골머리를 부셧던거 같은데 다행히 Edge Case는 다 통과했고 45분인가 40분 남은 시점에서 2번째 문제로 넘어갈 수 있었다.

문제는 두번째 문제가 나름 그나마 쉽게 만날 수 있는 Problem Solving 류의 영역이였는데, Edge Case 풀다가 5개중에 4개밖에 잡질 못했다.

살다살다 그 문제에서 Edge Case 다 잡지 못하리라고 생각한건 처음이였는데 어마무시한 일이였고,

그 때문에 코드를 수십번도 지우고 다시짯던 것 같다 (그 40분동안 진짜 알고있는 관련지식은 다 짜집기하고 넣어서 짜보려고 노력했었다)

그런데 결국은 실패했다. (어 그럼 떨어지겟지?)

결론적으로 HR쪽에 있는 원석님이 언급해주신 대로 야놀자에서는 Problem Solving 쪽을 굉장히 강화해놓은 것 같다. 단연코 내가 풀었던 코테중에는 최상급이였다고 믿고있다.