1달간의 길다면 길고 짧다면 짧은 기간이 끝났다. 이 생생한 기억이 가시기전에 글을 작성해두기로 했다.(그러면 2차프로젝트도 바로 적었어야......)

블랙.... 뭐요?

기업협업을 간 회사는 (주)아이비즈라는 곳으로 여러 솔루션을 만드는 업체인데 그 중에 내가 들어간 부서는 Blackboard라는 학사시스템을 제공하는 업체의 파트너사였다.
일단은 블랙보드라는 서비스를 접해본적이 없었는데 미국 유학생이었던 한 팀원의 말을 들어보면 외국에서는 유명하고 국내 대학에서도 이용하는 곳이 몇 군데 있는 것 같았다.

실제 고려대학교에서 사용중! (고대 친구말에 따르면 엄청 버벅인다고...)

이번 한달동안의 프로젝트는 실제 대학교에서의 학사db와 블랙보드 시스템 상의 db통신 과정에 작동하는 미들웨어를 만드는 것이었다.

좀 더 구체적으로 이야기하면 문제의 소지가 있을 수 있어서 이정도로만 이야기해야겠다(기업비밀!!) 비즈니스로직이 엄청 복잡해서 처음 설명을 듣고 팀원 4명의 표정을 보았을 때는 정확히 아래짤의 하하의 표정과 동일했다. 분명 동일한 한국어를 사용하는데 따라가기 힘들었다.

게다가 부산에서 혼자 파견나오신 한 분의 개발자(무려 풀스택?!)께서 PM을 맡아서 진행을 하셨다. 디자인, 기획자 분들과 같이 협업을 기대했었는데 그 부분은 아쉬웠던 것 같다.
인생이 늘 계산대로 이루어지는 것은 아니니 부딪혀보기로 했다. 어떻게든 되겠지...?

🤲🏻 팀구성은 좋아좋아

팀구성같은 경우 1차나 2차 프로젝트에서 각 분야에서 어느정도 두각을 나타냈던 분들과 같이 하게 되어서 큰 걱정은 없었다. 특히나 프론트 담당을 하셨던 분과는 이미 1차 프로젝트를 진행을 하면서 호흡을 맞췄던 경험이 있어서 안심이 됐다.

이미 2달간 동고동락하며 친분은 있었으나 그럼에도 최대한 말실수나 기분 상하게 해드리는 행동을 안하기 위해 팀원들의 성격을 파악했다.

다만 비즈니스 로직이 너무 어려웠고 전달해주시는 팀장님과의 소통이 원할하지 않았다. 특히 팀장님께서 요구하셨던 내용들이 계속 바뀌어서 따라가는 부분이 벅찼다. 중간에 만들었던 내용이 필요없어지거나 전혀 새로운 기능들이 추가되었다.

거기다 백엔드는 nodejs + express로 개발을 진행을 했는데 새로운 기술스택을 익히느라 처음 일주일이 지나가고 비즈니스로직을 이해하는데 추가로 1주일이 지나갔던 것 같다.

그래서 팀원들이 처음 2주는 나를 포함해서 디모티베이션이 왔던것 같다. 추가로 다른 기업들에서 제공하는 복지에서 차이가 느껴지다보니 더욱 그랬던 것 같다.

😮‍💨 아쉬운 점부터

위에 이야기한 것처럼 우선은 프로젝트 전체적으로 만족스러운 부분보다 아쉬운 점이 많다.

조금만 더 욕심을 가져볼 걸

다들 디모티베이션이 와서 더욱 많은 것을 못해봤던 것이 아쉽다. 실제로 마지막주에 코드를 다 작성을 했을 때는 생각보다 많은 기능을 시도해보지 못했다는 것을 느꼈다. 다른 팀의 최종 발표를 들으면서 더 크게 느껴졌다. 상황탓만 하며 노력을 등한시하지 않았나 생각해보게 되었다.

비교보단 집중을

위에 상술한대로 기업협업을 나갔던 다른 수강생들과 이야기를 나누다보니 기업간 차이를 느낄 수 있었다. 한 곳은 코드리뷰를 주기적으로 해주었고 추가로 과제 부여를 해주는 곳도 있었다. 반면 같이 일하셨던 팀장님 같은 경우 혼자 개발을 오래 하셔서 그런지 리거시 코드에 컨벤션을 지키는 부분도 많이 부족했고 잉여적인 코드가 많이 적혀있었다.

반면 조금만 시선을 돌리면 배울 수 있었던 부분도 있었는데 일단은 야생에 던져지다보니 부트캠프에서 스스로 부족하다고 느낀 혼자 공부하는 법을 제대로 익힐 수 있었다. 이 부분은 '그럼에도' 파트에서 조금 더 이야기하겠다.
팀장님이 개발보다는 시스템 유지쪽에서 오래 계시다보니 개발관련 용어 및 개념을 많이 접할 수 있었는데 DB INDEX store procedure와 같은 sql을 효과적으로 사용하는 방법이라든지 crontab - schedule job과 같은 생소했던 개념을 익힐 수 있었던 것 같다.

三人行 必有我師焉(삼인행 필유아사언)

공자님께서 말씀하시길 3명이 길을 걸으면 반드시 스승이 있다고 하셨다. 이 생각으로 최대한 시스템 및 개발관련 경험을 많이 배우려고 노력했던 것 같다. 다만 조금만 더 일찍 비교보단 내가 놓여진 곳에 장점을 알면 어땠을까하는 아쉬움이 있다.

다양한 시도

실제 b2b 업무 + 이미 알파모델이 있는 상황에서 내가 시도할 수 있는 부분은 많이 제약되었던 것이 사실이다. 그럼에도 불구하고 초기모델이라 제안을 받아들여주실 수 있다고 했는데 많이 못드렸던 것이 아쉽다.

대표적으로 express를 사용하였지만 별도록 ORM을 사용하지는 않았다. 우선은 리거시 코드가 query로 접근하는 로직이라서 로컬 DB를 그렇게 많이 다룰 일이 없을 것 같았다.

진행을 하다보니 내가 다루는 기능이 로컬DB의 객체에 많이 접근해야하고 계속 쿼리를 날리는 로직을 짜다보니 코드가 잉여적이고 반복이 심했다. (물론 쿼리 호출하는 함수는 모듈화를 했다.)

먼저 다뤄야 할 기능들에 대해서 생각을 스스로 많이 해보았다면 조금 더 효율적으로 시간을 쓸 수 있지 않았을까 하는 아쉬움이 있다.

---

🤜🏻 although(그럼에도)...

판도라의 상자에도 여러 부정적 재앙이 다 빠져나가고 나서도 한가지 중요한 희망이 남아있었듯이 스스로 만족스러웠던 부분들이 있다.

팀원 모티베이션

전체적으로 다들 의욕이 없던 상태에서 한번이라도 질문을 드려서 요구사항을 명확히 하려했다.
추가적으로, 할 수 있는 것과 무리인 것을 구분해서 기능을 최대한 마무리하도록 팀원들을 독려했던 것 같다. 요구사항이 명확해지고 구현가능한 기능을 분류하고 나니 마지막 1주는 나를 포함해서 다른 팀원들도 기능을 마무리하기 위해 노력할 수 있었던 것 같다.

비즈니스 로직 공유

디모가 왔던 부분중에 큰 포션을 차지하는 어려운 비즈니스 로직을 뿌시기(?) 위해서 스스로 비즈니스 로직 순서도를 그려보고 이 부분이 맞는지 지속적으로 팀장님과 소통을 하려고 했다. 더욱이 프론트와 직접적으로 소통하는 기능을 많이 진행을 했기 때문에 프론트에서 놓친 부분에 대해서 한 번 더 확인 이후에 수정을 할 수 있었다.

최대한 요구사항이 명확해져서 개발이 진행이 가능하도록 만들기 위해서 팀장님께 많은 질문과 챌린지를 했던 것 같다.

새 기술 스택 공부

위에 적은대로 기존에 django와 python만 다뤘었는데 이번 기회에 nodejs를 제대로 익혀보고 싶은 생각이 있었다. 처음에는 장고와 너무나 다른 점 때문에 낯설었다. (npm express init을 했을 때 달랑 package.json만 나오고 많이 당황했던 기억이 있다. )
그럼에도 어떻게든 스스로 기능을 만들어야 했기에 유튜브,공식문서를 계속 참조했다.(사랑해요 MDN 😍) 그리고 찾았던 좋은 블로그나 유튭링크는 트렐로에 링크를 달아두어 다른 팀원들이 자료를 찾는데 드는 시간을 줄이려고 했다.

처음이 힘들었고 이후에는 수많은 정보가 있고 그저 찾아서 공부만 하면 되는 것이었다. 다시 한번 내 모토인 '어려운 것은 없고 낯설 뿐이다'라는 진리를 느끼게 되었다.

🙋🏻‍♂️ 담당기능

자 이제 조금 기술적인 이야기를 해야 개발블로그 포스팅이니 맡았던 기능중에 핵심적이고 새로웠던 기능에 대해서 적어보려고 한다.

Job CRUD +toggle on/off

실제 주기적으로 일어나는 일(스케쥴)을 만들어야했고 그 스케쥴들에 대해서 각각의 설정값을 만들고 (create) 조회하고 (read) 변경하고 (Update) 삭제(delete)하는 로직을 만들었다.
특히 update와 삭제를 진행을 할 때는 특정 스케쥴만 지정을 해야했는데 이 부분이 많은 변경을 거쳤다.

< /:jobId> path parameter

처음에는 JobID에 path parameter로 접근을 해서 조회를 하려고 했는데 생각을 해보니 해당 Job에 대해서 프론트는 id가 무엇인지 파악하기 쉽지 않았다. 그렇다보니 이를 해결할 방법이 필요했다.

< /?data-type & ?action> query string

job을 만들 때 들어가는 두가지 필드 값으로 query파라미터를 만들어 해당 값을 특정하려고 했다. 각 job마다 두가지 값을 복합키로 적용을 하면 고유한 값이 나오기 때문에 이렇게 진행을 했다. 다만 프론트 분꼐서 쿼리 파라미터를 다루는 것에 익숙치 않아서 옵션 3으로 가게되었다.

POST + body

기존에는 토글 기능을 구현하기 위해서 patch로 toggle 필드의 값을 1,0으로 바꾸는 로직을 구현했었다. 이제 쿼리 파라미터를 사용하지 못하면서 이 부분을 포스트로 만들고 해당하는 바디에 특정할 수 있는 data-type과 action을 넣기로 했다. 다만 이 방식이 restful 하다고는 생각하지 않아서 아쉬움이 남는다...

middleware - decrypt

기존에 django에서는 decorator에서 토큰 값을 받고 decrypt한 후 특정 객체의 정보를 각 http메서드가 실행될 때 받아오도록 했다. 이와 비슷한 기능을 하는 것이 passport라고 알고 있는데 이 부분은 user 파트를 담당했던 팀원이 이용하지 않았다. 그래서 복호화를 별도록 하지 않은 상태로 토큰을 넘겨 받게 되었다. 각 이용자별로 JOB이 있기 때문에 이제 토큰을 복호화해서 어떤 사용자의 JOB에 대해서 요청을 처리할지 로직을 작성해야 했다.
이때 생각한 것이 express의 middleware이다. express의 가장 큰 장점인 자율성에 대표적인 기능중 하나인 middleware로 메서드를 실행하기 전에 꼭 middleware를 거치고 그 값을 다음 메서드에서 인자로 받을 수 있도록 res.locals를 사용하였다.

대략적인 코드는 다음과 같다.

// app.js   token ==> decorator
function token(req, res, next) {
  const token = req.header("Authorization");
  const payload = jwt_decode(token);
  const clientKeyId = payload["clientKeyID"];
  res.locals.id = clientKeyId;
  next();
}
app.use(token);
app.use("/config", configRouter);

이제 passport를 공부해보고 어떻게 접근하는 것이 더 좋은지에 대해서 생각을 정리해봐야겠다. (아무래도 위에 방식은 보안이 취약하고 확정성이 부족해보인다..... )

schedule JOB

node-schedule이라는 패키지를 이용해서 각 스케쥴이 지정한 Crontab 시간마다 돌도록 코드를 작성하였다. 다만 이 부분은 테스트를 진행할 시간이 부족해서 실제 기능에 반영하지는 못했다.
그럼에도 예제 코드를 쳐보고 실제 linux 명령어로 시간을 바꿔가며 테스트해보니 생각보다 어렵지는 않았던 것 같다.

Logging

각 메서드가 작동 + 쿼리가 돌때마다 결과에 대해서 파악할 수 있는 logging기능을 적용하였다. js에서 지원하는 winston.js 패키지를 이용해서 log와 error를 별도로 저장하였고 info 레벨까지 기록하도록 했다.
이 과정에서 실제 로그 + 지정한 메시지가 테스트를 할 때마다 찍혀서 신기했고 더욱이 에러메시지같은 경우 에러메시지가 그대로 error directory에 저장이 되어서 더욱 디버깅을 빠르게 할 수 있었던 것 같다.

(지운 부분은 보안 이슈로 !! )

개발자로서의 첫발자국

야생생존

생각보다 기업에선 사수가 없거나 지도를 해줄 수 없는 상황이 많다는 것을 느낄 수 있었다. 그러면 기능 구현 + 최적화는 전적으로 나의 몫이었다. 이 프로젝트를 통해 기능을 구현할 때 발생하는 문제를 해결하기 위한 검색능력을 기를 수 있었다. 똑같은 단어라도 검색어를 어떻게 조합하는지에 따라 다른 결과가 나오는 것은 신기했다 (error '해결' 식으로 한글자료를 찾아본 건 비밀....)

추가적으로 공식문서도 조금 더 들여다보기 시작했고 예시코드를 응용하는 법도 익힐 수 있었던 것 같다. 그리고 스택오버플로우에서 가장 먼저 노출되는 게시글외에도 추가로 보다보면 조금 더 마주한 문제상황과 비슷한 경우도 찾을 수 있었던 것 같다.

야생에서 살아남자!!

사수가 있다면 시너지

혼자서도 어느정도는 할 수 있었지만 사수님이 있다면 조금 더 시너지가 나지 않을까 싶었다. 연차가 너~~무 차이나는 시니어분이 사수님이셔서 질문을 드리는데 조금 조심스러웠다. 특히 사수님이 사용하시는 용어가 너무 낯설어서 찾아보며 따라가는 데 벅찼던 것 같다. 연차가 조금 차이나지 않는 사수님이 있다면 조금 더 좋을 것 같다. 그리고 나 스스로도 어려운 개념이나 로직을 쉽게 설명해줄 수 있는 선임이 될 수 있다면 좋을 것 같다.

도메인지식 < 기술에 집중

도메인 자체가 많이 낯설고 로직이 복잡해서 솔직히 중간에 의욕이 떨어졌었다. 그러다 이 문제에 대해서 멘토님과 상의한 결과 이런 경우라면 기술에 집중하는 것도 좋은 방법이라 하셨다. 그래서 생각을 바꾸고 나니 기존 프로젝트에서는 하지못했던 여러 기능들을 구현해야 하는 상황이 재밌었다. 도전적인 상황을 좋아하는 나로서는 새 기능구현을 잘해보기위해 집중을 했더니 프로젝트를 잘 마무리할 수 있었던 것 같다.

이제 취준으로!

취준생딱지를 뗀지 얼마안되어 다시 취준생이 된다는 게 조금 막막하기는 하지만 그래도 이제는 내가 진정으로 하고 싶은 분야고 노력한 것에 대해 결과로 보여줄 수 있는 정직한 분야에서 새로 도전하는거라 설레기도 하는 것 같다. 많은 탈락을 경험하겠지만 매 순간이 양분이 될 것이라 생각한다! 화이팅!!