항해99 실전 프로젝트 2주차 회고록

1. 이번주는 무엇을 했는가?

시간이 얼마 안 남았다는 조급함 때문인지, 이번주는 시간이 유독 빠르게 지나간 것 같다. 거의 매일같이 새벽 4시를 넘겨가며 개발을 했음에도 아직 해야할 일이 너무 많게만 느껴진다. 일단, 서버쪽은 저번주에 세워놓았던 기본 기능 항목은 거의 구현한 것 같다. 기능을 구현하는 과정에서 정말 큰 문제가 있었는데, 그렇다 할 만한 이슈를 만나지 못했다는 것이다. 굳이 한 가지를 꼽아보자면 TypeORM으로 관계를 설정한 후에 QueryBuilder로 JOIN해야 했는데, 이게 잘 안되었다는 점인 것 같다. 거의 하루정도를 TypeORM으로 JOIN하는 방법을 알아보고, 이해하는 과정을 통해 현재는 QueryBuilder에 약간은 익숙해진 것 같다.

2. N+1

ORM에서 가장 흔한 문제 중에 하나는 N+1 문제이다.

관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n) 만큼 연관 관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오게 되는데, 이를 N+1 문제라고 한다.

Java Spring에서 JPA hibernate ORM의 경우 OneToMany의 기본 조회 방식은 지연 로딩(Lazy Loading)이고, ManyToOne의 기본 조회 방식은 즉시 로딩이므로 N+1 문제를 바로 접할 수 있다고 한다. 반면에, TypeORM은 아래와 같이 어떤 종류의 관계에서도 기본 조회 방식을 적용하지 않는 것을 확인할 수 있다.

export interface RelationOptions {
  /**...*/
  lazy?: boolean;
  /**...*/
  eager?: boolean;
}

주특기 주차에서 개인적으로 N+1 문제를 따로 공부한 적이 있다.

• TypeORM N+1 - Eager Loading
• TypeORM N+1 - Lazy Loading

이 내용을 토대로 QueryBuilder를 사용하여 즉시 로딩 방식을 적용하려면 leftJoinAndSelect를 사용해야 한다는 것까지는 알고 있었다. 그렇다면, leftJoin 후에 addSelect로 특정 필드의 데이터를 조회하는 경우에도 즉시 로딩 방식에 해당하는지 의문이다. 로그로 남겨진 쿼리문을 보면 쿼리문이 한 번만 실행되므로 즉시 로딩 방식에 맞는 것 같은데, 내가 알고 있던 즉시 로딩 방식(불필요한 데이터까지 모두 조회)과는 차이가 있었기 때문이다. 처음 JOIN을 구현할 때에는 lazy 로딩 방식으로 구현하려고 하였으나, leftJoin과 leftJoinAndSelect는 무슨 차이가 있는지 알아보다가 한 번 적용해보았는데, 코드 가독성면에서 훨씬 괜찮은 것 같다. 이게 진짜로 괜찮은 방법인지는 증명해보아야 하겠지만, 필요한 데이터만 조회한다는 점에서는 lazy 로딩 방식의 장점이 적용된 eager 로딩인듯한 느낌이다.

TypeORM의 버전이 계속 업데이트 되고 있는데, 0.2.x 버전과 0.3.x 버전의 차이가 꽤 있는 것 같다. 처음에 Express에서 TypeORM 0.3.x 버전을 사용했을 때에는 DataSource 객체로 TypeORM 설정을 해주어야 했다. NestJS에서 아직 0.3.x 버전을 지원하지 않기 때문에 0.2.x 버전을 사용하고 있다.

3. 걱정 아닌 걱정

기본 기능을 구현하면서 생긴 걱정거리들을 글로 정리해보고자 한다. 위에도 언급했지만, 아직까지 기술적으로 크게 부딪혔다라고 할 수 있는 부분을 찾지 못한 것 같다. 누군가에게는 기술적인 문제라고 생각할 수도 있지만, 내 기준에서는 기술적 문제라고 할 수 없는 것 같다는 생각이 더 강력한 것 같다.

내 기준에서 기술적 문제는 구글링을 통해 해결할 수 없는 문제인 것 같다. 예를 들어, 라이브러리의 버전이 업데이트되면서 아무도 이슈를 남겨놓지 않았거나, 정말 새로운 기술적인 도전을 해보는 경우가 기술적 문제인 것 같다. 이건 기술 멘토링 때에도 질문을 할 수 없는 이유이기도 한데, 직장생활하면서 ‘충분히 검색해보고 정말 모르겠는 내용’을 질문하려는 태도가 아직도 몸에 많이 베어있는 것 같다. 다만, 코드를 왜 그렇게 작성했는지, 폴더를 왜 그렇게 나누었는지 등에 대해서는 할 말이 많을 것 같다. 이것도 기술적 문제라고 하면 기술적 문제일 수 있겠으나, 이 주제로 발표하라고 한다면, 글쎄… 잘 모르겠다.

또 다른 걱정은, 지금 프론트엔드의 진도가 매우 늦다는 것이다. 타임테이블대로라면, 오늘로 기본 기능이 전부 구현되고, 서버랑 통신까지 마친 상태여야 했다. 이를 사람의 신체로 나타내면 현재 무릎 위치 정도까지 개발이 완료된 상태로 느껴진다. 프론트랑 서버가 연결되고, 서로 통신하는 과정에서 추가적인 기능, 예상치 못한 오류를 발견하고, 이를 해결해나갈 계획이었는데, 이 계획이 매우 불분명해진 것 같다. 더군다나 엊그제 프론트엔드에서 리팩토링을 진행하길래 코드 수정을 도와줬는데, 죽이 되든 밥이 되든 저희가 알아서 할게요라는 말을 들은 이후로는 무엇을 우선적으로 처리해야할 지 감이 잘 잡히지 않는다.

3. 디자이너의 관점과 개발자의 관점

이번에 들어오신 디자이너분들 모두 훌륭하신 것 같다는 생각을 줄곧 해왔다. 굉장히 적극적이시고, 신선한 아이디어도 제안해주시고, 책임감을 갖고 끝까지 하려는 모습에서 큰 힘을 얻었던 것 같다. 그런데, 우리(개발자)가 디자이너분들의 좋은 아이디어를 실현시킬 시간이 부족하다는 사실에 항상 죄송스러운 마음이 있었는데, 어제 밤 12시부터 아침 8시까지 디자이너분과 대화한 끝에 서로의 입장을 이해하고, 오해를 풀게 되었다. 우리가 개발한 서비스가 얼마나 훌륭한지도 중요하지만, 개발자는 어떠한 문제가 발생하였고, 어떻게 해결하였는지에 큰 비중을 두고, 최대한 디자이너분들께서 해주신 디자인을 맞추기로 하였다.

4. 다음 주 계획

내일부터는 NestJS 단위 테스트, 통합 테스트 코드를 작성하고, 소켓 통신 쪽을 구현할 것 같다. 소켓 통신을 테스트하기 위해서는 프론트엔드와 연결해보아야 하는데, 이건 간단하게 React 코드를 작성해서 테스트 해보아야 할 것 같다. 시간이 얼마 안 남았지만, 그래도 끝까지 최선을 다해보려고 한다.