엔코아 데이터 엔지니어링 부트캠프 수료 기념 총 회고

2023년 6월 7일의 무더운 여름에 시작해 서먹서먹하기만 했던 약 스무 명의 수강생들은 어느덧 공기도 차가운 12월 7일에 파이널 프로젝트 발표를 하고 수료를 하면서 6개월의 긴 여정을 마무리했습니다. 참 쉽지 않았지만 재밌는 경험이었다고 생각합니다. 원래대로라면 그 감정이 가시기 전에 회고를 적는 것이 맞겠으나... 이력서 첨삭이니 행정 처리니 다른 사이드 프로젝트 기획이니 바쁜 일이 많아서 지금 간략하게나마 적어보려고 합니다.

수강했던 과목들에 대하여

데이터 엔지니어 직무는 다른 직무와는 조금 결이 다른 느낌이었습니다. 코드의 생산/머신러닝 또는 딥러닝 모델의 빌드/모델의 서빙(서비스로의 탑재)/배포 및 유지 보수/그리고 지금까지 말한 요소들의 자동화 등을 한 눈에 파악할 수 있어야 하는 직무여야 했기 때문이죠. 그래서 연구실에서 있을 적 데이터를 대략적으로 파악하고 EDA 열화판 딥러닝 모델에 넣고 학습시켜서 예측을 해내는 과정까지만 했던 저로서는 어느 순간 다른 세상이 펼쳐지는 것 같은 느낌을 받았습니다. 대략적인 교과 과정을 정리하면서 다시 짚고 가자면...

1. 파이썬 기본 (+ 약간의 SQL 쿼리)
2. 머신러닝 및 딥러닝(기초 모델부터 pre-trained 모델의 전이 학습까지)
3. 자바 기본 + 스프링 부트
4. 리눅스(우분투) + 도커 + AWS 배포 + 빅데이터 분석 툴(하둡, 스파크 등)
5. 프로그램 배포 및 유지/보수 실전

이 중에서 제가 그나마 익숙했던 부분은 2번에 해당하는 부분이었습니다. 좀 더 정확히 말하자면, 연구실에서 CNN(합성곱 신경망)까지만 다뤄봤기 때문에 사실상 RNN과 전이 학습으로 넘어가면 이미 거기서부터 새로운 세계였다고 보는 게 맞겠네요.
정말 제대로 피를 봤던 부분은 백엔드를 처음 맛 본 스프링 부트 파트였다고 생각합니다. 예제 하나 따라가기 버거웠을 정도로 낯선 파트였습니다. 더군다나 컴공과 등에서 이미 이 과정을 맛본 몇몇 전공생들과 달리 저는 이 부분에 대한 정보 자체를 처음 접했기 때문에 더더욱 그랬던 것 같습니다.
차라리 리눅스 부분은 조금 나았다고 보는 게 맞을 것 같습니다. 왜냐하면 딥러닝을 접하기 이전부터 연구실에서 우분투 터미널을 조금 만져본 적이 있었고, 그래서 어느 정도는 CLI 환경에서의 명령어와 작업을 알고 있었기 때문이죠. 물론 그 직후 도커 컨테이너와 이미지를 만지다가 다시 한 번 피를 보기는 했습니다만 이 부분은 다들 어려워 했기 때문에 예전만큼의 부담감은 없었던 것으로 기억됩니다.
가장 마지막에 (파이널 프로젝트 직전에) 배운 프로그램 배포와 유지/보수 또한 저로서는 새로운 내용이었지만, 오히려 이 부분은 큰 부담없이 정말 재밌게 들었습니다. 왜냐하면 지금까지 배웠던 내용들을 조금씩 복습하듯 적용할 수 있었고, 미숙하게나마 직접 만든 프로그램을 세상에 공개한다는 것이 코드의 작성과는 또다른 재미를 주었기 때문입니다. 여기에 깃허브의 풀 리퀘스트 기능을 활용한 협업 스킬도 배우면서 실무에서는 이렇게 일하는구나하는 것을 어렴풋이 알아갈 수 있던 것도 좋았습니다.

물론 가장 마지막에 가서 쿠버네티스 실습하려고 설치한 minikube가 뒤통수를 후려치긴 했습니다

네 번의 프로젝트 - 네 번의 성공, 네 번의 좌절

일부 과정은 과정이 끝날 즈음해서 짧게는 5일, 길게는 1주일 정도의 미니 프로젝트 기간을 가졌습니다. 이론과 예제만으로 기술을 습득하는 것은 한계가 분명하기 때문에 실제로 수강생들로 하여금 자신이 원하는 것을 만들어보면서 체득하게 하기 위함이었겠죠. 수료를 마친 저도 이러한 의도에 백번 공감합니다. 특히 백엔드 파트는 직접 만들면서 배우는 것이 정말 많았던 부분이라고 생각될 정도고요. 하지만 결과를 만들기까지의 과정을 가까이에서 지켜보면 몇몇 프로젝트에서는 크고 작은 좌절로 점철되어 있는 적이 많았습니다. 파이널 프로젝트가 아니라 미니 프로젝트 단계였음에도 불구하고요.

파이썬 기본 - Streamlit을 이용한 미세먼지 정보 제공 프로젝트

처음 배운 파이썬 기본에서는 우리가 파이썬으로 만든 것을 어떻게 서비스로 만들 것인지에 대한 가장 기본적인 프로젝트를 진행했습니다. 이 당시에는 아직 백엔드에 대한 지식을 갖지 않은 상태였기 때문에 streamlit을 이용해 지도, 탭 등을 구현하는 기본적인 방법을 배운 후 각 조별로 원하는 정보를 게시하도록 했습니다. 저희 조는 서울시의 각 구 별로 미세먼지 농도를 얻어온 후에 이를 지도에 표시하는 사이트를 만들었습니다.
기능 구현 자체에서는 큰 어려움이 없었고 로컬 환경에서도 원하는 기능이 모두 구동되는 것까지 확인했습니다. 그런데 외부에서도 접속할 수 있는 사이트를 만들기 위해 배포를 하고 나니 이게 왠걸, 일부 기능 한정으로 각종 에러가 발생하면서 원하는 이미지가 출력되지 않는 문제가 있었습니다. 이유인 즉, streamlit을 일반에 공개하기 위해 작업 폴더를 깃허브 리포지터리에 커밋한 후 기능을 실행하면, streamlit 서버에서 이를 웹 사이트 형태로 빌드하는 과정에서 각종 라이브러리(넘파이, 판다스 등)을 호환성에 문제가 없는 선에서 최신 버전을 import해서 사용하기 때문이었습니다. 로컬 환경에서 빌드할 때는 아나콘다 3.9 버전을 기준으로 라이브러리를 설치했기 때문에 streamlit 배포 버전에서 빌드를 할 때와 라이브러리 버전이 달라져 있었고, 이에 따라 몇몇 기능이 수정되어 있었습니다. 이에 맞게 코드를 일부 수정하고 나니 정상적으로 배포가 이루어졌던 기억이 납니다.
돌이켜보면 가장 간단한 형태의 배포를 실습해볼 수 있었던 미니 프로젝트라고 생각됩니다. 이것이 배포라고 직접 언급하지는 않았지만 내가 만든 서비스를 사람들에게 직접 보여줄 수 있는 재미를 일찍이 느껴볼 수 있었지만, 다른 면으로 보면 프로그램의 개발 뿐만 아니라 배포 과정에서 이런 문제가 생길 수도 있다는 것을 넌지시 암시하는 경험이었습니다. 이 경험을 조금 더 무겁게 받아들였다면, 향후 프로젝트의 배포에서 조금이라도 피를 덜 볼 수 있지 않았을까 싶은 마음이 드네요. 암울한 복선

스프링 부트 백엔드 - 네이버 웹툰 리뷰 공유 프로젝트

백엔드 프로젝트는 자바 기반 웹 프레임워크인 스프링 부트(Spring Boot)를 이용해 웹 사이트를 만들어보는 프로젝트였습니다. 이번에 편성된 저희 조는 네이버 웹툰에서 당시 서비스 중이었던 모든 웹툰의 데이터를 수집한 후, 기존의 사이트에서도 확인할 수 있던 요일별/인기도 순/태그별 분류 기능을 포함해 각 웹툰에 대한 리뷰를 작성한 후 이를 통합적으로 공유 및 열람할 수 있는 리뷰 사이트를 만들었습니다. DB를 구성할 때 각 작품의 작가, 인기도 등의 정보를 저장하는 테이블을 하나 마련하고, 사용자가 작성한 리뷰를 저장하는 테이블을 별도로 생성했습니다. 리뷰의 작성과 열람은 각 웹툰 작품에 대한 조회 및 전체 웹툰에 대한 리뷰 통합 조회가 가능합니다. 이 중, 개별 작품에 대한 리뷰만 묶어서 조회할 때는 각 작품의 상세 페이지에서 조회 가능하고, 통합 조회는 별도로 구현한 리뷰게시판 페이지를 통해 가능하도록 구현했습니다. 그리고 이 두 가지 유형의 리뷰 조회 방식을 구현하는 것이 본 프로젝트에서의 제 역할이었습니다(DB 테이블 생성은 다른 조원 분께서 수고해주셨습니다).
개인적인 감상을 적자면, 저에게 있어서는 파이널 프로젝트 이상으로 큰 어려움을 겪었던 프로젝트입니다. 첫 번째로 백엔드의 개념은 제가 지금까지 경험해 온 머신러닝/딥러닝 기반의 코딩과는 성격이 많이 달랐습니다. 어떻게 보면 스크립트 파일의 코드를 순서대로 실행하기만 하면 데이터의 전처리와 모델 훈련, 결과 예측 및 시각화까지 선형적으로 진행되는 머신러닝 영역과는 달리, 백엔드는 적게는 10여 개, 많게는 수십/수백 개의 스크립트 파일이 여러 폴더에 나뉘어 저장되고 이렇게 작성된 폴더와 스크립트, 여기에 데이터를 저장해놓은 데이터베이스까지, 모든 구성 요소가 유기적으로 연결되면서 요청과 응답을 실시간으로 주고받는 구조였습니다. 전공자들과 경험자들에게는 크고 작은 경험을 통해 익숙한 구조였겠지만, 웹 프로그래밍 자체가 처음이었던 저로서는 이러한 구조 간의 유기적인 설계가 너무 큰 벽으로 다가왔고, 이 때문에 제가 맡은 파트의 구현이 상대적으로 시간이 오래 걸렸습니다. 그리고 이것이 두 번째 이유로 이어지는데, 각자 자신의 백엔드 파트를 어느 정도 마무리하고 프론트엔드 파트로 넘어가 사이트를 꾸미기 시작하는 와중에 가장 기초적인 기능조차 구현하지 못한다는 마음에 크게 위축되었습니다. 결국 주말 중에 늦게나마 팀원들과 같은 반의 다른 조 수강생들에게 도움을 요청해 간신히 기능을 구현해 주 서비스에 통합할 수 있었습니다.
결과적으로 이 프로젝트는 저에게 두 가지 큰 교훈을 남겼습니다. 그리고 이 교훈은 남은 미니 프로젝트와 파이널 프로젝트를 넘어서 개발을 하는 사람의 사고 방식과 일하는 방법을 잡아가는 데 도움이 되었습니다.

1. 내가 생각하는 것보다 개발의 세계는 아주 넓고 복잡하다. 조금 더 많은 요소를 유기적으로 연결하는 생각과 설계를 연습하자.
2. 도움을 구하는 것을 주저하지 마라. 혼자 끙끙대다가 팀의 발목을 잡으면 그것이 팀에게 있어서 더욱 큰 손해다.

빅데이터 핸들링 - 2020년 주가 예측 프로젝트, 제주 버스 EDA 프로젝트

이때부터는 파이널 프로젝트를 위한 조를 먼저 편성해서 5명으로 구성된 조를 먼저 짰습니다. 그리고 이 조 그대로 수업에서 배운 기술을 활용해 인사이트를 도출하는 간단한 프로젝트 두 가지를 진행했습니다. 다만, 이번 두 프로젝트는 서비스의 배포에 목적이 있는 것 같지는 않았습니다. 오히려 빅데이터 분석 툴을 사용해 데이터를 분석하고 인사이트를 도출하는, 데이터 분석가의 업무에 가까운 실습이었던 것 같습니다. 제주 버스 EDA는 엘라스틱서치를 이용해 EDA를 실습해보는 과정이라 딱히 설명할 부분이 많지 않으니 여기서는 주가 예측 프로젝트를 위주로 설명을 해보죠.
주식에 한 번이라도 투자해 보셨다면 아시겠지만, 주식 투자는 원하는 종목의 현재 및 과거의 주가 데이터 뿐만 아니라 그 기업에 대한 사전조사가 매우 중요합니다. 고수들은 흔히 재무재표를 보면서 그 기업이 이득을 봤는지, 좀 더 자세하게 파고들어가면 그 기업의 이득이 순수한 성과를 기반으로 얻은 이득인지 아니면 직원을 해고하거나 자산을 매각해서 얻은 이득인지 등을 자세히 알아봐야 합니다. 이번 프로젝트에서도 각 조가 제공받은 데이터는 2019년부터 2020년 3월까지의 주가 데이터와 재무재표 데이터를 제공받았습니다. 이러한 데이터를 판다스 등으로 뜯어본 후에 투자할 종목을 결정하고, 매매 타이밍을 정하는 것이 프로젝트의 목적입니다. 다만, 기본적인 SQL 수준에서도 수행할 수 있는 데이터 양과는 다르게 빅데이터를 다룬다는 가정 하에 하둡과 하이브 사용을 조금 얹었다는 것이 일반적인 주가 프로젝트와의 차이점이라 할 수 있겠네요.
종목 선정에는 재무재표 데이터의 도움을 받았습니다. 과거 특정 기간 내에서 단일 기업의 데이터가 아니라 그 기업이 속해 있는 산업 분야 전체의 인사이트를 얻는 것이 향후 이득을 볼 수 있는 유망한 종목을 선정하는 기준이 되었는데, 종목 전체의 변동성이 100%를 넘어가는 불안정한 종목은 아무리 실제 이득이 컸다고 해도 투자 종목에서 배제하는 방향으로 가닥을 잡았습니다. 변동성이 큰 게임 등의 종목을 선택했다고 해서 이번 프로젝트에서 그 종목 중 가장 큰 성장을 거둔 기업에 투자한다고 하면 그건 이미 답을 알고 있는 상황에서 시험을 치르는 것이나 다름 없다고 판단했고, 이는 실제 주식 투자와는 거리가 멀기 때문입니다.

저를 포함한 조원들 중 주식 투자자들이 현실 투자에서 이를 고려하지 않았다가 피를 본 경험이 있었기에...

이러한 기준을 바탕으로 세 가지 개별적인 종목에서 가장 성장을 많이 한 기업을 한 곳 씩 선정하여 주식 관련 차트를 그려서 거래 타이밍을 선정했습니다. 저희는 이번 프로젝트에서 볼린저 밴드(Bollinger band), MACD, 스토캐스틱(실제 제공받은 자료에서의 이름은 스토캐스틱이 아니었지만 계산 공식과 차트 경향성이 매우 유사해 편의상 스토캐스틱으로 지칭합니다)의 세 가지 차트를 바탕으로 투자 타이밍을 정했습니다.
이러한 워크플로우의 수립이 잘 체득되어 파이널 프로젝트까지 잘 이어졌다면 좋았겠지만, 아쉽게도 저희의 경험 부족으로 인해 거기까지 이어지지는 못했습니다. 다만, 데이터 분석이 어떤 방식이 이루어지는지에 대한 간단한 이해, 그리고 특정 분야의 도메인 지식과 접근법을 얻는다는 점에서는 특히 주식 투자자들에게는 도움이 되었던 프로젝트였습니다.

마지막 시련 - 파이널 프로젝트

파이널 프로젝트에서는 미니 프로젝트보다 인원이 늘어나 5명 ~ 6명씩 조를 꾸렸고, 총 세 개의 조가 각자의 주제에 맞는 데이터 수집과 분석, 그리고 이를 이용한 서비스의 제작 및 구현까지 해내는 총집편이라고 볼 수 있었습니다. 각 조마다 멘토님이 한 명씩 배정되어 프로젝트를 도와주셨습니다.
저희 조는 사용자가 원하는 여행 테마를 담고 있는 검색어, 정확히는 특정 단어나 문장을 입력받아 그에 해당하는 여행 코스를 추천하는 서비스를 제작했습니다. 입력받은 문장에서 여행 테마에 해당하는 단어를 추출해 자연어를 다루는 머신러닝 모델의 일종인 tf-idf 모델을 훈련시키고 이와 유사도가 가장 여행지를 다섯 곳 선정합니다. 가장 유사도가 높은 곳을 첫 번째 방문지로 설정하고, 거기서부터 시작해 최단 거리를 계산한 후 이를 기준으로 여행 경로를 짜서 구글 맵 API에 표시합니다. 같은 방식으로 여행지뿐만 아니라 맛집도 다섯 곳을 선정해 경로를 얻을 수 있습니다. 또한, 각 여행지와 맛집을 클릭해 상세 페이지로 가면 각 스폿의 상세 정보를 확인할 수 있고 팝업 창을 통해 해당 스폿의 지도를 구글 맵 API로 확인할 수 있습니다.

프로젝트 중 문제점

사실 이 프로젝트는 시작부터 난항을 겪었습니다. 한 달이라는 기간이 사실 그렇게 긴 기간이 아니었기 때문에 데이터를 선정하고 수집하는 것도 갈피를 잡지 못하고 우왕좌왕했을 뿐더러, 마음만 급해서 EDA를 통해 데이터의 퀄리티를 분석하고 검증하는 과정이 부족했습니다. 여기에만 1주일을 허비하다 보니 길을 잃었다는 자체 진단이 나왔고, 결국 아키텍쳐와 데이터 플로우부터 확실하게 정립해야 한다는 멘토님의 조언에 따라 사용할 기술 스택과 데이터 구조부터 정립했습니다.
또한, 어떤 머신러닝 모델을 사용할 지 결정하는 것도 문제였습니다. 사용자의 편의성을 증대하는 차원에서 검색어를 직접 입력해 그에 따른 추천 여행지를 전달하려면 필연적으로 자연어 처리(NLP) 모델이 필요했는데, 앞서 설명한 것처럼 저희가 머신러닝/딥러닝 파트에서 배운 내용 중에 NLP 모델이 없었습니다. 게다가 대부분의 NLP 모델을 참고할 수 있는 허깅페이스(HuggingFace)에서 모델을 가져오려고 해도 파인 튜닝을 어떻게 해야 할 지 감을 제대로 잡을 수 없었습니다. 결국 지금 우리의 숙련도가 낮고 이를 메꾸기 위해 자체적인 학습을 하는 데 시간이 너무 많이 소모됨을 고려해서 사이킷런(Scikit-learn)에 기본적으로 탑재된 tf-idf 모델을 사용하는 것으로 선회했습니다. 이후의 백엔드 구현과 FastAPI로의 모델 탑재, 에어플로우를 이용한 데이터 수집 및 모델 재학습 자동화가 큰 어려움이 없었음에도 불구하고 시간 상 빡빡하게 진행된 것을 돌이켜보면, 첫 단추에 해당하는 EDA와 모델 선정이 얼마나 중요한 지를 뼈저리게 느낄 수 있었습니다.
이렇듯 난항을 겪으면서 기능 구현에만 급급했던 부분이 있었고, 그래서 최종 발표 당시에도 기존의 여행 추천 서비스와 다른 점을 잘 모르겠다는 지적을 받았습니다. 재화나 서비스란 소비자의 필요에 의해 만들어지는 것이고 특히 그런 니즈를 충족시키지 못하는 부분을 제작했어야 할 뿐더러, 만약 그런 서비스가 이미 있다면 아직 해결되지 않은 문제점을 다듬고 개선된 기능을 제공할 수 있어야 했습니다. 추후 취업을 해 업무를 맡거나 다른 사이드 프로젝트를 진행하더라도 진중하게 고민해야 할 부분이었습니다.

그럼에도 불구하고 우리가 얻은 것들

이렇듯 큰 어려움을 겪었음에도 프로젝트를 끝까지 진행해 마무리할 수 있었던 것은 정형화된 스케쥴을 미리 규정했기 때문이라고 생각합니다. 센터에 아침 9시까지 등원하면 반드시 9시 반에 30분 간 아침 회의를 하면서 현재 마일스톤의 진행 상황을 점검하고 밤 중에 각자 추가로 진행한 부분이 있다면 그 성과와 문제점을 공유하는 시간을 가졌습니다. 또한 오후 4시 반에서 5시 중에 다시 30분 간 하루의 마무리 회의를 진행하며 오늘 진행하면서 있었던 어려운 점과 기술적 구현 난이도, 시간 안에 구현 가능할 지에 대해 심도 있게 토의를 했습니다. 아키텍처 수립과 모델 수립이 어찌저찌 해결될 수 있었던 것도 이렇듯 매일 두 차례 진행한 회의에서 주어진 시간과 저희 팀원의 기술적 숙련도를 고려했을 때 여기까지는 진행할 수 있겠다는 타협점을 찾은 결과였습니다.
풀 리퀘스트와 이슈 탭의 사용법을 숙달한 것도 저희로서는 큰 성과였습니다. 같은 공간에 있으면서 문제점이 생길 때마다 팀원들 간에 즉석에서 의사소통을 하면서 해결되는 문제점도 많았지만, 개중에 절반 정도는 당장 해결책을 알 수 없는 것들이 많았고, 설령 해결이 가능했던 부분도 기록으로 남겨두면 나중에 비슷한 문제가 발생했을 때 참고할 수 있었습니다. 그래서 풀 리퀘스트를 올릴 때 어떤 문제가 발생했는지를 기록하기도 하고, 이슈 탭 또는 협업 툴(노션, 슬랙 등)에 문제점과 해결책을 공유하고 기록했습니다. 회의 때 안건으로 올려서 리마인드할 수 있는 이점도 있었고 말이죠.

총 회고

자, 그래서 지금까지 느꼈던 것들을 회고로 간략하게 정리하면 아래와 같이 나올 것 같습니다. 이번에는 평소와 달리 KPT(Keep, Problem, Try) 양식으로 적어볼까 합니다.

우리 포트폴리오에도 KPT를 많이 쓰기도 했고

Keep

• 배운 내용을 깃허브 이슈로 남기거나, 실습 파일을 개별 리포지터리에 커밋해서 기록하는 습관.
• 정형화된 일정 관리. 정례화된 회의를 통해 현재 진행 상황과 문제점을 공유하고 해결책을 제시하는 자리를 마련.
• 깃허브 협업 리포지터리의 풀 리퀘스트 및 이슈 탭의 활용 숙달.

Problem

• 데이터의 질과 양을 검증하려는 노력이 부족. EDA를 통한 사전 데이터 검증의 부족함.
• 사용하고자 하는 기술 스택의 장단점을 포함한 특성에 대한 이해도 부족.
• 협업 시의 커뮤니케이션 시 각자의 에고(ego)가 너무 강했던 것이 아닌가 싶음. 살짝 자아를 죽이고 유연하게 의견을 청취하는 노력이 더 필요했다고 봄.
• 우리가 만들려고 하는 서비스가 왜 필요한 지에 대한 더 깊은 고찰이 필요. 모든 서비스와 제품은 필요에 의해 만들어지는 것이고, 이미 그러한 서비스가 배포되고 있다면 그 서비스와의 차이점을 추구해야 함.

Try

• 조금 더 진보된 NLP 모델의 사용. 지금보다 다양한 모델의 사용을 가능케 하고 결과적으로 서비스를 유연하게 제작/배포하기 위해 파이토치와 트랜스포머와 같은 다른 딥러닝 라이브러리의 학습과 허깅페이스에 게시된 모델의 파인 튜닝 실습을 시도해볼 것.
• 구글 맵 API를 더 효과적으로 다루려면 자바스크립트의 숙련도가 필요할 것으로 보임. 향후에 제작할 서비스에 넣을 경우 구글 맵 API에 포함된 다른 기능들도 적극적으로 활용하면 좋을 듯.

마치며...

우연한 계기로 학부생 시절 머신러닝 강좌를 수강하며 데이터 직무에 대한 관심을 처음으로 가진 뒤, 그 관심을 진정한 내공과 능력으로 바꾸기 위해 여러 공부를 시작했습니다. 연구실에서 연구도 해봤고, 혼자서 공부하기도 했지만 어느 순간 한게에 부딪히면서 조금 더 폭넓은 분야를 알아가기 위해 데이터 엔지니어링 트랙에 지원했고 수강하게 되었습니다. 돌이켜보면, 쉽지 않은 교육과정일 것임을 예상했지만 그 예상보다도 조금은 어려운 길이었습니다. 데이터 분석의 편린이라고 할 수 있는 부분만 알고 있던 제가 전혀 생각하고 있지 못했던, 분석 결과라는 인사이트를 실제 서비스에 배포하는 부분이 상당 부분을 차지했기 때문이죠.
하지만 그럼에도 불구하고 내 결과를 세상에 공유하고, 직접 만든 프로그램을 세상에 배포하는 것은 지금까지의 공부와는 또다른 재미를 일깨워줬습니다. 그 과정에서 프로그램 개발이라는 새로운 분야에서의 협업 방식을 실습하는 것도 이전까지 다른 공학 분야의 공부만을 해왔던 저에게 더없이 귀중한 자산이 되어줄 것입니다.
6개월 간 함께 해주신 강사님들께 감사드리고, 같은 반 수강생들도 좋은 결과 있기를 바랩니다. 좋은 인연으로 뵙게 되어 감사했습니다.