cozlin project 기획 및 시작

이동명·2023년 5월 25일

Cozlin Project

프로젝트 기획

[문제 발견 및 리서치]

프론트엔드 파트로 근무하던 직장에서 퇴사를 한 뒤 이직을 하는 과정에서 면접을 다니다가 문뜩 떠오른 생각들이 있다.

면접은 여러가지 조건으로 인해 상대도 나도 둘 다 만족을 할 수있는 상황이 자주 나오진 않는 는다. 항상 회사측에서 원하는 스펙을 가진 사람만 지원하는 것도 아니며 설령 그렇다 해도 협상 결렬(?) 이 될 시 서로의 시간이 아깝다 라는 건 누구나 알고 있을 것 이다.
또한 구직자 입장에서 어느정도 자리를 잡은 3년차 이상 혹은 다양한 경험이 있는 누군가 라면 구직이 뭐 어렵겠어? 라는 입장일 수 있지만 나처럼 1년정도 밖에 경험을 하지 못한 입장 에서는 구직활동이 순탄치 않은 건 사실이다.
또한 구인하는 측 에서도 유니콘 기업이야 입사지원 이력서가 쏟아 지겠지만 그에 비해 조금 작은 스타트업이나 중소기업에서 입맛에 맞는 지원자를 찾는 것 또한 쉽지 않은 과정 이다.

그렇다면 ? 그 간극을 좁혀 줄 수 있는 무언가를 만들 수 없을까 ?

기업 의 시야 에서 시각화된 데이터로 잘 짜여진 UI로 현재 구직중인 개발자들의 조건을 보며 직접 컨택할 수 있는 플랫폼을 만들면 어떨까 싶었다.
개인 의 시야 에서는.. 외람된 이야기 지만 회사 및 학원 등 개발을 하고 있는 인맥들은 본인이 만든 프로젝트 및 본인의 스펙 등을 자랑하는걸 굉장히 좋아하는 사람이 많았다. 따라서 본인의 스펙혹은 경험 경력 들을 꾸밀 수 있는 소셜 네트워크를 만들며 활동과 동시에 구직등록을 하여 나를 원하는 회사의 컨택을 받아 볼 수 있는 서비스를 기획 하고 싶었다.

[서비스 구상 및 아이디어 수집]

메인 아이디어 기획 : 기업은 필요한 개발자&프리랜서 를 시각화된 데이터로 직접 컨택할 수 있고, 개발자는 구직에 큰 시간을 할애하지 않고 항시 오퍼를 받을 수 있는 중개 플랫폼
개발자 본인의 각종 스펙과 경력을 자랑할 수 있는 소셜 네트워크
개발자가 아니더라도 각종 업종에 대한 확장성은 열려있다.

[메인 서비스 및 요구사항 정의]

기업

구직 공개 등록 된 개발자들의 정보를 한눈에 볼 수 있어야 함.
구직 공개 등록 된 개발자들의 정보를 필터링 할 수 있는 기능이 있어야 함.
원하는 개발자 들을 팔로잉 또는 관심등록 할 수 있어야 함.
원하는 개발자와의 컨택을 할 수 있어야 함 (개인 메시지 및 알람)

개인

내 프로필을 시각화 할 수 있어야 함. (경력 및 스택 등)
기본적인 SNS 에서 활용할 수 있는 기능들은 사용되어야 함 (좋아요, 팔로우, DM 등등..)
타 개발자들의 정보를 한 눈에 볼 수 있어야 함

[개발 기술 기획]

FRONT

Main Stack
- React 18
- Redux
- Redux Tool kit

CSR 과 React 를 선택한 이유

네이티브 앱과 비슷한 빠른 인터렉션을 구현하고 싶었음.
View 렌더링을 브라우저에게 담당시킴으로서 서버의 트래픽을 줄이고 싶었음. (프리티어 db 리소스를 아끼고싶었음)
근무 했을 때 Vue.js 를 주로 써봤기 때문에 React 쪽을 선택하고 싶었고 React 쪽 생태계도 조금 더 자세하게 궁금 하였음.
Next 의 파일 기반 라우팅과 Static Side Generation 또한 간단하게 서버를 같이 둠으로써 풀스택을 구현할 수 있는 장점이 많지만 우리 프로젝트의 경우 React 를 처음 접하는 팀원이 있었고 회의를 거쳐 모두의 니즈를 가져가는 쪽으로 가기로 하였음.
또한 Next 에서 백엔드를 두고 Nosql 기반 DB에 접근해서 붙고 싶다기 보다는 Spring 진영에서 해보고싶은게 많았음.

TypeScript 를 채택하지 않은 이유

타입스크립트는 근무 할 당시 외주 프로젝트 (Next.js + TypeScript) 로 경험을 한번 해보았고 훌륭한 기능들을 가지고 있다.
하지만 이번 프로젝트 에선 React 가 처음인 프론트 담당 팀원의 모든 집중력이 React 생태계쪽으로 가는걸 원하였고 혼자 배워가면서 하는것보단 일단 빼고 하는게 낫다고 판단 하였다.
또한 이번 프로젝트가 어느정도 완성되고 중간지점 까지 왔을 때 JS -> TS 로 마이그레이션 하는 경험을 꼭 살려보고 싶었기 때문이다.

Styling
- CSS in Javascript (Module)
- Image - CDN

CSS in JS 를 선택한 이유

스타일시트의 묶음을 유지보수 할 자원을 할당하고 싶지 않았다.
복잡한 애플리케이션 내에서 선택자 충돌을 피할 수 없는 경우가 있고 BEM과 같은 네이밍 컨벤션은 한 프로젝트 내에서는 도움이 되지만, 서드파티 코드를 통합할 때는 도움이 되지 않는다. 따라서 CSS를 컴파일 할 때, 기본적으로 고유한 이름을 생성 하는 방식을 채택 하였다.
흔히 사용하는 Sass 는 근무할 당시 많이 사용해보았고 파일이 늘어날수록 문어다발식 import 가 되다보면 관리도 쉽지않고 빌드 시간도 비약적으로 늘어날 뿐더러 애초에 관리를 해야된다는 리소스 자체가 부담 이었다.

CI / CD
- env -> dev & prod (준비중)
- Github Action

Github Action 을 채택한 이유

근무할 당시엔 sh로 짜여진 코드로 배포 자동화를 하였는데 이번 프로젝트에서 꼭 적용해보고 싶었던 Github Action 으로 CI / CD 파이프라인을 구축하기로 채택 하였다.

원하는 IT 인재 채용 플랫폼 cozlin.com / fe - Github

Server

Main Stack
- Spring boot 2.7.12
- Spring Security
- Jwt
- Maven
- JPA

Main Stack 사용 이유

Spring boot 와 JPA 의 사용은 이번 프로젝트의 가장 큰 이유이기도 하다. 단순 강의나 혼자 개념을 공부하는 것도 좋지만 공부한 걸 적용하고 내 지식으로 만들만한 내 프로젝트가 필요했다.
Maven 을 사용한 이유는 솔직히 Gradle 써보지 않아서 시작했다. 이번에 공부를 시작했기 때문에 처음 공부할 때 시작한 Maven을 채택 하였다.
JPA 를 채택한 이유는 공부할 땐 Mybatis Mapper 파일로 쿼리를 직접 작성하여 사용하였지만 ORM에 대해 궁금하기도 하였고 JPA 에서 제공하는 기본 메소드의 사용으로 영속성 컨텍스트에서 캐싱처리를 하여 DB를 직접 찌르지 않는 (DB 트래픽을 줄일 수 있는) 방법을 기대하고자 사용 하였다. 또한 같은 취지와 목적으로 Redis 를 사용할 마음도 있다.
또한 혼자 Spring Security 와 Jwt 를 혼자 공부하면서 프로젝트에 적용해보고 싶었는데 좋은 기회 인 것 같아서 꼭 적용해보고 액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token) 방식 중 90분짜리 액세스 토큰을 적용해보고 리프레시 토큰에 대해서도 차차 공부를 해보려고 한다.

Network & DB
- Oracle Cloud
- Ubuntu 22.04
- Oracle Cloud ATP - DB

Network & DB 사용이유

초기 AWS 를 사용하려 했었지만 모든게 처음이고 무지한 탓에 원격 접속 포트 22번을 열어놓았더니 이틀만에 프리티어 요금제가 끝나 버렸고.. 잘 모르고 사용하다 과금이 청구되는 불상사를 원하지 않아서 오라클 클라우드 프리티어 요금제를 선택하게 되었다.
오라클 클라우드 프리티어는 내가 직접 요금제를 업그레이드 하지 않는 한 절대 요금이 청구되지 않을 뿐더러 해당자원 내 사용은 평생무료 라는 엄청난 장점과 스펙도 매우 좋다.
DB도 오라클의 자율운영 트랜잭션 DB를 사용하였다. 물론 Mysql 직접 장비에 설치한 후 띄우는 방법도 있었겠지만 해당 자원 (메모리 등)이 프리티어임을 고려했을땐 효율적인 방법은 아닌 것 같았다.