업보 청산하기

2024년 1월 17일 수요일

Today I Learned

날짜

2024년 1월 17일 수요일

내용

일이 많이 꼬여서 밤 새는거 아닌가 싶었으나 늘 그랬듯 답을 찾았다.

또경변수

지긋지긋한 ECS Task가 또 말썽을 부린다. 오늘 아침에 구글 스프레드시트에 추가되었어야 할 데이터가 추가 되지 않았다! 하필 1시간이 지나버려서 Task 기록도 안남았다. 실행 주기를 바꿔 실행해봤더니 또 환경변수를 못찾는다고 땡깡부린다. 하…

그동안은 테스트서버였고, 지금은 실서버라서 Task에 문제가 전혀 없는데 도대체 어디부터 또 시작해야 할지 눈 앞이 깜깜해졌다. 환경변수가 있는데 왜 못찾냐고! Task 상세정보를 봤는데 내가 알던 환경변수 경로와 달랐다. 생각해보니 실서버는 production을 위한 환경변수를 받아야 하는데 추가를 안해줬다. 진짜 없어서 못찾았구나? 그래도 미안하진 않다. 추가해주니 잘 작동한다.

스프린트 시작!

PMF를 찾은 프로덕트를 런치하기 위한 스프린트에 돌입했다. 이전에 플래닝미팅과 여러 회의를 통해 기획과 구성, 공수에 대해 이야기를 나눴고 협의가 있었다. 나름 열심히 생각하면서 일정을 짰다고 생각하지만 막상 들어가니 골치아픈 일이 참 많았다.

우선 데이터베이스 테이블에 대한 생각이 부족했다. 테이블을 추가해야 하는가? 추가해야 한다면 무엇을 위한 테이블이며 어떤 칼럼이 필요한가? 다른 테이블과의 관계는 어떻게 되는가? 기존에 있는 테이블에 추가 할 수 있는 방법은 없는가? 각 구현 방향에서 성능의 차이는 어떤가? 등등… 다행히 존경하는 선배님의 도움을 받아 협의 끝에 얼추 정했다. 하지만 시간으로 봤을떈 이미 Task 하나가 끝났어야 하는 시간인데.. 괜히 나 떄문에 일정이 꼬여서 다른 팀원들에게 피해를 끼칠까 걱정이다. 좀 더 많이, 깊이 고민했어야 했나라는 생각이 들기도 하지만 아직까지 코드를 직접 썼다 지웠다 하는 과정이 없으면 구현 방향에 대해 생각이 잘 나지 않는다. 분명 발전해야 할 부분이다.

플래닝 미팅에선 내가 해야할 부분을 작은 Task 단위로 쪼개고, 각 Task의 공수에 대해 이야기를 나눴다. 쪼갠 Task에 대해서 나도 모르게 각각을 API로 생각하고 있었다. 왜 그랬는진 지금도 이해가 가지 않는다. 내가 맡은 부분은 받아온 리뷰 데이터를 바탕으로 분석 결과를 도출하는 부분인데 사실 여긴 API가 많이 필요하지 않다. 전체 결과를 보내주면 되는 부분이지, 데이터 하나하나를 따로 요구할 리도 없고 보내줄 필요도 없다. 프론트에서 결과를 보여줄 수 있도록 모든 데이터를 잘 담아 보내주기만 하면 되는데.. 아무 생각없이 router부터 만들고 있었다. 내가 만든 기능의 Flow도 예상하지 못하니 발전해야할 부분이다.

잘한 부분이라면.. 그래도 생각없이 작성하진 않았다는 것? weekly review report email을 보낼 때, 처음에는 조건에 맞는 데이터를 가져와서 갯수나 평점을 계산했었다. 하지만 데이터베이스에서 계산한 결과를 가져오는 것이 성능상 더 유리하다는 조언을 듣고 바꾸었는데, 이번에도 그 생각이 났다. “그렇다면 import한 리뷰를 저장해야 데이터베이스에서 처리 할 수 있는데, csv 형식으로 가져온 것은 당연히 저장되지만 aliexpress에서 가져온 리뷰는 어떻게 저장해야할까?”라는 의문이 들어서 Task의 진행 방식에 대해 제대로 고민할 수 있었다. 물론 이 고민을 더 빨리 하지 못했으니 발전해야 할 부분이다.

로컬 DB

온보딩이 끝나고 맨 처음 로컬환경을 구축할 때, 뭐가 뭔지 하나도 몰랐다. 솔직히 그때 컨테이너 가동하는 법도 몰랐으니까.. 사실 가동하는 명령어만 알지 지금도 크게 다르진 않다. 테스트 서버 RDS에서 데이터를 가져와 로컬에 집어 넣어야했다. local-postgres 라는 컨테이너 안의 데이터베이스에 넣어야 했는데, 컨테이너 안의 데이터베이스를 pgadmin4로 보는 법을 몰라 고생했다. 결국 GUI 없이 powershell 명령어로 열심히 꾸겨 넣었다.

그 결과 데이터베이스는 postgres, local_review, local_shop 3 개가 탄생했다. 하지만 local_Review와 local_shop 데이터베이스가 사용되는 일은 없었다. 각각의 테이블들이 postgresl 데이터베이스 안에 합쳐져서 싹 다 들어가 있었기 떄문이다. review는 49개의 테이블, shop은 64개의 테이블을 각각 가지고 있는데 postgres는 113개의 테이블을 모두 가지고 있었다. 그리고 내가 데이터를 추가하면 review나 shop이 아니라 postgres에 저장됐다. 실제 우리 서비스는 두개의 데이터베이스를 가지지만, 로컬에서 나는 하나만 운용하는 꼴이 되버렸다! task를 진행하는 데는 지장이 없어 고치는 걸 미루고 있었다.

오늘 Task 과정에서 데이터베이스에 테이블을 추가해야했다. 잘 되지 않아 마이그레이션을 해야하는데 내 데이터베이스 구조가 개판이니 당연히 될 리가 없었다. 코드를 짜도, 데이터베이스 모델링을 제대로 했는지 확인할 수가 없고 데이터베이스가 갖춰지지 않으니 더미데이터로 테스트도 못했다.

더 미루다간 대참사가 날 것 같아 집에 와서 열심히 뚝딱거린 끝에 고쳐냈다. 마이그레이션도 제대로 작동해서 새로운 테이블이 이쁘게 잘 생겼다. 이제 정말 온전히 Task에 집중할 수 있겠다..

고해성사를 하나 더 하자면, 그동안 로컬 db를 powershell로 보고 있었다. 의도치 않게 나의 쿼리문 작성 실력이 늘긴 했지만.. 원인은 pgadmin4로 내 로컬 데이터베이스를 볼 수가 없기 때문이다. 최근에는 기가막힌 창의력을 발휘해서 pgadmin4를 위한 컨테이너를 추가하고 그 pgadmin4 port를 5050으로 설정해서 거기서 들여다 보고 있다. 데스크톱 프로그램으로 볼 수 없는 이유는.. 오류가 아래처럼 뜨기 떄문이다.

Untitled

난 도저히 이걸 뭐라고 검색해야 할지 모르겠다. 얼마나 나쁘다는걸까? 하지만 난 답을 찾을 것이다. 늘 그랬듯.

회고

한 번 할때 제대로하자. 업보쌓지말자.