Beoum

Beoum

열심히보다는 잘하는 사람이 되고 싶습니다.

신입개발자의 세번째 프로젝트 후기

12 minute read

다시 또 시간은 흘러 세번째 프로젝트도 마무리가 되었다.

한참 더운 여름에 땀을 흘리면서 면접을 봤던것 같은데 어느새 겨울이 지나고 따뜻한 봄이 오고 있다.

누구에게나 봄은 온다고 생각한다.

설령 그게 아니더라고 하더라도, 나는 그렇게 생각하고싶다.

앞으로의 삶에서 봄이 영영 없다고 한다면 그것처럼 비참한건 없을 테니까.

인생의 봄을 스스로 맞이해보려고 노력은 하는데 방향이 잘못된것인지,

가까이 오고는 있는건지 스스로에게 의문이 들때가 많다.

그래도 언젠간 봄이 오겠지. 봄이 늦게 온다면 얼마나 좋은 봄이 오려고 하는것인지 내심 기대가 된다.

물론 지금도 충분히 좋지만 완전한 봄은 아닌것 같다!


세번째 프로젝트 주저리 주저리 시작 합니다.

이슈

1. 유지보수

기존 프로젝트가 쌓이다보니. 신규 프로젝트를 진행하면서도 기존 프로젝트의 유지보수를 할 일 또한 많아졌다.

유지보수를 한다는 것 자체가 어렵거나 힘들지는 않지만, 뭐랄까…

스위치가 딸깍딸깍하면서 저 프로젝트로 전환되고 이 프로젝트로 전환되고 왔다갔다 하는 느낌을 받았다.

스위치를 전환하면서 이전에 무슨 작업을 하고 있었는지 까먹는건 덤이다.

그 중에서 기억에 남는 작업은 채팅기능쪽 에러 수정이 아닐까 싶다.

사용중 어느 시점이 되면 채팅 기능이 아예 먹통이 된다는게 아닌가…?

이럴때 이럴때가 안 돼요!

이것도 아니고 가끔가다 안된다뇨…. ㅋㅋㅋ쿠ㅠ퓨퓨ㅠ

당사자는 전혀 흥미진진하지 않죠!?


해결하고 보니 별것 아닌 문제였지만 누구나 그렇듯 알 수 없는 벽에 부딛히면 멘탈이 흔들리기 십상이었기 때문에, 강렬하게 기억에 남는것 같다!

해당 프로젝트는 당근마켓 같은 폐쇄형 플랫폼이라서 모든 유저들은 로그인이 필수 였고, 그렇기 때문에

채팅 기능을 구현할때에 user의 id에 socke id를 넣어 socket id를 관리했었다.

문제가 발생한 부분은 바로 한 디바이스에서 계정을 logout을 하고, 새로운 계정으로 로그인 할때였다.

내가 생각한 일반적인 logout은 session을 날린다거나? token을 날린다거나? 내가 상대를 알 수 있는(검증할 수 있는) 요소들을 초기화 시키는 일련의 작업들인데,

이 과정들 안에 socket의 id가 담긴 부분을 초기화 해준다는 요소가 없었기에 발생한 문제였다…

userId 1번에 a라는 socketId가 담기고, logout을 요청해도 a socketId를 가지고 있는건 userId 1번이었고,

그 상태로 userId 2번으로 login하게 되면 디바이스의 socketId는 a인데 login한 userId는 2번이니

userId와 socketId 간의 불일치가 일어나 간헐적 먹통현상이 발생한것이었다!

2. 리팩토링

나는 연초에 리팩터링 2판을 읽었던적이 있다.

코딩에 대한 경험이 많이 부족함에도 리팩터링이라는 책을 읽었던 이유는,

저질스러운 내 코드를 조금이라도 개선할 수 있는 방법이 뭘까? 하는 생각에서 비롯되었다.

회사에서는 이 프로젝트를 진행하고 집에와서는 리팩토링을 읽었는데, 책에서 읽었던 내용이 내 코드에서 발견되니 기분이 묘해졌었다.

두번 중복된 기능을 하나의 function으로 묶어서 작업한 부분에 대해서 기능을 수정하는 요청이 들어왔었다.

같은 일은 세번 반복하면 리팩토링해라!

해당 작업을 수행하면서 책의 내용이 머리속을 스쳐지나갔다.

두번째에서 조금만 더 참고(?) 세번째 때 공통으로 묶어서 처리를 했다면,
지금 더 깔끔한 코드가, 더 쉽게 작업을 수행할 수 있지 않았을까?

아쉬움이 많이 남았지만 이런 경험을 함으로써 책의 내용을 통해 생각하는게 조금씩 바뀌고 있다고 하니 한편으로 뿌듯하기도 했다.

물론 두번째는 안되고 무조건 세번째부터 리팩토링이다! 라고 말하고 싶은게 아니다.

나보다 경험이 많고 능력이 좋은 선배 개발자들이 이렇게 이야기할 때는

왜 그렇게 이야기했을까 다시 한번 생각을 정리할 필요가 있다라고 느끼게 되었다.
(이번 경험을 통해서 나도 위와 같이 느끼는바가 있었고 말이다!)

난관

1. 권한

이번에 진행한 프로젝트는 권한이 4가지 종류로 구성되어.

브랜드 및 브랜드 아래에 있는 가맹점을 관리하는 프로젝트였다.

최고관리자 -> 브랜드 -> 담당자 -> 가맹점

최고관리자 아래의 여러개 브랜드…

그 브랜드 소속된 많은 담당자…

그 많은 담당자 관리하는 수 많은 가맹점들…

모든 코드에 권한에 대한 체크가 들어가야 했고, 권한이 4가지가 있으니 조금만 작업을 해도 머리가 과부하되기 일쑤였다.

저녁시간이 되면 눈도 잘안보이더라...


이런 권한 체계에서 요구되는 당연(?)한 내용이 있다.

높은 권한을 가지고 있는 사람은 낮은 권한의 사람들이 할 수 있는 것들을 마찬가지로 할 수 있다는 것이다.

조건문으로 분기처리하면 뭐 간단한 내용아니냐!

물론 조건문으로 분기처리하면 충분히 가능하다.

다만, 가뜩이나 권한의 증명이나 validation으로 인해 복잡하게 엮인 business logic의 크기를 더욱 키울 필요가 있을까 생각이 들었다.

해결방법은 의외로 간단했다.

QueryString에 해당 기능에 대한 권한을 가지고 있는 하위 유저의 id를 넣어주고.

API 진입 전 유저인증단계에서 하위 유저에 대한 나의 권한만 체크를 한후, 하위유저의 입장에서 API에 접근하니,

조건문으로 분기처리를 할 필요도, business logic을 추가적으로 수정할 일도 없었다.

더 좋은 방법이 있었으리라 생각도 들지만 이번 프로젝트에 한해서는 이슈없이 깔끔하게 처리할 수 있었기에 만족한다.

2. SQL

프로젝트의 성격상 절대 빠질 수 없는 단골 기능이 있다.

바로 수익 통계기능인데, 기업을 운영하면서 수익이 얼마나 나고 있을까? 라는건 당연한 궁금증인것 같다.

거기다 효율적으로 업무를 하기 위해서는 내가 관리하는 업체(가맹점)가 얼마나 실적을 내고 있는지 알아야하지 않겠는가? 그렇다고 말해라

하여간 처신 잘 하라고!


일별로 수익을 뽑아내고 매번 바뀔 수 있는지출이라는 변칙적인 요소와 여러 상황이 작용하니, 도저히 ORM으로 작업할 엄두가 안나서 raw query를 사용했다.

물론 따로 Summary Table을 만드는 방법도 있지만, 불필요한 insert와 update가 너무 빈번하게 일어나게 될 것같고(필요에 의해서 작업한다면 불필요는 아니지만!),

또 지금은 business logic에 큰 영향을 주진 않지만 추가 기능이 생기거나, 기존 코드의 오류로 인해 코드를 수정하는 상황이 온다면 로직자체가 복잡해지고 커질 것 같았다.

이 결정으로 인해서 한 일주일정도는 꽤나 고통스러웠다(?).

1월부터 12월까지 통계를 뽑아야하는데, 놀랍게도 2월의 수익이 없다면 2월이 구멍이 생기는건가?

SELECT  *
FROM    (
            SELECT '2021-01' month UNION
            SELECT '2021-02' UNION
            SELECT '2021-03' UNION
                      ...
        )

위처럼 subquery와 union을 이용해서 가상의 달력을 만들고, LEFT JOIN을 이용해서 통계자료를 덕지덕지 붙이기도 했다.

LEFT JOIN의 참맛을 알아버렸다 흐흐


작업중 고정지출이 있는달이 있고, 없는달이 있는데, 고정지출이 없는달은 전달, 전달의 고정 지출도 없다면 그 전달의 고정지출 쭉쭉… 이전의 고정지출을 가져와서 계산을 해줘야했다.

그러다 보니 값을 임시로 저장할 수 있는 방법이 필요했는데, 도저히 이 값을 임시로 저장할 수 있는 방법이 떠오르질 않아서 고민을 하던중.

@ 를 사용하면 변수로서 사용이 가능하다는걸 알게 되었다.

SET @start:=5;

or

SELECT  @pixedCost:=(SELECT ...)

이런식으로 변수를 초기화하고 SELECT 구문에서 필요에 의해서 변수값을 다시 할당해주니까 어려워도 어찌어찌 구현에 성공했다!

SQL에서 변수까지 선언해가면서 작업을 하니 SQL단어의 뜻을 다시 한번 생각하게 되었다.

Strucured Query Language

그래… 너도 Language였었지 ㅋㅋㅋㅋㅋ 이전까지는 그저 DB를 다루기 위한 도구 처럼만 생각했었는데,

query를 작성하면서 이것저것 해보니 진짜 Language였었구나(?) 싶고 SQL과 좀 더 친숙해진것 같다.

3. API의 단일책임

서버의 부하를 줄이고, 여러 리소스를 잘 활용해서 많은 요청을 거뜬히 버텨내는 서버가 좋은서버다!

당연히 위의 말에 이견은 없다.

그런데 서버의 부하를 줄이겠다며 Request도 줄이면 엄청난 효과를 가져오지 않을까? 생각도 했다.

지금 와서 생각해보면 너무 막연하고 생각이 깊지 못했던것 같다.

  1. 각자의 최소의 역할을 맡으면서 작업을 처리한다!
  2. 말도 안되는 억지 논리로 한페이지(비슷한 페이지)에 있으니까 무조건 한 API로 처리한다!

되돌아 보면 나는 2번에 더 가까우면서 1번은 생각만 하는 사람이었다.

프로젝트를 진행하면서 비슷하면서 미묘하게 다른 기능이 있어서 이걸 한곳에 모아 한 API로 처리한적이 있다.

작업을 진행할 당시에는 하나로 묶어서 처리하면 타이핑도 줄고 문서작업량도 줄어드니 그것 나름 괜찮은 방법이라고 생각을 했었다.

물론 이 생각이 바뀌게 될때까지 오래 걸리지 않는다 ㅋㅋㅋㅋ;

시간이 지나며 요구사항이 변경되고 작업이 진행될 수록 해당 API는 수 많은 조건문과 validation으로 엉망진창이 되었다.

간단한 작업하나를 진행하려고 해도 해당 코드를 다시 이해하고 작업을 해야하는 지경에 다다른 것이다.

이 이후에는 진짜 필요한 기능만 하나로 묶고 API에 단일책임 원칙을 부여하도록 노력했다.

물론! 이렇게 API를 분리하면서 작업하니 시간이 더 들게 되었지만,

나중에 유지보수에 쓸 시간을 그나~마 여유 있는 지금 끌어다 쓴다고 생각하니까 결코 손해보는 장사(?)가 아니라고 느꼈다.

그리고 실제로 요구사항이 변경되었을때 재빠르게 대응하기가 훨씬 수월했다.

4. DB Schema Modeling

또 이 문제다 아니 진짜...


두번째 프로젝트에서는 schema를 너무 쪼개서 문제가 되었다면 이번에는 너무 쪼개지 않아서 문제가 발생했다.

...왜?


지난번에 고생을 하고 Schema Modeling의 중요성을 그렇게 깨달아 놓고서 또 실수를 저질러 버렸다.

너무 쪼개서 문제가 되었다면 공통되는 부분을 많이 합쳐보면 어떨까?

한마디로 정규화가 제대로 이루어 지지 않았다.

위의 사진들을 봐서 알겠지만 당연히 고생을 좀 했고, 계속해서 할 것 같다.

유사한 속성을 묶자는 입장에서는 좋은 도전이었지만, System상으로는 좋은 도전이 아니었다.

유사한 속성을 같이 사용하니 Column의 역할이 무엇인지 파악하려면 시간이 오래걸렸고(걸리고 있고), 비즈니스 로직의 끝은 결국 DataBase니 모든 작업을 하는 매 순간순간이 고민의 연속이었다.

다행이 중간에 들어서서 다른 Schema는 다시 설계해서 같은 상황은 면했지만 (지능 상승의 효과가 여기서!!)

위의 경우에는 작업해놓은 것을 전부 되돌리기에는 너무 와버려서 작업을 강행했다.

총 3개째 프로젝트만으로 당연히 대단한 Modeling Skill을 가질 수는 없지만.

그래도… 참 자신에게 많이 실망했던 부분이다 ㅋㅋㅋ

긍정적인 부분은 두번째 프로젝트보단 (아직) 고생을 덜 했다는 점에서!!

이렇게 계속 고생을 하다보면 언젠가는 괜찮은 Modeling Skill을 가질 수… 있지 않을까 희망을 가져본다.

5. Cloud Front

평소나는 EC2나, RDB, S3정도를 프로젝트 초반에 setting정도만 하고 이후는 거의 만지지 않는다.

딱히 만질일이 없다…?

그래서 핫한 AWS나 기본적인 인프라 지식이 많이 모자르다고 스스로가 생각한다.

각설하고, 이번 프로젝트는 관리자 웹페이지에 도메인 설정을 해달라는게 아닌가?

가비아에서 도메인을 구입하고 포트폴리오를 올린 EC2에 설정해본적이 있긴했지만,

S3 Buket에 도메인을 연결하라고 하니 좀 당황스럽기는 했다.

달라봐야 얼마나 다르겠어? 그냥 뚝딱 연결해주면 되지!

다르긴 하더라…. ㅋㅋㅋ;;;

도메인을 염두하고 bucket을 만들지 않았기 때문에 cname으로는 mapping은 되지만 접근이 되지않았고(bucket명이 도메인과 다르면 접근이 안되더라).

bucket을 복사해서 새로 setting해보기엔 처음 해보는 작업이기도 하고, 마감 기한이 얼마 남지 않았기 때문에 위험 + 많은 시간 소모 같은 모험을 할 수도 없는 노릇이었다.

AWS에서 자사 서비스끼리 호환 기능을 제공하지 않을까 Route53을 써서 작업을 하려고하니,

고객사에서 원하는 도메인은 AWS에서 취급을 안하더라

그래서 도메인은 가비아에서 구매하고 name server를 route53으로 옮겨주고…

장장 6시간에 걸친 삽질기를 펼치게 된다(주말 특근 후 집에서 쉬려고 했는데 결국 하나도 쉬지 못했다 ㅜㅠ).

가비아 -> Route53(name server setting)

Route53 -> Cloud Front -> S3

이 순서대로 연결을 해줘야 하는데, 막판에 Route53에서 S3를 연결해주는걸 못해서 진땀을 많이 뺏다.

너가 해달라는데로 다 해줬잖아...


Route53에서 별칭탭을 이용하니 AWS에서 제공하는 서비스들을 손쉽게 연결할 수 있더라.

고생은 좀 했어도 도메인을 쳐서 관리자 페이지로 들어가니 기분이 정말 좋더라!

성취감만 느낀다면 너무너무 좋지만 그 과정이 너무 험난하다

모르면 삽질하고 맨땅에 헤딩해야지 암 그럼그럼 ㅜㅡㅜ

개선

1. Switch문

나는 평소에 if문을 즐겨쓰고는 했다.

이유는 따로 없었다. 그냥 if문을 더 자주 사용해왔고, 손에 익었다고 해야할까?

그러던 중에 안드로이드 개발자님의 코드를 어깨넘어서 본일이 있었다.

그분은 Diff라고 하는 상태값을 switch문을 이용해서 처리를 했는데, 그게 새삼 깔끔해보이는게 아닌가 ㅋㅋㅋㅋ

좋은건 같이 하자니까 아 ㅋㅋ


어려운 일도 아니겠다. 당장 프로젝트에 적용을 시작했다.

if(diff === '학생') {
  점심시간에뛰지않기();
} else if(diff === '선생') {
  진도어디까지();
} else if(diff === '교장') {
  마지막으로한마디();
}

switch(diff) {
  case '학생':
    점심시간에뛰지않기();
    break;
  case '선생':
    진도어디까지();
    break;
  case '교장':
    마지막으로한마디();
    break;
}

굉장히 간단한 코드이기도 하고, 별로 차이가 없어보이기도 하지만 나는 switch문이 굉장히 정갈하다는 느낌을 많이 받았다.

아무래도 case라고 하는 조건이 line에 맞춰 정렬이 되어있어서가 아닐까 생각이 든다.

switch문에 감탄하며 활용할 수 있는 부분에는 최대한 활용해보자 여기저기 적용하던 중에

아 이건 좀…?

생각이 들었던 상황이 있었다. 그건 바로 switch문과 if문이 중첩되는 상황이었는데,

그 모습을 보고서 너무 충격을 받아서 순간적으로 switch문이 쓰레기 같아보이고 다시는 쓰고 싶지 않다고 생각까지 들었다.

switch(diff) {
  case '학생':
    const isRun = 점심시간에뛰지않기();
    if(isRun) {
      혼난다();
    } else {
      가던길마저간다();
    }
    break;
  case '선생':
    const isMiss = 진도어디까지();
    if(isMiss) {
      했던부분을또한다();
    } else {
      다음부분을이어간다();
    }
    break;
  case '교장':
    const isLast = 마지막으로한마디();
    ...
}

오버한다고 생각 할 수도 있지만, 그때 당시엔 그랬다!

지금와서 보면 괜찮은거 같기도 하고…?

그래서 내린 결론은 if문이 최소화되고, 구분값이 명확히 정해져있는 상황(ex. normalUser, admin)에 쓰면 더욱 빛을 바랄 수 있을 것 같다고 생각이 들었다.

2. Static Property

정적인 정보를 따로 빼서 관리하는건 일반적으로 당연한 일이다.

그런데 나는 이것까지 빼야할까? 싶었던 것들에 좀 데였던것 같다.

status 값이 바나나원숭이 였는데, 이걸 고객사에서 바나나로 바꿔달라는 요청이 있었다(물론 status값은 예시다 ㅋ).

DB의 값들이야 query를 조심해서 슉! 날려보면 된다고 하지만 code상에 자리잡고있는 static한 이 친구들을 전부 고치기란 여간일이 아니었다.

IDE의 기능을 이용하자니 바꾸지 말아야할 부분도 바뀌게 될것 같아서 IDE도 이용하지 못하고 일일이 바꿔줬다.

수정작업을 마친뒤 몇시간뒤 멀쩡하게 동작하던 부분이 안된다는 이야기가 들려온다…

왜 그런지 아는데 왜그러냐고요? 그건 저도 지금부터 찾아봐야죠


찾아보니 바뀌지 말아야할 WHERE 절에 있는 status 값까지 다 바꿔 버렸더라.

작은 프로젝트에서 이런 효과(?)라면 프로젝트의 규모가 커지면 도저히 감당이 안될것 같다는게 확실히 느껴지더라.

그래서 다음 프로젝트때는 Node의 좋은 기능중 하나인 export와 import를 이용해서 static property를 관리해보면 어떨까 싶다.

3. 형상관리(Release Tag의 사용)

이 프로젝트부터는 commit message부터 차근차근 형상관리에 신경을 쓰고 있다.

git commit -m "update"

항상 이런식으로 의미 없는 commit message를 남기곤 했다.

당연히 뭐라도 했으니까 commit을 하고 commit을 했으니까 뭐라도 수정됐겠지…

어느새부터인가 보니 저렇게 message를 남기면 형상관리를 한다기보다는 그냥, 코드 보관을 하기위해서 git에 올리는거 같다는 생각이 들게 되었다.

그래서 commit message를 남기는 방법을 바꾸기로 했다.

git commit -m "update: name값 필수값으로 수정"

git commit -m "create: user Create API 추가"

git commit -m "fix: 상태변경시 화면에 나오지 않는 문제 해결"

영어로 유창하게 남겨야할 이유도 못느꼈고, 유창하게 남길수도 없고

누가봐도 의미를 한번에 캐치할 수 있는 단어를 앞에 두고 그에 대한 설명은 한글로 빼뒀다.

또 프로젝트 마감을 기준으로 v1.0.0 이렇게 commit에 Tag를 붙이기 시작했다.

서비스가 실사용으로 전환되면 코드 하나하나를 수정할때 조심스러워지고,

사소한 작업에서 critical한 문제가 터지지 않으리라고 누구도 장담할 수 없으니까.

간단히 말하면 조금이라도 빠르게 대처하기 위한 point를 marking하기 위함이다.

날짜의 형식을 2021.01.01 => 2021-01-01 이렇게 바꾸는, 시스템에 영향이 적다고 판단이 들때는 version을 올리지 않고,

기능을 수정하고, error을 잡을때 version을 v1.0.1 이런식으로 한단계씩 올려주는 방식으로 운영해볼 생각이다.

두번째 프로젝트 부터 Tag를 달고 운영중인데 신기하게 오픈 이후 이렇다 할만한 요청이 오지않아서 아직도 v1.0.0이다.

그렇다면 그런줄 알아


아직 이렇다 할 만한 결과가 나오고 있지 않지만, 그래도 순기능을 가져올 때가 있지 않을까?

결론

우여곡절이 정말 많았던 프로젝트였다.

중간중간에 수시로 화면이 바뀌고 기능이 수정되고, 바뀐부분 수정하랴 새로운 기능 추가하랴

거기에 권한 4개를 가지고 놀아야하니 혼이 쏙 빠지는 프로젝트였다.

두번째도 정신없다 정신없다 했는데, 어째가면 갈 수록 더 그러는것 같기도 하고…?

ㅎ


이번 고객사는,

이제 사업을 막 시작하는 업체가 아니라 전국에 가맹점만 500개가 넘고 그룹안에서 관리하는 브랜드만 6개정도 되는 커다란 기업이었다.

그러다보니 더 바짝 긴장하고 작업에 임했던것 같다.

고객사의 덩치가 크니까 쫄았다는게 아니다!

이제 막 사용자를 모아야하는 업체들과는 달리 이미 수 많은 유저들을 보유하고 있는 상황이기 때문에,

서비스 초기부터 많은 피드백이 올것이고,

그렇기에 초반 기틀을 잘 잡아놔야겠다는 각오를 다졌다(물론 어느 프로젝트가 되었던 마찬가지지만).

피드백 -> 유지보수 -> 시간을 들인다 -> 시간 = 돈 -> ?

내 연봉이 아무리 귀여워도 저런 시간들이 쌓이다보면 회사에 결코 좋은 영향을 주진 않겠다는 생각이 강했다.

이렇게 프로젝트 한개 두개씩 쌓여가다 보면 어느사이에 꽉찬 1년차 개발자가 되겠지!

하지만 연차에 비례하지 못하는 실력… 눈감아?

개발실력도 개발실력이지만, 소통도 실력이고 정말 중요하다는걸 많이 느꼈다.

기획자와의 소통
디자이너와 소통
개발자간의 소통

어디 하나 중요하지 않은 부분이 없었고, 정말 소중한 경험을 한것 같다.

솔직히 말해서 수정사항도 없고, 쉽게 쉽게 물 흘러가듯이 흘러가는 프로젝트였으면 이렇게까지 소통의 중요성을 느끼지 못했을 것 같다.

고생은 사서도 한다고 6개월차는 사서도 고생을 해라~ 이말이야!

안맞으면 안돼요?


Java공부를 다시 시작했다.

이유는 간단하다. 우리나라의 프로젝트의 대부분은 Java 프로젝트이고 그만큼 Java 개발자들이 많다.

내가 우리 회사뿐 아니라 우리나라 안에서 경쟁력 있는 백엔드 개발자가 되기 위해서는 Java와 어느 정도 친숙해야한다고 생각했기 때문이다.

언어는 도구일뿐이다.

물론 이 말에 동의하지만, 그렇다고 하기엔 우리는 너무 언어에 종속적이라고 생각한다.

왜냐하면 당장 채용공고만 봐도 모집요강은 NodeJS경력자 이지만 우대사항에는 Java가 적혀있는 경우가 허다하고,

애초에 Java 경력자라고 공고에 올려 놓은 공고들이 많다.

이래도 언어가 오직 도구일뿐이라고만 이야기 할 수 있나?

진리의 케바케, 사바사, 회바회 이기때문에 단언할 수 없지만 분위기가 그렇다는 말이다!

아님 말궁


무슨 언어가 취업이 잘된다~ 더 좋다~ 이런말을 하려고 하는게 아니다.

진짜 언어를 도구라고 생각하는 사람이라면 자신이 언어에 종속적이지 않도록 노력해야한다고 생각한다.

이 노력에는 여러 방법이 있겠지만 내가 선택한 방법은 국내에서 가장많이 사용되는 Java를 학습하는 것이다.

JavaScript을 깊이 있게 학습하는것도 물론 중요하다(안하겠다는게 아니다!).

Java개발자 뽑는다고 해서 갔더니 Python만 만지고 있어요 ㅠㅠ

이런 이야기가 심심치 않게 들려오기도 한다.

저 이야기가 내 이야기가 되지 않으리라는 법은 없다.

또 무엇보다 나 스스로가 언어를 가리는 사람이 되고 싶지않다.

어떻게 보면 한가지 언어만 공부하는것보다 학습시간이 줄어들게되니 두가지 언어 다 흐지부지 될 수 있지만 그렇게 되지 않도록 해야지.

언어공부를 하면서 인프라쪽도 같이 공부해고싶다…!

다음 프로젝트부터 NestJS를 도입할 예정이다.

공부도 하고 고민도 많이하고 도입하지만, 회사 업무인 실제 프로젝트 라는점

또 기존 Express기반에서 NestJS로 넘어 가는것이기 때문에 많이 어려움을 겪을 것이라는것 등등…

심리적으로 압박감도 크고 부담스럽다.

솔직히 처음 NestJS를 도입한다고 대표님께 말씀드릴때 반대 하실줄 알았다.

왜냐하면 이미 Express 기반으로 작업을 잘 해왔는데. 굳이 바꿀 필요가 있을까 충분히 생각할 수도 있기 때문이다.

하지만 우려와는 다르게 흔쾌히 승락해주셨고, 이제 내가 증명해낼 차례인거다.

그래서 이번 프로젝트가 끝날때까지 나는 죽었다 생각하고 빡세게 달려볼 생각이다.

얻은 신뢰를 쉽게 잃고 싶지 않으니까!

NestJS를 도입하는 대표적인 이유는 아래와 같다.

  1. Express와 달리 Framework에서 프로젝트의 형식을 제공해줘서 어느정도 일관된 프로젝트 구조를 가진다.
    => 회사가 커져감에 따라 협업이 용이해진다.
  2. 대체가능한 모듈은 내장모듈로 대체하여 개인이 만든 open source를 최소화하고, 따로따로 install하는 각 모듈에 대한 러닝커브를 줄인다. 등등

지금은 NestJS에 대해 긍정적이고 많은 기대를 하고 있는데,

과연 프로젝트가 끝난 시점에도 긍정적일지 다음 프로젝트 후기를 기대하시라!

Leave a comment