Wecode/Project

Project - 기업과 하는 협업.

청렴결백한 만능 재주꾼 2020. 7. 16. 17:08
반응형

1,2차 프로젝트에 진지하게 목숨 걸고 했었던 개발 세계의 신생아.

험난 할 것 같았던 기업협업을 마치는 날/탯줄 잘리기 하루 전(수료식 하루 전)에 기업 협업에 대해서 블로그를 쓴다. 

 

 

 

기업 협업 가는 과정

2차 프로젝트 막바지에 들어서서 웅성웅성 된다. 분위기가 프로젝트에 집중하기가 힘든 분위기다. 왜냐하면 기업 협업 대상 기업들에 희망 순위를 제출했기 때문이다. 어느 기업이 어쩌고 저쩌고 좋냐 안 좋냐 기술 스택이 무엇이냐 등등 2차 프로젝트는 살짝 뒷전이 된다. 

그룹이 나뉜다. 

혼자 공부 족,

개별 프로젝트 족,

기업협업 족

 

나는 기업협업기업 협업 족이기 때문에 다른 그룹에 대해선 잘 모른다. 기업 협업그룹에서도 또 나뉜다. 바로 이력서 쓰고 기업 협업 나가는 첫 번째 주부터 면접을 보러 다니는 사람, 기업 협업에만 몰두하고 끝나고도 공부를 더할 생각인 부류. 난 이도 저도 아니고 미국으로 돌아가서 취업을 할 요량으로 그냥 회사를 다녔다. 

 

웬만하면 기업협업하면서 이력서를 여기저기 뿌리는 게 좋지 않을까? 위 코드 데이를 이용해서 면접을 보고...

 

운이 좋게도 우리 기수에서 가장 많이 희망했던 아그레아블에 걸렸다. 백엔드 개발자 1명, 프런트엔드 개발자 2명을 구하는 데 내가 백엔드 개발자로서 걸렸다. 마냥 신기했다. 집이 가까워서 꼭 가고 싶었던 회사인데... 떡하니 갈 수 있게 되어서... (나는 일단 출퇴근하는 거리를 굉장히 소중하게 생각함)

 

출근하여 받게 된 프로젝트

프로젝트 개요

Company Name : 아그레아블(wingeat.com)

website: e-commercial

 

웹사이트에 기능 추가

기간 : A month

요구사항 : 

internal website (wingeat-seller) - '셀러'로 지칭    

external website (node-wingeat) - '윙잇'으로 지칭

 

셀러에 "공지사항"과 "FAQ(자주 묻는 질문)" CRUD할 수 있게 만들고

윙 잇에서 공지사항과 FAQ를 get 할 수 있게 하는 것.

 

공지사항은 기존에 있었으나 중요표시를 할 수 있게 하여 중요 표시가 된 것은 윙 잇에서 표시가 될 수 있게 하는 것.

FAQ 같은 경우는 아예 DB설계부터 해야 하는 무에서 유를 창조해야 함. 둘 다 CRUD는 셀러에서 할 수 있게 하고 윙 잇에서는 read/GET만 할 수 있게 하면 됨.

 

개발 환경

셀러 : Meteor.js Node.js 

윙잇 : Express.js Node.js

DB :  MongoDB, Mongoose

 


시작

첫 출근... 어색했다. 회사도 우리를 어색해했다. 개발자들은 원래 그런 것인가 쭈뼛쭈뼛된다. 우리를 어려워하신다(?). 우리도 회사가 어려웠다. 

 

개발팀 구성원은 

개발팀장님

프론트엔드(우연히도 6기 수료생) 1명

UI 디자이너 1명

 

 

그리고 위코드 학생(백엔드 1명, 프런트엔드 2명) 3명.

 

회사생활 한달이 시작된다. 

 

첫날은 개발환경 세팅에 다 쏟아부었다. wow 매우 어려웠다. 그나마 guideline이 잘 되어 있어서 따라 하기 쉬웠는데 진짜 혼자 하라면 못할 것 같은 것들이다. 

 

약 1주 반동안 코드를 엄청나게 봤다. 진짜 봐도봐도 모르겠었고 지금도 모른다. 하지만 봐야 한다. 

javascript도 몰라서 진짜 무슨소리인지 1도 몰랐었다. 너무 답답했다. 하지만 답답해하는 것만이 답이 아니니까 공부했다. javascript repl.it부터 풀고 기초부터 했다. 그리고 웹 프레임워크(meteor)를 공부했다. 튜토리얼 보고 api 만드는 동영상 보면서 따라 하고. 사장되기 직전인 웹 프레임워크라서 자료도 크게 없었고 최신자료가 3~4년 전 자료였다. 그래도 노력에 노력을 하다 보니 눈에 익히게 되고 공지사항의 중요 표시 기능을 만들었다. 

오른쪽에 중요 기능.

중요 표시를 체크하고 넣으면 db에 만들어놓은 document에 들어가게 된다. boolean으로. 그렇게 되어 list view에서는 중요 칸에 O, X가 뜬다. 

 

db에 들어갈 자리 만들고 하면 끝일 줄 알았는데 html도 건드려야 했다. meteor가 풀스택개발용이라서 그런가... 그래서 내가 다했다. 프런트들은 셀러 쪽 거들떠보지도 않았다... 매우 슬펐던 부분.

 

다행히도 meteor에 내장되어 있는 기능들을 활용하면 되어서 내가 css를 직접 만들고 하지는 않았지만 있는 것들을 활용하고 했다. 이게 내가 처음으로 구현시킨 기능이다. 

 

여기서 느낀점은 일단 코드를 보는 기간은 어느 정도로만 보고 (매일매일 많이 많이 보는 건 변함없지만) 코드를 일단 건드려야 한다는 것을 느꼈다. 건들다 보니 좀 더 이해가 되고 진행이 빨라졌던 것 같다. 

 

공지사항은 끝이 났으니 이제 문제는 자주 묻는 질문을 생성하는 것이다. 

 

역시 실제 현업이라서 그런지 제플린이라는 플랫폼에 기획서가 담겨서 왔다. 매우 친절하게 설명이 다 되어있었다.

 

 

 

 

 

대략 저런식으로 보내주셨다. 저걸 보면서  진행을 했다. 여기서는 사이트 클로닝 프로젝트했던 경험이 도움이 되었다. 중간중간 의문점들은 질문하면서 FAQ의 윤곽을 잡아갔다. 

 

프런트들은 어차피 셀러 쪽 건드릴 필요가 없으니까 처음 저 제안서를 받았을 때부터 윙 잇 쪽만 신경 쓰고 레이아웃 잡고 했지만 나는 셀러 쪽만 붙잡고 있었다. 일단 셀러 쪽에서 CRUD가 가능해야지 DB에 뭐라도 들어가고 윙 잇에 뽑아서 던져줄 수 있으니까 마음이 급했다. 셀러 쪽이 되지 않으면 api는 없는 것이었다.

 

 

 

 

 

마음만 급해서는 되는 일이 없다는 것을 알기 때문에 움직였다. 부지런히. 주말에도, 평일 밤에도.. 잘 모르는 언어, 잘 모르는 웹 프레임워크, 잘 모르는 DB를 잘 알고 싶었다. 구현해내냐 안 해내냐 그게 중요한 것이지 얼마나 나에게 어렵냐는 중요하지 않으니까.

 

 

혼자 할 수 있어빌리티를 진정으로 실현했다. 백엔드는 혼자에다가 물어볼 멘토는 없고... 오직 개발팀장님에게만 몇 가지 물어보고 해내었다. 덕분에 감기와 축농증이 와서 아직도 고생 중이긴 한데... 뭐 나을 질병이니까 다행이다.

 

회사의 내부 정보이기 때문에 전체화면으로는 안했다.

일단 왼쪽 제일 하단에 자주 묻는 질문이 셀러에 생겼다. 기쁜 일이다. 물음표는 폰트어썸(프론트에서 알려주심)에서 따왔다. 저런 적절한 아이콘도 붙이고 나름 신경 썼다.

자주묻는 질문 리스트뷰
자주 묻는 질문 - 우선노출여부가 on되어있는 질문만 순서를 정하여 메인창 맨위에 띄울 수 있음.
자주 묻는 질문 create/update하는 창

 


 

 

이렇게 하여 셀러 쪽 끝이 났다. 2주 차 중간쯤이었다. 그래서 2주 반이라는 시간을 가진채 윙잇(express, node.js)에 뛰어들었다. 새로운 프레임워크에 적응을 해야 해서 또 한 번의 고통이 있었다. 

그렇게 만들게 된 5가지 endpoint

서버 구조에서 내가 건드렸던 부분들이다.

 - models: 여기에 데이터베이스 스키마를 설정하고 , loadClass(method)로 해서 'queries'안에 있는 파일을 연결해서 쓴다.

 

 - queries: 여기를 매우 많이 건드렸었는데 마치 장고에서 views.py를 짤 때 위에 필요한 것들을 db에서 불러와 fetch시켜놓는 것처럼 queries도 그렇다. 클래스 밑에 여러 명령어를 넣어서 그 명령어들이 db에서 무엇을 어떻게 들고 와서 가지고 있게 하느냐를 하게 하는 곳이다.

 

 - routes :  api 여기에서 endpoint, 들어오는 것들을 관리한다. 각 앱별로 하나씩 있으며 index.js에서 총괄한다. index에서 엔드포인트를 정해주고 어디로 갈지 정해준다. 일단 여기에서 api내에 앱 파일로 보내서 들어오는 파라미터들을 정리해주고 실행 시킬 서비스들을 정한다. 그리고 api 에 나갈 값들도 정해줄 수 있다.

 

 - services : 여기에서는 각종 api의 구성을 짜는 명령어를 만드는 곳이다. 여기에서 담아서 api내에 앱파일로 보내는 것이다. 아까 queries에서 짠 것들을 여기서 불러서 모은다. 그리고 쿼리 스트링으로 무언가를 받았으면 여기서 전달받아서 같이 queries에 보내서 결과값들을 받아온다.

 

 - vo : value object라고 하셨는데 맞나 모르겠다. 여기는 서비스에서 api의 틀(?)을 짤 때 어떤 식으로 틀이 짜게 될 것인지 정하는 곳이다. 말이 애매한데, mongoDB를 통째로 오지만 틀을 만들어서 필요한 정보만 담겨서 내보낼 수 있게 render를 정하는 곳.

 

 

끝나는 날까지 언급한 파일만 건드려서 5가지 endpoint를 만들었다. 갖가지 필터 기능이나 검색 기능도 넣었지만 ㅎㅎㅎ

 

해내고 나니 뿌듯하고 기분 좋았는데 앞이 보이지 않을 때를 생각하면.... 정말 힘들었다. 

 

사실 몰라서 오래 걸리는 것보다 맞게는 했는데 놓치는 부분들 때문에 오래 걸렸다. 예를 들면 기능을 만들고 어디에 등록을 해야 되는데 등록을 안 해서 안됬다거나 permission을 풀어야 한다거나... 디버깅도 힘든 부분이었다. 익숙하지 않은 환경에서 개발은 정말 쉽지 않았다. 

 

상품 제안하기/제안하기 기능도 하고 싶었는데 이것만 하는데 이렇게 걸리다니... 아쉽다. 다음에 기회가 있다면 아쉽지 않게 제대로 조지리라 다짐한다. 

 

 

 

 


일단 우려하고 걱정했던 그런 기업이 아니어서 좋았다.

코드를 개판으로 쓰고, 깃으로 버전 관리 제대로 안 하며, 최악의 사수에 , 근무환경 안 좋고, 많은 일들을 시킨다거나, 막말은 한다던지 그런 것들은 하나도 없었다. 오히려 배려해주시고 잘해주셔서 미안할 정도였다. 너무 폭풍같이 지나간 4주라서 무엇이 내 머릿속에 들어와 앉아있는지 구분이 안 간다. 사실 내 인생에서 바라보면 지난 3달간 많은 것들을 머릿속에 넣었다. 많은 것을 배웠다. 코딩에 코짜도 제대로 몰랐던 내가 기업 협업 프로젝트를 백엔드로써 무탈히 수행을 했다.  당연히 사람 by사람이라 다 그럴 수 있는 건 아니겠지만 내가 잘했든, 위 코드가 잘 가르쳤든, 어쨌든 내겐 좋은 결과다. 

 

진짜 모르는 것이 많아서 참 걱정인데 이런 식으로 새로운 회사 가서 적응하고 코딩하면 된다는 것을 알게 되어서 두려움이 많이 없어졌다. 빨리 좋은 회사가서 2~3년 경력 쌓고 몸값 올려야지 ㅎㅎ

 

 

- 첨부된 캡처는 회사에 먼저 컨펌을 받은 후 올린 것임-

반응형