오 괜찮네 ELK 써보죠
지금까지 회사에서는 API 콜 횟수라던가 로그를 보는 목적으로 사용했다.
그런데 이번에 주소검증에 대한 속도 문제가 발생하여 이것을 엘라스틱서치로 해결할 수 있다고 판단해서 주말 내내 좽일 작업을 해서 오전에 보여드렸다.
그리고 쓰자! 라는 이야기가 나왔고 세부적으로 디테일을 알아보자라는 이야기를 들었다.
주소검증 저희가 해야해요?
14시부터 16시30분까지 회의를 계---속 했다.
그러면서 나온 문제가 주소검증을 우리가 해야하는가?에 대한 본질적인 의견이 나왔다.
결론이 우리가 하는게 아닌 것 같다. 라고 나와서 회의가 정리가 됐다.
...내 주말동안 작업한 엘라스틱서치는!?!?!
리더님도 짠하게 바라보시면서 좋은 경험했다고...라고 하기엔 프로덕션에 안올라가면 타격이 큰데 라고 하시면서 위로를 해주셨다(ㅠㅠ)
장시간의 회의로 느낀 것이 있다.
내가 다니는 회사는 B2B라서 적용되는 것일지도 모르겠지만
책임이라는 아주 추상적인 문제가 존재한다.
어떤 일을 했을 때, 누구에게 책임이 있는가? X
어떤 안좋은 일이 벌어졌을 때, 누구에게 책임이 있는가 O
최악의 상황을 가정하고, 문제가 발생했을 때 피해를 누가 보느냐에 대한 문제다.
나같은 경우는 우리가 모든 것을 책임져야한다고 생각해서 어떻게든 작업을 해보려고 한 것이고
회의에서 나온 결론은 우리의 책임이 아니다. 라는 결론이 나온 것인데
이것은 비즈니스의 영역이다.
즉, 개발자는 절대로 비즈니스와 멀어질 수 없다는 것
어떻게보면 비즈니스를 도메인이라고 부르는 것도 맞지 않나 생각하고 있는데
개발자는 개발만 잘하는게 아니라, 어떻게 보면 스페셜 리스트마냥 다양한 관점으로 바라보면
절대적으로 작성하는 코드의 양이라던가, 질이 좋아질 것이라는 생각이 들었다.
덕분에 도메인이 달라진다거나 모르는 도메인을 가면 상당히 어려울 것 같다는 생각도.
버전업! 합시다!
노드버전, TypeORM v0.3 NestJS v9.0의 데드라인이 나왔다.
12월 15일까지 업그레이드 가이드라인 및 베스트프렉티스를 제출 할 것.
달리는 자동차에서 엔진을 갈아끼우는 작업을 드디어 하게 된다.
스타트업이라서 겪을 수 있는 제일 큰 경험이자 괴로움이 아닐까 싶기도 한데(...)
내가 그냥 TypeORM을 담당해서 함 만들어보기로 했다.
시간 짬짬히 날 때 브랜치 따가지고 작업을 하던가... 뭔가 수를 쓰면 되겠지
원래는 Prisma를 도입하려고 했지만, 이게...테이블의 정의가 맞질 않더라
MySQL에서 쓰는 이넘타입의 심볼이 Prisma와 호환이 안돼서 결국 우리는.... TypeORM으로 간다!
요즘 일이 참 많다, 근데 또 해보고 싶었던 것이라 재밌게 하기도 하지만
문제는 뭔가 너무 과하게 하고 있나? 라는 생각이 이번주에 확 들었다.
체력적으로 부담을 느낀 것 같기도 해서 조금 업무량을 줄여야 할 것 같기도하고....
아예 노트북을 회사에 놓고와버릴까 라는 생각도 좀 하는 것 같다.
