모노산달로스의 행보

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (9) | 부제 : 돌아보며

모노산달로스 — Tue, 12 Aug 2025 05:19:46 +0900

Perdue University 2025 글로벌 연수 - 9

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

08/04 (Monday)

Inside the Bee Hive

마지막 테스트를 진행했다

마지막 주말이 끝나고, 월요일이 찾아왔습니다. 오늘은 이전에 하지 못 했던 벌통 내부에 센서를 삽입하는 테스트를 진행했습니다. 꿀이 들어갈 프레임 하나를 드러내고, 그 자리에 센서를 삽입했습니다. 센서는 벌과 꿀로부터 보호하기 위하여 비닐팩 내부에 넣어두었습니다. 이후에는 마스터 노드를 핫스팟으로 연결하였습니다.

첫 테스트에서는 아쉽게도 서버로 데이터가 전송되지 않았습니다. 우리는 문제를 찾기 시작했는데, 이전과 달라진 환경은 와이파이가 아닌 핫스팟을 사용한 것뿐이었습니다. 따라서 교수님으로부터 와이파이 에그를 받아 마스터 노드를 연결했습니다.

결과는 성공적이었습니다. 더 강한 신호를 보낼 수 있는 와이파이를 사용하니 마스터 노드가 서버로 데이터를 전송하는 데에 문제가 없었습니다. 우리는 애플리케이션으로 결과를 확인한 뒤 모두 가슴을 쓸어내렸습니다. 이로써 우리가 지금까지 한 실험의 종지부를 찍을 수 있었습니다.

농장에서 하루를 마무리했다

오늘은 교수님의 농장에 방문하는 마지막 시간이 될 예정입니다. 대학교 캠퍼스만큼이나 기억에 많이 남을 공간이라는 생각을 했습니다.

08/05 (Tuesday)

데모 비디오

발표를 위한 데모 비디오를 제작했다

오늘은 발표에서 사용하기 위한 30초 정도의 데모 영상을 만들었습니다. 하드웨어 설명과 테스트 과정 그리고 애플리케이션에 대한 실험 과정에 대한 소개 영상입니다. 영상 제작은 익숙한 작업이었기에, 즐거운 마음으로 임할 수 있었습니다. 프로그램이 모두 끝난 뒤에는, K-스퀘어 활동에 대한 후기 영상 또한 제작할 예정입니다.

다른 팀원들은 논문 최종 피드백을 위해 추가 수정을 진행하거나, 자신의 발표 자료를 수정하는 작업을 진행했습니다.

08/06 (Wednesday)

마지막 준비

미리 발표 리허설을 진행했다

오늘로 최종 발표를 하루 앞두고 있는 상황입니다. 팀원 모두가 모여 스크립트를 읽으며 발표 연습을 진행했습니다. 발표 자료 또한 최종적으로 정리를 마치고, 구조를 수정했습니다.

이제는 정말 끝이 다가온다는 느낌이 강하게 들었습니다. 밤늦게까지 모여 발표 연습을 하는 모두의 마음이 하나 일 것이라고 생각합니다. 꼭 최종 발표를 잘 수행하여, 프로그램의 아름다운 종지부를 남길 수 있다면 좋겠습니다.

08/07 (Thursday)

최종 발표

최종 발표를 진행하다

오랜 시간을 기다린, 최종 발표의 날이 다가왔습니다. 팀원들이 스크린 앞에 서서, 지금까지 준비했던 모든 것들을 15분 안에 보여주려고 온 힘을 다했습니다. 중간발표와 비슷하게 교수님들은 우리를 평가하시기보다는 여러 의견들을 제시해 주셨습니다. 왜 MQTT서버를 사용했는지, 기기의 소형화 등에 대하여 마치 토의하듯 교수님과 이야기를 나눌 수 있었습니다.

발표는 오전 시간 안에 모두 끝이 났습니다. 12명의 학생들 모두 마음의 짐을 풀어놓은 듯한 기분을 느꼈습니다. 이제 두 달간의 일정이 끝이 났다는 생각이 들기도 했습니다. 편안한 기운 속에서 모두들 웃는 모습으로 마지막 업무를 잘 끝마칠 수 있어 기뻤습니다.

모두들 수료증을 받았다

이후에는 교수님으로부터 수료증을 받을 수 있었습니다. 두 달간의 여정에 보람을 느끼는 순간이었습니다.

08/08 (Friday)

마지막 인사

다들 힘을 모아 준비한 편지를 전달드렸다

K-스퀘어에서 남은 마지막 시간을 기리며, 전 날 모두 모여 편지를 준비했습니다. 두 달간 우리를 도와주신 교수님들의 은혜 그리고 14년간 이어진 프로그램의 마지막을 기리며 한 자 한 자 적어냈습니다. 그리고 금요일에 교수님들께 편지를 드리며 프로그램의 끝을 알렸습니다.

끝으로

미국에 처음 도착한 날을 기억하자면, 벌써 시간이 이렇게 흘렀나 생각이 듭니다. 사람, 건물, 자연 그리고 음식 존재하는 모든 것이 새로운 공간에서 적응하는 과정은 정말 뜻깊었습니다. 어쩌면 일생에 이보다 더 새로운 경험을 할 수 있을지 의문이 들 정도로 말이지요.

나는 두 달간 어떤 성장을 했을까요? 소기의 목적을 다시 떠올려봅시다.

먼저 기술적인 부분을 고민해봅시다. 돌이켜보면 몇 가지 새로운 분야를 탐구할 수 있어 좋았던 것 같습니다. 특히 잘 다루어 보지 못한 하드웨어적인 부분에 대해 알아 갈 수 있었고, LoRa와 같은 네트워크에 대한 실험 또한 수행할 수 있어서 좋았습니다. 두 부분 다 기존에 다루어보지 못했던 완전히 새로운 분야였고, 이를 내가 알던 지식과 조합하여 새로운 프로토타입을 만드는 것은 큰 의미가 있었다고 생각합니다.

이에 대하여 몇몇 학생들은 기대에 못 미치는 성과라고 여기기도 했습니다. 물론 두 달이라는 시간이 길지 않고, 원하는 주제를 선정하기가 힘들기도 했었죠. 특히 AI를 중점적으로 다루고 싶었다면, 이번 프로젝트에서는 조금 어려웠을 것이라 생각합니다. 하지만 제게는 어떠한 분야보다는 새로운 것을 학습하는 데에 목적이 있었기에 개인적으로는 만족을 했다고 생각합니다.

다음으로는 역시 영어에 대한 이야기를 빼놓을 수 없습니다. 영어 실력이 많이 늘었나? 라고 생각하면 갸우뚱 하기는 합니다. 본인도 모르는 사이에 늘었을 수도 있지만, 또 두 달이라는 기간이 획기적으로 성장하기에는 짧은 시간으로 보이기도 하지요.

즉, 분명 실력이 늘었다고는 여기지만, 기대 이상으로 잘하게 되지는 않았다고 생각합니다. 문법이나 발음 등 실력이라고 부를 요소 보다는, 실제로 소통하는 과정에서 자신감이 늘었다는 점이 더 큰 이득이라고 생각합니다.

영어의 성장에 대해서는 본인의 노력 여하에 따라 많이 달라졌다고 생각합니다. 그 어떤 외국인도 먼저 말을 많이 걸어주지는 않았으니까요, 본인이 대화를 하려고 노력을 많이 한 학생들 일수록 더 큰 성장을 했을 것 같습니다. 특히 프로그램 초반에는 다들 영어에 대하여 열정이 컸지만, 점점 익숙해지는 환경 탓에 이러한 노력을 미처 기울이지 못한 경우도 많았던 것 같습니다. 본인 또한 이 부분에 대해서는 반성하고 싶습니다.

다만 자신감이 늘었다는 점에 대해서는 확실히 느꼈습니다. 처음 영어로 대화 할 때 상대가 잘 못알아 듣는 모습을 보고 조금 주눅이 들고는 했습니다. 그런데 그것이 발음이 아닌 목소리의 문제라는 것을 알게되고는, 더 자신감 있게 소통을 이어나갔 던 것 같습니다. 물론 젊은 학생들 여럿이 빠르게 대화하는 것은 아직도 어렵게 느껴지기는 하지만, 공식적인 자리에서 공식적으로 소통하는 것은 이제 조금 익숙해진 것 같아 기쁘기도 합니다.

마지막으로 환경에 대한 이야기를 하고싶습니다. 미국은 정말 한국과는 많이 다른 나라입니다. 사람들의 행동, 태도 그리고 사고방식 모두 생소하게 느껴집니다. 이러한 상황에 적응을 하려고 노력하는 것, 교수님 께서도 언급했듯이 빼놓을 수 없는 중요한 부분이라고 생각합니다. 우리는 앞으로 살아가며 계속해서 새로운 상황에 놓여질 테고, 그 곳에 잘 적응하는 것이 사회의 새로운 일원으로써 역할을 하는 데에 큰 도움이 될 것입니다. 그리고 그 능력을 키우기 위한 방법으로는 새로운 상황을 많이 겪는 수 밖에 없는 것이지요.

이렇듯 12명 모두 다른 성과를 얻었겠지만, 개인적으로는 만족을 하고 있습니다. 더 많은 것을 원하고 힘들었던 기간도 잠시 있었지만 다시 돌아보고 후회하지는 않을 활동이었다고 생각합니다.

우여곡절이 있었지만 두 달이라는 시간이 모두 끝이 났습니다. 많은 지식을 새로 얻을 수 있었고, 새로운 문화도 많이 접했습니다. 훌륭하고 좋은 사람들 또한 많이 만났고, 자신을 겸손하게 여기는 기회가 되기도 했습니다. 그야말로 소중한 추억으로 남았습니다.

꿈에 그리던 기회를 주신 경기대학교 소프트웨어중심대학 사업단에 감사합니다. 또 좋은 프로그램을 운영하는 IITP와 퍼듀 대학교에 감사합니다. 그리고 나와 함께 해준 12명의 학생들에게도 감사합니다.

앞으로 모두가 자신이 바라는 일을 할 수 있기를 바라며 퍼듀 대학교 프로그램을 끝마칩니다.

이상

퍼듀 대학교 일지는 9번째 게시글을 마지막으로 마칩니다.

다음에 또 이렇게 좋은 경험을 글로 남길 수 있었으면 좋겠습니다.

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (8) | 부제 : 순리(順理)

모노산달로스 — Tue, 5 Aug 2025 00:04:21 +0900

Perdue University 2025 글로벌 연수 - 8

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

Baba O'Riley - The Who

순리의 의미는 가장 아래에

07/28 (Monday)

GPS Connected

보가 모두를 위해 디저트를 마련했다

다시 새로운 월요일이 밝았습니다. 남은 시간이 많지 않기에, 오늘도 본인은 애플리케이션 개발에 몰두했습니다.

이 날 한 가지 특별했던 일은, 보가 모두를 위해 디저트를 준비해 왔다는 것입니다. 모두 잠시 작업을 멈추고 달콤한 케이크를 즐겼습니다. 보의 베이킹 솜씨는 대단했고 모두가 입을 모아 칭찬을 이어나갔습니다. 우리는 단 음식을 먹어서인지 다시 힘을 내서 작업을 시작할 수 있었습니다.

보와 관련하여, 최근 며칠간의 개발 과정에서 특히 좋았던 점이 하나 있습니다. 바로 서버 개발을 맡은 보와의 협업이 자연스럽게 많아졌다는 것입니다.

서로 필요한 부분을 영어로 주고받으며 하나씩 문제를 해결해 나갔고, 사소한 부분이라도 놓치지 않으려 자주 소통하려고 노력했던 순간들이 기억에 남습니다. 그러한 과정에서 실전에서 영어를 연습해 볼 수 있어서 좋기도 했습니다.

GPS 연결에 성공했다

오후 즈음에는 드디어 기기에 GPS 연결을 성공시켰습니다. GPS의 전압을 맞추는 데에 약간의 어려움이 있었지만, 끝내 마무리를 할 수 있었습니다. 이후에는 K-Square 밖에 기기를 놓아두고 테스트를 진행했는데, 몇 번의 시도 끝에 좌표 정보를 받아 애플리케이션에 표시할 수 있게 되었습니다.

07/28 (Tuesday)

모습을 갖추다

더 작은 프로토타입을 개발했다

화요일에는 PVC Pipe를 더 작게 잘라 새로운 프로토타입을 만들었습니다. 기존에 비해 거의 두 배 작아진 모습을 보니, 스마트 더스트라는 목표에 더 가까워지는 듯한 기분이 들었습니다.

사실 소형화 과정에서 대부분의 마이크로 디바이스를 교체할 필요가 없었습니다. 대부분의 공간은 커다란 보조 배터리가 차지하고 있었기 때문입니다. 따라서 처음에는 최대한 작은 리포 배터리를 사용하고자 했지만, 충전과 과열 위험으로 부착을 못했습니다. 하는 수 없이, 더 작은 보조 배터리를 장착함으로써 소형화를 진행했습니다.

보가 논문에 대한 피드백을 해주었다

오후에는 논문 작업이 절반정도 완성되었습니다. 특히 중요하게 여겨진 Abstract와 Intro 부분을 끝낸 것은 좋은 신호였습니다. 여러 기존의 논문들을 많이 참고하여 작성이 진행되었습니다. 특히 기존에 비슷한 실험을 한 논문과 회사들이 존재했기에, 그들과의 차별성을 두기 위하여 노력했습니다.

이후 작성된 논문에 대해 보가 지속적으로 피드백을 주었고, 이는 우리에게 큰 도움이 되었습니다. 특히 우리는 아직 자연스러운 영어 표현에 익숙하지 않았기에, 보의 세심한 피드백은 더욱 값진 조언이었습니다.

최종 발표 구조에 대해 이야기 했다

일과가 끝나기 전에는 잠시 최종 발표에 대해서 논의를 했습니다. 중간발표와 달리 시간을 두고 완벽하게 준비하자는 마음을 다들 가지고 있었습니다. 따라서 이전 발표의 보완점에 대해 이야기했습니다.

논의 결과 내려진 결론은 이러했습니다. 각자 맡은 파트에 대한 적절한 분량을 가짐과 동시에 통일성을 추구해야 한다.

중간발표 때는 시간이 없어 한 사람의 주도로 발표를 이어갔습니다. 하지만 그렇게 되었을 때는 각자가 수행한 부분을 제대로 어필하지 못하는 아쉬움이 있었습니다. 또한 섹션별로 나누어진 다른 팀은 멤버 각자의 텐션이 달라 통일성이 떨어지고 정신이 없다는 느낌을 받기도 했습니다.

따라서 우리는 각자 맡은 파트를 소개하되, 모두가 같은 톤을 유지하는 것을 목적으로 정했습니다.

추가로 약 30초 분량의 데모 영상을 삽입하고자 계획을 했습니다. 꽤나 기대되는 최종발표의 모습이 그려지는 순간이었습니다.

07/29 (Wednesday)

대량생산

더 많은 노드를 만들었다

이번 주 금요일 농장에 실제로 노드를 설치를 할 예정입니다. 따라서 그전까지 모든 준비를 마칠 필요가 있었습니다. 남은 PVC를 모두 자르고, 디바이스를 넣을 준비를 했습니다.

애플리케이션 또한 실제 핸드폰에 이식하여, 테스트를 할 수 있도록 준비했습니다. 크게 문제가 되는 일은 없었지만, 각자 맡은 일에 열중하여 빠르게 시간이 흘러간 하루였습니다.

07/30 (Thursday)

시스템 통합

012

데모 테스트를 진행했다

목요일은 다음 날을 위해 시스템 테스트를 진행했습니다. K-Square 밖에 세 개의 스마트 더스트를 두고 데이터 측정을 시작했습니다.

확인 결과 좌표 정보, 센서 데이터 모두 정확하게 가져올 수 있었습니다. 마이크로 디바이스로 시작하여 서버를 거치고, 애플리케이션까지 모든 시스템 아키텍처가 하나로 통합 되는 순간 큰 기쁨을 느꼈습니다.

이렇게 기본적인 작동은 모두 확인했지만, 한 가지 변수가 남아 있었습니다. 바로 벌통 내부에서는 꿀과 벌들이 센서를 망가뜨릴 수도 있다는 점이었습니다. 내일 어떤 결과가 나올지는 모르겠지만, 농장 환경에서도 지금과 같이 잘 동작할 수 있다면 좋겠다고 소망했습니다.

남은 시간에는 약간의 PPT 작업을 도와주었다

그렇게 개발 과정이 전체적으로 마무리된 뒤에는 최종 발표 준비 작업을 시작했습니다. 각자 파트가 잘 나누어져 있었기에, 원하는 발표 내용을 구성하기 쉬웠습니다. 본인은 서버와 앱 부분을 담당했기에, 해당 부분에 대한 사진과 스크립트를 준비했습니다.

다른 팀원들 또한 각자 자료 구성을 어느 정도 끝냈었지만, 몇 가지 미적인 부분을 개선하면 좋겠다고 생각했습니다. 그래서 화질이 안 좋은 이미지를 개선하거나, 디테일한 디자인 요소를 개선하는 등의 도움을 주었습니다.

08/01 (Friday)

알파 테스트

논문 작업이 모두 마무리 되었다

오늘은 하루 종일 모두가 논문 작업에 신경을 썼습니다. 여럿이서 작업을 했기에 단어의 통일과 같은 부분을 주의하여 작업을 진행했습니다. 예를 들어 Geolocation와 GPS Location처럼 다른 단어이지만 같은 의미를 가지는 경우가 꽤 있었기 때문입니다.

우여곡절이 있었지만, 각자 맡은 부분을 여러 번 반복하며 수정을 했고 끝내 논문 작업을 잘 마무리할 수 있었습니다. 이후에는 농장에서 테스트를 위해 각 센서의 작동을 마지막으로 확인했습니다. 또한 현장에서 헷갈리지 않도록 노드들의 이름을 정리하여 두었습니다.

농장으로 가는 길에서도 테스트를 진행했다

금요일 오후 6시, 모든 일정이 끝나고 우리는 한 자리에 모였습니다. 사실 농장에 가는 목적은 우리 팀의 테스트만 아니었습니다. 프로그램이 끝나기 전, 다 같이 모여 Bonfire를 하는 것이 진짜 목적이었습니다. 다 같이 바비큐를 먹고 미국의 밤하늘을 구경하는 즐거운 시간이 될 예정입니다.

이동하는 차량에서도 노드를 켜보고 테스트를 시도했습니다. 데이터를 잘 받아오는 것을 확인할 수 있었고, 이전에 보았던 벌의 이동 문제에 대해서도 도움을 줄 수 있겠다는 생각을 했습니다.

벌의 이동 문제란 무엇일까요?

미국의 아몬드는 수분을 벌에게 의존하고 있습니다. 따라서 매년 재배를 하기 위해 미국 전역의 벌들 중 60% 이상이 캘리포니아로 이동합니다. 그런데 이렇게 이동하는 과정에서 폐사하는 벌들이 굉장히 많다는 사실이 있었습니다. 연구 초기 우리가 고려했던 문제이기도 합니다.

0123

각 벌통과 길 사이에 노드를 설치했다

농장에 도착하고 난 뒤에는 본격적으로 테스트를 준비했습니다. 우선 각 포인트를 나누었는데, 하나의 벌통이 놓인 A구역, 두 개의 벌통이 붙어있는 B구역 그리고 그 사이를 이어주는 오솔길 C구역 이 존재했습니다. 이후에는 디바이스의 전원을 모두 켜고 각 구역에 설치했습니다.

다음으로는 마스터 노드를 켜고, 와이파이를 연결해 본 결과 애플리케이션에 데이터가 잘 받아와 지는 것을 확인할 수 있었습니다. 특히 GPS데이터가 지도에 명확하게 보이는 것은 고무적이었습니다. 잘 동작하는 것을 확인한 뒤에는 약 1시간 정도 데이터 수집을 계속 이어갔습니다. 한 가지 특이한 점은 지면과 가까워서인지, 습도가 매우 높게 측정되고는 했습니다.

원래 벌통 내부에도 디바이스를 설치하려고 가져왔지만, 지금 벌통 내부에 설치하는 것은 어렵다는 교수님의 말씀이 있으셨습니다. 따라서 해당 작업은 월요일에 다시 농장에 방문하여 수행하기로 결론을 내렸습니다.

모닥불에 모여 밤을 지냈다

테스트 이후에는 즐거운 금요일 밤을 보냈습니다. 바비큐와 맥주 그리고 사람들의 이야기 속에 빠져들었습니다. 큰 개를 데려온 분도 계셨는데, 덕분에 분위기가 더 들뜨는 느낌이 들었습니다. 다들 맛있는 음식과 웃는 얼굴로 행복한 시간을 즐겼습니다.

밤이 깊어지고 어둠이 찾아왔을 때는 모두 불가에 모여들었습니다. 이 이야기도 곧 끝이 다가온다는 감정을 느꼈기 때문일까요? 시간이 지나고 꺼져가는 불꽃을 바라보며 싱숭생숭한 기분이 들었습니다.

약 두 달이라는 기간 동안 신비한 경험을 했습니다. 일상생활의 여러 스트레스에서 벗어나 완전히 자유로운 삶을 살아가는 듯한 느낌도 받았습니다. 이 프로그램은 행복을 느끼기에 최적의 시간입니다. 과거와 미래 모든 것과 단절되어, 오직 하나의 프로젝트에만 집중하면 되니까요.

그런데 이번 한 주간 이상하리만치 큰 혼란에 빠지고는 했습니다. 분명 완전한 행복을 느껴야만 하는 순간임에도, 알 수 없는 고통에 몸부림치고 있었습니다. 그리고 고민 끝에, 너무나 많은 것을 바라고 있었다는 생각이 들었습니다.

내가 얻기를 바라는 능력과 성취가 현실의 벽을 넘어서는 순간, 모든 것은 욕심에 해당하게 되었습니다. 그것이 크든 작든 욕심의 기준을 본인이 정하기란 불가능했습니다. 하지만 이를 자각하지 못하는 동안에는 새로운 스트레스를 느끼고 있었습니다.

그렇다면 여기서 내가 해야 하는 행동은 무엇일까요? 항상 정답은 명확합니다. 얻을 수 없는 것을 얻으려 하지 말고, 할 수 있는 일을 열심히 하자. 그것이 *순리(順理)의 진짜 의미가 아닐까 싶습니다. 물론 머리로 안다고 해서 즉시 행동으로 이어지기란 쉽지 않지만, 그것을 해내려는 과정에서 분명 성장할 수 있으리라 생각합니다.

*순리(順理) : 사물의 이치를 알고 행동하는 것

때로는 긴 여정 중 마음이 어지러운 순간이 있을 수도 있습니다. 하지만 이렇게 좋은 밤을 보내며 생각을 정리하면 다시 힘을 얻게 됩니다.

마지막 한 주는 욕심이 아닌 순리에 따르는 좋은 경험과 추억으로 남길 수 있기를 기대합니다.

...

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (7) | 부제 : Interim Findings

모노산달로스 — Sat, 26 Jul 2025 23:17:22 +0900

Perdue University 2025 글로벌 연수 - 7

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

07/21 (Monday)

Aftereffects

글을 읽기가 너무 힘들었다

3일간의 여행이 끝나고 다시 출근의 시간이 돌아왔습니다. 쉴 틈 없는 여행 일정 때문인지, 다들 정신이 몽롱한 상태로 작업을 시작했습니다.

수요일의 중간발표가 가장 급한 시점이었기에, 그것을 준비하는데 힘을 썼습니다. 본인은 발표를 위한 추가적인 자료 조사를 수행했습니다. 벌들이 죽는 이유와, 우리가 만드는 제품의 타당성을 연결하기 위해 노력했습니다.

이후 아래와 같은 논리 구조를 만들어 보았습니다.

1. 꿀벌은 미국 농업에 필수적이다
2. 2024년 여름 이후 전체 상업 군체의 60% 이상이 폐사한다
3. Varroa destructor이 현재 전 세계 꿀벌 집단 감소 및 붕괴의 최대 원인으로 지목된다
4. 기존 화학적 방제법은 내성 문제로 효과가 줄고 있다
5. 외부 기상(온도/습도)이 Varroa destructor발생 및 방제에 직접적 영향을 준다
6. 일평균/최고 기온이 25.1~31.7°C, 최저기온 5.5°C 이상일 때 Varroa mite가 많이 떨어진다
7. 습도가 낮아질수록(moisture 47→22%) 낙하도 증가한다
8. 특히 외부(open space)에 노출된 벌통에서 이 효과가 두드러진다

밖에 놓여진 우리의 디바이스

발표 준비 이외에도 한 가지 더 문제점이 있었습니다. 그것은 바로 조도센서의 측정값이 들쑥날쑥하다는 점이었습니다. 기기들이 같은 환경에서 서로 다른 값을 출력하는 것은 큰 문제였습니다.

이를 해결하기 위해 조도 센서의 저항과 관련하여 조사를 시작했습니다. 그 결과 기존 기기가 디지털 신호를 보내고 있다는 것을 알게 되었습니다.

우리가 원하는 것은 0과 1로 이루어진 디지털 신호가 아닌, 아날로그 신호의 조도 정보입니다. 따라서, ESP32는 조도 정보를 아날로그 신호로 받아야 합니다. 하지만 기존 기기는 조도 정보를 스스로 디지털 신호로 변환하여 전송하고 있었습니다.

따라서 Photoresistor가 아닌 아날로그 신호를 전송하는 Photocell을 사용하도록 계획을 변경했습니다.

이제 정말 완전히 데이터를 수집할 준비가 완료되었습니다. 우리는 KSW Sqaure 앞에 디바이스를 내다 두고 퇴근을 하였습니다.

07/22 (Tuesday)

Disconnected

오늘 아침 문제가 생겼다

화요일 이른 아침, 보에게서 메시지가 도착했습니다. 어제 새벽 즈음 기기가 종료되었다는 것입니다. 아침에 출근하여 확인해 보니 배터리가 모두 소모되어 있었습니다. 어제 오후 5시부터 새벽 1시까지, 약 8시간 정도 작동 후 종료가 된 상황입니다.

사실 지속가능한 기기를 만들기 위해서는 태양광 패널 같은 시스템이 필수적입니다. 자체적으로 배터리 공급이 가능할 때 멀리 퍼져있을 수 있고, 그때 비로소 스마트 더스트로써 역할이 가능하기 때문입니다.

하지만 패널을 구매하는 것은 교수님과 다시 논의가 필요한 부분입니다. 우선은 더 큰 배터리를 연결하여 사용하며 상황을 지켜보는 것으로 결론을 내렸습니다.

가장 기억에 남았던 Algorithm Issue

다음으로는 중간 발표에서 이야기할 내용을 다시 정리했습니다. 기억에 남은 부분을 소개하는 시간이 있을 예정인데, Meshtastic을 꼭 언급하고 싶었습니다.

특히 인상 깊었던 점으로 Mesh Broadcast Algorithm에서 발생하는 문제점을 소개하고 싶습니다. 발표 시간 관계상 너무 길지 않게, 간결하게 전달하는 게 중요하다고 생각하여, 문장을 여러 번 뜯어고치고는 했습니다.

총 평가에서 필요한 부분을 정리해주셨다

오후에는 모두가 발표 준비에 열중했습니다. 본인 또한 스크립트를 계속 읽어보고, 발표 자료를 살펴보며 시간을 보냈습니다. 그러던 중 교수님께서 몇 가지 조언을 주셨습니다.

사진에서 보이는 다섯가지의 요소는 필수적으로 발표에 포함되어야 하는 내용입니다. 그중에서 1번과 2번은 상당히 중요하다고 강조하셨습니다. 예를 들어서 '왜 이 프로젝트를 선택했는지?', '이 프로젝트가 세상에 어떤 의미가 있는지?', '이 프로젝트가 자신에게 어떤 의미가 있는지?'와 같이 프로젝트의 이유에 대한 질문을 상당히 강조하셨습니다.

또한 이 프로그램 수행 과정에 대해서 말씀하신 것도 기억에 남았습니다. 이 모든 작업과 발표는 평가가 아니라 학습에 의의가 있다는 것입니다.

교수님은 우리의 프로젝트의 결과에 대하여 평가를 내리지 않는다고 하셨습니다. 이 팀은 잘한 프로젝트, 이 팀은 못한 프로젝트 이렇게 나누지 않는다고 하셨습니다. 그보다는 프로젝트를 수행하며 어떤 것을 배웠고, 어떤 것을 느꼈느냐에 초점을 맞추어야 한다고 하셨습니다.

또, 모두가 발표에서 스피커가 되어야 한다는 점도 특이했습니다. 한국에서는 보통 제한을 두지 않거나 한 명의 발표자가 발표를 수행하는 형태가 대부분이었습니다. 하지만 미국에서는 모든 팀원이 발표에 참여하는 것이 기본(적어도 퍼듀에서는)이라는 말씀을 해 주셨습니다. 이는 우리에게 있어서도 좋은 점이었는데, 모두가 영어 실력을 연습할 수 있는 기회로 느껴졌기 때문입니다.

07/23 (Wednesday)

Presentation

드디어 중간 발표의 날이 다가왔습니다. 전 날 밤 모두 모여 발표 준비를 마치고, 드디어 모두에게 선보이는 시간이 다가왔습니다. 우리가 주제를 선택한 이유, 발견한 문제와 솔루션 등을 차례로 이야기했습니다. 그리고 각자가 마주한 트러블 슈팅에 대해서 발표를 진행했습니다.

발표 결과는 생각보다 정말 좋았습니다. 교수님께서는 우리가 선택한 주제와 진행 방식에 대해 호평을 해 주셨습니다.

교수님들께서 앞으로의 진행에 대한 몇 가지 피드백을 주셨습니다.

1. 벌통 내부의 센서 삽입
우리 팀은 벌통 외부에 센서를 두는 것을 목적으로 프로젝트를 진행했습니다. 하지만 교수님께서는 벌통 내부의 데이터도 필요하지 않느냐고 이야기해 주셨습니다. 실제 양봉업자 분과 인터뷰를 했을 때에도, 벌통 내부의 습도가 응애와 같은 기생충에 크게 영향을 준다고 말해 주셨기 때문입니다.

2. 두 장소의 데이터 비교
최종 발표에서는 GPS 기능을 가지는 프로토타입을 선보일 계획이었습니다. 이에 교수님께서는 두 장소의 온도와 습도 데이터를 알 수 있다면 양봉업자들에게 큰 도움이 될 것이라고 말씀해 주셨습니다. 양봉틀을 놓을 최적의 장소를 선택할 때 유용하게 쓸 수 있기 때문입니다.

푸쉬 알림 기능을 연동했다

오후에는 보와 이야기하면서 푸시 알림 기능을 테스트했습니다. 클라이언트가 빠르게 긴급 상황에 대처할 수 있도록 하기 위해 필요합니다.

07/24 (Thursday)

편안한 하루

하루종일 애플리케이션 개발에 집중했다

목요일 하루는 아침부터 저녁까지 정말 조용했습니다. 제 자신도 그에 따라 애플리케이션 개발에만 집중할 수 있었습니다.

이번 앱 개발의 한 가지 특이한 점은, 디자이너가 없다는 것입니다. 이에 따라 UI/UX적인 고민을 직접 해야 했는데, 그래프를 어떻게 보여 줄지 정하는 것은 생각보다 쉽지 않았습니다.

최종적으로는 노드 간 데이터 비교에 중점을 맞추어 개선을 하였습니다. 기존의 최대, 평균, 최소 값은 선택적으로 바꾸었습니다. 그리고 노드를 색으로 구별하도록 변경했습니다.

07/25 (Friday)

논문과 씨름

논문 작성을 본격적으로 시작했다

프로그램 종료까지 앞으로 약 2주 정도가 남았습니다. 따라서 더 늦지 않도록, 논문 작성을 본격적으로 시작했습니다. 논문에서 도입부에 해당하는 Intro와 Motivation가 가장 중요하다는 설명을 들었고, 우리 팀 또한 이에 집중하기로 결정했습니다. 본인은 논문을 주로 담당하는 역할은 아니었지만, 최대한 많은 기여를 하려고 노력했습니다.

우리 팀은 특히나 프로젝트의 목적에 대해서 고민이 많았습니다.

처음에는 스마트 더스트와 네트워킹에 주목적을 두고 프로젝트를 시작했습니다. 하지만 시간이 갈수록 양봉업자와 벌을 위한 시스템이 갖추어지기 시작했습니다. 내외부 환경을 측정하는 것은 원래의 의도였지만, 여기에 양봉업자를 위한 앱을 만든 것은 연구보다는 서비스 제작에 가까운 활동으로 보였기 때문입니다.

다시 말해, 스마트 더스트로 시작한 프로젝트이지만, 시간이 가며 그 의미가 많이 퇴색되었다는 것입니다.

논문 작성은 짧은 시간 안에 완성하기 어려워 보였습니다. 팀장님이 1 저자로서 많은 노력을 기울이려는 모습을 보였고, 저는 옆에서 도움이 될 수 있는 부분을 적극적으로 지원하기로 방향을 잡았습니다.

애플리케이션 연동이 막바지에 다가갔다

그동안 저는 애플리케이션 작업을 지속적으로 진행했습니다. 최적화 작업과 센서 데이터 패치를 완료했으며, 앞으로는 긴급 노드를 지도에 표시하는 기능을 구현할 예정입니다.

특히, 다음 주에 기기에 GPS가 부착되면 이를 기반으로 지도를 구현하고, 모든 애플리케이션 관련 작업을 마무리할 계획입니다.

최종 발표까지 약 2주 정도의 시간이 남았습니다.

2 달이라는 시간이 정말 짧게 느껴지는 여름입니다.

얼마 남지 않은 기간도 열심히 활동에 임해야겠습니다.

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (6) | 부제 : Prototype

모노산달로스 — Fri, 18 Jul 2025 05:09:17 +0900

Perdue University 2025 글로벌 연수 - 6

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

07/14 (Monday)

애플리케이션 제작

교수님께서 한국 음식을 사 주셨다

월요일 아침, KSW에 도착했을 때 교수님께서 많은 음식을 가지고 오셨습니다. 미국에서 생활하는 시간이 늘어날수록 한국 음식을 더 찾게 되는 것은 자연스러운 듯합니다. 많은 신라면이 벽장에 드러섰고, 마음이 든든해지고는 했습니다.

애플리케이션을 제작했다

월요일 오전 동안은 사용자가 데이터를 확인할 수 있도록 애플리케이션을 제작했습니다. 테스트를 위하여 온도 데이터를 받아 최고 온도, 최저 온도, 평균 온도를 그래프로 그리도록 만들었습니다.

애플리케이션 제작은 그간 해왔던 일이었기에, 속전속결로 작업을 마무리했습니다.

유명한 아이스크림 집에 들렀다

점심을 먹고 나서는 유명한 Silver Dipper Ice Cream 가게에 들렀습니다. 괜찮은 가격에 많은 아이스크림을 맛볼 수 있었습니다. 더운 여름 날씨 때문인지, 시원한 음료나 아이스크림이 더욱 맛있게 느껴지는 것 같기도 했습니다.

하드웨어 컨테이너의 새로운 재질을 소개해주셨다

오후에는 하드웨어에 대하여 다시 이야기를 시작했습니다.

우리는 스마트 더스트에 전원을 연결하기 위해서 보조배터리를 사용하게 되었습니다. 그런데 이 경우 리튬배터리에 비해 크기가 너무 커져 기존 취지와 어긋난다는 의견이 나오게 되었습니다.

하지만 교수님의 생각은 달랐습니다. 프로토타입 제작이라는 관점에서는, 크기가 중요한 것이 아니었습니다. 최종적으로는 작은 크기와 멋진 컨테이너를 사용하는 것이 목적이지만, 지금 단계에서는 빠르게 성능을 확인하는 것이 우선이라는 의미었습니다.

이후 교수님은 PVC Pipe를 새롭게 소개해 주셨는데, 우리 프로젝트에 적용하기에 최적의 소재로 보였습니다. 튼튼하고, 원통형으로 잘라내기 쉬우며 무엇보다 전파를 방해하지 않는 성질을 가지고 있었습니다.

남은 시간은 PVC Pipe에 대해서 조금 더 알아본 뒤, 내일 매장에 방문하기로 하였습니다.

07/15 (Tuesday)

MENARD

UI 작업을 마무리하다

오전 시간 동안은 남은 UI 작업을 모두 완료했습니다. 디자이너가 참여하는 상황은 아니었지만, Figma Community의 여러 작품을 참고하며 디자인을 고려했습니다.

그렇게 작업을 마치고 잠시 쉬고 있던 중, 좋은 소식을 들을 수 있었습니다. 보(퍼듀 대학교 학생)가 드디어 마스터 노드와 워커 노드 사이의 통신이 성공했다고 알려 준 것입니다.

이제 하드웨어만 완성을 하면 첫 스텝은 잘 마무리될 것으로 보였습니다.

PVC pipe 구매를 위해 매장에 들렀다

오후에는 MENARDS라는 대형 건축 자재 매장에서 PVC pipe를 구매했습니다. 미리 보드에 연결한 기기를 들고 가서 적절한 크기의 PVC pipe를 선택했습니다.

거대한 매장에 늘어진 건축 자재들을 보면서, 신기한 감정이 느껴졌습니다. 이 공간은 미국인들의 DIY 정신이 녹아든 매장이라는 생각이 들었습니다.

교수님은 자신의 Shed(간이 건물)를 직접 만든 이야기를 해 주셨습니다. 스스로 집을 개조하고, 유지보수하는 미국의 문화는 한국과는 많이 달랐습니다. 사람들이 스스로 무엇이든 할 수 있다는 생각을 항상 가지고 있는 듯했습니다. 한국에서도 이러한 DIY 정신을 마음에 두고 살아가고 싶습니다.

07/16 (Wednesday)

프로토타입 제작

코드 개선 사항을 논의하다

수요일, 워커 노드에 사용될 코드가 모두 완성되었습니다. 따라서 마지막으로 팀원들이 코드를 확인하고 점검하는 시간을 가졌습니다. 추가적인 개선 사항이나, 논의 사항에 대해 이야기를 나누었습니다.

데이터 전송 방식, 센서 경고 기준 등 세부적인 내용은 토론으로 만들어 추후 다시 이야기하기로 했습니다.

PVC pipe를 잘라주셨다

이후, 6인치 크기로 PVC pipe에 자름 선 표시를 하셨습니다. 그걸 받으신 교수님께서 테스트용으로 하나의 PVC pipe를 잘라내주셨습니다.

하드웨어 제작이 순조롭게 이어지는 모습을 보니 신기할 따름이었습니다. 한국에 돌아가서도 여러 가지 방법으로 프토토타입을 만들어 볼 수 있겠다는 생각이 들기도 했습니다.

완성되어가는 프로토타입

잘라낸 원통에 실제로 기기를 넣어 프로토 타입을 구성하기 시작했습니다. 하지만 여기서 중요한 고려 사항이 있었습니다.

센서들은 컨테이너 밖으로 나와야 측정이 가능합니다. 하지만 이 경우 센서 노출에 의한 방수 문제를 해결해야 합니다.

조도 센서의 경우 방수 기능이 어느 정도 있으므로, 구멍을 만들어 선을 연결하고 조도 센서를 밖으로 빼내는 방법을 생각했습니다. DHT22 온습도 센서는 방수 기능이 없어, 벤트 구멍을 뚫는 것은 어떨까 의논했습니다. 또, 비를 막아주는 초미세먼지 방충망 같은 방안이 언급되기도 하였습니다.

교수님이 언급하신 방법

마지막으로 교수님께서는 한 가지 장치를 보여주셨습니다. 그 기기는 뒤집어 놓은 그릇을 겹겹이 쌓은 형태를 하고 있었습니다. 판 내부에는 센서가 존재하는데, 이렇게 되면 비의 영향을 받지 않고 외부 데이터를 측정할 수 있었습니다.

교수님께서는 한 번에 최고의 방법을 알려주시지 않았습니다. 우리에게 계속 의문점을 던지며, 어떻게 하면 하드웨어를 창의적으로 구성할 수 있을지 고민하게 만들었습니다.

아마 생각하는 힘을 기르기 위해서 의도적으로 여러 단계를 거쳐 방법을 제시해 주시는 것이라는 생각을 했습니다.

07/17 (Thursday)

HETBAHN

구멍을 만들어 센서를 밖으로 빼내었다

차분한 분위기 속에 목요일이 시작되었습니다. 오늘은 하드웨어를 최종적으로 구성하는 날입니다. 어제 논의한 대로 뚜껑 위에 센서를 두고 우산과 같은 보호막을 세울 예정입니다.

이를 위해, 센서를 밖으로 내보내는 것이 우선이었습니다. 따라서 PVC 뚜껑 부분에 드릴을 이용하여 구멍을 내었습니다. 그리고 중앙 부분에는 큰 구멍을 만들어서 기둥을 설치했습니다.

햇반 뚜껑으로 지붕을 덮었다

마지막으로 햇반 뚜껑으로 온습도 센서를 가려주었습니다. 그리고 거기에 다시 구멍을 만들어 안테나와 조도 센서를 밖으로 드러냈습니다.

완벽하지는 않지만, 이로써 설치를 할 수 있는 프로토타입을 빠르게 완성 할 수 있었습니다.

네트워크 구조에 대하여 설명을 들었다

이후 시간에는 지금까지 구성한 서버 구조에 대해서 보가 설명을 해주었습니다. MQTT와 마스터 노드 그리고 데이터 서버 사이의 통신 과정에 대한 이야기었습니다.

먼저 마스터 노드는 MQTT에 데이터를 Publish합니다. 그리고 데이터 서버는 MQTT를 Subscribe하고 있습니다. 마스터 노드가 지속적으로 MQTT에 업로드한 데이터를 서버가 구독하여 저장하는 구조였습니다.

서버 구성에 대하여 몇몇 대화를 이어갔고, 어느새 시간이 지나 퇴근을 하게 되었습니다. 다음 날은 단체로 여행을 가기 때문에, 평소보다 조금 일찍 기숙사로 돌아갔습니다.

금요일, 토요일, 일요일 3일간은 마음 편하게 휴식 시간을 가질 예정입니다.

그리고 여행이 모두 끝난 뒤에는,

디바이스와 서버 그리고 클라이언트 사이의 통신을 확인할 수 있기를 기대합니다.

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (5) | 부제 : Forge Ahead

모노산달로스 — Mon, 14 Jul 2025 09:23:10 +0900

Perdue University 2025 글로벌 연수 - 5

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

07/07 (Monday)

계획에서 실행으로

기기의 핀 헤더 납땜을 진행했다

월요일은 납땜기를 켜는 것으로 시작되었습니다. 테스트를 수월하게 진행하기 위하여 ESP32 기기의 핀 헤더를 납땜했습니다. 납땜 경험이 많은 팀원이 있어 빠르게 진행 할 수 있었습니다.

디바이스간 통신을 테스트했다

한 팀원이 납땜을 진행하는 동안 본인은 다른 일에 집중했습니다. 이전에 조사한 Meshtastic을 실제로 ESP32 기기에 설치하여 통신이 가능한지 테스트를 진행했습니다.

Meshtastic은 인터넷 없이도 장거리 무선 메시지 전송이 가능한 오픈소스 메쉬 네트워크 통신 장치입니다. 해당 펌웨어를 LoRa 통신이 가능한 기기에 설치하여 사용이 가능합니다. 그리고 기기의 Region과 Channel을 동일하게 설정하면 자동으로 하나의 Mesh에 포함되게 됩니다. 그렇게 되면 같은 Mesh에 속한 기기끼리 메시지를 주고받을 수 있습니다.

오전 시간은 그렇게 실내 통신 테스트를 성공적으로 마쳤습니다.

먼 거리에서 테스트도 진행했다

오후에는 얼마나 먼 거리에서 통신이 가능한지 살펴보았습니다. 우리는 디바이스를 들고 이동하며 테스트를 진행했고, 캠퍼스 내에서는 약 300-400m 정도 거리까지 통신이 가능한 것으로 결론을 내렸습니다.

그렇게 진행을 하던 중 우리는 하나의 보드에 Meshtastic 펌웨어와 아두이노 코드를 같이 업로드할 수 없다는 사실을 알게 되었습니다. 따라서 Meshtastic 기능을 커스텀하지 않으면 기획 단계에서 원했던 방향과 벗어날 수 있다는 판단을 내렸습니다.

우리는 의견을 다시 모으기 시작했습니다. 몇몇 팀원은 Meshtastic 방식은 커스텀하기 복잡해 보이니 아두이노로 돌아가자는 의견을 냈습니다. 반대로 본인은 아직 Meshtastic을 조사한지 얼마 안 되었으므로 약간의 조사를 더 해볼 필요가 있다고 언급했습니다.

긴 대화 끝에, 우리는 Meshtastic과 아두이노팀으로 나누어 두 방식을 모두 테스트해 보기로 결정했습니다. 두 방식을 모두 시도하고 성과를 비교해 보는 것도 재미있을 것이라 생각이 들었기 때문입니다.

07/08 (Tuesday)

MCU 학습

회로 기초에 대한 설명을 들었다

오늘은 본격적으로 센서와 LoRa를 연동하는 작업을 수행하고자 하였습니다. 이를 위해 아두이노에 익숙한 동료에게 간단한 설명을 부탁했습니다.

가장 먼저 브레드보드(BreadBoard)의 선 구조를 이해했습니다.

그리고 전자 회로에서 자주 사용되는 기본 개념들을 이해하였습니다.

VCC: 전원(Power)을 공급하는 선입니다.
GND: 접지(Ground) 역할을 합니다.
AO: 아날로그 신호(Analog Output)를 의미합니다.
DO: 디지털 신호(Digital Output)를 의미합니다.

온습도 센서 등은 아날로그 신호를 사용하며, ESP32는 디지털 신호를 사용하는 구조입니다. 따라서 이 두 신호를 연결하려면 ESP32의 ADC 핀을 사용해야 합니다. ADC 핀은 아날로그 신호를 디지털 신호로 변환해 주는 역할을 합니다.

이러한 기초 개념을 바탕으로, 센서와 ESP32 간의 연결을 보다 명확하게 이해할 수 있게 되었습니다.

들었던 이론을 바탕으로 실제 센서를 연결했다

이후 실제로 연결을 진행하고, 코드로 센서 테스트를 진행했습니다. 그 결과 두 센서 모두 정상적으로 작동함을 확인할 수 있었습니다. 그동안 사용하지 않았던, 하드웨어 위주의 개발을 해보니 상당히 흥미로웠습니다.

센서 연결을 확인했으니, 이제 본격적으로 Meshtastic과 센서 제어를 동시에 사용할 수 있도록 시도 할 계획입니다.

오후에는 실제 양봉 매장을 방문했다

오후에는 교수님께서 알고 계시는 양봉 매장을 방문하였습니다. 다양한 양봉 도구들과 여러 종류의 꿀을 구경할 수 있었습니다.

이곳에서는 실제 양봉업에 종사하고 있는 분과 대화를 나눌 기회도 있었습니다. 우리가 시도하려는 것과 유사한 스마트 기기를 도입한 사례를 소개해 주셨고, 해당 기기들이 가격이 매우 비싸다는 점이 가장 큰 부담이라고 말씀해 주셨습니다.

또 벌의 소리에 집중하는 것도 좋다는 조언을 해 주셨습니다. 벌 비행 소리의 높낮이에 따라서 그들의 행동이 결정되고 다음 행동을 예측할 수 있기 때문입니다.

그렇게 많은 정보들을 얻은 뒤 매장을 떠나게 되었습니다.

돌아 올 때는 아이스크림 가게에 들렸다

더운 날씨에 지친 우리를 보셨는지, 교수님께서 아이스크림 가게를 제안하셨습니다. 근방에서 유명한 아이스크림 가게 Lindy Freeze로 다양한 맛의 아이스크림을 맛 볼 수 있었습니다.

날씨의 영향인지, 지친 몸에 단 음식을 먹어서인지 정말 환상적인 맛이었습니다. 이후 KSW에서 약간의 작업을 마무리 한 뒤, 하루가 마무리되었습니다.

07/09 (Wednesday)

Meshtastic과의 작별

많은 시도를 거쳤지만 실패했다

이번 수요일은 무척이나 힘든 하루였습니다. 아침부터 퇴근 이후까지 내내 Meshtastic을 공부했습니다. 어떻게든 Meshtastic을 사용함과 동시에 노드 간 조작을 실현하고 싶었습니다.

하지만 Meshtastic 펌웨어가 존재하는 상태로, 센서 데이터 전송과 하드웨어 제어 신호까지 시도하는 것은 매우 힘들었습니다. 마치 잘 차려진 요리에 새로운 토핑을 더하기 힘든 상황과 같았습니다. Akita Switching, Remote Hardware 등 여러 문서를 확인하고, 유튜브 영상 자료와 레딧의 글을 모두 살펴보았습니다. 하지만 결국 원활한 작동을 위해 추가적인 연산 기기가 필요하다는 결론을 내리게 되었습니다.

따라서 긴 시간 고민 한 끝에, ESP32 디바이스 하나만 사용하는 경우에는 Meshtastic 사용이 적합하지 않다고 판단했습니다. 조금 아쉽기는 했지만, 욕심을 버리고 처음부터 프로토콜을 제작하는 것에 합류하기로 결정했습니다.

07/10 (Thursday)

PlatformIO와 씨름

Heltec ESP32와 PlatformIO 사이의 호환이 맞지 않았다

오늘은 Meshtastic 조사를 그만두겠다고 팀원과 이야기를 한 뒤, 프로토콜 작업에 합류했습니다. 아주 기초적인 LoRa 간 통신은 Heltec V3 pingpong예제를 통해서 구현할 수 있었습니다. ArduinoIDE를 사용하면 Heltec ESP32 DEV Library에서 제공하는 예제 코드를 유용하게 사용할 수 있습니다. 이후에는 기존에 본인이 짜두었던 센서 코드와 결합하여, 센서로 데이터를 받아 전송하는 코드를 완성했습니다.

문제는 그렇게 되었을 때 하나의 ino 파일에 코드가 너무 길게 들어가게 되었던 것입니다. 따라서 파일 구조 분리를 편하게 하고자 Visual Studio Code에서 PlatformIO를 사용해 보기로 결정했습니다.

그렇게 6시간 동안 PlatformIO를 통해 코드를 업로드하려고 매달렸지만, 결국 실패했습니다. Heltec ESP32 V3 보드에 링킹을 할 수 없었고, 마땅한 정보도 찾기 힘들었기 때문입니다. 결국 다시 ArduinoIDE로 돌아와 거기서 작업을 이어가자고 결론을 내렸습니다.

점심으로 먹은 Einstein Bagel

이 날 점심으로는 Einstein Bagel을 먹었습니다. 부드러운 베이글 사이에 원하는 재료를 넣어서 샌드위치를 맛볼 수 있습니다. 베이글 하나는 양이 조금 부족하지만, 맛은 훌륭했습니다.

미국에 살며 외식비용을 감당하기 힘들다고 느껴지는 하루기도 했습니다.

07/11 (Friday)

하드웨어를 구상하다

기본적인 기능 개발이 모두 완료되었다

금요일이 되었을 무렵, 작동의 기초가 되는 코드는 모두 완성된 상태였습니다. 이제 센서들이 LoRa를 통해 메시지를 주고받으며, 데이터를 수집할 수 있게 되었습니다.

물론 멀티홉, 통신 프로토콜 등 네트워크 기능을 개선하기 위한 코드는 앞으로도 계속 추가되어야 합니다. 하지만 가장 기본적인 기능을 먼저 개발한 후, 점차 향상하는 전략을 취하고자 했습니다.

하드웨어에 대해 본격적인 고민을 시작했다

오후에는 본격적으로 하드웨어 구성에 대한 이야기를 나누었습니다. 처음에는 3D 프린터를 통해 우리 디바이스에 맞은 컨테이너를 제작하고자 했습니다. 하지만 교수님은 프로토타입이라는 취지에 맞는 새로운 방식을 우리에게 제안해 주셨습니다.

교수님은 아래와 같이 이야기해 주셨습니다.

3D 프린터를 사용하는 것은 생각보다 많은 시간이 소요될 수 있다. 실제 현장의 환경까지 고려하면 작업은 더욱 까다로워진다. 날씨나 벌레와 같은 외부 위협을 완벽하게 차단할 수 있는 컨테이너를 3D 프린팅 하는 일은 결코 간단하지 않다. 프로토타입 개발 단계에서는 이러한 제약을 극복하기 위해 더 큰 창의성이 필요하다. 예를 들어, 플라스틱 컵이나 박스와 같은 일상적인 물건을 활용하는 것도 유용한 대안이 될 수 있다.

하드웨어를 만드는 것에는 생각보다 고려 할 점이 많았습니다. 우리는 다시 브레인스토밍을 시작했고, 최종적으로 작은 플라스틱 박스를 선택했습니다. 여기에 몇 개의 환기구를 만들고, 기기를 적절하게 배치하면 좋은 프로토타입이 될 것이라는 생각이 들었습니다.

이후 몇 가지 잔업을 처리하고 어느덧 퇴근 시간이 다가왔습니다.

정말 눈 깜짝 할 사이에 3주차 활동이 끝났습니다.

이번 주에는 본격적인 작업 성과가 나기 시작 한 느낌도 들어 조금 뿌듯하기도 합니다.

다음 주에는 디바이스를 실제로 농장에 설치하는 계획을 실현 할 수 있었으면 좋겠습니다.

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (4) | 부제 : Long Weekend

모노산달로스 — Tue, 8 Jul 2025 09:48:18 +0900

Perdue University 2025 글로벌 연수 - 4

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

07/04 (Friday)

독립기념일

01234

Lafayette의 크고 작은 매장들

4th of July(Independence Day)는 미국의 독립기념일입니다. 1776년 영국으로부터 독립을 선언한 날으로, 미국 사람들에게는 애국심을 고취하는 큰 휴일로 여겨집니다. 국가적으로 불꽃놀이와 퍼레이드가 펼쳐지는 뜻깊은 기념일입니다. 올해는 금요일에 해당하여, 우리는 일요일까지 3일의 긴 휴가를 가지게 되었습니다.

물론 Purdue University가 위치한 인디애나에서도 마을 사람들이 모이는 축제가 펼쳐집니다. 우리는 낮 시간 동안 Lafayette의 여러 매장을 구경하기로 했습니다. 그리고 시간에 맞추어 불꽃놀이를 즐기러 이동하기로 결정했습니다.

독립기념일을 맞이하여 여러 매장에서 할인 행사를 진행하기도 했습니다. 일부 매장에서는 성조기나 행사 관련 상품을 팔기도 했습니다. 본인은 Dollor Tree(미국식 다이소)에서 작은 성조기 깃발을 구매하였습니다.

Boiling Seafood

이 날 저녁으로는 눈여겨보았던 Red Lobster 레스토랑을 찾았습니다. Red Lobster는 1968년 시작된 캐주얼 시푸드 레스토랑입니다.

우리는 Boiling Seafood를 주문하였습니다. 게, 새우 등 갑각류들로 가득한 만찬을 즐길 수 있었습니다.

엄청난 인파가 몰려들었다

식사 이후에는 축제가 열리는 Riehle Plaza로 이동했습니다. 도착하자마자 엄청나게 많은 사람들이 우리를 반겨주었습니다. 개중에는 성조기가 그려진 옷이나 빨강, 파랑, 하양으로 옷을 맞춘 사람들도 있었습니다.

이러한 사람들의 모습을 보며 미국인들이 조국을 얼마나 사랑하는지도 느낄 수 있었습니다. 많은 사람들이 자신의 나라를 자랑스럽게 여기고 있었고, 독립기념일을 진심으로 즐기고 있었습니다.

우리나라 혹은 자기 자신을 돌아보며 조금 먹먹하기도, 부럽기도 했습니다. 한국에서 열리는 광복절 행사에는 어떤가요? 분위기나 사람들의 인식이나 여러모로 부족하다는 생각이 들었습니다. 앞으로는 우리나라의 역사를 기념하는 날에 조금 더 관심을 가져보고자 다짐했습니다.

모두 모여 즐거운 시간을 보냈다

이윽고 10시가 되어 하늘이 어두워지기 시작했습니다. 그리고 곧 큰 소리가 울리며 불꽃놀이가 시작되었습니다. 불빛이 어둠을 밝히는 것을 넋 놓고 구경하며 그간의 힘든 시간을 덜어냈습니다.

독림기념일을 축하하며

07/05 (Saturday)

숨 고르기

체스 도구를 받았다

토요일은 전 날과 달리 좀 더 느긋한 시간을 보냈습니다. 몇몇 학생과 함께 수영도 하고, 체스도 두며 담화를 나누었습니다. 마음을 차분하게 만들며, 하루를 즐겼습니다.

07/06 (Sunday)

한인 교회

근처 한인 교회에 찾아갔다

긴 휴일의 마지막 날은 모두 함께 한인 교회에 찾아갔습니다. 기독교 신자인 한 학생이 우리 모두를 초대했고, 대다수가 흔쾌히 응했습니다. 본인 또한 종교를 가지고 있지 않지만, 이 날은 교회에 방문하기로 결정했습니다. 교회에서 차량을 보내주어 쉽게 이동 할 수 있었습니다.

7월 6일은 한인교회의 창립일이었습니다. 1시간 정도 예배 시간이 끝난 뒤 우리는 많은 한식을 대접받을 수 있었습니다. 미국에서 찾기 힘든 한식을 오랜만에 맛볼 수 있어 좋았습니다.

이 날은 해당 교회에 오랜 시간 머문 신도분이 떠나는 날이기도 했습니다. 그 신도분은 80년도에 미국으로 넘어오셔서 퍼듀 대학교를 졸업하시고 가정을 꾸리셨습니다. 그리고 곧 한국으로 돌아가게 되어 마지막으로 인사를 전하셨습니다.

여러 가지 말씀을 해주셨지만, 특히 두 가지가 기억에 남았습니다. 하나는 웃으면서 살아라. 둘은 미친 듯 살아라. 항상 당연하게 여기던 말이지만, 오랜만에 들으니 좋은 동기부여가 되기도 했습니다.

월마트에 다시 들렀다

교회를 나온 뒤에는 월마트에 다시 들러 몇가지 물품을 구매했습니다. 다양한 음식과 생필품으로 카트를 채우고 기숙사로 돌아왔습니다.

긴 휴일이 끝이 다가왔다

오늘로 연휴가 마무리되었습니다.

충분한 휴식을 취한 만큼, 다음 주도 무리 없이 프로젝트를 이어갈 수 있으리라 생각합니다.

앞으로 남은 날들도 힘내서 나아갈 수 있기를 바랍니다.

연휴의 끝

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (3) | 부제 : Carpe diem

모노산달로스 — Sun, 6 Jul 2025 04:18:11 +0900

Purdue University 2025 글로벌 연수 - 3

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

06/30

한 발짝씩 나아가자

본격적으로 팀을 나누었다

두 번째 주의 첫 아침이 찾아왔습니다. 이제 본격적으로 프로젝트 진행에 불을 붙일 시간입니다. 모두들 주말 동안 늘어진 몸가지를 정리하고 K-SW Square에 모였습니다. 테이블을 세 개를 나누어 팀 별 회의를 시작했습니다.

어느 때나 그러하듯이, 서로의 의견을 하나로 모으는 것은 생각보다 많은 시간이 필요했습니다. 특히 단어의 모호함은 이전부터 항상 대화의 발목을 잡고는 했습니다.

이번에는 매쉬 네트워크와 스마트 더스트가 그러했습니다. 팀원들이 생각하는 단어에 대한 개념이 달라, 소통에 어려움이 있었습니다. 누군가는 스마트 더스트 사이의 통신을 매쉬 네트워크와 같은 것으로 여기기도, 또 다른 누군가는 스마트 더스트를 이용한 새로운 통신 방법을 생각하기도 했습니다.

다행히 크고 작은 우여곡절이 있었지만, 모두의 의견을 하나로 모으는 데에 성공했습니다.

우리 팀은 기존 아이디어에서 최종적으로 몇 가지 구체화를 할 수 있었습니다.

하나는 스마트 더스트 사이의 프로토콜을 정의했습니다. 우리가 사용할 방식은 Min-Two Uniform Targets Protocol입니다. 이는 스마트 더스트간 통신 시에, 여러 노드들을 고려하여 최고의 전파 진전을 선택하는 프로토콜입니다.

다른 하나는 스마트 더스트 활용 방식에 대한 내용이었습니다. 기존에는 벌들이 살고 있는 벌통 자체에 포커스를 맞추었습니다. 하지만 조사 결과 이는 스마트 더스트의 활용과 거리가 먼 문제라는 것을 알게 되었습니다. 따라서 여러 공간에 퍼뜨리는 스마트 더스트의 개념에 맞추어, 벌통이 아닌 벌들이 수분을 하는 농장 환경 전체에서 정보를 얻는 것으로 목표를 정했습니다.

점심으로는 치폴레를 먹었다

그렇게 오전 시간이 지나고 점심으로 치폴레를 먹었습니다. 치폴레는 유명한 멕시칸 요리 체인점으로, 미국에서 큰 사랑을 받고 있습니다. 한국에서 비정상적으로 낮은 유명세가 신기할 정도입니다.

이전에 우버이츠를 통한 배달로도 미리 맛보았지만, 치폴레는 많은 사람들이 좋아하는 이유가 있다는 생각이 들었습니다.

이후에는 K-SW스퀘어로 돌아와 추가적인 회의를 진행했습니다. 특히 퍼듀 대학교 학생들 중 한 명인 'Bo'가 우리 팀에 합류하기로 결정했습니다. Bo는 우리 프로젝트 주제에 관심을 가지고 들어주었고, 몇 가지 생각을 공유하며 아이디어를 확장시켰습니다.

긴 시간 이어진 회의 탓인지, 익숙치 않은 영어를 계속해서 사용한 탓인지, 우리는 생각보다 빠르게 지친 모습을 보였습니다. 앞으로 적응을 해나가며 더 나은 체력을 가질 수 있으리라 희망합니다.

07/01

꿀벌과 함께

우리 팀 멤버, 나는 Bee Suit를 착용했다

화요일 아침, 다시 교수님의 농장으로 향했습니다. 우리는 벌들을 위해 어떤 것을 할 수 있을까 고민했고, 벌들이 살고 있는 환경을 관찰하기 시작했습니다.

교수님께서 기본적으로 사람이 관리하는 벌통의 구조에 대해 설명을 해주셨습니다. 그리고 벌들의 생활과 문제가 되는 점들에 대해 대화했습니다. 특히나 벌들이 정체불명의 이유로 계속 죽어가고 있고, 이는 상당히 심각한 문제라고 상기시켜 주셨습니다.

꿀벌들을 자세히 관찰할 수 있었다

여러 대화가 오간 뒤, 마지막으로 실제 양봉 일을 관찰했습니다. 필자는 Bee Suit를 입고 벌들을 가까이서 볼 수 있었는데, 평소에 쉽게 접하기 힘든 흥미로운 경험이었습니다.

그곳에는 네 개의 벌집이 있었습니다. 가장 흥미로운 것은 이유를 모른 채 벌들이 죽은 벌집이었습니다. 그곳을 열어보니 벌들이 아닌 다른 벌레들이 가득했습니다. 특히 작은 딱정벌레들이 많았고 이를 위한 전용 함정까지 설치되어 있었습니다.

마지막으로 벌들의 생존에 가장 위협이 되는 것은 Mite(응애)와 딱정벌레라고 조언을 받을 수 있었습니다.

Jennifer의 강아지

오후에는 식사를 마치고 다시 K-SW스퀘어로 돌아왔습니다. 그리고 그곳에서 퍼듀 학생인 Jennifer의 강아지가 우리를 반겨주었습니다.

Bo가 우리의 대화를 정리해주었다

이후 우리는 프로젝트 진행에 대해 다시 이야기했습니다. 여러 대화를 주고받았고, 다음과 같은 결론을 내렸습니다.

벌들의 문제를 찾는 데에 너무 많은 시간을 사용하지 않는 게 좋겠다. 스마트 더스트를 활용한 데이터 수집에 집중하자.

양봉장과 벌집의 데이터를 잘 수집할 수 있다면, 이는 양봉업자들에게 큰 도움이 될 것이라는 교수님의 조언을 받아들였습니다. 특히 기존 제품이 너무나 비싼 가격으로 형성되어, 양봉업자들은 쉽게 사용하지 못하고 있는 상황이었습니다.

따라서 우리는 스마트 더스트를 활용해 양봉장의 데이터를 저렴하게 수집하는 것에 집중하기로 결정했습니다.

이후에는 디바이스를 위한 몇가지 센서와 기기를 조사하면서 시간을 보냈습니다.

07/02

기기 점검과 시스템 아키텍처

아침에 본 멋진 올드카

다시 새로운 아침이 찾아왔습니다. 숙소에서 K-SW Square로 걸어서 이동하면 20분 정도 소요됩니다. 그동안 아름다운 캠퍼스와 미국 환경을 구경할 수 있었습니다.

시스템 설계를 정리했다

이 날 오전, 모두 화이트보드 앞에 모여 대화를 시작했습니다. 기술명세서 작성을 위하여, 지금까지 나누었던 아이디어를 글과 그림으로 정리했습니다. LoRa를 사용한 노드와 마스터노드간 통신, 그리고 서버와 유저까지 이어지는 아키텍처를 구상했습니다. 거기에 각 디바이스에 필요한 기능들 또한 정리했습니다.

이전까지 말로만 이야기 했던 아이디어를 시각적으로 정리했을 때 좋은 점이 많았습니다. 우리는 이제 모두 한 방향을 바라볼 수 있게 되었고, 더 원활한 소통이 가능해졌습니다. 또한 이로써 교수님께 구체적인 피드백을 요청드릴 기반이 세워졌습니다.

이후에는 교수님과 함께 추가적인 IoT기기를 받기 위하여 이동했습니다. 여러 기기들이 있었지만, 특히 LoRa 통신의 핵심인 Heltec ESP32를 5개 정도 챙길 수 있었습니다.

캠퍼스 앞에 위치한 골동품 가게

그렇게 오전 회의를 마치고는 점심을 먹기 위하여 이동했습니다. 우리는 어느덧 익숙해졌는지, 교수님 없이도 편안하게 캠퍼스를 돌 수 있었습니다.

점심을 먹고난 뒤에는 주변 가게를 둘러보았습니다. 골동품 가게가 크게 눈에 띄었는데, 다양한 물품들로 가득했습니다. 한국으로 돌아가기 전에 다시 들러 몇 가지 사 오고자 생각했습니다.

고장난 ESP32들

다시 K-SW Square로 돌아온 이후에는 오전에 가져온 기기들을 살펴보았습니다. 그리고 프로토타입을 어떻게 만들 수 있을지 조사에 착수했습니다.

그런데 한 가지 문제가 발생했습니다. 다섯 개의 ESP32 기기 중 세 개가 제대로 동작하지 않았습니다. 저는 여러 번 테스트를 거쳐 이 사실을 확인한 뒤 교수님께 보고드렸습니다. 교수님께서도 몇 가지 테스트를 해보셨지만, 결국 해당 기기들은 모두 폐기처분하게 되었습니다.

새로운 기기를 주문하기로 결론이 내려졌고, 우리는 우선 두 개의 기기를 먼저 사용하기로 결정했습니다.

교수님께서 아키텍처에 대한 설명을 해주셨다

이후에는 교수님과 모든 팀 멤버가 한 방에 모였습니다. 교수님께서는 LoRa와 LoRaWAN을 활용한 두 가지 아키텍처를 설명해주셨습니다.

하나는 오른쪽 그림의 LoRaWAN 표준 활용 방식입니다. LoRaWAN Gateway에 각 노드들이 직접적으로 신호를 보낼 수 있습니다. 그리고 받은 신호를 인터넷을 통하여 전송이 가능합니다.

두 번째는 왼쪽 그림의 Meshtastic 방식의 LoRa 활용입니다. 각 노드들이 Mesh-Network구조를 취하고 있으며, 서로 신호를 중계할 수 있습니다. 이 방식은 우리가 활용하려는 농장형 스마트 더스트 구조에도 잘 맞고, 구현하기도 쉽다는 말씀을 해주셨습니다.

추가적으로 한 가지 의문이었던 마스터 노드와 인터넷의 연결에 대한 조언도 해주셨습니다. 결론적으로는 LoRaWAN, Cellular, Wi-Fi 어느 것을 사용해도 상관이 없습니다. 우리가 보내는 데이터에 적절한 것을 선택하면 됩니다.

교수님의 설명이 끝난 뒤, 점점 구색이 갖추어지는 모습에 기분이 좋아지기도 했습니다. 어느새 프로젝트에 대한 애정이 점점 커져가는 느낌을 받기도 했습니다.

그렇게 얼마 지나지 않아, 어느새 다시 퇴근 시간이 다가왔습니다.

오랜만에 혼자만의 시간을 보냈다

어느새 미국에 온 지 일주일이 지났습니다. 지난 한 주 동안은 늘 누군가와 함께 시간을 보냈기에, 오늘 저녁만큼은 오랜만에 혼자만의 시간을 보내기로 했습니다.

오랜만에 단체 생활을 하며 조금씩 지쳐갈 무렵, 한 가지 생각이 들었습니다. 나는 주기적으로 개인적인 시간을 가져야 하는 사람이구나 싶었습니다. 사람들과 어울리는 것이 싫거나 힘든 것은 아니었습니다. 그동안 다양한 인간관계를 겪으며 성장해 왔고, 예전보다 훨씬 능숙해지고 있다는 느낌도 들었습니다.

하지만 그와는 별개로, 사람들 앞에서 나 자신을 유지하기 위해 사용하는 에너지는 상당히 크다는 것을 느꼈습니다. 그래서 때로는 혼자 밖으로 나와 시간을 보내는 것도 필요하다는 것을 알게 되었습니다.

07/03

What is Meshtastic?

Meshtastic에 대해 조사를 시작했다

목요일 아침에는 이전에 교수님께서 언급하신 Meshtastic을 조사하기 시작했습니다. Meshtastic은 Mesh + Fantastic의 합성어로, 오픈소스 장거리 무선 매쉬 메세징 시스템입니다.

조금 더 풀어서 설명하자면 아래와 같습니다.

1. Meshtastic은 LoRa 무선 칩을 활용하여, 인터넷이 없는 환경에서도 여러 기기가 서로 메시지를 주고받을 수 있도록 해주는 오픈소스 시스템입니다.
2. 여러 노드가 메시지를 중계해 주는 ‘메쉬’ 구조를 사용하므로, 아주 먼 거리까지도 메시지 전달이 가능합니다.
3. 따라서 산, 농장, 캠핑장 등 통신망이 없는 곳에서도 스마트폰이나 보드로 손쉽게 텍스트 메시지를 주고받을 수 있습니다.

즉, 넓은 농장의 많은 디바이스로 데이터를 모으고 전송하기에 매우 적합한 형태입니다. 우리는 조사를 마치고서야 교수님께서 언급하신 이유를 알게 되었습니다.

한 팀원이 디바이스 제작을 전담했다

오후에는 각자 자율적으로 프로젝트를 진행했습니다. 한 팀원은 IoT 경험이 풍부해, 작동 가능한 기기를 직접 제작하고 있었고, 퍼듀대 학생인 Bo는 라즈베리 파이로 서버를 구축하는 데 집중하고 있었습니다.

반면, 저를 포함한 나머지 두 팀원은 맡은 역할이 마땅치 않아 손이 비어 있는 상황이었습니다. 그래서 마지막 단계에서 만들기로 했던 애플리케이션을 지금부터 개발하는 게 좋지 않겠냐는 제안을 했고, 자연스럽게 그 방향으로 의견이 모였습니다.

그렇게 몇 가지 요구사항을 정리하며 오후 시간을 보냈습니다.

휴일 전에 모두 모여 밤 시간을 보냈다

7월 4일, 내일은 미국의 큰 공휴일입니다. 그래서 우리는 모두 모여 휴일 전날을 함께 즐기기로 했습니다. 그중에는 다른 프로그램에 참가한 한국 학생들도 있었습니다.

시간을 보내던 중, 우연히 함께 프로젝트를 하고 있는 퍼듀 학생 Jennifer와 그녀의 친구들을 만나게 되었고, 자연스럽게 카드게임을 하며 미국 학생들과 즐거운 시간을 보낼 수 있었습니다.

이 날 들었던, 한 가지 생각이 들었습니다. 아직도 제 영어 실력은 많이 부족하다는 점입니다. 특히 언어의 본질적인 목적이 타인과 생각을 나누고 가까워지는 것이라면, 그 부족함은 더욱 크게 다가왔습니다.

출국 전, 말하기 연습을 충분히 하고 어느 정도 자신감을 가지고 왔습니다. 실제로 교수님과의 대화나 1:1 상황에서는 그 노력이 효과를 발휘하기도 했습니다. 하지만 여러 미국 대학생들이 함께 어울려 대화할 때는 사정이 조금 달랐습니다.

그렇게 느낀 이유는 이렇습니다. 우선 공식적인 정보를 주고받는 대화보다, 농담을 주고받거나 감정을 솔직하게 표현하는 대화가 훨씬 더 어렵게 느껴졌습니다. 그런 대화는 연습해 본 적이 거의 없었기 때문에 더욱 낯설고 힘들었습니다.

게다가 ‘실수’에 대한 두려움도 더 크게 다가왔습니다. 또래들과 어울리는 자리, 특히 즐거운 술자리에서 말을 잘 못하는 모습을 보이고 싶지 않다는 감정은, 말하기 실력 향상을 막는 큰 장애물처럼 느껴졌습니다.

그렇게 오늘은 제 부족함을 다시금 느낀 하루였습니다. 다음에 기회가 온다면, 어떤 말이라도 주저하지 않고 용기 내어 던져보겠다고 다짐했습니다.

한국에 있을 때와는 달리, 이곳에서는 좀 더 즉흥적이고 편안한 기분이 듭니다. 첫날 교수님께서 말씀하신 것처럼, 지금까지의 모든 스트레스는 잠시 내려놓고 이 순간에 집중하며 남은 시간을 마음껏 즐겨야겠습니다.

내일은 미국의 독립기념일로, 전국 곳곳에서 불꽃놀이와 퍼레이드 등 다양한 행사가 펼쳐지는 특별한 날입니다. 금요일부터 일요일까지 이어지는 긴 연휴 동안 충분히 쉬고 재충전하여, 다음 주를 더욱 활기차게 시작할 수 있도록 하겠습니다.

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (2) | 부제 : 천천히 하지만 올바르게

모노산달로스 — Tue, 1 Jul 2025 10:13:50 +0900

Purdue University 2025 글로벌 연수 - 2

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

06/26

이정표를 세우다

드디어 K-SW Square에 방문했다

목요일 아침 9시, 우리는 모두 K-SW Square에 모였습니다. 이곳은 낡은 교회를 개조하여 만들어졌는데, 오직 Korean Software Square summer 2025에 참가한 학생들을 위해서만 사용됩니다. 즉, 앞으로 우리가 연구 작업을 이어나갈 주요한 일터가 되는 곳입니다.

현지 교수님들이 앞으로의 방향을 알려주셨다

오전 시간 동안은 현지 교수님들의 주도로 다양한 정보를 제공해 주셨습니다. 앞으로 프로그램이 어떻게 진행되는지, 우리가 무엇을 생각하고 얻어야 하는지에 대하여 알려주셨습니다.

교수님께서 강조하신 부분은 아래와 같습니다.
1. 한국처럼 정해진 일을 하는 것이 아니라 스스로 찾아야 한다.
2. 일과 이후에 무엇을 하든 자유이지만, 많은 사람을 만나라.
3. 새로운 환경에 적응하는 능력을 길러라.

많은 부분을 이야기해 주셨지만, 위 세 가지가 가장 핵심이 되는 부분이었습니다. 첫 번째로 프로젝트 진행 방식을 이야기 해주셨습니다. 자신들은 어떤 것도 시키지 않고 그저 옆에서 지원을 할 뿐이라고 말해주셨습니다. 한국과 미국의 문화 차이는 따로 글을 써내고 싶을 만큼 다른 점이 많습니다. 그중 하나인 자율성에 대해서 교수님이 특히 강조를 많이 하셨습니다.

또 다른 요점은 여러 사람과 만나는 것입니다. 영어 실력은 학생들마다 천차만별이었지만, 대다수는 영어 능력의 향상을 기대하고 있는 상황입니다. 그리고 이 프로그램은 훌륭한 영어 교육 환경입니다. 따라서 자유 시간에 방에 혼자 있기보다는, 밖으로 나가 여러 외국인을 상대하는 시간을 가지는 것이 중요하다고 말씀해 주셨습니다.

마지막으로 우리가 얻어가야 할 것에 대해서도 말씀을 해주셨습니다. 물론 전공 지식, 영어, 사람들과의 소통 능력 등 학생들마다 각자가 목표하는 바는 모두 다를 것입니다. 하지만 교수님께서 강조하신 단 하나는, 새로운 것에 대한 적응이었습니다. 모든 것이 낯선 이 프로그램에서 적응력을 기르는 것이야 말로 최고의 성과가 될 수 있다고 말씀해 주셨습니다.

점심으로는 판다 익스프레스에 들렀다

그렇게 오전이 빠르게 흘러가고, 점심을 먹기 위해 식당에 들렀습니다. 판다 익스프레스는 미국식 중화요리 레스토랑입니다. 원하는 메뉴를 몇 가지 골라 플레이트에 담아 먹을 수 있습니다.

메뉴에는 좋아하는 새우 요리가 가득했기에, 행복한 점심시간을 보낼 수 있었습니다.

자기소개 시간을 가지게 되었다

점심식사를 마치고, 다시 K-SW Square로 돌아왔습니다. 이번에는 학생들 간의 자기소개 시간이 이루어졌습니다. 각자 자신의 배경과 역량 그리고 반드시 자신의 특별한 점을 이야기해야 했습니다. 남들과 차별점을 가지는 자신만의 것이 있는 것은 굉장히 중요했습니다. 특히 미국에서는 더더욱 그러한 능력을 높게 평가하는 듯했습니다.

필자는 그러한 차별점으로 세 가지를 이야기했습니다. 하나는 글쓰기 실력, 두 번째는 창업에 대한 열망, 세 번째는 일본어 능력입니다. 각자 다른 부분에서 일반적인 컴퓨터공학부 학생들과 자신을 다르게 만든다고 생각 했습니다.

많은 학생들이 자기소개를 진행했고 이후에는 프로젝트 아이디어에 대해서 이야기를 하기 시작했습니다. 기존에 생각한 아이디어가 존재했지만 이번에는 잠시 접어두기로 결정했습니다. 왜냐하면 하드웨어와 결합하는 프로젝트, 그리고 미국에서만 가능한 프로젝트가 너무나 매력적으로 느껴졌기 때문입니다.

그렇게 조금은 얼렁뚱땅 세 개의 팀이 만들어지게 되었습니다. 이후부터는 각자 팀 별로 나누어져 간단히 생각을 공유하기 시작했습니다. 그 결과 우리 팀은 미국 농장에서 벌어지는 문제를 스마트더스트와 드론으로 해결하자는 투박한 목표를 세울 수 있었습니다.

0123

아름답고 편리한 공간이 정말 많았다

그렇게 오후 4시가 다 되어갈 무렵 회의를 잠시 중단했습니다. 모든 학생들이 다시 하나로 모여 캠퍼스 투어를 진행하게 되었습니다. 명문대학교의 명성에 걸맞게 정말 크고 아름다운 공간으로 가득했습니다. 또, 학생들이 이용할 수 있는 편리한 시설도 즐비해있었습니다.

특히 기억에 남는 것은 학교의 이름을 사용하는 의류나 문구들이 가득한 매장이었습니다. 뛰어난 명성 그리고 최고의 환경을 가진 대학교가 주는 매력은 엄청났습니다. 많은 사람들이 퍼듀 대학교 로고가 새겨진 옷을 구매하고 입는 것이 당연하게 여겨질 정도였습니다. 이 멋진 문화가 한 편으로는 부럽기도 했습니다.

캠퍼스 투어 이후에는 모든 일정이 종료되어 각자 숙소로 향했습니다. 필자 또한 간단히 운동을 마치고 달콤한 휴식을 취했습니다.

06/27

끝없이 펼쳐지는 미국의 농장

012

광활한 대지가 눈 앞에 펼쳐지다

네 번째 아침이 밝고, 오늘은 실제 미국 농장을 견학하는 일정이 있었습니다. 교수님들은 학교에서 멀지 않은 곳에 농장을 소유하고 있었습니다. 우리는 캠퍼스에서 약 20분 정도 교수님의 차량을 통해서 농장으로 향했고, 그곳에는 생전 보지 못한 넓은 농작지가 펼쳐져있었습니다. 특히 수많은 옥수수 잎들이 바람에 몸을 숙이는 모습은 눈이 부실 지경이었습니다.

그리고 잠시 뒤, 넓은 초원을 지나 나무 농장 안으로 들어갔습니다. 그곳에서 죽은 나무, 코요테, 아이비 등 다양한 이야기를 해주셨습니다. 결론적으로 미국의 농장은 한국과는 너무나 다른 환경과 문제를 가지고 있었습니다.

여러 환경을 구경하다 보니 어느덧 오전 시간이 끝이 나 있었습니다. 우리는 어떤 문제를 정의하면 좋을지 계속해서 소통하며 농장을 빠져나왔습니다.

점심 식사는 Mad Muschroom 피자를 먹었다

점심시간에는 캠퍼스에 있는 유명한 피자 레스토랑 Mad Mushroom을 방문했습니다. 이번 식사에는 앞으로 프로젝트를 함께 할 퍼듀 대학교 학생들이 함께했습니다. 현지 학생과 일상적인 이야기부터 프로젝트에 대한 고민까지 함께하며 식사를 진행했습니다.

오후에는 프로젝트의 결을 잡아갔다

식사 이후에는 다시 K-SW Square에 모두 모여들었습니다. 오전에 확인했던 농장 환경을 보며 각 팀별로 프로젝트의 방향을 잡아갔습니다. 몇 시간의 회의 끝에, 기존의 정보 수집과 전송에 대한 방법을 개선이라는 아이디어가 도출되었습니다. 저렴한 스마트 더스트를 여러 개 활용하여 정보를 수집하고, 정보 전달의 중심이 되는 큰 노드 하나가 모든 정보를 모아 전송하는 시스템을 구축해 보는 것을 계획했습니다.

교수님은 우리 아이디어에 대해 여러 가지 조언을 해주셨는데, 하나는 우선 노드(스마트 더스트) 간 정보 전달에 집중하라고 이야기해 주셨습니다. 우리는 드론을 사용하고 싶은 욕심도 있었지만, 우선 노드 간 통신이 잘 동작하는 것이 우선순위라는 것을 이해하게 되었습니다.

또 다른 조언으로 양봉장에서 활용을 이야기 해주셨습니다. 리는 어떤 정보를 수집할지에 대해 논의를 이어가고 있었는데, 양봉장은 우리의 좋은 타깃이 될 수 있었습니다.

그렇게 오후 4시 즈음 어느 정도 프로젝트에 대한 윤곽을 잡아갈 수 있었습니다. 각 팀이 회의를 끝내갈 때 즈음, 학교의 연구실 견학을 위하여 1시간 일찍 일정이 종료되었습니다.

연구실 건물 옥상에서 마주한 풍경

연구실 동은 학교의 다른 시설과 마찬가지로 엄청난 규모를 자랑했습니다. 거대한 전산실을 확인했을 때는 모두 입을 벌릴 수밖에 없었습니다.

우리는 연구실을 가볍게 구경한 뒤, 교수님과 창고에 도착했습니다. 그리고 그곳에서 프로젝트에 필요한 몇 가지 전자 장치들을 받을 수 있었습니다.

이후 마지막으로 옥상에서 퍼듀 대학교의 전망을 내려다볼 수 있었습니다. 그렇게 넓은 캠퍼스를 바라보며 오늘 하루 일정도 마무리되어 갔습니다.

지친 몸을 이끌고 밤 거리를 걸었다

모든 일과가 끝나고 오늘도 다시 체육관으로 향했습니다. 그리고 그날 밤에는 현지 학생이 알려준 매장에 방문하기로 했습니다. 연달아 이어지는 일정이 피곤하기도 했지만, 프로그램에서 한 시도 낭비하고 싶지 않았습니다.

그렇게 깊은 밤 동안 처음 보는 외국인들과 대화를 하려고 노력했습니다. 여전히 빠르게 말을 내뱉는 사람들의 말은 알아듣기 힘들었는데, 시끄러운 노래가 더해지니 더욱 소통이 어려웠습니다. 특히 우리가 지금 들어온 영어와 달리 사투리가 심한 경우 그 난이도는 배가 되었습니다.

제 자신의 능력이 아쉽기도 했지만, 한 편으로는 더 열심히 영어에 익숙해져야겠다는 다짐을 하게 되었습니다.

06/28

처음 맞는 주말 하루

시내 버스를 타고 이동했다

다섯 번째 아침을 마주했습니다. 오늘은 몇몇 친구들과 함께 월마트에 방문할 예정입니다.

오전 시간에는 나중에 있을 여행에 대한 계획을 세우고, 점심 먹기 위해 밖으로 나갔습니다.

점심 식사는 웬디스 햄버거를 선택했다

한 번쯤 먹어보고 싶었던 웬디스 햄버거가 캠퍼스 주변에 있었습니다. 우리는 만장일치로 빠르게 식사 메뉴를 결정했습니다.

식사를 하며 우리는 한 가지 약속을 했습니다. 한국인들만 있지만 우리는 영어로 대화하자. 다들 학습에 대한 열정이 강했고, 특히 영어에 대한 마음은 모두 하나였기에 우리는 이 시간 이후 계속 영어를 사용하기 시작했습니다.

식사 이후에는 월마트에 방문했습니다. 한국 마트와는 다르게 층계가 나누어져 있지 않고 큰 하나의 층만 존재했습니다. 우리는 개개인이 필요한 상품을 추가로 구매했습니다. 사실 이전에 교수님들이 기본적인 물품은 전달해주셨지만, 몇 가지 물품은 직접 골라야 했기 때문입니다.

모든 쇼핑이 끝나고 숙소에 향하기 전 잠시 북스토어(퍼듀 대학교 기념품 매장)에 방문했습니다. 그렇게 모든 일정을 끝마치고 숙소에 도착했을 때는 어느덧 오후 5시가 넘어있었습니다. 분명 12시에 숙소에서 출발했지만, 긴 이동시간 덕에 예상보다 오래 밖에서 시간을 보내게 되었습니다.

그동안 끝 없이 이어진 야외활동에 지쳐 오늘 저녁은 책상 앞에서 시간을 보내기로 합니다. 밀렸던 글을 작성하고, 멜라토닌을 하나 삼키며 하루를 마무리합니다.

06/29

첫 주를 마무리하며

수영과 함께 하루를 시작하다

드디어 첫 주의 마지막 해가 떠올랐습니다. 그간 쌓였던 피로를 풀고 조금은 느긋하게 기상하였습니다. 그리고 그간 미루어두었던 수영장을 몇몇 학생과 같이 방문했습니다. 오랜만에 하는 수영은 상당히 힘에 부쳤지만, 그만큼 즐거운 시간이었습니다.

COREC(퍼듀 대학교 내부 체육관)은 한 달에 40달러를 내고 이용할 수 있습니다. K-SW 프로그램 참여 학생들은 무료로 사용이 가능한데, 이를 모른채 처음 도착한 날 필자를 포함한 세 명의 사람들이 결제를 했습니다. 하지만 일주일이 되어가는 지금까지 전산상으로 넘어가지 못했고, 결과적으로 이는 좋은 선택이 되었습니다.

로비에서 다음 주를 위한 공부를 진행했다

수영 이후에는 오랜만에 혼자만의 시간을 보내게 되었습니다. 이번 프로그램에서는 IoT기기를 사용하는 특성상 LoRa 및 LoRaWAN에 대한 개념이 굉장히 중요합니다. 이에 대해 평일 중에 네트워크 교수님께서 직접 강의를 진행해주시기로 하셨기에, 미리 예습을 하기로 결정했습니다.

LoRa는 IoT기기 사이에서 주로 사용되는 장거리 저전력 무선 통신 기술입니다. 인터넷을 사용하는 것 보다 더 빠르고 저렴하게 사용할 수 있어 주목받는 기술입니다. LoRaWAN은 LoRa 위에서 동작하는 네트워크 프로토콜으로, 데이터 전송 방식을 정의합니다.

LoRa는 물리적으로 전달하는 도구, LoRaWAN은 전달하는 방식으로 간단히 비유 할 수 있겠습니다. 기본적인 개념을 이해한 뒤,

저녁 시간은 여행에 대한 이야기가 오갔다

시간이 지나 저녁을 먹고 난 뒤에는 모든 학생이 한 자리에 모였습니다. 우리는 앞으로 있을 여행 계획을 준비하고자 했습니다. 평일에는 아침부터 저녁까지 업무 시간이 고정되어 있습니다. 하지만 주말에는 완전히 자유로운 시간이 주어지기에, 이를 알차게 사용하고자 하는 마음이 모두 통했던 것 같습니다.

그렇게 대화는 점점 길어졌습니다. 그랜트 캐니언, 플로리다, 뉴욕과 같은 다양한 장소가 후보에 올랐습니다. 결국 여행지를 확정 하지는 못했지만, 추후 다시 모두의 의견을 모을 시간을 가지기로 결론을 내렸습니다.

드디어 길고도 짧았던 한 주가 끝이 났습니다. 이번 주는 마치 본격적인 프로젝트의 첫 단추를 잠그는 것과 같다고 생각합니다.

마라톤 같은 7주일의 시간이 지나고 무엇을 남기면 좋을까요?

영어 실력, 전공 지식 그게 아니면 그저 즐거운 추억으로 만족하면 되는 것일까요?

많은 사람들이 이야기하듯, 빠르게 걸어가는 것 보다 느리지만 올바른 방향으로 걷는 것이 중요합니다. 그간의 며칠은 앞으로 7주간 어느 방향으로 나아갈지를 결정하는 중요한 하루들이었습니다.

좋은 방향을 잡았으니 앞으로 남은 시간은 열심히 달리는 것에 집중할 것이라 다짐합니다.

새로운 경험이 가득한 앞으로를 기대하며

[Purdue] 퍼듀 대학교 2025 글로벌 AI 연수 (1) | 부제 : 이방인

모노산달로스 — Fri, 27 Jun 2025 12:44:47 +0900

Purdue University 2025 글로벌 연수 - 1

Purdue University

퍼듀 대학교는 미국 인디애나주에 위치한 공립 연구 중심 대학입니다. 공학과 항공 우주, 농업, 컴퓨터 과학 분야에서 우수한 평가를 받고 있는데요, 특히 NASA 우주비행사 닐 암스트롱을 포함해 많은 유명 동문을 배출한 것으로 잘 알려져 있습니다.

이러한 명문 대학교에서 매년 한국 학생들을 초청하여 K-SW Square에서 교육을 진행하고 있습니다. 이러한 좋은 기회를 경기대학교 소프트웨어 중심대학의 혜택으로 여름 방학 기간 동안 다녀올 수 있게 되었습니다. 이하 내용은 프로그램 진행 동안 일어난 경험이 기술되어 있습니다.

06/24

시카고로 출발하다

각 대학교의 학생들이 공항으로 모여들었다

2025년 6월 24일 이른 아침, 우리는 무거운 캐리어를 이끌고 인천 공항에 모였습니다. 비자 인터뷰 이후 처음 보는지라 다들 아직 서먹한 기운이 역력했습니다. 해당 프로그램을 지원하는 IITP의 박장순 책임님께서 마지막 지도를 도와주셨습니다. 주의사항 및 명심해야하는 부분들을 확인하고 우리는 게이트를 향했습니다.

무거운 강철을 타고 하늘을 날았다

탑승 수속은 순조롭게 진행되었고, 우리는 여객기에 탑승했습니다. 다들 부푼 마음을 가지고 저마다의 생각을 가지며 13시간을 비행했습니다.

시카고 공항에 도착하다

긴 비행 끝에 시카고 공항에 무사히 도착 할 수 있었습니다. 앞으로 프로그램을 지도해주실 두 분의 교수님이 우리를 반겨주셨습니다. 에릭 교수님은 AI와 드론의, 토니 교수님은 통신 분야의 매우 뛰어난 전문가 분들이십니다.

그렇게 가볍게 첫 인사를 나누고 인디애나주의 퍼듀대학교 기숙사로 이동하기 위해서 교수님의 픽업 트럭에 탑승했습니다. 그렇게 약 3시간의 주행이 이어졌습니다. 미국이 정말 큰 땅을 가진 나라라는 것을 육지에 발을 내딛은 순간 부터 체감하게 되었습니다.

주행동안 이어진 풍경은 정말 놀라웠습니다. 가장 먼저 한국에서 볼 수 없는 넓은 대평원이 눈에 들어왔습니다. 이후에는 거대한 트럭, 아름다운 건물들이 차례로 모습을 드러냈습니다.

중간에 잠시 점심식사를 위해 Chick-Fil-A에 들렀다

긴 여정 중 점식 식사를 위해 Chick-Fil-A라는 매장에서 잠시 시간을 보냈습니다. 한국의 맘스터치 처럼, 닭고기 햄버거를 메인으로 하는 패스트푸드 체인점입니다. 이때 미국에서의 첫 식사라고 부를 수 있는 경험을 하게 되었는데, 역시나 강한 짠 맛과 무거운 치즈로 가득했습니다.

분명 맛있는 음식이었지만, 미국식 식단에 조금 적응을 해야 할 필요도 있겠다는 생각을 했습니다.

퍼듀 대학교에 도착하다

퍼듀 대학교 기숙사에 도착하다

그렇게 다시 긴 시간이 지나고, 오후 5시 퍼듀 대학교 기숙사에 도착하게 되었습니다. 우여곡절 끝에 도착한 방은 깔끔하고 좋은 시설이었습니다. 12명의 학생은 2명씩 룸메이트가 되어 방을 사용하였습니다. 화장실 및 샤워실은 모두 공용 시설이었는데, 군 시절이 머리속을 잠시 스쳐지나가기도 했습니다.

우리는 짐을 정리했습니다. 내일은 교수님과 월마트에 들러 추가적인 물품을 구매하기로 약속하고 각자 휴식 시간을 가지게 되었습니다.

캠퍼스에 거대한 스포츠 센터가 존재했다

긴 이동 시간 탓에, 몇몇 학생은 지친 나머지 이른 잠에 들었습니다. 하지만 본인을 포함한 일부 학생은 아쉬운 마음에 저녁 식사와 함께 스포츠 센터를 둘러보기로 했습니다.

퍼듀 대학교 캠퍼스는 정말 거대했습니다. 그리고 그 크기에 어울리게 정말 많은 건물이 존재했습니다. 그 중 Recreational Sports Center는 가장 눈에 띄는 건물이었습니다. 그 내부에는 헬스장, 수영장, 농구장을 더불어 러닝 트랙과 클라이밍 시설도 존재했습니다. 미국이 스포츠에 열광하는 나라라는 것이 다시 한 번 느껴지는 건물이었습니다.

수영 하는 것을 좋아하기에, 내일 아침에는 운동을 좋아하는 친구와 함께 스포츠 센터 회원에 등록하기로 했습니다. 앞으로 한 달 넘짓한 기간 동안 애용하게 될 것 같습니다.

캠퍼스에서 저녁을 먹으며 하루를 마무리했다

여름방학인 퍼듀 대학교에는 생각보다 많은 학생들이 모여있었습니다. 여름 방학을 맞아 고등학교에서 체험을 온 학생들이 정말 많았습니다. 모두 스포츠 클럽에 속한 듯한 모습을 풍기고는 했습니다.

우리는 많은 인파와 어색한 상황 속에서 어떻게든 음식을 골라 자리를 잡았습니다. 휴식 없는 일정에 지친 탓도 있었겠지만, 정말 수 많은 외국인이 모여있는 공간은 강한 압박이 느껴졌습니다. 해외에서 기를 펴지 못하는 사람들의 심정을 이해하는 순간이기도 했습니다.

그럼에도 나 자신은 그렇게 주눅 들어서는 안된다고 생각했습니다. 미국에 오기 전 했던 생각을 다시 떠올렸습니다. 소통에도, 학습에도 언제나 당당하게 행동하자. 자신감을 가지고 남은 기간을 보내자. 굳게 다짐하며 잠에 들었습니다.

06/25

상쾌하게 마주한 아침

012

어제 계획한 스포츠 센터에 다시 찾아갔다

두 번째 아침이 밝았습니다. 전 날 피로 때문인지, 멜라토닌의 효과인지 이른 저녁 9시에 잠에 들었습니다. 그 결과 아침 6시에 좋은 컨디션으로 하루를 시작할 수 있었습니다.

계획한대로 스포츠 센터에서 하루가 시작되었습니다. 헬스장에서 1시간 정도 시간을 보내고 다시 기숙사로 돌아와 식사를 마쳤습니다. 전 날에는 자극적이라고 느껴진 음식들이, 좋은 컨디션 덕분인지 술술 넘어갔습니다.

국제 학생을 위한 강의를 들었다

오후에는 ISS(International Students and Scholars)에서 국제 학생들을 위한 주의사항과 비자에 대한 정보를 알려주셨습니다. 가장 기억에 남는 부분은 J-1 Visa에 대한 내용이었습니다. 일부 학생들은 Two-Years Rule이 적용되었는데, 이 경우 한국으로 돌아간 이후 2년간은 다른 비자로 미국에 돌아올 수 없습니다.

012

어쩌면 마지막일 수 있는 편안한 휴식

입국 이틀차까지는 자유시간이 많이 주어졌습니다. 본격적인 프로젝트 시작 전 우리는 많은 휴식 시간을 가질 수 있었습니다. 그리고 마지막 날 당일은 모두 함께 캠퍼스 근처의 펍으로 향했습니다. 그 곳에서 미국 사람들이 어떻게 술을 즐기는지 또한 구경할 수 있었습니다.

특히 Harry's Chocolate Shop은 동네에서도 상당히 유명한 가게였습니다. 이 곳에 가니 메뉴에 술이 없었고, 원하는 칵테일의 레시피를 직접 주문해야 했습니다. 우리는 직원분의 추천으로 각자 좋은 술을 하나씩 맛 볼 수 있었습니다.

마치며

명문 대학교란 이런 것이구나 몸소 체험할 수 있었다

퍼듀 대학교에서 이틀이 지났습니다. 본격적으로 프로젝트가 시작하기 전 휴식과 적응의 기간을 거치며 몸과 마음을 다스렸습니다. 밖에 나서면 보이는 날씨, 건물, 사람들 그리고 문화와 양식 모든 것이 새롭습니다. 이러한 새로운 환경에 적응을 해나가는 것 또한 하나의 뜻 깊은 경험이 아닐가 생각이 듭니다.

바로 내일, 남은 7개월을 책임 질 프로젝트에 대한 이야기가 시작 될 예정입니다. 12명의 학생들이 각자 다른 생각을 가지고 이 프로그램에 참여 했을 것입니다. 서로의 아이디어를 공유하고, 한 팀을 만들어 멋진 결과물을 만들어 낼 수 있기를 기대합니다.

이에 더불어 스스로도 남은 기간을 허투루 사용하지 않고, 분골쇄신(粉骨碎身)의 정신을 가지고 활동 할 것은 다짐합니다.

행복한 시간을 바라며 마침.

인터넷 속도가 정말 느립니다

[Experience] 2025 경기대학교 AWS Deepracer 자율주행 교육 및 대회 후기

모노산달로스 — Mon, 2 Jun 2025 22:13:11 +0900

2025. 6. 1 경기대학교 제 3회 AWS Deepracer 경진대회 회고록

AWS Deepracer League

인공지능 분야에서 주목 받는 여러 기술 중 하나인 자율 주행은 어느덧 우리 앞으로 성큼 다가왔습니다. 인공지능의 성능이 급격하게 상승하며, 정말 멀지 않은 미래에 우리는 자율 주행 차량을 도로에서 볼 지도 모르겠습니다.

그러나 오늘로부터 7년전, AWS Deepracer가 세상에 처음 공개되었습니다. 이는 강화 학습(Reinforcement Learning)을 보다 쉽게 학습하기 위해 만들어졌는데요, 1/18 스케일의 자율주행 레이싱 자동차와 클라우드 기반 시뮬레이션 시스템이 제공되고 있습니다.

2025년 5월 경기대학교 소프트웨어중심대학에서 이러한 AWS의 시스템을 활용하여, 학생들을 위한 강화학습 교육과 대회의 장이 마련되었습니다. 그동안 궁금했던 강화 학습을 한 번 체험해보는 좋은 기회라고 생각하여 해당 프로그램에 참여하게 되었습니다.

Drive My Car - The Beatles

강화학습이란?

What is reinforcement learning?

본격적으로 대회에 대해 이야기 하기 전, 해당 프로그램의 핵심이 되는 강화학습(Reinforcement Learning)에 대해 먼저 이해해봅시다.

강화학습은 현재 상당히 주목받는 기술입니다. 많은 사람들이 애용하는 ChatGPT에도 RLHF(Reinforcement Learning from Human Feedback)라는 방식의 강화학습이 적용되어 있습니다.

강화학습을 쉽게 비유하자면 강아지를 훈련시키는 것과 같습니다. 에이전트(Agent)가 수행한 행동에 대하여 잘 하면 칭찬, 못 하면 벌을주며 최적의 행동을 찾아가는 것이지요.

자율 주행에 이를 적용한다면 어떻게 될까요? 트랙을 올바르게 주행하면 칭찬을 하고 트랙을 벗어나거나 너무 느리게 달리면 벌을 주는 것을 떠올릴 수 있습니다.

오프라인 강화학습 교육

Students participated in a lecture on reinforcement learning

본격적인 강화학습 교육은 5월 넷째주 주말에 이루어졌습니다. 3인으로 구성된 모든 팀들이 한 장소에 모여서 오프라인 교육을 받을 수 있었습니다.

이틀간 PopcornSAR에서 강사님이 오셔서 여러가지 교육을 받을 수 있었습니다. 해당 산업 업계에 대한 내용, 강화학습에 대한 전반적인 내용, Deepracer 학습에 대한 내용 등 다양한 인사이트를 얻을 수 있는 유익한 시간이었습니다.

본선전이 바로 다음주이다 보니 Deepracer를 어떻게 학습시키면 좋을지에 대한 부분을 주의깊게 들었습니다. 하이퍼파라미터(Hyperparameter)의 대한 설명이나 조향(Calibartion)에 대한 설명 같은 당장 필요한 부분에 집중했습니다.

실제로 학습을 시키다

모든 학습이 끝난 뒤에는 각 팀당 AWS계정과 차량이 한 대씩 지급되었습니다. 이를 통해 일주일간 자유롭게 학습을 하고 오프라인 트랙에서 테스트를 할 수 있었습니다.

Placing the clipping point near the exit allows a smoother exit line and earlier acceleration

본격적인 학습을 시작하기 전, 강화학습의 정책(Policy)을 결정할 필요가 있었습니다. 어떻게 주행을 하면 가장 빠르게 트랙을 완주할 수 있을까요? 우리 팀은 물리적인 차량이 트랙을 돌아야 한다는 것을 고려하여 이러한 부분을 고민했습니다.

여러 이야기가 오간 끝에 우리는 코너를 빠르게 돌기 위하여 Out-In-Out Strategy를 사용하게 되었습니다. 코너 진입시 트랙의 Outside에서 진입하면 코너 중앙인 클리핑 포인트(Clipping Point)를 출구 쪽에 가깝게 잡을 수 있는데요, 이렇게 되면 더욱 완만한 곡선을 그리게 되어 빠른 주행이 가능해집니다.

The final-trained model

학습 진행에는 여러가지 어려움이 존재했습니다. 각 계정마다 15시간의 학습이 가능하기에 신중하게 학습을 진행 해야 했습니다. 우리 팀은 몇 번의 시도 끝에, 위와 같은 그래프를 최종적으로 얻을 수 있었습니다.

아쉬움이 남았던 것은 좋지 못한 모델을 개선하느라 많은 시간을 소모하고는 했던 점입니다. 그 결과 나중에 만들어진 모델의 학습시간이 1시간으로 매우 짧아지게 되었습니다.

Test Driving

예선전이 다가오기 바로 전 날, 해당 모델을 테스팅 해 본 결과 우회전을 못 하는 문제를 발견했습니다. 하지만 우리가 할 수 있었던 것이 없었는데, 학습을 시킬 시간도 테스팅을 할 시간도 부족했기 때문입니다.

일주일 중 4번을 트랙에 모여서 시간을 보냈지만, 차량 세팅에 생각보다 많은 시간을 보낸 부분은 아쉬움이 남습니다. 또, 학습 시간 분배를 현명하게 하지 못한 점 또한 돌이켜 보게 됩니다.

성과 발표를 하다

A presentation on the project progress was given

그렇게 한 주가 마무리 되었고, 6월 1일 토요일 발표회가 진행되었습니다. 각 팀들은 모두 그동안 있었던 과정과 성과에 대해서 발표를 이어갔습니다.

가지각색의 전략을 통해 학습을 수행한 점이 참 재미있었습니다. 특히 기계공학과 학생이 있었던 팀은 하드웨어적인 해결법을 찾으려고 노력한 점도 기억에 남습니다.

모든 팀이 겪은 공통적인 문제로 온라인과 현실 주행의 차이에서 오는 어려움이 있었습니다. 온라인에서는 잘 주행을 하더라도, 현실 트랙에 존재하는 여러가지 변수들을 제어하기란 정말 힘들었습니다. 조명, 트랙의 모양, 마찰력 등 고려사항이 매우 많았기에 많은 팀들이 이를 해결하기 위해 애를 먹고는 했습니다.

드디어 시작된 주행 대회

14 teams participated in the racing competition

소프트웨어 중심 대학 권기현 단장님께서 짧은 연사를 진행하신 뒤, 드디어 고대하던 예선 주행이 시작되었습니다. 우리 팀은 2번 순서로 참여하게 되었는데, 실제 경기 진행 당시 몇가지 돌발 상황이 발생했습니다.

가장 문제가 되었던 것은 배터리에 대한 부분이었는데, 충전 시간을 넉넉하게 가지지 못한 몇몇 팀들이 방전으로 달리지 못하는 현상이 생기고는 했습니다. 따라서 첫 번째 팀과 우리 팀은 충전을 하는 대가로 한 번의 기회만을 부여받게 되었습니다.

Exactly what we expected happened

결과는 아쉽게도 우리의 예상과 같았습니다. 우회전을 하지 못하여 코스를 탈선하고 말았습니다. 그리고 속도를 너무 빠르게 돌린 탓에 마지막 코너 부분에 한 번 더 탈선을 하게 되었습니다.

이후 모든 팀이 레이스를 마치고 예선전이 종료되었습니다. 5팀이 최종 선발되어 결선으로 올라갔습니다. 여러가지 상황과 더불어 조금 아쉬운 결과였지만, 좋은 경험이라고 생각하며 우리는 회장을 빠져나왔습니다.

결승전과 일주일의 끝

The winning team showed a really smooth run

6월 2일 일요일, 모든 팀이 다시 경기장에 모여들었습니다. 예선전과 달리 경기는 빠르고 순조롭게 진행되었습니다. 5팀 모두 탈선 없는 부드러운 주행을 보여주었는데, 특히 1등 팀은 10초대의 성적으로 완주하여 모두를 놀라게 했습니다.

이후 시상식이 진행되었고, 짧지만 재미있었던 일주일의 여정이 끝이 나게 되었습니다.

마치며

It was a great experience over the past week

이번 경기대학교 AWS Deepracer 자율주행 교육 및 대회는 대단히 의미가 있었습니다. 개인적으로 컴퓨터공학부의 수업이 소프트웨어 위주로 흘러가는 부분에 대해 약간의 아쉬움을 가지고 있었습니다. 이렇게 실제 차량을 학습시키는 교육을 받고, 트랙에서 주행을 하는 것은 꽤나 즐거운 경험이었습니다.

이러한 하드웨어와 소프트웨어가 결합된 교육의 기회는 더욱 늘어나야 한다고 생각합니다. 웹/앱 위주의 소프트웨어를 다루는 것과는 정말 다른 흥미를 이끌어 냅니다. 그리고 그런 새로운 경험이 더 많은 꿈과 희망을 찾아내는 등불이 되어줄 것이라고 확신합니다.

앞으로 더 많은 재학생 후배들이 이런 경험에 참여할 수 있기를 고대합니다.

마지막으로 한가지, 나 자신에게 청하는 것이 있습니다. 대학교에서 보낼 수 있는 시간이 이제 얼마 남지 않았습니다. 이제 6개월 남짓한 기간이 되었으니, 남은 나날을 더 다양한 경험으로 채울 수 있기를 기원합니다.

[Experience] 2025 GCSC 우수상 수상을 회고하며 (한일 대학생 창업 캠프) + 승려와 수수께끼를 읽고

모노산달로스 — Thu, 13 Mar 2025 20:04:32 +0900

2025. 3. 4 뒤늦게 적는 GCSC 회고록

Global College Startup Camp

누구의 소유물이 되기에는, 누구의 제 2인자가 되기에는, 또 세계의 어느 왕국의 쓸만한 하인이나 도구가 되기에는 나는 너무나도 고귀하게 태어났다. - 셰익스피어 '존 왕' 5막 2장

'승려와 수수께끼'라는 책의 마지막 장에 담긴 명언입니다. 해당 캠프가 끝난 뒤 접한 책인데, 방학 동안 창업에 대해 고민을 하는 제게 큰 힘이 되었던 책입니다.

스타트업의 본질은 무엇일까요? 혹자는 창업을 위해서는 인생을 걸어야 한다고 이야기합니다. 그렇다면 그 인생을 걸만한 '아이디어'란 뭘까요? 큰돈을 불러올 수 있는 것일까요? 혹은 내가 진정으로 해결하고 싶은 문제를 찾는 것일까요?

본 게시글은 2025 GCSC 행사의 시작부터 끝까지 회고를 기록하고 있습니다.

GCSC란 무엇인가?

What is GCSC?

GCSC는 Global College Startup Camp의 약자로 대학생들이 모여 사회적 문제를 해결하는 캠프입니다. 이번 2025년도는 가천대학교와 히토츠바시대학(一橋大学)이 공동 주최한 행사입니다. 글쓴이는 경기대학교 재학생으로 이벤터스를 통해 신청을 했습니다.

신청 과정은 1차와 2차 서류 면접으로 구성되어있었습니다. 창업과 관련하여 얼마나 관심을 가지고 활동했는지가 주요 관심사였습니다. 또 영상을 통해 자기소개를 하는 부분도 있었습니다.

운이 좋게도, 글쓴이는 약 70인의 합격자와 함께할 수 있었습니다. 일본 학생들과 한국 학생들이 각지에서 가천대학교로 몰려들었습니다.

첫 만남과 분위기(12.20)

온라인으로 오티가 진행되었다

본 행사가 시작되기 전, 12월 20일 온라인 오티가 진행되었습니다. 행사의 대한 소개와 팀 빌딩을 위한 자기소개 시간이 이어졌습니다. 오티가 끝난 뒤에는 자유롭게 본행사 전까지 팀을 구축해야 했습니다.

노션에 올라간 자기소개를 보고 연락을 했다

노션에 자신의 대한 소개를 올리고 모모보드로 연락을 주고 받았습니다. 이를 돌아보면, 본인의 자기소개를 너무 짧게 적은 점이 조금 아쉬웠습니다. 주요한 경력인 깃허브나 블로그 링크를 참조하지 못해 연락 시에 새롭게 전달해야 했기 때문입니다.

팀 빌딩 기간이 끝나갈 무렵 한 팀원과 연락을 주고받았고 팀을 이룰 수 있었습니다. 마지막까지 팀이 구해지지 않아 어려운 상황이었는데, 다행히도 좋은 팀원과 만날 수 있었습니다.

모모보드 앱을 통해 연락을 주고 받았다

이후에는 일본인 팀과 연락을 했습니다. 현장에서 일본인과 팀을 결성하는 것도 가능했지만, 우리는 우선 마음에 드는 팀을 선점하고자 했습니다. 카드를 만들어 우리를 알렸는데, 생각보다 순조롭게 원하는 팀을 결성할 수 있었습니다.

팀 빌딩을 하며 느낀 점이 있다면, 이룬 것이 없으면 학력에 눈이 가게 된다는 것이었습니다. 분명 학력이 다는 아니라고 생각은 하지만, 다른 경험이 없다면 학력 이외에 판단 기준이 없어진다는 것이 문제였습니다.

앞으로도 나 자신을 보여줄 수 있는 여러 활동을 더욱 많이 참여해야겠다고 다짐하는 시간이었습니다.

가천대학교에 모이다(01.08)

가천대학교 코코네스쿨에 도착했다

1월 8일 가천대학교에 버스를 타고 올라갔습니다. 생전 처음으로 본 가천대학교는 조금 놀라운 광경이었습니다. 비록 방학이었기에 학생은 많이 없었지만, 기대 이상으로 넓은 학교였고 멋진 조형물이 가득했습니다.

셔틀을 타고 올라간 언덕 꼭대기에는 코코네스쿨이 있었습니다. 코코네스쿨은 가천대학교의 존재하는 학과로써 '창업 교육'을 전문적으로 받을 수 있었습니다. 코코네스쿨의 존재 또한 당일 처음 알았는데, 행사가 모두 끝난 뒤에는 완전히 반할 정도로 좋은 학과였습니다.

드디어 얼굴을 마주할 수 있었다. 우 일본인 팀원(하늘, 치사키) 좌 한국인 팀원(채연, 나)

그리고 당일 온라인으로 대화만 했던 팀원과 드디어 얼굴을 마주 할 수 있었습니다. 우리 일본인 팀원 중 한 명(하늘)은 한국인이었는데, 일본 대학교를 다니고 있었습니다. 이에 한국어와 일본어 모두 능통한 것이 특징이었습니다.

다른 일본인 팀원(치사키)는 시간이 지나면서 더욱 빛이 났는데, 꼼꼼하고 인내심 있는 성격으로 팀에 큰 도움을 주었습니다. 한국인 팀원(채연)은 성격이 밝고 좋아 분위기를 잘 이끌 것이라는 생각이 들었습니다.

아이스브레이킹

사상 처음으로 춤을 배웠다

첫 날 당일은 아이스브레이킹 시간이 주어졌습니다. K-POP 댄스 배우기가 예정되어 있었는데, 시작하기 전에는 '뭐 이렇게 까지야..?'라는 분위기가 강했습니다.

그런데 막상 강사분들이 오고 춤을 배우는 과정은 꽤나 재미있었습니다. 또 팀별로 영상을 찍으며 쉽게 친해질 수 있었습니다. 그간 행사들의 아이스브레이킹 방식은 제각각이었지만, 적어도 춤을 배우는 것은 효과적인 방법이라는 결론을 내릴 수 있었습니다.

춤도 열심히 추니 보상이 따라왔다

우리는 약 1시간 넘게 열심히 춤을 배웠습니다. 그 모습이 강사님들에게 띄었는지, 상으로 과자를 받을 수 있었습니다. 첫날부터 팀 밝은 분위기가 이어졌고, 생각보다 순주로운 시작에 마음이 편안해졌습니다.

모든 활동이 끝난 뒤에는 피곤한 몸을 이끌고 숙소로 들어가 잠을 청했습니다. 한국인 학생과 일본인 학생 모두 가천대학교 기숙사를 이용했는데, 첫날밤 난방 시스템의 문제가 있었던 것이 기억에 남습니다.

영하 10도를 넘나드는 1월의 혹독한 날씨 탓에 더욱 힘들었는데, 다행히도 둘째 날부터는 땀이 날 정도로 따듯한 방을 만들어 주셨습니다.

아이디어 해커톤(Day 2)

인구 문제의 관해 전문가 집단의 강의가 이어졌다

둘째 날, 특강과 함께 본격적으로 아이디어 해커톤이 시작되었습니다. GCSC 기간 동안 아이디어 회의를 진행하는 것과 동시에 여러 전문가들의 강의가 이어졌습니다.

강의의 내용은 사회적 문제 중 인구 문제를 다루었습니다. 세 강사님이 각자의 시각으로 인구 문제를 설명하셨는데, 특히 인구 통계로 바라보는 서울대학교 교수님의 강의가 인상적이었습니다.

뜻깊었던 사례는 바로 비스포크의 대한 내용이었습니다. 가구의 구매는 기본적으로 결혼을 할 때 많이 이루어집니다. 그런데 혼인율이 떨어지는 추세에서 비스포크 브랜드의 런칭이 과연 올바른 일일까요?

이에 대한 교수님의 대답은 놀랍게도 Yes 였습니다. 인구의 양적인 부분(혼인율)은 떨어졌지만, 질적인 부분(경제력이 있는 결혼)은 감소가 적다는 것이 그 이유였습니다. 따라서 비스포크는 프리미엄 브랜드로 런칭을 하였고 이는 경제력이 있는 신혼부부에게 큰 인기를 끌었습니다.

이에 대응하기 위한 LG 가전의 반응 또한 재미있었습니다. 국내 프리미엄 가구를 비스포크가 이미 점령한 뒤에는 글로벌 시장으로 이동할 수 밖에 없었습니다. 그것이 바로 젊은 세대가 많고 생산성이 높은 국가 베트남이었고, LG의 결정 또한 좋은 결과를 가져올 수 있었습니다.

밤 늦게까지 회의가 이어졌다

강의 이후에는 문제 정의를 위한 회의가 이어졌습니다. 실질적으로 오늘을 포함하여 3일 내에 우리는 문제를 정의하고 솔루션을 도출해야 했습니다. 선택한 주제는 고령화 사회였는데, 여느 사회적 문제가 그렇듯 쉽게 떠오르지는 않았습니다.

특히 타겟을 정하는 데에 오랜 시간을 쓰게 되었는데, 노인의 대한 고정관념을 깨는 것이 정말 힘들었습니다. 60대의 노인, 70대의 노인, 80대의 노인 모두 다른 상황이고 경제력과 병의 중증도에 따라서도 노인의 상황은 천차만별이었습니다.

멘토링 기회를 정말 많이 받았다

그러한 상황에서 큰 도움이 되었던 것은 바로 멘토링이었습니다. 주제의 방향을 결정하는 데에 많은 조언을 받을 수 있었고 몰랐던 사실들 또한 알 수 있었습니다.

언제나 느끼는 사실이지만 뛰어난 사람들에게 피드백을 받는 것은 매우 중요합니다. 결국 팀 내부에서만 이야기가 돌아가면 한계에 부딪혔을 때 깨어내는 것이 쉽지가 않습니다. 그러한 상황에서 GCSC는 주기적으로 멘토링을 신청할 수 있었고, 여러 분야의 전문가분들이 다양한 의견을 제시해 주셨습니다.

끝이 없는 회의(Day 3)

잠들 틈도 없이 회의는 계속되었다

새벽에 자고 깨어나 3일째 아침이 밝았습니다. 오늘도 여지없이 특강을 듣고 회의를 이어갔습니다. 다음 날은 중간발표가 있는 날이기에 최대한 틀을 잡으려고 노력했습니다. 그리고 '노노(老老) 간병'이라는 키워드를 중심으로 주제를 잡아갔습니다.

사진을 보며 기억이 나는 것은 거대 포스트잇의 유용함입니다. 지금까지는 주로 화이트보드를 이용해서 회의를 했었는데, GCSC에서는 큰 포스트잇을 애용했습니다. 이는 자유롭게 아이디어를 펼치기가 좋았고, 벽에 붙여다가 즉시 대화를 이어가기도 편리했습니다.

사흘째는 밤을 새워야 했습니다. 키워드를 잡기는 했지만 문제 정의가 제대로 이루어지지는 못했고, 중간발표 준비가 겹쳐 시간이 매우 부족했습니다.

이러한 와중에 GCSC 측에서 여러 야식과 카페인을 지원해 준 것은 큰 도움이 되었던 기억이 납니다.

중간발표 그리고 명상(Day4)

인구문제 분야 팀들이 모여 중간발표를 진행했다

밤을 새우고 정신이 몽롱한 채 중간발표를 이어갔습니다. 중간발표는 평가보다는 피드백을 받기 위한 자리에 가까웠습니다. 그리고 우리에게 주어진 피드백은 냉정했습니다.

'노노(老老) 간병'이라는 키워드에 너무 초점을 맞춘 나머지 의사 전달이 제대로 이루어지지 못했습니다. 그리고 노노간병은 부정적인 부분이 많다는 것에 발목을 잡혔습니다. 이에 따라 '일본과 한국의 상황을 비교하는 것은 좋았지만, 문제 정의에 대해서는 더 고민을 해보아야겠다.'라는 결론이 내려졌습니다.

한 편으로는 힘 빠지는 피드백일 수도 있습니다. 하지만 우리에게는 오히려 기회가 되는 시점이기도 했습니다. 피드백을 받으면서 막혀있던 부분이 뚫리는 듯한 느낌도 들었습니다.

조금은 뜬금없지만 명상을 하며 마음을 치유했다

이후에는 명상 시간이 시작되었습니다. 여러 가지 동작을 따라 하며 마음을 편안하게 만들었습니다. 차분한 분위기에 그만 잠들어 버릴 뻔했지만, 열심히 달려가는 중에도 휴식은 필요한 법이었습니다. 명상 이후에는 다시 온건하게 회의에 집중할 수 있었습니다.

몬스터와 커피의 힘으로 회의는 이어졌다

이후 우리는 최종 발표를 위해 달려갔습니다. 단 하루 남은 상황에서 명확한 문제 정의조차 되어있지 않았지만, 우리는 포기하지 않았습니다. 길고 긴 회의 끝에 주제는 하나로 정해졌는데 바로 '노인 스마트홈 기기 매칭'이었습니다.

이는 일본의 가정에 잘 보급되어 있는 노인 보조 기구로부터 아이디어가 시작되었습니다. 기구의 유무에 따라 위험성은 천차만별이었음에도, 한국의 인식은 저조했습니다.

하지만 일본의 사례를 들며 보조 기구의 대한 사업이 의미가 있으리라고 생각할 수 있었고, 결과적으로는 '집안의 필요한 보조 기구가 무엇인지 분석해 주며, 보조 기구 설치 업체와 노인을 매칭해 주는 서비스'를 구상했습니다. 그리고 여기에 일반적인 기구가 아닌 최근에 주목받는 '스마트 홈' 기기를 다루도록 했습니다.

전문가가 노인의 집에 방문하여 신체 정보와 방의 구조를 분석합니다. 그리고 올바른 스마트 홈 기기의 위치를 알려주고, 설치 업체 연결까지 도와줍니다.

여기에 추가로 AI를 통해 방의 구조와 올바른 기구 설치를 학습시켜, 돈이 없는 노인에게도 서비스가 제공 될 수 있도록 구상했습니다. 기존의 전문가 방문을 AI가 대신하도록 하는 것입니다. 즉, 돈이 많은 노인으로 부터 사업을 시작하여 기술을 이점으로 사회적 약자에게도 도움을 주는 서비스인 것입니다.

기나긴 회의 끝에 방향을 잡고 나아갔다

나흘째가 되어서야 우리는 문제 정의를 마칠 수 있었습니다. 그리고 당일 솔루션을 도출함과 동시에 발표를 준비해야 했습니다. 분위기가 좋았던 시작에 비해서 그 과정은 순탄하지만은 않았습니다.

최종 발표일이 다가와서 겨우 문제 정의를 할 수 있었습니다. 이에 따라서 솔루션 도출과 발표 준비에는 시간이 턱 없이 부족했습니다. 결국 이 날 밤도 잠을 잘 수가 없었고, 새벽까지 내용 정리와 조사를 이어갔습니다.

이러한 문제는 PM 역을 맡았던 본인의 잘못도 있었다는 생각이 듭니다. 방향을 제대로 잡아주기까지 시간을 많이 쓴 것이 시간 부족의 원인이 되지 않았나 회고합니다.

이틀 연속 밤을 새우고(Day5)

발표를 위한 스크립트를 작성했다

아침이 되어갈 때 쯤에는, 팀원들과 함께 스크립트의 작성과 수정을 이어갔습니다. 이틀이나 밤을 새우고 많은 스트레스를 받은 탓에 서로의 신경이 약간 날카로워졌다는 게 느껴지기도 했습니다.

물론 다들 크게 개의치는 않았고, 오직 최종 발표만을 바라보며 작업을 이어갔습니다.

지금 보니 머리가 참 길다

우리는 오전 발표였는데, 마지막 전 순서를 배정받았습니다. 약간의 남은 시간 동안 본인은 계속해서 스크립트를 읽었고, 팀원들은 끝까지 예상 질문을 정리했습니다.

그리고 단상에 오르며 그간의 성과를 펼쳐냈습니다. 밤을 새우며 나흘간 이어갔던 땀과 노력을, 발표 자료와 함께 세상에 선보이는 기적적인 순간이었습니다. 그 순간에는 피곤한 정신은 어디에도 없었습니다. 오직 발표 내용을 떠올리려고 애를 썼고, 심사위원분들의 눈을 마주치려고 노력했습니다.

그렇게 발표가 끝난 뒤에는 팀원들이 올라와 각 질문들에 대답을 이어갔습니다. 마지막까지 준비를 한 보람이 있는지, 질문들에 막힘 없이 대답을 이어갈 수 있었습니다. 특히 치사키가 일본 교수님의 질문을 오목조목 잘 대답해 주어 기뻤습니다.

성과를 얻어내다

누구도 예상하지 못한 우수상을 수상했다

발표가 모두 끝난 뒤 그간의 긴장이 모두 풀리며 졸음이 쏟아졌습니다. 그리고 운명에 몸을 맡기며 두 눈을 감았습니다. 이전 대회에서 큰 기대를 걸었다가 참패를 맛본 기억이 있어, 기대하지 않으려고 애를 썼습니다.

그렇게 시간이 휙휙 지나가고, 어느새 수상자 발표 시간이 다가왔습니다. 그리고 놀랍게도 우리 팀의 이름이 단상으로부터 불리어왔습니다. 그 순간 머리 위로 피가 몰리며 당황한 눈과 입을 감추지 못했습니다. 이것이 정말 현실인가? 싶은 표정으로 우리는 서로를 바라보았고 이내 정신을 차리고 환호했습니다.

큰 카타르시스를 느꼈습니다. 그간의 스트레스, 피곤함, 부정적인 감정이 모두 해소되었습니다. 팀적으로 우리는 큰 보상을 받았습니다. 팀원 중 그 누구도 빠짐없이 열과 성의를 보였고, 그간의 피눈물 나는 노력을 상으로 보답 받았습니다.

개인적으로 이는 더욱 큰 의미가 있는 상이었습니다.
직전 대회에서의 참패로 인해, 본인은마음속 깊은 곳에 패배감을 간직하고 있었습니다. 그리고 언제나 대학생으로 외부 대회에서 상을 받는 경험은 꼭 이루고자 소망했습니다. 3월 12일 GCSC를 통해서 그 두 가지 심리적 고통을 모두 해소할 수 있었습니다.

GCSC 끝

모든 발표가 끝난 뒤에는 만찬이 준비되어 있었습니다. 와인가 뷔페를 즐기며 그간의 회포를 풀었습니다.

그리고 GCSC는 끝이 났습니다. 그날 밤 우리는 기쁨 마음을 간직하고 서로를 떠나보냈습니다.

사회적 문제를 해결하는 것은 누구의 몫인가?

이후 나는 승려와 수수께끼라는 책을 읽었다

2025년 한 달은 제게 큰 의미가 있는 달입니다. GCSC라는 이벤트도 있었지만, 그와 함께 '건강한' 삶을 살았던 한 달이기 때문입니다.

직전 대회의 참패 이후 2024년 후반기 부정적 감정에 시달리고는 했습니다. 그러고 1월이 시작되었을 때, 새로운 나를 마주했습니다. 매일 6시에 기상하여 1시간 책을 읽으며 아침을 시작했습니다. 그리고 술은 일절 마시지 않으며 하루를 생산적인 시간으로 가득 채우고자 노력했습니다.

그러던 중 읽은 것이 바로 '승려와 수수께끼'입니다. 승려와 수수께끼는 실리콘 밸리의 투자자인 화자가 열정적인 창업가와 대화하는 내용으로 이어집니다. 그리고 그 대화의 교훈은 사업을 하고 싶다면 '진심으로 하고 싶은 일'을 찾아야 한다는 것입니다.

대화에 나오는 열정적인 창업가는 '돈'을 위해서 움직이는 사람입니다. 이 사업을 하면 떼돈을 벌 수 있을 것이라고 말합니다. 그리고 그의 공동창업자는 창업 초기의 '의도'가 변질되고 '돈'만을 우선으로 하는 창업가에게 크게 실망합니다.

둘은 깨어질 위기에 처했지만, 이야기의 끝에는 서로의 의견을 수렴하여 '진정으로 하고 싶은 일'을 사업으로 만들어냈습니다. 그것이 성공하든 실패하든 말입니다.

돈을 목표로 하면 안되는 것일까?

GCSC의 참여한 대부분의 대학생들은 특이했습니다. 하지만 그러면서도 평범했습니다. 그저 대학생일 뿐입니다. 하지만 그중 눈에 띄게 다른 사람이 있었습니다. 그는 한국과 일본을 전전하며 많은 사업을 이어간 베테랑이었습니다. 본인 보다 고작 한 살 많은 나이임에도, 고등학생 때부터 많은 창업 경험을 가지고 있었습니다.

'돈'을 위한 사업을 하지 말라고 끝없이 들어왔습니다. 하지만 제가 보기에 그는 '돈'을 위한 사업을 하고 있었습니다. 그리고 꽤나 행복해 보였습니다. (물론 겉으로 보기에만 그랬을지 실제로도 그럴지는 알 수 없지만) 마치 창업이라는 행위를 즐기는 것 같았고, 실제로 수완도 좋았던 것으로 보였습니다.

GCSC에서는 사회적 문제 해결이라는 주제를 내걸었습니다. 개중에서 진심으로 사회적 문제 해결에 힘을 쏟고자 하는 사람이 얼마나 있었을까요?

비록 수상을 했지만, 이것이 제게 어떤 의미를 남길까요? 적어도 단순한 상금과 트로피로 전략해서는 안된다는 생각을 합니다.

플래시365. 플래시 게임을 만드는 것이 너무 즐거웠던 시절

여러 질문이 스스로에게 쏟아집니다. 이에 답하는 것이 너무 힘드니, 자기 자신만을 생각해 봅시다. '진정으로 하고 싶은 일'이 있는가? '돈'을 위한 사업을 하려고 하는가? 전자는 허무맹랑한 이야기 같기도 합니다. 후자는 껍데기가 요란한 이야기 같기도 합니다.

나 자신을 한 번 돌아봅시다. 본인은 초등학생 이후로 계속해서 '개발자'라는 꿈을 키워왔습니다. 쏟은 노력과는 별개로 게임을 만드는 것이 즐거웠습니다. 비록 지금은 게임 개발자를 목표로 하고 있지는 않지만, 언제나 즐거운 행위가 바로 그것입니다.

그리고 지금 자신을 돌아보며, '진정으로 하고 싶은 일'을 찾아가야 한다고 말합니다. 어쩌면 게임 개발자는 목표에 부합할 수도 있습니다. 그리고 스스로도 일찍이 하고 싶은 일을 찾았다고 자부했습니다. 하지만 대학교에 진학하고 조금 더 넓은 세상을 경험하면서부터는 조금 갸우뚱한 것도 사실입니다.

'게임 개발자'라는 꿈을 기억에서 지워버리고자 하는 것은 아닙니다. 본인은 그저 개발이라는 행위 그리고 창조적인 활동을 좋아하는 사람입니다. 단지 그것이 '개발자'가 아니어도 좋았다는 점, 그리고 만들고자 하는 것이 '사람들의 문제를 해결하는 것' 혹은 '사람들을 즐겁게 하는 것'인지에 따라 정도의 차이가 있는 것뿐입니다.

록 영상이라고는 하지만 비틀즈를 많이 다루었다 그리고 두 달만에 4000명의 팔로워를 얻었다

그런 고민을 하면서 1월과 2월을 보냈습니다. 내가 하고 싶은 일을 찾으려고, 혹은 돈을 벌 수 있는 사업거리를 찾기 위해서 노력했습니다. 세상을 관찰하고자 처음 보는 장소만 선정해서 둘러보거나, 하루 종일 빈 종이와 씨름하기도 했습니다. 심지어는 '록 음악'을 좋아하니 이를 토대로 SNS 계정을 키워본다는 둥의 시도를 해보기도 했습니다.

그렇다면 지금, 결론을 내릴 수 있었을까요? 솔직히 말하면 아직도 '사업으로 만들고 싶을 정도로 모든 것을 포기하고 싶은 아이디어' 이라던지 '이 사업을 한다면 떼돈을 벌 수 있는 아이디어'는 찾지 못했습니다. 이번 겨울 방학은 실로 안타깝기도 하면서, 때때로 흥미로운 시간의 연속이었습니다.

그리고 창업과의 인연은 휴학을 하겠다는 마음을 접고 4학년으로 진학하며 잠시 멀어집니다. 완전히 끝을 낸 것은 아닙니다. 그동안의 경험 덕에 '기업가 정신'이라는 것을 조금이나마 향유할 수 있게 되었다고 생각합니다.

다만 나는 천재가 아니고 사업이라는 기로에 서기에는 부족함이 많다는 사람이라는 것을 알게 되었을 뿐입니다.

벌써 3월이 되었습니다. 지금은 독서 습관을 이어가려고 노력하고, 전공을 살리기 위해 재차 공부하고 있습니다. 앞서 던진 질문의 해답을 찾아가는 것 또한 멈추지 않았습니다. 이는 사실 인생을 어떻게 살 것인 과도 관련이 있습니다. 그리고 그 해답을 책에서 얻으려고 애를 쓰는 상황입니다.

시간이 지나고 취직을 한 다음, 어쩌면 3년 혹은 그 보다 더 나중에 나는 창업이라는 세계에 다시 발을 담을 수도 있습니다. 여느 창업가들이 말한 것처럼 말이지요.

그날이 오기까지 하루하루 최선을 다하며 살아갈 것을 맹세하고 또 다짐합니다.

- 2025. 03. 13
- 오랜 기간 걸린 GCSC 회고 마침.
- 박성민 씀

[Volunteering] 주간보호 센터를 방문을 자원하다

모노산달로스 — Thu, 26 Dec 2024 18:15:31 +0900

2024. 12. 20 하늘빛 주간보호 센터 자원봉사 기록

Mother Teresa of Calcutta

자원봉사란 어떠한 일을 대가 없이 자발적으로 참여하여 돕는 것을 의미합니다. 우리 사회 모두가 봉사 정신을 가진다면 좋겠지만, 아쉽게도 이타적인 마음을 가진다는 것은 정말 어렵습니다. 정말 선택받은 일부를 제외하면 모두 자기 자신을 먼저 떠올리기 마련입니다.
다만, 역설적이게도 자기 자신을 위해서 이타적인 삶을 실천 할 수도 있습니다. 조금씩 조금씩 사회에 공헌하며 봉사 정신을 쌓아간다면, 그것이 자신의 성장 그리고 사회의 성장으로 연결될 수 있다고 생각합니다. 분명 그 의도가 Volunteer 정신과 어긋나더라도, Volunteering이라는 행동으로 이어졌다면 좋은 의미로 남을 수도 있겠다고 견해를 내놓습니다.

왜 자원봉사를 했는가?

2024년 단풍톤을 준비하며 마음에 남는 것이 하나 있었습니다. 그것은 바로 간병, 돌봄 실태에 대한 공감이었습니다. 다시 말해, 진심으로 간병 문제를 개선해보고 싶다는 생각을 가지게 되었던 것입니다.

하지만 기존 아이디어의 디벨롭은 불가피했습니다. 좋은 방법을 고민해보았고, 역시 돌봄 경험을 해보는 것이 좋겠다는 판단을 내렸습니다. 이내 자원봉사 부터 시작하고자 생각했고, 집에서 약 30분 떨어진 주간보호 센터에 자원봉사를 신청하게 되었습니다. 그렇게 인생 처음으로 자원한 봉사를 시작하게 되었습니다.

주간보호 센터를 가다

봉사 활동을 진행한 하늘빛 주간보호 센터

주간보호 센터란 약간의 도움이 필요한 노인분들이 낮 시간을 보내는 곳입니다. 다양한 활동을 하고, 어르신들끼리 교류하며 시간을 보낼 수 있는 공간입니다.

한 가지 특징은 요양원에 비해 대게 증세가 심하지 않으시기에, 조금 더 밝은 분위기라고도 합니다.

주간보호센터 내부도 크리스마스 분위기로 가득했다

센터에 도착한 것은 오후 2시 즈음이었습니다. 들어가자마자 인사를 드렸는데, 어르신분들이 너무나 친절하게 마주해 주셨습니다. 그 덕에 첫 주간보호센터라는 약간의 두려움은 금세 풀리게 되었습니다.

이윽고 오늘의 활동인 색칠하기가 시작되었습니다. 필자가 하는 일은 어르신을 '도와준다'였습니다. 색연필을 쥐어드리거나, 색칠할 부분을 알려드리거나 혹은 말동무가 되어드리는 것이 주 목표였습니다.

그 과정에서 어르신들의 다양한 성격이 드러나는 것이 재미있었는데, 조금 과묵하신 분도 계시고 웃으며 좋은 말을 해주시는 분도 계셨습니다. 특히 손을 잡고 기도를 해주시는 분도 계셨는데, 무교임에도 감동적으로 느껴지기도 했습니다.

센터의 가구 구조도 기억에 남았는데, 긴 책상이 두열을 이루고 그 사이에 빈 공간이 존재했습니다. 활동을 진행하며 구조를 이루는 이유를 알게 되었는데, 책상 앞에서 이동하며 어르신들을 돕기 좋은 형태였습니다.

색칠 활동이 끝난 뒤에는 원형으로 모두 모이셔서 축구를 즐기셨습니다. 공을 차는 동작을 잘하신다는 것 그리고 이 공차기 활동을 즐기신다는 것이 조금 신기했습니다. 그동안에는 센터 외곽을 청소하는 작업을 수행했습니다.

그렇게 시간을 보내고 4시가 되었을 때는 모두 식사를 하셨습니다. 요양보호사 분들이 식사, 약, 물 모두 챙겨드리는 모습을 볼 수 있었습니다. 요양보호사 분들이 양치를 하도록 유도하시는 모습이나 약을 먹어야 한다고 일러주시는 것도 볼 수 있었습니다.

다음으로는 청소기와 밀대로 바닥을 청소했고, 어르신들이 차례대로 퇴원 준비를 시작했습니다. 센터로 오는 것부터 집으로 귀가하는 모든 과정을 케어해 주는 것을 알 수 있었습니다.

센터를 나오며

약 5시 30분 즈음 모든 작업이 끝나고 센터를 나오게 되었습니다. 여러 생각이 들었는데, 가장 큰 것은 주간보호센터의 분위기가 정말 좋다는 것이었습니다. 약간의 투정을 제외하면 대부분 어르신이 통제에 잘 따라주셨습니다. 또 요양보호사분들과 서로 농담도 주고받을 정도로 서로의 관계가 너무 좋아 보였습니다.

주간보호 센터는 그야말로 괜찮은 공간이었습니다. 시설도, 분위기도, 사람들도 모두 꽤나 포근한 느낌을 받게 만들었습니다. 단 하루 만에 요양보호 활동을 이해하는 것은 불가능하겠지만, 자원봉사라는 활동을 다시 느낄 수는 있었습니다. 앞으로도 매 주에 한 번씩은 시간을 내어 노인 봉사를 진행해 보고자 생각합니다.

경험이 쌓였을 때 또 다른 통찰력을 이끌어 내기를 기대하며

마침.

생각해 볼 만한 점

할머니의 비율이 엄청 높았다.

주간보호센터는 확실히 건강하셨다.

건강 상태가 좋으신 분들이 확실히 더 많이 웃으셨다. 건강해서 행복한 걸까 행복해서 건강한 걸까?

요양원 자원봉사도 가보자.

[구름톤] 단풍톤 기획일지 (3/3) | 부제 : 첫 해커톤 마침

모노산달로스 — Sun, 22 Dec 2024 16:04:02 +0900

구름톤 - 단풍톤 Carely 기획일지 (3/3)

Kakao x goorm. 구름톤 유니브

구름톤 유니브의 끝은 역시 해커톤이라고 할 수 있습니다. 단풍톤에 참여하며 팀빌딩, 아이디어 제시, 구현 및 발표까지 일련을 과정을 거치게 됩니다. 그리고 그 결과물을 바라보며 구름톤 유니브 활동을 마무리하는 중요한 의미를 가지고 있다고 생각합니다. 필자가 참여하는 첫 해커톤이니 만큼, 꼭 좋은 성과를 낼 수 있도록 열심히 임해보고자 합니다.

해당 시리즈는 2024년 구름톤 유니브의 일원으로 단풍톤에 참여했던 기록을 담고 있습니다.

단풍톤 기획일지 (1/3) | 부제 : 기획자의 눈으로 사회적 문제를 바라보다

단풍톤 기획일지 (2/3) | 부제 : 예선전을 돌파하다

단풍톤 기획일지 (3/3) | 부제 : 첫 해커톤 마침, 작은 호소

본선을 준비하다

발표 자료의 내용을 일부 수정했다

11월 24일 예선전을 상당히 좋은 성적으로 올라가게 되었기에, 본선전을 대비하기 위한 회의를 시작하게 되었습니다. 본선전까지 무엇을 준비하면 좋을지 고민하였고, 다음과 같은 피드백을 수용하고자 했습니다.

예선전에서 받은 피드백
1. 검증되지 않은 예비요양보호사를 집에 들이는 것이 위험하다. (심사위원, 멘토 공통의견)
2. 시연을 해줄 때 관계의 힘이 잘 안 드러난다.
3. 기술 시연 점수를 낮게 평가받았다.

본선전에는 비밀기술심사위원이 코드 자체도 평가하기 때문에, 제품의 완성도와 더불어 리팩토링도 이어가야 했습니다. 따라서 개발팀에는 이전에 구현하지 못한 그룹 기능 구현, 코드 리팩토링 그리고 완성도 개선을 부탁했습니다.

디자이너는 예선에서 부족했던 브랜딩과 데모 부스 준비를 맡아서 하게 되었습니다. 단체복과 다양한 굿즈를 준비했고, PPT를 일부 수정하는 역할을 하였습니다.

기획에 있어서는 예비 요양보호사의 검증 문제와 관계의 힘을 보여주도록 개선해야 했습니다. 이에 추가적으로 비즈니스모델 또한 구상할 필요가 있었습니다.

비즈니스모델과 개선사항

처음으로 나온 아이디어는 범죄기록 조회였습니다. 이를 도입하기 위해 조사를 하는 과정에서, 한국 간병 문화의 법적인 부분도 알게 되었습니다.

형의 실효 등에 관한 법률 제6조(범죄경력자료의 제공 및 조회 제한)에 따라, 다른 법률에 따라 범죄경력조회를 할 수 있는 기관이 그 업무를 수행하기 위하여 필요한 경우에는 범죄경력을 조회할 수 있 습니다. 이에 해당하는 것이 재가노인복지시설로서 노인복지법 제39조의17에서 확인이 가능합니다. 따라서 재가노인복지 시설을 만들거나, 연계를 하는 방식을 사용하면 여러 이점을 가지고 갈 수 있을 것이라고 방향을 잡게 되었습니다.

범죄기록을 조회는 개발자가 던진 아이디어였습니다. 혼자서 가능성이 없다고 여겨 고민하지 않았는데, 막상 조사를 하니 단순한 아이디어에서 재가노인복지시설과 연계를 하는 비즈니스 모델까지 이끌어 낼 수 있었습니다. 이때, 어떤 의견이든 긍정적으로 바라보는 것이 새로운 길을 찾는데에 큰 도움이 된다는 것을 알 수 있었습니다.

이후에는 완벽한 발표를 위한 연습에 집중했습니다. 특히 6분이라는 발표 시간에 있어, 실수를 하면 시간 부족이 생긴다는 생각이 가장 컸습니다. 다시 말해 막힘 없는 발표를 해내야 했는데, 밤에 잠이 오지 않아 계속 연습을 하며 시간을 보냈습니다.

만족스러운 발표를 해내다

그리고 다음 날, 카카오 AI 캠퍼스에서 모두가 모이게 되었습니다. 발표는 오전 오후로 나누어 이루어졌는데, 오전 후반부에 발표를 진행하게 되었습니다.

담담하게 생각했지만, 발표를 하기 전 까지 긴장감은 유지되었습니다. 아침에 일어나자마자 해 본 발표가 잘 되었으니, 회장에서도 문제 없을 것이라 생각하며 마음을 가다듬었습니다.

이윽고 차례가 되어 발표를 수행했고, 그 결과는 꽤나 만족스러웠습니다. 당당하게 마이크를 들고 심사위원 앞에 서서 준비한 내용을 모두 보여주었습니다. 특히, 다른 팀이 시간 부족이나 스크립트를 보는 모습과 비견되어 더 좋은 모습을 보여주었다고 생각했습니다.

발표가 끝나고 받은 질문은 조금 놀랐습니다. 심사위원 분들 중 한 분이 요양원 컨설팅 경험이 있으셨는데, 비즈니스 모델을 보고 구체적인 금액을 궁금해 하셨기 때문입니다. 다른 팀에 비해서는 구체적인 비즈니스 모델이었지만, 정확한 단가 까지는 정하지 못했기 때문입니다.

이후에는 기술적으로 어려웠던 부분을 여쭈어보셨고, 개발자가 대신 "문제 해결을 위한 기술을 찾는 과정이 어려웠다" 고 대신 답변했습니다. 이후 단상을 내려왔고, 발표에 자신감이 더 생기는 계기가 되었습니다. 특히나 행사 내내 발표에 대한 호평을 계속 들을 수 있어서, 더욱 좋았던 경험이라고 생각하게 되었습니다.

데모 부스를 준비하다

단체복은 앞치마로 준비하였다

발표가 끝난 뒤에는 알 수없는 긴장감이 모두 사라졌고, 맛있는 점심을 먹을 수 있었습니다. 이제 데모 부스만 잘 운영하는 일만 남아있었습니다.

데모 부스는 예선전에 비해서 확실히 체계적이었습니다. 서비스 시연 또한 훨씬 안정적이었기에, 많은 사람들에게 제품을 보여줄 수 있었습니다. 한 가지 아쉬운 점은, 데모 부스 운영 시간이 너무 짧았다는 것입니다. 이에 설명을 해야하는 기획자들은 발이 묶여, 다른 팀을 잘 구경하지 못하는 문제가 생겼습니다.

결국 운영 시간이 끝나기 10분 전에 겨우 두 팀 정도를 볼 수 있었습니다. 다른 팀의 기획자도 같은 상황이었기에, 같이 돌아다니며 구경을 해보았습니다. 시연 하는 모습을 보면서 완성도가 높은 팀이 정말 많았다는 것을 알 수 있었습니다.

더 많은 팀을 볼 수 있었다면 좋았겠지만, 아쉽게도 금방 마무리 하는 시간이 다가오게 되었습니다.

심사 기준을 비판하는 작은 호소

왜 상호 평가가 필요했을까?

발표와 데모 부스 운영이 끝나고 평가의 시간이 다가왔습니다. 그리고 그 평가에 있어서 한 가지 이상한 점을 꼭 이야기 하고 싶습니다.

심사 기준은 심사위원 70% + 참가자 평가 30%였는데, 평가의 비율이 엉뚱하게 이루어져 있다는 생각을 했습니다. 왜 참가자 상호 평가가 필요했을까? 의문점이 들었습니다.

각 참가 팀이 3개의 좋았던 팀을 선택하는 것 방식인데, 이 과정이 공정하게 이루어지기란 굉장히 어렵기 때문입니다. 문제는 평가를 하는 자신이 그 결과에 포함이 되어, 어떻게 하면 이득을 볼 수 있을까? 를 생각하고 투표하게 됩니다. 따라서 상위권의 팀은 견제의 대상이 되어 예상보다 투표를 받지 못하게 되고, 애매한 중위권 팀이 올라가게 되는 것입니다.

물론 그렇게 한 팀들을 원망하지 않습니다. 참가자들은 자신의 이득을 위해서 움직이는 것이 당연하다고 생각합니다. 오히려 그들을 잘못된 방향으로 이끈 심사 방법에 있어서 작게 호소합니다.

아쉽지만 좋은 경험

좋은 경험을 만들어준 팀원들에게 감사

결과가 어찌되었건 끝이 나게 되었습니다. 뒤를 돌아보면 해커톤을 진행하며, 많은 성장을 이루었다는 것 하나는 분명하다고 생각합니다. 기획을 하는 것, 팀을 이끄는 것 모두 값진 경험이었습니다.

좋은 추억을 만들어 준 팀, 송연우, 정지오, 강신영, 김은서, 이규민 형 누나 동생들에게 감사합니다. 그리고 그러한 자리를 만들어 준 구름과 카카오에게도 감사의 말씀을 전합니다.

"첫술에 배부르랴" 밥을 첫 수가락 뜨고 배가 부를 수 없듯이, 첫 해커톤의 성과에 만족할 수 없으리라 어찌보면 당연하다고 생각합니다. 이번 경험은 다음을 위한 좋은 발판이 되었고, 결과에 대한 증명은 또 기회가 찾아 올 것이라고 굳게 믿습니다.

단풍톤 마침.

[구름톤] 단풍톤 기획일지 (2/3) | 부제 : 예선전을 돌파하다

모노산달로스 — Sat, 21 Dec 2024 19:17:38 +0900

구름톤 - 단풍톤 Carely 기획일지 (2/3)

Kakao x goorm. 구름톤 유니브

구름톤 유니브의 끝은 역시 해커톤이라고 할 수 있습니다. 단풍톤에 참여하며 팀빌딩, 아이디어 제시, 구현 및 발표까지 일련을 과정을 거치게 됩니다. 그리고 그 결과물을 바라보며 구름톤 유니브 활동을 마무리하는 중요한 의미를 가지고 있다고 생각합니다. 필자가 참여하는 첫 해커톤이니 만큼, 꼭 좋은 성과를 낼 수 있도록 열심히 임해보고자 합니다.

해당 시리즈는 2024년 구름톤 유니브의 일원으로 단풍톤에 참여했던 기록을 담고 있습니다.

단풍톤 기획일지 (1/3) | 부제 : 기획자의 눈으로 사회적 문제를 바라보다

단풍톤 기획일지 (2/3) | 부제 : 예선전을 돌파하다

단풍톤 기획일지 (3/3) | 부제 : 첫 해커톤 마침, 작은 호소

발표를 준비하다

How to prepare the presentation?

좋은 발표란 무엇일까요? 의도한 내용을 명확하게 전달한다면, 그것이 바로 좋은 발표가 된다고 생각합니다. 그렇다면 좋은 발표를 위해서 어떤 것을 준비하면 좋을까요?

당시 세 가지 정도를 생각했습니다. 발표 내용을 잘 구성하기, 평가 기준에 맞게 발표하기, 내용 전달 연습을 완벽하게 하기. 11월 23일 예선전이 시작되었고, 제가 해야 할 일은 발표를 완벽하게 해내는 것이었습니다.

예선장에 도착하다

단풍톤은 카카오 AI 캠퍼스에서 진행되었습니다. 상당히 많은 팀이 참여했기에, 지하부터 2층까지 사람들로 가득했습니다. 70팀이 넘는 가운데, 오직 16팀만이 본선에 진출할 수 있었습니다.

생각보다 많은 팀이 떨어지는 심사였지만, 발표만 잘 하면 본선은 문제없으리라 생각하고 준비를 시작했습니다.

발표와 별개로, 첫 해커톤에서 느낀 경험도 재미있었습니다. 현장의 분위기, 각종 이벤트, 식사와 간식 등 모두 새롭고 흥미로운 느낌을 받았습니다.

현장의 분위기는 각 팀의 열정이 느껴지게 만들었습니다. 데모 부스를 위해서 각자 준비한 것을 보여주었는데, 확실히 단체복을 맞춘 팀이 눈에 띄는 모습이 있었습니다.

이벤트도 정말 많았는데, 추첨을 통해 상품을 주거나 사진을 찍을 수는 것들이 있었습니다. 심지어는 즉석에서 번호를 뽑는 번호팅도 준비되어 있어 놀랐습니다.

준비된 식사도 너무 맛있었다

식사도 너무 맛있게 준비되었고, 새벽 시간에는 야식과 몬스터도 지원되었습니다. 지원받은 몬스터와 직접 사 온 몬스터 3병을 마시고 다음 날 심장이 아팠던 기억이 다시 떠오르고는 합니다.

본격적으로 발표를 준비하다

스토리보드를 계속 써내려가며 준비했다

발표 준비 과정은 조금 곤혹을 겪었습니다. 디자이너와 함께 발표 자료를 준비하며 계속 고민했지만, 기획 의도를 5분 안에 드러내는 것이 굉장히 힘들었습니다. 내용 또한 뭔가 앞 뒤가 잘 안 맞는 듯한 느낌도 계속 들었기에, 확정을 짓기가 너무 힘들었습니다.

선착순으로 현장 멘토링을 받았다

이러한 상황에서, 하나의 돌파구를 찾을 수 있었습니다. 그것은 바로 현장 멘토링이었습니다. 예선을 준비하면서 멘토링이 큰 도움이 되었던 것을 기억하고, 이번에도 빠르게 신청하였습니다. 두 번의 멘토링을 받을 수 있었는데, 모두 발표에 큰 도움이 되었습니다.

특히 발표 내용 구성에 있어 명확해진 것이 중요했습니다. 그렇게 가족 간병인의 금전적 문제를 부각하지 말고 감정적인 부분 위주로 구성하도록 확정하였습니다.

첫 멘토링에서도 "문제 인식은 좋지만 솔루션의 내용과 약간 어긋나 있다"라는 평을 들었었는데, 현장에 와서야 그 의미를 이해하게 되었습니다. 이렇게 명확한 흐름이 생기니, 발표가 굉장히 매끄러워지는 것을 몸소 느낄 수 있었습니다.

발표 시간이 다가오다

저녁 5시 부터 다음 날 아침 8시까지 시간이 흘렀습니다. 정신은 몽롱하지만, 머릿속에는 발표 내용을 계속 읊조리며, 꼭 본선에 진출하겠다는 생각만을 했습니다.

조금 단촐했지만 최대한 준비한 것을 보여주기 위해 노력했습니다. 맨 앞에는 시연을 위한 노트북을 세워두고, 약간 높은 위치에 발표 자료를 보여주었습니다.

그렇게 수행한 발표가 시작되었는데, 생각보다 순조로웠습니다. 밤을 새워가며 준비한 보람이 있는지, 피곤했음에도 내용을 모두 전달할 수 있었습니다.

특히 전달력에 있어서 부족한 팀이 많이 보였습니다. 목소리의 크기나 발음에 있어서는 높은 점수를 받지 않았을까? 하는 개인적인 생각도 있었습니다.

이와 별개로 시연에 있어서는 조금 아쉬움이 남았는데, 시연을 위해 계속 DB를 조작하거나, 약간의 버그가 보이는 등의 모습이 나타났습니다.

원인은 너무 많은 기능 때문에 완벽한 구현을 하지 못했다는 것입니다. 이는 개발자의 문제가 아니라, 기능을 줄이지 못한 자신의 잘못이라고 회고합니다.

이에 따라 느낀점 하나는 역시 MVP 구성이 중요하다는 것입니다. 많은 기능보다는, 필요한 기능을 보여주자. 그것이 해커톤의 핵심 요소라고 생각하게 되었습니다.

떨리는 결과 발표

본선 진출에 성공하다 (43팀 아나바다)

당시 있었던 해프닝이 있습니다.

현장 발표에서 우리 팀은 떨어졌습니다. 본선전은 무조건 올라 갈 것이라고 생각해서인지 그 실망감이 굉장히 컸습니다.

모두 아쉬운 마음을 가지고 집으로 돌아와 밀린 잠을 청하였습니다.

시간이 지나고 정신을 차린 뒤 책상 앞에 앉았습니다.

무엇이 문제였을까? 본선에 진출하지 못할 기획이었나? 고심했습니다.

조 1위를 해서 올라갔다

그렇게 생각하던 찰나 카톡을 하나 받게된 것입니다. 현장에서 전산오류가 있었고, 우리 팀(43팀)이 조 1위로 올라가게 된 것이었습니다.

본선을 준비할 수 있어 너무 기뻤고, 특히 기획에서 고득점을 받은 것에 큰 감동을 받았습니다. 그리고 곧 팀원들과 다음 목표를 정했습니다. 이제는 수상을 노리고 다음 일주일을 더 열심히 준비하자.

오직 그 생각만을 가지고 다음 일주일을 보내게 되었습니다.

3편 본선전에서 계속

[구름톤] 단풍톤 기획일지 (1/3) | 부제 : 기획자의 눈으로 사회적 문제를 바라보다

모노산달로스 — Sat, 30 Nov 2024 17:58:04 +0900

구름톤 - 단풍톤 Carely 기획일지 (1/3)

Kakao x goorm. 구름톤 유니브

구름톤 유니브의 끝은 역시 해커톤이라고 할 수 있습니다. 단풍톤에 참여하며 팀빌딩, 아이디어 제시, 구현 및 발표까지 일련을 과정을 거치게 됩니다. 그리고 그 결과물을 바라보며 구름톤 유니브 활동을 마무리하는 중요한 의미를 가지고 있다고 생각합니다. 필자가 참여하는 첫 해커톤이니 만큼, 꼭 좋은 성과를 낼 수 있도록 열심히 임해보고자 합니다.

해당 시리즈는 2024년 구름톤 유니브의 일원으로 단풍톤에 참여했던 기록을 담고 있습니다.

단풍톤 기획일지 (1/3) | 부제 : 기획자의 눈으로 사회적 문제를 바라보다

단풍톤 기획일지 (2/3) | 부제 : 예선전을 돌파하다

단풍톤 기획일지 (3/3) | 부제 : 첫 해커톤 마침, 작은 호소

팀빌딩이 시작되다

본격적인 팀빌딩이 시작되었다

단풍톤을 위한 팀 빌딩 기간이 시작되었습니다. 여느 프로젝트가 그렇듯이 팀 빌딩은 굉장히 중요한 사안입니다. 기획에 따라 필요한 기술을 가진 팀원을 구하는 것이 정석적인 방법입니다. 이에 더불어 팀원들 간 좋은 관계도 중요한 사안입니다.

이를 위하여 구름톤에 아이디어와 개인 PR 자료를 제출하였습니다. 그렇게 제출된 자료를 보고 다른 사람들과 연락하며 자율적으로 팀을 이루는 구조였습니다.

처음에는 개발자로서 활동을 하겠다고 생각했습니다.구름톤에는 개발자로 참여했기에, 마음에 드는 아이디어가 있는 팀으로 들어가고자 생각을 했었습니다.

비어 네트워킹에서 만난 누나가 연락을 했다

하지만 크게 끌리는 아이디어가 없었기에 조금 시간을 두고 기다렸습니다. 그렇게 시간을 보내던 중, 비어 네트워킹에서 만난 누나가 먼저 연락을 해주었습니다.

이 경우는 정말 운이 좋았습니다. 실력 있는 팀원을 만나기 위해서는, 본인의 실력이 필요합니다. 하지만 필자는 자신의 실력을 증멸할 경력은 부족했습니다. 그렇게 어느 팀에 자신있게 들어가기도 힘든 상황에서, 먼저 연락을 해주니 너무 고마운 마음이 들었습니다.

실력을 가진 사람이라는 것도 알고 있었고, 성격도 좋았기에 괜찮은 팀이 만들어질 것이라고 생각했습니다. 즉, 승낙하지 않을 이유가 없는 팀 제안이었습니다.

문제는 '아이디어' 그리고 '포지션'이었습니다. 팀원으로 초대해 준 것은 너무 좋았지만, 아이디어는 새롭게 구상할 필요가 있다고 판단했습니다.

기존 아이디어는 해커톤 주제와는 너무나 동떨어져 있었습니다. 이에 새로운 기획이 필요했는데 내가 아이디어를 구상하겠다고 선언을 했습니다. 당시 창업 준비를 막 시작하던 시기였고, 이에 기획을 잘할 수 있다는 자신감을 가졌기 때문입니다.

이에 기획자 포지션으로 넘어가기로 결정했습니다. 이어서, 팀에 디자이너는 꼭 필요하다고 이야기를 했습니다. 좋은 디자인 없이는 제품을 보여줄 수 없다는 생각을 했고, 꼭 구해달라는 부탁을 했습니다.

팀 빌딩을 잘 마무리 하다

그렇게 10월 17일 저녁, 디자이너를 구하면서 팀빌딩을 순조롭게 마칠 수 있었습니다. 놀라운 것은 그 디자이너가 이전에 같이 작업을 했었던 형이라는 것입니다.

신기하고 반가운 마음이 교차했고, 그 또한 좋은 실력을 가지고 있다는 것을 알았기에 마음이 든든해지기도 했습니다. 이렇게 팀이 완성된 이후 한 가지 생각만을 하게 되었습니다. 내가 좋은 기획을 가지고 와서 모두를 놀라게 하자.

사회적 약자를 위해서

단풍톤의 세 가지 주제

이번 단풍톤의 주제는 사회적 문제 해결입니다. 필자는 소외계층 문제 해결에 집중해보고자 했습니다. 이에 논문, 인터뷰, 뉴스 자료 등을 살펴보며 사회적으로 어떤 문제가 있는지 파악해 보기 시작했습니다. 그러던 중 한 아티클을 읽고 깊게 감명을 받게 됩니다.

[인스피아] 살기 위해 ‘슈퍼맨’이 돼야 한다: 고립 돌봄 사회 - 경향신문

살기 위해 우리는 모두 슈퍼맨이 되어야 할까요?

www.khan.co.kr

요지는 즉 가족 간병인의 힘듦에 대한 이야기였습니다. 보통 사회적 약자를 생각할 때 쉽게 장애인을 떠올립니다. 그런데 그 장애인을 돌보는 가족 간병인에 대해서는 잘 인식하지 않습니다.

가족 간병인은 장애인을 돌보며 사회적 고립에 빠지고 있습니다. 따라서 간병인 또한 사회적 약자로 분류할 수 있다는 생각이 들었습니다. 분명 해결할 필요성이 있지만 간병인을 적극적으로 돕는 기존 서비스를 찾아보기 힘들었습니다.

가족 간병인들도 자신의 삶을 원하지만 어쩔 수 없이 고립되고 있습니다. 그렇다면 그 이유는 무엇이고 어떻게 해결할 수 있을지 생각해보았습니다.

가족 간병인들 또한 자신의 삶, 타인과의 관계를 원하고 있었습니다. 하지만 가장 큰 문제는 간병으로 인해 시간이 없다는 것입니다. 기존 서비스는 요양보호사 매칭을 통해서 문제를 해결해 줍니다. 필자는 이러한 상황을 돈을 통해서 시간을 사는 개념으로 바라보았는데, 가난한 가족 간병인은 그것이 불가능했습니다.

따라서 가난한 가족 간병인을 최종적인 페르소나로 잡았습니다. 이에 따라 서비스의 목적이 명확해졌는데, 돈을 지불하지 않고도 간병인들이 시간을 확보할 수 있도록 도와주자는 결론을 내렸습니다.

팀원들에게 설명하기 위해 빠르게 만든 발표 자료

가족 간병인들이 시간을 가지기 위해서 누군가 환자를 돌보아야 합니다. 이를 위해 '관계의 힘'이라는 키워드를 떠올렸습니다. 즉, 혼자서는 할 수 없지만 만약 간병인들끼리 커뮤니티가 형성된다면? 서로를 도움으로써 시간을 확보할 수 있지 않을까 생각했습니다.

관계의 힘에 있어, 핵심 가설은 두 가지였습니다.

하나는 간병인의 관계 형성을 도와야 한다는 가설을 세웠습니다. 간병인의 마음은 간병인만 이해할 수 있다. 하지만 간병인들끼리 소통할 수 있는 방법은 제한적이다. 따라서 로컬 간병인을 연결시켜 주는 서비스를 만들 것을 제시했습니다.

둘은 간병인 그룹에 대한 가설을 세웠습니다. 만약 5명의 간병인과 5명의 환자가 존재한다면 간병 그룹이 형성될 수 있다. 만약 한 명의 간병인이 휴가를 가져도 다른 4명이 충분히 5명의 환자를 돌볼 수 있다. 따라서 간병 그룹을 만들어줄 것을 제시했습니다.

첫 회의날이 되었고, 전체적인 서비스 기획 의도를 발표했습니다. 간병인이 가지는 문제와 관계의 힘을 통한 해결을 팀원들 앞에서 설명했습니다.

하지만 생각보다 반응이 미약했습니다. '관계의 힘'이라는 키워드는 매우 호평을 받았지만 잇따르는 기능들은 너무나 미약하다는 평가였습니다. 따라서 아이디어를 더 디벨롭하여 다시 모이자는 결론이 내려졌습니다.

1차 아이디어 디벨롭

다양한 방면으로 문제를 바라보고자 노력했다

이후 디벨롭에서는 조금 다양한 것을 생각해 보았습니다. 현재 한국의 간병 산업은 어떤가? 간병 가족이 받는 혜택은 무엇이 있는가? 간병이란 활동은 대체 무엇인가?

무엇보다도 간병인의 입장에서 문제를 바라보는 것이 중요했습니다. 그래서 간병 다큐를 여러 찾아보며 그들의 상황을 이해하고자 노력했습니다. 그러자 조금씩 실마리가 풀리기 시작했습니다.

이에 문제를 해결할 솔루션을 추가하였습니다. 자원봉사자 매칭, 예비 요양보호사 매칭, 원클릭 혜택 서비스 등 다양한 아이디어를 떠올렸습니다. 이를 모두 기능으로 만들었고, 그 결과 마치 일반 커뮤니티에 여러 가지 기능이 존재하는 플랫폼의 형태를 띄게 되었습니다.

하지만 이번에도 팀원들의 호응을 이끌어내지는 못했습니다. 기능 자체가 나쁜 것은 아니지만, 관계의 힘에 관련된 이야기가 빠져버렸습니다. 여러 기능을 추가하려고 시도하니 본질이 퇴색되어 버린 것입니다.

간병인 아이디어는 꼭 성공시키고 싶었습니다. 조금의 시간을 더 달라고 한 뒤 다음 그날 저녁 다시 모이기로 결정했습니다.

2차 아이디어 디벨롭

새롭게 솔루션을 정리했다

다시 원점으로 돌아가서, 관계의 힘에 집중하고자 하였습니다. 지금까지 떠올린 모든 아이디어를 정리 한 뒤, 우선순위를 나열했습니다. 이전의 파편화되어 있던 아이디어를 하나의 서비스로 만드는 과정이었습니다.

그 결과 가족 간병인, 자원봉사자, 예비 요양보호사 간의 관계도가 그려졌습니다. 이에 단순히 그룹을 이루거나 커뮤니티 플랫폼과는 사뭇 달라졌습니다. 명확하게 서비스 이용 타겟을 정리하고, 각 이해관계자의 니즈를 연결해 주는 플랫폼이 기획되었습니다.

와이어 프레임을 그려서 설명하였다

와이어 프레임을 그리는 것은 아이디어 정리에 큰 도움이 되었습니다. 그간의 솔루션이 구체화되고, 어떤 기능이 필요한지 명확하게 보여졌습니다. 또 팀원들에게 설명을 하는 과정에서도 명확하게 기획의 의도를 전달할 수 있었습니다.

그날 저녁, 모두가 만장일치로 간병인 아이디어를 받아들이게 되었습니다. 자료를 조사하고 아이디어를 떠올린 과정에 의미가 부여되는 순간이었습니다.

너무나 기뻤고 이제 예선전까지 계속해서 디벨롭하며 좋은 성과를 낼 일만 남아있었습니다.

디자이너의 부탁으로 IA(정보 구조도)를 처음으로 그려보게 되었다

아이디어 픽스 이후에는 기획의 디테일을 다듬어가고자 생각했습니다. 따라서 IA를 그리고 본격적인 시장조사를 수행했습니다. 또 우리 서비스의 이유를 다시 한 번 정리하기도 했습니다.

이쯤에서 서비스의 이름은 Carely로 지어지게 되었습니다. 브랜딩과 관련된 부분은 디자이너의 실력을 믿고 맡기자고 생각을 했습니다. 그리고 그 결과는 꽤나 만족스러웠습니다.

기획자와 개발자의 시선 차이

Steve Jobs and Steve Wozniak, co-founders of Apple, in 1977.Getty ❘ Tom Munnecke

흔히 프로젝트를 진행하면 직군 간의 마찰이 생기고는 합니다. 보통은 기획자가 제안하고, 개발자가 거절하는 모습으로 그려지고는 합니다. 그런데 이번에는 조금 새로운 상황을 맞닥뜨렸습니다.

개발자로부터 블록체인을 활용하여 자격증을 검증하는 기능을 추가하자는 의견이 제시되었습니다. 이는 필자에게 있어 조금 와닫지 않는 이야기였습니다.

기획의 의도인 가족 간병인에게 중요하지 않다고 생각되었고, 블록체인은 구현도 어려운 고급 기술이었습니다. 무엇보다도 정부가 블록체인을 사용하지 않으니, 실현가능성이 매우 떨어진다고 여겨졌습니다.

필자는 기획자의 입장에서 이 기능은 필요하지 않다고 생각했습니다. 하지만 기술적인 도전을 원하는 개발자의 입장에서는 이러한 기능을 꼭 필요로 했었습니다.

이에 기능을 제하자는 의견을 내기도 힘들었습니다. 필자 또한 기획과 해커톤이 처음이었기에, 이를 단정 지을만한 자신감이 부족했습니다. 결론적으로는 팀의 의견을 무시할 수는 없기에 기능을 넣게 되었습니다.

그날 회의가 끝난 뒤 고민을 해보았습니다. 내가 고집을 부리고 의견을 밀어야 했을까? 아니면 팀원의 의견이 맞는데 내가 받아들이지 못하는걸까? 정답을 내기란 힘들었습니다.

하지만 개발자의 의견을 받아들이고 이 문제를 타결하는 것이 기획자로서 역량이라는 생각이 들기도 했습니다. 따라서 블록체인을 사용한 이유를 떠올리기 위해 고민을 시작했습니다.

기획자 vs 개발자

최고 제품 탄생의 비결 | 동서고금을 막론하고, 언제나 훌륭한 기업, 그리고 성공한 사업의 중심에는 뛰어난 개발자와 기획자가 있었다. 뛰어난 개발자는 훌륭한 기획자를 필요로 하며, 반대의

brunch.co.kr

이와 관련하여 찾아보았던 글을 첨부합니다. 기획자와 개발자가 바라보는 프로젝트를 다를 수 밖에 없다고 생각합니다. 당시 있었던 이슈는 분명 '건설적인' 사안이었다고 생각합니다. 더 좋은 기획을 위해서는 꼭 필요한 마찰이 아니었을까? 회고하게됩니다.

멘토링을 받고 해결책을 찾다

멘토링은 정말 큰 도움이 되었다

구름에서 해커톤 이전에 각 파트별로 멘토링을 받을 수 있도록 지원을 해주었습니다. 그리고 이는 실로 큰 도움이 되었습니다.

기획적으로 막혀가던 부분을 질문하였고, 이에 대한 해답으로 새로운 방향을 찾을 수 있었습니다. BM, 성장 방향성, 블록체인, 요양보호사 타겟 등 다양한 부분을 새로운 시선으로 바라볼 수 있었습니다. 멘토님께는 큰 감사의 말씀을 드립니다.

그중 블록체인을 활용하는 돌파구를 제시해 주신 것이 정말 큰 도움이 되었습니다. 멘토님이 제시하신 것은 바로 민간 자격증을 발급해 주는 것이었습니다.

정말 새로운 솔루션이었고, 이를 바탕으로 디벨롭하면 꽤 특색 있고 의미 있는 기능이 되겠다고 생각이 들었습니다.

이후에도 멘토링을 몇 번 더 진행했는데, 정말 큰 도움이 되었습니다. 멘토링이라는 활동은 어느 분야에서 받으나 빠른 성장의 발판이 되어준다는 생각이 들었습니다. 앞으로도 관련한 기회가 있다면 놓치지 않고 멘토링을 받으리라 결심했습니다.

시간이 많이 지나고 다시 글을 쓰는 입장에서는, 블록체인과 자격증이 들어가면서 더 재미있는 기획이 되었다고도 생각하게 됩니다. 상황을 탓하지 않고 좋은 솔루션을 내주시는 모습이 정말 훌륭한 기획자라는 생각이 들었습니다.

마치며

I invent nothing, I rediscover. - Auguste Rodin

팀 내에서 기획자라는 역할을 수행하는 것은 처음이었습니다 자료를 찾고 솔루션을 내는 과정, 팀원들과 의견을 조율하는 다양한 어려움이 존재했습니다.

하지만 그 역경을 버티고 나니 아름다운 서비스가 눈앞에 존재했습니다. 기획이라는 일의 보람은 내가 기획한 서비스라는 것에 있다고 생각합니다.

물론 "혼자서 모두 떠올린 서비스야, 나 혼자 해냈어!" 라고 이야기 하는 것은 아닙니다. 분명 팀이 없었다면 만들어질 수가 없었던 서비스입니다. 그저, 그만큼 아이디어에 애정을 가지고 많은 노력을 기울였다는 의미로 받아들여주시면 좋을 것 같습니다.

이러한 결과에는 약 한달간의 창업 활동이 큰 도움이 되기도 했습니다. 그간의 경험이 없었더라면, 지금 같은 자료 조사와 아이디어 도출은 불가능 했을 것입니다. 해커톤이라는 좋은 기회가 올바른 타이밍에 찾아온 것에 감사합니다.

이제 예선전을 위한 준비가 모두 마쳐졌습니다. 앞으로는 개발을 기다리는 것 그리고 발표 준비를 잘해나가는 것만 남아있었습니다.

꼭 좋은 결과를 내어 해커톤을 마무리할 수 있었으면 좋겠습니다.

[SideProject] AWS Lambda를 이용한 스크래핑 자동화 / 기술적인 이슈 - (2/3)

모노산달로스 — Wed, 20 Nov 2024 19:13:22 +0900

SideProject - 기룡아 밥 먹자

개발자들은 왜 사이드 프로젝트에 뛰어들까요? 일반 팀 프로젝트와 다르게 자신이 원하는 서비스를 만들어 볼 수 있다는 점이 큽니다. 또한 자유롭게 새로운 기술을 적용해 보거나 경험하면서 실력을 키우기에도 좋습니다. 실제로 수익을 목적으로 하는 팀 프로젝트와 다르게 가볍게 접근할 수 있다는 점도 한 이유로서, 많은 개발자들이 사이드 프로젝트를 수행하고 있습니다.

(1/3) 문제 인식 및 프로젝트 기획

(2/3) 기술적인 이슈 해결

(3/3) 프로젝트 회고

1. 마주한 기술 이슈

Faced a problem unsolvable with the skills at hand.

사이드 프로젝트 진행 도중, 두 가지 기술적 문제를 마주했습니다.

1. 어떻게 하면 식단 정보를 매주 자동으로 스크랩할 수 있을까?
2. 스크랩을 한 정보를 데이터 베이스에 어떻게 자동으로 업로드할 수 있을까?

이를 해결하기 위해 고민해야 했습니다. 특히 자동화는 해당 프로젝트 유지보수에 있어 꼭 필요한 부분이었습니다. 매주 아침 데이터를 손수 가져와 업데이트하는 것은 매우 바보 같은 짓이기 때문입니다.

따라서 스크래퍼 제작과 CI/CD, AWS에 대하여 집중적으로 공부하기 시작했습니다. 식단 정보 스크래퍼를 만들고, CI/CD와 AWS에 대한 지식이 생기면 자동화 또한 가능할 것이라고 생각했습니다.

2. 필요한 기술을 배워가다

AWS(Amazon Web Services)를 학습하다

스크래퍼는 유튜브를 보며 제작하였고, Jenkins 또한 강의 하나를 구매하여 학습을 진행했습니다.

하지만 여러 가지 학습 중에서, 가장 많은 시간을 투자한 것은 AWS(Amazon Web Services)였습니다.

처음 Jenkins를 공부할 때, AWS ECS에 서버를 배포하는 과정에서 큰 어려움을 겪었습니다. 특히, 기초적인 지식 없이 계속 시도하려고 하니 너무 오랜 시간과 힘을 소모해야 했습니다. 때문에, AWS를 제대로 학습하지 않으면 앞으로도 계속 이러한 문제를 마주할 것이라는 생각이 들었습니다.

AWS Bestseller Course on Udemy

따라서, 즉시 Udemy에서 AWS Developers 강의를 구매하였습니다. 여러 가지 서비스들을 배우는 것은, 기존의 코딩 강의와 다른 새로운 학습 경험이었습니다. 특히 현재 수강하는 Serverless에 대한 내용은 정말 흥미로웠고, 다음 프로젝트에 활용해보고자 하는 마음을 가지게 되었습니다.

처음 AWS를 접했을 때는 복잡하고, 어려운 기능이 많은 스파게티와 같다고 생각했었습니다. 하지만 지금은 Serviece들 하나하나 유용하고 편리한 것들로 가득한 보물 창고가 되었습니다.

3. 설계도가 완성되다

The scraping automation structure of the project

이어지는 학습 끝에 위와 같은 최종적인 로직을 구상할 수 있었습니다. 구조에 대한 순서를 설명하자면 다음과 같습니다.

Scraping

1. EventBridge의 Scheduler를 생성합니다. 매 주 월요일 9시에 람다 함수를 호출합니다.
2. 호출된 람다 함수는 ECS task로 Scraper를 upload 합니다.
3. scraper는 스크래핑을 수행합니다. 이때, 결과물을 S3 Bucket에 저장합니다.

Data Update

1. S3 Bucket의 output.csv가 업데이트되면 트리거가 발동하여 람다 함수를 호출합니다.
2. 호출된 람다 함수는 Spring Server로 HTTPS 요청을 보냅니다.
3. 요청을 받은 서버는 S3 Bucket에서 데이터를 읽어 DB로 삽입하는 로직을 실행합니다.

더 최적화를 시킬 부분이 존재하지만, 작동에는 무리가 없을 것이라고 판단하였습니다. 이제 실제로 구현을 해 볼 일만 남아있었습니다.

4. 스크래퍼를 제작하다

Scrapy is a Python framework for fast web scraping

스크래퍼 구현에는 방법들이 존재했는데, 파이썬의 Scrapy라는 framework를 사용하였습니다. 유튜브 강의와 같은 정보가 잘 나와있었기에 입문하기 좋았습니다. 또 Item Pipeline과 같은 기능을 사용하면 자동화도 문제없을 것이라고 판단하였습니다.

기존에 식단이 올라오는 사이트

가장 먼저 한 일은 경기드림타워 홈페이지를 분석하는 것이었습니다. 그 결과 페이지의 url에서 한 가지 패턴을 알아낼 수 있었습니다.

https://dorm.kyonggi.ac.kr:446/Khostel/mall_main.php?viewform=B0001_foodboard_list&gyear=2024&gmonth=11&gday=20

쿼리 파라미터로 year, month, day를 사용하고 있었습니다. 즉, 연도, 월, 일 값만 넣어주면 원하는 주간의 식단을 가져올 수 있는 것입니다.

    def start_requests(self):
        today = datetime.now()
        year = today.strftime("%Y")
        month = today.strftime("%m")
        day = today.strftime("%d")

        url = f"https://dorm.kyonggi.ac.kr:446/Khostel/mall_main.php?viewform=B0001_foodboard_list&gyear={year}&gmonth={month}&gday={day}"
        yield scrapy.Request(url=url, callback=self.parse)

실제 스크래퍼 코드에서는 위와 같이 구현을 할 수 있었습니다.

스크래핑하는 당일의 날짜를 사용하여 url을 지정하니, 최신 식단 정보를 스크랩할 수 있었습니다.

개발자 도구를 통해서 페이지 구조를 확인한다

다음으로는 html 구조를 분석했습니다. 스크래핑을 위해서는 구조에 맞는 코드를 작성해 주어야 원하는 데이터를 가져올 수 있기 때문입니다.

def parse(self, response):
        decoded_body = response.body.decode('euc-kr')

        for row in response.css("table.boxstyle02 tbody tr"):
            date = row.css("th a::text").get() or row.css("th::text").get(default="").strip()
            meals = row.css("td")
            
            breakfast = ""
            lunch = ""
            dinner = ""

            if len(meals) > 0:
                breakfast = "&".join([item.strip() for item in meals[0].css("::text").getall() if item.strip()])
            if len(meals) > 1:
                lunch = "&".join([item.strip() for item in meals[1].css("::text").getall() if item.strip()])
            if len(meals) > 2:
                dinner = "&".join([item.strip() for item in meals[2].css("::text").getall() if item.strip()])

            yield {
                "date": date,
                "breakfast": breakfast if breakfast else "미운영",
                "lunch": lunch if lunch else "미운영",
                "dinner": dinner if dinner else "미운영",
            }

기존 테이블의 일자, 아침, 점심, 저녁 형태를 그대로 유지하여 output.csv를 구성하고자 결론을 내렸습니다. 그 결과 위와 같은 코드를 작성할 수 있었습니다.

이때, Spring 코드에서 데이터를 삽입하기 쉽도록 구성하고자 노력했습니다. 이를 위해 각 메뉴들을 &(Ampersand)로 구분하도록 했습니다.

주말과 같이 값이 비어있는 칸은 미운영으로 처리했습니다. 또한 날짜에 앵커 태그가 달려있어도 데이터를 가져오도록 하여, 원하는 형태의 결과물을 얻을 수 있었습니다.

스크래핑 결과인 output.csv

import constants
import boto3
import requests

OBJECT_NAME_TO_UPLOAD = 'output.csv'

s3_client = boto3.client(
    's3',
    aws_access_key_id = constants.access_key,
    aws_secret_access_key = constants.secret_access_key,
    region_name = 'us-east-1'
)

response = s3_client.generate_presigned_post(
    Bucket = 'dorm-menu',
    Key = OBJECT_NAME_TO_UPLOAD,
    ExpiresIn = 60
)

files = {'file' : open(OBJECT_NAME_TO_UPLOAD, 'rb')}
r = requests.post(response['url'], data=response['fields'], files=files)

이렇게 만들어진 output.csv 파일은 boto3을 통해 자동으로 S3 bucket으로 업로드됩니다.

버킷에 접근하기 위해서는 Generate_Presigned_Post을 이용했습니다. 이 방법을 사용하면 사전에 인증된 상태로 요청을 보내기 때문에, 클라이언트가 직접 S3에 접근하기 용이합니다.

이렇게 스크래퍼의 구현을 잘 마칠 수 있었습니다. (구현한 스크래퍼 전체 코드)

5. 자동화를 수행하다

AWS Lambda

스크래퍼를 만들었으니 이제 자동화를 진행해야 했습니다. 스크래퍼의 실행과 데이터 업데이트 두 가지 모두 자동으로 실행되도록 하고자 했습니다.

초기에는 데이터 업데이트를 위해 Item Pipeline을 사용하고자 했습니다. 하지만 고민 끝에, 익숙한 Spring 코드로 데이터를 업데이트하는 것이 좋겠다는 결론을 내렸습니다. 따라서 다른 팀원이 해당 API를 제작하고, 글쓴이는 이를 어떻게 하면 자동화를 할 수 있을지에 대해서 집중적으로 고민했습니다.

Lambda Function for Updating the Menu

주어진 문제는 이렇습니다.

스크랩을 한 정보를 데이터 베이스에 어떻게 자동으로 업로드할 수 있을까?

Spring 코드에서 output.csv 파일을 읽어 데이터 베이스에 저장하는 로직이 수행되고 있습니다. 따라서, 이를 적절한 타이밍에 요청해야 하는 상황이었습니다.

Lambda Trigger Configuration

이 문제는 람다의 Trigger를 지정하여 문제를 해결했습니다. 선택한 Bucket의 object가 생성되는 경우, 람다 함수가 실행되도록 설정되었습니다.

스크래퍼가 실행되어 자동으로 S3 Bueckt에 식단을 업데이트를 하면, 자동으로 람다 함수가 이를 읽는 API를 호출하는 것입니다.

def lambda_handler(event, context):
	# 로그인 데이터 예시
    login_data = {
        "email": "test@example.com",
        "password": "12345"
    }
    
    try:
        # 로그인 요청
        login_response = requests.post(login_url, json=login_data)
        login_response.raise_for_status()
        
        # `token` 키로 토큰을 가져옴
        token = login_response.json().get("token")
        
        # 헤더 설정
        headers = {
            'Content-Type': 'application/json',
            'Authorization': f'Bearer {token}'
        }

        body_data = {
            'key': 'output.csv'
        }

        response = requests.post(api_url, headers=headers, json=body_data)
        response.raise_for_status()
        
        return {
            'statusCode': 200,
            'body': response.text
        }
    except requests.exceptions.RequestException as e:
        return {
            'statusCode': 500,
            'body': str(e)
        }

다음으로는 위와 같이 HTTPS 요청을 보내는 람다 코드를 작성했습니다. Spring Security가 존재했기 때문에, 로그인을 먼저 선행하는 과정이 필요했습니다.

테스트 결과, 올바르게 데이터 베이스에 값을 업데이트할 수 있었습니다.

스케줄러를 잘 구성해보자

다음으로 이러한 문제를 해결해야 합니다.

어떻게 하면 식단 정보를 매주 자동으로 스크랩할 수 있을까?

이 또한 처음에는 Python 내부에서 Scheduler를 구성하고자 했습니다. 하지만 AWS 학습을 이어나가다 보니 그럴 필요가 없다는 것을 깨달았습니다.

Scarper 자체를 ECS Task로 올리고, EventBridge와 Lambda로 스케줄링을 해주어 문제를 해결했습니다.

ECS Task Definition

ECS Services

가장 먼저 Scrapy를 Docker Image로 만들어 ECR(Elastic Container Registry)에 업로드하였습니다.

이후 기존 Spring 서버가 돌아가던 ECS(Elastic Container Service)에 Scraper를 위한 서비스를 만들었습니다. 이로서 Scrapy Task가 돌아가기 위한 환경이 구성된 것입니다.

import boto3
import os

def lambda_handler(event, context):
    client = boto3.client('ecs', region_name='us-east-1')
    
    try:
        response = client.run_task(
            cluster=os.getenv('ECS_CLUSTER_NAME'),
            taskDefinition=os.getenv('ECS_TASK_DEFINITION'),
            launchType='FARGATE',
            networkConfiguration={
                'awsvpcConfiguration': {
                    'subnets': [os.getenv('ECS_SUBNET_ID')],
                    'securityGroups': [os.getenv('ECS_SECURITY_GROUP')],
                    'assignPublicIp': 'ENABLED'
                }
            },
            overrides={
                'containerOverrides': [
                    {
                        'name': os.getenv('ECS_CONTAINER_NAME'),
                        'command': ['python', os.getenv('ECS_MAIN_SCRIPT')]
                    }
                ]
            }
        )
        
        return {"status": "Task started successfully"}
    
    except Exception as e:
        return {"status": "Task failed to start", "error": str(e)}

다음으로는 Task를 업로드하는 람다 코드를 작성했습니다.

스케줄러를 설정하기 전 테스트를 진행하였고, Task가 업로드됨에 따라 스크래퍼가 잘 작동하는 것을 확인했습니다.

EventBridge Scheduler

마지막으로 EventBridge에서 람다 함수를 위해 스케줄러를 설정했습니다.

홈페이지에 식단 정보가 올라오는 정확한 시간을 알 수 없었기에, 최대한 넉넉한 시간으로 지정하였습니다.

오전 5시로 설정했다가 빈 값을 가져오는 문제가 발생했었다

다음 주 월요일, 테스트 결과 식단 정보를 잘 업데이트하는 것을 확인할 수 있었습니다.

이로서 스크래핑과 데이터 업데이트 모두 자동화에 성공할 수 있었습니다!

6. 인프라 결과물

그간의 설계 구상

최종적인 인프라 구조도

초기에 걱정했던, 기술적인 문제를 모두 해결할 수 있었습니다. 이번 사이드 프로젝트에서 문제를 마주하며, 배포와 CI/CD 그리고 스크래퍼 구현에 대한 기술을 익힐 수 있었습니다.

또 무엇보다도 AWS에 대한 관심과 학습을 이어간 것이 중요한 경험이 되었습니다. 특히 인프라에 대해서 완전히 무지한 과거에서, 이제는 스스로 인프라 구조를 그려낼 수 있을 정도로 성장했기 때문입니다. 이러한 성과물을 보면 다시 학습을 이어나갈 열정을 얻을 수 있다는 생각이 듭니다.

이제 배포일이 얼마 남지 않은 만큼 프론트와 연동을 빠르게 끝낼 예정입니다. 이후에는 사용자들의 반응을 받아보며 앱을 개선하는 시간을 가지고 싶습니다. 마지막까지 힘을 내어 꼭 프로젝트를 완수한 뒤, 세 번째 포스트로 돌아오겠습니다.

[스타트업] 2024년 10월의 창업 기록

모노산달로스 — Sun, 3 Nov 2024 18:03:29 +0900

스타트업 - 2024. 10

People follow the main character, finding meaning in his silent and steady run - Forrest Gump (1994)

2024. 10
이번 달은 새로운 활동을 시작하게 된 의미 깊은 달입니다. 삶의 목적이 있고, 그것에 의미를 부여할 때 비로소 인간은 행복을 느끼게 됩니다. 그러고 나서는 묵묵히 달려 나갈 뿐입니다. 지난 몇 달간, 여러 힘든 시간을 겪고 방황을 하고 있었습니다. 그러던 중 새로운 목표가 생겼고, 이제는 그것을 위해 열심히 뛰어가고 있습니다.

첫째 주(09.28 ~ 10.06)

창업 활동이 시작되었다. 우리는 목표를 세웠고, 세상을 관찰한다.

경기대학교에서 사전 인큐베이팅 교육이 진행되었습니다.

본격적인 활동은 사전 인큐베이팅 교육으로부터 시작되었습니다. 경기대 학생 팀과 일반인 팀이 경기대학교 창업지원단으로 모였습니다. 그리고 몇 가지 강의가 진행되었습니다. 사업의 전반적인 사이클에 대한 교육과 비즈니스 성향에 대한 교육을 들었습니다. 또 마지막으로는 마케팅과 예창패 대비에 관한 강의가 이어졌습니다.

가장 기억에 남았던 것 두 가지가 있었습니다. 첫째로 비즈니스 성향 분석 결과 메이트와 나 모두 '실행력'이 떨어진다였습니다. 그래서 팀원 중 실제로 '일'을 많이 할 사람이 필요하다는 이야기를 들었습니다. 물론 성과를 내지 못하는 것은 아니지만, 벌린 일의 수에 비해서 완수율이 부족하다고 돌아보게 되었습니다.

둘 째는 마케팅의 중요성과 예비창업패키지에 대한 내용이었습니다. 조금 떨어지는 아이디어도 훌륭한 마케팅이 있다면 돋보일 수 있었다는 게 인상 깊었습니다. 그리고 예비창업패키지에 대해 어떤 사업이 유리한지, 어떻게 준비하면 좋을지 교육을 받을 수 있었습니다.

교육이 끝나고, 예비창업패키지 선정이라는 새로운 목표가 생겼습니다. 우리는 꼭 결과를 보자고 다짐을 했습니다. 그리고 기존에 하던 활동들을 줄여 오직 창업에만 힘을 쏟아보자는 결론을 내렸습니다.

첫째 주 활동

이후 본격적으로 예비창업패키지를 준비하는 활동을 수행하기 시작했습니다. 디스코드를 통해 지속적으로 소통하고, 노션을 사용해 창업 활동을 기록했습니다.

첫 주차에는 기존에 준비했던 RPA에 대해 조사하고자 했습니다. 대체 이 기술이 무엇인가, RPA 산업 현황은 어떤가? 실제로 사용했을 때 어떤가? 알아보는 시간을 가졌습니다.

하지만 결과는 좋지 않았습니다. 기술의 활용 방법을 알아내기가 힘들었고, 기존 경쟁사와 차별점을 주기도 어렵다는 생각이 들었습니다. 따라서 자료조사와 회의를 거친 뒤 RPA 아이디어는 보류하게 되었고 새로운 아이디어를 찾고자 판단했습니다.

토스 사업 히스토리

그렇다면 아이디어는 대체 어디서 나오는가? 를 고민했습니다. 이때 가장 큰 영감을 준 것이 바로 토스의 이야기였습니다. "발로 뛰며 세상 사람들을 관찰하고, 문제를 파악한다." 우리는 기존의 데스크 서칭에서 벗어나, 이 방법을 차용해 보기로 했습니다.

그동안 모니터 앞에서 정보를 찾았던 우리를 돌아보았습니다. 그리고서는 우리도 직접 사람들이 있는 곳으로 나가서 관찰하자는 결론을 내렸습니다. 그리하여 하루 날을 잡아, 수원에서 유동인구가 가장 많은 수원역에서 모이게 되었습니다.

그렇게 토요일이 되었고, 역을 돌아다니며 사람들을 관찰하고자 했습니다. 다음으로 든 생각은 아, 이것이 가능한 걸까? 였습니다. 비록 쏟은 시간이 많지 않았지만, 정말 이 방법으로 아이디어를 얻을 수 있을까 의문이 들기 시작했습니다.

당시 예비창업패키지 준비에 매몰되어 있었던 우리는 조급해지기 시작했습니다.

라이프코드 창업 설명

그날 밤 우리는 아이디어를 얻는 방법에 대해 조사하기 시작했습니다. 그 결과 '나 문제'를 해결하라 라는 영상을 보게 되었습니다. 다른 이의 문제에 공감하는 것은 어려운 일이니 자신의 문제를 해결하라, 세상에 당신과 비슷한 사람은 무조건 존재한다.라는 이야기를 했습니다.

우리는 혼란스러웠습니다. 명확한 방법과 정답이 존재하는 기존의 학습이 아닌, 상황에 따라서 다른 해결책이 필요한 창업 학습이었기 때문입니다.

둘째 주(10.07 ~ 10.13)

아이디어를 찾아 헤매다. 실패한 인터뷰 작전

둘째 주 활동

둘째 주에는 다시 책상 앞에서 만났습니다. 그리고 우리가 해결할 문제를 찾기 시작했습니다. 브레인스토밍을 진행하며 여러 아이디어를 도출하고자 노력했습니다. 그 결과 '밤에 잠을 잘 시간이 밀리는 문제' 그리고 '인터뷰어를 구하기 힘든 문제'가 나오게 되었습니다.

이 중 수면 문제와 관련하여 더 깊게 디벨롭을 해보고자 하였습니다. 따라서 우리뿐만 아니라 사람들이 실제로 문제가 있다고 생각하는지 검증이 필요하다고 느꼈습니다. 이를 위해서 인터뷰를 진행하고자 했습니다.

이때 쯤 팀 명을 정하게 되었는데, 유미모로 결정되었습니다. You, Me, Momentum이라는 간단한 의미를 가지고 있습니다.

대면 인터뷰를 진행한 결과

인터뷰 항목을 정했습니다. 인사 방법, 잠을 잘 자는지 못 자는지, 그 이유는 무엇인지 물어보고자 했습니다. 우리는 스타필드에 모였고, 사람들에게 말을 걸기 시작했습니다.

모르는 사람에게 말을 걸어서 인터뷰를 진행하는 것은 쉽지만은 않았습니다. 계속된 시도 끝에 대략 8명 정도와 대화를 할 수 있었습니다. 하지만 의미 있는 정보를 얻지는 못했습니다.

문제는 검증 방법에 있었습니다. 우리가 원하는 정보는 설문조사로도 간단하게 얻을 수 있습니다. 하지만 실제로 대면 인터뷰어를 찾아 나서고 매우 큰 체력과 시간 손실을 보게 되었습니다. 즉, 인터뷰가 아닌 설문조사를 진행하는 것이 옳았던 것입니다.

분명 인터뷰는 정보를 얻는 좋은 방법입니다. 하지만 여러 질문을 통해서 깊은 대화를 진행해야만 인터뷰로서 의미가 있습니다. 짧은 질문 몇 가지를 던지는 것은 인터뷰로서 가치가 떨어졌습니다.

스타필드를 나오고 다시 머리를 맞대었습니다. 인터뷰 작전은 실패했고, 다음 검증 방법을 찾아야 했습니다. 결국 다시 데스크 서칭으로 돌아가서 수면과 관련된 정보들을 모으기 시작했습니다.

셋째 주(10.14 ~ 10.20)

자료 조사 그리고 BM을 세워보자.

셋째 주 활동

우리는 수면 문제에 대한 검증은 잠시 건너뛰고, BM을 세워보고자 했습니다. 비즈니스 모델 캔버스와 같은 도구를 사용하여 BM 세우기에 도전했습니다. 하지만 처음으로 세워보는 BM은 너무나 어려웠습니다. 특히 플랫폼 사업으로 한정되다 보니 구독, 인앱 결제, 광고 이외에 수단을 찾기가 힘들었습니다.

그 과정에서, 빠르게 개발하여 출시하고 사용자 반응을 보자는 결론을 내렸습니다. 기획 단계에 많은 힘을 쏟기보다는 우선 서비스를 배포하고 사용자 반응에 맞추어 피봇팅을 시도하자 생각했습니다.

회의를 자주하는 우리는 화이트보드를 애용하게 되었다.

이에 따라 빠르게 앱 구조도를 그린 뒤 필요한 기술 공부를 하고자 했습니다. 그리고 멘토링에서 물어볼 것들을 정리하기 시작했습니다.

넷째 주(10.21 ~ 10.27)

멘토링을 받고 조금씩 방향을 찾아가자.

넷째 주 활동

스타트업 비즈니스 모델 빌드업 프로그램에서 멘토링 교육을 지원해 주었습니다.

3주라는 기간 동안 방향을 잡지 못하고 헤매고 있었습니다. 첫 주차에 멘토링을 생각했을 때는, 사업 계획을 가져가서 멘토링을 받을 생각이었습니다. 하지만 그간 유의미한 성과를 내지 못했고, 창업을 준비하는 방법부터 알아야겠다는 결론을 내렸습니다.

좌측부터 창업메이트 김진형, 비원플러스 김형민대표님, 글쓴이 예비창업가 박성민

멘토링은 비원플러스 김형민 대표님께서 진행해주셨습니다. 이 멘토링은 어떻게 해야 할지 몰라 방황하던 우리에게, 중심점이 생기는 중요한 프로그램이었습니다.

멘토링이 끝나고 곧바로 내용을 정리했다.

멘토링의 주요 포인트가 몇 가지 존재했습니다.

하나는 기존 사고방식의 문제점입니다. 우리는 무작정 빠르게 구현하여 실패를 경험하자는 생각을 했습니다. 하지만 이는 힘들고 귀찮은 준비 과정을 건너뛰겠다는 생각이기도 합니다. 이에 대해 무작정 시도하고 실패하며 배우는 것이 아니라, 실패로 배움이 있을 때 시도하라. 이야기를 들었습니다. 우리는 기존에 생각했던 방법을 다시 고민하게 되었습니다.

다른 하나는 why? 를 통해 솔루션을 찾아가는 방법을 배웠습니다. 기존의 브레인스토밍 과정은 주먹구구 식으로 진행되었습니다. 멘토님과 함께 기존 아이디어에 why?를 이어가며 새로운 방법을 알게 되었습니다. 간단히 설명하자면, 질문을 타고 큰 문제를 쪼개어 해결하고자 하는 방법입니다. 이에 대해 멘토님은 오랜 시간 연습이 필요할 것이라고 이야기하였습니다.

마지막으로 창업을 왜 하는가? 를 고민해야 했습니다. 이 이야기는 조금 철학적이었지만 깊게 와닿았습니다. 창업을 하기 위해서 내적동기가 없다면 중간에 무너지게 된다는 이야기를 하셨습니다. 창업을 위한 창업을 하는 것은 아닐까? 생각을 해야만 했습니다. 시간을 가지고 각자 왜 창업을 하고자 하는지 고민을 해야겠다고 다짐했습니다.

예비창업패키지에 대한 조언은 이러했습니다.
지금 상황에서 내년 예비창업패키지에 도전하는 것은 어렵다. 마감기한에 매몰되어 아이디어를 구하고자 하니 더 힘들어지는 것이다. 심지어 그렇게 나온 아이디어로 선정되었다고 해도, 사업을 길게 가져갈 수 있을까? 그저 1년 하고 말 사업이라면 그것에 투자한 시간과 노력이 너무나 아깝다.

앞으로 방향성을 생각해보았다.

결국 우리는 예비창업패키지라는 목표를 없애었습니다. 그리고 창업 활동 기간을 더 길게 바라보고자 했습니다. 좋은 사업 아이템은 짜낸다고 나오지 않는다고 생각하게 되었습니다. 지금 기간 동안은 문제를 보는 지혜와 창업을 준비하는 힘을 키우고자 결론을 내렸습니다.

처음으로 해본 why? training

이에 우리끼리 처음 진행한 why? 의 결과는 굉장히 처참했습니다. 이렇게 하는 것이 맞는 건가?라는 생각을 계속했고, 명확한 결론도 내리지 못했습니다.

다시 절망할 수 있었지만, 조급해하지 않기로 했습니다. 그리고 지금 할 수 있는 것이 무엇일까? 이야기를 나누었고 기존에 실패했던 시장조사 인터뷰에 대해 고민했습니다.

설문조사를 위해 올릴 글 양식을 정했다.

기존에 시장조사 없이 아이템을 선정했기에, 아이디어에 계속해서 의문이 생기는 상황이었습니다. 따라서 설문조사를 시행하여 문제 정의를 명확히 하고자 했습니다. 이에 설문조사를 '잠을 제시간에 자지 못하는 문제'를 사람들이 어떻게 생각하는지 알아보는 내용으로 구성했습니다. (지금 돌아보면 시장조사라기보단 수요조사 수준이었습니다만)

이에 설문조사를 어떻게 하면 잘할 수 있을까? 에 대해 다시 공부하기 시작했습니다. 설문 조사 질문 구성 방법, 사람들의 응답을 얻어내는 방법을 고민했습니다.

고민 끝에 설문조사에 많은 사람들이 응답하지는 않을 것이라 생각이 들었습니다. 최소 모수인 30명을 기준으로 50명까지만 받아보자는 결론을 내렸습니다. 이에 응답자의 10%인 5명을 위한 보상으로 스타벅스 기프티콘을 준비했습니다.

그렇게 처음에는 이오, 디스콰이엇, 에브리타임 같은 우리가 평소에 접하는 사이트에 홍보를 하였습니다. 하지만 그 결과 응답자 수 10명 이상을 넘기지 못했습니다.

우선 설문조사를 올려두고 다시 why? training 단계로 돌아왔습니다. 이번에는 수면이 아닌 인터뷰어 매칭 플랫폼에 대해 why?를 시도했습니다.

인터뷰이와 설문조사 응답자를 구하기 힘든 이유를 고민하기 시작했습니다. 그러다 보니 왜 응답자 수가 저조할까?라는 질문이 떠올랐고, 이에 대해 고민하다 보니 도리어 우리가 시행한 설문조사의 문제점을 파악할 수 있었습니다.

절대적인 노출량이 부족한 이유를 분석했습니다. 그리고 우리가 올린 사이트는 사용자의 풀이 겹치니 다양한 사이트에 설문조사지를 올려야 한다는 결론을 내렸습니다. 사용자가 많은 DC인사이드, FM코리아 그리고 네이버 카페에도 설문조사를 홍보하게 되었습니다.

설문조사 응답자 수에 놀랐다

그 결과 예상을 훨씬 뛰어넘는 설문조사 응답을 얻을 수 있었습니다.

인터뷰어 매칭 플랫폼에 대해 더 디벨롭하다 보니 좋은 아이디어라는 생각이 들었습니다. 따라서 이를 구체화하기 위해 경쟁 플랫폼을 조사했습니다. 하지만 그 과정에서 우리가 제시한 솔루션을 고객이 사용할 이유가 없다는 결론이 내려졌고, 결국 보류되었습니다.

그와 별개로, 우리가 점차 why? 훈련에 적응해 가는 것이 느껴졌습니다. 앞으로도 문제 해결 방법을 찾기 위해서 마인드맵과 why?를 적극 사용하게 되었습니다.

다섯째 주(10.28 ~ 11.03)

조금씩 구체화되는 아이디어

다섯째 주 활동

다섯째 주는 조금 긴 휴가일을 가지게 되었습니다. 서로의 일정 조율이 잘 되지 않아 3일을 연속 회의를 진행하지 못했습니다.

이에 대해서도 조금 고민을 하게 되었습니다. 오랜 기간 관련 활동을 놓게 되니, 진행속도가 크게 더뎌졌기 때문입니다. 따라서 앞으로는 일주일에 단 하루만 휴가를 가지기로 결정했습니다. 서로 조율하여 하루를 정하고 비대면 학습 기간을 가지기로 결정했습니다.

하루의 휴가 기간은 멘토링에서 배운 것을 떠올려, 뇌를 쉬게 해 주는 시간을 가지자는 의미로 넣게 되었습니다. 회의를 할 때도 하나의 문제에 몰입되어 진행을 하지 못하는 경우, 쉬는 시간을 적절하게 부여하는 노하우를 얻게 되었습니다.

설문조사 분석과 솔루션 유도

월요일에는 설문조사 결과를 정리했습니다. 이에 사람들이 수면 문제를 확실히 느끼고 있다는 것을 알게 되었습니다. 따라서 본격적인 솔루션 도출 회의를 진행했고, 수면 솔루션으로 적절한 '보상'이 필요하다는 결론을 내렸습니다.

이는 앱 내부에 육성 시스템을 추가하자는 아이디어로 이어졌고, 이에 관련한 기존 서비스를 조사하였습니다. 그 결과 많은 앱들이 존재했고, Sleeptown과 Forest라는 앱을 발견하게 되었습니다.

금요일과 토요일은 수면 솔루션 관련 시장조사 및 기존 서비스 분석을 이어갔습니다. 그 결과 수면 테크 시장은 확실히 성장하고 있고, 소프트웨어를 통한 수면 개선이 큰 관심을 얻고 있다는 것을 알게 되었습니다.

그리고 기존에 찾았던 서비스의 단점과 장점을 정리하고 규합했습니다. 이렇게 시장조사 결과와 기존 서비스를 정리하니, 수면 개선 서비스는 디벨롭을 해봐도 좋겠다는 생각이 들었습니다. 따라서 본격적인 서비스 기능을 고민하기 시작했습니다.

당분간은 해당 서비스에 집중하여 회의를 진행하게 될 것 같습니다. 어떤 기능을 가져갈지, 어떻게 차별점을 줄지, 어떤 콘셉트로 구현할지 논의를 이어 갈 생각입니다.

마치며

컵라면으로 간단히 허기를 때우는 모습

창업 준비의 첫 달은 혼란의 연속이었습니다. 이제야 한 달을 겨우 넘기는 상황에서, 앞으로가 너무 두렵기도 합니다. 하지만 미래는 감히 예측할 수 없는 것이고 낙담하고만 있을 수도 없습니다. 그저 지금을 열심히 달려 나가고자 하는 마음뿐입니다.

11월에도 더 성장한 모습으로 글을 작성할 수 있으면 좋겠습니다.

[스타트업] 내가 창업 일지 기록을 시작한 이유

모노산달로스 — Sat, 2 Nov 2024 20:29:02 +0900

창업 기록 - 왜 기록하는가?

기록(記錄)이란

기록하지 않으면 존재하지 않는 것과 같습니다. 회사에서 일하는 순간, 여행에서 보내는 즐거운 순간, 집에서 음악을 들으며 사색에 잠기는 순간 모두 시간과 함께 사라집니다. 하지만 이를 글과 사진으로 기록한다면 언제든 그 순간을 다시 돌아볼 수 있습니다. 당신이 하고 있는 활동들에 의미를 부여하고 싶다면, 지금 당장 기록을 시작해야 합니다.

이 기록은 왜 하는가?

How to start writing?

창업 준비를 시작한 지 한 달이 지나고, 문득 생각이 들었습니다. 나는 무엇을 하고 있는 걸까?

항상 스스로를 채찍질하며 학습을 해나갑니다. 분명 내가 원하는 활동을 하고, 원하는 공부를 이어나가고 있습니다. 그런데 정말 잘하고 있는 걸까요? 이는 자신을 돌아보지 않으면 깨달을 수 없다는 생각이 들었습니다.

모든 과정 은 기록으로 남아야 합니다. 창업은 수많은 시행착오가 쌓이고 쌓여 오랜 시간이 지나서야 성과가 보이게 됩니다. 마치, 피라미드 꼭대기의 캡스톤(Capstone)처럼, 수많은 과정들위에 아주 작은 성과가 놓여있는 모습일 것입니다.

즉, 그간의 과정들이 모여 나의 성장 기반이 되는 것입니다. 그런데 과정들을 기록하지 않아 작은 성과만 남게 된다면, 그간의 시간과 노력들이 기억 속에서 사라지게 될 것입니다.

창업 활동뿐만 아니라 인생의 모든 것은 기록될 필요가 있습니다. 그 일환으로서, 현재 가장 큰 삶의 비중을 차지하는 창업 일지 기록을 시작하고자 합니다.

창업가가 되고자 다짐하다

여름에 했던 씨케이넷 인턴쉽

창업을 시작한 계기를 이야기하기 위해 올해 여름 7월로 거슬러 올라갑니다. 당시 경기대학교 산학협력으로 씨케이넷이라는 회사에서 인턴쉽을 진행했습니다.

이 활동에서 가장 좋았던 것은 사장님과 여러 대화를 나눌 수 있었다는 점입니다. 이 활동으로 여러 가지 인사이트를 얻을 수 있었는데, 특히나 '도구를 사용하는 사람이 아닌 도구를 만드는 개발자가 되어라'라는 말이 기억에 남았습니다.

개발자로서의 정체성
자기 주체성
어떤 개발자가 되어야 하는가
분명 개발을 좋아하는 것은 맞지만, 개발자로서의 미래는 조금 명확하지 못했습니다.
어릴 적 꿈이었던 프로그래머를 아직까지도 정처 없이 쫒고 있는 것은 아닐까?

이야기를 듣고 자신을 되돌아보는 생각을 하게 되었습니다.

Confusing

시간이 지나고 내년 상상기업 프로젝트에 대해 고민하기 시작했습니다. 인턴쉽에서 얻었던 아이디어를 바탕으로 이번에는 RPA 툴을 만드는 프로젝트를 진행하고자 했습니다. 그래서 이번 상상기업을 함께 했던 친구에게 RPA 프로젝트에 대해 이야기를 하였습니다.

우연찮게도, 프로젝트 제안을 했던 친구는 창업에 관심이 많은 친구였습니다. 평소에 열정적으로 동아리에서 활동하는 모습을 서로 보았고, 다음날 친구에게서 함께 창업에 도전할 생각이 있느냐? 는 질문을 받게 되었습니다.

자기 주도성이 강한 성격 탓에 창업에 관심이 없었던 것은 아닙니다. 회사원으로서의 미래와 내가 모을 수 있는 부에 대해서 고민도 했습니다. 하지만 두려움과 망설임 때문에 창업과 관련된 활동을 시작하지는 못했습니다. 막연히 개발자로서 성장해야겠다는 생각만 가지고 있었습니다. 이 대화는 도전이라는 작은 불씨에 장작불을 지피는 계기가 되었습니다.

학교에서 진행하는 창업 지원 사업

고민 끝에 창업 세계에 뛰어들고자 마음을 먹었습니다. 그 이후, 친구와 팀을 이루어 스타트업 비즈니스 모델 빌드업 프로그램에 지원하게 되었습니다.

지원 기간이 3일 남짓이었기에, 하루 내내 RPA에 관한 사업계획서를 작성했습니다. 그 결과 빌드업 프로그램에 합격할 수 있었습니다.

이것이 '창업'이라는 세계에 발을 들이게 된 계기입니다. 그렇게 9월 28일부터 창업 인큐베이팅 교육을 시작으로 본격적인 활동을 이어나가고 있습니다.

앞으로

“Everything will be okay in the end. If it's not okay, it's not the end.”

이 글을 작성하는 11월 2일은 창업 활동을 시작한 지 5주가 되어가는 날입니다.

10월의 경험과 함께 이어지는 활동을 모두 정리하여 창업 일지를 기록할 것입니다.

조금은 갑작스럽게 시작되었고, 지식도 부족하여 많이 헤매고 있습니다.

지금도 어려운 상황이지만, 앞으로는 더 크고 강한 역경들을 마주할 것입니다.

그럴때 이 기록이 큰 도움이 될 수 있다고 생각합니다.

포기하지 않고 이러한 활동이 쌓이고 쌓인다면 결국은 창업이라는 꿈을 이룰 수 있으리라 믿습니다.

[AWS] Route 53의 개념과 Records에 대하여

모노산달로스 — Mon, 28 Oct 2024 16:31:33 +0900

aws - Route 53, Records

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

Route 53

What is Route 53?

이전에 DNS(Domain Name Service)에 대해서 소개한 바 있습니다. Amazon Web Services에서 DNS를 관리하기 위해서 Route 53를 사용할 수 있습니다.

Route 53란 High Availability와 Scalability를 가지는 Authoritative DNS입니다. 여기서 Authoritative란 유저가 DNS records를 업데이트 할 수 있다는 것을 의미합니다.

Route 53의 주요 기능으로 도메인 생성 및 관리와 Health Check가 있습니다. 또한 100%의 SLA Availability를 제공한다는 특징이 존재합니다.

이번 포스트에서는 Route 53의 핵심인 Records에 대해서 정리해보겠습니다.

Route 53 - Records

What is Records?

Record(레코드)란 특정 도메인으로의 라우팅 방법을 정의한 것입니다. 각 레코드는 도메인 이름을 비롯한 여러 정보를 가지고 있습니다. Record Types, Routing Policy 그리고 TTL 등이 있습니다.

한마디로 정리하자면, 레코드를 사용하여 도메인 요청이 어떻게 라우팅될지 설정할 수 있습니다. 이러한 레코드의 타입으로 다양한 선택지가 존재하는데, 아래에서 주로 사용되는 4개의 타입을 정리했습니다.

Record Types

A
호스트 이름과 IPv4를 매핑합니다.

AAAA
호스트 이름과 IPv6를 매핑합니다.

CNAME
호스트 이름과 다른 호스트 이름을 매핑합니다. 대상은 A와 AAAA가 될 수 있습니다.
DNS namespace 혹은 Zone Apex의 상위 노드로 CNAME을 사용할 수 없습니다.
예를 들어 example.com에는 CNAME을 사용할 수 없지만, www.example.com은 가능합니다.

NS
Hosted Zone을 위한 Name Server
서버의 DNS 이름 또는 IP address로 Hosted Zone에 대한 DNS 쿼리 응답이 가능합니다.
트래픽이 도메인으로 라우팅 되는 방식을 제어합니다.

Hosted Zone

What is the concept of a hosted zone?

Hosted Zone이란 간단히 이야기해서 레코드의 컨테이너입니다. 도메인과 서브 도메인으로 가는 트래픽의 라우팅 방식을 정의합니다. 다시 말해, Hosted Zone은 특정 도메인 이름에 대한 DNS Records의 모음입니다.

Hosted Zone은 Public Hosted Zone와 Private Hosted Zone으로 구분할 수 있습니다. 두 방식은 이름 그대로 공개 여부에 따라 결정됩니다.

Public Hosted Zone은 누구든지 접근이 가능하며 도메인 이름의 IP가 무엇인지 알 수 있습니다. Public Domain을 살 때마다 Public Hosted Zone을 만들 수 있습니다.

Private Hosted Zone은 내부 네트워크에서만 접근이 가능하며 VPC만 URL resolve가 가능합니다. Private Domain을 지원합니다.

Public Hosted Zone vs Private Hosted Zone

What are the distinguishing features between the two?

Public Hosted Zone은 클라이언트로부터 온 쿼리에 응답이 가능합니다. 이를 통해 인터넷상의 도메인 이름을 IP address로 변환하거나, 트래픽을 AWS 리소스로 라우팅할 수 있습니다.

이에 반해 Private Hosted Zone은 VPC(Virtual Private Cloud) 내부에서 동작합니다. 이에 따라 VPC 내부에서만 사용되는 프라이빗 도메인 이름을 통해 프라이빗 리소스에 접근할 수 있습니다.

둘의 동작방식은 동일합니다. Route 53을 통해 domain name으로부터 IP address 정보를 얻어옵니다. 유일한 차이점은 Public은 누구나 레코드를 쿼리할 수 있고, Private는 VPC 내부에서만 쿼리가 가능하다는 점입니다.

Route 53 - Records TTL

What is TTL in Records?

TTL(Time To Live)는 캐시를 어느 시간만큼 가지고 있을지를 정합니다. DNS 쿼리를 하면 레코드 타입과 IP address 그리고 TTL을 받습니다. TTL은 이러한 결과를 캐시하도록 요청합니다. 즉, 다음에 같은 호스트 이름으로 접속하면 쿼리를 하지 않아도 되는 것을 의미합니다.

만약 TTL이 매우 길어지면, Route 53으로 향하는 트래픽은 매우 적어질 것입니다. 하지만 클라이언트가 오래된 레코드를 받을 가능성이 높아집니다. 즉, 새 레코드를 캐시에 저장할 때 까지 오랜 시간을 기다려야합니다.

반대로 TTL이 매우 짧아지면, Route 53으로 향하는 트래픽이 증가하고 이는 비용의 증가로 이어지게 됩니다. 하지만 오래된 레코드의 보관 기간이 짧아진다는 장점이 있습니다.

레코드를 변경하는 경우

1. TTL을 길게 만듭니다. 이를 통해 클라이언트가 기존 정보를 안정적으로 유지할 수 있습니다.
2. 모든 클라이언트가 긴 TTL을 가지고 있는지 확인합니다.
3. 모두 긴 TTL을 가지고 있다면 레코드를 변경합니다.
4. 레코드 업데이트가 모두 완료되면 TTL을 원래대로 돌려놓습니다.

Alias Records

How do Alias Records work?"

ELB 혹은 CloudFront와 같은 서비스를 사용하는 경우 호스트 이름이 노출됩니다. 이를 보유한 도메인 이름과 매핑하여 사용할 수 있습니다. 매핑을 하면 다양한 장점이 생깁니다. 예를 들어 서버나 인프라의 IP address가 변경되어도 도메인을 수정할 필요가 없어집니다.

앞서 언급한 CNAME은 호스트 이름을 다른 호스트 이름으로 매핑합니다. 이를 통해서 도메인 이름을 매핑할 수 있습니다. 하지만 CNAME은 루트 도메인에서 사용하지 못한다는 단점이 있습니다.

Alias Records또한 호스트 이름을 다른 호스트 이름으로 매핑합니다. 그런데 Alias Records는 CNAME와 달리 루트 도메인에서도 동작한다는 특징이 존재합니다.

Alias Records의 특징

- 기반 ELB에서 IP address가 변경되면 이를 바로 인식합니다.
- Zone Apex의 상위 노드로 사용될 수 있습니다.
- A 또는 AAAA의 record type을 사용하며 TTL이 자동으로 설정됩니다.

Alias는 Route 53에 한정되지만 호스트 이름이 특정 aws recource로 향하도록 할 수 있습니다. 장점으로 비용이 들지 않는다는 점, 자체적으로 헬스체크가 가능하다는 점이 있습니다.

Route 53의 기본적인 개념과 더불어 Records에 관련된 내용을 모두 정리했습니다.

다음 포스트에서는 Routing Policy에 대해서 알아보겠습니다.

[AWS] DNS(Domain Name System)가 대체 무엇인가?

모노산달로스 — Thu, 24 Oct 2024 15:40:59 +0900

aws - DNS

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

AWS에서 Route 53은 DNS의 역할을 수행하는 서비스입니다.
본격적으로 학습하기 전, DNS의 개념부터 정리하고 넘어가겠습니다.

DNS(Domain Name System)

What is DNS (Domain Name System) Before Learning About Route 53?

DNS(Domain Name System)이란 마치 전화번호부와 같은 역할을 합니다. 한 마디로 설명하자면, DNS는 host name을 IP address로 번역해 주어 우리가 실제 주소로 접근이 가능하도록 도와줍니다.

구글 사이트에 접속하기를 원하는 상황을 가정합시다. 우리는 www.google.com domain name을 가지고 있습니다. 하지만 실제로 사이트에 접속하기 위해서는 IP address가 필요합니다. 이때 DNS가 우리가 제시한 host name을 실제 IP address로 번역해 준다는 이야기입니다.

DNS Terminologies

Domain Register : Amazon Route 53, GoDaddy
DNS Records : A, AAAA, CNAME, NS
Zone File : contains BNS records 모든 DNS레코드를 포함한다. 호스트 이름과 IP를 매치시키는 방법
Name Server : resolves DNS queries (Authoritative or Non-Authoritative) 실제로 DNS 쿼리를 해결하는 서버
Top Level Domain : com, us, in, gov, org
Second Level Domain : amazon.com, google.com

How DNS Works

The Way DNS Works

그럼 DNS의 '번역'이라는 과정은 어떻게 작동하는 것일까요? 예시를 통해서 천천히 알아봅시다.

Web server가 하나 존재합니다. 우리는 example.com이라는 domain name을 통해서 해당 서버에 접근하고자 합니다. 그런데 내부적으로는 IP address를 알아낼 필요가 있습니다.

따라서 Local DNS server에게 해당 domain name에 대하여 물어봅니다. 만약 domain name에 해당하는 IP address를 알고 있다면 즉시 응답합니다. (캐시를 통해서 응답하는 경우입니다.)

처음 보는 domain name이라면 Local DNS Server가 다시 Root DNS Server에게 물어봅니다. Root DNS server는 인터넷의 최상위 DNS server입니다. 이때 .com을 사용한 것을 알고 있으니 .com에 대한 NS(Name Server)를 알려줍니다.

NS는 Name Server의 약자입니다.
DNS에서 NS 레코드는 특정 도메인 이름을 처리하는 Authoritative Server를 가리키는 역할을 합니다.
즉, 어떤 도메인의 DNS 쿼리에 대해 어느 서버가 해당 도메인에 대한 정보를 가지고 있는지를 알려주는 것입니다.

응답을 받은 Local DNS server는 .com에 대한 NS를 알게 되었으니 다시 TLD DNS server에게 물어봅니다. 그 결과 example.com에 대한 NS를 알 수 있습니다.

마지막으로 SLD DNS server에게 example.com의 주소를 물어봅니다. 이번에는 응답으로 실제 IP address를 얻을 수 있습니다. Local DNS server는 이를 웹브라우저에게 반환하고, 실제 web server에 접근이 가능하게 됩니다.

DNS 작동방식 요약

1. 사용자가 domain 입력 → Local DNS server 확인
2. cache에 없으면 Root DNS server에 요청
3. TLD DNS 서버에 연결 (예: .com)
4. SLD DNS 서버에서 최종 IP address 확인
5. IP address 반환 후 web server 접속

DNS에 대한 개념을 정리해 보았습니다. 다음 포스트부터는 본격적으로 Route 53에 대해서 알아보도록 하겠습니다.

[AWS] ElastiCache를 이해하고 캐싱 전략을 정해보자

모노산달로스 — Sun, 20 Oct 2024 20:19:48 +0900

aws - Aurora

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

ElastiCache

What is ElastiCache?

ElastiCache란 캐시 기술인 Redis 혹은 Memcached를 사용할 수 있도록 해주는 서비스입니다. 이를 통해 최적화와 모니터링 등 여러 관리 이점을 가질 수 있습니다.

Cache(캐시)란 무엇일까요? 한마디로 높은 성능과 짧은 대기시간을 가지는 인메모리 데이터베이스라고 할 수 있습니다. 캐시를 사용하면 읽기 워크로드에 대한 데이터베이스의 트래픽을 줄일 수 있습니다.

ElastiCache를 사용하기 위해서는 애플리케이션 코드의 변경이 필요합니다. 다른 서비스와 달리 활성화를 한다고 해서 즉시 캐시를 얻을 수는 없다는 이야기입니다.

해당 포스트에서는 ElastiCache에 대한 설명과 어떠한 캐싱 전략을 선택할지에 대한 내용을 정리해 보겠습니다.

ElastiCache Solution Architecture

How ElastiCache Works

가장 먼저 애플리케이션이 ElastiCache를 쿼리 하여 쿼리 오류가 발생했는지 혹은 이미 발생하여 ElastiCache에 저장되어 있는지 확인합니다.

이때, 응답할 데이터가 캐시에 존재하면 Cache hit이 발생하고 그렇지 않은 경우 Cache miss가 발생합니다. 만약 Cache miss가 발생하는 경우 데이터베이스로 다시 요청을 보내야 합니다.

이후, 동일한 쿼리를 수행하는 애플리케이션을 위해 캐시에 write 작업을 수행합니다. 이러한 캐시 기술은 데이터베이스의 트래픽을 줄이는 데에 매우 유용합니다. 다만, 캐시에 데이터를 저장하고 있기 때문에 최신 데이터가 사용될 수 있도록 캐시 무효화 전략을 잘 세워야 합니다.

캐시를 사용하여 유저의 세션 정보를 저장하는 것 또한 가능합니다.
1. 사용자가 로그인을 하면 애플리케이션이 ElastiCache로 세션 데이터를 보냅니다.
2. 사용자가 애플리케이션의 또 다른 인스턴스로 리다이렉트 되면 애플리케이션은 ElastiCache에서 세션 캐시를 검색합니다.
3. 이전에 세션 캐시를 작성했으므로 로그인 상태가 유지됩니다.
즉, 사용자의 세션을 저장하여 애플리케이션을 무상태로 만들 수 있습니다.

Redis vs Memcached

What is the difference between Redis and Memcached?

ElastiCache를 사용할 때 두 가지의 선택지가 존재합니다. 바로 Redis와 Memcached입니다. 둘의 차이점이 무엇인지 간단한 게 알아보고 넘어가겠습니다.

Redis
- Auto failover를 가진 multi-az가 존재합니다.
- read replica가 있어서 read를 스케일 하고 고가용성을 가집니다.
- AOF 지속성을 사용하는 데이터 내구성이 있습니다.
- 백업과 복원 기능이 있습니다.
- 세트와 정렬세트를 지원합니다.

Memcached
- 데이터 파티셔닝을 위한 멀티 노드를 사용합니다.(샤딩)
- 고가용성이 없고 복제도 없습니다.
- 지속 캐시가 아닙니다.
- 백업과 복원도 없습니다.
- 다중 스레드 아키텍처입니다. 따라서 샤딩을 통해 여러 인스턴스를 보유하고 있습니다.

간단히 정리하자면, Redis는 High Availability(고가용성), 백업, 읽기 전용 복제본 등의 기능을 가집니다. 이에 반해 Memcached는 오직 순수한 캐시 기능만 가집니다.

Caching Patterns

What are the Criteria for Choosing a Caching Pattern?

데이터 캐싱을 통해 많은 이점을 얻을 수 있습니다. 하지만 항상 캐싱을 해야 하는 것은 아닙니다. 예를 들어 데이터가 빠르게 바뀌고 데이터셋의 모든 키가 필요한 경우 캐싱은 비효율적일 수 있습니다.(anti-patterns)

따라서 올바른 캐시 사용을 위해 적절한 캐싱 설계 패턴을 선택할 필요가 있습니다. 패턴은 크게 세 가지 종류로 나눌 수 있습니다.

Lazy Loading / Cache-Aside / Lazy Population

How does Lazy Loading work?

Lazy Loading 혹은 Cache-Aside, Lazy Population이라고도 불리며 앞서 ElastiCache Solution Architecture에서 설명했던 방법과 동일하게 작동합니다.

read 작업 수행 시 캐시를 확인하고 만약 데이터가 존재하지 않는다면 데이터베이스에서 읽어옵니다. 이후, 캐시에 해당 데이터를 작성합니다.

장점은 오직 요청받은 데이터만 캐싱된다는 점이 있습니다. 또한 캐시가 삭제되거나 노드 실패가 발생해도 치명적이지 않습니다. 물론 캐시를 한 번 warm-up 해야 하므로 시간 지연은 발생합니다. (warm-up이란 예열한다고도 하며 캐시 데이터를 가지기 위해서는 모든 읽기가 RDS로 가야 한다는 뜻입니다.)

단점으로 캐시 미스인 경우 애플리케이션에서 3번의 네트워크 호출이 필요합니다. ElastiCache로 한 번, 데이터베이스로 한 번, 캐시를 쓰면서 한 번 발생합니다. 이는 지연 발생으로 이어지게 됩니다. 또한 오래된 데이터가 존재할 수 있습니다. 데이터가 RDS에서 업데이트되어도 캐시는 업데이트되지 않을 수 있기 때문입니다.

따라서 최신 데이터가 아니어도 일관성을 유지하는 것이 중요한지 고민할 필요가 있습니다.

Write Through

How does Write Through work?

Write Through는 데이터베이스가 업데이트될 때 케시를 추가하는 방식으로 작동합니다. 즉, 앱이 RDS 데이터베이스를 수정하는 경우 캐시를 작성합니다.

장점은 캐시 데이터가 항상 최신화되어 있다는 점입니다. 사용자는 캐시 데이터에 접근할 때 오래된 데이터를 가져오지 않을 수 있습니다.

단점으로 업데이트가 추가될 때까지 데이터 누락이 발생할 수 있습니다. 이를 해결하기 위해 Lazy Loading 전략과 결합하여 캐시 데이터가 없는 경우 가져오도록 할 수 있습니다. 또한 캐시 이탈률이 존재하여, 많은 캐시에 많은 데이터가 있지만 절대 읽히지 않는 경우가 존재합니다.

Lazy Loading과 비교하였을 때 가장 큰 차이점으로 wirte penalty가 생긴다는 점입니다. Lazy Loading은 cache miss가 발생하였을 때 read latency이 발생합니다. 반대로 Write Through의 경우 write 과정에서 무조건 캐시를 작성하기 때문에 write latency가 발생합니다.

사용자 관점에 따라 read latency 최적화를 더 중요하게 생각한다면 Write Through 방식이 더 적합하다고 볼 수 있습니다.

Cache Evictions and Time-to-live(TTL)

Cache Evictions?

캐시에는 제한된 크기가 있습니다. 따라서 캐시를 제거할 필요가 있는데 이때 Cache Eviction이 일어납니다. 가장 간단한 방법으로 캐시를 명시하여 삭제할 수 있습니다. 혹은 캐시 메모리가 가득 찬 경우 가장 오랫동안 사용하지 않은 데이터를 삭제하는 방법도 존재합니다. (LRU)

Cache Eviction의 또 다른 방법으로 TTL(Time-to-live)를 사용할 수 있습니다. 이는 쉽게 말해 캐시에 수명을 부여하고 시간이 지나면 삭제되도록 하는 것입니다.

TTL은 짧으면 몇 초에서 길면 며칠까지 갈 수도 있습니다. 매우 작은 TTL이라도 데이터가 자주 요청되는 경우에는 효과적일 수 있습니다.

다만, 메모리가 가득 차서 너무 많이 제거되는 상황이라면, 캐시 크기 자체를 늘릴 것을 고려할 필요가 있습니다.

There are only two hard things in Computer Science: cache invalidation and naming things.

컴퓨터 과학에서 가장 힘든 일은 캐시 무효화와 이름을 짓는 것이라는 명언이 있습니다. 그만큼 캐싱이라는 기술을 적용하기 매우 어려운 기술입니다.

해당 포스트에서도 정말 기초적인 내용만이 설명되고 있습니다. 캐시에 관해서는 AWS 학습이 끝이난 뒤 다시 한번 깊게 공부해 볼 필요가 있겠다는 생각이 듭니다.

이제 RDS, Aurora, ElastiCache까지 관계형 데이터베이스 서비스와 연관된 모든 내용 정리가 끝났습니다. 다음 포스트는 Route 53에 대한 내용으로 돌아오겠습니다.

[AWS] Amazon Aurora는 대체 무엇인가?

모노산달로스 — Sat, 19 Oct 2024 20:49:39 +0900

aws - Aurora

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

Amazon Aurora

What is Amazon Aurora?

Amazon Aurora란 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진입니다. aws의 독점 기술로서 클라우드 최적화가 되어있습니다.

Aurora 엔진은 다양한 기능을 통해 RDS에서 mySQL보다 5배, PostgreSQL보다 3배 뛰어난 성능을 보여줍니다.

데이터베이스 생성시 위와 같이 선택이 가능합니다.

1. 스토리지가 자동으로 늘어납니다. 데이터가 입력될수록 128TB까지 증가합니다.
2. Databasem 및 sysops로서 디스크 모니터링에 신경쓰지 않아도 됩니다.
3. Read replica를 15개까지 가질 수 있습니다.
4. 빠른 Failover 성능을 보여줍니다.

즉, Aurora는 비싼 가격을 지불해야하지만, 데이터베이스 엔진에 비해 뛰어난 성능을 보여주는 엔진입니다.

High Availability and Read Scaling

How does Aurora work?

Aurora는 3개의 AZ(Availabilty Zone)에 걸쳐 데이터 사본을 6개 저장합니다. write 작업에는 4개가 필요하고 read 작업에는 3개가 필요합니다. 즉, 한 AZ가 사용 불가 상태가 되어도 작동한다는 의미입니다. (High Availaiblity)

데이터 하나가 주어지만 자동으로 위 작업을 수행합니다. 사용자는 스토리지에 대해서만 관여하고, 이외의 모든 것은 aws가 관리합니다.

write 작업을 담당하는 인스턴스는 하나가 존재하며 이를 마스터라고 부릅니다. 이외에도 read 작업을 수행하기 위해 최대 15개의 read replica는인스턴스가 존재합니다.

이때, 만약 마스터가 동작하지 않으면 30초 이내에 자동으로 failover를 수행하여 replica중 하나가 마스터가 됩니다.

Aurora DB Cluster

How about Aurora as a cluster?

이번에는 클러스터로서 Aurora Database에 대해 알아봅시다.

클라이언트가 모든 인스턴스와 어떻게 인터페이스 할 수 있을까요? Aurora는 Auto expanding shared storage volume(자동 확장 공유 스토리지 불륨)이 존재합니다. 이는 모든 인스턴스가 동일한 데이터에 원활하게 접근할 수 있도록 보장합니다.

앞서 설명했듯이 마스터만 오직 write 작업을 수행합니다. 따라서 마스터를 가리키는 writer enpoint를 제공합니다. 즉, 마스터에 장애가 발생해도 클라이언트는 여전히 writer enpoint로 접근이 가능하다는 의미입니다.

Aurora는 Auto scaling 기능을 통해 자동으로 적절한 래플리카 수를 가집니다. 이때, 애플리케이션이 추적하기 어려운 상황이 발생할 수 있습니다. 예를 들어 래플리카의 위치, url, 연결방법 등이 그렇습니다. 따라서 reader enpoint가 제공되며, 모든 래플리카에 연결 로드 밸런싱이 지원됩니다.

Aurora Security

Aurora Security Operation Process

RDS와 Aurora에서 저장된 데이터를 암호화할 수 있습니다.

At-rest encryption(정지 상태 암호화)란 데이터가 저장될 때 자동으로 암호화하는 기능입니다. KMS(Key Management Service)에서 생성한 키를 통해 암호화를 수행합니다.

마스터를 암호화하지 못한 경우 read replica 또한 암호화 될 수 없습니다. 만약 암호화 되지 않은 기존 데이터베이스를 암호화하는 경우, 스냅샷을 가져온 뒤 암호화된 데이터베이스로 복원하는 과정을 거쳐야합니다.

In-flight encryption(전송중 상태 암호화)란 클라이언트와 데이터베이스간의 이동중인 데이터를 암호화하는 기능입니다. 이때, 클라이언트는 TLS 루트 인증서를 사용합니다.

이외에도 IAM roles을 사용하여 데이터베이스에 연결하거나, Security Groups로 RDS와 데이터베이스 연결을 제어할 수 있습니다.

Amazon RDS Proxy

How Does RDS Proxy Work?

VPC에 RDS 데이터베이스를 배포할 수 있습니다. 이때, Fully Managed Database Proxy(완전 관리형 데이터베이스 프록시) 또한 배포가 가능합니다.

RDS Proxy는 왜 필요할까요? 애플리케이션이 데이터베이스로 설정된 연결을 풀링하고 공유가 가능해집니다. 즉, 모든 애플리케이션을 데이터베이스가 아닌 프록시로 연결하면, 프록시가 이 연결을 데이터베이스에 대한 더 적은 연결로 풀링합니다.

Pooling(풀링)이란 자원을 모아두었다가 재사용하는 것을 의미합니다. 데이터베이스의 연결이 많은 경우 유용하며, CPU 혹은 RAM 등 리소스에 대한 스트레스를 줄여 효율이 증가하기도 합니다.

failover가 발생하면 프라이머리 인스턴스에서 스탠바이 인스턴스로 이동합니다. 이때, RDS 프록시를 사용하는 경우 failover 시간이 66% 줄어듭니다. 왜냐하면 애플리케이션에서 연결을 수정 할 필요도 없고, 프록시의 풀링 기능이 사용되기 때문입니다.

추가로 프록시에 IAM 인증을 사용할 수 있습니다. 즉, IAM 인증을 거치는 경우만 RDS 인스턴스에 접근이 가능하도록 할 수 있습니다. 이러한 자격 증명은 AWS Secret Manager에 의해 안전하게 저장됩니다.

RDS Proxy에 대한 내용을 정리하자면 다음과 같습니다.

RDS Proxy는 데이터베이스 인스턴스의 연결을 최소화하고 풀링하기 위해 사용합니다.
장애 조치 시간을 최소화 할 수 있으며, IAM 인증 시행 및 자격 증명이 가능하고 이는 ASM에서 안전하게 관리됩니다.

Aurora는 다양한 기능을 지원하는 강력한 엔진입니다. 가격 부담만 없다면 마음껏 사용해보고 싶은 기능 중 하나입니다.

다음 포스트에서는 Elasti Cashe에 대하여 알아보겠습니다.

[AWS] RDS(Relational Database Service)의 대한 이해

모노산달로스 — Thu, 17 Oct 2024 16:13:31 +0900

aws - RDS

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

RDS(Relational Database Service)

What is RDS(Relational Database Service)?

RDS(Relational Database Service)란 SQL 쿼리를 사용하는 데이터베이스를 위한 관리 서비스입니다. 다시 말해, aws에서 관리하는 관계형 데이터베이스를 생성할 수 있습니다.

RDS에서 생성 가능한 데이터베이스
Pstgres
MySQL
MariaDB
Oracle
Microsoft SQL Server
IBM DB2
Aurora(AWS Proprietary database)

RDS는 EC2 instance에 데이터베이스를 배포하는 것과는 조금 다릅니다. 완전 자동화, OS fetch, 백업 및 복원 기능 등 관리 서비로서 역할을 수행합니다. 다만, EC2 instance와는 다르게 SSH로 접근하는 것은 불가능합니다.

Storage Auto Scaling

What is Storage Auto Scaling?

RDS에서 데이터베이스를 생성하는 경우 스토리지 용량을 지정해야 합니다. 그런데 시간이 지나고 초기에 지정한 스토리지 용량으로 운영이 힘들어진다면 어떻게 될까요?

이러한 경우 RDS가 지정한 임계값을 통하여 자동으로 스케일링을 수행할 수 있습니다. 심지어 DB를 중단하지 않고 스케일링이 이루어집니다. 다만, Maximum Storage Threshold(최대 저장 임계값)을 설정하여 스토리지 최대 한도를 정해야 합니다. 이는 예측하기 힘든 애플리케이션 운영시 유용하게 사용됩니다.

자동으로 스토리지가 수정되는 경우는 아래와 같습니다.

할당된 저장 공간의 10% 미만이 남은 경우
부족한 저장 공간이 5분 이상 지속되는 경우
마지막 수정 이후 6시간이 지난 경우

RDS Read Replicas for read scalability

The relationship of read replicas in RDS

Read Replica란 읽기 전용 복제본이라고도 부르며, 애플리케이션이 데이터를 읽어오는 것만 가능한 데이터베이스 복제본입니다.

기본적으로 애플리케이션은 데이터베이스에 Read 작업과 Write 작업을 수행합니다. 이때, 메인 데이터베이스가 너무 많은 Read 요청을 받게 되면 성능이 저하되므로 읽기 전용 복제본을 만들어 Read Scalability를 확보하는 것입니다.

RDS에서 읽기 전용 복제본은 최대 5개까지 생성이 가능하며, 동일한 AZ(Availability Zone), 서로 다른 AZ 또는 서로 다른 리전에 생성될 수 있습니다. 이때, 애플리케이션은 복제본을 사용하기 위해 새롭게 연결 정보를 업데이트해야 합니다.

또한 복제본은 메인 데이터베이스로 승격할 수도 있으며, 이 경우 자체 생애주기를 가지게 됩니다.

Async Replication

What is ASYNC?

Async(Asynchronous)란 흔히 비동기 프로그래밍에서 사용되는 용어입니다. 쉽게 말해 여러 작업이 동시에 실행될 수 있다는 것을 의미합니다.

RDS에서 Async replication이란 데이터를 메인 데이터베이스에 먼저 작성된 이후에 복제 데이터베이스에 전달하는 것을 의미합니다. 이에 따라 결국 복제본의 데이터는 메인 데이터베이스와 일관성을 유지할 수 있게 됩니다.

Use Case

RDS read replica use case

그럼 이러한 read replica가 실제로 어떤 경우 사용되는지 알아봅시다.

평균적인 로드를 감당하고 있는 생산 데이터베이스가 존재한다고 가정합시다. 이때, 새롭게 기존 데이터를 기반으로 분석 및 보고를 수행해야 하는 상황이 발생했습니다. 이를 위해 새롭게 Reporting Application이 생겨났습니다.

그런데 Reporting Application이 생산 데이터베이스에서 데이터를 읽어온다면 어떻게 될까요? 기존에 비해 늘어난 작업량으로 인해 오버로드가 발생하고, Production Application의 속도가 느려질 것입니다.

이를 해결하기 위해서 read replica를 생성할 수 있습니다. 이 경우 Production Application이 영향을 받지 않으므로 좋은 해결책이 될 수 있습니다.

Networking Cost

Networking cost based on region and AZ

잠시 Networking Cost(네트워킹 비용)에 대한 이야기를 해봅시다. 앞서 read replica는 동일한 AZ, 서로 다른 AZ 또는 서로 다른 지역에 생성될 수 있다고 이야기했습니다.

기본적으로 한 데이터가 다른 AZ로 넘어가는 경우 비용이 발생하게 됩니다. 하지만 RDS read replica의 경우 다른 AZ여도 같은 지역에 존재한다면 비용이 발생하지 않습니다.

Multi-AZ

How Multi-AZ works?

그럼 본격적으로 Multi-AZ(다중 가용영역)에 대해 알아보겠습니다.

다중 가용영역은 주로 Disaster Recovery(재해 복구)를 위해서 사용합니다. 이는 스탠바이 인스턴스를 다른 AZ에 복제하는 것으로부터 시작합니다. stanby replica는 async replication을 통해 이루어지므로 변경사항이 그대로 복제됩니다.

이는 하나의 DNS를 통해 통신하는 경우, 메인 데이터베이스에 문제가 생기면 자동으로 스탠바이 데이터베이스도 failover(장애 조치)가 수행된다는 뜻입니다. 이때, 자동으로 stanby replica가 메인 데이터베이스로 승격하며 장애를 해결하게 됩니다.

이러한 과정은, High Availability를 확보를 의미하기도 합니다. 따라서 해당 기능을 다중 가용영역이라고 부르는 것입니다.

From Single-AZ to Multi-AZ

The process of creating a standby database

그렇다면 Single-AZ(단일 AZ)로부터 Multi-AZ(다중 AZ)로 전환이 가능할까요?

다중 AZ로 전환하는 작업은 다운타임이 없습니다.(Zero downtime opertaion) 즉, 데이터베이스를 중지하지 않아도 전환이 가능합니다. 간단하게 데이터베이스 수정 버튼을 누르고 다중 AZ를 활성화하면 됩니다.

이는 replication과정이 내부적으로 다음과 같이 작동하기 때문입니다.

1. RDS가 기본 데이터베이스의 스냅샷을 저장합니다. (EBS snapshot과 같은 원리)
2. 스냅샷은 새로운 스탠바이 데이터로 복원됩니다.
3. 복원된 후 동기화 과정이 일어납니다. 따라서 스탠바이 데이터베이스는 메인 데이터베이스의 모든 데이터를 가져옵니다.

RDS의 기본적이고 전반적인 내용을 정리한 포스트입니다. 다음으로 Aurora database에 대해 알아본 뒤 순차적으로 Security와 Cache까지 나아가 보겠습니다.

[AWS] ASG(Auto Scaling Group)의 대한 이해

모노산달로스 — Thu, 17 Oct 2024 00:21:14 +0900

aws - ASG

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

ASG(Auto Scaling Group)

What is ASG(Auto Scaling Group)?

ASG(Auto Scaling Group)란 서버의 생성과 제거를 자동화하는 서비스를 의미합니다. ASG에서 최소 및 최대 EC2 instance의 수를 설정할 수 있습니다. 이에 따라 scale-out과 scale-in을 수행합니다.

웹사이트나 애플리케이션의 사용자의 수는 계속 변화합니다. 따라서 시간이 지나면서 데이터 로드 수치가 변화할 수 있습니다. 이때 aws에서 서버를 빠르게 생성하고 제거할 수 있는데, 이를 자동화하는 것이 바로 ASG입니다.

ASG scale out with ELB

ELB와 연결하여 사용할 수도 있습니다. 로드 밸런서가 EC2 instance의 상태를 unhealthy 하다고 여기면 ASG가 인스턴스를 종료시키고 새로 만드는 것도 가능합니다. 만약 scale-out이 발생하면 해당 인스턴스에도 부하를 분산시킵니다.

Scaling Policies

You can define the capacity of an ASG

Scaling Policies는 ASG에서 인스턴스 수를 자동으로 조정하기 위한 규칙으로, 워크로드 변화에 따라 작동하는 방식을 설정하는 정책입니다. 생성 가능한 전략은 크게 두 가지로 나눌 수 있습니다.

Dynamic Scaling은 실시간 모니터링된 지표를 기반으로 하는 방식입니다. 세 가지 방법으로 다시 나누어 볼 수 있습니다.

Target Tracking Scaling
CPU 사용율과 같은 매트릭과 목표값을 지정합니다. 이에 따라 ASG가 실행됩니다.
간단하게 셋업이 가능합니다.

Simple / Step Scaling
CloudWatch alarm을 정의하여 일정 조건 달성시 알람을 발생시킵니다. 이에 따라 ASG가 실행됩니다.

Scheduled Scaling
미리 알려진 패턴을 기반으로 스케일링을 예측합니다.
예를 들어 매일 오후 1시에 사용자가 증가한다면 ASG가 해당 시각에 capacity를 증가시킵니다.

Predictive Scaling은 과거 데이터를 기반으로 하는 방식입니다.

지난 트래픽 패턴을 분석하여 예측치를 생성하고 스케일링 작업을 예약합니다.
예기치 못한 변화 대응에 특히 효과적입니다.

Good metrics to scale on

How to choose the right metric?

그렇다면 좋은 metric(측정 기준)에 대해서 이야기 해봅시다.

일반적으로는 CPU Utilization(CPU 사용률)을 주로 사용합니다. 인스턴스의 평균 CPU 사용률이 높아지면 활용도가 높아졌다는 것을 의미하기 때문입니다.

Request Count Per Target(대상별 요청수)를 사용할 수도 있습니다. EC2 instance는 한 번에 타깃별로 1000개의 요청이 들어오면 최적으로 작동합니다. 이에 맞추어 인스턴스 수를 조절할 수 있습니다.

Average Network IN / OUT(평균 네트워크 유입 / 유출)은 네트워크에 의존적인 서비스에서 사용을 고려할 수 있습니다. 다시 말해, 업로드와 다운로드가 잦고 인스턴스 병목 현상이 일어날 것이라 생각되는 경우가 그렇습니다.

이외에도 CloudWatch를 통해서 원하는 매트릭을 자유롭게 사용할 수 있습니다.

Scaling Cooldowns

What is Scaling Cooldowns?

Scaling Cooldowns란 스케일링 작업 후 인스턴스를 추가하거나 제거할 때마다 일정한 대기 시간을 가지는 것을 의미합니다. 쿨다운 시간 동안 ASG는 새롭게 인스턴스를 생성하거나 제거하지 않습니다.

왜 쿨다운이 존재할까요? 그 이유는 매트릭을 안정화하고 새로운 인스턴스가 적용된 뒤 매트릭의 변화를 살피기 위함입니다. 성능을 위해 ready-to-use AMI를 사용하면, EC2 instance 생성 시간을 줄여 요청을 더 빠르게 처리할 수도 있습니다.

ASG에 대한 내용이 끝이 났습니다. 이로서 고가용성과 확장성에서 시작하여 이것을 다루는 aws의 전반적인 서비스들을 모두 정리하였습니다.

이제 다음 포스트 부터는 RDS와 관련된 내용으로 넘어갑니다. RDS는 관계형 데이터 베이스 서비스로서 Aurora와 ElastiCache등 다양한 내용이 존재합니다.

아직 다룰 내용이 정말 많이 남아있습니다. 계속 정진해야겠습니다.

[AWS] ALB(Application Load Balancer) & NLB(Network Load Balancer) & GWLB(Gateway Load Balancer)의 이해 및 차이점 비교

모노산달로스 — Wed, 16 Oct 2024 00:55:54 +0900

aws - ELB

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

ELB(Elastic Load Balancer)

What is ELB(Elastic Load Balancer)?

ELB(Elastic Load Balancer)란 확장성과 고가용성을 지원하기 위한 서비스로서 인스턴스로 들어오는 트래픽을 관리해 주는 역할을 합니다. ELB의 대한 전반적인 내용은 이전 포스트에서 정리했습니다.

이번에는 ELB의 각 타입 ALB(Appliaction Load Balancer), NLB(Network Load Balancer) 그리고 GWLB(Gateway Load Balancer)의 대해 정리해 보겠습니다.

OSI 7 Layers

The structure of OSI 7 Layer

ELB 타입들을 설명하면서 레이어 계층에 관한 이야기가 등장합니다. 만약 네트워크에 대한 CS지식이 전무한 경우 이해가 어려울 수 있습니다. 따라서 본격적으로 설명에 들어가기 전 OSI 7 Layer에 대해서 간단하게 알아봅시다.

OSI 7 Layer은 네트워크 통신을 단계별로 나눈 모델로, 각 계층이 특정 역할을 담당하여 데이터 통신이 이루어집니다. 외우기 보다는 가볍게 읽고 넘어가시면 좋을 것 같습니다.

1. Physical Layer(물리 계층): 하드웨어적 연결을 담당하며, 전기 신호나 물리적 매체를 통해 데이터를 전송합니다. (케이블, 전압 등)
2. Data Link Layer(데이터 링크 계층): 물리 계층에서 전달된 데이터를 프레임으로 변환하고, 오류 제어 및 흐름 제어를 수행합니다. (MAC 주소, 스위치 등)
3. Network Layer(네트워크 계층): 데이터를 패킷으로 분할하고, 서로 다른 네트워크 간에 데이터를 라우팅 합니다. (IP 주소, 라우터 등)
4. Transport Layer(전송 계층): 데이터 전송의 신뢰성을 보장하고, 데이터 분할 및 재조립을 관리하며, 오류 검출과 흐름 제어를 수행합니다. (TCP/UDP 등)
5. Session Layer(세션 계층): 통신 세션의 설정, 유지, 종료를 관리하며, 장시간 통신이 필요한 응용 간의 연결을 제어합니다.
6. Presentation Layer(표현 계층): 데이터 형식의 변환, 암호화, 압축 등을 처리하여 데이터를 통신할 수 있는 형태로 변환합니다. (데이터 인코딩, 암호화 등)
7. Application Layer(응용 계층): 사용자와 직접 상호작용하는 계층으로, 네트워크 서비스 및 애플리케이션을 제공합니다. (HTTP, FTP, 이메일 등)

깊이 있게 설명하기에는 주제와 벗어나는 이야기 이기 때문에 간단하게 정리했습니다. 이후의 내용을 이해하는 데에 조금이나마 도움이 되었으면 좋겠습니다.

ALB(Application Load Balancer)

What is ALB(Application Load Balancer)?

ALB(Application Load Balancer)란 네트워크 레이어 7 계층에서 동작하는 타입의 ELB입니다. 머신간 다수의 HTTP 애플리케이션 라우팅에 사용합니다. 지원하는 통신 방법은 HTTP/HTTPS 그리고 WebSocket입니다.

ALB의 특징으로 경로 라우팅을 지원합니다.

URL 패스에 기반한 라우팅이 가능합니다.
URL의 호스트 이름에 기반한 라우팅이 가능합니다.
쿼리 문자열과 헤더에 기반한 라우팅이 가능합니다.

모바일 사용자는 1번 그룹, 데스크톱 사용자는 2번 그룹으로 트래픽을 보내자고 가정합시다. 이를 위해 타겟 그룹을 둘로 나누어줍니다. 이후, 쿼리 문자열에 기반하여 경로 라우팅을 사용합니다.

사용자로부터 신호가 오면 ELB는 쿼리 문자열을 확인합니다. 이후 결과에 따라서 사용자 트래픽을 분산하여 각 그룹에 전송합니다.

What is Dyanmic Port Mapping?

ALB는 동적 포트 매핑을 지원하기 때문에 고정되지 않은 ECS instance의 동적 포트 리다이렉션이 가능합니다.

ECS instance는 하나의 인스턴스에 여러 컨테이너가 실행됩니다. 이때, 각 컨테이너는 서로 다른 임의의 포트에서 서비스됩니다. 동적 포트 매핑을 사용하면 ALB가 대신 임의로 지정된 포트로 트래픽을 전송합니다.

따라서 ALB는 마이크로 서비스나 컨테이너 기반 애플리케이션에 사용할 때 추천됩니다.

ALB의 대해 알아두면 좋은 정보
1. 고정 호스트 네임이 부여됩니다.
2. 애플리케이션 서버는 클라이언트 IP를 직접적으로 알 수 없습니다. 이를 위해서 헤더를 확인해야 합니다. (X-Forwarded-For)
3. 포트와 프로토콜도 마찬가지로 헤더를 확인해야 합니다. (X-Forwarded-Port, X-Forwarded-Protocol)

NLB(Network Load Balancer)

NLB(Network Load Balancer)란 네트워크 레이어 4 계층에서 동작하는 타입의 ELB입니다. 따라서 TCP와 UDP 트래픽을 처리합니다.

높은 성능의 로드 밸런서로 초당 수백만건의 트래픽을 처리할 수 있습니다. 지연시간 또한 ALB에 비하여 굉장히 짧습니다.

Load Balancing

NLB는 AZ(Availability Zone)당 하나의 고정 IP가 존재합니다. 그리고 각 AZ에 Elastic IP를 배정할 수 있습니다. 따라서 여러개의 고정 IP가 있는 애플리케이션 노출 시 유용합니다.

한 가지 재미있는 것은 ALB앞에 NLB를 둘 수도 있습니다. 그렇게 하면 NLB로 고정 IP를 얻고 ALB로 HTTP 트래픽 처리를 할 수 있습니다.

GWLB(Gateway Load Balancer)

GWLB(Gateway Load Balancer)는 네트워크 레이어 3 계층에서 동작하는 타입의 ELB입니다. 즉, 모든 로드 밸런서 중 가장 낮은 레이어에서 동작합니다.

주로 aws의 타사 네트워크의 가상 어플라이언스 플릿 관리를 위해 사용합니다. 여기서 가상 어플라이언스 플릿이란 네트워크 관련 작업을 수행하는 여러 개의 가상 장치(Virtual Appliances)로 구성된 집합을 의미합니다.

Operation process of GWLB (Gateway Load Balancer)

GWLB는 유저가 트래픽을 보내면, 가상 어플라이언스가 존재하는 Target Group으로 트래픽을 전송합니다. 그럼 여러 가상 장치들이 네트워크 트래픽을 분석합니다.

이후 분석 결과에 따라 트래픽의 목적지를 결 정합니다. 본래 목적지인 EC2 instance로 보낼 수도 있고 보안에 문제가 있다고 판단되면 트래픽을 버릴 수도 있습니다.

ELB의 모든 타입들에 대해 글로 정리하였습니다. CLB(Classic Load Balancer)는 이제 사용되지 않는 서비스이므로 해당 글에서는 제외되었습니다.

이제 ELB에 대한 내용이 모두 정리되었으니 ASG에 대해 살펴볼 수 있게 되었습니다. 로드 밸런서에 대한 내용은 길고 복잡하지만 정말 중요한 서비스이므로 꼭 완벽히 이해하고 넘어가야 할 것 같습니다.

[AWS] ELB(Elastic Load Balancer)의 대한 이해

모노산달로스 — Tue, 15 Oct 2024 23:28:51 +0900

aws - ELB

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

ELB(Elastic Load Balancer)

What is ELB(Elastic Load Balancer)?

ELB(Elastic Load Balancer)란 확장성과 고가용성을 지원하기 위한 서비스로서 인스턴스로 들어오는 트래픽을 관리해 주는 역할을 합니다.

ELB는 Managed Load Balancer라고도 부르며 aws가 관리하며 업데이트, 고가용성, 유지보수를 보장합니다. 또한 EC2 instance, ASG, ECS 등 aws의 다양한 서비스들과 연동이 가능합니다.

aws의 ELB를 사용하는 것이 자체적으로 로드 밸런서를 마련하는 것보다 훨씬 저렴하며 확장성도 뛰어납니다. 해당 포스트를 통해서 ELB의 개념에 대해 차근차근 알아봅시다.

Load Balancing

What is Load Balancing?

Load Balancing이란 aws 서버 혹은 서버 셋으로 트래픽을 다운스트림 EC2 instance(백엔드)로 전달하는 역할을 수행합니다. 이때, 트래픽을 다수의 다운 스트림 인스턴스로 분산하여 전달합니다.

더 많은 유저가 연결될수록 EC2 instance로 가는 부하가 분산됩니다. 하지만 유저는 자신이 어떤 인스턴스에 연결되는지는 알 수 없습니다.

로드 밸런싱이 필요한 이유
트래픽을 다수의 다운 스트림 인스턴스로 분산하기 위해서 사용합니다
애플리케이션에 DNS를 노출하고 다운스트림 인스턴스 장애를 원활하게 처리하기 위해서 사용합니다(Health Check 메커니즘)

로드 밸런싱의 특징
SSL Termination을 통하여 HTTPS 트래픽을 가질 수 있습니다
Cookie를 통해 Session Affinity(세션 고정성)을 가질 수 있습니다
AZ(Availability Zone)사이에서 High Availability(고가용성)을 가집니다
개인 트래픽과 공공 트래픽으로 분리가 가능합니다

로드 밸런싱에 대한 많은 내용들이 한 번에 정리되었습니다. 이제 하나하나 살펴보며 각 특징들을 이해해 봅시다.

Type of load balancer on AWS

You can select a type when creating a load balancer in AWS

aws에는 4가지 종류의 Load Balancer가 존재합니다. 기본적으로 더 많은 기능을 가지는 최신 로드 밸런서 사용이 권장됩니다.

CLB(Classic Load Balancer)
HTTP, HTTPS, TCP, TLS, SSL을 지원합니다
가장 초기 형태의 로드 밸런서로 현재는 사용을 권장하지 않습니다

ALB(Application Load Balancer)
HTTP, HTTPS, WebSocket을 지원합니다
Application layer에서 동작하는 로드 밸런서입니다

NLB(Network Load Balancer)
TCP, TLS, UDP을 지원합니다
Network layer에서 동작하며, 가장 높은 성능을 가지는 로드 밸런서입니다

GWLB(Gateway Load Balancer)
Network layer에서 동작하며, 보안 및 침입 감지 등 방화벽의 역할을 수행합니다

해당 포스트는 ELB의 전반적인 내용을 다루고 있습니다. 따라서, 각 로드 밸런서에 대한 설명은 여기서 자세히 정리했습니다.

Load Balancer Security Group

How to setup security group for ELB

로드 밸런서의 Security Group 생성시 다음과 같이 트래픽을 허용해야 합니다. HTTP/HTTPS를 사용하는 ELB를 예로 들어봅시다.

Users는 HTTP/HTTPS를 통해 로드 밸런서에 접속합니다. 따라서 ELB는 HTTP/HTTPS 트래픽을 허용해야 합니다. 인스턴스의 경우 모든 트래픽이 로드 밸런서를 통해서 넘어오도록 해야합니다. 따라서 EC2 instance는 로드 밸런서의 시큐리티 그룹을 참조합니다.

Session Affinity(세션 고정성)

What is Session Affinity?

Session Affinity(세션 고정성)란 로드 밸런서가 같은 클라이언트의 요청을 같은 인스턴스로 보내는 것을 의미합니다. 위 그림과 같이 user1의 트래픽은 항상 첫 번째 EC2 instance로 흘러가는 것이 그 예시입니다.

세션 고정성이 왜 필요할까요? 사용자의 로그인과 같은 중요한 세션 데이터를 유지하기 위해 동일한 인스턴스에 연결할 필요가 있습니다. 이런 경우 고정성을 활성화할 필요가 있습니다. 하지만 일부 인스턴스가 고정 사용자를 가지게 되어 트래픽의 불균형이 생길 수 있어 주의가 필요합니다.

Cookie(쿠키)를 통해 세션 고정성을 구현할 수 있습니다. 쿠키는 고정성과 만료 기간이 존재하며, 쿠키가 만료되면 다른 EC2 instance로 트래픽을 전송합니다.

Cookie

What is Cookie?

Cookie는 세션 고정성을 위해서 사용될 수 있습니다. 이를 위한 cookie로 Application-based Cookies와 Duration-based Cookies두 종류가 존재합니다.

Application-based Cookies

Custom Cookie
타겟 그룹으로부터 생성됩니다
애플리케이션에 필요한 사용자 정의 속성을 가집니다
쿠키 이름은 그룹별로 작성합니다 이때, AWSLAB, AWSALBAPP은 사용하지 않습니다. 이는 ELB에서 사용하는 이름입니다.

Application Cookie
로드 밸런서로부터 생성됩니다
쿠키 이름으로 AWSALBAPP를 사용합니다

두 쿠키는 애플리케이션에서 만료 기간을 정할 수 있습니다

Duration-based Cookies

Duration Cookie
로드 밸런서로부터 생성됩니다
쿠키 이름으로 ALB를 위해 AWSALB가 사용됩니다

중요한 것은 쿠키의 기반이 둘로 나뉘고 ELB가 선점한 쿠키 이름이 존재한다는 것입니다.

Cross-Zone Load Balancing

What is Cross-Zone Load Balancing

Cross-Zone Load Balancing(교차 영역 로드 밸런싱)이란 쉽게 말해 로드 밸런서가 모든 가용 영역의 인스턴스에 트래픽을 분배하는 것입니다. 위 그림에서 100의 트래픽이 10개의 인스턴스에 고르게 분포되어 있습니다. 즉, 두 개의 ELB는 서로 다른 AZ의 모든 인스턴스에 일정한 양의 트래픽을 전달하고 있습니다.

교차 영역 로드 밸런싱이 없으면 특정한 AZ에 한정되어 트래픽을 전달하게 됩니다. 만약 EC2 인스턴스 개수가 불균형한 경우 특정 AZ의 인스턴스가 더 많은 트래픽을 전달받게 됩니다.

Application Load Balancer
기본적으로 활성화 상태입니다 (타겟 그룹 레벨에서 비활성화 가능)
데이터가 다른 AZ로 넘어가도 비용이 부과되지 않습니다

Network Load Balancer & Gateway Load Balancer
기본적으로 비활성화 상태입니다
데이터가 다른 AZ로 넘어가면 비용이 부과됩니다

Health Check(상태 체크)

What is Health Check?

Health Check(상태 체크)란 ELB가 타겟 인스턴스의 작동이 올바른지 확인하는 과정을 의미합니다. 만약 상태 체크에 실패하는 경우 트래픽을 전송하지 못하기 때문에, 트래픽을 전송하기 전에 꼭 거쳐야 하는 과정입니다.

상태 체크는 포트와 라우트에서 이루어집니다. 먼저 특정 endpoint에서 인스턴스의 응답을 기다립니다. 만약 응답받은 상태 코드가 200이 아니라면 해당 인스턴스를 unhealthy 상태로 기록합니다. 그리고 해당 인스턴스에게 트래픽을 보내지 않습니다.

Connection Draining

What is Connection Draining

Connection Draining(연결 드레이닝)이란 인스턴스가 등록 중, 종료 중 혹은 unhealthy 상태인 경우 처리 중인 요청을 완료할 수 있도록 시간을 주는 것을 의미합니다. 즉, 인-플라이트 요청(in-flight requests)을 안정적으로 완료할 수 있도록 도와주는 기능입니다.

연결 드레이닝은 1부터 3600초 사이의 값으로 설정할 수 있습니다. 이때, 짧은 요청의 경우 낮은 값으로 설정하는 것이 좋습니다.

예를 들어, 1초보다 적은 아주 작은 요청은 30초 정도로 설정합니다. 그렇게 되면 EC2 instance가 빠르게 드레이닝과 교체를 수행합니다. 만약 파일 업로드와 같이 시간이 오래 걸리는 요청은 높은 값으로 설정하여 EC2 instance가 바로 사라지지 않도록 합니다.

ELB에 관한 전반적인 내용을 다루어보았습니다. 다음 포스트로는 ELB의 각 타입들인 ALB, NLB, GWLB의 대하여 정리하여 보겠습니다. 그러고 난 뒤 ASG에 대한 내용으로 넘어가겠습니다.

Scalability와 High Availability 그리고 ELB와 ASG 모두 연관이 있기에 순서대로 잘 정리하여 공부를 이어나가야겠습니다

[AWS] Scalability(확장성) & High Availability(고가용성)의 개념

모노산달로스 — Tue, 15 Oct 2024 18:46:09 +0900

aws - Scalability & High Availability

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

ELB(Elastic Load Balancer)에 대하여 본격적으로 알아보기 앞서 필요한 개념에 대하여 정리해 봅시다.

Scalability(확장성) & High Avaliability(고가용성)

Scalability는 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리하는 것을 의미합니다.

Vertical Scalability

What is vertical scalability?

Vertical Scalability란 수직 확장이라고도 불리며, 인스턴스의 크기를 확장하는 것입니다. 전화교환원을 예를 들어 생각해 봅시다. 신입 전화교환원을 숙련된 전화교환원으로 교체하면 더 많은 양의 일을 처리할 수 있습니다.

인스턴스에 있어서도 마찬가지입니다. t2.micro의 인스턴스 타입을 t2.large로 업그레이드하는 경우가 바로 vertical scalability를 수행하는 경우입니다.

RDS 혹은 Elasti Cache와 같은 데이터베이스 같이 분산되지 않은 곳에서 주로 사용합니다. vertical scalability은 하드웨어의 성능에 따라 한계가 정해진다는 특징이 존재합니다.

인스턴스의 크기를 키우는 것을 scale-up, 인스턴스의 크기를 줄이는 것을 scale-down이라고 부릅니다.

Horizontal Scalability

What is horizontal scalability?

Horizontal Scalability란 수평 확장이라고도 불리며, 인스턴스의 수를 늘리는 것입니다. 전화교환원의 예시를 들어보자면, 전화교환원의 수를 늘려 더 많은 작업을 수행하기 하는 것입니다. 수평 확장이 사용되는 경우 분배 시스템이 존재한다는 것을 의미하기도 합니다. (현대 대부분의 앱이 분배 시스템을 가집니다)

Amazon EC2와 같은 서비스 덕분에 매우 간단하게 horizontal scalability를 수행할 수 있습니다.

인스턴스의 수를 늘리는 것을 scale-out, 인스턴스의 수를 줄이는 것을 scale-in이라고 부릅니다.

High Availability

What is High Availability

High Availability란 시스템을 적어도 둘 이상의 AZ(Availability Zone) 혹은 데이터 센터에서 가동중인 것을 의미합니다. 전화교환원을 예로 들자면, 전화교환원이 배치된 장소를 둘로 나누는 것과 같습니다.

고가용성을 통해서 하나의 데이터 센터가 손실되더라도 그 피해를 최소화 할 수 있습니다. 즉, Busan의 전화교환소가 먹통이 되어도 Seoul의 전화교환원이 그 일을 대신 할 수 있는 것입니다.

High Availability는 Passive High Availability와 Active High Availability 으로 나뉠 수 있습니다.

수동형 고가용성 : 하나의 인스턴스가 작동중인 경우 다른 인스턴스는 대기상태를 유지하는 것
활성형 고가용성 : 두 인스턴스가 동시에 작업을 수행하는 것

추후에 나올 ELB와 ASG을 이해하기 위해서 필요한 개념을 정리해보았습니다. 짧은 내용이지만 꼭 필요한 내용이라 따로 포스트를 남겼습니다.

[AWS] EBS(Elastic Block Store) & EFS(Elastic File System)의 대하여

모노산달로스 — Mon, 14 Oct 2024 15:17:06 +0900

aws - EBS & EFS

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

EBS(Elastic Block Store)

What is EBS(Elastic Block Store)

EBS(Elastic Block Store)란 EC2 Instance가 실행 중인 동안 연결 가능한 네트워크 드라이브를 의미합니다. 여기서 네트워크 드라이브란 네트워크를 통해 접근할 수 있는 저장 공간을 의미합니다. 중요한 특징으로 인스턴스가 종료된 후에도 데이터를 유지할 수 있다는 점이 있습니다.

EBS volume이란 생성한 EBS의 구체적인 스토리지 단위를 의미합니다. 특정 가용 영역에서만 생성 가능하다는 특징이 존재합니다. 즉, us-east-1a에서 생선 된 경우 us-east-1b에서는 생성이 불가능합니다.

EBS volume Level
CCP Level : 하나의 EC2 인스턴스에 하나의 EBS 마운트 가능
Associate Level : 하나의 EC2 인스턴스에 다중의 EBS 마운트 가능

USB Stick

EBS volume을 쉽게 이해하기 위해서 USB stick과 같은 역할을 한다고 생각하면 됩니다. USB는 하드웨어에 연결되어 데이터를 저장하고 연결이 끊어져도 데이터가 유지됩니다. 마찬가지로 EC2 Instance에 연결되고 끊어지면서 데이터를 저장할 수 있는 공간입니다.

다만 네트워크 드라이브이기 때문에 지연이 발생할 수 있다는 차이점이 존재합니다. 또한 특정 AZ(Availability zone)에 고정되어 있다는 특징이 있습니다. 이를 다른 가용 영역으로 옮기기 위해서는 Snapshot이라고 부르는 방법을 사용해야 합니다.

EBS can be attached within the same availability zone

EC2 Instance 생성 시 자동으로 생성되는 EBS volume을 root volume이라고 합니다. 이 root volume은 기본적으로 EC2 Instance 종료 시 함께 삭제되도록 설정되어 있습니다. 이를 설정하는 부분이 바로 Delete on Termination attribute입니다. 만약 root volume이 삭제되기를 원하지 않는다면 해당 부분을 disabled 하면 됩니다.

EBS Snaptshot

How to use snapshot for EBS?

앞서 EBS는 특정 AZ에 고정되어 있다고 설명을 했습니다. 그리고 이를 해결하기 위해서 사용하는 snapshot에 대해서도 언급을 했습니다. 그럼 대체 snapshot이 어떤 역할을 할까요?

Snapshot은 쉽게 말해서 EBS를 특정 시점에 Backup 하는 것과 같습니다. 만들어진 snapshot은 다른 가용 영역에서도 접근이 가능합니다. 따라서 snapshot을 통해 EBS를 생성하면 마치 다른 AZ의 EBS를 복사하는 것과 같은 결과를 얻을 수 있는 것입니다.

EBS Snapshot Archive
snapshot을 더 저렴한 archive tier로 옮기는 것을 의미합니다. 아카이브는 복원 시 24시간에서 72시간의 대기시간이 필요합니다.

Recycle Bin
snapshot을 영구적으로 삭제하는 대신 휴지통에 보관합니다. 실수로 삭제한 경우 복원이 가능하며, 하루에서 1년까지 보관 규칙을 설정할 수 있습니다.

FST(Fast Snapshot Restore)
snapshot을 완전히 초기화하는 것을 의미합니다. 크기가 매우 큰 snapshot로 EBS volume을 초기화하는 경우 사용합니다. 비용이 많이 든다는 특징이 있습니다.

EBS Volume Types

Amazone EBS volume types

EBS volume 생성시 여섯가지 선택지가 존재합니다. 이 요소들은 Size, Thorughput, IOPS로 정의할 수 있습니다. 위 표에 나타나는 네 가지의 타입은 boot volume으로 사용될 수 있는 특징이 있습니다.

General Pupose(gp2 / gp3)
비용 효율적인 스토리지로서 낮은 대기 시간을 가집니다. 가상 데스크톱, 개발 및 테스트 환경에서 자주 사용합니다. gp2의 경우 IOPS와 처리량을 독립적으로 늘리는 것이 불가능합니다.

Provisioned IOPS(io1 / io2)
IOPS 성능이 높은 스토리지입니다. 데이터베이스 작업이 스토리지 성능과 일관성에 매우 민감한 경우 적합합니다. multi-attached를 지원한다는 특징이 있습니다.

Hard Disk Drives(st1 / sc1)
매우 큰 저장량이 필요한 경우 사용하는 스토리지입니다. boot volume으로 사용할 수 없으며, 비용이 비교적 저렴합니다. sc1는 아카이브와 같은 역할로 데이터 접근이 매우 적은 경우 사용합니다.

32000이상의 매우 높은 IOPS가 필요한 경우 EC2 Nitro와 io1 혹은 io2를 사용해야합니다.

EBS Multi-Attached

EBS multi-attached to the EC2 instances

이제 앞서 언급한 EBS Multi-Attached 기능에 대해서 알아봅시다. 하나의 EBS volume을 여러개의 EC2 instance에 할당하는 기능을 의미합니다. 이때, EBS volume와 EC2 instance는 같은 AZ에 존재해야합니다.

io1와 io2 type에서 사용이 가능하며, 각 EC2 instance는 고성능의 volume 읽기와 쓰기 권한을 가지게 됩니다. 동시 쓰기 작업을 관리하는 경우 유용하며 하나의 EBS volume은 최대 16개의 EC2 instance에 할당될 수 있습니다.

EFS(Elastic File System)

EFS(Elastic File Sytem) mount to the EC2 instances

EFS(Elastic File System)은 관리형 NFS(Network File System)으로 서로 다른 AZ에 존재하는 여러 EC2 instance에 할당 될 수 있습니다. 웹 서빙, 데이터 공유, Wordpress등 다양하게 사용됩니다. 가용성이 높고 확장성이 뛰어나지만 EBS에 비해 가격이 비싸다는 특징이 있습니다.

NFS Protocol을 사용하며 액세스 제어를 위해 Security Group 설정이 필요합니다. linux기반 AMI만 호환되며, POSIX라는 file system을 사용합니다.

EFS Performance & Storage Classes

Amazone EFS performance

EFS를 생성할 때 EFS Performance에 관련된 설정을 정할 수 있습니다. General Perpose, Max I/O 그리고 Max Thorughput이 존재합니다.

General Purpose (default)
웹 서버 혹은 CMS와 같이 latency에 민감한 서비스에서 사용합니다.

Maximum IOPS
빅 데이터 혹은 미디어 프로세싱에서 사용합니다. 높은 throughput과 높은 latency를 가집니다. parallel 하게 작동합니다.

Maximum Thorughput
Bursting, Provisioned, Elsatic 세 가지 선택지가 존재합니다. Bursting은 실제 사용중인 스토리지 용량에 따라 처리량을 확장합니다. Provisioned는 스토리지 크기에 상관 없이 처리량 설정이 가능합니다. Elastic은 워크로드에 따라 자동으로 처리량을 설정해줍니다.

일반적으로는 Elastic을 사용하는 것이 추천됩니다.

EFS Storage Tier

마찬가지로 EFS Storage Classes 또한 설정할 수 있습니다. Storage Tier는 세 가지가 존재하며 액세스 주기에 따라 역할이 달라집니다.

Storage Tier
Standard : 자주 액세스 하는 데이터를 저장합니다.
Infrequent Access(EFS-IA) : 자주 액세스 하지 않는 데이터를 저장합니다. 파일 검색시 비용이 발생하지만 저장 비용이 감소합니다.
Archive : 거의 액세스하지 않는 데이터를 저장합니다.

세 개의 계층간 이동은 Lifecycle Policies를 통해서 자동화 될 수 있습니다.

추가로 Availability와 Durability 설정이 가능합니다. Multi-AZ는 여러 AZ에 접근이 가능하며 프로덕션 환경에서 주로 사용합니다. One Zone은 하나의 AZ에 고정되어 있으며 주로 개발 용도로 사용합니다.

위와 같이 상황에 맞게 올바른 클래스 스토리지를 사용하면 매우 높은 비용 절감 효과를 얻을 수 있습니다.

EFS Practice Screen using CLI

EFS를 사용하면 위와 같은 결과를 얻을 수 있습니다. 서로 다른 AZ에 존재하는 EC2 Instance 1와 Instance 2가 존재한다고 합시다. 둘은 하나의 EFS에 연결되어 있습니다.

이러한 상황에서 EC2 Instance 1에서 hello.txt 파일을 생성하였습니다. 이후 EC2 Instance 2에서 같은 경로로 접근하면 앞서 생성한 hello.txt 파일에 접근이 가능합니다. 즉, 다른 AZ에 존재하는 EC2 Instance가 같은 파일 시스템을 공유하고 있다는 의미입니다.

EC2 Instance Store

EBS volume은 좋은 네트워크 드라이브입니다. 하지만 네트워크로 연결하는 특성상 성능이 제한될 수 밖에 없습니다. 따라서 더 좋은 성능이 필요하다면 EC2에 연결된 하드웨어의 성능이 뛰어나야합니다.

Instance store temporary block storage for EC2 instances

EC2 Instance Store는 물리적 서버에 연결된 하드웨어 드라이브로서 뛰어난 I/O 성능을 가집니다. 하지만 EC2 Instance가 종료되면 스토리지도 같이 손실되기 때문에 임시 스토리지라고 부르기도 합니다. 즉, 장기 데이터를 보관하기 위해서는 추천되지 않습니다.

버퍼, 캐시, 스크래치 데이터 등 일시적 콘텐츠에 적합하며, EC2 인스턴스 기본 서버에 장애가 발생하면 연결된 스토어에도 장애 발생합니다. 따라서 데이터의 백업과 복제가 필요하다는 특징이 있습니다.

What is AMI(Amazon Machine Image)?

AMI(Amazone Machine Image)의 대한 내용은 약간 범위에서 벗어난 내용이라 과감하게 생략했습니다. 간단하게 설명하자면 EBS의 snapshot과 같은 역할을 하지만, EC2 Instance를 위해 사용된다고 이해하면 좋을 것 같습니다.

EC2의 스토리지에 관한 내용이 끝이 났습니다. 네트워크 드라이브의 개념에 대해서 이해한다면 어렵지 않은 내용이였습니다.

특히 EBS type의 종류와 더불어 EFS, EC2 Instance Store와의 차이점을 위주로 공부하면 좋을 것 같습니다.

[AWS] EC2(Elastic Compute Cloud)의 대하여 with SSH로 EC2 Instance 접근하기

모노산달로스 — Sun, 13 Oct 2024 23:01:07 +0900

aws-EC2 with SSH

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

EC2(Elastic Compute Cloud)

What is EC2(Elastic Compute Cloud)

EC2(Elastic Compute Cloud)란 마치 aws 서비스의 Infrastructure와 같습니다. 단순히 하나의 서비스가 아니라 여러 기능을 포괄하고 있습니다.

EC2는 매우 중요한 위치에 있습니다. 클라우드 서비스란 컴퓨터 기능을 필요에 따라 임대하는 것을 의미합니다. 즉, EC2의 사용 방법을 이해하는 것은 클라우드 기능의 사용 방법을 이해하는 것과 같습니다. 해당 포스트에서는 이러한 EC2 그중에서도 EC2 Instance에 대하여 자세히 알아보겠습니다.

EC2 : 가상 머신을 빌리는 기능
EBS : 가상 드라이브에 데이터를 저장하는 기능
ELB : 머신들 사이의 부하를 분배하는 기능
ASG : auto-scaling group을 사용하여 서비스를 스케일링하는 기능

EC2 Configuration options

Page of the creating EC2 instance

EC2 Instance 생성시 여러 가지 Option을 선택할 수 있습니다.

OS : Linux, Mac, Windows ...
CPU : How much compute power & cores
RAM : How much random-access memory
EBS & EFS : How much storage space
Network Card : Speed of the card, public IP address
Firewall rules : security group
Bootstrap script : EC2 User Data

여기서 중요한 부분은 가상 머신의 특정 부분을 설정하고 임대가 가능하다는 것입니다. 아래에서 몇 가지를 살펴보겠습니다.

EC2 Instance types

EC2 Instance type

EC2 Instance type은 매우 많은 선택지가 존재합니다. 해당 정보는 아마존 공식 홈페이지에 자세히 정리되어 있습니다.

컴퓨팅 - Amazon EC2 인스턴스 유형 - AWS

aws.amazon.com

모든 Instance type을 설명할 수는 없지만, 각 Instance type은 다음과 같은 규칙으로 구분할 수 있습니다.

예를 들어 m5.xlarge Instance type을 분석해봅시다.
m은 Instance class를 의미합니다. m 혹은 t와 같은 type은 general purpoes로서 일반적으로 사용될 수 있는 type입니다.
5는 세대(generation)를 의미합니다. aws가 해당 type의 새로운 버전을 출시할 때마다 숫자가 늘어납니다.
2xlarge는 instance class의 크기를 의미합니다. 크기가 클수록 많은 리소스를 사용할 수 있습니다.

EC2 User Data

EC2 User data configuration

Bootstrap이란 컴퓨터 실행 시 수행하는 초기 작업들을 의미합니다. EC2 Instance에서 같은 역할을 하는 것이 바로 user data입니다.

EC2 Instance 생성 시 Advanced 설정으로 위와 같이 User data를 입력할 수 있습니다. 이는 Bootstrap 작업을 시작할 때 실행되는 스크립트입니다. 해당 스크립트는 root user로 실행된다는 특징이 있습니다.

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

위와 같이 User Data를 설정할 수 있습니다. 시스템 업데이트, 아파치 웹 서버 설치, index.html 생성 등의 작업들을 자동화하는 역할을 수행합니다.

Secruity Groups

What is Inbound traffic and Outbound traffic

Security Groups는 AWS 네트워크 보안의 기본으로서, EC2 Instance의 방화벽과 같은 역할을 하기도 합니다. 즉, 인스턴스로 들어오고 나가는 트래픽을 허용하는 부분을 담당합니다. 이때, 각 트래픽을 Inbound Rules과 Outbound Rules으로 구분하여 관리할 수 있습니다.

Inbound traffic이란 위 그림과 같이 웹과 같은 외부 요소에서 EC2에 접근하는 것을 의미합니다. 반대로 Outbound traffic은 EC2 Instance에서 다른 웹 혹은 애플리케이션으로 신호를 보내는 것을 의미합니다.

Creating Security Group

Rule 생성시 위와 같은 요소들을 통해 규제가 가능합니다. Port의 대한 범위, IPv4 혹은 IPv6의 대한 범위로 규칙을 정할 수 있습니다.

Port number는 고전적으로 아래와 같은 의미를 가집니다.
22 : SSH - Linux instance에 로그인하는 경우
21 : FTP (File Transfer Protocol) - file share로 파일을 업로드하는 경우
22 : SFTP (Secure File Transfer Protocol) - SSH를 사용하여 파일을 업로드 하는 경우
80 : HTTP - 웹사이트에 암호화되지 않은 상태로 접근하는 방법
443 : HTTPS - 웹사이트에 암호화된 상태로 접근하는 방법
3389 : RDP (Remote Desktop Protocol) - Windows instance에 로그인하는 경우

이러한 Security Groups는 몇 가지 특징을 가집니다.

첫 번째로 하나의 Security Groups에 인스턴스가 여럿 존재할 수 있습니다. 반대로, 하나의 EC2 인스턴스는 여러 보안 그룹에 속할 수도 있습니다. 이를 통해 각 인스턴스에 대한 다양한 트래픽 규칙을 적용할 수 있으며, 네트워크 접근 제어를 더욱 세밀하게 설정할 수 있습니다.

두 번째로 특정 지역 혹은 VPC 조합에 의해 제한된다는 특징이 있습니다. 즉, 새로운 VPC 혹은 다른 지역에서 사용하는 경우 새롭게 그룹을 생성해야 합니다. 특히 추후 설명할 SSH 액세스를 위해서는 별도의 그룹이 존재하는 것이 추천됩니다.

EC2 Instance에 public IP로 접근 시 에러가 발생하는 경우 다음과 같은 상황을 의심할 수 있습니다.

Timeout error 발생 : Security Groups 설정이 되어있지 않은 상황
Connect Refused 발생 : Traffic이 통과되었지만 애플리케이션에서 에러 발생

Referencing other security groups

Referencing other security groups Diagram

Security Groups 생성 시 위와 같이 다른 Security Group을 참조하는 것이 가능합니다. 예를 들어, 데이터베이스 서버가 속한 보안 그룹이 웹 서버가 있는 보안 그룹을 참조하여, 웹 서버에서만 데이터베이스 서버로의 트래픽을 허용하는 식으로 설정할 수 있습니다.

위 그림은 Inbound Rules로서 Security Group 1와 Security Group 2에 대해 허용을 하는 경우 를 나타내고 있습니다. 따라서 해당 보안 그룹에 속하지 않은 세 번째 EC2 Instance은 신호를 보내도 거부됩니다.

SSH(Secure SHell)로 EC2 Instance 접근하기

What is SSH(Secure SHell)?

SSH(Secure SHell)란 네트워크를 통해 원격 시스템에 안전하게 접속하고 제어할 수 있도록 하는 암호화된 통신 프로토콜입니다. Windows, Linux, Mac 등 모든 OS에서 사용 가능합니다. 특이하게도 Windows환경에서는 PuTTY를 사용 하는 방법도 있습니다.

이러한 SSH를 통해서 EC2 Instance를 CLI(command-line interface)로 조작할 수 있습니다. 보안그룹에서 포트 22 (SSH)를 허용했다면, 웹으로 22번 포트를 통해 접근하여 터미널 혹은 커맨드라인에서 EC2 Instance에 접근이 가능하게 됩니다.

아래는 실제로 SSH를 통해 EC2에 접근하는 과정입니다.

EC2 Instance 생성시 위와 같이 Key pair를 생성 할 수 있습니다.

위와 같이 .pem 형태로 생성이됩니다. 해당 파일을 통해 SSH로 터미널 혹은 커맨드라인에서 접근이 가능합니다.

ssh -i <pem file name> <user name>@<EC2 Instance public IP>

첫 접근시 위와 같이 에러가 발생하는 경우가 있습니다. key의 보안 수준이 너무 낮다는 의미입니다. 따라서 보안 수준을 높여주어야합니다.

chmod 0400 <pem file name>

위와 같이 보안 수준을 설정해줍니다.

이후 다시 접근하면 위와 같이 EC2 Instance에 잘 접근되었음을 확인 가능합니다.

이후 aws의 IAM 유저 리스트를 출력해보고자 합니다. 그러면 credentails configure를 수행하라고 나타납니다. 이때, Access Key를 그대로 입력하는 것은 좋은 방법이 아닙니다. EC2 Instance에 매우 민간함 정보가 저장되기 때문입니다.

대신 Instance의 IAM Role을 업데이트 해주는 방법을 사용할 수 있습니다.

업데이트 후 다시 명령어를 실행하면 IAM user의 정보가 출력되는 것을 확인할 수 있습니다.

가장 유명하고도 많이 사용되는 EC2에 대한 첫 포스트입니다.

AWS에서 가장 중요한 부분이라고도 생각되고 많은 분들이 처음 접하는 서비스라고도 생각합니다.

후에 나오는 서비스들과도 유기적으로 연결되니 꼭 잘 정리하고 넘어가야 할 것 같습니다.

[AWS] IAM(Identify and Access Management)의 대하여

모노산달로스 — Fri, 11 Oct 2024 19:49:43 +0900

aws - IAM

AWS(Amazon Web Services)

AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.

IAM에 대한 요약
사용자 및 권한을 안전하게 관리하는 서비스
Users : 실제 유저와 대응되어 생성한다. 각 유저가 고유의 비밀번호를 가진다.
Groups : 각 사용자들은 그룹으로 묶을 수가 있다.
Policies : 유저 혹은 그룹별로 권한을 부여한다. JSON 형태로 작성 가능하다.
Roles : EC2 instances 혹은 AWS services를 식별하기 위해 사용한다.
Security : MFA + Password Policy를 통해 보안성을 높일 수 있다.
AWS CLI : command-line으로 aws services 접근한다.
AWS SDK : programming language로 aws services 접근한다.
Access Keys : CLI 혹은 SDK에서 AWS를 사용하기 위해 필요하다.
Audit : IAM Credential Reports & IAM Access Advisor 등의 관리 도구를 사용할 수 있다.

IAM(Identify and Access Management)

What is IAM(Identify and Access Management)

IAM(Identify and Access Management)가 대체 무엇일까요? 한 마디로 정의하자면 AWS에 접근하는 사용자들과 각종 권한을 관리하는 서비스입니다.

AWS의 서비스들은 Console에서 설정한 지역에 따라 모두 달라집니다. 하지만 IAM은 한 지역에 종속되지 않고 Global 하게 동작합니다. 본격적으로 IAM의 각종 서비스를 설명하기 앞서 알고 가야 하는 개념이 있습니다. 바로 Root account와 User입니다.

Root account와 User에 대한 설명을 표현한 그림

Root account는 사용자가 생성한 AWS 계정 자체를 의미합니다. 모든 서비스에 접근 권한을 가지고 있다는 특징이 있습니다. 보안상의 이유로 Root account를 통해 작업을 수행하지는 않습니다.

User는 권한을 부여받을 사용자를 의미합니다. 실제 사용자들과 1대 1로 대응되는 개념이라고 생각할 수 있습니다. 마치 새로운 계정을 생성하는 것처럼 이름과 비밀번호가 존재합니다. Root account가 아닌 다른 유저들은 해당 계정을 통해서 콘솔에 접속이 가능합니다.

Group은 user들이 속해있는 조직을 의미합니다. 예를 들어 위 그림에서 Danny, Park, Jun은 Operator라는 Group에 속해있습니다. 즉 실제로 그들이 속한 팀에 맞게 Group을 생성하고 권한을 부여할 수 있다는 의미입니다. Jun, Mark처럼 두 가지 그룹에 속할 수도 있고 Lisa처럼 아무런 그룹에 속하지 않을 수도 있습니다.

Root account 혹은 IAM user로 접속이 가능합니다

Permissions

특정 User 혹은 Group은 권한을 부여 받습니다

앞서 설명한 User 혹은 Group들은 Policies를 할당할 수 있습니다. 말 그대로 사용자들에게 허가 할 작업들을 정의하는 것입니다. 예를 들어 IAM User를 읽어오는 권한을 부여하면 해당 Group은 IAM에 어떤 계정이 존재하는지 확인할 수 있습니다.

한 가지 유의 할 점으로 권한 부여시 최소권한원칙(Principle of Least Privilege)을 준수해야합니다. 불필요한 권한을 부여하지 않고 꼭 필요한 만큼의 권한을 부여해야 한다는 의미입니다.

JSON Document로 구성한 S3 Policies

Policies는 Console에서 GUI를 통하여 부여할 수도 있지만 위와 같이 JSON으로 구성을 할 수도 있습니다. (방법의 차이일 뿐 결과는 같습니다) 각 요소의 설명은 아래와 같습니다.

Version : Policy의 언어 버전을 의미합니다.
Id : Policies를 구별하기 위한 식별자입니다.
Statement : Policy는 하나 혹은 여러개의 Statement을 가집니다.
- Sid : Statement를 구별하기 위한 식별자입니다.
- Effect : 특정 API에 접근 허용 여부를 결정합니다. (Allow or Deny)
- Principle : Policy을 적용할 사용자/계정/역할을 의미합니다.
- Action : Policy가 허용하거나 거부하는 API 리스트를 의미합니다.
- Resource : Action에서 사용 할 리소스 리스트를 의미합니다.

Roles

AWS service에 Role을 부여할 수 있습니다

EC2, S3, ECS 등등 수 많은 AWS services가 존재합니다. 이러한 service들은 사용자를 대신하여 자신이 맡은 역할을 수행합니다. 이를 위해서 AWS의 정보에 접근 할 필요가 있습니다. 따라서 우리는 AWS services에 권한을 할당해야 합니다.

그 권한을 부여하는 방식이 바로 Roles을 부여하는 것입니다. 위 그림처럼 EC2에 Roles을 부여하여 작업을 위한 권한을 지정해 줄 수 있습니다. 그렇게 되면 둘은 마치 하나의 객체가 되어 AWS 자원에 접근이 가능하게 됩니다.

AWS는 Infrastrucrue 혹은 각종 구성과 Compliance validation과 같은 역할을 맡습니다. 반대로 IAM 각종 권한과 역할을 관리하는 것은 사용자입니다. 즉, 인프라를 제공하는것은 AWS이지만 이를 책임지고 이용하는 것은 사용자의 몫입니다.

IAM 에 대한 학습이 끝나고 이해한 내용을 작성한 글 입니다. 복잡한 AWS의 시작 관문과도 같은 부분이 바로 IAM이라고 생각합니다. 각종 권한 부여는 곧 보안과 관련된 부분이므로 잘 학습 한뒤 실무에 적용 할 필요가 있다는 생각이 들었습니다.

+ IAM Guidelines

AWS account setup을 제외한 경우 root 계정을 사용하지 말 것
One Physical user는 One AWS user로 대응 할 것
유저를 그룹에 할당하고 그룹에 권한을 부여 할 것
강한 비밀번호와 MFA를 통해 보안성을 높일 것
AWS services에 Roles을 부여할 것
Access Keys를 사용하여 CLI 사용할 것
권한 감시를 위해 보고서를 잘 이용 할 것(Credentials Report, Access Advisor)

[SideProject] 나의 학교를 위한 서비스 개발기록 / 문제 인식 및 기획 - (1/3)

모노산달로스 — Thu, 3 Oct 2024 23:01:29 +0900

SideProject - 기룡아 밥 먹자

개발자들은 왜 사이드 프로젝트에 뛰어들까요? 일반 팀 프로젝트와 다르게 자신이 원하는 서비스를 만들어 볼 수 있다는 점이 큽니다. 또한 자유롭게 새로운 기술을 적용해 보거나 경험하면서 실력을 키우기에도 좋습니다. 실제로 수익을 목적으로 하는 팀 프로젝트와 다르게 가볍게 접근할 수 있다는 점도 한 이유로서, 많은 개발자들이 사이드 프로젝트를 수행하고 있습니다.

(1/3) 문제 인식 및 프로젝트 기획

(2/3) 기술적인 이슈 해결

(3/3) 프로젝트 회고

1. 문제 인식

많은 대학생이 사용하는 에브리타임 앱

당시 앱 개발에서 서버 개발로 넘어가기 위해 고군분투 중인 상황이었습니다. 그러다 스프링으로 기본적인 REST API를 구현할 수 있을 때 즈음, 프로젝트를 진행하며 공부를 진행하고 싶었습니다. 큰 프로젝트에 본격적으로 투입되기 전 사이드 프로젝트를 통해 step-up 하려는 계획이었습니다.

사이드 프로젝트 주제로는 무엇이 적절할까요? 사실 사이드 프로젝트로 항상 만들고 싶었던 주제가 있었습니다. 그것은 바로 교내의 식당 정보를 한 곳에 취합하는 것입니다.

기존 시스템의 문제는 다음과 같았습니다. 첫 번째는 산재되어 있는 부정확한 정보입니다. 학생들이 주로 에브리타임 앱을 통해서 식당 정보를 확인하는 경우가 많았습니다. 하지만 게시판 검색을 통해서 원하는 정보를 찾기란 매우 번거로운 일입니다. 심지어 부정확한 정보가 있는 경우도 많았습니다.

두 번째는 식당에 대한 반응 확인 수단이 없습니다. 많은 식당이 존재하지만 어떠한 메뉴가 인기가 많은지, 어느 식당을 사람들이 많이 찾는지 확인하는 것은 매우 힘들었습니다.

학교 홈페이지에 일부 식당 정보가 존재하기는 했지만 완전하지 않았습니다. 또한 접근성이 떨어져 사용자들이 쉽게 사용하기 좋은 에브리타임 앱에 의존하게 되는 경향도 있었습니다.

2. 프로젝트 기획

이제 이 간단한 문제를 해결해봅시다

따라서 이 두 가지 문제점을 해결하는 웹앱을 개발하기로 결정했습니다. 한 곳에서 교내의 모든 식당 정보를 확인하고, 리뷰 시스템을 추가하여 메뉴에 대한 반응을 확인할 수 있도록 기획했습니다. 여기에 매주 바뀌는 기숙사 식단 정보를 추가하여 교내의 '식사'와 관련된 모든 정보를 한 곳에 모으고자 했습니다.

본래 아이템 결정을 위해서는 철저한 시장조사와 기획을 거쳐야 합니다. 하지만 사이드 프로젝트 특성상 복잡한 기획 없이 곧바로 작업에 착수하게 되었습니다.

최종적인 목적은 아래와 같았습니다.

1. 프로젝트를 통해 교내에 존재하는 작은 문제를 해결
2. 배포 및 실 서비스 경험
3. 서버 개발자로서 프로젝트 참여

학교 마스코트 기룡이

얼마 뒤 3인 팀이 꾸려졌습니다. 본인은 서버 개발자로 작업에 참여하고 간단한 React 작업을 돕기로 하였습니다. 그리고 프로젝트 이름 은은 우연히 '기룡아 밥 먹자'로 정해졌습니다. 학교 마스코트의 이름인 기룡이를 프로젝트 디자인에 사용하기로 결정했습니다.

3. 초기 작업 과정

이후 디자인을 좋아하는 프런트 개발자와 함께 UI/UX 작업을 시작했습니다. 특히 모바일 사용자가 많을 것으로 가설을 세웠기 때문에 반응형 디자인에 대해 고심하는 과정을 겪었습니다.

0123

개발 문화와 관련해서도 꼭 수행하고 싶었던 것이 있습니다. 바로 '코드 리뷰' 문화입니다. 코드 리뷰의 필요성을 느낀 경험은 두 가지가 존재했습니다.

하나는 스터디 프로젝트에서 팀원과 코드 리뷰를 진행했을 때 빠르게 성장했었던 경험이 있었습니다. 새로운 기술을 처음 사용해 보는 입장에서 큰 도움이 되었습니다.

둘째는 코드 리뷰 없이 머지되어 예기치 못한 에러를 마주한 경험이 있습니다. 서로가 맡은 파트는 명확히 인지하고 있지만, 유기적으로 연결되는 코드 혹은 다른 팀원의 코드를 건드리는 경우가 생길 수 있습니다. 이 경우 곧바로 머지하게 되면 뜻밖의 변화와 에러로 인해 팀원들이 당황하게 되는 경우가 존재했습니다.

이러한 이유 때문에 앞으로 프로젝트를 진행하면 꼭 서로의 코드를 리뷰하도록 하고 싶었습니다.

4. 기술적인 이슈

기숙사 홈페이지에서 확인 가능한 식단 정보

작은 프로젝트였지만 기술적으로 고민을 해보아야 하는 부분이 존재했습니다. 바로 매주 갱신되는 기숙사 식단 정보였습니다. 여기서 발생하는 두 가지 의문점을 해결해야 했습니다.

1. 어떻게 하면 식단 정보를 매 주 자동으로 스크랩할 수 있을까?
2. 스크랩을 한 정보를 데이터 베이스에 어떻게 자동으로 업로드할 수 있을까?

한 가지 아이디어는 RPA를 사용하는 것입니다. RPA란 특정 작업을 자동화하기 위해 사용하는 도구입니다. 이전에 특정 웹사이트에 접근하여 데이터를 엑셀 형태로 반환해 본 경험이 있어 이번에도 활용이 가능할 것이라고 생각했습니다. 심지어 Ui Path는 AWS와 연동이 가능했기 때문에 두 가지 문제를 동시에 해결해 볼 수 있을 것이라는 생각이 들었습니다.

사용자가 가장 많은 RPA 도구인 Ui Path

하지만 장기적으로 보았을 때 이는 해결법이 될 수 없었습니다. Ui Path 60일 무료 체험 기간이 끝나면 결국 비용을 지불해야 하기 때문입니다.

그렇게 고민하던 중 다음과 같은 시나리오를 세웠습니다. Python을 통해 직접 스크랩을 진행하자 그리고 CI/CD Pipeline을 구성하면 매주 자동으로 데이터를 갱신하도록 할 수 있지 않을까?

결론적으로 크롤링과 배포 그리고 CI/CD에 대한 지식이 부족했습니다. 처음에는 당황했지만 이내 좋은 기회라는 생각이 들었습니다. 이러한 문제를 해결하면서 새로운 지식을 습득해보고자 했습니다. 조금의 시간이 지나고, 마침내 아래와 같이 공부해야 하는 내용을 정리할 수 있었습니다.

1. Jenkins를 통한 CI/CD pipeline 구축
2. AWS를 통한 배포 과정
3. Python을 통한 크롤링
4. Scrap과 데이터 업데이트 자동화

(2/3) 기술적인 이슈 해결에서 계속됩니다.

[Database] Transaction(트랜잭션)이란?

모노산달로스 — Thu, 15 Aug 2024 12:32:09 +0900

Database/DBMS - Transaction

Databases are crucial for managing, securing, and scaling data efficiently

현대 사회의 모든 것은 데이터로 이루어져 있습니다. 많은 서비스가 데이터를 기반으로 동작합니다. 특히나 AI가 발전함에 따라 데이터의 중요성은 더욱 커져가고 있습니다. 즉, 데이터의 수가 크게 늘어남에 따라 이를 적절하게 관리하고 접근하는 기술은 이제 필수적입니다. 데이터베이스는 대량의 데이터를 체계적으로 저장, 관리, 검색하여 다수의 사용자가 동시에 접근하고 활용할 수 있도록 하는 시스템입니다. 앞으로 효과적으로 데이터를 관리하기 위해 이에 대한 깊은 이해가 필요합니다.

Transaction(트랜잭션)

트랜잭션은 거래라는 뜻의 명사입니다

데이터베이스의 데이터에 변화가 일어나는 경우, 모든 작업은 순차적으로 일어날 필요가 있습니다. 예를 들어 은행 거래를 생각해 봅시다. 한 사용자가 자신의 계좌에서 돈을 인출하려고 합니다. 그렇게 되면 다음과 같은 작업을 수행하게 됩니다.

1. 사용자의 잔금을 확인합니다.

2. 필요한 양의 금액을 제거합니다.

3. 이체받는 계좌의 금액을 갱신합니다.

즉, 순차적으로 데이터를 조작하기 시작합니다. 이러한 연속된 작업을 모아 트랜잭션이라고 합니다.

Transaction Flow

트랜잭션이 필요한 이유는 두 가지가 존재합니다.

서비스에서 시스템 오류는 피할 수 없습니다. 이러한 상황에서 트랜잭션은 안정적인 결과를 보장해 줍니다. 즉, 하나의 작업을 모두 수행하여 변화가 올바르게 반영되는 경우와 오류가 발생하여 변화를 적용하지 않는 경우만 존재하게 됩니다.

또한, 데이터베이스 서버에 동시적인 요청이 발생하는 경우, 같은 데이터를 동시에 변경하는 문제가 생길 수 있습니다. 트랜잭션이 이러한 충돌을 방지해줍니다.

DBMS에서의 Transaction(트랜잭션)

Transaction 작업의 예시

두 개의 세션이 존재하는 경우를 생각해 봅시다. 세션 1에서 두 개의 멤버 데이터를 추가합니다. 이후 데이터베이스를 조회하면 세션 1에서는 새롭게 추가한 멤버 데이터를 확인할 수 있습니다. 하지만 세션 2에서는 아직 멤버 데이터를 조회할 수 없습니다.

이러한 상황에서, 세션 1에서 Commit 명령어를 실행하면 실제로 변화가 적용됩니다. 세션 2는 이제야 변화를 확인할 수 있습니다. 만약 Rollback 명령어를 수행한다면 데이터는 기존의 상태로 돌아가게 됩니다. 즉, 변화가 적용되지 않고 세션 2는 기존의 데이터만 계속 조회하게 됩니다.

트랜잭션은 처음부터 끝까지 완전하게 실행되어야 합니다. 다시 말해, 연속된 작업이 절반만 실행되고 결과가 저장되는 경우는 없습니다. 트랜잭션이 실행 중이라면 데이터베이스의 상태가 일시적으로 불일치하게 됩니다. 트랜잭션을 끝내기 위해 Commit(변화를 적용한다) 혹은 Rollback(변화를 적용하지 않는다)을 수행하고 나서야 변화가 적용됩니다.

Transaction이 필요한 경우에 대한 예시

이제 계좌이체를 하는 상황을 다시 생각해 봅시다. memberA가 memberB에게 2000원을 송금하는 경우입니다. 트랜잭션에 따라 순차적으로 작업을 수행합니다.

1. memberA의 계좌에서 2000원을 빼냅니다.
2. memberB의 계좌에 2000원을 더합니다.

그런데 2번 작업(memberB의 계좌에 2000원을 더합니다)을 수행하던 중 오류가 발생했습니다. 그 결과 memberA는 계좌에서 2000원을 빼내어 8000원이 되었지만, memberB의 계좌는 여전히 10000원인 상태입니다. 만약 Transaction 개념이 없다면 이러한 변화가 그대로 적용되어 큰 문제가 발생하게 됩니다.

Transaction이 존재한다면 무엇이 달라질까요? 2번 작업에서 오류가 발생하는 경우, 변화를 되돌리는 Rollback 명령어를 수행하기만 하면 됩니다. 그렇게 되면 1번 작업에 의해 일어난 데이터의 변화를 적용하지 않게 됩니다. 따라서, 송금을 시도하기 전으로 데이터가 돌아가게 됩니다. 즉, 데이터의 안정성을 확보할 수 있게 되는 것입니다.

ref.

https://www.geeksforgeeks.org/transaction-in-dbms/

https://fauna.com/blog/database-transaction

[Internship] CKNET 씨케이넷 RPA 교육 인턴쉽 후기 (2/2)

모노산달로스 — Wed, 31 Jul 2024 13:17:03 +0900

Internship - CKNET

Are you doing an internship?

인턴쉽이란 사원으로서 업무를 시작하는 것이 아닌, 아직 실력이 부족한 인원을 대상으로 실무 경험을 쌓을 수 있도록 도와주는 제도입니다. 실력을 키우는 것뿐 아니라 사회적 네트워킹을 확장할 수 있고 개인의 직무 적합성을 평가할 수도 있습니다. 대학생이 할 수 있는 좋은 경험 중 하나라고 생각합니다.

이전 글 확인 CKNET 씨케이넷 RPA 교육 인턴쉽 후기 (1/2)

씨케이넷 인턴쉽

CKNET 회사 입구에 걸린 로고

7월 30일 마지막 교육이 시작되었습니다. 이전 주차가 끝나고 모두에게 최종 RPA 과제가 주어졌습니다. 오늘은 수행한 과제를 바탕으로 하는 최종 발표가 있는 날입니다. 마지막 날인 만큼 기대도 되고 발표가 있어 긴장도 되는 하루가 시작되었습니다.

최종 과제 발표회

글쓴이에게 주어진 과제는 RPA 툴을 이용하여 다음과 같은 요구사항을 만족하는 것입니다.

1. 네이버 데이터랩에서 무작위 검색 카테고리를 고릅니다. 그리고 해당 카테고리의 검색어 키워드를 1위부터 10위까지 가져옵니다.
2. 네이버 쇼핑에서 가져온 검색어 키워드를 검색합니다. 그리고 리뷰 좋은 순으로 정렬합니다.
3. 정렬된 아이템의 정보(이름, 가격, 별점, 구매 링크)를 가져옵니다. 그리고 엑셀 파일에 입력합니다.
4. 10개의 키워드가 10개의 시트에 저장된 엑셀 파일 하나가 결과물입니다. 해당 결과물이 미리 설정된 메일로 전송이 됩니다.

발표는 순조롭게 진행되었습니다. 먼저, 과제물을 실시간으로 구동시켜 자동화 프로세스 과정을 눈으로 확인했습니다. 다음으로는 코드를 보며 어떠한 방식으로 프로그램을 구성했는지 설명했습니다.

한 가지 재미있었던 점은, 각 인원들이 같은 과제더라도 다른 방식으로 수행했다는 점입니다. 반복되는 부분을 함수로 잘 정리한 인원도 있었고, 검색 시간을 줄이기 위해 아이템 ID를 사용한 인원도 있었습니다. 특히 인상적이었던 것은, 도구에서 제공하는 검색어 입력 기능을 사용하지 않고 URL을 통한 페이지 접근으로 아이템을 읽어 오는 방법이었습니다.

인턴쉽의 모든 교육은 워크트로닉스라는 툴을 통해서 진행되었습니다. 분명 RPA라는 분야는 매력적인 분야입니다. 하지만 도구에 익숙하지 않았다는 점 그리고 인터넷상에 정보가 활성화되어있지 않은 점에서 어려움을 겪었습니다. 자동화 도구는 훌륭한 아이디어지만 실 사용자 입장에서 약간의 개선이 필요하다는 생각을 하게 되었습니다.

그래서 도달한 결론은, 내가 직접 RPA 툴을 제작해 보면 어떨까? 였습니다. 일반 사용자였다면 생각에서 그치겠지만, 도구를 개발할 역량이 되는 컴퓨터 공학도라면 시도해 볼 만한 주제라고 판단을 했습니다. 내년에 상상기업(학생들이 모여서 가상의 기업을 만드는 프로젝트) 활동을 수행할 때, 해당 주제를 제시하여 수행해야겠습니다.

인턴쉽이 끝이 나고

이번 인턴쉽은 경기대학교 소프트웨어 중식 대학과 기업 씨케이넷이 협력하여 진행되었습니다. IT기업이지만, 주 업무는 RPA 도구를 사용하는 것이기 때문에, 기존의 프로그래밍 언어로 코딩하던 것과는 다른 경험이었다고 생각합니다. 학생들 또한 RPA 도구의 사용을 위해서 인턴쉽에 참여한 것은 아닐 것입니다. 그렇다면 이번 인턴쉽에서 무엇을 얻을 수 있었을까요?

먼저 새로운 아이디어를 알게 되었다는 것입니다. 대부분의 학생들이 RPA라는 툴에 대해서 그 존재조차도 모르고 있었습니다. 외국에서는 이미 큰 사업이지만, 국내 시장은 한참 커져가는 과도기로 여겨졌습니다. 만약 RPA 툴을 사용하는 것이 아닌 직접 제작하는 입장이라면, 이는 새로운 사업 분야로도 여겨질 수 있다고 생각이 들었습니다. 즉, 회사에서만 얻을 수 있는 아이디어를 발견했다는 점이 첫 번째입니다.

두 번째는 네트워킹입니다. 언제나 대외활동에 있어 네트워킹 활동은 빼놓을 수 없는 부분입니다. 특히나 이번 인턴쉽은 IT 업계에 30년 이상 몸담은 씨케이넷 대표님과 많은 대화를 나눌 수 있었습니다. 다시 말해, 현직자의 멘토링을 자연스럽게 받을 수 있었습니다. 특히나 개발 분야로서 상담뿐만 아니라 비즈니스 관점에서 학습에 대해서 고민해 볼 수 있었던 것이 인상적이었습니다.

어떤 활동이든 의미가 없는 활동은 없었습니다. 크고 작은 깨달음은 언제나 찾아옵니다. 우리는 모두 같은 시간을 가지고 살아갑니다. 하지만 모두 같은 인생을 사는 것은 아닙니다. 다시 말해 모두 같은 활동에 참여했지만, 서로 얻은 것은 모두가 다르다고 생각합니다.

세상은 항상 변화하고 예측 불허합니다. 어려운 세상에 잘 적응하기 위해서는, 언제나 남들의 이야기에 귀 기울이고 주어진 상황에서 최선을 다해야 합니다. 파도가 치면 닻을 내릴 수도, 바람이 불면 그것을 이용할 수도 있어야 합니다. 그렇게 꾸준히 노력한다면, 언제 어디에서든 좋은 결과물을 얻어낼 수 있을 것이라고 회고합니다.

2024. 07. 31

[Spring] SOLID 5원칙이란?

모노산달로스 — Tue, 30 Jul 2024 00:26:30 +0900

Spring - SOLID principles

Spring makes Java simple, modern, productive, reactive

스프링은 프레임워크로 현대 자바 기반 애플리케이션을 위한 종합 프로그래밍과 환경설정 모델을 제공합니다. 스프링의 중요한 요소는 앱 단계에서 인프라 지원입니다. 즉, 개발자가 앱 단계의 비즈니스 로직에 집중할 수 있도록 만들어줍니다. 결론적으로 스프링은 자바 프로그래밍을 빠르고 쉽고 안전하게 만들어줍니다. 이러한 이점 때문에 많은 사용자를 보유하는데, 특히 한국에서는 백엔드 개발자의 대부분이 스프링을 사용할 정도로 인기가 많습니다.

What is SOLID principles

https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/

SOLID 원칙들(SOLID principles)은 2000년 컴퓨터 과학자 Robert J.Martin에 의해 처음 소개되었습니다. 객체지향 클래스 디자인의 다섯 가지 원칙으로, 클래스 구조를 디자인하기 위한 관례와 규칙들을 나타냅니다. 이 원칙들은 개발자가 복잡한 문제들을 작은 조각으로 나누도록 돕습니다. 즉, 느슨하게 결합된 유지보수에 용이한 코드를 작성하도록 돕습니다.

스프링 또한 객체지향 언어인 자바의 프레임워크입니다. 따라서 스프링 프레임워크를 올바르게 사용하기 위해서는 SOLID 원칙을 잘 이해할 필요가 있습니다. 지금부터 5가지의 원칙들을 하나하나 살펴보겠습니다.

단일 책임 원칙(Single-Responsibility Principle)

https://blog.nonstopio.com/single-responsibility-principle-in-python-429dc93c7fd5

단일 책임 원칙, 줄여서 SRP는 다음과 같은 의미를 가집니다.

1. 클래스 혹은 메서드는 하나의 이유에 의해서 변화해야 합니다.
2. 하나의 클래스는 하나의 작업을 수행해야 합니다.

클래스 혹은 메서드의 로직을 디자인하는 경우, 한 곳에 모든 책임을 부여해서는 안됩니다. 이는 코드가 작은 변화에도 큰 영향을 받게 만듭니다. 즉, 복잡한 코드가 만들어지고 유지보수가 힘들어집니다.

public class Invoice
{
            public void AddInvoice()
            { 
                // your logic
            }

            public void DeleteInvoice()
            { 
                // your logic
            }

            public void GenerateReport()
            { 
                // your logic
            }

            public void EmailReport()
            { 
                // your logic
            }
}

예를 들어 위와 같은 청구서를 관리하는 클래스가 존재합니다. 이러한 클래스는 단일 책임 원칙이 잘 지켜졌을까요? 메서드들을 살펴보면 각각 하나의 작업을 수행하는 것을 알 수 있습니다. 예를 들어 AddInvoice() 메서드는 오직 청구서를 추가하는 역할을 수행합니다.

하지만 Invoice클래스의 경우 이야기가 조금 다릅니다. 청구서에 관련된 메서드뿐 아니라 보고서를 생성하고 전송하는 역할까지 모두 수행하고 있습니다. 즉, SRP를 따르기 위해서는 Invoice클래스의 일부 메서드를 다른 클래스로 옮겨야 합니다.

public class Invoice
{
            public void AddInvoice()
            {
                // your logic
            }

            public void DeleteInvoice()
            {
                // your logic
            }
}

public class Report
{
            public void GenerateReport()
            {
                // your logic
            }
}

public class Email
{
            public void EmailReport()
            {
                // your logic
            }
}

위와 같이 Report 클래스와 Email 클래스를 생성하여 Invoice 클래스의 역할을 나누어주었습니다. 이제 SRP 원칙을 잘 지키는 코드가 완성되었습니다.

개방 폐쇄 원칙(Open-Closed Principle)

개방 폐쇄 원칙, 줄여서 OCP는 다음과 같은 의미를 가집니다.

1. 소프트웨어의 독립체들(클래스, 모듈, 함수 등)은 확장에는 열려있고 수정에는 닫혀있어야 합니다.

개방 폐쇠 원칙을 지키면 여러 가지 이점을 얻습니다. 새로운 기능을 추가하는 경우 예를 들어봅시다. 우리는 처음부터 기능 개발을 할 필요가 없습니다. 확장에는 열려있기 때문에, 이전 코드를 재활용할 수 있습니다. 거기에 변화에는 닫혀있어, 기존 코드를 수정할 필요가 없습니다. 이는 결국 코드의 유지보수성을 증가시키고, 필요 없는 버그의 발생을 피하도록 돕습니다.

class Footballer {
  constructor(name, age, role) {
    this.name = name;
    this.age = age;
    this.role = role;
  }

  getFootballerRole() {
    switch (this.role) {
      case 'goalkeeper':
        console.log(`The footballer, ${this.name} is a goalkeeper`);
        break;
      case 'defender':
        console.log(`The footballer, ${this.name} is a defender`);
        break;
      case 'midfielder':
        console.log(`The footballer, ${this.name} is a midfielder`);
        break;
      case 'forward':
        console.log(`The footballer, ${this.name} plays in the forward line`);
        break;
      default:
        throw new Error(`Unsupported animal type: ${this.type}`);
    }
  }
}

const kante = new Footballer('Ngolo Kante', 31, 'midfielder');
const hazard = new Footballer('Eden Hazard', 32, 'forward');

kante.getFootballerRole(); // The footballer, Ngolo Kante is a midfielder
hazard.getFootballerRole(); // The footballer, Eden Hazard plays in the forward line

위와 같이 4가지 역할을 부여할 수 있는 Footballer클래스가 존재합니다. 만약, 위 코드에서 새로운 포지션인 'winger'를 추가하여 5가지 역할을 부여하도록 만든다면 어떨까요? 우리는 switch 구문을 수정해야 합니다. 이는 새로운 기능을 추가하기 위해 기존 코드를 수정하는 것이 됩니다. 즉, 개방 폐쇄 원칙을 위반한 것입니다.

이를 해결하기 위해서 각 역할을 클래스로 분리해야 합니다. 이를 위해 역할을 가져오는 상위 클래스를 만들고 각각의 역할이 이를 상속받도록 만들었습니다.

class Footballer {
  constructor(name, age, role) {
    this.name = name;
    this.age = age;
    this.role = role;
  }

  getRole() {
    return this.role.getRole();
  }
}

// PlayerRole class uses the getRole method
class PlayerRole {
  getRole() {}
}

// Sub classes for different roles extend the PlayerRole class
class GoalkeeperRole extends PlayerRole {
  getRole() {
    return 'goalkeeper';
  }
}

class DefenderRole extends PlayerRole {
  getRole() {
    return 'defender';
  }
}

class MidfieldRole extends PlayerRole {
  getRole() {
    return 'midfielder';
  }
}

class ForwardRole extends PlayerRole {
  getRole() {
    return 'forward';
  }
}

// Putting all of them together
const hazard = new Footballer('Hazard', 32, new ForwardRole());
console.log(`${hazard.name} plays in the ${hazard.getRole()} line`); // Hazard plays in the forward line

const kante = new Footballer('Ngolo Kante', 31, new MidfieldRole());
console.log(`${kante.name} is the best ${kante.getRole()} in the world!`); //Ngolo Kante is the best midfielder in the world!

그 결과 위와 같은 코드가 완성되었습니다. 이제 'winger'라는 새로운 역할을 추가하는 상황을 다시 생각해 봅시다. 우리는 기존 코드를 수정할 필요가 없습니다. 그저 PlayerRole을 상속받는 새로운 WingerRole 클래스를 만들기만 하면 됩니다. 이것이 바로 OCP를 잘 준수한 예시입니다.

리스코프 치환 원칙(Liskov-Substitution Principle)

https://www.linkedin.com/pulse/liskov-substitution-principle-lsp-jerson-arturo-castro-rincon

리스코프 치환 원칙, 줄여서 LSP는 다음과 같은 의미를 가집니다.

1. 상위 클래스의 오브젝트는 프로그램의 정확성에 영향을 주지 않으면서 하위 클래스의 오브젝트를 바꿀 수 있어야 합니다.
2. 하위 클래스는 상위 클래스의 모든 프로퍼티와 메서드에 접근할 수 있어야 합니다.

public class Green {
   public void getColor() {
      System.out.println("Green");
   }
}

public class Blue extends Green {
   public void getColor() {
      System.out.println("Blue");
   }
}

public class Main{
   public static void main(String[] args) {
      // violate LSP because color of green object is blue
      Green green = new Blue();
      green.getColor();   
      //output: Blue  
   }
}

상위 클래스 Green과 이를 상속받는 Blue클래스가 존재합니다. 하위 클래스인 Blue는 getColor() 메서드를 오버라이드 하고 있습니다. 이러한 상황에서 green 인스턴스가 Blue 클래스 객체를 받게 됩니다. 그렇게 되면 green.getColor()의 결과는 "Green"이 아닌 "Blue"가 출력되게 됩니다.

public interface IColor{
   public void getColor();
}

public class Green implements IColor {
   public void getColor() {
      System.out.println("Green");
   }
}

public class Blue implements IColor {
   public void getColor() {
      System.out.println("Blue");
   }
}

public class Main{
   public static void main(String[] args) {
      IColor color = new Blue();
      color.getColor();   
      //output: Blue
   }
}

이를 해결하기 위해서 IColor 인터페이스를 생성합니다. 기존의 Green과 Blue클래스는 해당 인터페이스를 구현합니다. 이렇게 되면 하위 클래스가 모두 getColor()의 기능을 가지게 됩니다. 그렇게 되면 IColor color를 오브젝트로 사용할 수 있습니다. 즉, 중요한 것은 하위 클래스는 인터페이스 규약을 지켜야 한다는 것입니다.

인터페이스 분리 원칙(Interface-Segregation Principle)

https://www.linkedin.com/pulse/interface-segregation-principle-isp-prithveesh-goel

인터페이스 분리 원칙, 줄여서 ISP는 다음과 같은 의미를 가집니다.

1. 클래스는 인터페이스에 의해 필요 없는 메서드를 만들지 않아야 합니다.

다시 말해, 하나의 인터페이스가 너무 거대하여, 과도하게 많은 기능이 존재하는 경우 문제가 된다는 뜻입니다.

public interface Payment { 
    void initiatePayments();
    Object status();
    List<Object> getPayments();
}

public class BankPayment implements Payment {

    @Override
    public void initiatePayments() {
       // ...
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }
}

예를 들어, 위와 같이 Payment 인터페이스와 이를 구현한 BankPayment 클래스가 존재합니다. 여기서 인터페이스에 기능을 추가하면 어떻게 될까요? 대출 기능을 위해 인터페이스에 메서드를 추가하고 새로운 클래스를 생성하겠습니다.

public interface Payment {
 
    // original methods
    ...
    void intiateLoanSettlement();
    void initiateRePayment();
}

public class LoanPayment implements Payment {

    @Override
    public void initiatePayments() {
        throw new UnsupportedOperationException("This is not a bank payment");
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }

    @Override
    public void intiateLoanSettlement() {
        // ...
    }

    @Override
    public void initiateRePayment() {
        // ...
    }
}

인터페이스에 두 메서드가 추가되고 새로운 LoanPayment 클래스를 만들었습니다. 여기서 문제가 발생합니다. 하나의 Payment라는 인터페이스를 사용하기 때문에 LoanPayment 클래스는 필요하지 않은 모든 메서드를 구현하게 되었습니다. 즉, initiatePayments()와 같은 메서드가 필요하지 않음에도 구현하게 되었습니다.

public class BankPayment implements Payment {

    @Override
    public void initiatePayments() {
        // ...
    }

    @Override
    public Object status() {
        // ...
    }

    @Override
    public List<Object> getPayments() {
        // ...
    }

    @Override
    public void intiateLoanSettlement() {
        throw new UnsupportedOperationException("This is not a loan payment");
    }

    @Override
    public void initiateRePayment() {
        throw new UnsupportedOperationException("This is not a loan payment");
    }
}

심지어 기존의 BankPayment 클래스도 문제가 발생합니다. BankPayment 클래스 또한 원하지 않게 새로 생긴 두 메서드를 구현하게 되었습니다. 즉, 하나의 인터페이스가 여러 가지 역할을 맡게 되어 문제가 발생한 것입니다. 이를 해결하기 위해 아래와 같이 인터페이스를 분리할 수 있습니다.

public interface Payment {
    Object status();
    List<Object> getPayments();
}

public interface Bank extends Payment {
    void initiatePayments();
}

public interface Loan extends Payment {
    void intiateLoanSettlement();
    void initiateRePayment();
}

이제 두 클래스는 각각 Bank 인터페이스와 Loan 인터페이스를 상속받습니다. 이렇게 되면 자신에게 필요한 메서드만 구현할 수 있습니다. 즉, ISP 원칙이 잘 적용되었다는 뜻입니다.

의존관계 역전 원칙(Dependency-Inversion Principle)

의존관계 역전 원칙, 줄여서 DIP는 다음과 같은 의미를 가집니다.

1. 높은 단계의 모듈 혹은 클래스는 낮은 단계의 모듈에 의존해서는 안 된다.
2. 추상은 구체에 의존되면 안된다. 구체가 추상을 의존해야 한다.

각 모듈들은 추상화된 인터페이스 혹은 클래스에 의존해야 합니다. 이는 다형성과도 관련이 있습니다.

예를 들어봅시다. 한 뮤지컬에 남자 주인공 배우와 로미오 역할 그리고 여자 주인공 배우와 줄리엣 역할이 존재한다고 생각해 봅시다. 여기서 배우는 구현체, 역할은 추상체입니다.

이때, 남자 주인공 배우가 여자 주인공의 역할이 아닌 배우에 의존한다면 어떨까요? 만약 여자 주인공 배우가 교체되는 경우, 남자 주인공 배우 또한 문제가 생기게 됩니다. 즉, 코드의 유연성이 매우 떨어지게 됩니다.

// High-level module
public class PaymentService
{
    private CreditCardProcessor _creditCardProcessor;

    public PaymentService()
    {
        _creditCardProcessor = new CreditCardProcessor();
    }

    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Perform payment processing using the CreditCardProcessor
        _creditCardProcessor.ProcessPayment(amount, creditCardNumber);
    }
}

// Low-level module
public class CreditCardProcessor
{
    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Implementation details of payment processing using a credit card processor
        Console.WriteLine($"Processing payment of {amount} using credit card {creditCardNumber}");
    }
}

// Usage
PaymentService paymentService = new PaymentService();
paymentService.ProcessPayment(100.0m, "1234 5678 9012 3456");

예를 들어, 위와 같이 하위 모듈인 CreditCardProcessor클래스가 존재하고, 이를 의존하는 상위 모듈 PaymentService클래스가 존재합니다. PaymentService는 생성자 내부에서 CreditCardProcessor의 인스턴스를 만듭니다 그리고 직접적으로 ProcessPayment() 메서드를 호출합니다. 즉, 상위 모듈이 특정 클래스 구현체에 의존하는 강한 결합(Tight coupling)이 생기게 됩니다.

// High-level module
public class PaymentService
{
    private IPaymentProcessor _paymentProcessor;

    public PaymentService(IPaymentProcessor paymentProcessor)
    {
        _paymentProcessor = paymentProcessor;
    }

    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Perform payment processing using the injected payment processor
        _paymentProcessor.ProcessPayment(amount, creditCardNumber);
    }
}

// Abstraction or interface for payment processing
public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount, string creditCardNumber);
}

// Low-level module implementing the IPaymentProcessor interface
public class CreditCardProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Implementation details of payment processing using a credit card processor
        Console.WriteLine($"Processing payment of {amount} using credit card {creditCardNumber}");
    }
}

// Usage
IPaymentProcessor paymentProcessor = new CreditCardProcessor();
PaymentService paymentService = new PaymentService(paymentProcessor);
paymentService.ProcessPayment(100.0m, "1234 5678 9012 3456");

IPaymentProcessor 인터페이스를 생성하여 PaymentService가 인터페이스에 의존하도록 만들어봅시다. 이제 구현체를 직접 의존하지 않습니다. 이는, DIP 원칙을 잘 준수 한 예시입니다. 이에 대한 효과로, 생성자에서 paymentProcessor를 통해 원하는 구현체를 주입받을 수 있습니다. 즉, 코드가 유연해졌다는 것을 의미합니다.

Ref.

SRP
https://www.geeksforgeeks.org/single-responsibility-in-solid-design-principle/
OCP
https://www.freecodecamp.org/news/open-closed-principle-solid-architecture-concept-explained/
LSP
https://tusharghosh09006.medium.com/liskov-substitution-principle-lsp-744eceb29e8
ISP
https://medium.com/@ramdhas/4-interface-segregation-principle-isp-solid-principle-39e477bae2e3
DIP
https://dev.to/tkarropoulos/the-power-of-dependency-inversion-principle-dip-in-software-development-4klk

Inflearn - 스프링 핵심 원리 기본편(김영한)

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

[Experience] 구름톤 유니브 3기 합격 및 오프라인 OT / Singularity or Stagnation?

모노산달로스 — Sun, 28 Jul 2024 18:37:08 +0900

Experience - 구름톤 유니브 3기

카카오와 구름이 함께 진행하는 구름톤 유니브 3기

구름톤 유니브란 여러 대학의 학생들이 모여 함께 활동하는 IT 연합 동아리입니다. 3기는 8월부터 활동이 시작되어 미르미라는 이름으로 각종 스터디, 행사, 멘토링에 참여할 수 있습니다. 11월에는 해커톤(단풍톤)을 진행하며 팀원들과 활동의 결실을 맺게 됩니다. 그 후, 가장 마지막 활동인 9UAP을 통해서 구름톤 유니브의 마침표를 찍게 됩니다.

구름톤 유니브에 지원하다

구름톤 유니브 경기대학교 참여자 모집

구름톤 유니브는 각 학교별로 인원을 뽑아 여러 행사에 참여하게 됩니다. 글쓴이도 경기대학교에서 3기 참가자를 뽑는 것을 확인하고 지원을 하게 되었습니다. 지원한 이유는 여러 가지가 있었지만, 가장 큰 이유는 두 가지였습니다.

하나는 IT 연합동아리에 참여할 좋은 기회라는 것입니다. 교내에도 훌륭한 인원들이 많지만, 더 넓은 곳에서 활동을 하며 다양한 인재를 만나는 것은 중요한 부분이라고 생각합니다.

다른 하나는 해커톤에 참여할 기회가 주어지는 것입니다. 해커톤이란 짧은 시간 안에 개발자, 디자이너, 기획자가 힘을 합쳐 서비스를 개발하는 것입니다. 3기에서 진행하는 단풍톤은 무박 2일로 진행되는데, 개발자로서 꼭 해보고 싶은 경험이라고 생각되었습니다.

구름톤 유니브 합격 메일

서류 심사 및 온라인 인터뷰를 거쳐 합격 메일을 받아볼 수 있었습니다. 심사 기준과 과정은 각 학교마다 상이하기 때문에 정확하지는 않지만, 글쓴이는 아래와 같이 서류를 작성하고 인터뷰를 진행했습니다.

본인소개(700자)
간단한 자기소개와 자신 있게 보여줄 수 있는 역량을 소개했습니다. 하나는 지금까지 사용해 온 기술인 Flutter였고 다른 하나는 커뮤니케이션 능력이었습니다. 추가로 해당 블로그에 대한 정보도 기술했습니다.

얻고 싶은 점(500자)
세 가지를 작성했는데, 소중한 개발 경험과 네트워크 확장 그리고 성공하고자 하는 마음가짐이었습니다.

애정 있게 참여한 프로젝트(700자)
첫 프로젝트이자 팀장으로 참여했던 경험을 기술했습니다. 지금 돌아보면 굉장히 미숙한 프로젝트였지만, 여러 고군분투했던 기억과 더불어 팀장으로서 느낀 많은 부분들이 도움이 되었다는 이야기를 했습니다.

온라인 인터뷰
기본적인 소개와 지원하게 된 계기, 얻고 싶었던 점에 대해 질문하며 인터뷰가 시작되었습니다. 다음으로는 서류에 적었던 내용에 대한 질문과 주 역량에 대한 기술적인 질문이 이어졌습니다.

오프라인 OT (2024. 07. 27)

판교 카카오테크 부트캠프

판교의 카카오테크 부트캠프에서 구름톤 유니브의 오프라인 OT가 진행되었습니다. 이번 3기는 역대 최대 규모로 48개의 대학에서 600명이 넘는 미르미가 동아리에 참여하게 되었습니다. 따라서 모든 인원을 수용하기 힘들었기에 80명의 인원이 티켓팅을 통하여 오프라인 OT에 참여하게 되었습니다.

카카오테크 부트캠프

경기 성남시 분당구 대왕판교로 660 유스페이스1 A동 405호 (삼평동 670)

place.map.kakao.com

OT의 첫 번째 세션은 구름톤 유니브 3기에 대한 소개였습니다. 작년에 미르미로 참가했던 변해빈(Dan)님께서 전체적인 진행을 도맡아 주셨습니다. 구름톤에 대한 소개와 더불어 앞으로의 진행 일정을 알려주셨습니다. 앞으로 교내 스터디와 더불어 다양한 활동(멘토링, 교내 해커톤) 등을 지원 할 예정이라고 합니다.

이후 두 번째 세션으로는 KDC/KDT에 대한 소개가 이어졌습니다. 구름톤 유니브의 수료 조건으로 구름에서 진행하는 KDC/KDT 강의에 참여해야 합니다.

구름톤 DEEP DIVE - kakao X goorm

몰입의 깊이가 실력의 높이가 되는 곳, 구름톤 딥다이브. 풀스택 개발자, 프론트엔드 개발자, 백엔드 개발자, 사이버 보안 전문가, 생성형 AI 응용 서비스 개발자, 클라우드 네이티브 엔지니어링,

deepdive.goorm.io

K-Digital Training은 고용노동부에서 지원하는 사업으로 국민내일배움카드를 발급받으면 국비지원을 통해 누구나 무료로 원하는 강의를 수강할 수 있습니다. 이에 따라, 각 기업에서 여러 부트캠프들이 쏟아져 나오고 있습니다. K-Digital Training을 통해 국비 지원을 받을 수 있는 기회는 한정되어 있으므로 참여하려는 부트캠프가 어떤지 잘 확인해 보고 지원해야 합니다.

다음으로는 구름 류성태 대표님께서 AI시대의 개발자에 대한 세션을 진행하셨습니다. 그 내용은 아래와 같았습니다.

먼저 IT의 역사와 특이점에 대해서 설명하셨습니다. 해당 업계에서는 주기적으로 세상을 놀라게 하는 큰 발전(구글 검색, 아이폰, ChatGPT 등)이 발생합니다. 이 주기가 시간이 갈수록 짧아지고 있다는 이야기였습니다. 특히나 AI의 발전이 대두되면서 여러 직업이 사라질 위기에 쳐하고 있습니다.

따라서, 지금과 같은 시대에 개발자는 어떤 스탠스를 취해야 하는가? 에 대하여 말씀을 해주셨습니다. 이제 단순한 코딩은 AI가 모든 인간을 뛰어넘는 성능을 보여줍니다. 따라서 AI가 따라오지 못한 문제해결능력에 집중해야 합니다. AI가 코드를 생산하지만, 그 코드를 요구하는 것(프롬프트)은 인간입니다. 즉, 아직 우리가 대체되지 않을 수 있는 분야는 창의성과 관련된 부분입니다.

강연 중, 가장 기억에 남았던 부분은 마지막에 언급하신 Singularity or Stagnation?라는 한 문장이었습니다. 이는 특이점을 선택할 것인가 혹은 정체를 선택할 것인가?라는 뜻입니다. 다시 말해, 우리의 미래는 예측할 수 없습니다. 하지만 가만히 있으면 아무런 변화도 일어나지 않습니다. 따라서 우리는 선택해야 합니다. 열심히 노력하여 특이점에 도달할 것인지, 아니면 지금 그대로 멈춰 침체될 것인지.

이는 마치, 구름톤 유니브와 같은 활동에도 포함된다고 해석했습니다. 변화를 두려워하지 않고 새로운 것을 받아들이는 것, 여러 가지 활동에 참여하면서 도전하는 것, 이들이 모여 결국은 특이점으로 도달하는 하나의 길이 될 수 있으리라 생각합니다.

마지막 세션으로 구름톤 유니브 2기에 참여하셨던 염경록님께서 이전 기수의 후기를 전해주셨습니다. 특히 해커톤과 같은 프로젝트 진행에 있어 중요한 부분에 대한 이야기가 기억에 남습니다. 자신은 기획 분야로 활동을 했지만 처음에는 개발, 디자인에 대한 지식이 없어서 굉장히 힘들었다는 이야기였습니다.

이는, 앞서 대표님의 언급과 유사했습니다. 하나만 잘해서는 안 되는 시대가 되었습니다. 개발자는 개발 능력이 가장 중요합니다. 하지만 이제는 디자인과 기획 그리고 분석 능력 또한 가지고 있어야 합니다. 즉, 하나의 주 기술과 다른 여러 역량을 갖춘 T-Shaped People을 목표해야 합니다.

세션이 끝나고 네트워킹 시간이 이어졌습니다. 즉석에서 랜덤으로 팀이 만들어졌고 여러 가지 게임이 진행되었습니다. 각 대학의 인원들과 처음 만나는 자리였기에 어색함이 있었지만 드로잉 퀴즈, 노래 맞추기 등등 시간이 지날수록 분위기가 풀어졌습니다.

게임이 모두 끝나고, 총점수가 가장 높은 팀에게는 상품이 주어졌습니다. 카카오 굿즈로 춘식이가 그려진 유리컵이었습니다. 아쉽게도 이번에는 1등을 하지 못했지만, 다음 기회가 있다면 높은 점수를 목표로 열심히 해야겠습니다.

모든 활동이 끝나고 추가적으로 술집으로 장소를 이동하여 Beer-Networking을 진행했습니다. 연합 동아리였기에, 각지의 학생들이 술집에 모이는 기회는 조금은 생소했습니다. 하지만 술이 하나 둘 들어가며 다들 부드러워지고, 자신의 이야기를 풀어놓았습니다. 사람 사는 이야기를 듣는 것은 언제나 즐거운 일입니다.

특히나 개발자들이 많은 자리였기 때문에 평소보다 조금 특이한 이야기를 많이 들을 수 있었습니다. 경험이 많았던 선배 개발자로부터 자신이 학습하는 내용, 이루었던 경험들을 배울 수 있었습니다. 미래에는 만났던 선배 개발자들처럼 후배 개발자들에게 귀감이 될 수 있는 사람이 되도록 노력해야겠습니다.

[Flutter] .env를 통해 API Key 안전하게 사용(AndroidManifest.xml에서의 사용 포함 / 환경변수 설정)

모노산달로스 — Mon, 22 Jul 2024 21:42:03 +0900

Flutter - API key 값 숨기기

Flutter is an open-source UI software development kit created by Google

개발을 진행하면서 소셜 로그인 혹은 지도와 같은 외부 API를 사용하고는 합니다. 이때 API Key값을 발급받아 사용하는데, Github와 같은 공간에 노출되지 않도록 보호해야 합니다. dotenv package를 사용해 Key값을 안전하게 보호하면서 사용하는 방법에 대해서 알아보겠습니다. 특히나 고생했던 AndroidManifest.xml 파일에서.env에 저장된 키 값을 가져오는 방법에 대한 설명이 담겨있으니 참고하시길 바랍니다.

API Key값을 보호해야 하는 이유

Security of API keys

API key는 보안에 매우 취약합니다. Client(API key를 발급받는 사람)이 주의하지 않으면 다른 누군가가 API key를 훔쳐 악용할 가능성이 있습니다. 일반적으로 협업 시 깃허브에 코드를 올리게 됩니다. 이때, Public Repository에 API key가 그대로 올라가게 되면 이러한 문제가 발생합니다.

해당 포스트에서는 이러한 API key를 안전하게 보호하고 사용하는 방법을 알아보겠습니다.

dotenv package import 하기

flutter_dotenv | Flutter package

Easily configure any flutter application with global variables using a `.env` file.

pub.dev

flutter pub add flutter_dotenv

terminal에 명령어를 입력하여 dotenv를 사용할 준비를 합니다.

.env 파일 생성하고 사용할 준비하기

원하는 경로에 생성합니다. 글쓴이는 assets/config 폴더 내부에 .env 파일을 생성했습니다.

pubspec.yaml file

pubspec.yaml 파일에도 위와 같이 .env를 사용할 수 있도록 설정합니다.

.gitignore file

마지막으로 .gitignore 파일에도 .env를 추가하여 깃허브에 올라가지 않도록 합니다. 이제 .env파일을 사용할 준비가 완료되었습니다.

.env file

원하는 API key를 .env파일 내부에 작성합니다.

.env에 저장된 키 값 가져와서 사용하기

앞서 .env에 변수를 만들어 키 값을 저장했습니다. 이제 해당 키 값을 가져와서 사용해 보겠습니다. 먼저 main.dart와 같은 일반적인 lib폴더 내부 파일에서 사용하는 방법을 설명하겠습니다. 우선 키 값에 접근하기 위해서 .env파일을 불러옵니다. dotenv.load() 메서드를 통해서 불러올 수 있습니다.

import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: 'assets/config/.env');
  runApp(const MyApp());
}

비동기적으로 실행되어야 하기 때문에, await를 사용합니다. fileName에 자신의 .env 파일의 경로를 입력합니다.

void main() async {
  await dotenv.load(fileName: 'assets/config/.env');
  String? kakaoNativeAppKey = dotenv.env['KAKAO_APP_KEY'];
  runApp(const MyApp());
}

다음으로 dotenv.env['VAR_NAME']; 를 통해서 원하는 키 값을 가져옵니다. 우리는 KAKAO_APP_KEY라는 이름으로 저장을 하였으니 위와 같이 입력합니다. 마지막으로 kakaoNativeAppKey 변수를 만들어 불러온 키 값을 대입합니다.

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await dotenv.load(fileName: 'assets/config/.env');
  String? kakaoNativeAppKey = dotenv.env['KAKAO_NATIVE_APP_KEY'];
  KakaoSdk.init(
    nativeAppKey: kakaoNativeAppKey,
  );
  runApp(const MyApp());
}

이제 원하는 곳에 해당 변수 통해서 키 값을 사용합니다. 이렇게 사용하면 해당 코드를 통해서 API key 값의 내용을 확인할 수가 없습니다. 즉, 깃허브에 코드가 공유되어도 키 값은 보호되는 것입니다.

추가적으로 WidgetsFlutterBinding.ensureInitialized(); 메서드를 추가합니다. 이는 Flutter 프레임워크가 잘 초기화되어 있는지 확인하는 역할을 합니다. 주로 비동기 작업을 수행하는 경우 선언해 줍니다.

코드 전문

main.dart

import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: 'assets/config/.env');
  WidgetsFlutterBinding.ensureInitialized();
  String? kakaoNativeAppKey = dotenv.env['KAKAO_NATIVE_APP_KEY'];
  KakaoSdk.init(
    nativeAppKey: kakaoNativeAppKey,
  );
  runApp(const MyApp());
}

AndroidManifest.xml으로 .env에 저장된 key값 가져오기

Android 환경 설정을 위해 AndroidManifest.xml 파일을 수정합니다

하지만 API key 값을 AndroidManifest.xml 파일에서 사용해야 한다면 어떻게 해야 할까요? 해당 부분에 대한 설명을 찾기가 너무 힘들어 직접 해결하고 공유합니다.

   <!-- 카카오 로그인 커스텀 URL 스킴 설정 -->
    <activity 
        android:name="com.kakao.sdk.flutter.AuthCodeCustomTabsActivity"
        android:exported="true">
        <intent-filter android:label="flutter_web_auth">
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />

            <!-- "kakao${YOUR_NATIVE_APP_KEY}://oauth" 형식의 앱 실행 스킴 설정 -->
            <!-- 카카오 로그인 Redirect URI -->
            <data android:scheme="kakao${YOUR_NATIVE_APP_KEY}" android:host="oauth"/>
        </intent-filter>
    </activity>

카카오 로그인을 사용하기 위해서는 위와 같은 코드를 android/app/src/main/AndroidManifest.xml 파일에 추가해야 합니다.

<data android:scheme="kakao${YOUR_NATIVE_APP_KEY}" android:host="oauth"/>

추가적으로 위 부분을 자신의 API Key로 바꾸어줍니다. 즉, "kakao${YOUR_NATIVE_APP_KEY}"를 "kakaoabcdefg1234567"로 바뀌어야 합니다. 하지만 이렇게 직접적으로 바꿔주게 되면 마찬가지로 API key가 노출되는 상황이 발생합니다. 따라서 .env파일에 저장된 키 값을 불러오는 방법을 사용하겠습니다.

AndroidManifest.xml 파일의 ${YOUR_NATIVE_APP_KEY} 부분은 Placeholder라고 합니다. 이는 문자열 내에서 동적으로 값을 받아오는 역할을 합니다. 다시 말해, Placeholder 부분은 앱이 실제로 빌드될 때 실제 값으로 바뀌게 됩니다.

// .env 파일 경로 설정
def dotenv = new Properties()

placeholder 값을 지정하기 위해서는 android/app/build.gradle 파일을 수정해야 합니다. 위와 같은 코드를 build.gradle 파일 내부 아무 위치에 추가합니다. Properties() 객체는 설정 값을 키-값 쌍으로 지정하는 역할을 합니다. 주로 설정 파일을 읽고 사용하는 경우에 사용합니다.

// .env 파일 경로 설정
def dotenv = new Properties()
def envFile = file("${rootProject.projectDir}/../assets/config/.env")

다음으로 .env 파일의 경로를 envFile 변수에 대입합니다. 여기서 ${rootProject.projectDir}는 Gradle 파일의 루트 디렉터리를 의미합니다. 즉, android 폴더를 의미하며 해당 위치에서 시작하여 .env파일 경로를 찾아갑니다.

// .env 파일 경로 설정
def dotenv = new Properties()
def envFile = file("${rootProject.projectDir}/../assets/config/.env")
if (envFile.exists()) {
    envFile.withInputStream { stream -> dotenv.load(stream) }
} else {
    throw new FileNotFoundException("Could not find .env file at: ${envFile.path}")
}

마지막으로 envFile을 잘 불러왔는지 검사를 진행합니다. 만약 잘 불러왔다면 envFile.withInputStream을 통하여 파일을 입력 스트림으로 엽니다. 그리고 파일의 내용을 dotenv에 load 합니다. 이제 dotenv 객체에 .env 파일의 내용이 키-값 쌍으로 존재하게 됩니다.

// manifestPlaceholders 추가 및 null 체크
def kakaoKey = dotenv['KAKAO_APP_KEY']
if (kakaoKey == null) {
    throw new GradleException("KAKAO_NATIVE_APP_KEY not found in .env file")
}
manifestPlaceholders = [YOUR_NATIVE_APP_KEY: kakaoKey]

이제 dotenv객체에 저장된 키 값을 Placeholder 값으로 사용하겠습니다. 위와 같은 코드를 defaultConfig{ } 내부에 작성합니다. dotenv['KAKAO_APP_KEY'] 을 통해서 .env에 저장했던 키 값을 가져옵니다. 그리고 잘 불러왔는지 null 체크를 진행합니다.

manifestPlaceholders는 Android 빌드 시스템에서 AndroidManifest.xml 파일의 Placeholder를 실제 값으로 치환하기 위해서 사용합니다. 즉, [YOUR_NATIVE_APP_KEY: kakaokey]는 ${YOUR_NATIVE_APP_KEY} Placeholder를 .env에서 가져온 kakaokey 값으로 치환하는 역할을 수행합니다.

<data android:scheme="kakaoabcdefg1234567" android:host="oauth"/>

이제 빌드를 하게 되면 AndroidManifest.xml 파일은 위와 같은 모습을 하게 됩니다. 물론 위와 같이 코드가 바뀌는 것은 아닙니다. 즉, 키 값을 확인할 수는 없습니다. 우리는 이제 API key 값을 잘 보호하면서 AndroidManifest.xml 파일에서 사용할 수 있게 되었습니다.

코드 전문

android/app/build.gradle

...

// .env 파일 경로 설정
def dotenv = new Properties()
def envFile = file("${rootProject.projectDir}/../assets/config/.env")
if (envFile.exists()) {
    envFile.withInputStream { stream -> dotenv.load(stream) }
} else {
    throw new FileNotFoundException("Could not find .env file at: ${envFile.path}")
}

...

defaultConfig {
		...

        // manifestPlaceholders 추가 및 null 체크
        def kakaoKey = dotenv['KAKAO_NATIVE_APP_KEY']
        if (kakaoKey == null) {
            throw new GradleException("KAKAO_NATIVE_APP_KEY not found in .env file")
        }
        manifestPlaceholders = [YOUR_NATIVE_APP_KEY: kakaoKey]
    }
   
...

android/app/src/main/AndroidManifest.xml

     <!-- 카카오 로그인 커스텀 URL 스킴 설정 -->
    <activity 
        android:name="com.kakao.sdk.flutter.AuthCodeCustomTabsActivity"
        android:exported="true">
        <intent-filter android:label="flutter_web_auth">
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />

            <!-- "kakao${YOUR_NATIVE_APP_KEY}://oauth" 형식의 앱 실행 스킴 설정 -->
            <!-- 카카오 로그인 Redirect URI -->
            <data android:scheme="kakao${YOUR_NATIVE_APP_KEY}" android:host="oauth"/>
        </intent-filter>
    </activity>

[Machine Learning] 다항식 선형 회귀(Multiple Linear Regression)

모노산달로스 — Thu, 18 Jul 2024 14:34:29 +0900

MachineLearning - 다항식 선형 회귀

컴퓨터 과학의 아버지 앨런 튜링

머신러닝은 데이터를 분석하고 패턴을 학습하여 자동으로 예측하거나 결정을 내리는 기술입니다. 다양한 산업에서 효율성을 극대화하고 혁신을 촉진하기 때문에 머신러닝은 현재 주목받는 기술입니다. 이러한 상황에서 미래 기술 발전의 핵심 역량을 갖추기 위해서 머신러닝의 공부는 필수적입니다.

다항식 선형 회귀 모델 (Polynomial Linear Regression Model)

다항식 선형 회귀 모델이란 다중 선형 회귀와 비슷한 면이 있습니다. 여러 개 변수의 영향을 받는 식의 형태를 가집니다. 하지만 같은 변수의 다른 거듭제곱으로 식이 표현된다는 것이 큰 특징입니다. 주로 질병의 확산이나 대출 이자와 같이 비 선형적으로 증가하는 데이터 셋을 분석하는 경우에 사용합니다.

즉, 쉽게 말해서 비선형적인 데이터를 분석하는 모델입니다. 그렇다면 왜 다항식 선형 회귀라고 불릴까요? 종속 변수 y와 독립 변수 x는 비선형 관계를 가집니다. 하지만 각 계수들은 선형 조합을 가지고 함수를 표현할 수 있습니다. 이때, 회귀 구축 시 목표는 계수의 값을 찾아서 x를 통해 y를 예측 가능하게 만드는 것입니다. 따라서, 다항식 선형 회귀는 이름 그대로 독립 변수의 다항식을 사용하지만, 회귀 계수들이 선형적으로 결합된다는 점에서 선형 회귀로 불리는 것입니다.

비선형적 데이터 예측(Non-Linear Data Prediction)

직군(Position)	단계(Level)	봉급(Salary)
비즈니스 분석가(Business Analyst)	1	45000
주니어 컨선턴트(Junior Consultant)	2	50000
시니어 컨설턴트(Senior Consultant)	3	60000
매니저(Manager)	4	80000
국가 매니저(Country Manager)	5	110000
지역 매니저(Region Manager)	6	150000
파트너(Partner)	7	200000
시니어 파트너(Senior Partner)	8	300000
최고경영진(C-level)	9	500000
최고경영자(CEO)	10	1000000

만약 당신이 A 회사의 HR에서 근무한다고 가정합시다. 이번에 B 회사에서 이적하는 직원 K와 봉급 논의를 하는 상황입니다. K는 160000$를 받기를 원한다고 합니다. 그 이유를 물어보니, 자신이 이전 회사에서 그렇게 받았다고 이야기합니다. 해당 직원의 이력서를 살펴보니, 그가 지역 매니저로 2년 정도 근무했다는 사실을 알 수 있었습니다.

이러한 상황에서 우리는 위와 같은 B 회사의 봉급 표를 가지고 있습니다. 그렇다면 그의 이야기가 진실인지 허풍인지 알 수 있을까요? 이를 위해서 우리는 다항식 선형 회귀 모델을 사용해 볼 수 있습니다.

선형 회귀 모델을 사용한 경우

먼저 단순 선형 회귀 모델을 사용한 경우입니다. 빨간 점으로 표시된 것이 봉급표의 값이고 파란 선은 단순 선형 회귀로 예측한 결과를 나타냅니다.

보다시피 예측 값과 실제 값의 차이가 매우 크게 나타나는 것을 확인할 수 있습니다. 즉, 해당 데이터에 단순 선형 회귀 모델은 적절하지 않다는 것을 눈으로 확인 가능합니다.

다항식 선형 회귀 모델을 사용한 경우 (degree = 2)

이번에는 차수가 2인 다항식 선형 회귀 모델을 사용한 결과입니다. 앞서 확인한 모델과 다르게 예측 값이 실제 값에 근접한다는 것을 확인할 수 있습니다. 예측선이 직선이 아닌 곡선으로 표현되기 때문에 비선형적 데이터를 분석하기에 적절합니다.

다항식 선형 회귀 모델을 사용한 경우 (degree = 4)

이번에는 차수가 4인 다항식 선형 회귀 모델을 사용한 결과입니다. 차수가 증가하니 더욱 정확한 결과 값을 보여주고 있습니다. 그렇다면 여기서 의문이 생깁니다. 어떠한 차수의 값이 적절한지 확인하는 방법이 있을까요?

방정식에서 올바른 차수(The right degree of the equation)

다항식 선형 회귀 모델에서 차수의 값이 증가하면 모델의 성능 또한 증가하게 됩니다. 하지만 그와 동시에 과대적합(Overfitting) 혹은 과소적합(Underfitting)의 위험성도 증가하게 됩니다. 차수를 찾는 방법은 두 가지가 존재합니다.

1. 전진 선택법 : 가장 적절한 모델이 정의될 때까지 차수를 증가시켜 나갑니다.
2. 후진 선택법 : 가장 적절한 모델이 정의될 때까지 차수를 감소시켜 나갑니다.

Ref.

Understanding Polynomial Regression!!!

Polynomial Regression is a special case of Linear Regression where we fit the polynomial equation on the data with a curvilinear…

medium.com

[Algorithm] 그리디 알고리즘(Greedy Algorithm), 분할 배낭 문제(Fractional Knapsack Problem)

모노산달로스 — Fri, 12 Jul 2024 20:13:36 +0900

Algorithm - 그리디 알고리즘

대수학의 아버지 알콰리즈미, 알고리즘은 그의 이름에서 유래되었다

알고리즘은 컴퓨터 과학의 핵심 요소이다. 검색 알고리즘 덕분에 데이터의 바다에서 원하는 것을 추출할 수 있다. 정렬 알고리즘은 난잡한 데이터들을 잘 정리하여 가공할 수 있도록 만들어준다. 그래프 알고리즘은 효율적인 연결 경로를 찾는데에 필수적이다. 알고리즘 지식은 프로그래밍과 시스템 설계에서 복잡한 문제를 해결하는데 필수적이다.

그리디 알고리즘(Greedy Algorithm)

What is greedy algorithm?

정의

그리디 알고리즘은 항상 명확하고 즉각적인 이익이 되는 것을 선택하는 알고리즘입니다. 매 순간에 가장 이익이 되는 것을 선택하는 최적화 문제에서 사용합니다. 빠르게 구현이 가능하고 간단하게 작동하는 장점이 있습니다. 다른 말로 탐욕 알고리즘이라고도 부릅니다.

그리디 알고리즘을 구현하는 단계는 매우 간단합니다.

1. 해결해야 하는 문제를 정의합니다.
2. 최적의 선택을 확인합니다. 현재 상태에서 어떤 선택이 최선인지 알아냅니다.
3. 최적의 선택을 수행합니다. 최적의 선택을 수행하고 현재 상태에 변화를 적용합니다.
4. 위 단계를 반복합니다.

한계

https://www.freecodecamp.org/news/greedy-algorithms/

그리디 알고리즘은 지역적으로 선택을 합니다. 즉, 요소의 전체를 보고 판단하지 않습니다. 이러한 특징 때문에 항상 최적의 해답을 찾을 수 없다는 단점이 존재합니다.

예를 들어 위 그림에서 그리디 알고리즘을 적용해서 최댓값이 되는 수의 합을 찾아봅시다. 매 순간 최고의 이익을 선택하면 6 -> 4 -> 14로 총 수의 합은 24가 됩니다.

하지만 이는 지역적인 선택입니다. 만약 모든 요소를 고려하여 선택한다면 6 -> 3 -> 20로 총 수의 합은 29가 됩니다. 즉 그리디 알고리즘을 사용하면 요소의 순서와 같은 환경에 따라 최적의 해답을 놓칠 수 있습니다.

분할 배낭 문제(Fractional Knapsack Problem)

Fracional Knapsack Problem

그리디 알고리즘을 적용할 수 있는 유명한 문제로 분할 배낭 문제가 존재합니다. 해당 문제에 대한 설명은 아래와 같습니다.

N개의 상자가 존재한다. 각 상자는 가치와 무게 수치를 가진다. 이 상자들을 W만큼의 공간의 가방에 넣어야 한다. 각 상자들은 분할이 가능하다.

위 문제를 풀기위해 가능한 모든 부분집합을 고려한다면 시간 복잡도 O(2^N)과 보조 공간 O(N)이 필요합니다. 이를 그리디 알고리즘으로 접근한다면 더욱 쉽게 풀어낼 수 있습니다.

그리디 알고리즘으로 접근

해당 문제에 그리디 알고리즘을 사용하는 방법은 다음과 같습니다.

1. 이익과 무게의 비율을 계산하여 비율이 높은 순서대로 상자들을 정렬시킵니다.
2. 순서대로 상자를 선택합니다.

{{100, 20}, {60,10}, {120, 30}}의 이익과 무게를 가지는 상자들이 존재합니다. 이를 W = 50 크기의 가방에 넣어야합니다. 최적의 해를 구해봅시다.

우선 각 상자의 비율을 계산해야합니다. 이익 / 무게로 비율을 계산한 뒤 정렬하면 {{60,10}, {100,20}, {120, 30}}의 순서로 나열됩니다. 이제 상자들을 순서대로 선택하겠습니다.

첫 번째 상자를 선택하면 profit : 0 -> 60, W : 50 -> 40이 됩니다.

두 번째 상자를 선택하면 profit : 60 -> 160, W : 40 -> 20이 됩니다.

세 번째 상자는 무게가 30이기 때문에 2/3으로 나누어줍니다. 그렇다면 {80, 20}의 상자로 분할됩니다. 따라서 최종적으로 profit = 240, W = 50이라는 해를 얻을 수 있습니다.

0-1 배낭 문제(0-1 Knapsack Problem)

만약 상자를 분할할 수 없다면 어떻게 될까요? 그러한 상황에서는 문제를 그리디 알고리즘으로 풀어낼 수 없게 됩니다. 이를 0-1 배낭 문제라고 하며 동적 계획법(Dynamic Programming)과 같은 최적화 문제 풀이법을 적용해야 합니다.

다음 포스트에서 동적 계획법과 함께 해당 문제를 다루도록 하겠습니다.

[Algorithm] 에라토스테네스의 체(Sieve Of Eratosthenes)

모노산달로스 — Thu, 11 Jul 2024 19:08:50 +0900

Algorithm - 에라토스테네스의 체

대수학의 아버지 알콰리즈미, 알고리즘은 그의 이름에서 유래되었다

알고리즘은 컴퓨터 과학의 핵심 요소이다. 검색 알고리즘 덕분에 데이터의 바다에서 원하는 것을 추출할 수 있다. 정렬 알고리즘은 난잡한 데이터들을 잘 정리하여 가공할 수 있도록 만들어준다. 그래프 알고리즘은 효율적인 연결 경로를 찾는데에 필수적이다. 알고리즘 지식은 프로그래밍과 시스템 설계에서 복잡한 문제를 해결하는데 필수적이다.

소수(Prime number)란 무엇인가?

What is prime number?

소수란 1과 자기 자신으로 밖에 나누어 떨어지지 않는 수를 의미합니다. 만약 1과 자기 자신이 아닌 수로 소수를 나눈다면 0이 아닌 나머지를 얻게 됩니다. 요소가 둘 보다 많은 수는 합성수(Composite number)라고 표현합니다.

생각나는 소수가 있으신가요? 2, 3, 5, 7, 11 ... 여기서 한가지 의문이 생깁니다. 그럼 1은 소수일까요 아닐까요? 결론을 이야기하자면 1은 소수가 아닙니다. 1은 요소가 자기 자신 하나밖에 없습니다. 따라서 소수도 아니고 합성수도 아닙니다.

에라토스테네스의 체

Sieve of Eratosthenes

고대 그리스 수학자 에라토스테네스는 소수를 찾는 빠른 방법을 찾아냈습니다. '체' 라는 것은 국수를 삶을 때 사용하는 그 체를 의미합니다. 즉, 에라토스테네스의 체라는 것은 수 많은 숫자들 중에서 소수를 걸러내는 방법을 의미합니다. 그 방법은 아래와 같이 매우 간단합니다.

a. 2부터 소수를 구하고자 하는 수를 모두 나열합니다.
b. 2는 소수이므로 빼냅니다.
c. 2를 제외한 2의 배수를 모두 제거합니다.
d. 남은 수 중에서 3은 소수이므로 빼냅니다.
e. 3을 제외한 3의 배수를 모두 제거합니다.
f. 남은 수 중에서 5는 소수이므로 빼냅니다.
g. 5를 제외한 5의 배수를 모두 제거합니다.
h. 남은 수 중에서 7은 소수이므로 빼냅니다.
i. 7을 제외한 7의 배수를 모두 제거합니다.
j. 이 과정을 반복합니다.

위 그림의 경우 11의 제곱이 120보다 크므로 7의 배수까지만 삭제합니다. 즉 120보다 작은 수 중에서 2, 3, 5, 7의 배수를 제거하고 남은 수는 모두 소수입니다.

파이썬으로 에라토스테네스의 체 구현하기

이제 알고리즘을 파이썬 코드를 통해서 실제로 구현해보겠습니다.

def seiveOfEratosthenes(n):
    seive = [True] * n
    m = int(n ** 0.5)
    for i in range(2, m + 1):
        if seive[i] == True:
            for j in range(i+i, n, i):
                seive[j] = False
    return [i for i in range(2, n) if seive[i] == True]

Boolean 리스트를 사용하여 소수를 판단합니다. 자세한 구현 방식은 아래와 같습니다.

1. 구하려는 수의 범위 n 을 입력 받습니다.
2. n의 크기를 가지는 리스트를 생성합니다. 이때, 모든 값을 True로 초기화합니다.
3. n의 제곱근을 계산하여 m에 대입합니다. 앞서 설명했듯이 최대 수 보다 작은 소수의 배수만 제거하면 계산이 완료되기 때문입니다.
4. 2부터 m + 1까지 순회합니다. 이때 소수를 발견하면(seive[i] == True) 배수를 삭제하기 시작합니다.
5. 자기 자신을 제외한 자신의 배수들의(i+i 부터 n까지 i의 배수로) 위치에 False를 대입합니다.
6. 다시 첫 번째 반복문으로 돌아가서 순회를 반복합니다.
7. True 값을 가지는 수의 인덱스를 출력합니다. 이는 곧 소수들을 의미합니다.

간단한 알고리즘인 만큼 이해도 구현도 쉽게 풀어낼 수 있습니다. 이 모든 과정을 이해했다면 베르트랑 공준(4948) 문제를 풀어보시길 바랍니다. 에라토스테네스의 체를 정복했다고 말할 수 있도록 자신이 잘 이해했는지 확인하는 시간을 가져봅시다.

[Machine Learning] 다중 선형 회귀(Multiple Linear Regression)

모노산달로스 — Thu, 11 Jul 2024 17:29:02 +0900

MachineLearning - 다중 선형 회귀

컴퓨터 과학의 아버지 앨런 튜링

머신러닝은 데이터를 분석하고 패턴을 학습하여 자동으로 예측하거나 결정을 내리는 기술입니다. 다양한 산업에서 효율성을 극대화하고 혁신을 촉진하기 때문에 머신러닝은 현재 주목받는 기술입니다. 이러한 상황에서 미래 기술 발전의 핵심 역량을 갖추기 위해서 머신러닝의 공부는 필수적입니다.

다중 선형 회귀 모델 (Multiple Linear Regression Model)

https://medium.com/analytics-vidhya/multiple-linear-regression-an-intuitive-approach-f874f7a6a7f9

우리는 앞서 단순 선형 회귀 모델에 대해서 살펴보았습니다. 하나의 독립 변수와 하나의 종속 변수 사이의 관계를 나타내는 모델이었습니다. 같은 회귀 모델이지만, 다중 선형 회귀 모델은 여러 개의 독립 변수에 영향을 받는다는 것이 차이점입니다.

따라서 단순 선형 회귀 모델과는 다른 학습 방법이 필요합니다. 변수가 많이 존재하기 때문에 그 양을 줄이는 작업이 필요합니다. 이에 대해서 두 가지 이유를 제시할 수 있습니다.

1. 쓸모없는 데이터를 학습시키면 쓸모없는 결과가 나타납니다.(Garbage In Garbage Out)
2. 변수의 수가 과도하면 모델 설명이 힘들어집니다.

학습에 필요하지 않은 데이터를 사용한다면 모델의 예측 품질 또한 낮아질 수 있습니다. 또한 많은 변수의 수를 가진다면 모델을 다른 이에게 설명하기가 힘들어집니다. 따라서 예측에 도움이 되는 변수만 남겨야합니다.

모델을 만드는 다섯 가지 방법 (5 Method to build model)

그렇다면 적절한 변수를 어떻게 판단해야 할까요? 이에 대한 해답으로 5가지의 방법을 제시합니다. 해당 파트에 들어가기 전에 P-value에 관한 포스트를 꼭 확인하시기 바랍니다.

1. 올인(All-in)

올인이란 모든 변수를 사용하는 방법입니다. 사전 지식으로 정확히 어떤 변수들인지 파악이 되는 경우 혹은 회사 규정상(Framework) 해당 변수들을 모두 사용해야 하는 경우 사용합니다.

변수들을 제거하지 않고 모두 사용하기 때문에 적절한 변수가 무엇인지 전혀 분별이 되지 않는 방법입니다. 따라서 기본적으로 추천되지 않는 방법입니다.

2. 후진 소거법(Backward Elimination)

https://www.linkedin.com/pulse/backward-elimination-powerful-feature-selection-method-ravi-singh

후진 소거법이란 모든 변수들을 가지고 시작하여 기준에 따라 순차적으로 변수를 제거하는 방법입니다. 자세한 진행 순서는 아래와 같습니다.

1. 모델 내 유의 수준(Significance Level)을 설정합니다.
2. 모델 전체에 가능한 예측 변수를 모두 사용합니다.
3. 가장 높은 P값을 가지는 변수를 찾습니다. 만약 P값이 유의 확률보다 크다면 4번으로 이동합니다. 그렇지 않다면 모든 단계를 종료합니다.(모델 완성)
4. 가장 높은 P값을 가지는 변수를 삭제합니다.
5. 해당 변수를 제외하고 모델을 생성합니다. (3단계로 돌아가 반복)

P값이 크다는 것은 해당 변수가 종속 변수에 미치는 영향이 통계적으로 유의미하지 않다는 것을 의미합니다. 즉, 학습에 도움이 되지 않는 변수를 삭제하는 과정임을 다시 한번 확인 가능합니다.

3. 전진 선택법(Forward Selection)

전진 선택법이란 후진 소거법과 반대로 순차적으로 변수를 선택하는 방법입니다. 자세한 진행 순서는 아래와 같습니다.

1. 모델 내 유의 수준(Significance Level)을 설정합니다.
2. 가능한 모든 단순 회귀 모델들을 넣습니다. P 값이 가장 낮은 변수를 가지는 모델을 찾습니다.
3. 선택한 변수를 유지하면서 다른 가능한 모델들을 모두 사용합니다. 그리고 예측 변수를 하나 더 기존 변수에 넣습니다.
4. 가능한 변수 두 개의 회귀들 중 우리가 추가한 새 변수가 가장 낮은 P 값을 가지는 경우를 확인합니다. P값이 유의 수준보다 낮다면 좋은 변수입니다. (3단계로 돌아간다. 즉, 세 번째 변수를 넣는다.)

처음에는 변수가 한 개인 단순 선형 회귀 모델들을 가능한 만큼 모두 만듭니다. 그리고 P값이 가장 낮은 변수를 가지는 모델을 선택합니다.

그다음에는 변수가 두 개인 가능한 회귀 모델들을 가능한 만큼 모두 만듭니다. 두 개의 변수들 중 하나는 처음에 선택한 변수가 됩니다. 변수가 두 개인 회귀들 중 추가된 변수의 P값이 가장 낮은 모델을 선택합니다.

그 다음에는 변수가 세 개인 회귀 모델들을 만들고... 또 P값이 가장 낮은 모델을 선택합니다. 그러다가 가장 낮은 P값이 우리의 유의 수준보다 높다면 그만둡니다.

이 과정은 한마디로 모델 확장이 가능한 조합들 중 선택해서 적절한 변수를 늘려나가는 것입니다. 앞서 설명했듯이 선택한 변수의 P값이 유의 수준보다 높다면 도움이 되지 않는 변수이므로 그만둡니다.

4. 왕복 소거법(Bidirectional Elimination)

왕복 소거법이란 앞서 설명한 후진 소거법과 전진 선택법을 모두 사용하는 방법입니다. 자세한 진행 순서는 아래와 같습니다.

1. 들어갈 유의 수준(Enter Significance Level)과 유지할 유의 수준(Stay Significance Level)을 설정합니다.
2. 전진 선택법의 다음 단계를 수행합니다. (P값이 SLENTER보다 작으면 변수를 추가합니다.)
3. 후진 소거법의 모든 단계를 수행합니다. (P값이 SLSTAY보다 크면 변수를 제거하고 2단계로 돌아갑니다.)
4. 변수를 선택하거나 삭제하지 못하는 상황이 생기면 그만둡니다.

위에서 설명한 후진 소거법, 전진 선택법, 왕복 소거법을 단계적 회귀 분석(Stepwise Regression)이라고 부르기도 합니다.

5. 가능한 모든 모델들(All-Possible-Models)

가장 세밀하고 어려운 방법입니다. 먼저 학습에 가장 적절한 기준을 선택합니다. 그리고 가능한 모든 회귀 모델을 만듭니다. 만약 변수가 n개라면 2^n - 1 개의 조합이 만들어집니다. 변수의 수가 10개라면 1023개의 모델 중에서 선택해야 한다는 의미입니다. 이 수많은 모델들 중에서 가장 적절한 모델을 선택하는 방식입니다.

[Statistics] P값(P-value)란 무엇인가? (유의 수준, 신뢰 구간, 귀무가설)

모노산달로스 — Wed, 10 Jul 2024 15:04:23 +0900

Statistics - P-value

현대 수리통계학의 창시자 칼 피어슨

"통계학은 과학의 문법이다" 칼 피어슨은 이런 말을 했습니다. 과학의 기본 도구로써 통계는 매우 유용하게 사용됩니다. 데이터의 중요성이 높아진 지금 통계학의 중요성은 더욱 커져가고 있습니다. 특히나 복잡한 데이터를 이해하고 해석하여 정확한 결론을 도출하는 능력을 갖추기 위해서 꼭 필요한 학문입니다.

동전 던지기

동전 던지기의 결과는 앞면 혹은 뒷면 두 가지가 존재합니다.

동전 던지기를 한다고 가정해 봅시다. 여기서 이해를 쉽게 하기 위하여 동전 던지기의 확률이 독립적이지 않다고 가정해 보겠습니다. 동전이 조작되어 있지 않다면, 결과로 나오는 앞면과 뒷면은 모두 0.5의 확률을 가집니다. 그렇다면 실제로 동전을 다섯 번 던진 결과를 아래에 표로 정리해 보겠습니다.

횟수	결과	확률
1	뒷면	0.5
2	뒷면	0.25
3	뒷면	0.12
4	뒷면	0.06
5	뒷면	0.03

위와 같은 결과가 나온다면 어떤 생각이 드시나요? 뒷면이 다섯 번 연속으로 나왔습니다. 한 번 혹은 두 번은 그럴 수 있다고 생각합니다. 하지만 일정 횟수를 넘어가면 우리는 동전이 조작되어 있는건 아닌지 의심하게 됩니다.

만약 우리가 의심을 하게 되는 확률을 0.05라고 가정합시다. 이러한 기준을 유의 수준(Significant Level)이라고 합니다. 네 번째 시도까지는 그 확률이 유의 수준보다 높으므로 신뢰 구간(Confidence Interval)에 존재한다고 표현합니다. 신뢰구간은 우리가 설정하기에 따라 달라집니다. 만약 의학이나 검증 분야와 같이 안전이 중요한 산업에서는 신뢰구간이 더욱 높아질 수 있습니다.

P값(P-value)

What is P-value?

그렇다면 P값은 대체 무엇을 의미할까요? 귀무가설(Null Hypothesis)이 참이라는 가정 하에, 데이터가 나올 확률을 의미합니다. 즉, 동전을 던졌을 때 해당 면이 나올 확률 그 자체를 의미합니다.

위 예시에서 다섯 번째 시도의 결과가 뒷면이 나올 확률, 다시 말해 P값은 0.03입니다. 이는 우리가 설정한 유의 수준보다 낮기 때문에 귀무가설을 부정할 수 있습니다. 그렇다면 귀무가설이란 대체 무엇일까요?

귀무가설(Null Hypothesis)

https://evaluationcomics.freshspectrum.com/comic/youre-the-null-hypothesis/

귀무가설이란 통계적 검정에서 '변화가 없거나 효과가 없다'는 기본 가정을 나타내는 가설입니다. 다시 말해 위 예시에서 '동전 던지기의 결과는 공평할 것이다'라는 게 바로 귀무가설입니다. 앞서 이야기한 귀무가설을 부정한다는 이야기가 바로 '동전 던지기의 결과는 공평하지 않다'라고 생각하는 것을 의미합니다.

P값이 유의 수준보다 낮으면, 귀무가설(동전 던지기의 결과는 공평하다)을 부정할 수 있다.

이제 위 문장을 이해할 수 있을 것입니다.

[Machine Learning] 단순 선형 회귀(Simple Linear Regression)

모노산달로스 — Tue, 9 Jul 2024 23:31:44 +0900

MachineLearning - 단순 선형 회귀

컴퓨터 과학의 아버지 앨런 튜링

머신러닝은 데이터를 분석하고 패턴을 학습하여 자동으로 예측하거나 결정을 내리는 기술입니다. 다양한 산업에서 효율성을 극대화하고 혁신을 촉진하기 때문에 머신러닝은 현재 주목받는 기술입니다. 이러한 상황에서 미래 기술 발전의 핵심 역량을 갖추기 위해서 머신러닝의 공부는 필수적입니다.

단순 선형 회귀 모델 (Simple Linear Regression Model)

What is regression model?

회귀 모델이란 무엇일까요? 하나 혹은 그 이상의 독립 변수와 하나의 종속 변수 사이의 관계를 표현하는 함수입니다. 해당 모델은 연속되는 실수를 예측하는 것이 목표입니다. 급여 혹은 온도나 연속되는 숫자값이 그 예시입니다.

단순 선형 회귀 모델은 하나의 독립 변수와 하나의 종속 변수 사이의 관계를 의미합니다. 고유한 식에서 도출되므로 데이터의 테스트 셋과 트레이닝 셋의 회귀선이 같다는 특징이 존재합니다.

선형 회귀 방정식 (Linear Regression Equation)

선형 회귀 방정식

왼쪽에는 종속 변수, 오른쪽에는 독립 변수가 존재합니다. y 절편인 b0는 상수라고 하며 b1은 기울기 계수입니다. 예시를 통해서 해당 식에 대해서 살펴보겠습니다.

비료 사용량에 따른 감자의 수확량을 예측하는 식을 세운다면, Potatoes[t] = b0 + b1 * Fertilizer[kg]이 됩니다. 만약 단순 선형 회귀 알고리즘을 실행하여 b0 = 8[t], b1 = 3[t/kg]이 나왔다고 가정하겠습니다. 그 결과 다음과 같은 산점도가 나타납니다.

https://www.youtube.com/watch?v=HYgHKxWs1b4

여기서 y 축은 감자 생상량 그리고 x축은 사용한 비료량을 의미합니다. 파란 점을 통해 각기 다른 수확량이 표시되고 있습니다. 위에서 구한 식은 이 점을 통과하며 그려지는 선을 나타냅니다. y 절편이 8[t]으로 표시되어 있고 비료량이 1kg 증가하면 감자 생산량이 3t 늘어나는 것을 확인할 수 있습니다.

최소 제곱법(Ordinary Least Squares)

https://www.researchgate.net/figure/Ordinary-least-squares-OLS-linear-regressions-between-climate-data-and-glaciological_fig3_325879777

각 점들은 실제 데이터의 값을 의미하고 선은 예측된 데이터의 값을 의미한다는 것을 알았습니다. 또한, 실제 데이터의 값과 예측값에는 차이가 존재합니다. 이러한 상황에서, 우리는 어떤 것이 가장 적절한 예측선일까요? 이를 최소 제곱법(Ordinary Least Squares)를 통해서 알아낼 수 있습니다. 간단히 말해서 가장 적합한 기울기를 정하는 방법입니다.

잔차를 구하는 방정식

실제 데이터의 값과 예측 데이터의 값 차이를 잔차(residual)이라고 합니다. 잔차의 값이 적다는 것은 예측의 오차가 적다는 것을 의미합니다. 따라서 우리는 잔차 제곱의 합이 가장 작은 식을 찾아야 합니다. 즉, 모든 데이터 포인트에서 잔차를 제곱한 뒤 더하여 총합을 구합니다. 이 값이 가장 작은 회귀선이 바로 가장 적합한 회귀선을 의미합니다.

[Machine Learning] 데이터 전처리 과정, 데이터 셋 분리하기, 특성 스케일링(Data Preprocessing)

모노산달로스 — Thu, 4 Jul 2024 14:28:11 +0900

MachineLearning - 데이터 전처리

컴퓨터 과학의 아버지 앨런 튜링

머신러닝은 데이터를 분석하고 패턴을 학습하여 자동으로 예측하거나 결정을 내리는 기술입니다. 다양한 산업에서 효율성을 극대화하고 혁신을 촉진하기 때문에 머신러닝은 현재 주목받는 기술입니다. 이러한 상황에서 미래 기술 발전의 핵심 역량을 갖추기 위해서 머신러닝의 공부는 필수적입니다.

데이터 전처리

데이터 전처리란? 머신러닝에 사용 할 데이터를 가공하고 필터링하고 인코딩하는 것입니다. 데이터 전처리는 누락된 데이터와 같은 데이터 문제를 제거하기 위해서 이루어집니다. 데이터 기반 알고리즘에서 데이터의 품질이 그 결과를 결정합니다. 즉, 데이터 전처리를 통해서 좋은 품질의 데이터를 만들어야만 좋은 학습 결과를 얻어낼 수 있다는 이야기입니다.

지금부터 데이터 전처리 과정에 대해서 차근차근 알아보겠습니다.

독립 변수와 종속 변수

Country	Age	Salary	Purchased
France	44	72000	No
Spain	27	48000	Yes
Germany	30	54000	No
Spain	38	61000	No
Germany	40		Yes

위와 같은 데이터가 있다고 가정하겠습니다. 여기서 독립 변수는 무엇이고 종속 변수는 무엇일까요?

독립 변수란 다른 변수에 의해 영향을 받지 않는 변수를 의미합니다. 예를 들어 나이는 독립 변수입니다. 두 사람이 같은 날에 태어나면, 어떻게 살았던 두 사람은 같은 나이를 가지게 됩니다. 위 표에서는 국가, 나이, 봉급이 독립 변수가 됩니다.

종속 변수란 다른 변수나 요소에 의존하는 변수입니다. 예를 들어 내일 시험이 있다고 가정하면, 시험의 결과는 그동안 공부한 시간의 양에 따라서 결정됩니다. 여기서 시험의 결과가 바로 종속 변수가 되고 공부한 시간은 독립 변수가 되는 것입니다. 위 표에서는 구매 여부가 종속 변수가 됩니다.

결측 데이터 처리하기

앞서 설명했듯이, 데이터의 품질은 학습의 품질을 결정합니다. 누락된 데이터는 그 품질을 떨어뜨리기 때문에 전처리 과정에서 처리해주어야 합니다. 예를 들어 위 표에서 마지막 행의 봉급이 적혀있지 않습니다. 이러한 결측 데이터를 처리하는 방법은 두 가지로 나누어집니다.

데이터의 규모가 커 결측 데이터를 무시해도 된다면, 관측치를 삭제해버릴 수 있습니다. 다른 방법으로는, 해당 열의 다른 모든 값의 평균 값으로 대체하는 방법이 존재합니다.

범주형 데이터 처리

범주형 데이터(Categorical data)란 클래스로 분류되는 데이터를 의미합니다. 즉, 위 표에서 문자열로 이루어진 국가 데이터는 범주형 데이터입니다. 학습을 수행할 때 이러한 데이터를 구분하지 못하기 때문에 반드시 수치형 데이터(Numerical data)로 변환을 시켜주어야 합니다. 이러한 과정을 인코딩(Encoding)이라고 합니다.

한 예시로 원 핫 인코딩(One-hot encoding)이 존재합니다. 0과 1을 통해서 각 범주를 구별하고 그 크기는 범주의 수에 맞게 만들어집니다. 위 표에서 France, Spain, Germany 세 개의 범주가 존재합니다. 따라서 이들을 원 핫 인코딩으로 수치형 데이터로 바꾸어주면, 100, 010, 001과 같은 결과로 바뀌게 됩니다.

데이터 셋 분리하기

데이터 전처리 단계에서 훈련 데이터와 테스트 데이터를 나누어줍니다. 훈련 데이터는 머신 러닝을 학습할 때 사용합니다. 훈련 데이터가 많을 수록 정확도가 올라갑니다. 테스트 데이터는 새 관측치에 대한 모델의 성능을 평가하기 위해 사용합니다. 새 관측치는 배포 후 관측하게 되는 데이터와 동일하게 취급됩니다.

특성 스케일링

특성 스케일링이란 모든 특성을 동일한 스케일로 변환하는 것입니다. 예를 들어서 나이의 값은 1 ~ 100 사이의 값을 가지지만 봉급은 그보다 큰 단위인 10000 이상의 값을 가지게 됩니다. 이러한 차이 때문에 나이 특성이 봉급 특성에 비해 너무 작게 평가되어 무시될 수 있습니다. 따라서 특성 스케일링을 통해 이러한 문제를 보완하는 것입니다.

특성 스케일링은 표준화(Standardization)과 정규화(Normalization) 두 종류로 나누어집니다.

표준화(Standardization)는 특성의 모든 값에서 평균을 뺀 후 분산의 제곱근인 표준편차로 나누어줍니다. 그렇게 되면 특성값이 -3에서 3 사이의 값으로 조정됩니다.

정규화(Normalization)는 특성의 모든 값에서 최솟값을 뺀 후 최댓값과 최솟값의 차로 나누어줍니다. 그렇게 되면 분모가 분자보다 항상 크기때문에 0과 1 사이의 값으로 조정됩니다.

데이터가 정규분포(Normal Distribution)를 따르는 경우 정규화를 사용하는 것이 유리하고, 대부분의 경우 표준화를 사용하는 것이 좋습니다.

[Internship] CKNET 씨케이넷 RPA 교육 인턴쉽 후기 (1/2)

모노산달로스 — Wed, 3 Jul 2024 16:23:58 +0900

Internship - CKNET

Are you doing an internship?

인턴쉽이란 사원으로서 업무를 시작하는 것이 아닌, 아직 실력이 부족한 인원을 대상으로 실무 경험을 쌓을 수 있도록 도와주는 제도입니다. 실력을 키우는 것뿐 아니라 사회적 네트워킹을 확장할 수 있고 개인의 직무 적합성을 평가할 수도 있습니다. 대학생이 할 수 있는 좋은 경험 중 하나라고 생각합니다.

시작하게 된 이유

새로운 경험은 언제나 즐거운 일입니다. 특히나 인턴쉽을 통해 학교를 벗어나 실무를 경험하는 것은 더욱 의미가 크다고 생각합니다. 이번에는 소프트웨어 중심대학 사업으로 인턴쉽 프로그램을 신청하여 회사를 방문하게 되었습니다. 인턴쉽 교육은 7월 한 달간 대면 교육과 비대면 교육을 번갈아가며 진행될 예정입니다.

CKNET 회사 입구에 걸린 로고

7월 2일 교육이 대면 교육이 시작되었습니다. 빗길을 헤치고 영등포구에 도착하니 CKNET 로고가 보였습니다. 씨케이넷은 RPA(Robotic Process Automation) 기술을 다루는 회사입니다. 다소 생소하지만 꽤 많은 분야에서 사용되고 있는 기술입니다.

회사를 소개하는 대표님

잠시 교육장에서 대기를 하고, 먼저 대표님께서 회사에 대한 소개를 진행하셨습니다. RPA의 등장 이유는 다음과 같습니다. 사람은 작업을 할 때 집중과 휴식이 존재하여 그 효율이 떨어집니다. 이를 해결하기 위해 아웃소싱을 하는 회사가 늘어났습니다. 여기서 더 나아가서 로봇이 완전히 작업을 대체하는 RPA 기술이 발달하게 된 것입니다.

삼성, 대한항공 등 큰 기업에서도 해당 기술을 통해서 자동화를 구현하고 있습니다. 최근에는 OCR과 chatbot을 결합한 형태로 발전하고 있다고 합니다. 다만, 실제 도입에 있어서는 경영진의 결정이 가장 중요하다고 합니다. 아무래도 사람의 업무가 대체되는 것이다 보니, 경영진과 일반 사원 사이의 마찰이 존재할 가능성이 있을 것 같습니다.

Worktronics를 사용하여 RPA 교육이 진행되는 모습

이후, 본격적인 교육이 시작되었습니다. 실습 형태로 진행되었습니다. RPA 툴을 직접 사용해 보며 기술을 익혀보는 시간을 가졌습니다. Worktronics란 국내 최초 웹 기반 클라우드 RPA개발 환경입니다. 아쉽게도 맥 환경에서는 작동하지 않기 때문에 윈도우 노트북을 꼭 소지해야 합니다.

첫 주차 교육이기 때문에, 아주 간단한 실습을 몇 가지 진행했습니다. 프로그램을 사용하기 위해서 사람이 할 일은 단 하나입니다. RPA 프로그램 실행 버튼을 누르기만 하면 됩니다. 그 이후에는 스스로 웹 브라우저를 열고 검색창에 검색을 하여 원하는 페이지로 이동합니다. 해당 페이지의 정보를 받아와서 스스로 엑셀을 연 뒤 표에 정리를 하고 원하는 디렉터리에 저장까지 가능했습니다.

자동화라는 기술을 처음 익혀 신기했습니다. 다만, 툴 자체가 전공자에게 친숙한 환경은 아니었습니다. 비전공자도 사용할 수 있도록 만들어진 도구이기 때문이라고 생각합니다. RPA 툴을 다루는 것 자체는 전공자가 해야 할 일은 아니라고 합니다. 다만, 이러한 기술이 있다는 것을 배우고 경험한다는 것에 의의가 있다고 생각합니다.

이번 인턴쉽 과정이 끝나면 공부하던 머신러닝과 파이썬을 통해 자동화 프로그램을 제작해보고 싶다는 생각을 했습니다.

RPA 도구를 사용하는 것이 아닌 도구를 제작하는 사람이 되는 것이 개발자로서 추구해야할 일이라고 생각합니다.

첫 주 사내 회식의 모습

약 4시간에 결친 교육이 끝나고 저녁 6시가 되었습니다. 인턴쉽 첫 주를 기념하여 모든 사원이 모여 피자와 맥주를 먹었습니다. 인턴쉽에서 얻어가는 것 중 하나는 네트워킹이라고 생각합니다. 인턴쉽은 단순히 기술만 배우는 것이 아닙니다. 사회가 무엇인지, 회사의 대표는 무슨 생각을 하는지, 업계 선배들은 어떤 길을 걸어왔는지, 다양한 정보가 대화 속에서 오갔습니다.

대학생이 되어 자신의 대학교 안에 갇히는 경우가 많습니다. 그렇게 되면 눈과 귀로 들어오는 정보가 한정되게 됩니다. 한정된 시간이니 만큼 다양한 경험을 하고자 노력해야 한다고 생각합니다. 자꾸만 밖으로, 다른 학교로, 넓은 사회로 나가면서 성장의 기회를 잡아야 할 것입니다.

가지고 싶었던 생맥주 기계

인턴쉽 첫 주차 교육은 그렇게 마무리되었습니다. 길지 않은 시간이지만 최대한 많은 것을 배우고자 노력해야겠습니다. 중요한 것은 결말을 맺는 것이라고 생각합니다. 마지막까지 잘 수행하여 7월의 끝을 장식할 수 있도록 해야겠습니다.

[Linear Algebra] 행렬 곱셈 (Matrix Multiplication)

모노산달로스 — Mon, 1 Jul 2024 15:09:12 +0900

선형대수학 - 행렬 곱셈

선형 대수학의 아버지 윌리엄 로월 해밀턴

인공지능 시대가 떠올랐습니다. 선형대수학은 데이터의 표현과 변환에 핵심적인 역할을 하여 AI 모델의 학습 및 예측 과정에서 효율적인 계산을 가능하게 합니다. 또한, 차원 축소와 같은 기법으로 고차원 데이터를 효과적으로 처리하고 시각화하므로 AI 개발을 위해 선형대수학 공부가 필수적입니다.

위와 같은 이유로 선형대수학을 공부하면서 정리한 내용을 담은 포스트입니다.

행렬 곱셈(Matrix Multiplication)이란?

우리는 이전에 하나의 행렬을 대상으로 실수를 곱한 적이 있습니다. 그렇다면 행렬이 여러개일 때 서로 연산이 가능할까요? 덧셈과 뺄샘은 물론 곱셈 연산 또한 가능합니다. 하지만 곱셈 연산은 같은 위치의 값을 단순히 더하고 빼는 것과는 조금 다른 과정을 거치게 됩니다.

차원 문제(Dimensions matter)

행렬 A와 행렬 B간의 곱셈 연산을 수행하는 경우에 그 순서는 매우 중요합니다. A · B의 연산 결과와 B · A의 연산 결과는 다릅니다. 다시 말해서, 교환 법칙(Commutative)가 성립하는 실수의 곱셈과 달리 행렬의 곱셈에서는 순서에 따라 값이 바뀔 수 있습니다.

1. 첫 번째 행렬의 열의 크기와 두 번째 행렬의 행의 크기가 같아야한다.

행렬간 곱셈을 수행하기위한 조건은 위와 같습니다. 예를 들어 3 x 2 크기의 행렬 A가 존재한다면, 곱셈 연산이 가능한 행렬 B는 2 x 1 혹은 2 x 2, 2 x 3 ... 과 같을 것 입니다. (위 표현식에서 첫 번째 수는 행의 크기 두 번째 수는 열의 크기를 의미합니다. 행렬 A의 열의 크기가 2 이므로 행렬 B의 행의 크기가 2가 되어야 합니다.)

조금 더 쉽게 위와 같이 표현이 가능합니다. 2 x 3의 크기를 가지는 행렬 A와 3 x 4의 크기를 가지는 행렬 B를 곱할 수 있습니다.

반대로 BA의 순서로 곱셈 연산을 시도하는 것은 불가능하다는 것을 알 수 있습니다.

곱셈의 결과는 첫 번째 행렬의 행의 크기와 두 번째 행렬의 열의 크기로 결정이 됩니다. 즉 AB 곱셈의 결과로 2 x 4 행렬이 되는 것을 알 수 있습니다.

행렬 곱셈 예시(Example of matrix multiplication)

이제 실제 행렬의 곱셈 과정을 알아보겠습니다. 2 x 2 크기의 행렬인 A와 B가 존재합니다. 여기서 행렬 A의 첫 번째 행은 R1, 두 번째 행은 R2로 표현하겠습니다. 그리고 행렬 B의 첫 번째 열은 C1, 두 번째 열은 C2로 표현하겠습니다.

위와 같이 표현된 행렬 A와 B은 아래와 같이 곱셈 연산이 가능합니다.

R1C1 : 행렬 A의 첫 번째 행과 행렬 B의 첫 번째 열이 곱해져 첫 번째 행의 첫 번째 열의 값이 됩니다.

R1C2 : 행렬 A의 첫 번째 행과 행렬 B의 두 번째 열이 곱해져 첫 번째 행의 두 번째 열의 값이 됩니다.

R2C1 : 행렬 A의 두 번째 행과 행렬 B의 첫 번째 열이 곱해져 두 번째 행의 첫 번째 열의 값이 됩니다.

R2C2 : 행렬 A의 두 번째 행과 행렬 B의 첫 번째 열이 곱해져 두 번째 행의 두 번째 열의 값이 됩니다.

R1은 2와 6의 값을 가집니다. C1은 -4와 1의 값을 가집니다. 따라서 둘을 곱할때는 2 x (-4) + 6 x (1) 과 같은 연산을 거치게 됩니다. 연산 결과는 -2이며 이는 AB 행렬의 첫 번째 행의 첫 번째 열의 값이 됩니다.

마찬가지로 R1과 C2는 2 x (-2) + 6 x (0)으로 연산이 가능합니다. 그 결과는 -4이며 AB 행렬의 첫 번째 행의 두 번째 열의 값이 됩니다.

R2과 C1는 3 x (-4) + -1 x (1)으로 연산이 가능합니다. 그 결과는 -13이며 AB 행렬의 첫 번째 행의 두 번째 열의 값이 됩니다.

R2과 C2는 3 x (-2) + -1 x (0)으로 연산이 가능합니다. 그 결과는 -6이며 AB 행렬의 첫 번째 행의 두 번째 열의 값이 됩니다.

행렬 곱셈의 결과는 위와 같습니다.

행렬 곱셈의 성질(Properties of matrix multiplication)

1. 행렬 곱셈은 교환 법칙(Commutative)이 성립하지 않는다.
2. 행렬 곱셈은 결합 법칙(Associative)가 성립한다.
3. 행렬 곱셈은 분배 법칙(Distributive)가 성립한다.

앞서 설명하였듯 AB와 BA의 결과 값은 다릅니다. 행렬 곱셈의 교환 법칙은 성립하지 않습니다.

행렬 곱셈은 결합 법칙이 성립합니다. 위 식과 같이, 괄호의 위치를 옮겨도 연산 결과는 동일합니다. 행렬의 순서를 바꾸지 않기 때문입니다.

행렬 곱셈은 분배 법칙이 성립합니다. 다른 값들 사이에 곱셈을 분배하는 것이 가능합니다.

[Linear Algebra] 가우스-조던 소거법 (Gauss-Jordan elimination)

모노산달로스 — Mon, 1 Jul 2024 00:47:08 +0900

선형대수학 - 가우스 조던 소거법

선형 대수학의 아버지 윌리엄 로월 해밀턴

인공지능 시대가 떠올랐습니다. 선형대수학은 데이터의 표현과 변환에 핵심적인 역할을 하여 AI 모델의 학습 및 예측 과정에서 효율적인 계산을 가능하게 합니다. 또한, 차원 축소와 같은 기법으로 고차원 데이터를 효과적으로 처리하고 시각화하므로 AI 개발을 위해 선형대수학 공부가 필수적입니다.

위와 같은 이유로 선형대수학을 공부하면서 정리한 내용을 담은 포스트입니다.

가우스 조던 소거법(Gauss-Jordan elimination)이란?

우리는 행렬을 기약 행 사다리꼴(Reduced row-echelon form)의 형태로 표현하는 것이 방정식 풀이에 도움을 준다는 것을 배웠습니다. 행렬의 행 연산을 통해서 이것을 수행하는데, 가우스 조던 소거법(Gauss-Jordan elimination)이란 그러한 변환을 단계별로 표현한 알고리즘입니다.

1. (선택사항) 행렬의 행에서 상수 배가 있는 경우 인수를 꺼내서 간단하게 만들어줍니다.
2. 만약 피벗이 0이라면 다른 행과 위치를 바꾸어줍니다.
3. 0이 아닌 피벗을 1로 만들어줍니다.
4. 피벗 열의 다른 수를 0으로 만들어줍니다.
5. 2번으로 돌아가서 반복합니다.

가우스 조던 소거법은 위와 같은 방법으로 수행이 가능합니다. 위의 5가지 단계를 잘 기억한다면 소거법을 문제없이 진행할 수 있습니다.

예시를 통해서 소거법이 실제로 어떻게 사용이 되는지 알아보겠습니다. 위와 같은 행렬을 기약 행 사다리꼴의 형태로 변환하겠습니다. 먼저 첫 번째 행에 대하여 소거법을 수행합니다.

가우스 조던 소거법의 첫 번째 단계, '행렬의 행에서 상수 배가 있는 경우 인수를 꺼내서 간단하게 만들어줍니다.'를 수행합니다. 따라서, 두 번째 행을 5로 나누어줍니다.

가우스 조던 소거법의 두 번째 단계, '만약 행의 피벗이 0이라면 다른 행과 위치를 바꾸어줍니다.'를 수행합니다. 이미 -1로 0이 아니므로 이 단계는 넘어갑니다.

가우스 조던 소거법의 세 번째 단계, '0이 아닌 피벗을 1로 만들어줍니다.'를 수행합니다. 첫 번째 행에 -1을 곱하여 피벗을 1로 만들어줍니다.

가우스 조던 소거법의 네 번째 단계, '피벗 열의 다른 수를 0으로 만들어줍니다.'를 수행합니다. 따라서, 첫 번째 행과 두 번째 행을 더합니다.

피벗 열의 세 번째 행인 2 또한 0으로 바꾸어주어야 합니다. 따라서 첫 번째 행에 -2를 곱한 뒤 세 번째 행과 더해줍니다.

이제 첫 번째 열은 1, 0, 0과 같은 형태가 되었습니다. 이제 두 번째 단계로 돌아가서 두 번째 행에 대해 앞서 수행한 연산을 반복합니다.

가우스 조던 소거법의 두 번째 단계, '만약 행의 피벗이 0이라면 다른 행과 위치를 바꾸어줍니다.'를 수행합니다. 이미 4로 0이 아니므로 이 단계는 넘어갑니다.

가우스 조던 소거법의 세 번째 단계, '0이 아닌 피벗을 1로 만들어줍니다.'를 수행합니다. 두 번째 행에 4를 나누어 피벗을 1로 만들어줍니다.

가우스 조던 소거법의 네 번째 단계, '피벗 열의 다른 수를 0으로 만들어줍니다.'를 수행합니다. 따라서, 두 번째 행에 -5를 곱한 뒤 첫 번째 행과 더해줍니다.

세 번째 행에 대해서도 연산을 수행합니다. 두 번째 행에 5를 곱한 뒤 세 번째 행과 더해줍니다.

이제 두 번째 열은 0, 1, 0 과 같은 형태가 되었습니다. 이제 두 번째 단계로 돌아가서 세 번째 행에 대해 앞서 수행한 연산을 반복합니다.

가우스 조던 소거법의 세 번째 단계, '0이 아닌 피벗을 1로 만들어줍니다.'를 수행합니다. 두 번째 행에 -1을 곱하여 피벗을 1로 만들어줍니다.

가우스 조던 소거법의 네 번째 단계, '피벗 열의 다른 수를 0으로 만들어줍니다.'를 수행합니다. 따라서, 세 번째 행과 첫 번째 행을 더합니다.

그 결과 행렬이 기약 행 사다리꼴 형태가 되었습니다. 방정식을 풀면 (x, y, z) = (-1, -4, -4)가 됩니다.

[Linear Algebra] 피벗 성분 및 행 사다리꼴(Pivot entries and row-enchelon forms)

모노산달로스 — Thu, 27 Jun 2024 19:00:01 +0900

선형대수학 - 피벗 성분 및 행 사다리꼴

선형 대수학의 아버지 윌리엄 로월 해밀턴

인공지능 시대가 떠올랐습니다. 선형대수학은 데이터의 표현과 변환에 핵심적인 역할을 하여 AI 모델의 학습 및 예측 과정에서 효율적인 계산을 가능하게 합니다. 또한, 차원 축소와 같은 기법으로 고차원 데이터를 효과적으로 처리하고 시각화하므로 AI 개발을 위해 선형대수학 공부가 필수적입니다.

위와 같은 이유로 선형대수학을 공부하면서 정리한 내용을 담은 포스트입니다.

피벗(Pivot)이란?

피벗이란 하나의 행(Row)에서 0이 아닌 가장 먼저 오는 성분을 의미합니다. 다른 말로 선행성분(leading entry)이라고 합니다. 피벗을 가지고 있는 열(Column)은 피벗 열(Pivot Column)이라고 합니다.

행렬의 예시

위와 같은 행렬이 존재한다면, 각 행에서 4와 2 그리고 -3이 피벗이 됩니다. 그리고 좌측의 세 열은 모두 피벗 열이 됩니다.

행 사다리꼴 행렬(Row-enchelon forms)

1. 모든 피벗은 1입니다.
2. 0만을 가지고 있는 행은 행렬의 가장 아래에 위치해야 합니다.
3. 피벗은 계단식으로 존재해야합니다. 왼쪽 위 코너에서 오른쪽 아래 코너로 순차적으로 놓여집니다.

행 사다리꼴 행렬은 위와 같은 조건을 가집니다. 지금부터 각 조건을 차례대로 알아보겠습니다.

행 사다리꼴 행렬의 예시

위 행렬은 행 사다리꼴 행렬입니다. 모든 피벗(각 행의 선행성분)이 1로 표현되고 있습니다. 또한 0만을 가지고있는 행이 행렬의 가장 아래에 위치합니다. 또 각 행의 1의 위치를 눈여겨 보면 피벗이 계단식으로 존재함을 알 수 있습니다.

그렇다면 위와 같은 행렬들이 존재했을 때, 어떤 것이 행 사다리꼴 행렬(REF)인지 확인해보겠습니다.

행렬 A는 모든 피벗이 1입니다. 또한 0으로 이루어진 행이 행렬의 가장 아래에 위치합니다. 또한 피벗이 계단식으로 존재함을 확인할 수 있습니다. 따라서 행렬 A는 행 사다리꼴 행렬입니다.

행렬 B는 세 번째 행의 피벗이 3으로 나타납니다. 따라서 모든 피벗이 1이 아니므로 행 사다리꼴 행렬이 아닙니다.

행렬 C는 모든 피벗이 1로 나타납니다. 하지만 피벗이 계단식으로 존재하지 않습니다. 두 행이 같은 열에 피벗을 가지고 있기 때문에 행 사다리꼴 행렬이 아닙니다.

행렬 D는 모든 피벗이 1로 나타납니다 하지만 두 번째에 행이 0으로만 이루어져 있음에도 행렬의 가장 아래에 위치하지 않습니다. 따라서 행 사다리꼴 행렬이 아닙니다.

기약 행 사다리꼴 행렬(Reduced Row-enchelon forms)

4. 피벗 열에서 유일하게 피벗이 0이 아닌 수입니다.

기존의 행 사다리꼴 행렬에서 위와 같은 조건이 추가되면 기약 행 사다리꼴 행렬이 됩니다.

기약 행 사다리꼴 행렬의 예시

위와 같이 피벗 열에서 유일하게 0이 아닌 수가 피벗인 경우 기약 행 사다리꼴 행렬이라고 표현합니다.

그럼 위 네 가지 행렬에서 기약 행 사다리꼴 행렬(RREF)을 찾아보겠습니다.

행렬 A는 3번째 열에서 -2와 1이 동시에 존재합니다. 따라서 기약 행 사다리꼴 행렬이 아닙니다.

행렬 B는 4번째 열에서 3과 1이 동시에 존재합니다. 따라서 기약 행 사다리꼴 행렬이 아닙니다.

행렬 C는 피벗 열에서 피벗을 제외한 수가 모두 0입니다. 따라서 행렬C는 기약 행 사다리꼴 행렬입니다.

행렬 D는 0으로 이루어진 열이 행렬의 가장 아래에 위치하지 않습니다. 따라서 기약 행 사다리꼴 행렬이 아닙니다.

[경기대학교] 컴퓨터공학부 3학년 기초캡스톤 프로젝트를 끝내며 (2/2)

모노산달로스 — Thu, 13 Jun 2024 22:08:01 +0900

기초 캡스톤 디자인 프로젝트

What is capstone design

캡스톤 디자인이란? 돌 산을 쌓을 때 가장 윗부분을 캡스톤이라고 합니다. 지금 까지 배운 내용들을 통해 모두가 힘을 모아서 마지막 윗부분을 만드는 것, 그것이 바로 캡스톤 디자인입니다.

경기대학교에서 컴퓨터공학부 3학년이라면 모두가 기초 캡스톤에 참여합니다. 실력이 좋은 사람, 자신이 없는 사람, 자신의 능력을 모르는 사람 등 모두가 팀을 이루어 결과물을 발표하고 경쟁합니다. 글쓴이 또한 2024년 3학년을 맞이하여 기초 캡스톤에 참여하게 되었습니다.

해당 포스트는 3월부터 6월까지 경기대학교에서 수행한 기초캡스톤 프로젝트 진행 과정을 필자 시점으로 정리한 내용입니다. 긴 글이 되어 두 개로 나누어 작성하게 되었습니다.

기초 캡스톤 프로젝트를 끝내며 (1/2)

후반 작업

본격적인 후반 작업이 이어졌습니다. 가장 먼저 백엔드에서 만든 미션 api를 사용하는 도중 미션 관리라는 행위가 필수적이라는 것을 알게 되었습니다. 지금까지 선생님이 미션을 제공하고 그것을 통해 아이들이 도장을 수집한다. 라는 개념만이 존재했지만 실제로 그 미션을 만들고 나서 그것을 확인하고, 미션을 종료하는 것을 생각하지 않았던 것입니다. 또한 이를 위해 세션 유지가 필요하다는 사실 또한 알게 되었습니다. 이처럼 개발 중에 계속해서 기능이 추가되는 경우도 있었습니다.

따라서 백엔드에게 주어진 임무는 아래와 같았습니다.

미션을 종료하는 기능 구현
세션을 유지하는 기능 구현
아이들에게 알림을 보내는 기능 구현

프론트 공부를 끝낸 둘에게도 임무를 주었습니다.

지도 스크린 구현
미션 관리 스크린 구현

그동안 글쓴이는 Bump 기능(하이파이브) 개발에 집중하도록 하였습니다.

Bump

범프란 이런 것을 의미합니다

처음에는 본명 그대로 bump라는 이름으로 부르며 개발했습니다. bump란 두 사용자가 스마트폰을 흔들어 서로가 가까이 있다고 인증하는 기술입니다. 이러한 기술을 통해 어린아이들이 서로 만났다는 것을 확인한 뒤, 도장을 지급하고 다른 아이들에게 알림을 전송하고자 했습니다.

문제는 bump api를 사용하고자 생각하고 시작했지만, 그러한 api가 존재하지 않았습니다. 조사 과정에서 알게 된 사실은 다음과 같습니다.

과거 bump라는 회사가 존재했지만 구글에게 인수된 후 사라졌다.
gps와 accelator를 통해 구현한 것으로 추정된다.

솔직히 조금은 막막했습니다. 0부터 시작하여 기술을 개발하는 것은 불가능하다고 생각했습니다. 그렇게 고심하던 중 Nfc를 이용해 보면 어떨까? 하는 생각이 떠올랐고 바로 실행에 옮겼습니다.

나름대로 전략을 세우고 구현해보고자 했지만... Nfc를 통한 peer-to-peer 형태의 통신은 개발할 수 없다는 것을 알게 되었습니다. (보안 문제로 추정) 절망에 빠진 상태로 이번에는 '두 device의 연결'이라는 키워드로 자료를 찾아보았습니다. 그러던 중 한 패키지를 발견하게 되었습니다.

마치 한줄기 빛을 발견한 것 같았습니다. NearbyConnection는 플러터 근거리 통신을 제공하는 패키지로 peer-to-peer 방식을 통한 연결을 제공하고 있었습니다.

Flutter NearbyConnection Package

해당 패키지와 shake detector를 적절히 사용하면 bump 기능을 구현할 수 있겠다고 생각이 들었습니다. UI를 개선하고 작동 초기화 부분을 조작하는 것을 통해서 작업을 이어갔습니다.

그러던 중 하나 문제점을 발견했습니다. 사용자가 기기를 흔드는 것을 테스트하기 위해 실제 Device를 이용하여 테스트를 진행하다 보니 로컬 서버에 접근이 안된다는 것이었습니다. 즉 실제 서버를 개설할 필요성을 인지하게 된 것입니다.

서버 구축

AWS EC2

AWS EC2(Amazon elastic compute cloud)는 아마존 클라우드에서 제공하는 가상 컴퓨팅 환경입니다. 이를 통해서 가상 서버를 구축하여 사용할 수 있습니다. 백엔드 팀원 중 한 명이 서버 담당을 맞게 되었습니다. 해당 팀원이 도맡아 AWS EC2를 통해서 가상서버를 구축했습니다.

이를 통해서 로컬 서버에서 벗어나게 되었습니다. 이제 테스팅을 위해 백엔드 작업물이 필요하지도 않고, Physical device에서도 통신이 잘 이루어지게 되었습니다.

추가적으로 테스팅을 위해 swagger 또한 도입되었습니다. 백엔드 api를 쉽게 확인하고 테스팅하는 기능입니다. 이제는 노션에 페이지를 만들어 reqeust와 response의 정보를 직접 손수 작성할 필요가 없어졌습니다.

기업 미팅

기초캡스톤 디자인을 진행하면서 각 팀은 전문가 자문을 받아야 합니다. 우리 팀은 앱 개발이라는 목표에 맞게 '모바일앱개발협동조합'이라는 회사에 자문을 받게 되었습니다. 자문 내용 중 가장 의미 있었던 것은 디자인 지원이었습니다.

앱 UI 디자인 지원은 아니었고, 전시회에서 사용할 포스터 디자인이었습니다.

디자이너분과 포스터 내용과 배치에 대한 대화를 주고받았습니다. 그 결과 꽤나 아름다운 포스터가 결과물로 나오게 되었습니다.

제작 과정에서 학교에서 진행한 특강 '이종필 교수의 presentation skill'을 들었습니다. 발표와 포스터 제작에 대한 방법을 배웠는데, 포스터 내용 배치와 발표 준비에 있어 길라잡이 역할을 해주었습니다.

속도를 올리자

마감 일이 다가올수록 하루 작업 량은 늘어나갔습니다. 이제는 모든 팀원이 학교에서 모여 합을 맞추어 작업을 진행했습니다. 특히나 마지막 3일은 새벽까지 밤을 새우면서 완성하고자 힘을 쏟았습니다.

How to push alert using firebase

알림 기능의 구현은 Firebase를 이용하게 되었습니다. 프론트에서 유저의 FCM toekn을 넘겨주면 백엔드가 Fireabase 서버와 통신하여 알림을 전송하는 방식이었습니다. 여러 가지 어려움이 있었지만 어떻게든 구현에 성공하며 핵심 기능인 하이파이브와 모이자 기능을 완성할 수 있었습니다.

가장 놓치고 있었던 부분은 세션 유지였습니다. 작업 후반부에 백엔드와 실제로 연결해 보니 세션 유지가 잘 작동하지 않았는데, 이는 플러터에서 cookie 사용이 기본적으로 불가능하다는 이유 때문이었습니다.

이를 위해 dio package와 dio cookie manager 그리고 cookie jar package를 사용해야 했습니다. 어떻게든 코드를 만들어 쿠키를 통한 세션 유지에 성공했습니다.

유저 로그인시 백에서 생성한 쿠리를 사용하기위해 저장

쿠키가 정확히 무엇인지, 플러터에서 어떻게 사용하는지에 대해 프로젝트가 끝난 이후에 다시 공부하고자 생각했습니다. 어찌 되었건 우선 유지에 성공했다는 것에 큰 희열을 느꼈습니다.

그리고 전시 하루 전, 다른 두 프론트 팀원에게 작업물을 건네받았습니다. 해당 작업물들을 합치고 UI를 개선하는 작업을 계속해서 이어나갔습니다. 다른 사람의 코드, 심지어 잘 정리되지 않은 코드를 보는 것은 상당히 힘든 작업이었습니다. 어떻게든 마무리를 해야 한다는 일념 하나만으로 정신을 놓지 않았습니다.

전시회 당일

그렇게 잠에 들지 못하고 전시회의 아침을 맞이했습니다... 어떻게든 힘을 내 회장에 도착하였고 바로 부스를 만들기 시작했습니다. 기초 캡스톤 발표는 오후였는데, 오전까지도 계속해서 버그를 수정해야만 했습니다. 도장의 지급과 표시 그리고 미션 완료 부분에서 작은 버그들이 아직 존재했었기 때문입니다.

이와 더불어 발표 준비도 계속 이어나갔습니다. 작품만큼이나 발표 또한 중요했기에 입으로는 계속 발표 내용을 중얼거렸습니다. 처음 계획은 핸드폰 거치대를 올려두고 시연을 할 생각이었습니다. 하지만 그렇게 되면 하이파이브 기능을 제대로 보여주기 힘들 것이라고 판단되었습니다. 따라서 두 팀원이 핸드폰을 들고 발표를 돕는 것으로 최종 결정 되었습니다.

전시회 당일 부스의 모습

전시회 당일 다른 여러 팀들도 구경했습니다. AI 기술을 선보이는 팀이 대다수였고 게임을 만든 한 팀과 키오스크를 사용한 팀이 인상적이었습니다.

심사는 2시부터 6명의 심사위원분들이 각자 부스를 돌며 진행했습니다. 심사위원 분들 앞에서 발표를 진행할수록 점점 발표가 유연해지는 것이 느껴졌습니다. 그렇게 마지막 발표를 진행하였는데, 조금 생각을 깨우는 개선점을 들을 수 있었습니다.

그것은 바로, 데이터의 이용이었습니다. 기본적으로 아이들의 행동을 트래킹 하는 앱이기 때문에 활동적인 아이, 비활동적인 아이로 나누어 데이터를 수집하기가 좋습니다. 이렇게 수집한 데이터를 통해서 어떤 장소에 아이들이 많이 몰리는지 통계를 낼 수도 있고, 사업자에게 이러한 통계를 제공하기도 유용하다는 피드백을 받았습니다.

지금까지 회의를 거치며 생각하지 못한, 한 단계 더 나아간 '사업성' 측면에서 앱 개발을 고심하게 되었습니다.

끝내며

만찬

드디어 3개월을 걸친 프로젝트가 끝이 났습니다. 처음으로 접하는 큰 프로젝트이자 지금까지의 공부의 성과를 본다는 생각에 들떠있었습니다. 이번 기초캡스톤을 통해서 배운 점도 많았고 아쉬운 점도 참 많았습니다.

배운 점은 프로그래밍, 개발협업, 리더십 세 가지로 나눌 수 있습니다.

첫 번째로 Flutter 개발 자체에 대한 지식이 많이 늘었습니다. 지금 까지 flutter를 공부한 어느 순간보다 많은 성장을 이뤘다고 생각합니다. http를 통해 통신, nearbyconnection 및 shake 기능 사용, 반응형으로 앱 만들기, 쿠키 사용하기 등등... flutter 개발 능력 측면에서 공부를 많이 하게 되었습니다. 이와 더불어 백엔드 지식이나 CS지식 또한 조금이나마 얻어낼 수 있었습니다.

두 번째로 협업에 관하여 많이 배웠습니다. 혼자 개발하는 것이 아니다 보니 깃과 더불어 잘 소통할 필요가 있었습니다. 깃을 사용하는 방법을 배우기는 했지만 이렇게 실제로 사용한 경험은 많이 없었습니다. 이번 기회에 브랜치를 사용하는 방법, 코드 리뷰, 풀 리퀘스트, 푸시, 패치, 풀 등등... 깃에 대한 많은 것들을 실제로 느낄 수 있었습니다.

세 번째로 리더로서 역할을 조금 더 배웠습니다. 어떠한 작업자가 다른 작업자를 기다리지 않도록 일정을 만들어야겠다고 생각했습니다. 또한 회의를 적절하게 진행하고 내용을 정리하여 다시 작업자들에게 상기시키는 것 또한 중요하다는 것을 알게 되었습니다. 리더로서의 역할, 팀을 잘 이끌고 팀원을 관리하는 것에 대하여 다시 한번 경험할 수 있어서 좋았습니다.

물론 아쉬운 점 또한 남았습니다.

첫 번째로 요구사항 명세서, 프로덕트 백로그 등 기초캡스톤 개발을 시작할 때는 몰랐던 것들이 아쉽습니다. 직접적인 개발을 시작하기 전 이러한 부분을 잘 정리했더라면 작업 후반부에 업무가 과중되는 문제가 조금 줄어들었을 것이라고 생각합니다.

두 번째로 깃의 사용법이 조금 아쉬웠습니다. 프론트와 백의 레포지토리를 따로 나누어 관리하는 것이 더 좋다는 것을 차후에 알게 되었습니다. 이번 프로젝트에서는 깃의 사용에 있어 브랜치도 엉망이고 머지 과정에서 충돌도 자주 발생했습니다. 다음에 깃을 사용한다면 더 잘 사용하고자 생각했습니다.

https://github.com/Capstone-Project-Basic/capstone

GitHub - Capstone-Project-Basic/capstone: Application help to increase sociability for children

Application help to increase sociability for children - Capstone-Project-Basic/capstone

github.com

결과물이 궁금하다면 깃허브 레포지토리를 참고해주세요.

결과는 은상을 받았습니다

처음으로 협업을 해보고 끝을 보았다는 것에서 큰 기쁨을 얻었습니다.

친구들과 처음 보는 사람들과 함께 프로젝트를 진행하는 것은 앞으로 해야 하는 일의 미리 보기와도 같습니다.

글쓴이도 리더 역할을 하면서 더욱 열심히 임하였고 팀원들도 잘 따라와 준 덕에 프로젝트가 잘 끝이 났다고 생각합니다.

특히 끝맺음이 있다는 것, 항상 장대하게 시작하더라도 후반부로 갈수록 지지부진 해지는 자신을 돌아보게 되었습니다.

이번에는 내 전공 프로젝트에 있어 끝을 보았다는 사실이 참 행복합니다.

진행기초 캡스톤 발표는 오후였는데, 오전까지도 계속해서 버그를 수정해야만 했습니다. 중인 프로젝트, 앞으로 해나갈 프로젝트도 꼭 열심히 임하여 좋은 결과를 맛보았으면 좋겠습니다.

이상으로 읽어주셔서 감사합니다. 기초캡스톤 후기를 마칩니다.

[경기대학교] 컴퓨터공학부 3학년 기초캡스톤 프로젝트를 끝내며 (1/2)

모노산달로스 — Thu, 13 Jun 2024 20:31:34 +0900

기초 캡스톤 디자인 프로젝트

What is capstone design

기초캡스톤 프로젝트를 끝내며(2/2)

팀 결성

총팀원은 8명으로 구성되었습니다. 처음에는 14명이 모였는데, 앱을 개발할 팀과 자율주행을 개발할 팀으로 나누어졌습니다. 그리고 글쓴이는 팀장이 되었습니다. 팀원으로 있으면 답답함을 느끼고는 했기에 기본적으로 팀장 역할을 마다하지 않았습니다. 이러한 본격적인 프로젝트는 처음이었지만 그동안 공부한 내용을 바탕으로 잘 이끌 수 있을 것이라 생각하였습니다.

개발자들은 디스코드를 많이 사용한다

가장 먼저 디스코드로 회의를 통해 앞으로의 계획과 팀원들의 전력을 파악했습니다. 다섯 명의 팀원은 이미 알고 있던 친구들로 모두 백앤드를 공부하고 있었습니다. 다른 두 팀원은 아직 아무것도 모르는 상태였습니다. 이미 백앤드 기술자가 많으므로 배움이 필요한 2명은 프론트를 맡아야 했습니다. 따라서 한 달의 시간을 주어 2명이 프론트 공부를 하도록 하였고 그전까지는 혼자 개발하게 되었습니다.

아이디어 회의

이후 무작정 모여 아이디어를 짜내기 시작했습니다. 약 2주에 걸쳐 회의가 진행되었고 결론은 '아이들의 사회성'을 증진시키는 앱을 만들게 되었습니다. 구체 화 한 아이디어는 다음과 같습니다.

선생님이 사회 활동에 관한 미션을 제시하고 도장을 보상으로 제공한다. 이를 통해 아이들이 사회활동 참여를 유도한다.

자료 정리를 위해 노션 페이지를 만들었습니다. 올해 초 동아리와 다른 프로젝트에서 노션을 접하게 되었는데 실제로 협업 과정에서 중요하게 사용된다는 것을 알게 되었습니다. 따라서 우리 팀도 노션을 사용해 아이디어를 정리하고 서로의 작업을 나누고자 했습니다. 특히나 학교 구글 계정이 있다면 노션 에듀케이션 플랜을 사용할 수 있다는 것이 유용했습니다.

다만, 노션을 프로젝트 후반까지 100% 사용하지 못했다는 점은 아쉽습니다. 요구사항 명세서와 프로덕트 백로그 등등 미리 정해야 하는 것들이 있다는 것을 나중에 알게 되었고, 당시에는 주어진 시간이 길지 않으므로 빨리 개발을 시작해야겠다는 생각에 휩싸였었습니다.

전반 작업

피그마를 통해 작업한 와이어 프레임

위와같이 피그마를 이용하여 각자 생각하는 UI를 만들었습니다. 당시에는 몰랐지만 현재는 이를 '와이어 프레임'과 같은 용어로 부른다는 것을 알게 되었습니다. 작업을 시작하기 전 어떻게 UI를 구성하고 기능을 집어넣을지 정하는 단계였습니다.

여러 가지 기능이 들어있었는데, 교수님과의 미팅 과정에서 '필요한 것을 추려내라'라는 평가를 받았습니다. 지금 다시 보면 난장판이지만 당시에는 쉽게 빼내지 못했었습니다.

다음으로 깃허브 레포지토리를 만들고 작업을 시작했습니다. 위와 같은 전략으로 브랜치를 나누어 사용하고자 했는데, 이 점 또한 아쉬움이 남는 부분입니다.

왜냐하면 개발 분야별로 각각의 레포지토리를 만드는 것이 조금 더 낫다는 것을 나중에 알게 되 었기 때문입니다. 실제로 하나의 레포지토리를 만들고 위와 같이 브랜치를 구성하니 작업물이 꼬여 조금 힘들었던 기억이 있습니다.

012

당시 만들어졌던 UI 클릭하면 커집니다.

구현의 시작은 굉장히 막막했습니다. 누군가가 api를 짜야한다는 이야기를 들었다고는 하지만 모두가 그것이 왜 필요한지, 어떻게 해야 하는지 조차도 모르는 상황이었습니다. 그래도 8명이 머리를 맞대고 어떻게든 바퀴를 굴리기 위해 노력했습니다.

프론트의 경우 혼자 위와 같이 UI를 만들었습니다. 디자이너가 없기 때문에 いらすとや의 무료 이미지를 사용했습니다. 아기자기한 이미지가 아동용 애플리케이션이라는 콘셉트와도 잘 맞아 유용했습니다. 방학 동안 공부한 Flutter의 성과를 보는 것과도 같아 기분이 좋았습니다.

백엔드는 로그인, 회원가입, 도장 기능, 미션 기능의 작업을 나누어 진행했습니다. 스프링과 h2를 통해서 진행했는데, 자세한 작업 과정을 모르기에 계속 재촉하게 되었습니다...(미안) 어찌 되었건 백엔드 팀원들이 각자 역할을 잘 수행하여 결과물을 내놓았습니다.

이러한 작업과 동시에 논문 또한 작성해야했습니다. 프론트에는 남는 손이 없었기에 백엔드에서 한 명이 논문을 도맡아 작성하게 되었습니다.

처음 손 잡는 프론트와 백

백엔드 작업(Spring boot)에 관한 지식이 없다보니 작업이 끝났는데, 그것을 사용하는 방법을 공부해야만 했습니다. 이렇게 프로젝트를 진행하면서 플러터에서 http를 통해 백과 통신을 처음 해보았습니다.

막막했었지만, 깃허브와 유튜브를 뒤져보며 다른 사람들이 Flutter에서 어떻게 http를 통해 통신했는지 공부했습니다. User 정보를 위한 Model도 만들고 json 형태로 값을 보내보기도 하고... 여러 가지 시도를 계속 이어갔습니다.

그 결과, 처음으로 database에 회원 정보가 등록되는 것을 확인하고 큰 기쁨을 느꼈습니다. 정말 사소한 작업이지만 직접 내 손으로 팀원들과 해냈다는 것이 뿌듯했습니다.

굉장히 어색했지만 작업 후반으로 갈 수록 숨 쉬듯이 통신하는 코드를 작성하게 되었습니다. 이렇게 백엔드와의 통신을 공부하면서, 백엔드에 대한 공부도 조금 필요하지 않을까?라는 고민도 하게 되었습니다.

빈약한 아이디어 바로잡기

전반 작업이 끝나고 중간고사가 시작되었습니다. 잠시 프로젝트가 중단되고 각자의 공부를 이어나갔습니다. 이후 다시 모였을 때, 글쓴이는 고민에 빠지게 되었습니다. 현재 주요 기능인 '미션과 도장'은 너무나 빈약하다는 생각이 들었습니다. 단순한 CRUD기능 구현에 지나지 않기 때문이었습니다.

핵심은 '선생님 없이 아이들의 사회활동을 앱에서 인식' 해야한다는 점입니다.따라서 긴급하게 회의를 소집하였고, 두 가지의 핵심 아이디어를 얻어낼 수 있었습니다. 그것은 바로 '하이파이브'와 '모이자' 기능이었습니다.

Zenly bump: https://mosg.tv/2019/02/24/app-track-friends-ridiculously-creepy/

첫 번째 기능 '하이파이브'는 Zenly 애플리케이션의 bump라는 기능에서 착안했습니다. 두 아이가 물리적으로 가까이 있다는 것을 인식하는 방법으로 사용하기 좋다고 생각했습니다. 핸드폰을 흔드는 행동 또한 발표장에서 보여주기 정말 좋겠다고 생각했습니다. 글쓴이는 자료 수집 과정에서 bump api라는 것이 있다는 글을 보고 그것을 통해 쉽게 구현할 수 있겠다고 생각했습니다. (사실 그런 것은 없었고 정말 힘들게 구현하게 되었습니다.)

google map을 사용하고자 했습니다.

두 번째 기능 '모이자'는 다음과 같습니다. 먼저 앱에 지도를 추가하여 다른 아이들의 위치를 확인할 수 있습니다. 그리고 장소를 터치하여 거기서 모이자는 알림을 보낼 수 있는 기능입니다.

위 두가지 핵심 기능이 추가되고 비로소 앱의 방향이 결정되었습니다. '아이들의 사회성 증진'이라는 목적 또한 더 잘 설명할 수 있게 되었습니다.

목표가 명확해졌으니, 이제 개발에 집중할 일만 남았습니다.

2편에서 계속...

[Software Engineering] 애자일 개발 방법론 그리고 스크럼을 경험하자 (Agile Software Development and Experience of Scrum)

모노산달로스 — Thu, 30 May 2024 17:16:08 +0900

애자일 프레임워크. 스크럼

해당 포스트는 경기대학교 소프트웨어 공학 강의의 도움을 바탕으로 작성되었습니다.

소프트웨어는 개발은 팀을 만들고 인원들이 서로 협업하면서 이루어집니다. 이러한 소프트웨어 개발을 위하여 다양한 방법론이 제시됩니다. 구조적 방법론, 객체 지향 방법론, CBD 개발 방법론 등 필요에 따라 알맞은 방법론을 선택할 수 있습니다. 이번 포스트에서는 애자일 개발 방법론에 대하여 알아보고 K-scrum을 통한 실제 경험을 공유해 보겠습니다.

Agile Software Development

출처 : https://kruschecompany.com/agile-software-development/

애자일 개발 방법론이란 이름 뜻 그대로 재빠르게(Agile) 최소한의 실행 가능한 제품(minimum viable product)을 출시하는 것을 기본으로 합니다. 이후 유저의 행동이나 피드백을 받아서 제품을 수정하고 기능을 추가하면서 개발이 이루어집니다.

그 유명한 폭포수 모델(Waterfall method)과 정 반대의 성격을 가지고 있습니다. 폭포수 모델은 개발을 시작하기 전 매우 구체적인 요구 사항과 설계도를 만듭니다. 그리고 개발을 진행하여 '완전한' 제품을 출시합니다. 이러한 특징 때문에 개발하고자 하는 제품이 복잡해질수록 설계 과정에 소모하는 시간이 급격히 늘어나게 됩니다.

출처 : https://management.org/waterfall-methodology

현재 소프트웨어 산업의 특성상 원하는 제품을 빠르게 개발하는 것이 중요합니다. 실제로 개발을 진행할 때도 처음부터(Scratch) 만들기보다는 이미 만들어진 틀에서부터 시작하는 경우도 많다고 합니다. 또한 개발되는 제품은 날이 갈수록 복잡해지고 있기 때문에, 애자일 개발 방법론이 주목받는 것은 당연한 상황이 되었습니다.

Scrum

출처 : https://theartofgoalkeeping.com/product/rugby-scrum-design/

럭비 경기를 보신 적이 있다면 스크럼에 대해 들어본 적 있을 것입니다. 경기를 재개할 때마다 양 팀의 선수들이 한 장소에 모여서 공을 차지하기 위해 경쟁합니다. 이러한 스크럼이 애자일 프레임워크(Agile Framework)에서 소프트웨어 개발 용어로써 사용됩니다.

스크럼의 두드러진 특징으로 스크럼 마스터(Scrum Master)와 프로덕트 오너(Product Owner)의 존재가 있습니다. 이들은 스크럼팀(개발자, 디자이너, QA 그리고 테스팅 등)을 조직하고 관리하는 역할을 합니다.

출처 : https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/

Sprint

스크럼은 여러 번의 스프린트(Sprint)를 거치면서 진행됩니다. 하나의 스프린트는 약 2주간 진행되는데, 그동안 정해진 양의 작업을 완료하게 됩니다. 이러한 스프린트의 특징은 애자일 원칙의 "빠른 제품 배포 간격" 그리고 "계획의 변화를 수용"에 부합한다고 볼 수 있습니다.

출처 : https://www.cybermedian.com/what-is-a-sprint-in-scrum/

스프린트의 진행 과정은 아래와 같습니다.

1. 스프린트 전 회의를 통하여 프로덕트 백로그를 스프린트 백로그로 변화시킵니다.
2. 스프린트 기간 동안은 미리 정한 목표를 완수합니다.
3. 데일리 스크럼을 진행합니다. 15분 이내의 짧은 시간 동안 진행하는 미팅으로 팀의 작업상황을 확인합니다.
4. 스프린트가 끝나면 다음 스프린트를 준비합니다.

K-Scrum

경기대학교 소프트웨어 공학 강의에서 이러한 스크럼의 진행 과정을 실제로 경험할 수 있었습니다. 이는 K-scrum으로 불리는 학생 교육용 경량화 스크럼을 통하여 진행되었습니다.

먼저 팀을 구성한 후 각자 역할을 프로덕트 오너(Product Owner), 스크럼 마스터(Scrum Master), 개발 팀(Develop Team)으로 나누었습니다. 글쓴이는 스크럼 마스터의 역할을 맡게 되었습니다. 앞으로 제품 개발 과정에서 작업을 잘 할당해 주고 개발 팀을 관리하는 일을 하게 됩니다.

개발 주제는 Movie Lens를 통한 영화 추천 웹사이트의 개발이었습니다. 스프린트는 0부터 3까지 진행되며 각 스프린트는 2주간의 기간을 가지게 됩니다.

아래부터는 각 스프린트의 리뷰와 최종 결과에 대한 후기를 서술하겠습니다.

출처 : https://www.scrum.org/resources/what-scrum-module

스프린트 0

스프린트 0은 본격적인 개발을 시작하기 전 팀원들 간의 아이스 브레이킹을 위한 시간으로 구성되었습니다. 개발 과정에서 팀원들 간의 협업을 위해서는 신뢰가 바탕이 되어야 합니다. 목표를 향해 달려가기 전 각자의 능력과 역할을 다시 한번 파악하는 시간을 가졌습니다.

작업을 위해 디스코드와 카카오톡으로 소통했습니다. 그리고 앞으로 따라야 할 깃 전략을 시각화하여 미리 공유했습니다.

Main을 루트로 Release branch를 만들었습니다. 그리고 Backend와 Frontend 브랜치 두 개로 나누어 작업을 구분했습니다. 각자 역할에 맞게 Frontend와 Backend 브랜치에서 자신의 작업 브랜치를 만들어 수행한다면, 누가 어떤 작업을 얼마나 했는지 확인하기 용이하다고 생각했습니다.

스프린트 1

가장 먼저 2주간의 스프린트 동안 2번의 미팅을 하도록 정했습니다. 스프린트를 시작하기 전 작업을 분배하는 미팅, 작업을 잘 수행했는지 확인하는 미팅이었습니다.

K-scrum은 실제로 실무에서 만나는 것처럼, 팀원 대부분이 처음 보는 인원이었습니다. 이러한 상황에서 작업을 알맞게 분배하고 어떻게 참여를 유도할지 스크럼 마스터로서 고민하게 되었습니다.

우선 개발팀의 인원들은 생각보다 작업에 미숙한 상황이었기 때문에 PO와 함께 작업에 적극적으로 참여해야겠다는 계획을 세웠습니다.

피그마로 구성한 제품 UI

그리고 개발팀을 위하여 먼저 틀을 잡아야겠다고 생각했습니다. 피그마를 통해서 제품의 UI를 구성한 다음 개발팀과 공유했습니다. 작업을 지시하기 위해서 시각적으로 목표를 보여준다면 쉽게 따라올 수 있을 것이라 생각했습니다.

스프린트 2

스프린트 1에서 제작한 틀에 숨을 불어넣는 시간이 되었습니다. 스프린트 2에서는 추천 기능을 제외한 기능들을 모두 구현하고자 생각했습니다. 사이트에서는 영화의 리스트를 화면에 보여줍니다. 그리고 영화에 댓글을 달거나 좋아요를 표시할 수 있고, 그것만 모아서 확인하는 기능을 생각했습니다. 그러기 위해서는 현재 정적인 웹 사이트를 동적으로 바꿀 방법이 필요했습니다.

문제는 Developer Team에서 서버와 DB를 다룰 수 있는 인원이 없었기 때문에 난감한 상황에 빠졌었습니다. 다행히 PO가 DB에 관한 역량을 가지고 있었기에 어떻게든 진행할 수 있었습니다. 이에 따라 기존의 HTML에서 PHP를 사용하도록 계획을 변경하였습니다.

Movie Lens Database

스프린트 3

스프린트 2에서 추천 기능을 제외한 기능을 모두 구현했지만 아직 부족한 점이 많았습니다. UI가 매우 미숙한 상태였으며, 추천 기능 또한 아직 전혀 구현되지 않았었습니다.

개발하고자 한 추천 기능은 정렬 알고리즘을 통한 방법입니다. 사용자는 장르, 연도, 정렬 기준을 선택합니다. 이를 바탕으로 가장 적합한 영화를 추천해 주도록 하였습니다.

다만 이렇게 만들면 계속해서 추천되는 영화만 추천이 될 가능성이 높기 때문에 차후에 개선할 필요성이 있다고 생각합니다.

마지막 스프린트부터는 글쓴이 또한 개발에 적극적으로 참여하게 되었습니다. 사이트의 전반적인 버그를 수정하고 UI 개선에 힘을 쏟았습니다. 마지막으로 PO와 함께 추천기능을 개발하여 웹 사이트를 릴리즈 하였습니다.

GitHub - boroboro01/SoftwareEngineeringProject: Kyonggi University Software Engineering Project Repository. The website recommen

Kyonggi University Software Engineering Project Repository. The website recommend movie using AI - boroboro01/SoftwareEngineeringProject

github.com

그렇게 마지막 스프린트가 종료되었습니다.

후기

소프트웨어 공학 수업 또한 막바지를 향해 달려가고 있습니다. 3학년이 되면서 짧은 시간에 많은 팀 프로젝트를 수행하게 되었습니다. 외부 공모전까지 합치면 4개가 넘는 프로젝트에 참여하면서 최근 정말 많은 성장을 하고 있다고 느끼고 있습니다.

이러한 상황에서 특히나 소프트웨어 공학 수업의 중요성이 두드러진다고 생각합니다. 지금까지 학교에서 배운 수업은 개발 자체에 대한 내용이었습니다. 하지만 개발자라면 당연하게도 팀을 이루어야 하는 상황에서 '어떻게 개발 협업을 잘 수행할까?'에 대한 내용을 제시히고 있기 때문입니다.

개발자에게 팀워크는 중요한 역량입니다

K-scrum을 통하여 이러한 과정을 이론뿐 아니라 실습으로 배워볼 수 있어 좋았습니다. 스크럼 마스터의 역할을 수행하면서 팀을 이끌고 개발팀과 대응하는 방법을 경험하는 것은 쉽게 해 볼 수 없었던 경험이라고 생각합니다.

하지만 스크럼 마스터의 역할을 잘 수행했느냐? 하면 아쉬움이 남는 것은 사실입니다. 스프린트 막바지에는 PO와 글쓴이 두 명이서 개발을 도맡아 하게 되었습니다. 그렇게 되면서 스프린트 3에 업무가 과중되는 문제가 생겼습니다.

개발팀의 역량이 부족했다고 무작정 탓을 할 수도 있지만, 그러한 상황에서 데일리 스크럼을 통해 개발팀의 참여를 잘 유도하여 작업을 수행했더라면 진행이 조금 더 수월했으리라 생각합니다.

글쓴이는 팀장 역할을 맡아 팀을 이끄는 것을 좋아합니다. 앞으로도 수많은 프로젝트를 진행하게 될 텐데, K-scrum의 경험은 이러한 상황에서 필요한 능력을 얻어가는 좋은 기회였다고 다시 한번 회고합니다.