🐈 간단한 서론

앞선 포스트에서 소개한 공지사항 수신기 슬랙 봇 웹캣을 만들며 만난 이슈들을 기록한다.

이번 개발하면서 Workaround라는 표현을 유독 많이 마주쳤던 것 같다.
당장 완벽한 해결이 사실상 어려운 이슈들을 마주하며 Workaround를 찾게 되는 순간엔 정말 반가웠다😅.

인상이 강렬하게 남는 이슈 순서대로 적어 내려간다.

🐈 Issues

🐾 1. iOS device에서의 슬랙 api 이슈 발견

🧶 이슈 소개

슬랙 봇이 보낸 메시지에 포함되어 있는 링크가, ios device에서 제대로 접속되지 않는 이슈가 발생했다.

아래와 같이, 공지사항으로 연결되는 바로가기 링크를 마크다운 형식으로 메시지에 포함시켜 전송했다.
컴퓨터에서는 이상 없이 접속되었으나, 아이폰에서는 데이터가 충분하지 않습니다. 라는 문구와 함께 접속되지 않았다.

🧶 발생 원인

URI 인코딩과 관련된 슬랙 iOS app의 이슈였다.

URI에 포함된 띄어쓰기나 특수기호, 한글 등의 문자는, UTF-8 인코딩에 따라 각 character에 맞는 기호로 인코딩된다.

벨로그 글 주소를 복사할 때 뭔가 뒤에 잔뜩 붙어서 나오는 이유도, URI에 포함된 한글 포스트 제목이 인코딩되어서 그렇다.
아래 두 링크는 달라 보이지만 같은 웹페이지를 가리키는, 같은 URI이다.

https://velog.io/@seewon/공지사항-알려주는-고양이-웹캣-개발기

https://velog.io/@seewon/%EA%B3%B5%EC%A7%80%EC%82%AC%ED%95%AD-%EC%95%8C%EB%A0%A4%EC%A3%BC%EB%8A%94-%EA%B3%A0%EC%96%91%EC%9D%B4-%EC%9B%B9%EC%BA%A3-%EA%B0%9C%EB%B0%9C%EA%B8%B0

이렇게 인코딩과 관련해서, 우리가 흔히 ampersand라고 부르는 & 기호는, URI 상에서 &와 같다. 따라서 URI 상의 & 기호를 죄다 &로 바꿔버려도 문제 없이 같은 페이지로 접속된다.

서강대학교 컴퓨터공학과 주요공지의 각 게시글에 접근하는 URI는 다음과 같은 구조로 이루어져 있다.

https://scc.sogang.ac.kr/front/cmsboardview.do?currentPage=1&searchField=ALL&searchValue=&searchLowItem=ALL&bbsConfigFK=1905&siteId=cs&pkid=886557

searchLowItem=ALL 이후의 URI 쿼리를 잘 살펴보면, bbsConfigFK=1905&siteId=cs&pkid=886557라고 되어 있다. DB에서 bbsConfig라는 이름의 Foreign key가 1905인 항목 중, siteID가 cs이고, Primary key가 886557인 항목을 조회하는 것으로 보인다.

이처럼 학교 홈페이지는 DB에 저장된 항목을 URI 쿼리로 직접 조회하는 구조이다.

URI 인코딩 상에서는 &와 &는 같은 의미였지만, DB(SQL)에서는 &만이 and를 표현하는 연산자이고, &는 그저 syntax error을 발생시키는 구문이다.

Slack API를 통과한 학교 공지사항 링크의 &가 슬랙 iOS 앱에서는 죄다 &로 바뀌어 버려 오류가 발생했다.

🧶 해결 방법

Slack 측에 이슈 리포팅 후에, 주변 사람들한테 조언도 구하고, 다방면으로 고민한 결과 Short URL을 구현하기로 했다.

도메인을 하나 따서, 내가 새로 만든 도메인을 거치면 학교 공지사항 링크로 redirect되도록 구현하면 될 것 같았다. 새로 만든 도메인에는 &가 포함되지 않게 하고, 서버에서 공지사항으로 연결되도록 구현할 생각이었다.

계획만 세워 두고 시험공부를 하고 있었는데, 슬랙 측에서 제출한 이슈에 대한 트러블슈팅을 돕겠다며 이슈에 대한 확인 메일이 왔다.

사실 short URL 구현을 염두에 두고 있어 크게 도움 받을 생각은 없었지만, 버그 개선을 위해 이슈 재현 방법 등을 포함해 답장을 보냈다.

전문가를 배정해 주겠다는 몇 통의 메일이 더 오가고,
며칠 후 해당 문제를 확인했다는 사실과 함께 Workaround 우회 방법에 대한 안내를 담은 메일이 왔다.

API 요청을 보낼 때 plain text가 아닌, Blocks에 담은 형태로 데이터를 전송하면 된다는 답변이었다.
(Blocks는 슬랙 API에서 메시지를 구성하는 데 사용하는 방식 중 하나이다.)
적용해 보았더니, 문제가 잘 해결되어 아직까지 잘 쓰고 있다.

Slack의 공식 Github 레포지토리가 있었다면 contributor가 될 수 있었을텐데😆 없다는 게 내심 아쉬웠다.

그래도 서비스를 제공하는 본사 측에 성공적인 issue reporting을 해보는 새로운 경험을 했다.

🐾 2. /var/run 디렉토리의 경로 이슈로 인한 Cron Daemon 작동 중단

🧶 이슈 소개

어느순간 잘 돌던 Cron 데몬이 죽었다.
메일 로그를 확인해 보니 아래와 같은 에러가 발생했었다.

selenium.common.exceptions.WebDriverException: Message: Service {chromedriver 경로} unexpectedly exited. Status code was: 1

크롬 드라이버의 unexpected exit이었다.
좀 더 자세한 확인을 위해서, Cron log가 찍히는 파일을 찾았다.
/var/log/cron-20221023 의 경로에 저장되어 있는 파일에서 구체적인 오류를 찾을 수 있었다.

Cron이 작업 수행을 위해서 참조하는 crond.pid 파일이 있어야 하는 경로 /var/run/crond.pid에서 찾을 수 없어 문제가 발생하고 있었다.

🧶 발생 원인

crond.pid가 존재해야 하는 해당 경로로 가서 확인해 보니, 원래 멀쩡하게 존재하던 /var/run 디렉토리가 빨간 색으로 깜빡이고 있었다.

디렉토리 옆 화살표 표시는, 리눅스의 symbolic link로, 윈도우에서 폴더 바로가기와 같이 원래 경로로 이어 주는 역할을 하는데 이 부분에 문제가 생긴 것이다.

리눅스에서 /run 디렉토리는 원래 /var 디렉토리 하위에 있다가, /run 디렉토리로 접근해야 할 일이 많아 depth 감소를 위해 언젠가부터 홈 디렉토리로 옮기고, /var 디렉토리 하위에는 symbolic link로 남겨두었다고 한다.

🧶 해결 방법

Broken Symbolic link를 어찌해야 하나 구글링을 많이 했는데 명쾌한 해결 방법을 찾지 못해서.. 그냥 /run 디렉토리를 /var 디렉토리 안으로 옮겼다. 옛 것 감성 그대로 사용해보자는 취지로..ㅎ

옮기고 나니 다시 cron이 잘 동작했다.
왜 갑자기 멀쩡하던 symbolic link가 깨진 건지는 여전히 잘 모르겠다..

🐾 3. 가상 환경에서의 /dev/shm 파티션 할당 크기 부족으로 Selenium 동작 이슈

🧶 이슈 소개

어느 순간 ssh 접속이 안됐다.
AWS console에 접속해 서버 모니터링 화면을 켜 보았는데, CPU 사용량이 거의 100%를 달성하고 있었다.

급하게 인스턴스를 중지하고, 다음 날 다시 시작하고 접속해 로그를 확인했더니 아래 이슈가 계속 발생하고 있었다.

selenium.common.exceptions.WebDriverException: Message: unknown error: DevToolsActivePort file doesn't exist

DevTools Active Port가 필요하구나.. 하곤 몇 번의 구글링을 통해 크롬 웹드라이버 옵션으로 디버깅 포트를 추가해 주었다.

chrome_options.add_argument('--remote-debugging-port=9222')

에러가 발생하지 않고 잘 동작하길래, 된 줄 알았으나 다음 날에는 아래 에러가 발생하고 있었다.

selenium.common.exceptions.WebDriverException: Message: disconnected: unable to connect to renderer

Stackoverflow에서, 어떤 사람은 내가 전 날 추가한 옵션이 에러를 발생시키고 있었다고 했다.

--remote-debugging-port=9222 옵션이 없으면 DevToolsActivePort file doesn't exist 에러가 발생했고, 해당 옵션이 있으면 unable to connect to renderer 에러가 발생했다.

그럼 나는 어떻게 해야 하는가!!!

뭐지.. 뭘까.. 하면서 조사에 착수했다.

🧶 발생 원인

힘들게 찾은 크롬 이슈 리포팅에 따르면,

On most desktop Linux distributions, the default /dev/shm partition is large enough. However, on many cloud providers using Docker containers (such as the Google App Engine Flexible Environment) or Heroku, the default /dev/shm size is appreciably smaller (64MB and 5MB, respectively). On these platforms it's impossible to change the size of /dev/shm, which makes using Chrome difficult or impossible. This is particularly an issue for those who want to take advantage of its new headless mode.

The /dev/shm partition is too small in certain VM environments, causing Chrome to fail or crash (see http://crbug.com/715363). Use this flag to work-around this issue (a temporary directory will always be used to create anonymous shared memory files).

내 환경과 같이 AWS EC2와 같은 클라우드 환경에서는 /dev/shm 파티션에 할당된 용량이 부족해 해당 이슈가 발생한다는 내용이었다.

실제로 해당 경로에 할당된 크기를 확인해 봤더니, 아예 0이었다.

🧶 해결 방법

크롬드라이버 옵션 중 --disable-dev-shm-usage 옵션을 추가해서 해결했다. 해당 옵션은 참고 링크 에 따르면,

The /dev/shm partition is too small in certain VM environments, causing Chrome to fail or crash

가상 머신 환경에서 나와 같은 이슈가 발생할 때 사용하고,

Use this flag to work-around this issue (a temporary directory will always be used to create anonymous shared memory files

shared memory files을 위해 임시 디렉토리에서 필요한 작업을 수행하도록 해준다.

Work around로 탈출구를 미리 만들어 둔 크롬 측에 무한한 감사를 표한다.
이게 엔지니어링이지

🐾 4. 프리 티어 EC2 인스턴스의 메모리 성능 제한으로 인한 crashing

🧶 이슈 소개

띄워 둔 EC2 인스턴스로 ssh로 접속해 개발을 진행했다.

원활한 개발을 위해 VSCode의 remote SSH 확장을 이용해 개발하다, python lint(pylint와 pyright), python code formatter까지 사용하려고 확장에 추가했는데, 어느 순간 램이 버티지 못해 계속 인스턴스가 먹통이 되었다.

🧶 발생 원인

처음에는 왜 안 되는지도 잘 몰랐다.
몇 번 인스턴스를 중지하고 다시 시작하기를 반복했을까..
잘 안 되기 시작한 시점이 확장을 몇 개 추가한 이후라는 것을 깨닫고 확장을 지우고 나니 그제서야 다시 정상으로 돌아왔다.

Lint 등의 원활한 사용을 위해 로컬에서 개발하고 서버에 배포하는 방안도 사실 처음부터 고려했었으나,

Selenium은 linux에서와 내 로컬 환경인 windows에서 웹드라이버부터 시작해, 대부분의 동작 환경이 상이했다.

WSL을 통해 로컬의 Ubuntu에서 개발해볼까 했으나, 인스턴스의 OS는 amazon linux2였고, 그간의 경험으로 봤을 때 분명 경로나 패키지 등 많은 설정값들이 달라 Ubuntu 로컬에서의 동작과 Amazon Linux 2 서버에서의 동작이 같기를 기대하기 어려울 것이라는 것이 분명하게 느껴졌다.

🧶 해결 방법

프리 티어 EC2 인스턴스에서 1기가 사용이 가능한 RAM 용량을 많이 잡아먹던 Lint 관련 extension들을 비활성화했다.

Remote SSH, 코드 포매터 확장만 사용하고, 린트는 아직 사용하지 않고 있다. Docker 등을 활용하면 로컬 WSL 환경에서도 서버에서의 개발 환경과 거의 동일하게 구성해 안정적으로 개발할 수 있을 것 같다. 추후에 더 필요성을 느끼면, 도커를 활용한 개발환경도 구축해야겠다.

🐾 5. default 쉘 zsh 설정 과정에서의 이슈로 인한 VScode ssh 접속 불가

🧶 이슈 소개

VScode에서 remote SSH 확장을 이용한 서버로의 접근이 실패했다.

에러 메시지를 따로 캡처해 두지 않았으나, 터미널에서는 잘 접속이 되었으나 VScode를 통해 접근하려고 하는 경우 무한 로딩만 일어나고, 접근에 실패했다.

🧶 발생 원인

Shell로 zsh를 사용하고 있었는데, .bashrc 파일에서 exec zsh를 통해 default shell을 zsh로 설정한 것이 원인이었다.

🧶 해결 방법

비슷한 이슈를 겪는 사람의 경우를 참고해 기본 쉘 설정을 chsh를 사용해 수행했다.
Amazon Linux 2에는 chsh가 기본으로 설치되어 있지 않아
sudo yum install util-linux-user -y을 통해 설치했고, chsh -s $(which zsh)를 수행해 기본 쉘을 zsh로 설정해 주니 VScode에서도 접근이 되었다.

혹 인증 문제로 기본 쉘을 바꾸지 못하는 분이 계시다면, 초기 비밀번호 설정을 sudo passwd 사용자 이름으로 제대로 수행했는지 확인하면 될 것 같다.

나의 경우에.. 사용자 이름이 ec2-user이었으나 그냥 루트 권한을 설정하면 되는 줄 알고 sudo passwd root만 반복하다 잠깐의 절망을 맛보았다.
금방 깨달았기에 망정이다.

🐾 6. Iframe 태그 스크래핑

🧶 이슈 소개

BeautifulSoup을 활용해 HTML을 파싱했고, select 혹은 find를 통해 찾고자 하는 선택자에 접근했는데, 자꾸 ~~~ has no attribute ### 에러가 발생했다.
스크린샷을 찍어두지 않아서, 에러 메시지는 기억에 의존하는 점 양해 바란다.

분명 개발자 도구를 열어 확인했을 때는 내가 찾고자 하는 id를 가진 요소가 존재하는데, BeautifulSoup가 찾아내지를 못하는 이슈가 있었다.

🧶 발생 원인

Iframe은 HTML 안에서 인라인으로 HTML을 렌더링할 수 있도록 하는 요소이다. 아래와 같이, HTML에서 <iframe> 태그 이후에는, 새 HTML 파일이 처음부터 렌더링되는 것을 확인할 수 있다.

이렇게 iframe 태그를 활용하는 구조에서, BeautifulSoup으로 HTML 파싱을 수행하게 되면, 아래와 같이 <iframe> 태그 내부 요소들은 가져오지 못한다.

🧶 해결 방법

ifrmae 태그를 잘 살펴보면, 어떤 source에서 새 HTML 파일을 가져올지 src가 attribute로 존재하는데, 이 부분을 도메인 뒤에 연결해 source HTML 파일이 존재하는 경로를 찾을 수 있었다.

🐾 7. 몇 가지 사소한 것들..

개발 중 실수로 테스트용 파일에 하드코딩된 Slack 봇 인증 토큰이 Github에 노출되어 봇이 강제로 비활성화되거나,

셀레니움을 쓰면서 driver.quit()를 해주지 않아 프로세스 및 /tmp 디렉토리가 크롬 웹드라이버 관련 디렉토리들로 점령당하는 사소한 이슈들도 많았다.

다시 앱을 추가하고, 올바르게 드라이버를 quit시켜주는 것처럼 간단하게 해결했고, 이상의 간단한 이슈들은 생략한다!

🐈 후기

절대적으로 모든 걸 다 알고 있는 사람은 없고, 특히 지금의 나는 아는 것보다 모르는 게 훨씬훨씬 많다.

그렇기 때문에 생각만 하기보다 경험해 보는 것이 중요하고,
실행력이 좋은 내 성향은 큰 강점이라고 생각한다.

생각하는 것과 해보는 것은 정말 다르고, 그 과정 속에서 생각지도 못한 것들을 많이 배우게 된다. 특히 매번 이슈들을 마주하면서 왜 학교 공부가 중요한지 나날이 깨닫게 된다😅
내년 학부 3학년 때 시스템 프로그래밍, 데이터베이스, 운영체제, 네트워크와 같은 핵심 CS 과목들을 많이 들을 예정인데, 벌써 기대가 된다.

2019년 1학년 때 처음 C언어를 배울 때에는 왜 배워야 하는지에 대한 납득을 하지 못했었다.

C언어 쓸데없고 어렵기만 한데 왜 알아야 할까 파이썬 쓰면 포인터 몰라도 되는걸

라고 생각했고, 불만만 가득해 재미도 느끼지 못하고 과제도 정말 억지로 했다.

근 1년간 재미를 붙여 이런저런 프로그램들을 만들어 보면서 1년 전의 나보다 정말 많이 성장했는데, 새로운 것들을 배우는 과정 속에서 늘 부족한 점이 많은 것들을 느끼고, 앞으로도 달려나갈 길이 많이 남은 것 같아 기대가 된다.

앞으로 더 성장할 내 모습을 기대하며 글을 마무리한다😎

여담) 2022년 11월 기준 지금은 C언어는 최고의 언어라고 생각한다. 누가 쓸데없다고 했냐