[프로그래머스]최종 프로젝트 1주차

앞으로 최종 프로젝트를 진행하면서 겪었던 일들을 기록하고자 한다

주제 선정 - InGame

"만약 인생이 게임처럼 내 성장을 수치로 확인할 수 있다면 어떨까?" 라는 생각을 오랫동안 해왔다. 이러한 주제에 대해서 팀원들에게 제안했을 때, 팀원 모두 흥미를 느꼈고, 긍정적인 반응을 보여주었다. 그래서 위와 같은 주제로 함께 프로젝트를 진행하게 되었다.

데이터베이스 설계

프로젝트의 데이터베이스 설계를 진행하게되었다. 퀘스트를 어떻게 생성하고 관리할지에 대한 의견이 갈리게되었는데, 1안은 하나의 큰 테이블에서 메인 퀘스트, 서브 퀘스트, 하위 퀘스트를 모두 관리하는 것이었다. 이렇게 하면 subsidiary라는 별도의 테이블을 통해 메인 퀘스트와 관련된 하위 퀘스트를 연결할 수 있었다.

그러나 내 생각으로는 하위 퀘스트는 메인 퀘스트에 종속되어 있는 퀘스트인데, 굳이 하나의 퀘스트 테이블에서 생성할 필요가 있을까?였다

위와 같은 상황들이 구두로만 전달되는 상황이다보니, 내가 생각한 부분을 정확히 설명하지 못해 아쉬웠다.

그래서 두 번째 회의에서 위 그림처럼 이미지화하여 각각의 테이블 설계에 대한 장단점을 설명드렸고, 메인 퀘스트에 종속된 하위 퀘스트를 별도의 테이블로 관리하는 구조로 결정하게 되었다.

위의 경험을 토대로 앞으로 다른 사람에게 설명하기 위해서는 말보다는 이미지로 설명드리는게 훨씬 이해하기 쉽다는 것을 깨닫게 되었다. 그래서 앞으로 다이어그램에 대해서도 학습해볼 생각이다.

NestJS 선택 및 환경설정

우리 팀은 이번 프로젝트에서 백엔드 서버를 구축하기 위해 NestJS 프레임워크를 선택했다. 이전에 사용해봤던 Express 프레임워크는 애플리케이션을 자유롭게 설계할 수 있는 장점이 있지만, 체계적인 구조가 부족하다고 판단했기 떄문에, 우리 프로젝트에서는 NestJS 프레임워크가 더 적합하다고 생각했다.

그 후, NestJS 프레임워크의 백엔드 서버를 구축하기 위해서 초기 환경 설정을 진행했는데, 이전 프로젝트에서 경험해을 토대로, 초반에 개발 환경과 배포 환경을 분리해서 환경설정을 구축하는게 편하다는 것을 깨달았다.

동적으로 환경설정

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { TypeOrmModule } from '@nestjs/typeorm';
import { typeORMConfig } from './config/typeorm.config';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      cache: true,
      envFilePath: process.env.NODE_ENV === 'production' ? '.production.env' : '.development.env',
    })
  ],
})
export class AppModule {}

위 코드처럼 NODE_ENV 값을 development와 production으로 설정하여, 환경에 맞는 변수 파일을 자동으로 불러오도록 구성했다.

이로인해 앞으로는 개발 환경과 배포 환경에 필요한 환경 변수 파일을 별도로 작성해두기만 하면, 개발 환경과 배포 환경에 따라 소스 코드를 수정할 필요가 없을 것 같다.

마무리

말로만 다른 사람들을 설득하는 과정이 쉽지 않다는 것을 다시 한번 깨닫게되었다. 의견이 다른 상황에서 어떻게하면 상대방이 기분 상하지 않게, 그리고 설득력 있게 말할 수 있을지 고민하게 되는 시간이었다.

그래도 이번 경험을 통해 말만으로 설득하는 것보다 이미지와 같은 시각적 도구를 함께 사용하는 것이 훨씬 더 설득력을 높일 수 있다는 것을 배우게되었다.