원티드 X 위코드 프리온보딩을 끝내고

김남형·2021년 12월 6일
0

원티드 X 위코드 프리온보딩을 끝내고

저는 프리온보딩을 Javascript -> NestJS로 수행했습니다. 처음 보는 팀원들과 함께 호흡을 맞춰 진행하는 프리온보딩이 참 재밌었습니다.
그렇지만 다른 팀원분들도 동의한 딱 한가지 아쉬운 점이 있었습니다. 저희는 파이썬으로 주어진 과제를 수행 할 수 없었던 것입니다.
자바스크립트로 파이썬 과제를 수행 할 수 있었으면 좋았겠지만 파이썬으로 구현되어야 했기에 어쩔 수 없었습니다.
프리 온보딩을 진행하면서 불필요하게 반복되는 것이 시간이 아깝다고 생각했습니다. 과제를 구현함에 있어 유저 인증은 대부분 필수사항이었습니다.
그래서 저는 유저인증 보일러플레이트를 만들고 팀원들에게 제안하여 사용했습니다. 그렇게 요구사항에 집중 할 수 있는 발판을 만들 수 있었습니다.
그럼에도 불구하고 아쉬웠던 점은 배포를 자동화하지 못했던 것입니다. 처음 접근은 로컬에서 완성하고 배포하면 될것이라고 예상했습니다.
예상과 달리 배포 이후에 수정 해야 하는 상황이 생겼고 그에 따라 배포가 은근히 시간을 소모했습니다.

결국 저는 프리온보딩의 아쉬움을 달래기 위해 두가지를 혼자 스스로 해보기로 했습니다.

  • 배포 자동화
  • 파이썬 사용해 과제 구현하기

AWS EC2, Jenkins, Docker 배포 자동화

저는 두대의 젠킨스, 배포를 담당하는 두대의 EC2를 사용해 배포를 자동화했습니다.
그림이 간단하지 처음으로 접하는 젠킨스는 가혹했습니다. 그루비 문법을 몰라 스크립트를 작성하면서 수많은 오류를 겪었습니다.

원티드 과제를 수행하기 위해 배포 테스트를 94번이나 진행하게 된 것입니다. 스테이지 하나하나 지나가면서 제대로 되는지 다음 스텝으로 넘어
가기도 했지만 도커를 사용하다가 연결이 제대로 안되는 경우 명령어 스크립트가 잘되는 경우 등.... 여러 사례를 만났기에 그래도 다행히!
100번은 넘기지 않고 배포 자동화를 마무리 할 수 있었습니다.

요구사항

  1. 다국어를 지원하고 ko, en, ja 세가지의 다국어 셋을 지원한다.

첫번째 요구사항과 데이터 셋을 보았을 땐 아래와 같이 하나의 테이블에로 구성하려고 생각했습니다.

class Company:
	company_ko: str
	company_en: str
	company_ja: str

class Tag:
	tag_ko: str
	tag_en: str
	tag_ja: str

왜냐하면 하나의 테이블을 사용하면 저장과 검색이 용이 할 것이라고 판단했습니다.

  1. 테스트 케이스에서 새로운 언어 tw도 추가 해야 한다.

주어진 테스트에선 동적으로 새로운 언어가 추가 되는 것을 파악 할 수 있었습니다.

내가 고려한 사항

  • 코드에서 직접 문자열 현지화
  • 관계형 데이터베이스에 저장

코드에서 직접 문자열 현지화

만약 데이터 셋에서 주어진 다국어만 지원 한다면 변수에 값을 할당하는 조건문 또는 딕셔너리를 사용해 코드에서 직접 처리하도록 한다. 하지만 변경 사항의 적용 및 기존 코드를 추적하기 어렵습니다. 또한 동적으로 추가되는 언어에 대응 할 수 없습니다.

관계형 데이터베이스에 저장

  1. 가장 단순한 구현은 지원되는 언어만큼 칼럼을 추가한다.
  2. JSON 타입의 칼럼으로 저장한다.
  3. 언어의 칼럼을 추가하는 대신 별도의 테이블을 추가한다.

첫번째 방법은 동적으로 생성되는 언어에 대응 할 수 없기때문에 배제했습니다.
두번째 방법은 데이터를 JSON으로 저장 할 수 있지만 데이터 뿐만 아니라 칼럼 정보 구분자등으로 불필요한 사이즈가 늘어나기 때문에 배제하기로 했습니다.
세번째 방법은 로케일이라는 테이블을 별도로 두어 로케일이 추가 될 때 데이터베이스 구조를 변경하지 않고 동적으로 추가 할 수 있기 때문에 3번째 방법을 사용하여 구현하기로 했습니다.

구현 과정에서 태그_현지화를 만들기 이전에 태그를 식별 할 수 있었어야 했기에 tag에 name필드가 추가되어 같은 태그라면 중복으로 생성되지 않도록 했습니다.

결과

스웨거 접속 URL 배포, 테스트를 위한 URL 입니다.

회사명에 쿼리가 포함되어 있다면

이 부분을 구현하는데 약간 문제가 있었습니다 SQL의 LIKE를 사용하려고 했는데 제가 사용한 SQLMODEL이란것에선 LIKE를 찾지 못했습니다.
아마도 제가 제대로 접근하지 못했던 것이라고 생각하는데 구현을 위해 일단 로케일 기준으로 회사를 모두 조회하고 애플리케이션내에서 문자열을 포함하는지 확인하여 결과값을 출력했습니다.

회사명으로 검색하기

회사명으로 검색하는 조건 중 언어설정이 저장되어 있지 않으면 오류 처리하였습니다.

새로운 회사 추가하기

새로운 회사를 추가하는 부분이 스키마를 정하는데 가장 중요한 역할을 했습니다. 새로운 언어가 동적으로 추가 되어야 해서 테이블의 칼럼으로 처리 할 수 없었기 때문입니다. 현재 이부분에서 회사 네임이 중복으로 들어가지 않도록 에러처리 했습니다. 만약에 회사 이름도 중복으로 가능하다면
회사에 UUID와 같은 식별자를 추가 해야하는 설계가 필요할것으로 파악됩니다.

주어진 E2E 테스트 통과

FastAPI를 사용해 테스트 환경을 조금 바꾸느냐고 처음에 고생했다. 처음에 그대로 사용해야 해야 하는것인지 의문이 들어 조금 시간을 지체했지만 FastAPI Docs를 보고 수정해 테스트를 완료 했습니다.

profile
제빵사에서 개발자되기

0개의 댓글