1. 실습 지원 이유 및 목표
인턴을 지원하기 전 나는 가장 많은 고민의 시간을 보내고 있었다. 앞으로 나의 방향성을 결정할 중요한 시기를 앞두고 대학생활에 대한 정리를 해보았다. 6번의 학기, 몇 개의 공모전과 대회를 경험했지만 나의 방향성을 결정할만한 유의미한 프로젝트는 4개 정도밖에 되지 않았다. 이 경험만으로 "아, 나는 이 프로젝트에서는 이런 분야를 다뤄보았으니 이 분야로 취업을 하면 되겠다."라는 짧은 판단을 하고 싶지 않았고 오히려 학생의 신분일 때 경험할 수 있는 분야를 넓히고 싶었다. 이러한 고민을 하다 내린 결정은 "직접 실무를 경험해야겠다"였다. 실무를 경험하면서 다양한 직무의 사람들이 소통을 하는 방법과 그들의 분야를 느끼고 싶었으며, 막연했던 미래에 대한 고민을 이뤄낼 수 있는 목표로 만들고 싶었다.
실무를 많이 경험하고 싶다고 느낀만큼 인턴을 지원하기 위해 회사를 고르는 시간이 오래 걸렸었다. 회사를 선택할 때의 기준은 세가지였다.
- 회사의 2달 커리큘럼이 체계적인가, 생산적인 일을 배울 것 같은가
- 회사를 다니면서 다양한 경험을 하게 될 것 같은가
- 회사의 홈페이지 내용이나 기사를 봤을 때 발전적인가
이 기준에 모두 해당하는 회사가 바로 'Superb AI' 였다. 회사에 지원을 한 후 코딩테스트와 약 1시간의 면접을 본 후 2달간의 목표가 조금 더 뚜렷해졌다. 면접을 보면서 느낀점은 회사에서는 능동적으로 질문을 하며 일을 해나가는 자세를 원한다는 점이었다. 그러한 자세는 나에게 부족한 부분이었으며 채우고 싶은 부분이었다. 실습 전 나의 목표는 다음과 같았다.
- 회사에서 능동적으로 일을 찾으며 질문할 수 있는 능력 기르기
- 내가 지금까지 해왔던 분야 (데이터 전처리)에서 벗어나 새로운 분야 경험해 보기
- 실질적으로 기록할 수 있는 코드 / 프로젝트 남기기
- 회사 사람들과 대화를 하면서 막연했던 나의 목표를 구체화 시키기
2. 실습 내용
2-1 개발
✨2-1-1. 1주
Superb Ai 회사 측의 배려로 원하는 분야를 선택하여 프로젝트에 합류하기 위해 1주일간 공부하는 시간을 갖게 되었다. 주어진 분야는 총 세가지로
- 리액트를 이용한 프론트엔드 개발
- Django와 Django Rest Framework를 이용한 Restful Api 백엔드 개발
- AWS Chalice 를 이용한 서버리스 백엔드 개발이었다.
1주일의 기간동안 간단한 튜토리얼을 익히면서 Django와 React를 이용한 To-do list를 구현해보았고 Django Rest Framework를 이용하여 User를 구분하여 파일,이미지를 업로드 할 수 있는 웹을 구현하였다. Serverless 환경을 이용해서도 To-do list를 구현해보았다.
이 과정을 통해 배경지식이 전혀 없었던 리액트와 서버리스를 경험해 보았으며 Django에 대한 복습도 할 수 있었다.
이 1주일의 과정을 통해 2달간 참여하고 싶은 분야를 결정했으며 나의 최종 결정은 백엔드 개발이었다.
✨2-1-2. 2주 ~ 3주
2주 단위 Sprint가 시작되는 주이다. 회사의 개발 흐름을 파악하지 못했기에 바로 회사의
Main 개발 흐름에 들어가기 보다는 회사에서 연구해보고 적용해봐야 할 Spike Task에 참여를 하였다. 참여하게 된 Spike Task는 "label view 속도 개선"이다. 현재 도메인에서 데이터를 불러 처리하는데 시간이 오래 걸리기 때문에 이에 대한 해결책 연구가 필요했는데, 그 중 하나가 View 테이블을 만들어 속도 개선을 노리는 연구였다.
해당 Task를 하기 위해 우선 전체 회사 도메인에 대한 설명을 듣고 이를 이해하는 시간을 가졌다. 그 후 회사에서 View 테이블을 사용했을 때 어떠한 이점이 있을 것이고, 어떠한 단점이 있는지에 대한 조사기간을 가졌다. 조사내용은 다음과 같다.
- View의 속도 개선 효과를 볼 수 있는 상황과 방법
- View Table에 Index를 걸었을 때의 장점과 한계점
- Django ORM을 이용하여서 Database View를 생성하는 법
이에 대한 조사가 끝난 후 Django에서 View Table을 만드는 라이브러리를 찾아 View Table을 구현하였다. 구현하기 전에 개발을 위한 환경설정이 필요하였는데, 이 회사는 docker환경에서 django를 띄워 작업을 하기 때문에 이 과정에 대한 습득이 우선적으로 필요했다. 한번도 docker를 다뤄본적 없기에 Docker, Docker-compose, pipenv에 대한 기본 공부를 진행하였다.
그 후 AWS EC2에 ubuntu환경으로 인스턴스를 생성하여 Docker, Docker-compose, pipenv를 설치하고 Dockerfile, docker-compose.yml파일을 작성하여 Docker환경에서 Django를 띄워 작업을 진행하였다.
조사와 개발이 끝난 후 회사사람들과 조사한 내용을 바탕으로 현재 도메인의 어디 부분에 View Table을 설정하는 것이 좋을지, 설정을 한다면 확실한 속도 개선을 일으킬 것인지에 대한 회의를 진행하였다. 결론적으로는 현재 가장 큰 도메인에서 뷰를 설정했을 때 제약조건이 너무 많이 생겼으며 다른 부분에서 뷰 테이블을 설정하기 위해서는 sql 명령어를 한줄 한줄 다 읽으 면서 전체적인 도메인 정리와 함께 진행해야 할 일이라는 결과가 나왔다. 이 작업을 지금부터 한다면 남은 한달 이상으로 진행해야 할 큰 작업이었기에 길지 않은 인턴 기간을 고려하였을 때 다른 Spike task를 추가로 진행하는 것이 좋을 것이라는 판단을 내렸다. 새로운 Spike task는 현재 AWS chalice로작성되어있는 부분을 확장성이 큰 Serverless Framework로 변환하여 진행하는 프로젝트이다.
✨2-1-3. 4주 ~ 5주
새로운 Spike task가 시작되는 주이다. Chalice를 Serverless Framework로 변환해야한다는 의견이 나온 이유는 바로 Chalice의 확장성 문제 때문이다. Chalice는 python 기반 serverless구현 도구로 쉬운 python 사용, 빠른 Lambda 배포, 편리한 IamRole설정이라는 장점이 있으나 다른 Resource를 Chalice로 사용할 수 없다는 단점이 있다. 반면 Serverless Framework는 python은 사용하기 불편하나 다양한 Resource가 사용가능하고 사용할 수 있는 Plugin이 많다는 장점이 있다. Plugin중에서 python의 불편함을 줄여주는 Plugin도 생겼기 때문에 Chalice코드를 Serverless Framework로 변환하는 Task를 진행하게 되었다.
이 작업을 진행하기 위해 Serverless framework의 문법과 작동방식, AWS의 Resource에 대한 개념에 대해서 알아야 했다. 2주 안에 효율적으로 진행하기 위해 Task를 잘게 쪼개서 해야할 목록을 나누었다.
- Chalice, Serverless 비교 분석
- Serverles python requirements Plugin 적용
- Serverless python lambda 작성
- Serverless s3 event trigger 연동
- Serverless sqs, lambda 연동
- Serverless Stepfunction Plugin적용
- Serverless 조사 내용 발표
SQS와 Lambda를 연동하는 경우 Lambda1의 Trigger로 SQS를 연동한 후 Lambda1이 실행되면 SQS에 메시지가 생성되게 한 후 해당 메시지가 Lambda2를 실행시키는 방식의 코드를 구현하였다.
Stepfunction Plugin을 적용할 때에는 지금까지 조사한 것을 합쳐 구현하였다. S3에 .jpg, .txt등 다양한 확장자의 파일이 들어오면 stepfunction을 시작하게 하는 lambda를 호출한다. 그 후 stepfunction이 호출되면 stepfunction내에서 lambda가 s3에 저장된 확장자의 유형을 파악한 후 유형에 따라 다른 lambda를 호출하도록 코드를 구현하였다. 이렇게 코드를 짜면서 다양한 오류를 만나게 되었고, 이를 해결하는 과정에서 Serverless Framework와 AWS Resource에 대한 지식이 많이 쌓이게 되었다.
새로운 방식을 도입하였기 때문에 이에 대한 내용과 코드를 회사 사람들에게 발표 형식으로 공유하는 시간을 가졌다. 그 이후 Q&A도 받아 이에 대한 질문에 답하고, 부족한 조사 부분은 채워서 다시 공유하는 시간을 가졌다.
✨2-1-4. 6주 ~ 7주
원래 계획은 저번주까지 조사했던 내용을 바탕으로 Chalice를 Serverless로 바꾸는 코드를 구현하는 것이었으나 회사 분의 Spike중 Serverless Framework가 필요한 부분이 있어 이번 주와 다음주에는 해당 Spike에 참여하게 되었다. 새로운 Spike는 Kinesis를 활용하여 실시간 Data처리를 하는 Spike이다. 이 Spike가 필요한 이유는 회사 서비스를 사용하는 고객이 프로젝트, 사용자 별 Class의 개수를 실시간으로 파악하고 싶을 때 데이터를 실시간으로 받아 처리하는 기능이 필요하기 때문이다.
Spike의 흐름은 다음과 같다.
[Rawdata producer] -> [Kinesis Stream] -> [Lambda] -> [RDS] <- [Lambda] <- [API G/W]
[Kinesis Stream] -> [Kinesis Firehose] -> [S3]여기에서 내가 맡은 부분은 KCL 파트로 kinesis에 저장된 데이터를 받아와 처리하여 RDS에 저장하는 부분이다. 회사 분과 함께 2주간의 task를 나눈 결과는 다음과 같다.
- RDS 테이블 모델 생성 , 테이블 생성
- KPL 사용방법 숙지
- KCL 사용방법 숙지
- API G/W Interface 정의(RESTful 형태로 정의 or Graphql)
- lambda 로직 작성
- serverless 로직 작성
- RDS에 변형된 데이터 Insert
- lambda local unit test
- 발표 문서 작성
여기에서 내가 맡은 부분은 3, 5, 6, 7, 9(공동) 이었다. 코드 구현은 Github에 회사분과 협업을 하는 방식으로 진행하였다. 가장 시간이 많이 걸린 부분은 5. Lambda 로직을 작성하는 부분이었다. 초기 방식은 json파일을 pandas dataframe으로 변형 후 처리를 하여 다시 json으로 변형하는 순서였으나 이렇게 코드를 짜서 실행시켰을 때 pandas의 특성상 데이터 처리에 걸리는 시간이 길었다. 따라서 json파일을 바로 mysql문으로 처리를 하는 방식으로 다시 구현하였다. 이후 RDS에 변형된 데이터를 넣는 작업을 진행햐였으며 Lambda Local Unit test코드를 짠 후 테스트를 진행하였다.
목표했던 코드를 다 구현한 후 회사분과 함께 준비를 하여 발표 문서를 작성하고 해당 내용을 회사 사람들에게 공유하는 시간을 가졌다. 저번의 발표와는 다르게 이번 발표는 회사 분과 함께 준비를 하였기에 어떻게 준비를 해야 더 발표를 체계적이고 이해가 잘 되게 할 수 있는지 배울 수 있었다. 다음은 발표 준비를 하면서 부족했던 점을 정리한 내용이다.
- 발표 자료를 작성할 때에는 처음 보는 사람이 이해할 수 있을 만큼 상세히 작성.
- 상세히 작성하되 단어와 문장을 짧게 짧게 표현하기.
- 문서 작성시 문서 전체의 모양 고려 ( indent, 들여쓰기, 번호 표기 방법)
발표가 끝난 후에는 원래 계획이었던 Chalice 코드를 Serverless로 변환하기를 이어 진행하였다. 회사 전체 코드를 다 변환하기에는 시간상의 문제가 있었기에 우선 Chalice로 작성된 코드 중 일부분인 Thumbnail부분을 변환하는 것을 목표로 하였다. 회사 Github에 Repository를 만든 후 serverless로 기본적인 틀을 만들었다.(S3 ---> SQS ---> Lambda ---> Stepfunction)
✨2-1-5. 8주
마지막 주차이다. 저번주에 진행했던 Chalice 코드를 Serverless로 변환하는 Spike를 이어 진행하였다.Serverless에서 S3, SQS조건을 선언하였고, Lamda의 내용도 수정하여 채워넣었다. 그 후 회사 사람들이 해당 작업을 파악할 수 있도록 공유문서를 작성하여 Github에 추가하였다. 이 후 해당 내용을 회사 사람들에 공유하는 시간을 가졌다.
이번 주는 두달 간의 인턴이 끝나는 주이기 때문에 2달간 한 작업들, 느낀점들을 요약하여 약 15분간의 발표 시간을 가졌다.
2-2. 운영
2달간 개발 외에 배운 것은 회사의 개발 협업 방식이다. 이 회사의 운영 방식은 Agile한 방식을 띄고 있다. Sprint 단위는 2주인데, 진행을 할 때 우선 Sprint의 마지막주 금요일에 다음 Sprint의 대략적인 계획을 잡는다. 다음 Sprint에 진행해야 할 내용, 해당 내용의 담당자, 참여자가 그 계획에 해당한다.
그 후 다음 Sprint의 첫 월요일에는 계획에 대한 세세한 Task를 잡게 된다. Task의 단위 시간은 1시간,2시간,4시간,8시간이며 개발자 스스로가 본인의 능력을 판단하여 Task의 시간을 잡게 된다.
Sprint가 진행되는 동안 매일 아침마다 개발자가 모여 짧은 Scrum 시간을 갖는다. 이 시간에는 자신이 잡은 Task의 진행도를 공유하고, 현재 개발의 문제점을 공유한다.
개발을 하는 동안에는 조용한 분위기 보다는 문제를 공유하고 토론을 하는 자유로운 분위기가 형성이 된다.
이 회사가 협업하는 방식은 그동안 내가 프로젝트를 진행할 때와는 다르게 체계적이고, 효율적이었다. 나중에 프로젝트를 진행할 때 도입하고 싶은 부분은 크게 세가지이다.
- 본인이 맡고 싶은 개발 부분을 제시한다.
- 제시한 개발에 대한 Task를 스스로 쪼개고 그에 대한 시간도 스스로가 할당한다.
- 개발의 현재 상황과 문제는 실시간으로 공유한다.
Sprint에 들어가서 이러한 방식으로 실제로 일을 진행해본 결과 본인의 일에 대한 책임감도 더 생기고 성취를 했을 때 느끼는 성취감도 더 크게 느껴졌다.
3. 실습 후 회고
3-1. 얻은 것
기존 실습 목표는 위에서 말했다시피 다음 4가지였다.
- 회사에서 능동적으로 일을 찾으며 질문할 수 있는 능력 기르기
- 내가 지금까지 해왔던 분야 (데이터 전처리)에서 벗어나 새로운 분야 경험해 보기
- 실질적으로 기록할 수 있는 코드 / 프로젝트 남기기
- 회사 사람들과 대화를 하면서 막연했던 나의 목표를 구체화 시키기
이번 실습을 통해서 이 목표를 모두 이뤘으며 내가 세운 목표보다 더 많은 것을 배웠다. 회사분들과의 대화 중에 가장 기억에 남는 말은 바로 "스스로를 학생이라 생각하고 학생처럼 행동하지 마라"라는 말이었다. 그 동안 내가 공부해 온 주된 환경은 주어진 상황에서 많은 사람들이 사용한 코드를 배우고 이를 응용하는 방법이었다. 이미 많은 사람들이 연구해 놓은 것을 따라가는 방법으로 공부를 하는 것이 일반적이었기에 새로운 것을 도입하고 이를 공유하는 습관이 몸에 배어있지 않았다. 회사 사람들이 나를 마냥 학생으로 보지 않기를 원하면서 정작 나는 학생 처럼 행동하고 있다는 것을 깨달은 순간 앞으로의 행동의 방향성이 보이게 되었다. 그 이후에는 최대한 이해할 수 있는 것을 이해하고 적용시키려 노력하였으며 순간 순간 "학생이면 이정도면 되지라는 마음으로 일에 임하고 있지 않은가"에 대해서 고민하게 되었다.
하나 더 배운 것은 바로 협업 능력이었다. 그 동안 학교에서 프로젝트를 진행할 때 협업을 하는 방식에 대해 고민이 많았었다. 한 사람에게만 일이 몰리는 경우도 있었고, 목표로 한 일이 기한 내에 끝마치지 못해 계속해서 밀리는 경우도 많았기 때문이다.
마지막으로 새로운 것을 배울 때 효율적인 방법을 배웠다. 실무에서 당장 새로운 기술을 도입하기 위해서는 정확성, 속도 모두 중요하다. 이를 성공하기 위해서는 그냥 앉아서 이론을 오래 보기보다는 일단 코드를 시도해 보는 것이 중요하였다. 넓은 시도 후 부족한 부분이 있다면 해당 부분을 깊게 파는 방식이 빠르다는 것을 느끼게 되었다.
2달간의 실습 기간은 내가 겪었던 방학 중 가장 짧게 느껴지는 방학이었다. 시간이 짧게 느껴진 것은 그만큼 바빴기 때문이기도 하겠지만 2달을 돌아보았을 때 그만큼 재미있는 시간이었기 때문이기도 하다.
Superb AI회사 분들은 인턴이라고 가벼운 일만 주는 것이 아니라 인턴으로 와서 2달간 어떠한 일을 해야 실질적인 도움이 될지를 진지하게 고민해주는 분들 이었다. 그 결과 회사의 가장 큰 개발 흐름에 속하는 일은 아니지만 회사에서 도입해야 하는 새로운 기술에 대한 task를 맡음으로써 주도적으로 task를 진행하는 경험, 새로운 기술과 지식을 배우는 경험을 모두 하게 되었다.
또한 이 회사에서 놀랐던 부분은 바로 '동등한 대우'였다. 실습을 하면서 들을 거라 기대를 하지 않았던 말은 바로 "이 부분에 대해서 어떻게 생각하세요?", "이 부분은 어떻게 진행하는 건가요?"라는 말이었다. 나도 모르게 스스로를 학생이라 생각하여 낮게 보았는데 그 생각이 나의 발전을 막는 생각이었다. 2달의 시간동안 이를 극복하기 위해서 노력하였고 계속해서 생각하고 극복을 해야할 부분이다.
실습을 하는 동안 회사 사람들과 대화를 하며 소통하는 순간이 낯설지만 즐거웠다. 목표하는 일을 끝마칠 때에는 냉철하다가도 의견을 나눌 때에는 밝은 에너지로 대화를 하는 회사였다. 이러한 에너지를 가진 회사에서 일해본 것은 좋은 경험이었다. 첫 실습이었던 만큼 아쉬웠던 점도 많았지만 그에 못지 않게 뿌듯했던 경험, 고마웠던 경험도 많았다. 좋은 회사와 좋은 사람들을 알게 되어 행복했고 이 후 4학년을 보내면서 이번의 경험이 많은 도움이 될 것 같다.
3-2. 아쉬운 점
위 좋았던 점에서 언급하긴 했지만 학생의 틀에서 벗어나는 것, 기존의 공부하던 습관 대신 새로운 습관을 갖추는 것이 끝까지 아쉬웠다.
또 아쉬운 점은 소통 능력이었다. 전체적인 코드를 짜는 속도가 부족하기도 했지만 회사분과의 소통을 빠르게 시도하지 않아서 잘못된 방향으로 코드를 짜느라 헛된 시간을 날린 일이 많았다. 사례들 중에 한가지를 예로 들면 진행하던 코드 중 Input data의 형식이 1개의 column에 2개의 data가 들어오는 형태라 이를 분리하는데 시간을 많이 보낸 작업이 있었다. 코드를 다 짜고 보니 input data가 1개의 column에 1개의 data로 들어오는 형태로 변형되어 있어서 그동안 코드를 짠 시간이 헛수고가 된 일이 있었다. 학교에서는 혼자 고민하고 해결하는 방식의 공부를 많이 했어서 그런지 빠른 공유와 문제 공유가 익숙치 않았는데, 실무에서는 공유할 수 있는 힘이 시간을 절약하는 가장 좋은 방법임을 깨달았다.
마지막으로 아쉬웠던 점은 자료 조사의 미숙함이다. 6주~7주동안 진행했던 Spike의 내용 중 꼭 알아야 했던 내용은 kinesis의 핵심인 kcl문법이었다. 그러나 이 문법을 익히는데 오래걸려 이를 충분히 회사사람들에게 공유를 하지 못하였다. 이 부분은 추후 공부 후 블로그에 업로드를 할 예정이다.
4. 향후 계획
이번 현장 실습을 통해서 내가 다룰 수 있는 분야를 하나 더 넓히게 되었다. 그렇다 해서 이번 현장 실습에서 배운 분야에만 집중해서 파야겠다!' 라는 마음가짐은 아니다. 오히려 내가 다룰 수 있는 무기가 하나 더 늘었으며 앞으로는 그 무기를 갈고 닦음과 동시에 다른 무기도 들어 봐야겠다라는 마음을 먹게 되었다.
2달 간은 AWS의 Resource를 다뤄보았으며 Serverless Framework또한 다뤄보았다. 그러나 AWS Resource를 어떻게 설계해야 가장 효율적인지를 고민해보는 시간은 적었다. 따라서 이 후 에는 계속 AWS의 다양한 기능들을 써보면서 아키텍쳐 설계에 대한 공부와 고민을 해나갈 예정이다.
또한 이번 2달간의 모든 코딩은 python기반으로 진행하였다. 사실 Serverless Framework는 node.js 기반이기 때문에 node.js 코드 자료가 압도적으로 많다. 그러나 node.js문법을 배워본 적이 없기에 자료를 조사할 때나 적용할 때 문법 지식 부족으로 인해 시간이 굉장히 오래걸렸다. 공부를 할 수록 node.js를 배워야 겠다는 생각이 많이 들었으며 인턴이 종료된 이후에는 node.js 코드 공부를 할 예정이다.
