23년 2월 회고
이대로는 안되겠다
개요
집, 회사를 반복하던 일상에서 벗어나고자 2월은 외부 활동에 집중했던 시기였다. 새로운 분들도 만나고 유튜브 스트리밍으로 발표도 해보면서 색다른 경험을 가지는 시간이었다.
발표하기
2월 22일 유투브 스트리밍으로 “나는 어떻게 ooo이 되었는가?”를 발표하게 됐다. 자세한 내용은 이미 포스팅으로 올라와있으니 생략하겠다.
“나는 어떻게 ooo이 되었는가”를 준비하면서 알게된 점은 나는 어느 순간마다 “이대론 안 되겠는데?”하면서 적절한 판단을 내리고 그에 따라 계획을 세우고 행동을 시도한다는 점이었다. 외부 활동을 하려고 했던 것도 왠지 그런 점과 밀접하게 닿아있지 않을까라는 생각을 하게 된다.
문제는 외향적인 성격이 아니어서 평소보다 에너지가 많이 들었다. 그래서 그런지 개발하는데 쓰는 시간을 적절히 분배하지 못했다.
결과적으로 이번 달에는 특별히 개발 부분에서 새로운 시도 하게 된 것이 없다는 게 흠이라면 흠이다.
알고리즘 풀어나가기
“kata”라는 용어가 있는데 이는 특정 무술을 실전에서 사용하기 전에 연습을 위한 용도로 사용되는 일련의 동작을 지칭하는 말이다. 태권도의 “품새” 같은 것이라고 이해하면 되는데 이러한 연장선상에서 알고리즘을 풀기로 시작했다.
학생 시절 “수학”에 대한 문제 풀이를 잘 못해서 그런지 알고리즘 문제를 푸는 게 학생 때를 생각하게 만들어 회피하고 있었는데 앞서 언급했듯 왠지 “이대론 안 되겠다”를 생각이 들어서 풀어나가기로 했다.
다음은 2월에 푼 문제 목록이다.
02.06 92, 역순 연결리스트2
02.07 Linked Stack
02.07 20, 유효한 괄호
02.09 Jaden Case
02.10 카펫
2.13일 짝지어 제거하기
2.14일 22, 일일 온도
2.15일 구명보트
2.15 ~ 2.16일 개인정보 수집 유효기간
2.16 가장 가까운 같은 글자
2.20, 카드 뭉치
2.21 [카카오 인턴] 키패드 누르기
2.22 기사단원의 무기
2.23 숫자 짝꿍
이 중에서는 힌트를 보고 풀기도 하고 힌트를 안 보고 푼 것도 있는데 핵심은 Code Kata를 연습하는 데에 의의를 두기로 했기 때문에 “힌트”를 보고 풀었어도 “왜 이런 레벨 낮은 문제도 못 풀지” 하는 생각은 접기로 했다.
알고리즘 문제 풀이도 익숙하지 않아서 머리로만 생각해서 푸는 건 거의 불가능하고 직접 Ipad에 풀이 아이디어를 적어보면서 구성하는 방식으로 풀어나가고 있다. 그래서 그런지 문제만 보고 머릿속으로 알고리즘을 떠올려 문제를 푸는 사람들을 보면 경이롭게 느껴진다.
컨디션 대처하기
7시간 이상의 수면을 취하는데도 불구하고 잠을 잘자지 못하는 것 같아 이를 개선하려고 단백질, 아르기닌, 오메가 3을 챙겨 먹기 시작했다. 아직 일주일 정도밖에 먹지 않았음에도 불구하고 자고 일어나면 그래도 상쾌하게 일어나는 편이다.
작년에 영양제를 한 번 챙겨 먹어봐서 그런지 이제 조금은 컨디션이 안 좋을 때 어떻게 대처해야 하는지 하나씩 알아가는 느낌이다.
App Runner Trouble Shooting
사내에서 App Runner를 실험적으로 써보고 있는데 스케줄링 처리가 적용된 상황에서 메시지를 2번 전송하게 되는 현상을 겪게 되었다. Flask에 ApScheduler라는 라이브러리를 사용해서 올려놨었는데 처음에 감이 안 잡혔는데 최근 들어 겨우 어떤 게 문제인지 알 것 같았다.
처음엔 스케줄링 시간문제라고 생각했다. 예를 들어 오후 3시 00분에 돌아가게끔 작성한 코드가 실패하여 구동한 서비스를 다시 시작하게 될 경우 오후 3시 00분에 시작한 것이기 때문에 2번 돌아가는 것인지 짐작했다.
즉 정확하게 3시 00분 00초라고 지정하면 메시지가 2번 전송 안 되겠지 싶었는데 이 가설은 틀렸었다. 이 문제를 상세하게 쫓으려면 App Runner가 코드가 실패했을 때 정확이 어떤 식으로 수행하는지 그리고 ApScheduler의 내부를 분석할 필요가 있는데 그렇게까지 하는 건 왠지 시간이 많이 가는 작업이라 판단하고 다른 해결 방법은 뭐가 있을까를 생각했다.
두 번째 접근법은 똑같은 조금은 다른 결이 다르게 접근했다. App Runner가 컨테이너를 실행할 때 Flask App을 생성한다면 ApScheduler라는 객체의 초기화가 2번 이루어지는 게 아닐까 싶었다 ApScheduler를 실행할 때는 start()라는 메서드를 호출함으로 스케줄링 작업을 호출하는데 이 부분에서 start() 호출하는 시점을 조절해 주면 어떨까 싶었다.
결론적으로는 두 번째 접근법에서 도출한 해법이 메시지를 2번 전송하지 못하게 했는데 실험 중인 단계라서 이게 정확한 것인지는 두고 볼 필요가 있겠다.
SQLAlchemy와 sqlalcodegen
3.11에서는 호환이 안 되나 보다. sqlalcodegen의 pypi를 보니 rc 버전이 보여서 pip으로 설치했다.
pip install sqlacodgen==3.0.0rc1
설치하고 나니 다음과 같은 에러가 나온다.
AttributeError: module 'sqlalchemy' has no attribute '__all__'. Did you mean: '__file__'?
아무래도 sqlalchemy에 의존적이다 보니 sqlalchemy를 봤는데 버전이 2.0을 쓰고 있었다.
https://pypi.org/project/sqlacodegen/3.0.0rc1/를 읽어보니 sqlacodgen은 sqlalchemy 1.4를 지원한다고 나와있다. sqlalchemy를 2.0 → 1.4로 다운그레이드하니 오류가 해결되었다.
공휴일 데이터 받아오기
Slack Bot에서 공휴일과 국가공휴일인 경우 메시지를 전송을 하지 않기 위한 방법을 생각했었다. 공휴일인 경우 datetime 모듈을 통해 처리한다고 해도 국가 공휴일은 어떻게 처리할까?라는 문제에서는 언뜻 해결법이 생각나진 않았다.
찾아낸 해법은 한국공공데이터포털에서 제공하는 API를 이용하는 것인데 뭔가 석연치 않은 점이기도 했다. 어떤 대상을 판단하기 위해 외부 API를 사용해야 되고 이런 과정을 반복하다 보면 Project는 외부 API에 의존하기 때문에 외부 API에 대한 관리 포인트라던지 구조의 복잡성 문제가 커지는 상황이 되려 역효과이지 않나 싶은 생각이 들었다.
그런데 Slack Bot 자체는 가볍게 만들고 있어서 이러한 문제도 크게 신경 쓰지 않기로 했다. 말 그대로 서비스가 커지기도 전에 “우리 서비스 잘되면 어쩌지?”하는 너무 과하게 서버를 설계하는 호들갑 같은 부분이라고 봤기 때문이다. 향후 발생할 수 있는 문제를 식별하고 미리 대처하는 방법들을 생각하는 것도 좋지만 지금 처한 상황이 어떤가 가 더 중요한 포인 트지 않을까 싶다.
영어 때우기
아침에 일어나서 간단하게 10 ~ 20분 정도 영문법을 보고 있다. 아침에 짧은 틈에 봐서 그런지 진도가 확확 나가거나 본 내용들이 머릿속에 확 남지는 않지만 시작하는 단계에서는 꾸준히 보는 것을 목표로 삼았다. 조금 더 큰 목표는 원어민 수준의 회화 능력과 번역의 도움 없이 기술문서를 획획 해독해 나가는 것인데 지금 단계에서는 너무 원대한 꿈이지 않나 싶다.
Summary
2월도 끝나고 내일이면 벌써 3월이다. 어떻게 보면 벌써 1분기가 끝나가기 때문에 신년에 세웠던 목표들을 다시 보고 정량적으로 측정해볼 필요를 느낀다.
