슬기로운 의사생활 심리테스트 개발 후기

인생 드라마 슬기로운 의사생활을 덕질하고 싶었습니다. 슬의생 캐릭터를 소재로 직접 심리테스트를 만들어보고자 절친 2명과 사이드 프로젝트를 진행했습니다. 이 과정에서 느낀 소회와 개발자로서 배운점, (주로) 아쉬웠던 점을 풀어보겠습니다.

우선 결과물

https://www.mbti-hospital-playlist.site/

-> 도메인 변경 : https://friendly-shannon-fbae91.netlify.app/

슬기로운 의사생활 심리테스트

 

프로젝트 파트 회고

야심찬 시작

마케터 친구 덕분에 노션을 적극 활용하며 회의를 진행할 수 있었고, 칸반을 잘 정리해주어 레퍼런스와 회의 내용을 기록할 수 있었습니다.
이때까지만 해도 슬의생이 방영중이던 시점이라 종영 전까지 프로젝트를 마무리할 수 있을거라 생각했습니다.

위태로운 과정

팀원 세명 모두 오랜 친구였지만 각자 사는 삶과 지역(부산/서울/김해)이 달랐습니다. 시국은 둘째 치더라도 서로 너무 멀리 떨어져있어 대면 회의는 힘들었습니다.
프로젝트 진행 초반에는 서로 으쌰으쌰하며 정기적으로 회의를 가졌지만 후반으로 갈 수록 다들 집중력이 흐려지는 것을 느꼈습니다. 기어코 잠정적으로 중단되기도 했습니다(저는 그렇게 느꼈습니다 ㅎ) 줌도 사용해보고, 게더타운도 사용하며 서로의 거리감을 좁혀봤지만 쉽지 않았습니다.
까놓고 말하면,, 프로젝트의 아이디어를 내놓은 제가 책임지고 총대를 메야했지만, 워낙 친한 친구들이다 보니 각자의 바쁜 사정을 이해하다 보니 진행이 더딜 수 밖에 없었습니다.
체계적으로 회의 날짜를 잡고 회의에선 어떤 내용을 픽스해야 하는지, 다음 회의 까진 무엇을 준비해야하는지 등 주도적인 모습을 보여야했지만 그러지 못했습니다. 무엇보다 1인 개발자 팀이다 보니, 기획단계가 끝나면 개발자가 빠르게 치고나가며 프로덕트를 개발해야 했지만, 그 부분에서 뚝심이 부족했던 점이 아쉽게 느껴집니다.

용두사미 결말

결국엔 예상보다 오랜 시간이 걸려 완성했고, 결과만큼 과정이 뒷받쳐주지 못한 프로젝트를 내놓게 됐습니다.
1인 개발이 이렇게 고독하다는 걸 배웠습니다. 이전까진 동아리에서 함께 개발하는 것에 익숙했는데, 혼자 개발하게 되니 모든 작업이 오롯이 저에게만 달려있더군요.

우여곡절 끝에 완성

우여곡절 끝에 트러블슈팅과 검수를 마치며 최종적으로 배포할 수 있었습니다.

---

개발 파트 회고

개발스택
Front-end | Typescript, React, Recoil
Back-end | Typescript, Nestjs
DB | postgreSql
Deploy | Netlify(front), Heroku(back, db)
Design | Adobe Xd

레포지토리 세팅 (배포 세팅)

기존에는 하나의 레포지토리에 front 와 back 프로젝트를 모두 몰아넣었습니다.
그러다 배포 문제에 맞닥뜨렸는데, front 는 netlify, back 은 heroku 배포를 할 예정이었기 때문에 개별 레포지토리가 필요했습니다. 그리하여 두개의 서로다른 레포지토리를 만들어 각각 서버를 배포했습니다. Back end 배포에서 많이 힘들었고 db 역시 heroku 에 함께 배포하며 이런저런 트러블을 많이 만났습니다. 도저히 이해할 수 없는 에러가 계속 생기면서 이 프로젝트는 어디로 가는건가 아찔하기도 했지만, 다행히 97%의 구글링과 2%의 끈기 그리고1%의 운이 닿아 해결할 수 있었습니다.

AWS 를 시도하지 않은 점이 아쉬웠는데, 사실 프로젝트 규모가 작다보니 굳이 AWS 까지 사용할 필요가 있을까 하는 마음이 더 컸습니다. 물론 AWS 와 아직 친숙하지 않은 점, 아직 CI/CD 같은 개념에 미숙한 점 때문에 시도하지 않았다는 것도 인정합니다.

Front-end

React 와 react-hook, 상태관리 라이브러리는 recoil 을 택했습니다.
Recoil 은 확실히 편리했습니다. 보일러플레이트가 전혀 필요 없었을 뿐더러 사용하고자 하는 atom 을 구독하는 형태로, 원하는 컴포넌트 어디에서든 사용할 수 있었습니다. atom-family 와 selector-family 등 더욱 다양하게 사용할 수 있는 기능들이 많았으나 오버 엔지니어링이 될 것 같아 atom 을 주로 사용했습니다. (사실 아직 recoil 을 덜 익혀서)

렌더링 최적화 (feat.lighthouse)

인프런에서 프론트엔드 최적화 수업을 하나 수강했습니다. 배운 내용을 적용하고자 최적화를 시도했고, lazy-loading 과 폰트, 이미지를 preload 하여 렌더링 속도를 더 높일 수 있었습니다. (최적화 전후로 사진을 캡쳐해두었어야 하는데 이런 점이 준비되지 않은게 아쉽습니다.)
다만 강의에서 배운내용이 모두 곧이 곧대로 적용되는 것은 아니었습니다. 스택오버플로우를 좀 더 많이 참조한건 기분 탓이겠죠. 그럼에도 강의를 들었으니 어떤 부분을 최적화 해야겠다는 개념과 기준을 잡을 수 있었습니다.

시행착오를 겪기도 했는데 개발자도구 라이트하우스에서 브라우저와 모바일의 성능 체크 속도가 별개로 있었다는 점입니다. 바보같이 데스크톱에서만 성능검사를 했고 90점이 넘는 점수라 만족하고 있었는데, 모바일에서의 성능체크는 영 아니었습니다. 심리테스트 특성상 모바일 유저가 더 많았을 텐데,,아찔했습니다. 모바일에서 성능 점수가 낮았던 이유는 반응형으로 이미지를 로드하지 않았기 때문이라 생각합니다. 분명 모바일 규격보다 큰 이미지사이즈를 그대로 렌더링 하다보니 용량과 속도측면에서 느려졌을 거란 생각이 드네요. 리팩토링을 할 때 이 부분도 분명 고려해야겠습니다.

만족스런 데스크톱 성능 점수와 그렇지 못한 모바일..

 

애증의 CSS

사실 이번 프로젝트가 오래 걸렸던 이유는 CSS를 0부터 100까지 다뤄야 했기 때문이었습니다. 회사에서는 퍼블리셔팀이 html/css 작업을 담당해주신 덕분에 별도의 작업을 할 필요가 없었지만, 개인 프로젝트이다 보니 직접 css 에 손대야 했습니다. 하지만 덕분에 배운점도 많았습니다. 막연하기만했던 반응형 미디어 쿼리를 직접 손볼 수 있었고, 해당 프로젝트에 적용하진 않았지만 css-in-js 개념인 styled-components 도 알아갈 수 있었습니다.

그럼에도 앞으로 외주 작업이나, 1인 개발을 계속 하고 싶은 욕심이 생겼고, 좀 더 체계적으로 html/css 를 배우고 싶어졌습니다. 왜인지 모르겠지만, 전에 유튜버 김버그님이 다른 구독자분에게 코드리뷰를 해주는데, 'div 밭이네요!' 라고 피드백 하신 부분이 계속 생각났습니다. 김버그님의 오늘의집 클론코딩 수업을 듣고싶어서 그랬을까요 ㅎ..? 들어보신 분 있다면 의견 부탁드립니다.

타입스크립트

오늘 프로젝트를 다시 점검해보는데, //@ts-ignore 를 13번이나 사용한 흔적이 보였습니다. 이러려면 타입스크립트를 왜 사용한 건지 싶더군요,, 확장자는 모두 .tsx 를 썼지만 정작 타입스크립트를 제대로 사용하지 못했습니다. 파라미터나 props 의 타입은 잘 지정했지만, 딱 그정도로밖에 타입스크립트를 사용하지 못한 것 같아 아쉽습니다.
그럼에도 다음 프로젝트에서 타입스크립트를 사용할 것이냐 묻는다면 '무.적.권'입니다. 얄팍하게 사용하긴 했지만, 뒷단의 nestjs 와 데이터를 주고받을 때 데이터 타입이 명시돼 있다는 사실이 주는 안정감은 이루 말할 수 없었습니다. 무엇보다 유지보수(할 필요는 없는 프로젝트지만) 를 할 때 간혹 내가 짠 코드가 어떤 의미인지 오락가락 할 때가 있는데, 이럴때 데이터 타입이라도 명시돼 있다면 코드의 의미를 이해하는데 한층 수월한 걸 알기에, 일말의 여지 없이 저는 타입스크립트를 다시 사용할 것 입니다 (이제 더 제대로 된 개념을 곁들인).

13번의 @ts-ignore..

 

Back-end

회사에서 사용하는 스택이 Nestjs 인 점과, 실제로 작은 프로젝트에서 빠르게 서버를 구축할 수 있다는 점에서 nestjs 를 백엔드 프레임워크로 정했습니다. 언어는 당연히 타입스크립트로 하였습니다.

회사에서는 DB 테이블을 nestjs의 엔티티로 매핑하는 방법을 사용하고 있습니다.
화살표로 표현하자면 (DB Table => table.entity.ts in Nestjs) 입니다. 이유는 테이블의 컬럼 갯수가 기본적으로 30개를 넘어가기 때문에, 이를 일일이 코드화 하는 것 보다는 테이블을 매핑하여 엔티티화 하는 과정이 낫다고 생각하기 때문입니다. orm 은 typeorm을 사용중이었기에 typeorm-model-generator 로 테이블 엔티티를 nestjs 로 매핑했는데, 본 프로젝트에서는 다뤄야할 컬럼이 5개밖에 되지 않았습니다. 때문에 엔티티를 직접 타이핑하여 DB에 마이그레이션 하는 방법을 택했습니다.

테스트 결과 도출 과정

아래의 로직 중 1~3번은 원래 백엔드에서 담당하였지만, 결국 프론트로 로직을 빼냈습니다. 아래 절차를 보면서 이유을 설명드리겠습니다.

1) 심리테스트에서 12개의 문항은 각각 mbti 의 성향을 판별할 수 있는 질문으로 구성돼있다.
ex. 1번 문제의 보기 : e 유형의 답변, i 유형의 답변. 2번 문제의 보기: n 유형의 답변, s 유형의 답변 ...

2) 12개의 결과를 하나의 객체로 종합하여, 어떤 유형에 더 가까운지(N vs S, E vs I ...) 찾아낸다.

3) 결과로 나온 유형(ex ENFP)에 따라 파라미터 id 를 출력하기 위해 switch ~ case 문을 사용했다.

4) switch ~ case 를 거쳐 도출한 id 를 백엔드 API 의 파라미터로 넘기며 GET 호출한다.

-------------------------------- 위 까지 Front 단 작업 --------------------------------

5) 프론트에서 넘어온 id 값을 매개로 typeorm 에서 findOne() 메서드로 DB 조회한다.

6) 파라미터에 대한 조회값을 다시 front로 Response 한다.

처음에는 12개의 결과 객체 자체를 백엔드로 보냈습니다.
백엔드에서 받게되는 것은 당연히 12개의 답변으로 구성된 배열이었고, 이 배열을 계산하여 사용자에 맞는 성향을 도출하는 로직이었습니다. 뭔가 깔끔하지 않다는 생각했습니다. 백엔드에서 DB 를 조회할 때는 결과에 맞는 id 값(1~11 에 해당) 만 있으면 충분했습니다. 즉 프론트 단에서 12개의 원소로 이루어진 배열을 미리 계산하여, 결과 인물의 id 값만 백엔드에 보내면 되지 않을까 라고 생각했습니다.

실제 코드로 보면,
1. 프론트의 요청을 컨트롤러에서 받는다. 이때 id 값은 결과 인물이 갖는 고유한 id 값으로 결과 테이블을 조회할 때 사용된다.

// hospital.controller.ts

@Controller('/result')
export class HospitalController {

  constructor(private readonly hospitalService: HospitalService) {}

  @Get(":id")
  @UsePipes(ParseIntPipe)
  getResult(@Param("id") id) {
    return this.hospitalService.getResult(id);
  }
}

2. 컨트롤러는 service layer 를 호출해 id 값을 resultId 란 매개변수로 넘깁니다.

// hospital.service.ts

@Injectable()
export class HospitalService {
  constructor(
    @InjectRepository(HospitalEntity)
    private hospitalRepository: Repository<HospitalEntity>
  ) {
  }

  async getResult(resultId) {

    const resultData = await this.hospitalRepository.findOne(resultId);

    if (resultData) {
      return {
        "resultCode": 200,
        "resultData": resultData,
        "resultMsg": "success"
      };
    } else {
      throw new NotFoundException("not found");
    }
  }
}

resultId 는 곧바로 typeorm 의 findOne() 메서드의 인자가 되어, 테이블에서 조회할 값을 찾을 수 있습니다.

즉 하나의 값 (id) 만 백엔드로 넘기느냐, 12개의 원소로 이루어진 객체를 넘기냐의 차이였습니다.
처음에는 후자를 선택해 로직을 짰지만, 다시 생각했을 땐 전자가 훨씬 깔끔하고 직관적이란 생각하여 위와 같은 코드로 리팩토링 하였습니다.

마치며

다 쓰고 나니 망한 프로젝트를 회고하는 느낌이네요. 무언갈 계속 반성하고, 고치려하고,, 🥲
생각해보면 제가 프로그래밍을 배운 이후 처음부터 끝까지, 제 손길이 닿지 않은 곳이 없는 코드를 개발한 프로젝트였습니다. 무엇보다 중간에 포기하지 않고 어떻게든 마무리했다는 점에서는 만족스럽습니다. 다만 개발자답게, 좋은 코드와 로직, 설계적인 부분에서는 빈틈 투성이라는 것도 여실히 느낀 프로젝트였습니다. 스읍... 트래픽도 잘 안나와서 아쉽지만.. ㅋㅋㅋㅋㅋㅋㅋ 어쩌겠습니까 딛고 일어나야겠죠? 1년뒤에 이 포스팅을 다시봤을 땐, 풉 나 완전 초짜였네 ㅋㅋㅋ 이럴수 있길 바라겠습니다 :) 긴글 읽어주셔서 감사합니다.

마무리는 99즈 :)) 시즌3 존버

---

스스로 생각해봐야 할 점
1. 왜 typeorm 을 사용했는지. prisma 같은 다른 orm 은 왜 고려하지 않았는지.
2. DTO, DAO 개념을 충분히 숙지하고 사용하려했는지 (아니요..)
3. 애초에 DB 를 붙이 필요가 있었는지, front 단에서 결과를 준비해두고 렌더링하면 되는건 아니었는지.

보완해야 할 점
1. API 호출 문서화
2. nestjs 에서 테스트 코드 작성 시도해볼 것
3. @ts-ignore 를 점진적으로 제거해보자.
4. 깃헙 코드 공개 ㅠ