kakasoo

const users = this.userRepository.createQueryBuilder('u') .addOrderBy('u.height', 'DESC', 'NULLS LAST') .getMany(); orderBy의 세번째 파라미터로 NULLS LAST, NULLS FIRST를 지정해서 처리할 수 있다.

1. 기획과 계획은 다르다. 계획이 어떻게 할 것인가에 대한 것을 의미한다면, 기획은 무엇을 할 것인가에 가깝다. 무엇을 할 것인가. 그 기준은 고객에게 있다. 우리가 가치있음은 고객이 우리 가치를 인정하기 때문에 발생한다. 따라서 고객에게 인정 받는 제품을 만들어야 한다. 다만 고객이 인정하는 우리 가치가 고스란히 우리의 것은 아니다. 때로 우리가 제품을 만들다보면 정해진 고객 안에서 더 많은 매출을 내기 위해 고군분투할 때가 있다. 이 역시 반드시 필요한 과정임에도, 이 과정은 고객에게는 쓸모가 없는 일이다. 우리가 고객의 가치를 창출할 때 비로소 살아남을 수 있지만, 우리가 우리의 가치를 창출하는 일은 고객의 관심 밖이다. 우리는 어떻게 고객의 가치를 창출하면서도 우리 가치를 챙길 수 있을까, 생존..

최근에 뜻밖의 뉴스를 봤다. 강아지도 암에 걸린댄다. 강아지가 암에 걸리는 건, 기존에 없던 현상이었다. 그래서 더 더욱 충격일 수 밖에 없었다. 기존에 암에 걸리지 않던 동물도 암에 걸리다니. 암에도 전염성이 있던가? 아니면 강아지라는 종이 인류를 만남으로 인해 면역체계가 약해지기라도 했는가? 관심이 생겨 찾아보니, 강아지가 암에 걸리는 건 그저 수명이 늘어난 탓이었다. 인류의 기대 수명이 늘어남에 따라 치매나 골다공증과 같은 문제들이 자주 발생하기 시작한 것처럼, 강아지 역시 이전과 달리 더 긴 수명을 누릴 수 있게 됨에 따라 노화 문제가 발생한 것이다. 이걸 문제시할 수 있는가. 물론 당사자인 노인, 그리고 강아지에게는 고통스럽겠지만, 일단 이 문제의 발생조차도 이전보다 인류와 강아지라는 종이 더 ..

네이버의 사용자 체류 시간을 늘리기 위해 무엇을 해야 할까. 검색을 어렵게 만들면 된다. 아니, 검색창을 없애면 된다. 그러면 유저는 자신의 원하는 정보를 찾기 위해 여기 저기 눌러볼 수 밖에 없다! 하지만 이건 바보 같은 방법인 걸 누구나 알 것이다. 검색창을 없애면 체류 시간이 늘어나다 못해 사용자들은 모두 이탈하고 말 것이다. 서비스는 이처럼, 유저에게 편의성을 제공하여 자체적으로 체류 시간을 줄이는 선택을 해야 한다. 정확히는 체류 시간을 줄이는 선택을 함께 해야 한다. 서비스가 잘 되기 위해서는 유저의 체류 시간을 늘리는 것이 맞지만, 반대로 유저의 체류 시간을 줄이는 것도 함께 고려해야 한다. 우리가 제공하는 가치가 얼마나 효과적인지 보기 위해서는 체류 시간이 짧아야 한다. 유튜브 숏츠 영상을..

좋은 문장이 많았다. 하지만 내가 문장을 이해하더라도, 경험 부족 등의 이유로 아직 체감되지 않는다면 옮기지 않는다. 19p 모든 비즈니스 케이스의 핵심적인 두 가지 요소를 기억하는가? ‘얼마만큼의 돈을 벌 수 있는가’와 ‘얼마만큼의 비용이 드는가’다. 자, 냉엄한 진실은, 현재 시점에서 우리는 이 두 가지 수치에 대한 근거가 전혀 없다는 것이다. 솔직히 우리는 알 방법이 없다. 왜 해야 하는가? 무엇을 위한 것인가? 누가 ( 어떤 고객이 ) 하라고 했는가? 그 누가 몇 명인가? 그 누가 어느 정도 매출에 영향을 주는가? 이렇게 하라고 했는가? 나는 일을 할 때는 항상 사용자와 비즈니스 관점에서 질문을 던져봐야 한다고 믿는다. 납득이 되지 않는다면 아직 실행에 옮겨서는 안 된다. 납득 없이 바로 행동하는..

잘못된 팀 빌딩은 팀을 망친다 스타트업이 망하는 이유는 각양각색이지만, 최근 들어 드는 생각은 그 이유들이 꼭 한 가지는 아니라는 점과, 그리고 하나의 원인이 여러 개의 원인으로 늘어난다는 점이다. 이러한 사실로 볼 때, 나는 인사가 만사라는 점에 동의한다. 논리적 비약처럼 보일 수 있겠지만, 이 하나의 원인에 가장 부합하는 게 결국 잘못된 팀 빌딩이라고 보기 때문이다. 예컨대 사람을 잘못 뽑게 된다면 팀의 생산성은 낮아질 것이고 당연히 고객의 요구를 충족하지 못할 것이다. 이걸 제품이 매력적이지 않았다는 이유로만 보게 된다면, 아마 스타트업의 대표는 앞으로도 제대로 된 제품을 만들지 못할 팀으로 계속 피봇(Pivot)을 반복하게 될 것이다. 좋은 팀을 결성하지 못하는 것 (NOT THE RIGHT TE..

오늘도 느꼈다. 기본이 무엇보다 중요하다. 응용도 중요하지만, 그걸 위해서라도 기본을 챙겨야 한다. 당연한 말을 굳이 블로그에까지 남기는 이유는, 이 당연함이 생각보다 무시되는 경우가 너무 많아서다. 언제나 정도가 중요한 건데, 정도는 양 극단 사이의 줄타기처럼 너무나도 비좁은 구역이다. 즉, 당연함이 생각보다 당연하지 않다. 오늘도 그런 케이스를 보고 말았다. 보고 싶지 않은데, 봐버렸다. 많은 고민을 하게 한다. 절이 싫으면 중이 떠나야 하는가?

대학교 기술 세미나에서 발표할 일이 있을 때, 선후배 동문들을 상대로 발표한 적이 있는데, 그 때 코드를 최근 공유할 일이 생겼다. 그래서 블로그에도 올려서, 누구나 볼 수 있게 한다. ( Repository에도 올렸다. ) 지금 가르치는 학생분들을 포함해, Node.js에서 기본적인 서버 구현이 가능한 사람이라면 충분히 배워볼 만 하다. STEP 0. Express 코드 const express = require("express"); const http = require("http"); const path = require("path"); const app = express(); app.use(express.static("public")); const server = http.createServer(a..

지금 내가 개발하고 있는 서비스는, B2B 특성 상 유저에게 주어질 수 있는 권한이 다양하다. 게임처럼 ( 나는 안해서 정확히 모르지만 ) 브론즈부터 플래티넘까지의 계급이 있다고 이해하기 보다, 세부적인 권한을 설정해야 한다. 가령 우리 고객들은, 자기의 후임에게 아래처럼 권한을 줄 수 있다. "배송지를 새로 추가할 수는 있지만, 기존의 배송지를 수정할 수는 없게 하고 싶고, 직접 결제할 수는 없지만 주문 내역을 볼 수는 있다." 우리 서비스 내에서 유저에게 설정해줄 수 있는 권한은 카테고리만 해도 10가지 가량 되고, 세부 항목은 수십 가지가 넘는다. 심지어 이 항목들은, 아직도 기획이 추가되는 단계이고, 점차 확보할 고객 구성에 따라서 더 다양해질 수도 있다. 우리 서비스를 고객들이 어떻게 활용하느냐..

아직 끝나지도 않았지만, 옛날 생각이 떠오른다. 리뷰어는 뭐 하는 사람인가? 코드 리뷰는 위와 같은 구성으로 이루어진다. 코드 리뷰라고 해서, 모든 코드를 한 줄 한 줄 읽는 게 아니고, 자동화한 부분을 제외한 나머지 부분에 중점을 둔다. 코드 스타일은 Eslint, Prettier가 잡아줄 부분이고, 우리는 문서화와 비즈니스에 더 중점을 두고 바라본다고 생각하면 된다. 자동화할 수 있는 부분은 굳이 사람의 눈으로 잡지 않고, 컴퓨터가 대신할 수 없는 부분을 리뷰한다고 생각하면 되겠다. 하지만 부스트캠프에서 이루어지는 코드 리뷰는 누군가를 가르치고, 또한 가까이서 조력하기 위함이기에 모든 단계를 함께 한다. 지나칠 수는 있겠지만, 그래서 더욱 조심히, 코드 스타일에도 관여를 한다. 배우는 단계에 있는 캠..

수직확장과 수평확장 사람들은 확장성과 관련해 용량 확장(수직 확장), 규모 확장(수평 확장) 을 말한다. 수직 확장은 좀 더 강력한 장비로 이동하는 것이고, 수평 확장은 여러 기기들로 부하를 분산하는 것을 말한다. 서로 다른 기기로 부하를 나누기 때문에 수평 확장은 다시 비공유 아키텍처라고 부르기도 한다. 단일 장비에서 수행하는 시스템이 비교적 간단하기는 하지만, 고사양 장비는 매우 비싸 대개 규모 확장을 택한다. 적절한 장비 몇 대가 다량의 낮은 사양 가상 장비, 또는 몇 대의 높은 사양 가상 장비보다 저렴하고 효율적이다. 탄력적 (Elastic) 일부 시스템은 탄력적(elastic)이다. 즉, 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있다. 탄력적인 시스템은 부하를 예측할 수 없을 경우..

TypeORM에는 setFindOptions 라는 메서드가 있고, 이걸 활용하면 할 수 있는 일이 참 많습니다. 하지만 공식문서에는 이 메서드에 대한 소개가 전혀 없는데요, 이건 TypeORM이 반성해야 할 부분 같습니다. 이 메서드는, QueryBuilder가 가진 문제점을 부분적이나마 해소해줍니다. 코드를 통해 보겠습니다. QueryBuilder 사용법 const posts = await connection .createQueryBuilder(Post, "post") .where('post.author IS NULL') .orderBy("post.id", "ASC") .getMany() post를 조회할 때 우리는 where문과 order를 where, orderBy라는 메서드를 통해 해결할 수 있습..