이번 2탄은 바로 기업 인턴 2주 차 이후, 필자의 프로젝트 전반에 대한 과정과 소감에 대해 한 번 담아보겠다.

<2주 차>

어떻게 지나갔는 지 모를 정도로 정말 순식간에 흘러가 버린... 한 주!
정말 새로운 프레임워크와 업무 환경에 적응하기도 전에 불어닥친 일 감들에 치였던 한 주였던 것 같은데... 그땐 몰랐다. 한 주 한 주가 지나갈 때마다 더 빨라지는 가속도의 균형계가 깨져가고 있었다는 것을...

1) 작업의 시작.

po 창완님께서 드디어 화요일이 되어서, 질문 문항의 작성을 완료해 주셨다. 고로 필자에게는....

드디어... 일감이 제대로 또 주어진 것이다. 물론 그 전까지 계속 컴포넌트와 더불어 재사용 가능한, 컴포넌트 들을 만들어 왔기에... 계속 작업은 진행해 왔었지만...

일단, 설문 항목은 크게 총 4개 챕터, 13개 질문 문진표 Draft 가 만들어졌다. 이에 따라, 일단 최대한 수요일 회의 전까지 초안만 만들어 갈 것을 생각하고 만들었다.

2) 첫 충돌.

수요일에 다시 우리 팀은 2주 차 주간 회의를 시작했다. 이번 회의에서는 다양한 논의들이 오갔고, 그 중에 가장 핵심 사안은 하나의 섹션에 몇 가지 질문을 정할 지였다.

아! 요즘 보면, 이렇게 하나의 단일 문항으로 하는 게 효과가 좋아보이던데 어떠신가요?

PO 창완님은 최근 트렌드에 맞춰진 단일 문항 서베이 형식을 보여주면서 제안을 하셨다.

음... 제 생각에는 이렇게 하면, 문항이 몇 개 없는 경우에는 효과적이지만 현재의 서베이 문항 구조처럼 문항이 10개를 넘어가는 시점에서는 조금 어려운 구조라고 생각이 됩니다. 기술적인 문제라기보다는, 사용자의 입장에서 다음 버튼을 계속 누르면서 피로도가 누적될 것으로 보여요...

그렇게 필자는 의견을 던졌다. 필자의 의견에 CPO 재민님, 개발 실장인 한솔님까지 모두 동의해 주셨다. 그렇게 창완님의 의견은 조금 보류해 보기로 결정했다. 왜냐하면, 해당 구조가 우리 개발 전체의 구조를 뜯어 고쳐야 할 수도 있기에, 다소 조심스러운 부분이 있었기 때문이다.

3) 합의 사안 도출

그래서 일단, 한 페이지에 5개 문항 수준으로 정리하는 것으로 합의를 도출했다. 한솔님께서 한 챕터에 문항을 모으고 그 안에서 스크롤 하는 방식을 해보는 것을 추천해 주셨다. 그러면서 본인이 얼마 전 공유해 준 스크롤박스 컴포넌트를 활용해서 만들어 보라고 조언해 주셨다. 그렇게 적용하면 헤더와 푸터와 고정된 채로, 안에서 스크롤이 움직이는 방식이라 사용자도 피로도가 적을 것으로 판단되었다.

<추후 스크롤 박스를 적용한 모습>

또한, 체중 설정은 기존에 슬라이더 형식으로 만들었는데, 그 부분은 사용자가 입력하다가 실수하는 등의 우려가 있어서 그냥 단일 텍스트 창에서 입력하는 방식으로 변경했다. 그 외에도 프로그레스 바에 대한 추가,카카오 로그인으로 약관 동의로 약관 페이지 대체 등의 다양한 논의가 이뤄졌다.

4) 새로운 구조에 대한 논의.

물론 위의 논의 사항들 역시 중요한 부분인 것은 사실이다. 하지만, 문제는 따로 있었다. 창완님께서 만들어 주신 문항을 토대로 기획자 분들은 사용자의 입력에 따른 약간은 동적인 요소가 포함이 더 되길 바랐다.
예를 들어, 기타 선택 항목을 눌면, 텍스트 입력이 나오거나, 항목의 답변에 따라 문항이 바뀌는 등의 추가 요소들을 요청했다. 이 부분은 개발자가 구현해야 할 필수적인 사안이라는 판단이 들었다. 하지만, 약간 필자처럼 개발 경험이 적은 입장에서는 제대로 감이 서지 않은 것 역시 사실이었다.

따라서 뎁스를 어떻게 표현할 지에 대한 방법을 찾아야만 했다. 특히 한솔님께서는 개발 시작 단계에서부터 surveyjs라는 사이트이 json 스펙을 활용한 구조를 원하셨다. 이 부분을 어떻게 처리할 지에 대한 새로운 고민을 계속 하기 시작했다.

5) 최종 우선 순위에 대한 정리.

마지막으로 한솔님께서 개발 실장님 답게, 개발 일정에 대한 정리를 해 주셨다. 문진표> 카카오 로그인> 데일리 입력(가장 후순위) 순으로 개발하기로 팀원간의 합의를 이끌어내셨다. 그것을 보고, 이런 생각이 들었다.

역시. 진짜 능숙하고 노련한 개발자는 팀의 개발적인 우선 순위를 분간하고 그에 따라, 일정을 조율할 줄 아는 사람이구나.

6) 구조학 개론.

금요일에 다시 미팅이 잠깐 잡혔지만, 그 이전에 이틀 동안 끙끙댔지만, 뎁스를 통한 프로그래밍 구조에 대한 감을 제대로 잡지 못 했다. 그래서 필자는 이 부분에 대해 한솔님께 dm을 드렸다.

그러면 한 번 같이 논의해 보도록 하죠.

그렇게 해서 나온 구조 변경안. 한솔님께서 서베이 js의 구조를 보면서 직접 회의실 화이트 보드로 현재 필자가 만든 구조 대비해서 새로운 구조 적용안을 설명해 주셨다.
1. 현재 필자의 컴포넌트 구조 파악.

한솔님께서는 현재 컴포넌트 구조에 대해 필자에게 그려보라고 요청하셨다. 크게 현재 컴포넌트 구조는 홈, 어바웃, 피니쉬라는 3단 단계 프로세스였다. 가장 중점적으로 보아야 할 컴포넌트는 about이라는 부분이었는데, 이 부분에서 page1~ page5까지 여러 개의 페이지 단위로 나눠서 해당 컴포넌트를 조건부 랜더링을 먹여서 갈아끼우는 방식이라고 설명했다.

사실 이러다보니 문제가 생기는 점이 바로, 데이터 처리에 대한 고민이었다. 추후에 설문지 문항을 사용자가 입력을 끝낸 뒤에 해당 데이터를 메디스트림 db에 저장 시키는 구조였다. 그러다 보니, 뎁스가 깊어지면 깊어질 수록 해당 컴포넌트에서 계속 프롭과 에밋 처리를 해줘야만 했다. 물론 혹자는 그러면 vuex를 쓰면 되지 않냐고 반문할 수도 있다.

하지만, 그것은 일단 여러 가지 문제가 걸려 있어서 쉽게 도입이 어려웠다.

첫 번째, 현재 회사는 부분적으로만 vuex를 도입하고 있다. 따라서 회사에서 추후 다른 코드들과 호환성 측면에서 맞지 않을 수 있다.
두 번째, 현재 프로젝트 단계에서는 그렇게 큰 단위가 아니기에 전역 상태 관리를 쓰는 것이 오히려 복잡성을 더 초래할 수도 있다.

이런 여러 가지를 생각해 볼 때, 최대한 구조를 단순화 시킬 수 있다면 단순화 시키는 것이 좋다는 결론이 났다. 그래서 필자와 한솔님은 구조에 대해 한 번 다시 논의해 봤다.

자~ 음...그러면 그냥 단순하게 이렇게 가는 것은 어떨까요?

그는 내게 이렇게 구조에 대해 정리를 해 주셨다. 즉, 정리하자면, 지금처럼 about페이지 안에서 컴포넌트를 쪼개놓았는데, 그것을 하나의 페이지로 통합시키자고 했다. 그래서 about이라는 페이지 하나에는 각 유형의 질문 컴포넌트들만 존재하고, 그것 들에 대해서 v-for와 v-if를 통해 하나의 컴포넌트 안에서 조건부 랜더링을 처리해 준다. 이렇게 되면 굳이, survey-> page-> 개별 문항 컴포넌트 까지 깊이에서 survey-> 개별 문항으로 줄어든다. 이를 통해 처리한 데이터 들은 survey쪽으로 emit 처리해서 합쳐주면 편리하다.

결론적으로 필자역시 이 구조가 훨씬 안정적이고, 단순화되어 더 좋다는 것에 동의했고, 이번 주에는 해당 부분에 대한 구조를 적용하도록 코드를 다시 리 팩토링하기로 했다.

<3주 차>

진짜 이제 딱 남은 2주. 개발에 박차를 가해야할 때. 수요일 주간 회의에서 갑작스럽게 기획에도 추가 사항들이 나왔고, 이에 대해서 한 번 논의가 필요한 시점이 왔다.

1) 이제 마무리를 해야할 때.

기획 측에서는 몇 가지 추가 및 수정 사항 반영이 가능한 지에 대한 의문을 던졌다.

하지만, 이 부분을 전부 수용하기에는 좀 어려웠다. 왜냐하면, 필자는 다음 주 목요일까지 인턴 기간이 끝나기에... 그날 배포한다고 하면, 현실적인 시간이 부족했다. 특히 프론트 전담을 혼자하고 있는 이 상황에서는 더욱... 그래서 일단 한솔님과 상의 후 해당 사항에 대해서는 팀원들과 협의해서 어느 정도 타협이 필요했다. 그 내용을 요약하자면, 다음과 같았다.

1. 기획 질문사항
   • 한 질문에 여러 답변 가능한지?
     → Multiple Text 유형으로 해결 가능
   • Question에 이미지 추가 가능한지?
     → description 필드 활용하는 방법 연구해보겠음
   • 기존 답변 내용 동적 재활용 가능한지? - 답변 불러와서 설명 추가 (모든 보기를 기타로 처리)
     → 난이도 있을거 같다. 나중에

2) 개발 우선순위

주요 비즈니스 로직이 한 차례 완성되어 다음 주에 MVP 를 돌려볼 수 있게 해야 한다. 그러려면 새로운 폼 유형 대응, UI 디테일이나 이팩트 등은 후순위로 해야 함. 현재 Required 대응, Logic 랜더링 부분까지 완성도가 높지 않기 때문에 이번 주에는 이 부분까지 해서 입력폼 부분에 대한 불확실성을 모두 해결하고, 금요일이나 다음 주에 API 붙이는 작업 진행. 오늘 나온 논의내용 포함해서 이후에 추가된 내용은 추후 상황봐서 대응 여부 결정하자.

이렇게 논의에 대한 합의점이 정해졌고, 일단 필자는 현재 개발 중인 초기 json 형식으로 개발을 진행하고 mvp가 될 수 있도록 조건부 랜더링이나, 리콰이어드 대응과 데이터 축적 방식에 대한 로직 등을 짜기로 했다.

3) 쉽지만은 않았던 조건부 랜더링.

참고로 이전에 언급한 about은 새롭게 이름을 Survey.vue로 바꿨고, Questionpage.vue라는 단일 컴포넌트 하나로 전체 페이지를 통합시켰다.

사실 조건부 랜더링에 대해서 생각보다 난항을 겪었다.

이게 전체 항목에 대해서, json 파일의 데이터를 활용해서 v-if 조건 문을 활용해야 했다. 특히, 현재 코드 전문을 공개할 수는 없지만, 해당 데이터의 조건문을 담은 메서드를 통해서 랜더링 자체가 어떤 특정 값의 유무로 나눴다. 이게 생각보다, 조건이나 메서드 등을 처리하는 것에서 꽤나 까다로웠다. 생각해 보면, 엄청 어려웠다기보다는 생소함에서 오는 어려움이었다. 이후에 선배 주변 개발자 분들께 질의를 드리면서 이 부분을 해결할 수 있었다. 이를 통해 내가 어떤 부분을 놓치고 있는 지, 방향성을 짚어볼 수 있었다.

특히, 다양한 조건에 따라 설문 문항이 달라지는 조건부 랜더링 부분은 vue 개발자 도구를 통해서 살펴보니 데이터 흐름을 파악할 수 있었다. 대표적으로 여성이나 남성의 조건에 따라 설문 문항이 달라지는 부분의 처리가 단순히 해당 컴포넌트에서 처리해서는 안 된다는 것을 알 수 있었다. 즉,위의 사진처럼 서베이라는 부모 컴포넌트에서 해당 값의 조건부 랜더링 데이터를 가지고 있어야만 다음 페이지에서 역시 랜더링이 걸린다는 것을 깨달았다. 이 데이터가 결국 자식 컴포넌트에 프롭으로 내려지면서 해당 데이터를 통해 조건부 랜더링을 걸어줄 수가 있었다.

4) 새로운 도구의 사용 figma.

3주 차에는 전직 디자이너 출신인 CPO 재민님께서 피그마를 통해 디자인을 완성해 주셨다. 피그마는 처음 사용해 봤는데, 현업에서 디자이너와 협업할 때 피그마를 통해 협업을 많이 한다고 전해 들었다. 난생 처음 써 봤지만, 생각보다 사용법도 간편했고, 기본적인 css 속성이나 자료들을 바로 export할 수 있어서 너무 좋은 도구라는 생각이 들었다.

5)vuetify의 다양한 속성들에 대한 적응.
이번 프로젝트에서 한솔님의 권장으로 vuetify의 사용법을 익히면서 많은 부분 적용해 봤다. 디자인 프레임워크(?)는 처음 사용 해봤는데, 생각보다 굉장히 기능도 많고 다양한 디자인 패턴들이 있어서 커스텀하기에 좋은 기술이라는 생각이었다. 하지만, 뭔가 제대로 알지 못한 채로 쓴다면 또 버그나 다양한 대응이 힘들겠다는 생각도 들었다. 한솔님께서도 무조건적인 뷰티 파이 사용은 지양하지만, 이번 프로젝트의 경우 간단한 디자인이라 사용해도 되겠다고 판단하셔서 결정하셨다고 했다.

어떤 기술을 사용함에 대한 결정은 누구나 할 수 있지만, 그 결정에 대한 책임의 범위는 누구나가 될 수 없다.

< 3주 차 ~ 4주 차>

이번에는 3주 차와 4주 차 배포까지 일련의 과정에 대한 이야기다.
3주 차에는 이제 바로 다음 주 mvp 배포를 위해 달리는 시기로 두고, 엄청나게 변화되지 않는 선에서 마무리 짓는 쪽으로 가닥을 잡았다. 더욱이, 아직 데이터 처리라던지 조건부 랜더링 등에 대한 것과 디테일 적인 ui 작업 처리도 끝나지 않았기에... 추가적인 작업은 최대한 배제했다. 그렇게 3주 차 중반 부 이후에는 거의 ui는 완성이 되었고, 이제 남은 작업은 유저가 입력하는 서베이 데이터 입력 값에 대한 처리와 백엔드 경우님께서 만들어 주신 api와의 연동 처리가 핵심 과업이 되었다.

1) 전체 데이터 처리에 대한 고민.

앞서 설명했던 것처럼, 이번 프로젝트는 사실 프론트에서 데이터 처리를 어떻게 할 것인지에 대한 고민을 정말 많이 했었다.

흔히들 생각하기에, 프론트엔드 개발자가 ui와 같은 겉으로 보이는 것을 개발하는 개발자라고 생각하기 쉽다.

하지만, 필자의 생각에 프론트 개발자는 진정한 프론트 개발자는 ui를 잘 만들어서 사용자의 사용 만족도를 최대한 올리는 것만큼이나, 백엔드에서 데이터를 받아와서 그것을 다시 처리해 주는 지에 대한 역할도 중요하다고 본다.

왜냐하면, 결국 그 모든 것들이 성능 최적화나 다양한 관점에서 볼 때, 사용자의 경험에도 영향을 미치기 때문이다.

서론이 길었는데, 결국 그래서 이번 프로젝트에서도 설문 서베이를 통해 얻게된 사용자에 대한 데이터를 db에 저장시켜야 할 지에 대한 고민에서 시작되었다.

2) 풀리지 않던 수수께끼.

기본적인 골격 구조는 가장 최상단의 부모 컴포넌트인 Survey.vue에서 데이터를 관리한다. 이 데이터를 자식 컴포넌트인 QuestionPage로 내려줘서 이벤트 동작을 통해 바뀌어진 값을 다시 emit을 통해 서베이의 데이터에 저장시키는 구조로 큰 틀을 잡고 코딩을 했다.

대부분의 데이터들을 그 방식대로 잘 담겼다.

스토어라는 객체에 담겨지는 데이터를 확인할 수 있다.

하지만, 체크 박스와 같은 다중 선택지의 경우 쉽지 않았다. 특히 다중 선택의 형태가 배열 형태로 담기는 구조였는데, 아무리 해도 에밋 처리가 되어서 저장이 되지만, 계속 이상하게 값이 제대로 들어가지 않았다.

처음에는 v-model을 사용하지 않고, 바인드와 벨류를 통해 단방향 바인딩 처리만 했다. 하지만, 이내 이렇게 될 경우, 자식 컴포넌트 내에서 만든 데이터에 지속적으로 푸쉬를 해줘야만 했다. 또한, 가장 큰 문제는 포문으로 해당 선택지들이 처리가 되다 보니, 각 항목에 어떤 값들이 들어오는 것인지 구분이 되지 않았다. 그에 따라, 데이터에 저장되는 값들 역시 데이터 배열을 공유하게 되었다. 즉, 따로 항목마다 값이 구분되어야만 하는데... 그것이 아니라 하나로 합쳐지면서 적층이 되는 구조였다.

이유가 뭘 지에 대한 고민을 며칠 내내 하다가 결국에는 금요일까지 풀지 못했다. 마치 벽에 막힌 느낌이었지만, 포기할 수는 없었다.

이 구조를 풀어야 이후에 db에 저장하는 것 역시 가능했기 때문이다. 결국 답답한 마음에, 한솔님께 이 부분에 대한 질의를 드렸다.

3) 애초에 잘못된 컴포넌트 구조....

필자는 그간의 상황과 시도에 대한 설명을 드렸고, 코드를 보여드렸다. 그러자, 그가 바로...

음... 애초에 이거 컴포넌트 구조가 잘못 짜여진 것 같네요...

한솔님은 필자의 코드를 보더니, 바로 이런 지적을 했다. 그랬다. 애초에 필자는 구조 논의에서 잘못된 방향으로 컴포넌트 구조를 짠 것이다. 원래 한솔님의 의도는 survey => questionpage => 선택지 항목 컴포넌트들 이런 식으로 나눠서 구조를 만드는 것 이었다. 하지만, 필자는 단순히 survey=> questionpage의 식으로 컴포넌트 구조를 만들었다. 즉, 선택지 항목들도 애초에 컴포넌트화 시켜서 캡슐화를 시키지 않고 풀어 써 버린 것이다.

그 결과, v-model과 같은 양방향 바인딩이 제대로 먹히지 않았다. 부모 컴포넌트에서 v-model을 통해서 처리한 데이터를 자식 컴포넌트에 프롭으로 내려준다면 이렇게 구분 없이 섞이지 않았을 것이었다.

그래서 시간 관계상, 현재 구조를 다 갈아 엎을 수는 없었기 때문에, 필자는 일단 현재 구조를 유지한 상태에서 데이터 처리를 할 수 있는 방식을 선택했다.

이처럼, 인덱스의 해당 메서드를 처리할 때 분기 조건을 달아서 구분을 해줬다. 즉, 스토어라는 객체에 담긴 키 값의 이름이 같을 경우에만 실행하는 것으로 설정한다. 분기 조건으로는 선택되는 선택지의 값이 그 스토어라는 객체에 인덱스 값이 없는 경우에만 값을 넣고 그외에는 빼버리는 splice를 썼다.

이게 좋은 방식은 절대 아니지만, 현재 상황과, 구조에서는 최선의 선택이었다.

이를 계기로 잘못된 소통으로 인한, 잘못된 구조가 결국에는 최악의 결과를 도출할 수 있으며, 이미 돌이키기엔 돌아갈 수 없는 강을 건너는 것과 같다는 것을 깨달았다. 이제부터는 항상 로직이나 컴포넌트 구조를 짤 때에도 큰 그림을 그리고 코드를 짜는 법을 항상 염두에 두어야겠다.

4) api연동과 CORS & stackoverflow

api 같은 경우, 필자가 데이터 처리에 시간 소비를 너무 많이 한 나머지 배포 전 날인 수요일에 할 수밖에 없었다. 먼저, 데이터를 불러오는 api부터 한 번 테스트 삼아 콘솔을 찍어봤다. 하지만, 갑자기 CORS 에러가 떴다.

필자만 그런 것이 아니라, 한솔님도 똑같이 나오셨던 것 같다. 그래서 스레드로 경우님께 전달해 드렸고, 이후에는 경우님과 dm으로 해당 사항에 대해 논의를 주고 받았다.

아! 참고로 백엔드 담당이신 경우님께서는 현재 미국에서 유학중이셔서 한국과 시차가 꽤 많이 났었다. 그래도 다행히 수요일은 선거일이라 휴무라서 간신히 시차를 맞출 수 있었고, 최대한 빨리 api 연동을 해야만 하는 제약적인 상황이었다.

처음에는 cors 문제인 줄 알고, vue.config 파일에서 proxy 설정을 계속 만졌다. 하지만, 이번에는 cors 에러가 아닌 status code가 500이 나오는 것이 아닌가... 일단, 위의 상황에서 경우님께서 ajax 통신으로 한 코드를 주시길래 이 때는 잘 통신이 되었다.

그렇지만, 여전히 axios를 이용한 코드는 404에 이어 500이 떴다.
그래서 하도 이상해서 이 문제가 아니겠다는 생각에 구글링을 계속 해 봤다. 그러다 문득, 진리의 stackoverflow의 글을 발견하게 되는데...

이 부분에서 헤더의 값을 설정하지 말고 요청을 해보라는 답을 발견했고, 진짜로 빼고서는 보내봤더니, 200ok가 떴다.

이후에는 포스트로 데이터를 처리하는 과정 역시 백엔드의 경우님이 데이터를 받는 구조가 약간 달라서 일부 수정을 했다.

그에 따라 재빨리 헤더에 담기는 값들의 보내는 형식을 수정하고 처리해서 데이터를 db에 저장하는 것까지 정상 작동하는 것을 확인할 수가 있었다.

5) 과정은 똑같지만 처리가 달랐던 카카오 로그인.

다음 과정은 우리 프로젝트의 중요한 선결 과제인 카카오 로그인이다. 사실 처음에는 기존에 다른 프로젝트에서 리액트 상에서만 구현을 해봤던 터라... vue는 좀 다르지 않을까라고 생각했었다.

하지만, 실상은 그다지 다를 것은 없었다. 결국 카카오에 요청해서 받아오고 그걸 백에서 처리하는 과정은 동일하다는 생각이 들었다. 그래서 일단, restapi 구조로 카카오 로그인을 구성해 봤다.

그런데 구현 중에 뭔가 막히기 시작했다. 즉, 인가코드까지는 잘 받아오지만, 이후에 백엔드 서버와의 통신이 문제가 생겼다. 그래서 급한 마음에 백엔드에서 설정해 준 부분을 경우님께 dm드려봤다. 그는 내게

민수님 구현 과정이 어떻게 되는 지 알려주시면 알 수 있을 것 같습니다.

그래서 필자는 당연히 기존 카카오 로그인처럼 인가코드를 받고, redirect 페이지에서 카카오 서버와 통신후 토큰을 받아서 백엔드에 전달할 예정이라고 말씀드렸다. 그랬더니,

그랬다. 결론적으로 기업에서는 보안상의 이유로 굳이 프론트에서 처리하지 않는다고 했다. 그걸 모르고 계속 백에 카카오 토큰을 날렸으니, 될 리가 없었다. 이후에 다시 요청하신대로 코드 값만 넘기고 응답으로 자체 토큰을 발급을 바로 해주는 로직을 짰다.

그런데 앞선, 포스트처럼 payload에 구조가 달리 담겨서 구조를 다시 짜서 넘겨줬다. 그랬는데, 갑자기 또 412가 나왔다. 이건 경우님 말씀으로는 카카오가 인가코드를 재사용하지 못 하게 막은 것이라고 하셔서 카카오 로그인을 다시 처음부터 해 봤더니 잘 되었다.

추가적으로 경우님께서, 쿠키에 셋팅까지 잘 되는 지 확인해 보라고 하셔서 이 부분까지 확인을 하고 최종적으로 api 통신은 다 붙일 수 있었다.

6) 아쉽지만 배포는...

사실 여기까지 과정을 지나오면서, 원래는 한솔님께서 파이프라인을 연결해서 바로 배포 가능한 환경 구축을 약속하셨지만, 안타깝게도 업무가 과중하셔서 그것까지는 못 하셨다고 토로 하셨다. 그래서 어쩔 수 없이 간단하게 로컬 테스트만 해봤다. 다행히도 로컬 상에서는 문제 없이 잘 되는 것을 확인할 수 있었다.

휴~ 배포까지 이뤄졌다면 더 좋았겠지만, 그래도 나름 소기의 성과를 이뤄낼 수 있어서 뿌듯했다.

< 기업 인턴십 최종 소감 및 마무리>

1. 첫 느낌.

사실 혼자라는 생각에 두려움과 걱정이 컸던 것은 사실이었다. 하지만, 생각보다 이전 기수 선배분들과 선배 동료 개발자분들께서 잘 대해 주셨다. 또 염치불구하지만, 수많은 질문을 드리면서 많이 배우고 단단해 지는 과정을 겪었다.

2. 기업 협업을 통해 배운 것들

1) 소통의 문제.

이번 기업 협업의 가장 큰 수확이 이 부분이라고 생각한다. 특히 기존에 기획자나 디자이너 등과 협업해 볼 기회가 없었는데, 이번 기회를 통해 경험할 수 있었다. 하나의 사안을 두고 기획자가 요구하는 사항과 개발자가 컷해야하는 상황에 대해 많은 부분을 직접 몸소 느끼고 배울 수 있었다.

2) 일정 관리의 능력.

사실 혼자서 이번 프로젝트 일정 관리를 했으면 못 했을 것 같다. 개발 실장이신 한솔님께서 이 부분에 대해서 계속 체크해 주시면서 기획자 분들과 전반적인 조율을 해주셨기에 금일 배포에도 일정에 차질이 없었다.

3) 큰 그림을 보는 능력.

개발자가 코딩만 잘하는 것. 물론 중요하다. 하지만, 본인이 만든 코드의 유지 보수나 재사용 가능성에 대한 것들에 대해 볼 줄 아는 능력 역시 중요하다는 것을 더 뼈저리게 느꼈다. 사실 이번 프로젝트 말미에서야 내 스스로의 프로젝트 구조가 잘못된 것을 알게 되었다. 시간 관계상 현재는 이 부분을 다 뜯어고쳐야 했기에... 포기할 수밖에 없었다.

4) 혼자만의 생존법

이미 많은 도움을 받기는 했지만, 그래도 사실 이번 프로젝트는 같이 협업하는 개발자 없이 프론트는 나 혼자만 전담했기에... 직접적으로 누군가와 같이 문제 해결하기에는 좀 어려웠다. 결론적으로는 혼자만의 생존법을 찾아야만 했다. 이때 검색과 수많은 공식문서, 스택 오버 플로우를 통해서 충분히 해결할 수 있었다. 이를 토대로 정말 혼자 살기 위해서는 무엇을 잘 해야하는 지에 대해 좀 많이 배운 것 같다.

3. 협업을 마친 시점에서

사실 처음부터 기업에 오퍼를 기대하고 간 것이 아니었기에, 오퍼가 있든 없든 크게 신경은 쓰이지 않았다. 물론 오퍼가 있었다면 더 좋았겠지만, 모든 채용은 상황에 따라 변수가 많기에.. 그럼에도 불구하고 정말 좋았다. 한 달간, 스타트업이 어떤 곳인지. 그리고 개발자들이 어떻게 일하고 협업하고 생활하는 지에 대한 전반을 익힐 수 있었다. 이 부분을 통해 나는 어떤 개발 문화를 가진 회사에 적합하고, 향후 취업 시장에 뛰어들었을 때 회사 선택의 기준점을 체득한 것 같다.

결과야 어찌되었건, 클론 코딩을 넘어서 이제는, 무에서 유를 창조해서 기획에 맞춰 새로운 제품을 만드는 경험은 어딜 가서도 못 할 경험이라고 생각한다.

개발 커리어 시작에서 귀중한 1달을 값지게 보낸 것 같다.