한 달 인턴 지원 전, 내가 취업준비 관련하여 고민하던 것
-
백엔드와 소통해서 만든 프로젝트가 없었다는 게 아쉬웠어. baas로만 구현했던 프로젝트가 대부분이어서 현업에서 백엔드와 같이 프로젝트를 완성하기엔 경험이 부족하지 않을까 생각했어.
다른 포지션과의 REST API통신을 하며 겪은 문제나 서로 필요한 데이터가 무엇인 지 주고받으며 기능 구현을 해보고싶었어. 프론트엔드에서 API통신하며 필요한 데이터를 정리할 API설계를 효율적으로 짤 수 있지 않을까 싶었지.
한 달 인턴을 지원하게 된 이유(무엇을 기대하고 지원했는 지)
-
무엇보다 현업에서의 백엔드와의 소통을 대비할 수 있고, 프론트엔드에서 데이터를 사용할 때 편하게 API 통신을 해볼 기회라고 생각했어. 사수분이 계시다면 사수분께 질문을 드리고 답을 얻는 방법을 터득하기에 좋을 거라 생각했고.
한 달 인턴으로 매칭된 회사에서 한 프로젝트/업무
-
센터와 PT트레이너, 고객 간의 필요한 예약, 결제, 관리 서비스를 만들어드리는 프로젝트를 진행하게 됐어. 주요 기능으로는 인증/인가, 예약서비스, 결제서비스, 센터의 고객 예약 관리 서비스로 구성했고 구현하게 됐어.
서비스를 실제로 사용하실 고객님과 소통하면서 요구하시는 주요 기능들을 전부 구현하는 거였어. 추가 기능들은 런칭이후에 고도화 작업에서 사용될 예정이었고.
특히, 클라이언트(고객)님과 직접 대화를 해서 고객님이 원하시는 서비스와 목적, 기능들을 정리하기도 해보고 거기에 필요한 데이터가 뭐가 있는 지 API설계를 했지.
한 달 인턴을 진행하며 가장 크게 배운/얻은 것
-
이번 팀같은 경우, 기업에서 제시한 업무진행 방법은 FFD야. FrontEnd First Develop의 약자인데, 프론트 엔드 포지션을 기준으로 프로젝트 진행을 주도하는 방식이지.
-
첫번째로는 프론트엔드와 백엔드가 서로가 꼭 필요한 데이터가 있는데 그 데이터가 왜 필요한 지 이유를 얘기하고 설득을 해서 데이터를 구성해달라는 얘기가 필요하단 거야. 서로 기능들에 필요한 데이터를 알고있지만 각 포지션별로 꼭 필요한 데이터가 뭔지 모르기 때문이야.
예를 들면, 프론트엔드에선 데이터를 뿌릴 게시글들엔 id들이 필요하잖아. 프론트에서 id를 만들고 프론트에서만 가지고 구별을 하면 소용이 없기도하고, 어차피 백엔드 DB에서 받는 데이터에 uuid를 껴서 보낼 데이터라면 백엔드에 uuid생성도 부탁해서 아예 받을 때 고유 id도 같이 받으면 프론트에서도 데이터를 구별해서 CRUD나 받은 데이터를 뿌릴 때 훨씬 편하니까. 백엔드에서 uuid생성하는 건 어렵지 않거든. 그동안 baas로 사용해서 프로젝트를 구현했다면 그 baas의 기능을 백엔드가 해준다고 보면 돼. 그리고 백엔드에서도 데이터 테이블을 구성하면서 필요한 데이터가 있는데 백엔드 분들과 소통하면서 그 정보도 프론트엔드에서 구성해서 줄 수 있어서 서로에게 도움이 돼.
-
두번째는 프로젝트를 시작하면서 서로 다른 포지션이라도 한 팀에서 프로젝트를 구현하면서 어떤 목적과 목표를 가지고
프로젝트를 완성할 지도 정하면 좋다는 거야. 이게 안 되면, 프로젝트는 흐지부지 되거나 중간에 소통할 때 트러블이 났을때, 서로 난감한 상황이 되고 시간 낭비를 하게 되니까.
예를 들어, 프로세스를 어떻게 할 지, 기획, 회의 시간을 어떻게 분배해서 기능을 구현하고 데이터를 구성할 지와 해당 계획을 이행할 장소를 정하는 거야.
프로세스같은 경우, 클라이언트가 필요로 하는 주요 기능을 먼저 구현하고 클라이언트가 추가로 요구하는 기능을 구현할 지 아니면 시간이 넘쳐나고 필수 기능을 구현하면서 추가 기능을 같이 넣을 필수 기능을 구현을 하고 나서 구현을 하는 가야.
-
세번째는 인증/인가를 포함해서 어떤 데이터를 주고받을 때는 어떻게 줄 지, 어떻게 받을 지, 뭐가 필요한 지 확실하게 소통을 해서 주고받아야한다는 거야.
예를 들어, 인가 기능을 구현하면서 백엔드와 토큰을 어떤 보안방식으로 처리할 지 얘기를 해보고 백엔드에서 어떤 보안방식으로 처리할 것이라 정하면 프론트에선 어떻게 토큰을 받아서 최대한의 보안으로 저장하고 인가를 할 지 로직을 구현하는 거지. 프론트에선 백엔드의 코드를 알 필요없다해서 코드를 몰라도 된다고는 하지만, 토큰을 쿠키로 줄 지 헤더로 줄 지는 알아야 프론트에서 토큰을 어떻게 처리해서 인가를 하고, 토큰 재발급하는 핸들링 또는 에러 핸들링을 할 수 있으니까. 어떤 식으로 데이터를 주고 받을 지 정도는 소통을 할 필요성이 있더라. 안 그럼 어떻게 토큰이 오는 지 모르고 토큰이 어디에 들어서 오는 지 모른 체 구현을 해서 기능이 안 된다 생각할 수 있어.
-
네번째는 앱과 웹에서 받는 데이터나 API통신하는 시점가 다르다는 점을 알게 됐어. 서로 저장하는 방식이 달라서 api요청을 하는 시기가 달랐어. 앱에선 자체적으로 이용하는 저장공간이 있어 탈취되지 어려운 반면 웹에선 간단한 정보를 브라우저 상에 저장하게 되어도 사용자의 데이터가 탈취되기 쉬우니까.
백엔드에서도 어떤 게 보안에 좋은 지 알고 있지만 프론트엔드에 대해서 알고 있는 부분이 한계가 있으니 백엔드에 프론트 엔드에서 필요한 데이터를 얘기할 때, 데이터를 어느 시점에서 어떤 데이터를 받으면 좋을 지 왜 그래야하는 지 잘 설명해줘야 해.
-
다섯번째는 클라이언트분과 디자이너분께는 개발에 관해서 모르시기에 그 점을 고려하고 소통해야한다는 거야. 소통을 할 때 용어를 순화해서 얘기하면서 설명을 드릴 필요가 있어.
개발을 할 때 클라이언트분께서 원하는 기능이 있다면 개발에 있어서 구현 못 하는 건 없다지만 현실적으로 기간 내에 구현하기 어려운 기술을 요구하실 때가 있어. 그럴 땐 개발팀에서 어떠한 이유로 이런 기능을 이런 방향으로 구현되면 어떨 지 클라이언트분과 디자이너분께 설명을 해서 설득을 할 필요성이 있는 것 같아. 무엇보다 고객을 위한 서비스가 제한 기간에 완성을 하려면 그렇게 할 필요성도 있을 것 같아.
이전 프로젝트 때와 달리 이번엔 3~4주 내에 완성하기 어려운 디자인 스코프가 나와서 결국 다들 마지막에 구현하면서 ui의 일부를 빼며 동시에 추가적인 기능을 계속 빼며 필수 기능만 구현했던 것 같아. 이 점은 초기에 다같이 어떤 기능을 우선 구현하고 추가 기능을 언제 구현할 지, 개발 프로세스가 어떻게 될 지 확실히 정하지 못 했던 게 컸다고 생각해. 그렇게 디자이너분께 개발팀이 기능이 어떻게 구현이 되는 지 알려드리거나 설득을 했다면 필요한 ui와 추가적인 ui를 생각하고 같이 만들어 주시지 않았을까싶어.
한달 인턴을 고민하고 있는 사람에게 하고 싶은 말 + 추천하고 싶은 사람
-
배우는 목적에 참여한 인턴일지라도 배우는 건 배우는 거고 서비스 개발은 마감기한을 확실히 지켜야한다고 생각해. 학원에 가서 배우러 간게 아니라 기업에 가서 실제 고객님이 원하는 서비스의 프로토 타입을 만드는 거니까.
실제로 기업에서도 인턴으로 참가하지만 프로라 생각하고 실제 서비스를 사용하는 고객을 위해 우리 인턴 단계에서는 주요 기능만이라도 사용할 수 있는 서비스를 완성해달라고 하셨으니까. 개발 가이드 분들인 개발자분들도 다른 추가적인 기능은 둘째치고 주요 기능을 사용할 수 있고 완성이 되는 게 좋다고 하셨고. 나 또한 필수기능부터 구현하고 추가기능까지 완성해오면서 마감기한에 못 맞춰 완성 못한 서비스는 없었으니까.
주요 기능을 우선 완성하는 게 역시 좋아. 추가 기능까지 같이 구현하려다가 실제 서비스에 사용될 기능들을 기간 내에 완성 못 해서 고객님이 원하는 시기에 서비스를 이용 못 하는 것보단 낫다고 봐. 필수 기능인 주요 기능들 부터 완성하고 나서 추가 기능들을 구현해도 괜찮다고 생각해.
조언을 해주실 사수분이 계시다면 질문하는 것에 있어서 꺼려하지 않았으면 좋겠어. 필요한 요구 사항은 확실하게 근거를 본인이 확실히 궁금해하고 고민하는 점을 파악하고 있다면 정리해서 한 꺼번에 다 물어봐. 부족하다면 사수분께선 원하는 걸 캐치하기 위해 질문 한 두개를 던져주실 것이고 이해에 충족되셨다면 질문에 대한 답을 확실하게 주시니까.
만약 질문드릴 내용이 스스로 잘 파악이 안 됐다면 트러블 슈팅 정리하던 것처럼 어떻게 구현하기 원하는 지, 맞닥들인 문제, 생각하는 원인, 시도한 방법 등으로 정리해서 질문할 때 참고해서 하면 좋은 것 같아. 실제로 그렇게 질문을 드렸을 때 확실하고 명확한 답을 주셨어.
무엇보다, 같이 간 프론트엔드 페어분이 계시면 시도한 방법할 때 같이 고민하는 건 당연한 것 같아! 인턴이니 당연히 서로 배우는 관계고 같이 고민하면서 성장하는 것이라 생각해! 서로가 얘기나눈 해결방법은 뭐든 시도해보면 좋아. 이게 맞나? 아닌 것 같은데?라는 생각에도 일단은 시도해봐서 구현해내는 게 개발자니까. 여태 해왔던 것처럼 시도 안 해보는 것 보단 일단 내가 익힌 지식 혹은 찾은 지식 혹은 엉뚱하더라도 그걸 토대로 모든 방법을 시도해보고 어떤 문제든 해결하는 개발자가 되면 좋은 것 같아. 이게 왜 돼? 할 지 언정 일단 되게 하고 이유를 찾아보는 것도 좋지 않을까. ㅋㅋ 안 해보는 것보단 나으니까. 실제로 내 경우에도 그렇게 해서 못 해결한 문제는 거의 없었고, 그렇게 해서 얻은 지식이나 좋은 코드들도 많이 보고 배울 수 있었으니까.
- 참고 사이트
Frontend First Development
Frontend First Development
www.frontendfirstdevelopment.com