W사(서울 서초구) 면접 후기

인성 면접을 본다고 적혀 있었고 화상으로 진행됐다. 가장 처음으로 보는 취업 면접이었고 준비도 가장 안됐던 것 같다. 그래서 엄청 긴장한게 그대로 티가 났다. 😅

첫 면접이고 인성 면접이라고 해서 크게 준비를 안했다. 자기소개랑 지원 동기, 커리어 골과 성격의 장단점 정도만 정리하고 면접에 임했다. 그리고 마지막 한마디를 되게 열심히 준비했는데 모든 기업에서 마지막으로 할 말을 물어보지 않고 회사에 대한 질문을 물어봤다...

면접은 30분 정도 진행됐는데 그 중 15분 정도는 면접관께서 회사에 대한 소개, 인턴 기간동안 맡게될 업무 등에 대해 소개하는 시간이었고 실질적인 면접은 15분 정도 소요됐다.

면접 질문

• 학교 생활 중 다양한 프로그래밍 언어(자바스크립트를 포함하여)를 접했을 텐데 프론트 엔드 프레임 워크를 접한 시점은 언제이며, 이외에 어떤 기술 스택을 공부했는가?
• 타입 스크립트나 서버 사이드 렌더링을 적용한 경험이 있는가? (이거 대답을 너무 못했다... 안해보긴 했지만 그 개념에 대해 알고, 필요성을 느끼고 있다고 대답 할 수 있었을 텐데 나는 그냥 '아뇨, 없습니다.')
• Redux 사용해본 경험이 있는가? (나도 가장 약점으로 생각했던 부분이었다. Vue는 vuex를 사용해서 상태 관리를 제대로 써봤지만 React로 언어를 급하게 변경한 뒤에는 생략했기 때문에.. ㅜ)
• (위의 두 질문에 모두 아니라고 대답했기 때문에) 그렇다면 React를 단순히 UI 라이브러리같은 개념으로 사용한 것 같다. (그래서 프로젝트 과정을 설명하며 Vue에서 React로 변경하며 제한된 시간 등을 주저리주저리 얘기함)
• 그럼 Vue와 React의 차이점 등을 설명할 수 있겠는가?
• 주변 동기들에 비해 자신의 실력이 어느정도 된다고 생각하는가? (가장 당황했던 질문.. 중하라고 답변했다.. 근데 사용 기술을 보고 나름 높게 평가했다고 한다. 그치만 주변에 워낙 괴물들이 많아서요 😅)
• 만약, 간단한 쇼핑몰 사이트를 만든다고 했을 때(로그인-상품 창-장바구니 담기-결제 등등), 어느 정도 기간이 소요될 것 같은가? (정답이 있는 문제는 아니지만, 나는 한달 정도 걸린다고 대답했다. 그리고 답변 후 왜 그렇게 생각했는지도 물었고, 나는 이전 프로젝트 경험을 통해 내린 결론이라고 답했다.)
• 그럼 위의 사이트를 만들며 가장 어려울 것 같은 부분은 어디인가? (사실 앞에 사이트 설명을 되게 길고 자세하게 해주셔서 살짝 멍때렸는데 어려운 부분 물어봐서 좀 당황함.. 결제하는 부분이라고 답했다.)
• 이외에 내가 포폴에 넣었던 프로젝트에 대한 질문(화상 회의 서비스인지라 Web RTC를 사용했는데 그 부분에 다들 관심을 가지셨다.)
• 업무를 진행할 때, 혼자 마스터에서 작업하는 스타일인가, 아니면 따로 브랜치를 파고 PR을 요청하면 상사가 코드 리뷰를 한 후에 머지하는걸 선호하는 스타일인가? (나는 후자를 답했는데 스타트업과 같은 소기업에서는 전자를 답하는걸 좀 더 좋아할 것 같다고 생각한다.)

가장 전형적인 개발자 면접이었다고 생각이 들고, 스스로 준비한 답변대로 흘러가지 않음을 느꼈다. 임기응변이 중요하다고 생각했다. 내가 제출한 문서들을 보긴 봤지만 꼼꼼하게 봤다는 느낌은 안들었다.

M사(서울 구로구) 면접 후기

기술 면접과 인성 면접을 같이 봤고, 전화로 면접을 봤다. 신기하게도 모든 안내 사항을 전화로(메일이 아닌) 전달 받았다. 전화 면접이다 보니 따로 하는 거 없이 면접 전화를 기다리는 상황이었는데 약속한 시간에서 4분 가량 늦게 전화가 왔다. 꽤 규모가 큰 회사였는데 이런 부분에서 살짝 엥? 싶었다.

인성 면접부터 빠르게 시작했고, 상당히 어려운(준비를 안했다면 답변하기 힘들었을) 질문들이었다. 나는 면접 전에 유투브로 면접 관련 동영상을 봤는데 대부분 마케팅과 같이 문과 직무여서 그냥 생각없이 보고 넘겼는데, 거기서 본 내용이 정말 면접에 나와서 놀랐다.

기술 면접은 생각했던 것 보다 훨씬 길고 내용도 많았다. 애초에 지원 포지션을 정하고 뽑는게 아니라 뽑고 나서 포지션을 배치하는 방식이라서 프론트 엔드 쪽 질문 외에도 다양하게 질문을 받았다.

면접 질문

• 장단점은 무엇인가?

• 팀원을 뽑는다면 어떤 팀원을 뽑을 것인가?

• 회사의 목표와 팀의 목표, 자신의 목표가 다르다면 어떤게 가장 중요하다고 생각하는가?

• 팀장이 지시한 내용이 회사의 목표와 맞지 않는다면 어떻게 할 것인가?

• 내가 기술 면접으로 블로그에 정리한 글에 대한 내용 중에서 70% 이상 나왔다.

• 반복문(for, which)/ switch 문/ 스택과 큐/ call by reference, call by value/ 삼항 연산자 등

• 질문이 대체적으로 ㅇㅇ 사용해봤나요? 네 -> 그렇다면 ㅁㅁㅁ은 무엇인가요? 처럼 이어졌고, 안써봤다고 하면 다른 언어에 대한 질문으로 넘어가는 방식이었다.

• JAVA에 대한 질문으로는 생성자/ 오버로딩과 오버라이딩의 차이점

• 데이터베이스에 대한 질문으로는 index/index의 시간 복잡도/ RDBMS와 NoSQL의 차이점/ 몽고 DB 사용 여부

• Spring에 대해서는 사용한 적 없다고 해서 더이상 질문 안하셨다.

• 프론트 엔드 관련해서 MVC 패턴/ 싱글톤 패턴/ 동기와 비동기의 설명과 차이점/ 예외 처리 방법(try-catch)/ 사용자가 직접 exception을 처리하는 방법

• 진행했던 프로젝트에 대한 질문

전화로 진행된 터라 면접관의 표정이나 그런걸 전혀 읽을 수 없어서 잘 대답하고 있는지를 알 수가 없었다. 그리고 앞선 면접에서 처럼 대화식으로 풀어나가는게 아닌 스피드 퀴즈를 하듯이 정답과 오답만 체크하고 넘어가는 듯한 느낌이 들었다. 대답을 잘 하든 못하든 답만 하면 다음 질문으로 넘어갔다. 결국에는 합격을 한 걸 보면 그래도 답을 꽤 많이 한 편이니까 그런 것 같은데 면접 경험이 별로 좋지는 않아서 별로 가고 싶지는 않았다.

G사(경기 성남시) 면접 후기

*이곳은 면접 전 미션을 받았고, 약 1주일간 미션을 수행한 후 면접에 가서 코드 리뷰가 있었다. 대면 면접이었고 1시간 30분 정도 소요된다고 적혀있었지만 45분 정도로 짧게 끝났다. 같은 시간에 면접 본 사람이 한 명 더 있었는데 각자 다른 방으로 들어가 면접을 진행했고, 면접관은 3분이 들어오셨다.

전체적으로 코드 리뷰를 하며 내가 잘못 짠 부분이나 다른 사람과 다르게 짠 부분(아마도)이 있다면 그런 부분 위주로 질문하셨다. 이외에도 자기소개, 남들과는 다른 점(장점), 지원 동기와 프로젝트 경험에 대한 질문이 있었다. 처음 바흐흑을 구해죠바흐흑 게임을 직접 해봤는데 너무 어려웠다며 말씀하시면서 들어오셨는데 다른 기업에 비해서 정말 포폴이나 자소서 등을 꼼꼼하게 자세히 보셨다는 느낌을 받아서 좋았다.

면접 질문

• 진행한 미션을 기반으로 잘못하거나 좀 이상하게 짠 부분에 대한 질문이 들어왔는데, 한 분이 먼저 A를 사용해서 코드를 짜셨는데 B라는 방법도 있습니다. 이 둘의 차이점을 알고 있는지에 대해 질문하고, 답변 후에 다른 분이 이 부분에 기능이 좀 떨어지는데 개선 방법이 있을까요? 하고 물어보셨다. 이처럼 내가 좀 생각해 볼 수 있도록 물음표를 던지신 후에 잘못 짠 부분에 대해 답변할 수 있도록 해주셨다.
• 내가 진행한 미션에서는 안돌아가는 부분은 없었으나 개선해야 할 부분이 3개 정도 있어서 지적해주셨다.
• 자기소개, 지원 동기를 열심히 준비해서 간 것이기에 물어보셨을때 당황하지 않고 줄줄 읊었는데 다들 빵 터지시면서 준비 정말 열심히 하셨다고 해주셨다.
• 가장 긴장하지 않고 대화하듯 자연스럽게 면접을 끝냈다. 이외에도 다른 질문을 하셨는데 공통 질문이라기 보다는 각자의 경험에 맞게 궁금한 부분에 대해 질문하신 것 같아 굳이 적지는 않겠다.

회사를 직접 가봐서 그런진 모르겠지만 분위기도 좋고 면접 내내 이분들과 같이 일하고 싶다는 생각이 너무 들었다. 거리가 멀긴 해도 투정하지 않고 잘 다닐 수 있을 것 같다. 최종 합격해서 망설임 없이 확정했다. 면접을 보면서 내 깃허브를 확인하는 듯 했고, 그러면서 코드 확인하고 궁금한 부분이 있으면 질문하는 식이었다.

세 번의 면접을 보며 되게 감사하게도 다양한 유형을 모두 경험할 수 있었고, 준비하면서 조금이나마 성장한 기분이었다. 누가 이걸 볼지는 모르겠지만 혹시나 면접에 대해 궁금할 수 있으니 조금 첨언을 하자면, 기술 면접 위주로 본다고 하면 정말 빡세게 다 공부하는게 좋을 것 같고, 인성 면접 등을 본다고 하면 간단한 질문(자기 소개, 지원 동기, 장단점, 커리어 골 + 프로젝트 경험 설명할 수 있을 정도의 준비)등에 대해서 좀 생각하고 가면 좋을 것 같다.

최종적으로 G사와 M사 두 기업에 합격했다. (W사도 처음에는 합격으로 되어있었는데 이후에 다시 확인하니 탈락으로 변경됐다. 🤔)

가장 가고싶었던 G사에 합격해서 너무 기분이 좋았고 망설임 없이 확정 처리했다. 거리가 먼게 좀 마음에 걸렸지만 그래도 가고 싶은 곳에 가야 후회가 없을 것 같았다. 열심히 준비했고 결과적으로 좋은 기회를 얻게 되어서 뿌듯하다. 졸업 전에 인턴을 하게 되어서 기분이 좋다!! 🤩

그리고 문제 특징이 쫌 어려운 문제(4,5)는 비슷한 유명한 문제을 조금 바꿔서 내는 식인 것 같다. 4번 문제같은 경우는 백준의 회의실 배정과 아주아주 유사했다.

1번보다 2번이 더 쉬웠고 3번까진 무난하게 풀었다.

보통의 코테처럼 2, 3시간 제한으로 나온 문제였다면 4(3.5?)문제 이상 풀어야 만족스러울 것 같지만 이건 12시간이나 있었기 때문에 무조건 다맞겠다는 생각을 가지고 있었다.

평소에 프로그래머스 3단계 문제를 풀 수 있는 실력이라면 따로 준비는 안해도 될 정도.. 나는 한 삼사일 전부터 하루에 한 두 문제씩 풀어봤다.

시험 결과는 테스트가 완전히 종료된 후 하루 뒤에 메일로 받아볼 수 있다. 문제 풀었던 시간도 함께 나온다고 하길래 전체 걸린 시간이 나올 줄 알았는데 문제 별로 나왔다. 문제도 함께 확인할 수 있고 내가 제출한 코드도 같이 있었다.

아래는 문제 별로 걸려있던 태그들에 대한 점수로 결과 페이지에서 캡쳐했다. 대충 어떤 유형이 나왔는지 확인할 수 있을 것 같다.

문제 난이도(내 느낌 상)

우앙 나 외국인이랑 대화 첨해봐 o0o 빨리 해치우고 컨트리뷰터가 되고싶었지만 안타깝게도 토이 프로젝트 기획에 정신이 팔려 한동안 건들지 못하고 있었다.

쉽게 기여를 할 수 있다고 좋아라 했건만 역시 인생은 호락호락하지 않는법! 처음 PR을 올리는 과정에서 이것 저것 테스트 해보며 공백이 동일하게 표시되지 않는 것을 인지하고는 있었지만, 한 번에 수정하기에는 어려울 것 같아 그냥 넘겼었는데 역시 그 문제인가? 싶은 생각이 들었다.

ICT 인턴십 종료와 함께 갑자기 여유가 생겨서 1주일만에 다시 VS 코드를 열었다. 이전에 발견했던 문제는 정확한 이유를 파악했는데 현재 이 PR과는 관련성이 높지 않아 따로 이슈를 등록할 예정이다. 그리고 원래 확인했어야 하는 '공백이 동일하게 보이지 않는 문제'는 관리자 도구 등을 통해 안의 공백 개수를 확인해보니 개수는 맞게 들어있지만 픽셀, 폰트 등의 차이로 인해 달라 보였던 문제였다.

따로 수정할 부분은 없는 것 같아 내가 그렇게 생각하게 된 부분을 캡쳐하고 코멘트를 달아두니,

빠르게 답이 달렸다!

그리고 2022년의 첫 번째 날이 되서야 마지막으로 요청받은 최근 릴리즈를 모두 pull 받아 다시 코멘트를 달아 두었다.

감격의 순간..! 드디어 머지가 되었다. 거의 한 달에 걸쳐 찔끔찔끔 진행되던 일이 이렇게 마무리가 되자 너무 마음이 편안하다.. 시작은 회사에서 업무 툴로 사용하며 발견한 버그였고 팀 리더께서 직접 버그를 고쳐서 PR을 올려보면 어떻겠냐고 가볍게 말씀하셨던 일이었지만, 이렇게 끝내고 나니 언젠가의 버킷리스트였던 오픈소스 컨트리뷰트를 달성하게 되었다! (이제 릴리즈만을 목이 빠져라 기다려야지 ㅋㅋㅋ)

회사 일하면서 좋은 리더를 만나 이런 특별한 경험까지 해보다니 너무 신난다! 😆😆 p.s 최근 몇 달간 블로그 포스팅 주제를 던져주신 분도 우리 리더..

바로 텍스트에 공백이 반영되지 않는 것이었는데, 얼마 전 라이브 채팅을 구현하며 동일한 문제를 발견했었고 굉장히 간단하게 해결했던 기억이 반짝 스쳐지나갔다.

개발자 도구를 키고 설마? 하며 white-space: pre-line을 입력하는 순간 눈이 커지고 심장이 두근거렸다!

드디어 나도 오픈소스 컨트리뷰터의 기회가..

그날 부로 퇴근 후 짬짬히 코드 구조를 파악하고 환경 셋팅을 하는데, 윈도우로 개발을 하는것이 어렵다는것을 처음 느끼게 되었다.

mac OS에서는 그냥 한 줄 치면 끝나는 것을 윈도우로는 뭐를 설치하고 이걸 이렇게 바꾸고...

윈도우는 리눅스를 사용하기 위해서 wsl을 설치해 작업 환경을 설정해 주어야 한다고 한다.

잠깐, WSL이란? WSL은 윈도우에서 리눅스를 구동할 수 있도록 도와주는 기능이다. WSL2에서는 기존의 WSL을 개선해 더욱 뛰어난 성능과 통합된 환경을 경험할 수 있다. 또한 Docker를 사용할 수 있게 되었다고 한다.

정말 처음 들어보았기 때문에 오늘도 여전히 '개발이라는 바다를 헤엄치는 한 마리의 작은 물고기'가 된 기분으로 열심히 검색을 하며 환경 세팅을 했다.

• https://www.44bits.io/ko/post/wsl2-install-and-basic-usage
• https://www.phpinfo.kr/entry/WSL2%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-Nodejs-%EA%B0%9C%EB%B0%9C-%ED%99%98%EA%B2%BD-%EC%84%A4%EC%B9%98

위에 두 글을 보며 WSL까지 설치를 완료했다.

그러나 이후 다른 명령어 하나 하나를 칠 때마다 이슈가 생겨(스크립트 파일을 실행하는데 개행 문자가 달라서 /bin/sh^M: bad interpreter: No such file or directory오류가 발생하는 등..) 결국 회사 맥북으로 SOS를 요청했다.

개발은 맥북으로...

1주일이라는 시간이 흐른 뒤 주말, 드디어 맥북과 함께 다시 환경 셋팅부터 시작했다. 물론 여전히 물 흐르듯 자연스럽게 잘 되진 않았지만 내친구 구글과 함께라면 무섭지 않아!

그리고 Appsmith가 사용자가 꽤나 많은 편에 속하고 소통을 지향하는 듯 해서(유투브 채널도 있고, discode 채널도 존재한다!) 워낙 문서가 잘 작성되어 있었다.

나는 client 단의 코드를 수정할 것 이었기 때문에 appsmith/contributions/ClientSetup.md를 참고하여 환경 셋팅을 진행했다.

맥북과 함께하니, 너무 스무스하게 단계가 넘어가는 것을 보고 '아! 이래서 맥북이구나..'를 다시 한번 느꼈다. node 14 버전을 설치해야하는 것을 빼고는 큰 문제가 없었다. yarn start를 치고 dev.appsmith.com을 치는 순간! 502 Gate way가 아닌 로그인 페이지가 뜨는 것을 보고 감격했다.

이미 추가할 코드는 적어둔 상태이기 때문에 서버를 실행 하자마자 원하는 대로 동작하는지 확인했다.

빠르게 수정사항이 잘 돌아가는지 확인한 뒤에 2차 관문인 테스트를 시작했다. 그런데 Cypress 테스트를 하기 위해 yarn test를 입력하면 자꾸 에러를 뱉는 것이었다..!

구글링으로도 만족스러운 해결책을 찾지 못하고, 혹시 Jest Unit test는 되려나 싶어 yarn run test:unit을 입력하니, 이건 또 된다?

와, 됐다!

크게 변경사항이 있는 커밋도 아니고, 단지 css 관련하여 한 줄 추가했기 때문에 테스트 하나라도 통과했으니 그냥 PR 올리자~ 하는 마음으로 바로 PR을 올려버렸다. 좀 서두른 이유는 워낙 간단하게 고칠 수 있는 버그여서 누가 먼저 수정할까봐 전전긍긍했기 때문이다 ㅋㅋ 서두르는 바람에 Reviewer, Assignees 도 하나도 못 지정한 채로 올려버렸다.

아직 코멘트도 하나 달리지 않은 상황이지만 굉장히 좋은 경험을 했다고 생각한다. 생전 해보지 않았던 일들을 한다는 것은 두렵지만서도 매번 새롭다. Appsmith 사용하다보니 불편한 점들 몇개를 더 찾았는데 이걸 발판으로 삼아 다른 기여도 해보고 싶다 !

MDN 문서에 의하면 line-height 속성은 Line box의 높이를 지정한다. 한 마디로 텍스트 줄 간격을 설정하는 것이다. 또한 뒤이어 이런 설명이 나타나는데, 번역본을 보아도 쉽게 이해가 되지 않는다.

On block-level elements, it specifies the minimum height of line boxes within the element. On non-replaced inline elements, it specifies the height that is used to calculate line box height.

Block-level 요소의 경우 인라인 박스의 최소 높이를 지정한다고 한다. 앞의 설명과 일치하니, 다음 문장을 보자. non-replaced inline 요소는 라인 박스의 높이를 계산하기 위해 사용되는 높이를 지정한다고 한다. 도대체 non-replaced inline elements 는 무엇일까?

교체되지 않은 인라인 요소

lnline 요소라는 것은 알고 있는데 앞에 붙은 non-replaced가 무슨 뜻인지 한참 찾아보았다. 우리의 친구 stackoverflow의 한 질문에서 답을 찾을 수 있었다.

우선 replaced element(대체 요소)의 한 예로는 <img> 태그가 있다. 태그와 여타 다른 inline 속성을 가지는 태그들, 이를테면 <a>, <span> 등을 생각하며 답변을 마저 살펴보자.

So “non-replaced element” is just an element that is rendered as such, instead of causing some external content to appear in its place.

간단 명료한 설명이다. '외부 컨텐츠가 들어가는 것이 아닌' 경우가 바로 non-replaced한 것이다. MDN에 대체 요소(replaced element)에 대해 검색해 보니 이곳에서도 설명이 꽤 잘 나와 있었다.

replaced element

• <iframe>
• <video>
• <embed>
• <img>

위의 예시들을 보면 이제 replaced element에 대해 감을 잡았을 것이고, 우리가 궁금해 했던 non*-*replaced element 란 위의 태그들을 제외한 일반적인 inline 속성을 가진 태그들 임을 알아냈다. 이제 다시 처음 질문으로 돌아가보자.

그래서 line-height는 숫자로 지정해야 한다고?

MDN에 따르면 line-height는 unitless numbers 를 사용하는 것을 권장하고 있다. 흔히 사용하는 px, rem, em 등의 단위로 지정하는 것을 지양하라는 것인데, 이유가 무엇일까?

바로 상속(inheritance)때문이다.

아래의 예시를 보면, 초록 박스는 unitless number, 분홍 박스는 em, 파랑 박스는 %를 통해 line-height를 지정해 주었다.

<div class="box green">
    <h1>오늘은 line-height 속성에 대해서 알아볼 것이다.</h1>
    line-height는 unitless number로 지정하는 것이 좋다. 상속으로 인해 의도하지 않은 결과가 나타날 수 있기 때문이다.
</div>

<div class="box red">
    <h1>오늘은 line-height 속성에 대해서 알아볼 것이다.</h1>
    line-height는 unitless number로 지정하는 것이 좋다. 상속으로 인해 의도하지 않은 결과가 나타날 수 있기 때문이다.
</div>

<div class="box blue">
    <h1>오늘은 line-height 속성에 대해서 알아볼 것이다.</h1>
    line-height는 unitless number로 지정하는 것이 좋다. 상속으로 인해 의도하지 않은 결과가 나타날 수 있기 때문이다.
</div>

.green {
  line-height: 1.1;
  border: solid limegreen;
}

.red {
  line-height: 1.1em;
  border: solid pink;
}

.blue {
  line-height: 110%;
  border: solid skyblue;
}

h1 {
  font-size: 30px;
}

.box {
  width: 18em;
  display: inline-block;
  vertical-align: top;
  font-size: 15px;
}

부모인 <div>태그의 font-size가 15px로 지정되어 있기 때문에 15px * 1.1 = 16.5px로 line-height가 <h1> 태그에도 동일하게 지정된 것을 볼 수 있다. 때문에 글씨가 깨져버린다. 아래의 설명으로 달린 부분은 폰트가 15px이기 때문에 의도한 대로 설정되었지만 <h> 태그의 경우 font-size가 30px이지만 부모의 font-size인 15px을 기준으로 line-height가 계산되어 문제가 발생했다.

따라서 이러한 문제를 피하기 위해서는 단위가 없는 숫자를 통해 line-height를 지정해 주도록 하자!

Polling: 엔드포인트에 이벤트가 발생했는지 주기적으로 요청을 보내는 방식 → 비효율적

Webhook: 엔드포인트에서 발생한 이벤트가 우리의 앱에 수신되는 형태 → 이벤트에 대한 핸들러

*엔트포인트란 발생한 이벤트가 어디로 전달되어야 하는가에 대한 것. 한 마디로 이벤트의 목적지이다.

슬랙 API에 incoming webhooks라는 것이 있는데, 이를 통해 외부 시스템에서 슬랙으로 메시지를 쏴줄 수 있다. 즉, 외부 시스템에서 어떤 이벤트가 발생하여 웹 훅이 실행되면 웹 훅 내부에서 슬랙의 웹 훅 엔드포인트로 post 요청을 쏘는 것이다. 이를 통해 슬랙 채널에 메시지를 보낼 수 있다.

[이미지 출처 및 참고 블로그]

그래서 웹 훅이 뭔데?

웹 훅은 역방향 API라고도 한다. 일반적으로 API는 클라이언트가 서버를 호출하지만, 웹훅의 경우 웹 훅을 서버측에 등록하면 서버에서 특정 이벤트가 발생했을 때 클라이언트를 호출하게 된다.

Slack의 incoming web hook을 통해 간단한 알림 봇 만들기

위의 api를 통해 특정 이벤트가 발생하면 알림을 보내주는 간단한 알림 봇을 만들 수 있다.

우선 알림 봇이 필요한 채널에 들어가서 Incoming WebHooks(수신 웹 후크) 앱을 추가한다.

우리는 위에서 보이는 웹후크 URL만 있으면 알림을 보낼 수 있다.

보내고자 하는 메시지를 postData에 저장해 두었고, headers에는 'Content-Type': 'application/json' 을 꼭 추가해 주도록 한다.

그런 다음 POST 로 요청을 보내기만 하면 된다!

슬랙의 메시지 첨부 파일 부분을 보면 다양한 서식을 지정해 줄 수 있으니 참고하자.

API 테스트 해보기

POSTMAN을 사용해서 API를 손쉽게 테스트할 수 있다. POST 방식으로 요청을 보내야 하므로 선택한 뒤, url에는 아까 기억해둔 웹 훅 url을 넣어준다.

다음으로는 Header에 Content-Type: application/json 을 추가해 준 뒤,

Body에는 메시지 내용을 적으면 된다. 간단하게 테스트 해 볼 예정이므로 슬랙에서 예시로 제공한 메시지를 그대로 복사 붙여넣기 했다.

만약 붙여넣은 내용에 에러가 뜬다면 따옴표를 잘 확인해보자. 쌍따옴표를 써야 하고 한/영 차이인지는 모르겠지만 기울어져 보이는 따옴표가 아닌( " ) 정방향의 따옴표( " )를 사용해야 한다.

마지막으로 Send 버튼을 누르면 Incomig web hook을 추가했던 채널로 알림이 오는 것을 확인할 수 있다.

알림 봇으로 사용하려면?

아래의 코드는 간단하게 버튼을 누르면 슬랙으로 누른 사람의 정보를 볼 수 있는 api를 짜고, 그 일부를 가져온 것이다. 해당 코드는 sendMessage라는 함수 내부에 내용이고, /api/user/alerm url로 연결된 라우터에서 sendMessage 함수를 호출하게 된다.

const sendMessage = async ({ userName, userPhone }) => {
  const postData = {
    attachments: [
      {
        title: '알림 봇이 알림을 보냈습니다!',
        pretext: '아래의 유저 정보를 확인해보세요.',
        color: '#ffffff',
        fields: [
          {
            title: '이름',
            value: userName,
            short: true,
          },
          {
            title: '연락처',
            value: userPhone,
            short: true,
          },
        ],
      },
    ],};

    const res = await axios.post(
        ${웹 훅 url},
        postData,
        {
          headers: {
            'Content-Type': 'application/json',
          },
        }
    );
    if (res && res.data) {
      if(res.data === 'ok') {
        return true;
      }
    }
}

exports.sendMessage = sendMessage;
---

// 버튼 클릭시 아래의 url로 axois 요청을 보낸다.
router.post('/api/user/alerm', async (req, res) => {
  try {
      // ... 다른 내용들
      slack.sendMessage({ userName, userPhone });

      return res.json(true);
    } catch {
      return res.json(false);
  }
});

이후 postman을 통해 위의 API를 호출해보자. 캡쳐 화면은 위의 예시와 맞아 떨어지지 않아 주소와 body에 보낼 데이터 값을 편집해서 넣어두었다.

https://{localhost 또는 실제 서비스 되는 주소}/api/user/alerm 의 주소로 보내도록 하고 body에는 필요한 데이터인 userName, userPhone을 넣어준다.

send 버튼을 누르면 요청이 가게 되고, slack.sendMessage() 함수가 실행된다. 이 함수 내부에서 웹 훅을 사용해 슬랙으로 알림을 보낼 수 있고, 알림 보내기에 성공했다면 응답으로 'ok'를 받을 수 있다.

우리는 sendMessage함수 하단에서 위의 응답을 확인해서 성공 시 true를 반환하도록 했으므로 postman에서 하단 응답으로 true가 적혀있는 것을 확인할 수 있다.

이를 통해 간단하게 알림봇을 만들어 보았다! 잘 응용한다면 회사의 점심 메뉴를 정하는 알림봇 등을 쉽게 만들 수 있을 것이다.