출근 29일차

·2022년 10월 5일
0

회사이야기

목록 보기
29/118

오늘은 오랜만에 사무실 출근을 했다!

...이주만에 갔나?

재택근무는 확실히 한계가 있다.

현재 거대한 작업을 하고 있는데, 딜레이가 걸려서 PR을 못 올리고 있었다. (PR을 한번 올리고, 수정하는 커밋을 계속 못올리고 있었음)

그러다보니 작업물을 알릴 수 없다보니, 조금 걱정되는 부분이 있으셨나보다.

그래서 지금 작업물을 보여드리면서 이렇게 진행되고 있고 현재 코드는 이만큼 작성되어있다~하면서 전반적으로 리더님한테 설명을 드렸다.
더불어서 CTO님도 지나가시길래 붙잡고 이렇게 작업이 진행되고 있다! 라고 알렸다.

최근 스페이스에서 작업이 거대할 경우 PR을 하루에 한개도 올리기 힘든 경우가 발생하는데
재택근무를 할 경우에는 저것을 파악할 수 없기에 조금 답답한 감이 있다는 이야기를 들었는데

지금 상황이 딱 그렇게 된 것 같아서 음...

일주일에 한번정도는 사무실 출근을 해야겠다 라는 생각이 들었다.

오늘 자리가 세팅이 완료됐는데, 참 좋더라..
회사만 가까웠어도 내가 맨날 출퇴근을 했을텐데 2시간은 쫌...ㅠ_ㅠ

진짜 이사갈까싶더라 작업환경이 갑자기 집보다 좋아짐(;)

도메인 지식은 도움이 된다!

오늘은 운영팀 리더분과 대략 30분 넘게 1:1 미팅을 진행했다.

내가 지금 무슨 백엔드를 하는가 했는데 어제 아는 분께서 백오피스! 라고 하셔서
아! 그런 용어가 있구나!

물류 도메인에서 일을 하고 있는데, 현재 나는 물류창고에서 일하시는 매니저분들이 사용하는 프로그램(?)을 개발하고 있다. (백오피스라는 용어가 있는지 몰랐지)
그러면서 현재 내가 맡고 있는 담당은 출고의 전 과정을 총망라하고 있는 상태인데

나는 실제로 물류창고에서 일도 제법 해봤다.

그래서 계속 프로세스를 보면서 뭔가... 이상한데? 라는 생각을 하고 있었다.

때마침 택배사 연동건 에픽을 내가 가져오면서 모든 것을 다 건드릴 수 있는 기회가 생겼기에
큰 틀에서의 프로세스는 변경되지 않지만, 창고 매니저들이 업무가 조금 더 수월할 수 있도록 바꾸기 위하여 회의 자료를 만들었고

그 자료를 기반으로 운영팀 리더님과 미팅을 하면서 말씀해주신게

뭔가 도메인 지식이 있는 것 같다, 어색하거나 필요한 부분을 제대로 짚는 것 같다. 라고 이야기하셨다.

왜냐하면 물류창고같은 경우에는 정규직 매니저파트타임 알바가 함께 작업이 이뤄지는 경우가 상당히 많다.

그렇다는 소리는, 프로세스가 최대한 간결하고 단순하게 만들어야한다는 것이다.

왜?

  1. 파트타임을 가르치는데는 시간이 들어간다.
  2. 실수를 할 경우 오배송의 문제로 클레임을 받을 수 있다.

즉 직관적이고, 명확한 프로세스일수록 작업 효율이 늘어난다는 것이기에, 이런 부분이 눈에 많이 거슬렸다.

내가 직접 해봤으니까, 불편한게 뭔지 경험을 해봤으니까

그래서 그런 부분을 바탕으로 미팅이 진행되서 많은 것들에 불편함이 있다길래
최대한 풀어보려고 노력을 하는데...

아 어렵네...? 옵션값 한개만 더 주면 좋겠는데 한개밖에 없어가지고 조금 나사가 빠질 것 같다..
하하 젠장

아이고 DataSource 어케쓰는건데

어 뭐야 Too many connections? DB 커넥션이 꽉찼다고? 이게 먼 개소리야!?

외부서비스로 뽑아서 내가 작업하고 있는 서버는 메인 프로덕트와는 다르게 TypeORM v0.3.7을 사용하고 있다.
그리고 TypeORM으로 두개의 DB를 한번에 써야하고, 기왕이면 이번 버전에 들어온 것을 써보자! 라고 해서 쓰고 있었는데

기존에 커넥션이 이어져있다면 재접속하는 옵션이 사라져있더라. (여기서 싸함을 느끼긴 했는데)

그리고 DataSource의 특징은 DB에 계속 커넥션을 물려놓는 것이 아니라, 쓸 때 연결하고 끊는 것이라고 적혀있길래

난 서버를 끄면 커넥션도 자연스럽게 끊어지는 줄 알았지...

응 안꺼진다.

이건 TypeORM 공식 문서에 있는 예제자료인데 이렇게 쓰면 안된다(...)

그래서 방금 찾다가 TypeORM 레포에 TS 예제가 있어서 한번 보고 왔는데

....이렇게 쓰는거라고? 진짜?

그냥 TypeOrmModule.forRoot({})에 담아서 쓰는게 맞을 것 같다는 생각이 든다...
아무튼 좀 고려를 해봐야겠다(...) TypeORM v0.3 + NestJS + DataSource의 자료가 아직은 좀 빈약한 것 같더라

찾아도 내가 원하는 모양세가 안나와 음음


https://levelup.gitconnected.com/nestjs-multiple-db-setup-with-typeorm-a78cb05a085

이렇게 쓰는 방식도 있긴 한데...
데이터소스로 쓰는 편이 확실히 코드가 전반적으로 깔끔한 것 같다.

일단 연결이 안끊어져있으면 다시 물리는 설정을 잡아놨으니까 커넥션이 터지는 일은 없을텐데 ㅋㅋ

오후에 있던 상황...

나 : 리더님 이거 왜 커넥션 풀이라고 안들어가져요 ㅠ
리더님 : ? ㄱㄷ 제꺼 커넥션 풀어볼게요
리더님 : 접속해봐요
나 : 대네?
리더님 : ㅋㅋㅋㅋ???
리더님 : 이거 커맨드 쳐봐요 (까먹음, 커넥션 물려있는걸 다 볼 수 있는 쉘스크립트였다)
나 : 오.... 겁나 많이 물려있네....
리더님 : 그냥 쉘에서 디비 접속 해제해볼래요? (AWS에서 커넥션 물린거 개수보고계심)
나 : 끊었어요
리더님 : 커넥션이 확 줄었는데?
나 : 아 ㅋㅋㅋ
~확인중~
나 : 아.... 커넥션이 안풀렸으면 다시 그걸로 연결해야하는데 새로 연결했네요...

근데 흠 임시방편처럼 한 느낌이여가지고 조금 더 확인을 해봐야할 것 같다.

쿼리 요청은 잘 됐다!

NestJS Typeorm v0.3 이상에서 2개 이상의 DB를 DataSource로 사용해보신 분을 찾습니다...


내일은 출근한지 30일차, 그리고 백엔드 월간 회고의 날이다!

자야지

profile
물류 서비스 Backend Software Developer

0개의 댓글