HyperConnect 인턴 생활과 개발기

2018-08-05

logo

Intro


하이퍼커넥트에 인턴으로 생활한지 벌써 한달이라는 시간이 지나간다.

지난 한달간의 인턴생활 회고와 남은 한달의 기간을 어떻게 보낼지에 대한 생각을 정리하려 한다.

(절대 회사에서 시켜 쓰는거임)

HyperConnect


사실 하이퍼커넥트가 어떠한 회사이고, 어떤 서비스를 하는지도 모르고 여름인턴에 지원 했다.

친한 동생에게 처음 하이퍼커넥트라는 회사에 대해서 알게 되었고 그 동생의 추천으로 카페에가서 30분만에 지원했다. (앞으로는 최소한의 준비는 해야겠다고 생각된다.)

지원서를 제출한지 한 시간쯤 지났을 무렵 하이퍼커넥트에서 전화면접 안내 전화가 왔다.

이때 빠르고 박력있는 채용 프로세스를 통해서 하이퍼커넥트라는 회사에 큰 호감을 느꼈다.

이후 전화면접을 무려 1시간동안 쉬지않고 봤는데 쏟아지는 질문 세례에 정신을 못차렸던 기억이 난다.

wa

궁금한점에 대해서 질문을 해달라고 하셔서 면접 결과를 언제 받아볼 수 있냐고 물어봤더니

당일 결과가 나온다고 하셔서 고민없이 광탈이라고 생각했다.

good

근데 붙음 뿌-듯

항상 느끼는 거지만 면접을 보게 된 직후에는 급격한 현자타임과 자괴감으로 인해 만사가 귀찮아 지지만, 이 자극을 이용하면 스스로를 발전시키는 원동력이 되는것 같다.

Hyper-X


빠르고 박력있는 채용 프로세스에 의해 합격소식을 받고 바로 다음주 부터 출근을 하게 되었다.

power

처음 입사지원을 할 때 아자르팀에 지원을 했지만 회사측에서 HyperX가 더 잘 맞는 포지션이라고 팀을 옮겨주었는데 지금 생각해보면 인사팀은 엄청난 혜안을 가지고 있는것 같다.

사실 뭐하는 팀인지도 몰랐는데 와서 보니 이곳은 헤븐.

HyperX를 나타내는 말은 많지만 내가 와서 직접 느낀 HyperX는 스타트업 속에 또다른 스타트업이다.

아자르라는 이미 어느정도의 궤도에 진입한 서비스가 있지만 만족하지 않고 새로운것을 도전하는 팀이라고 생각한다.

기술 스택에 대한 제한도 전혀없고 개발자가 하고싶은데로 하면 된다.

너무 많은 자유가 주어졌기 때문에 수동적인 성향을 가지고 있는 사람이 HyperX에 오게 된다면 힘들 수 있을 것 같지만 능동적이고 스스로 쟁취하는 성격을 갖고 있다면 HyperX의 많은 장점을 느낄 수 있을거라는 생각이 든다.

예를 들면 일반 학부생 또는 이제 개발을 업으로 삼을 비기너 개발자들은 서비스를 어떻게 만들지에 집중하게 되는데 HyperX에서는 어떻게에서 조금 더 근본적으로 들어가 무엇을 만들지에도 집중할 수 있게 된다. 물론 이 부분에서 극심한 고통을 느끼기도 하지만 다른 곳에서 쉽게 경험할 수 없는 값진 고통이다.

그리고 가장 중요한 초기 설계부터 배포/운영까지 모든 프로세스를 겪을 수 있다는 점이 개발자로서 최고의 장점이 아닐까 싶다.

사실 나는 이전까지 서비스를 출시해본적은 많지만 실제로 운영까지 해본적은 없어서 이 부분이 매력적으로 느껴졌다.

trap

운영을 위한 개발 툴(?)도 개발해야 된다는 것은 함정

Cell


HyperX의 또 다른 특징으로는 클라이언트 개발자와 백엔드 개발자 두 명이서 셀을 구성하게 된다.

(PM 또는 디자이너 분들은 공용 리소스로서 요청시에 투입이 되는 형식!!)

현재 내가 포함된 Cell6까지 총 6개의 셀이 존재한다.

올해 10개의 셀을 운영하는게 목표라고 하고 하는데 다음달에 내가 사라지면 Cell6 도 사라지겠지 ㅎㅎㅎㅎㅎ

문화


그룹런치

살아가는데있어서 가장 중요한건 먹는게 아닐까 싶다. (먹고 살기 위해 일하는것이기도 하니까)

하이퍼커넥트에는 한달에 두번씩 사내 직원들끼리 랜덤으로 팀을 맺어 점심 식사를 하는 ‘그룹런치’ 가 존재한다.

이전 회사에서는 같은 팀원들 끼리만 식사를 해서 다른 팀은 정확히 어떤 일들을 하는지 그리고 어떤 고충을

가지고 있는지 알 수 없었는데, 그룹 런치를 통해 다른 팀에 있는 분들과 이야기를 할 수 있었고 그 덕분에

회사에서 어떻게 운영이 되는지 다른 팀에서는 어떤식으로 협업을 하는지 알 수 있었다.

Engineer’s Meetup

주기적으로 하이퍼커넥트의 개발자들이 모여서 발표(?)를 하는 자리인데, 무려 피자가 제공 된다.

다른 팀 개발자분들이 새로운 기술을 사용해 토이프로젝트를 진행했던 경험이나, WWDC 또는 구글 I/O 같이 해외 컨퍼런스에 다녀온 경험을 발표기도 했다.

나도 발표 잘 할 수있는데, 보내 주면 좋겠다.

Dev Intern Seminar

여름 인턴을 대상으로 다양한 세미나가 열렸다. 개발 분야에 제한없이 열렸기 때문에, 백엔드를 개발 하는 나도 스위프트, 코틀린에 대한 세미나도 참여했다.

가장 기억에 남는 세미나는 쉽게 접하지 못할 디자인분들의 세미나였는데, ‘디자이너에게 1px이란?’ 세미나와 UX 리서치에 대한 세미나였다.

개발자로서 생각하지 못했던 그리고 디자인은 주관적인 분야라고 생각했던 나에게, 디자인의 논리적인 결과 도출 과정을 보면서 스스로를 되돌아 보고 논리적이지 못한 나를 반성했다.

ddong

나는 이었다.

수박 파뤼

여름 인턴기간동안 총 3번의 이 있었다.

무슨 복이냐 하면 초복, 중복, 말복이다. 어떻게 보면 개노답 삼형제처럼 보이기도 하지만

덕분에 무더운 더위속에 수박을 다같이 즐기며 대화할 수 있는 시간을 마련해준 고마운 개노답들이다.

그래서 한달동안 무엇을 했고, 무엇을 배웠나

지난 시간동안 내가 무엇을 했고, 무엇을 배웠나를 말하기 전에 내가 인턴 기간동안 무엇을 목표로 했는지를 먼저 정리를 해야 한다.

첫 번째로 나는 인턴 기간 동안 자신감을 찾고 싶었다.

구체적으로 말하자면, 나는 개발을 업으로 삼을 수 있는지에 대한 확신과 자신감을 찾고 싶었다.

뒤 늦게 IT 분야에 관심이 생겨 다니던 학교를 자퇴하고, 1년 넘는 수험생활을 거쳐 CS를 전공하고 졸업하기 까지의 이야기로는 내가 진정 개발을 좋아하는지, 그리고 업으로 삼아도 후회가 없을지에 대한 확신과 자신감을 주기엔 부족했다.

두 번째, 항상 해 왔던 개발이 아닌 무언가를 새로 도전하고 배우고 싶었다.

지금까지 해왔던 기술 스택을 벗어나 새로운 언어와 기술을 배우고 활용하고 싶었다. 익숙해진 언어와 프레임워크를 사용 한다는건 그 만큼 퍼포먼스가 보장(그래 봤자 퍼포먼스 별로 안나오지만) 되지만, 비기너 개발자 로서 언어와 프레임워크를 고집한다는건 득보단 실이 많은 선택이라고 생각했다. 특히, 최근에 들어서 비슷한 개발만 해오니 기술적 정체가 아닌지 의심이 들기도 했다.

개발


위에 말한 2번째 이유 때문에 기존의 Node.js + Express의 스택을 버리고 백엔드의 구성은 Kotlin + Spring Boot를 생각했다.

요즘 가장 핫한 스택이기도하고 한번쯤 스프링을 해보고 싶긴했었는데, 개발 기간이 짧았기에 새로운걸 배울 시간이 없어서 쿨하게 포기했다.

drawing

사실 책까지 샀는데… 환경세팅까지 했는데… 초기설정까지 했는데…

결국 가장 익숙한 Nodejs를 선택했는데, 이전과 다른 차이가 있다면 이번 프로젝트에서는 ORM을 사용하고, 테스트코드와 CI/CD를 최대한 활용하려했다.

현재 개발을 진행 하면서 Nodejs ORM 라이브러리인 Sequelize를 도입해서 사용중이고 TestCode 작성은 mocha, chai, supertest를 사용해서 작성하고 있다.

앞으로 CircleCI와 도커를 사용해서 CI/CD를 도입할 에정이다.

현재 겪고 있는 수 많은 문제중 하나는 Sequelize의 트랜잭션인데, Sequelize의 문제라기 보다는 초기 구조 설계를 할때 생각을 너무 대충한 것 같다.

현재 프로젝트의 구조는 스키마를 정의하는 Model과 Model을 바라보는 Service 그리고 Service들을 조합하여 호출하는 Controller로 구성되어 있다.

이 구조의 단점은 컨트롤러가 뚱뚱해지면서 비지니스 로직까지 품고 있게 된다는 단점이 있다. 해결 방법으로는 컨트롤러와 서비스 사이의 하나의 레이어를 더 두고 비즈니스 로직을 새로운 레이어에 넣는 방법이 가장 현실적인 해결 방법이라고 생각한다. 하지만 이 방법은 서비스가 커질 수록 관리해야할게 많아진다는 단점을 가지고 있기도 하다.

또 다른 궁금즘은 module 패턴과 namespace였는데, 함수로 네임스페이스를 만들어 모듈화 한다거나 또는 함수 자체를 모듈화 하는 여러가지 방법의 차이점이 궁금했다.

협업

개발을 제외한 다른 인력들은 모두 HyperX의 ‘공용 리소스’ 이다. 내가 속한 Cell 뿐만 아니라 다른 Cell에서도 디자인 팀의 인력과 PM 팀의 인력을 사용하기 때문에 필요한 리소스가 있다면 적절한 시점에 요청하는게 쉽지가 않았다.

개인적으로 웹프론트팀에서 인턴생활을 하면서 디자인팀, 기획팀, 백엔드팀을 돌아다니며 몸으로 협업을 체험했기에 큰 무리가 없을줄 알았는데, HyperX의 협업은 더 힘들었던것 같다.

Cell 자체가 인턴 두명으로 이루어져있고, 그 누구도 우리에게 신경을 써주지 못했기 때문에 서비스를 기획하는 초기에는 정말 많은 문제가 있었다.

서비스 초기에 하루에 3~4번은 아이디어가 엎어지고 피봇되는 과정에서 디자인팀과 PM팀에 실시간으로 정보를 공유하는게 쉽지 않았다. 그리고 어느 정도까지 공유를 해줘야하는지도 몰랐기 때문에 큰 사고를 치기도 했다.

결론


유난히도 더웠던 2018년의 7월과 8월을 하이퍼커넥트에서 겪은 것은 ‘실패’ 다.

아마 HyperX에서 가질 수 있는 가장 큰 경험과 교훈은 ‘실패’가 아닐까 싶다.

HyperX 였기 때문에, 그리고 HyperX 덕분에 ‘실패’에 대한 의미를 재정의하게 된것 같다. 그리고 단지 의미없는 실패가 아닌 의미 있는 ‘실패’였기 때문에 더욱 값진것 같다.

현재 시점으로 아직 인턴 기간이 끝나지 않았기 때문에 앞으로 내가 목표로 했던 것들을 모두 이뤘을지 아직은 알 수 없지만, 지금 상태라면 어느 정도의 성취는 이룰 수 있지 않을까 싶다.

인턴이 끝나고 하이퍼커넥트로 리턴하거나 다른 회사에서 일을하게 되어도 2018년 여름의 하이퍼커넥트는 좋은 의미로 그리고 나쁜 의미로 쉽게 잊혀지지 않을거 같다.