발단
내가 이수했던 연계전공은 졸업하기 위해서 "종합설계" 과목을 수강해야만 했다. 4학년 1학기에 열리는 이 강의는 쉽게 말해 "너희가 지금까지 배운 모든 것들을 종합해서 뭔가 프로젝트 하나 해 봐라"라는 목적을 가진 강의다. 팀을 결성해서 한 학기간 프로젝트를 진행하고, 2학기엔 프로젝트의 내용을 졸업 논문으로 옮겨서 심사까지 받으면 졸업 요건이 갖춰지는 시스템이다. 즉, 간단하게 말하면 졸업 작품이다.
4학년에 졸업 작품을 만들어야 한다는 것은 이미 알려져 있었기 때문에, 전공을 쭉 들으면서 틈날 때마다 여러 프로젝트를 머릿 속으로 구상하곤 했었다. 때마침 17년도에 아두이노와 라즈베리 파이를 배울 기회가 있었고, 임베디드 프로그래밍에서 재미를 느꼈던 나는 가급적 아두이노를 사용하는 졸업 작품을 만들고 싶었다.
당시 내 집은 도어락이 아닌 열쇠로 출입이 가능한 집이었다. 건망증이 심한 나는 가끔 열쇠를 고향에 두거나 택시에 놓고 내려 낭패를 보는 일도 많았고, 집을 떠나 있을 때에 친구가 어떤 이유로 내 집에 들려야할 상황이 생겨도 열쇠를 건네줄 방법이 없었으니 난감한 상황이 종종 있었다. 그러다보니 이런 생각이 들었다. 도어락을 원격제어하는 프로젝트를 해보면 어떨까?
내 프로젝트는 다르다, 아무튼 다름
사실 아두이노를 이용한 스마트 도어락, IoT 도어락은 검색해보면 많이 나온다. 이미 RFID를 이용하여 제어할 수 있는 도어락도 있었고, 휴대폰과 블루투스 통신으로 여닫는 도어락도 있었던 것 같다. 이 부분이 문제였다.
- 이미 흔한 주제에,
- 구현 내용도 그렇게 어렵지 않다는 것.
졸업 작품으로선 여러모로 자격 요건이 떨어지는 아이템이었다.
그래서 여기에서 더 확장해서 가전 기구에 블루투스 비콘을 설치해서 서버로부터 허가를 받은 사람만 가전을 사용할 수 있도록 하는 프로젝트를 하고 싶었다. 여러 사람이 공용 공간을 사용하는 쉐어하우스 등에 적용해서, 이용 권한과 이용량에 따라 관리비 등을 차등 부과하도록 하면 괜찮지 않을까? 싶었는데 팀 회의와 교수님의 피드백을 거친 결과 이 확장안은 부결되었다.
"사실상 시도하고자 하는게 SI랑 크게 다를게 없어보이는데, 이 과목의 주제와 안 맞지 않나요?"
"구현까지 들여야하는 품은 많은데, 정작 구현된 알맹이는 뜯어보면 참 심심한 작품입니다."
이 두가지가 교수님의 주된 지적사항이었다. 그리고 슬프게도 이 지적은 학기가 끝날때까지 계속 되었고, 급기야 종강을 한달 남겨둔 시점에선 "아이템부터가 잘못되었다" 는 평가를 받았다. (그걸 처음부터 말해주셨으면 모두가 다 편했을텐데.. ^_ㅠ..)
우여곡절 끝에 정해진 프로젝트의 최종 스펙은 다음과도 같다.
- 이름 : LogINN
- 설명 : Login과 INN의 합성어. 에어비앤비같은 홈쉐어링 서비스를 이용하는 호스트들을 타겟으로 한 서비스. 호스트가 직접 숙소까지 방문하지 않고도 숙소의 도어락 비밀번호를 설정할 수 있다. 비밀번호는 서버단에서 랜덤으로 결정해주며, 이렇게 생성된 비밀번호는 바코드 이미지로 변환되어 숙소를 예약한 손님에게 이메일로 전송된다.
사실 위의 설명도 제대로 된 설명은 아니다. 일단 1학기에 완성되었던 결과물은 이렇지 않았다. 지금부터 순서대로 소개하고자 한다.
1학기의 LogINN - ver.A
풀스택을 넘어, 만능 개발자 데뷔
이 당시 내가 맡았던 역할은 다음과 같다.
- 아두이노 프로그래밍
- 라즈베리파이단 프로그래밍(Python 사용)
- 안드로이드 앱 프로그래밍
- 백엔드 api 서버 프로그래밍
- 각종 센서 구입
실제 종합 설계 진행기간은 16주(==4개월)이었지만 초창기에 구상 회의도 있었고, 발표가 날 때마다 혹평을 받아(아직 프로토타입도 안 보여줬는데..) 잦은 컨셉 수정을 거치느라 실제로 구현할 수 있었던 기간은 1달 정도였다. (써놓고보니 학기 중 이 과목만 수강하는 것이었다면 그렇게 빡세게 느끼지 않았을지도 모르겠단 생각도 든다. 그러나 난 해당 학기에 컴퓨터 공학 과목을 18학점을 수강했고, 과제만 도합 33개를 받았다.) 저 기간 내에 상기의 일들을 전부 처리했다. 농담이나 과장이 아니라 진짜 다 했다.
애석하게도 내가 만든 팀에서 프로그래밍을 할 수 있는 사람은 나밖에 없었다. 다른 팀원들이 프로그래밍을 안 배운 것은 아니었지만 역량차가 심각했다. (같이 일했던 팀원들은 원래부터 이중전공 선택을 후회한다고 했고, 지금은 IT와 관련이 없는 직무로 취직을 준비중이다.) 새삼 신기할 일은 아니었다. 난 팀 프로젝트에서 늘 코딩 전담이었으니. 그러나 이번만큼은 정말 진지하게 협업을 했어야 했다는 것을 말미에 후회했다.
위의 역할을 보면 알겠지만, 안드로이드 앱 프로그래밍 이 포함되어있다. 피드백으로 인한 컨셉 변경 중에 일어났던 일인데, 그래서 이 당시의 LogINN은 "숙박 앱과 도어록 관리 앱 그 어딘가 사이의 애매한 앱"이 되어버렸다. 구현을 하다보니 우리가 에어비앤비 클론을 만들고 있는건지, 스마트 도어록 앱을 만들고 있는 건지 헷갈릴 정도.
어중간하게 참견할 것이라면 아예 하지 말자
계속해서 이야기하는 내용이지만, LogINN ver.A는 참 여러가지로 노답이었던 프로젝트였다.
- 개발인력은 나 혼자였고
- 다뤄야하는 기술 분야는 임베디드, 모바일, 백엔드까지 각양각색인데다
- 매 발표때마다 뭘 말하고 싶은지는 모르겠으나, 아무튼 우리 프로젝트가 마음에 안 든다는 메시지만 확실히 전달되는 피드백을 받았고
- 그 피드백을 따라가기 위해 매번 컨셉을 고치다
- 결국엔 만든 본인들조차도 결과물을 설명할 수 없는 참사가 발생했다.
차라리 첫 발표때 아이템 자체가 거부당했더라면 이 정도로 심하진 않았을 것 같다는 생각이 든다. 아니, 결국 아이템 꺼낸 사람은 나니까 결국 내 문제였을까… 그렇다면 앞으로 기획은 피해야할 지도 모르겠다.
2학기의 LogINN - ver.B
이제 아무도 나를 막을 수 없으셈
다행인 점은, 2학기 졸업 논문 작성은 개별로 이루어진다는 점이었다. 즉, 더 이상 팀플을 하지 않고 1학기에 했던 프로젝트를 토대로 개인 논문을 작성해서 심사받으면 되는 것이다.
그 덕에 LogINN은 온전히 내 개인 프로젝트가 되었고, 누구의 간섭도 받지 않으며 재구축하는 것이 가능해졌다.
물론 그렇다고 논문 작성이 손쉬웠던 것은 아니다. 일단, LogINN이란 아이템 자체를 뒤엎고 새로운 것을 해볼까 하는 생각도 들었었다. 결국 새 아이템을 찾아 구현하는 데에도 수고가 적지 않게 들것 같아 포기하고 LogINN을 수정하는 쪽으로 마음을 바꾸긴 했지만.
그리고 ver.B로 넘어가면서 몇가지 컨셉이 바뀌었다.
안드로이드 앱 안녕, 다시 웹앱으로 회귀
아까도 언급했던 내용이지만, 본래 이 프로젝트에 안드로이드 앱은 안중에도 없었다. 갑자기 안드로이드 앱을 사용하게 되면서 부랴부라 앱 제작에 착수하긴 했지만, 모바일 앱 개발이라곤 애들 장난같은 조잡한 리듬게임 하나 겨우 만들어서 돌려본 나에게는 힘이 부치는 작업이었다.
특히나, 안드로이드 SDK는 버전을 넘나들때마다 어떤 메소드들이 우수수 deprecate되고, 새로운 메소드로 대체되고, 그에 따라 구글링을 해봐도 지금 상황에 딱 맞는 정보는 좀처럼 찾기가 힘들었고, 심지어 구글 개발자 API 문서가 잘못 작성되어있기까지(!) 했다. 원래부터 안드로이드 프레임워크 기반 개발을 쭉 해왔고, SDK 업데이트 내역을 전부 팔로우했던 사람이라면 간단하게 처리했을 내용이었겠지만, 급하게 구현을 해야하는 내 입장에서는 정말 대환장파티가 따로 없었다. 팩트체크하는 기자가 된 심정으로 정보를 선별적으로 모아야했으니..
그러한 연유로 내 개인 프로젝트에서 안드로이드 앱은 깔끔하게 배제하고 최소한의 기능이 담긴 웹앱으로 회귀했다. 이 때 당시에는 프론트엔드 개발을 전혀 몰랐으므로 UI가 뛰어난 웹 앱 같은건 생각하지도 못 했다. 그래서 결국엔 텍스트 필드와 submit 버튼만 있는 심심한 디자인으로 결정되었다.
푸시알림 구현은 MQTT로
1학기 ver.A에서는 푸시 알림이 별도로 없었다. 그저 라즈베리파이가 1시간 주기로 서버에 연결해 값을 받아오는 것이 전부였다. 이 방법이 크게 문제가 되진 않는다. 보통 손님들이 숙소를 예약한지 1시간만에 찾아가는 경우는 좀처럼 없기 때문이다. 하지만 나는 좀 더 세련된 처리 방법을 원했다. 그렇다면 푸시 알림이 답인데, 안드로이드는 FCM이라는 푸시 알림 서비스가 있는데, 라즈베리파이에서는 어떻게 처리할까? 검색 끝에 MQTT라는 푸시 알림 프로토콜이 있음을 찾아냈다.
MQTT(Message Queueing Telemetry Transport)는 TCP/IP 프로토콜 위에서 동작하는 발행-구독 형태의 메시징 프로토콜이다. 이 MQTT는 대역폭을 적게 차지하고, 저전력 환경에서도 구동 가능하단 점에서 IoT 시대에서 각광받을 푸시 알림으로 주목받고 있다고 한다. 실제로 IoT 업계에서 이 프로토콜을 주목하고 있는지는 아시는 분 있으면 제보 부탁드립니다.
위 스샷은 dev 환경에서 확인해 본 mqtt 브로커-클라이언트 mosquitto의 작동 모습이다.
이번엔 실제 도어락을 사용한다
1학기 ver.A에서는 도어락을 구할 방도가 없어 대신 서보모터와 피에조 부저를 이용해서 문이 열린 상황을 연출했었다. 2학기에는 운 좋게 이모네 집에서 쓰지 않는 도어락을 받을 수 있어서, 이 도어락을 가지고 실제 프로젝트에 참여했다.
실제 구현
구현 과정을 상세히 다 적지는 못한다. 나중에 mqtt 사용법이나 도어락과 아두이노 연결 방법 등은 별도의 강의로 다룰 생각이다. 아래는 간략한 흐름을 나타내보려고 했다.
위의 그림들은 실제 졸업논문에 우겨넣은 그림들이다.
숙소를 공유하는 호스트가 서버쪽에 손님의 이메일 주소를 넣고 generate하면, 서버에서 무작위 비밀번호를 생성한 다음, 숙소의 라즈베리파이에 mqtt 메시지로 새로운 비밀번호를 전달하고, 비밀번호를 바코드화한 이미지를 smtp를 통하여 손님에게 전송하는 방식이다.
이후 손님은 바코드 이미지를 저장해뒀다가 실제 숙소에 가서 바코드 리더기에 찍으면 도어락을 열 수 있다.
마지막으로 데모 영상으로 글을 끝마치고자 한다.
평가
후기를 쓰는 것이 망설여졌던 프로젝트는 이게 유일하다. 어떻게 보면 내 실패에 관한 기록이기도 했으니. 그래도 성과가 아예 없었던 것도 아니고, 혼자서 팀 프로젝트 하드 캐리할 수 있을 것이라는 자만심을 버리게 되는 계기도 되었다. 지금은 백엔드 개발자를 지향하게 됨으로써 임베디드나 mqtt 같은 이색 장르(?)에 해당하는 기술을 손 댈 일은 줄어들었다. 그러나 난 근본적으로 모든 기술에 관심을 가지는 사람이다. 이 때 아두이노를 손댔던 일, 누군가에게는 이름조차 생소할 mqtt를 다뤄본 일들은 나에게 소중한 경험으로 남았고, 언젠가는 이러한 경험이 또 나에게 큰 도움으로 돌아올 것이라고 난 믿는다.