겨울방학 동안 스타트업에서 개발 인턴을 한 후기

 나는 학교의 현장실습지원 시스템을 통해, 직원수 5명 이내의 조그만 스타트업 기업에서 겨울방학 2달 간 개발 인턴을 수행했다. 회사측에서 주는 돈은 없이, 학교에서 지원하는 인턴 지원금만 받으며 일을 하고, 많은 걸 느꼈는데 그 점들을 조금이나마 공유하고자 한다.

 

 

 일단 회사는 e-커머스나 타사의 광고대행 등을 맡는 기업이고, 설립한지 1년도 채 되지 않은 신생 스타트업이었다. 직원분들 모두 매우 젊은 분들이었고, 휴게실이나 탕비실은 모두 타 회사들과 공유하는 공유 오피스의 형태였다. 사무실은 넓지는 않았지만 꽤 쾌적했다.

 

 

 하는 업무는 웹 페이지에 구글 애널리틱스와 같은 트래픽 분석 툴을 삽입하고, 이 정보들로 소비자들의 행동 패턴을 분석하는 업무... 라고 인턴 공고 때 봤었다. 사실 이런 업무는 말은 거창해 보이지만 실제론 이미 툴이 다 해주기 때문에, 개발보다는 오히려 마케팅 쪽에 가까운 업무이다. 물론 이 점은 지원할 때부터 알고 있었고, 무언가 그럴듯한 개발 업무를 할 만한 자리는 대부분 취업연계형으로 졸업예정자를 뽑고 있던 지라 그냥 현업만 경험해보고 가자는 느낌으로 지원했다.

 

 

 결과는, 구글 애널리틱스의 'ㄱ' 자도 볼 일이 없었다. 회사에서 타 업체가 사용할 웹 사이트 개발 업무를 수주하게 되어, 나와 다른 SW 인턴 두 분과 함께 해당 사이트 개발 프로젝트를 두 달동안 진행하게 되었다. 정확히 두 달 내내 저 프로젝트를 한 건 아니지만, 거의 80% 이상의 업무가 저 프로젝트와 관련되어 있었으므로 이번 인턴의 메인 프로젝트라 할 수 있겠다.

 

 

1. 수평적인 분위기의 회사

 사실 이건 기성 회사들도 회사마다 다른 점인데, 일단 스타트업은 대부분 수평적인 분위기로 알고 있다. 일단 대체적으로 나이대가 높지 않다 보니 개인주의 문화가 발달되어 있는 편이고, 들어오시는 분들도 거의 젊은 분들이다. 직접 다녀보니 그럴 수밖에 없다. 일단 사원이 매우 적다 보니 인원 한명한명이 여러 가지 역할을 맡게 되고, 딱히 실무진과 경영진이라는 구분이 없다. 그냥 일이 닥쳐오는 대로 다 나눠서 해야 하는 입장이다. 그래서 사원들 간의 업무의 괴리감 같은 것도 없다. 대표와 팀장, 인턴이 한 자리에서 일하며 직접 의견 교환을 해야 하는 환경이라, 개인적으론 직함의 구분이 잘 안 느껴졌다. 물론 상호간 모든 의사소통은 당연히 존대를 사용했다.

 

 

2. 팀플 이상의 실무 프로젝트 경험

 

 일단 이 회사가 SW와 조금 관련이 있긴 하지만, IT 전문 회사가 아니었다. 이번 인턴모집을 담당했던 컴퓨터공학과 출신직원분은 계셨지만 사내에서 수행하는 직무는 개발 업무가 아니었다. 결론적으로, 사내에 개발을 담당하는 전문 인력이 없었다. 그래서 따로 멘토 없이 SW인턴들끼리 이슈를 해결해 나가는 과정이 필요했고, 내가 프로젝트의 팀장 역할을 하게 되어 팀원들 간 업무 분담이나 논의 등을 조율하게 되었고, 나중엔 아예 PM 겸 CTO 역할을 했다.

 

 

 개발 업무는 팀 프로젝트와 거의 유사했다. 주어진 과제를 받고, 학생들끼리 해당 과제에 맞춰 프로그램을 작성하고, 그 내용을 고객사에 발표하는 과정이었다. 나도 방학 프로젝트를 진행하는 느낌으로 다녔다. 하지만 팀 프로젝트와 크게 다른 점이 몇 개 있었다.

 

 

 우선, 일반적인 학교 프로젝트는 정해진 주제에 맞춰 어느 정도 고정된 방식으로 해결하는 과정이라면, 회사에서의 개발 업무는 주제만 정해지고 나머지는 전부 자유로웠다. 오히려, 수단과 방법을 가리지 않고 가장 편하게 만드는게 Best였다. 의뢰받은 사이트의 규모가 크지 않은 데다 웹개발 경험이 적은 사람들이 많다는 걸 고려하여, python을 사용하기로 결정했다.

 

 

 사이트를 제작하면서 기술적인 애로사항이나 모호한 부분에 대한 질문, 비효율적이라고 판단되는 사항은 직접 기획자님과 소통하면서 끊임없이 요구사항을 수정해 나갔다. 이 과정에서 필요하다고 생각하면 과감하게 구글 스프레드시트 등의 개발 외적인 툴을 가져와서 사용했다. 

 

 

 두 번째로, PM 역할을 하게 되면서 느낀 것이, 학교 프로젝트와 달리 개발과 관련이 없는 사람들(기획자 등)과 필히 소통을 할 일이 생기는데, 이 사람들에게 우리의 작업을 일상 언어로 표현하는 화법이 필요 했다. 특히, 최종 발표는 우리의 개발 과정에 대한 어떤 정보도 없이 오직 구현 결과물로만 평가하는 사람들이라서, 우리의 작업물을 단순히 표현하는 걸 넘어 멋있게 포장하는 능력이 필요했다. 

 

 

 여기서 가장 도움이 됐던 게 문서였다. 나는 진행하는 프로젝트에 대해 어느 정도 문서를 정리하는 습관이 있는데, 사람들을 설득할 땐 그냥 줄글보단 수치와 표가 훨씬 효과적이었다. 숫자를 증거로 주장이나 설득을 하니 대부분의 사람들이 납득해 주었다. 글 쓰는 실력을 더 키워야겠다고 생각하게 되었다.

 

 

 마지막으로, 내가 개발한 프로그램을 사람들이 직접 쓴다는 점으로 동기부여가 되었다. 팀프로젝트 같은 경우엔 프로젝트가 종료되면 바로 버려지는 일이 흔한 데, 내가 회사에서 작업한 결과물들은 단순히 발표하기 위핸 프로젝트가 아니라 단 한명일지라도 실제로 사용할 사람들이 존재하는 프로젝트들이었다. 그러다 보니, 유지보수나 관리 등을 위해 로그 작성이나 모듈화에 더욱 신경을 쓰고, 무엇보다도  무급으로 일함에도 프로젝트에 애착이 꽤 많이 갔다. 그래서 더욱 신경쓰며 코드를 작성한 것 같다. 특히 모듈화는 굉장히 많이 도움이 됐는데, 회사 특성상 크롤링을 할 일이 많았고 크롤링 프로그램 제작 요구가 몇 건 있었는데 첫 프로그램 개발 때 직접 작성한 모듈을 인턴 프로그램 내내 사용했다.

 

 

3. 실무 경험

 2번이 개발의 의미에서 실무라면, 여기는 그냥 일반적인 의미의 실무이다. 사내에서 slack이나 notion, asana 같은 업무용 툴을 많이 사용했는데, 각 툴마다 특징이 있다. 저런 툴은 학교 생활할땐 사용해 볼 일이 전혀 없는데, 저 툴들을 사용해 본다는 경험 자체가 굉장히 신선했다. 보통 저런 툴은 사용하더라도 특별한 일 없으면 개인용 무료 버젼을 이용하는데, 회사에서는 기능이 추가된 유료 버젼을 주로 사용하기 때문에 여러 신기한 기능들도 많이 사용해 보았다.

 

 

 e-커머스 회사다 보니 회사에서 네이버 스마트스토어, 쿠팡 등의 쇼핑몰에 제품을 올리고 판매하는 일이 주 업무이다. 크롤링을 위해 이런 쇼핑몰 계정에도 조금 손댈 일이 있었는데, 대충 이런 쇼핑몰들이 어떤 식으로 운영되는 지도 이해하게 되었다. 소소하지만 언젠간 이런 지식도 도움이 될 것 같다.

 

 

 사실 위에서 설명한 대로 직급만 인턴이고 월급을 제외하면 정직원과 거의 동일한 처우를 받고, 담당 업무도 정직원과 비슷했다. 이게 개인적으론 가장 재미있는 경험이었다. 프로젝트 수주 회의에서 요구 사항을 기술적으로 검토하며 문제점을 설명하기도 했고, 기획자님에게 직접 어떠어떠한 자료가 필요하다고 지시도 해 보고, 직접 고객사까지 가서 30분 정도 프레젠테이션(하고 조기퇴근...)까지 해 봤었다. 이런 경험은, 인턴 한명한명도 실무에 바로 투입하는 스타트업이라서 가능했었다고 생각한다. 물론 이러한 일을 하는덴 어느 정도 열정과 약간의 지식이 뒷받침되었기에 가능했다.

 

 

 무급 인턴이라 금전적으론 아무런 보상이 없었지만, 이러한 열정과 성과에 힘입어, 며칠간의 재택 근무(!) 등을 얻어내는 등 인턴으로서 생각할 수 없는 많은 혜택을 받았다. 지금 생각해 보니 사실 이만큼 인턴들도 존중해 주는 분위기라서 열심히 일한게 아닐까 하는 생각도 든다. 

 

 

 그리고, 사람들 고생하는 거 보면서 돈 버는 게 새삼 힘든 일이라고 느꼈다... 사실 이게 가장 중요할지도 모른다.

 

 

 

 

 

4. IT 스타트업이 아니라서...

 

  위에서 말했듯이 멘토가 없이 내가 PM의 역할을 했다. 프로젝트 설계도 내 마음대로 할 수 있었고 실제로 90% 이상의 프로젝트 설계가 내가 생각한 대로 이루어졌다.

 

 

 하지만, 이렇게 진행하면서 무언가 막힐 때마다 항상 "내가 어딘가 잘못한 걸까?" 라는 생각이 끊임없이 머릿속을 맴돌았다. 무슨 에러가 난다는 구글에 검색할 수 있지만, '내가 생각한 이 방법이 옳은가? 더 나은 프로세스는 없는가?' 라는 질문엔 어디서도 답을 찾을 수가 없었다. 멘토가 없다는 점이 여기서 가장 큰 체감이 되었다. 심지어 내가 짜는 코드가 옳은 지도 확신이 안 들었다. 혹시 내가 잘못된 방식으로 매일 코드를 짜다가, 그 방식이 습관이 되어 버리는게 아닐까 하는 불안감도 있었다. 개발 전문 회사가 아니다 보니 딱히 사내 가이드라인 같은 것도 없었고, 오히려 내가 가이드라인을 작성해야 하는 입장이었다.

 

 

 그래도 끊임없이 고민하면서, 최대한 비슷하게 구글에다가도 검색해 보고, 가끔은 아는 선배분들께 조언도 구해보면서 나름대로 최선의 길을 찾으려 노력했다.  

 

 

  또, 개발 관련 회사가 아니기에 당연하겠지만, 처음 회사에 들어왔을 땐 사내에 개발 관련한 어떤 가이드라인도 없었다. 심지어 협업을 할 수 있는 버젼관리 툴도 없었고, 회사에서 사용하는 AWS EC2 인스턴스도 이전 여름 인턴분들이 하고 가신 상태로 방치되어 있었다. 참고로 저 EC2 인스턴스 같은 경우엔 비밀 키마저 잃어버려서 접속이 안 됐고, 반나절동안 비밀 키를 초기화하는 작업을 수행했었다. 그래서 처음 프로젝트를 요청받았을 때, 우선 회사의 github 계정을 만들었고, 그 계정으로 private 레포지토리를 생성하는 가이드라인을 작성하는 게 시작이었다.

 

 

 이렇게 IT 관련 인프라가 전무하다 보니, 프로젝트를 진행할 때 나쁜 의미로 학교 팀플처럼 진행되었다. 새로운 기술들을 사용할 일 없이, 두 달 내내 python과 git이라는 익숙한 기술들만 활용해서 작업하게 되었다. 체계적인 모듈을 활용한 테스트나 상호간 코드 리뷰같은건 엄두도 못 냈다. 물론 내가 이런 걸 하자고 제안하기엔 시간적, 인적 제약도 있고 인턴이라는 위치상 곤란했다. 물론, 이런 것 없이도 프로젝트가 잘 마무리 되었지만, 개발 과정 자체는 그냥 학교 프로젝트를 하나 더 한 느낌에 가까웠다. 무언가 실무 테크닉이나 기술, 업무 문화를 경험해보고자 했던 나한텐 가장 아쉬운 점이었다.

 

 

 

 

 

5. 결론

 

 위 내용을 요약하자면, 다음과 같다.

 

+ 인턴보다는 정직원에 가까운 실무 경험

+ 수평적인 분위기

 

? 다양한 경험. (순수하게 기술만 경험하고 싶은 사람한테는 단점이 될 수도 있다.)

 

- 사내 기술/인프라의 부족

 

 개인적으론 매우 뜻깊고 꽤 재미있는 경험이었다. 회사 사람들도 매우 좋았고 좋은 추억만 남았다. 그렇지만, 여기서 계속 일하고 싶냐고 말하면 대답은 Yes는 아닐 것이다. 나는 아직 초보자이고, 아직 많은 걸 배워야 할 사람이라고 생각하기에 좀더 뛰어난 사람들 밑에서 새로운 걸 배울 수 있는 환경이 좋을 것 같다. 그리고 반드시 SW 관련 회사에 들어가는 게 내 미래를 위해 좋을 것 같다.