(Project) Cherground

위코드에서의 마지막 한 달은 실제 프로젝트를 진행하고 있는 기업에 투입되어 실무자 분들과 함께 협업을 진행하는 한 달이다. 멘탈이 흔들렸던 한 달을 회고해보자..

협업을 시작하기까지..

• 위코드의 기업 협업은 우리의 대장 은우님께서 협업 희망 기업들을 하나하나 컨택하시고, 그 중에서도 우리에게 도움이 될만한 기업들을 멘토님들 간의 회의를 통해 추려내신다.

  • 그 추려낸 기업들의 리스트를 우리에게 공개해주시고, 어디로 갈지는 순수하게 우리가 정하는 것이다.

• 10개 정도의 기업들 중에서 나는 동대문에서 패션업을 수행하고 있는 기업들을 대상으로 사입, 정산 대행 등을 수행하는 쉐어그라운드에서 기업 협업을 진행하기로 마음먹었다.

  • 쉐어그라운드에서는 자사 플랫폼 가입자들의 주문 의뢰 페이지를 만들고자 하였고, 기술 스택으로는 Node.js, Express, Typescript, DynamoDB, Serverless를 활용하고 있었다.

  • 이에 더해 Clean Architecture, 객체지향프로그래밍에 대한 기술 세미나도 함께 진행해야 했다.

• 사실 처음부터 쉐어그라운드에서 기업협업을 진행하고자 마음먹지는 않았다. Python/Django 기반으로 기술 스택을 쌓아온 나로써는 이를 활용하는 기업에서의 협업을 통해 기반을 더욱 다지고 싶은 것이 우선순위였으나,

  • 그 생각이 바뀌었다. 새로운 기술스택들은 어떻게 코드를 짜야하는 지 궁금했고, 조금은 들떴다.

    • Node.js/Express는 Python/Django와 많이 다른지
    • Typescript가 뜨고있다던데 어떻게 사용하는건지
    • NoSQL은 뭐가 다른건지
    • Serverless는 서버가 없이 배포를 한다는 건가?

  • 지금까지 배워온 기술 스택들과는 거의 정반대의 스택들이다보니 적응하기 쉽지 않으리라는 생각과 함께 어차피 인생은 공부의 연속이라는 나의 모토가 머릿속에서 공존하고 있었다.

생각보다 힘들었던 새로운 스택에 대한 적응

• 쉐어그라운드로의 협업이 정해지고, 예리님 및 다른 멘토님들께서는 '제2의 부트캠프'라며 정말 잘 선택했다고 말씀해주셨다.

  • 그 말씀이 정확했다. 쉐어그라운드에는 실력과 위트, 리더쉽을 갖추신 CTO님과 우리가 하나라도 더 배워갔으면 하는 마음에서 바쁘신 중에도 시간을 투자해 성심성의껏 알려주셨던 위코드 출신의 사수분들이 계셨다.

• 우리가 한달 간 수행해야 할 프로젝트는 쉐어그라운드에서 개발 중인 플랫폼의 회원가입/로그인 및 주문의뢰서를 접수하는 페이지의 구현이었다.

  • 백엔드 사수님과의 첫 날에는 초기세팅을 진행했다. App-Controller-Service-DB로 이어지는 MVC패턴을 적용하기 위해 디렉토리를 생성했다.

    • 의존성 주입을 위한 Interface와 실제 내가 구현할 Impl 파일의 구분, DTO-VO-DAO와 같이 데이터베이스를 구분하는 용어 등은 어리둥절의 연속이었다.

  • 자바스크립트 개념의 시작도 모르는 나에게 있어 Node.js는 처음부터 난관이었다. 프로젝트를 수행하면서 때마다 자바스크립트를 공부하면 되겠지라는 안일한 생각을 한 나를 자책했다.

  • DynamoDB 또한 생소함의 극치였다. AWS의 NoSQL 기반인 DynamoDB는 JSON과 비스무리하게 생긴 파라미터를 통해 CRUD를 진행해야 했다.

• 새로운 기술 스택을 받아들인다는 것이 쉬운 일은 아니라는 것을 깨닫게 되었지만 내가 선택한 길이었기에 후회는 없었다.

프로젝트

• 이러한 상황에 놓여있다니 나와 같은 처지에 있던 백엔드 동료 분과 머리를 싸매고 프로젝트의 모든 기능을 함께 만들어나가야했다.

• 일단 자바스크립트에 익숙한 프론트엔드 동료 분의 추천을 받아 코드카데미부터 공부를 시작했다.

  • 사수분께서 데이터 전송의 빠른 처리를 위해서 VO의 데이터를 가져오는 과정을 Promise 객체를 통해 비동기처리하여 코드를 진행해야해준다고 말씀해주셨다. 과거 프로젝트에서는 비동기라는 개념이 없었기 때문에 그 개념부터 받아들이고 활용하는 데 초반에 애를 많이 먹었다.

  • 코드카데미 수강을 통해 궁금했던 Arrow Function의 활용법을 배워 적용할 수 있게 되었고, Promise도 같이 적용할 수 있었다.

• 그러나 문제는 우리는 Typescript를 해야한다는 점이었다. 타입을 정의함으로써 프론트엔드와 백엔드 개발자 간의 소통을 더욱 원활히 할 수 있다는 장점이 있었지만, 객체 자체를 타입으로 지정해서 Promise객체로 서로 다른 레이어에 연결까지 해야한다는 사실을 이해하는 데 꽤 많은 시간이 걸렸다.

• 그렇게 코딩을 진행하면서, Django의 편의성과 주의점을 한 번에 깨닫게 되었다.

  1. Dao에서 Method를 생성하면서 Django ORM의 편리성을 알게 된 점
  2. Django는 Startapp 명령어를 입력하면 디렉토리가 생성되었지만 Node는 내가 하나하나 만들어 나가야한다는 점

• 이런 부분에서 왜 위코드에서 백엔드 기술 스택으로 Django를 택하고 있는지, 왜 Django가 빠른 개발을 필요로 할 때 사용이 되고 있는지, 프레임워크에 의존을 하게 되면 Node나 Flask와 같은 런타임 혹은 프레임워크에 적응하기는 상당히 힘들어 질 것이라는 느낌을 한꺼번에 받았다.

• 결국 우리는 막히는 부분이 생길 때마다 사수분께 여쭤보고 코드를 고쳐나가는 방식을 통해 로직이 100% 완벽하지는 않았지만 기본적인 로그인/회원가입, 주문 의뢰를 구현해냈고, 이를 Serverless로 배포했다.

  • 처음 써보는 Serverless의 느낌은 정말 간편하다. 서버를 Call할 때만 구동되니 비용적인 문제도 걱정할 필요가 없겠구나 였다.

  • AWS, DOCKER로 배포를 진행할 때는 AWS는 리전에 EC2, RDS를 생성하는 절차를 거쳐야했고, DOCKER 역시 Container, Image 생성 등의 절차를 거쳐야했으나, Serverless는 yml 파일 생성 후 터미널에 sls deploy만 입력하면 끝이라는 것이 인상적이었다.

기술 세미나

• 협업 2주차와 3주차에 진행했던 기술세미나 역시 힘들었지만 보람찼던 추억으로 남아있다. 특히 클린아키텍처와 디자인패턴과 관련된 세미나를 준비할 때는 위워크에서 새벽 6시까지 자료를 만들고 1시간 취침 후에 다시 회사로 나갔었고, 객체지향프로그래밍 역시 자정까지 준비하고 귀가를 했었다.

• 클린아키텍처와 디자인패턴

  • 위코드에서 처음 장고를 시작할 때 장고는 MTV라는 디자인 패턴이라는 것을 알고 시작했지만, 백엔드에서는 Template을 다루지 않았기 때문에 디자인 패턴을 인식하기가 힘들었다.
  • 그러나, 협업을 시작할 때 파일의 디렉토리 구조를 먼저 만들고 클린아키텍처 기술 세미나를 진행하면서 실무에서는 비즈니스 로직 등을 고려하고 디자인 패턴을 접목하여 업무를 진행한다는 것에 대해 인식하게 된 계기였다.

• 객체지향프로그래밍

  • 파이썬 역시 객체지향 프로그래밍을 선호한다는 얘기는 들어왔었고, 클래스가 그 중심에 있다는 얘기 역시 들어왔으나, 그 얘기가 정확히 어떤 의미인지는 파악하기 힘들었다.

  • 비록 정말 겉핥기 정도의 조사를 통한 발표였지만, 추상화, 캡슐화, 다형성의 의미가 무엇인지 알 수 있었던 세미나였다.

후기

1. 아직 갈 길이 멀다는 점

   • 너무도 많이 바뀐 기술 스택으로 갈피를 잡지 못했다. 협업이 끝난 시점에서도 이 기술들이 어떻게 활용되었는 지 명확하게 파악되지 못한 부분들이 많은 것이 사실이다.

   • 이 또한 나의 부족한 부분들이고 향후 개발자로써의 커리어를 쌓아가면서 보완하다보면 "이 땐 이 정도 레벨도 어려워했구나?" 라며 과거의 내 자신을 흐뭇하게 바라볼 날이 오지 않을까 생각한다.

   • 정말 첫 주차에는 너무 헤맨 나머지 거의 손도 대지 못한 날들이 있었다. 그러다 보니 스스로 초라하다고 느끼는 날들이 자주 있었다.

   • 분명, 앞으로 이런 날들이 수두룩할 것이라 생각한다. 미리 경험해서 다행이다.

5. 기록하고 싶은 코드 / 함수 / 로직

파일 디렉토리 구조

• 전형적인 MVC 형태의 파일 디렉토리 구조

• App -> Controller -> Service -> DB로 흘러가는 구조를 항상 명심하고 있어야겠다.

├── api
│   ├── app
│   │   └── app.ts
│   ├── controller
│   │   ├── RequestController.ts
│   │   ├── UserController.ts
│   │   └── implement
│   │       ├── RequestControllerImpl.ts
│   │       └── UserControllerImpl.ts
│   └── dto
│       ├── Request.ts
│       └── User.ts
├── index.ts
├── injector.ts
├── mapper
│   ├── BaseMapper.ts
│   ├── RequestMapper.ts
│   ├── UserMapper.ts
│   └── implement
│       ├── RequestMapperImpl.ts
│       └── UserMapperImpl.ts
├── repository
│   ├── dao
│   │   ├── RequestDao.ts
│   │   ├── UserDao.ts
│   │   └── implement
│   │       ├── RequestDaoImpl.ts
│   │       └── UserDaoImpl.ts
│   └── vo
│       ├── RequestVo.ts
│       └── UserVo.ts
└── service
    ├── RequestService.ts
    ├── UserService.ts
    └── implement
        ├── RequestServiceImpl.ts
        └── UserServiceImpl.ts

의존성 주입

• 현재 어떤 계층의 코드는 다른 계층의 코드를 굳이 상세하게 알 필요 없이 어떤 구조로 형성 되어있는지 외관만 알고 있어도 충분하다.

• 이를 위한게 인터페이스이고, Container 기능을 통해 인터페이스(Impl)에 실제 코드를 주입함으로써 자연스럽게 인식할 수 있도록 유도한다.

const container: Container = new Container();

container.bind<UserController>("UserController").to(UserControllerImpl);
container.bind<UserService>("UserService").to(UserServiceImpl);	
container.bind<UserDao>("UserDao").to(UserDaoImpl);
container.bind<UserMapper>("UserMapper").to(UserMapperImpl);
container.bind<RequestController>("RequestController").to(RequestControllerImpl);
container.bind<RequestService>("RequestService").to(RequestServiceImpl);
container.bind<RequestMapper>("RequestMapper").to(RequestMapperImpl);
container.bind<RequestDao>("RequestDao").to(RequestDaoImpl);

export default container;