본문으로 건너뛰기

플리지 인턴 후기

위코드 부트캠프에서는 2차 프로젝트가 종료됨과 동시에 위코드 측과 연계된 회사에서 인턴을 진행한다. 1달동안 진행되는 인턴십이지만, 경험하고 느낀 것이 많아 정리하기로 했다.

어떻게 진행되는가?​

위코드에서 진행하는 인턴은 기업 협업이라는 이름으로 2차 프로젝트가 종료되기 전에 시작된다. 먼저 인턴을 원하는 회사의 리스트를 전달받게 되는데 여기에는 기업이 하는 일, 인턴이 하게 될 일, 사용 기술 등이 적혀있다. 수강생들은 그 중에서 3개의 기업을 추려 위코드에 전하고 매칭이 된 기업이 발표되면 차주에 해당 기업으로 출근하여 인턴 생활을 시작한다.

인턴 생활​

나와 같이 협업하게 된 분들은 플리지라는 곳에서 인턴을 시작하게 됐다. 플리지는 번호판을 이용한 SNS를 운영하는 기업으로 인턴 당시에는 해당 서비스의 배포를 준비하고 있었다. 플리지는 디자이너 1명과 개발자 2명(BackEnd, AOS)로 구성되어 있었고 우리들의 역할은 서비스를 위한 웹 사이트와 Admin을 개발하고 배포하는 것이었다.

생각과는 다른 시작​

같이 일할 분들과 인사를 나누고 제품과 개발 방향에 대한 설명을 들었는데... 생각보다 기획단계에서부터 삐긋거림이 보였다. 디자이너분은 UX/UI 경험이 없다시피 했고, 그렇기에 기획 방향은 있으나 어떻게 나아가야 할 지 중구난방인 상태였다. 우리 팀원분들은 모두 IT와 접점이 없는 실무경험을 하신 분들이었음에도 문제가 꽤 크다는 말이 나올 정도였다. 우린 CEO님과 다시 한 번 미팅을 하기로 했고 미팅에서 나의 실무경험을 살려 제품의 문제점을 추려 얘기하였다. 다행이 우리의 의견을 받아들임과 동시에 나에겐 UX/UI 디자인에 대한 상당한 수준의 발언권까지 제공됐다. 그리하여 나의 역할은 2가지가 됐다.

  1. 프론트엔드 개발자로서 팀원들이 구현한 기능의 점검 및 테스트 제품의 배포
  2. 프로덕트 디자이너로서 제품의 경험과 인터페이스를 개선

프론트엔드 개발자로 일하기​

처음 백엔드 개발자 겸 사수님과 얘기했을 때는 배포가 어떤 순서로 이뤄지는지에 대한 지식이 전무하여 시행착오가 많았다. 사수님은 Docker로 배포를 진행할 예정이라고 말씀해주셔서 주말을 이용해 Docker에 대한 개념과 사용 방법을 공부했다. 먼저 작은 프로젝트를 만들어 배포를 혼자서 진행해봤어야 했는데 그렇게 하지 않은 것은 잘못이었다. 1달짜리 인턴이지만 회사의 구성원으로써 더 집중했어야 했는데 너무 안일한 내가 미웠다. 다행이도 친절하신 사수님 덕분에 dockerfile 개념부터 작성까지 천천히 경험해보며 진행할 수 있었다.

dockerfile을 작성하면서 github에 대한 접근권한 설정이라든지, 필요한 의존성의 설치 등 여러가지에 대해 알 수 있었다. 배포방법은 다른 포스트에도 많아 자세히 다루지 않겠지만 내가 경험한 배포 순서를 간단히 정리하자면 아래와 같다.

1. dockerfiledp env-cmd 패키지를 다운로드하는 명령어를 추가
2. package.json의 build에 env-cmd -f ~/.env.dev 명렁어를 추가
3. root에 .env.dev를 생성

이렇게 프론트 테스트 서버가 성공적으로 끝난 줄 알았지만 배포 후 백엔드 개발자님께서 배포 방식이 잘못됨을 언급, S3로 재배포해야 한다고 하셨다. (사실 경험이 없어 어떤 배포 방법이 더 좋은지 알지 못 했고, 이 부분은 전적으로 백엔드 개발자님의 의견을 따르기로 했다.)

S3로의 재배포는 백엔드 개발자님이 미리 배포를 위한 준비를 해주신 상태였고, 나는 준비해둔 bucket에 프로젝트를 업로드만 하면 되는 상태였다. 배포는 프로젝트를 build하면 프로젝트 폴더에 out이라는 폴더가 생기는데 이 때 out 폴더 안에 있는 모든 폴더 및 파일을 업로드해주면 끝이다. Docker로 했을 때보다 더욱 심플했다. 다만 build시 sessionStorage 혹은 localStorage is no defined라는 경고 문구가 뜨면서 build가 되지 않은 문제를 겪을 것이다.

Next.js는 CSR을 실행하기 전에 SSR을 실행하는데, Next.js에서 제공하는 SSR에서는 window나 document와 같은 전역 객체 사용이 불가능하다. 따라서 페이지가 client에 로드되고 전역객체가 정의되기 전까지는 sessionStorage 혹은 localStorage에 접근할 수 없다. 이럴 땐 페이지가 client에 마운트 될 때까지 기다린 후 스토리지에 접근해야 하는데 아래의 방법으로 해결했다.

if (typeof window !== 'undefined') {
  // Perform localStorage action
  const item = localStorage.getItem('key');
}

스토리지를 이용한 코드블럭에 위와 같이 수정 후 빌드하니 이상없이 빌드가 완료되고, 성공적으로 S3에 업로드 할 수 있었다.

프로덕트 디자이너로 일하기​

프론트엔드 개발자의 역할을 수행하면서 간간히 디자이너분과 제품의 경험과 UI에 대해 의견을 나누고 방향을 조정했다. 디자이너분이 UX/UI에 대한 경험이 없었던만큼 디자인된 시안을 보고 레이아웃과 전체적인 균형에 대한 수정, 그리고 개발자로써 각 UI에 대한 자세한 기능과 동작, 상태별 화면에 대해 정리하여 다시 건네는 방식으로 진행했다.

다행인 것은 웹 사이트의 구조는 비교적 간단했고, Admin의 경우 이전 회사에서 근무할 때 기획과 디자인을 해본 경험이 있어 개발 기간에 영향이 가지 않게 진행할 수 있었다. 그러나 진행 도중에 디자이너분이 그만두게 되어 추가적인 UI 개선은 어려웠고, 이를 CEO님과 얘기하여 Admin은 당장 필요한 기능을 제외한 나머지 기능들은 우선 순위에서 내리기로 하였다.

인턴기간은 한정되어 있고 나 또한 이 회사에 개발자로 들어온 것이기에 해당 직무에 더 집중해야 하는 것이 옳다고 생각했지만 한편으로는 내가 만들고 있는 제품이 미완성으로 마무리 되는 것이 아쉬웠다.

후기​

배포를 맡기로 했을 땐 사용하는 플랫폼이나 언어의 특징, 그리고 수많은 오류들이 걱정이 되었다. 그러나 사수님과 함께 Docker로 먼저 배포를 해보며 오류를 맞이하는 것에 대한 두려움이 많이 줄어들었고, 이 또한 나를 성장시킬 수 있는 양분이 된다고 생각하니 오류를 해결하는 것이 진짜 개발자 같이 느껴져 재밌있었다. 하지만 예상했던 것보다 더 많은 오류와 시행착오로 시간이 많이 소요되었다. '프론트엔드니까 배포는 중요하지 않겠지?'라는 마인드로 임했던 과거의 나를 반성하는 계기가 되었다. 그리고 프로덕트 디자이너로써 제품에 기여한 것이 CEO님에게 인상 깊었는지 감사하게도 로켓펀치에 추천사를 남겨주셨다.