Xamarin 과연 쓸만한가

Xamarin은 한마디로 애증의 기술입니다.

WebView를 이용하는 하이브리드앱 기술이든 중간자를 이용한 Xamarin 같은 멀티플랫폼앱 기술이든 5년 내내 개발자들과 CTO들을 갈등하게 만듭니다.

▲ Xamarin과 Blockchain 연동이라지만 그냥 Azure Blockchain WebAPI 용례입니다. 속았잖아!

Xamarin의 장점은 하이브리드앱 보다 네이티브API 연동이 더 직관적이고, 단점은 안드로이드/iOS 둘 모두 중급의 실력을 필요로 한다는 것입니다. ‘네이티브로 컴파일된다’는 기치를 걸고 있는 ReactNative, NativeScript는 Xamarin보다 복잡도가 더 높다는 생각이 듭니다. 저는 그래요.

왜냐하면 네이티브 프로그래밍에 가까운건 C# 코드와 1:1 변환 수준인 Xamarin과 HTML+JS+CSS를 동원하는 다른 것들과는 중간자의 복잡도에 있어서 시작부터 게임이 안되거든요. 아키텍처 관점에서의 논리랄까요.

JS기반 하이브리드앱 프레임워크(대표적으로 Cordova, Phonegap)들은 네이티브 연동을 위해서는 npm 모듈이 나올 때까지 멍때려야 하는 경우도 있지만 양쪽 플랫폼 모두 중급의 실력까지는 필요 없다는 점이 장점입니다. 뭐 실력이 좋으면 직접 모듈을 작성하면 되겠지만 하이브리드가 아닌 경우에는 ‘그냥’ 되는걸 굳이 왜그래야하나 싶은 생각이 들기 마련이죠. 특히 비슷한 기능의 npm이 여러개인데 뭐가 좋은지 어디까지 믿어야 하는지 고민할 때마다 ‘내가 지금 왜 하이브리드앱을 선택했다는 이유로 이런 것에 시간을 써야하나’싶죠.


저는 클라이언트 개발에 있어서 언제나 네이티브 주의자인데, 요즘은 ‘평범한 소셜 앱서비스’ 정도는 하이브리드로 최대한 버티려는 마음도 있습니다. 특히 다른 분들에게는 하이브리드를 추천합니다. 왜냐하면 저희 팀처럼 보폭을 착착 잘맞추는 팀은 많지 않기 때문입니다.

그래도 여전히 Xamarin을 눈여겨보는 이유는 양쪽 플랫폼의 발전에 꽤 빠른 속도로 따라가고 있는 점을 높이 사기 때문입니다. 예를 들어 지문인식 API 등 OS에 강하게 결합하는 API의 지원은 여느 하이브리드앱보다 빠르게 대응해왔습니다.

Xamarin의 인기가 적은 이유는 두가지라고 생각합니다.
멀티플랫폼 모두에 대한 중급 이상의 실력이 필요: Microsoft는 외계인들이 많겠지만, 평범한 회사는 둘 중 하나만 잘하거나 둘 다 못하는 개발자들이 대부분이죠.
훌륭한 설계가 필요: Microsoft는 IT 역사에서 가장 아키텍처링을 잘 하는 회사입니다. 하지만 대부분의 IT회사는 하루하루 먹고살기 바빠서 아키텍처에 쓸 시간이 부족하고 언제나 레거시에 허덕이고 있습니다.


그런데 요즘 하이브리드, 멀티플랫폼 모두 의미없게 만드는 경향이 작년부터 강하게 밀려옵니다.

다름 아닌, kotlin/swift 언어인데요. 공교롭게도 두 언어의 느낌이 비슷~합니다. 그러다보니 많은 개발자들에게 언어간 적응력이 뛰어납니다. 이제는 Android/iOS 양측의 이해도만 적당히 갖추면 두 언어를 오가며 개발하는 것도 큰 불편이 없어질거라 생각합니다.

여러분이 앱개발자라면, 2019년에는 완전히 kotlin/swift로 전향하는 것을 목표로 하길 권합니다. Xamarin은 XAML Standard가 성숙한 다음에 고려하는 것이 맞겠습니다.

광고

이게 대체 뭐하는 DB – Azure Cosmos DB

5년전이었나…시작은 평범한 NoSQL json DB였습니다. 실제로 제품명도 “DocumentDB”라는 맹물같은 이름이었지요. 장점이라면, MongoDB와 비슷한 용도에 (당시에는) MongoDB SaaS형 서비스보다 무척 빠른 속도였습니다.

그러다가 뭘 잘못먹었는지 Planet-scale이라는 거창한 슬로건을 가지고 이름을 Cosmos DB로 바꿉니다. 직역하면 우주 데이터베이스라니. 사춘기 청소년이 지은 이름 같잖아요.

Azure Cosmos DB라는 것입니다.
https://docs.microsoft.com/ko-kr/azure/cosmos-db/

이것의 가장 큰 특징은 두 가지인데, 하나는 API 또 하나는 분산복제입니다

API는 SQL, MongoDB, Gremlin, Table, Cassandra API 등을 지원하는데, ‘뭐 대충 인기있는 형식의 DB는 다 지원하자’는 느낌입니다. “너의 데이터가 어떤 형태로 있든 Cosmos DB는 다 맞춰줄 수 있다”는 의지마저 읽힙니다.

https://azure.microsoft.com/mediahandler/files/resourcefiles/build-enterprise-grade-blockchain-applications-with-azure-cosmos-db/Blockchain%20and%20Azure%20Cosmos%20DB.pdf

두번째 Cosmos DB의 특징은 분산복제입니다. 전세계적으로 복제본을 아주 빠른 시간 내로 만들 수 있다고 합니다. 이게 아주 대단한 연구를 실현한 기술이라더군요. 저는 시간 없어서 못읽어봤는데, 한번 연구해볼 가치가 있다고 봅니다. 관련 논문은 http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf 입니다.

그런데 이번엔 블록체인 떡밥도 물었네요. (아..제발 님아 그 강은 건너지마오) 생각해보면 분산복제 기능이 블록체인의 특성과 잘 맞아떨어진다고 생각합니다.

이 문서를 읽어보면, 전체적으로 “에이~ 블록체인 그냥 CosmosDB로 퉁치면 안되나? 될거같은데에~?”라는 인상을 주는 글입니다. 링크의 글을 읽어보면 아래와 같은 플로우차트가 있는데, 결국 하고 싶은 말은 ‘기존 블록체인과 연계하는 용도 외에는 대부분의 요구사항은 CosmosDB로만 구현해도 된다고 주장합니다. (저에겐 그렇게 읽히네요)

프라이빗 블록체인의 요구사항 대부분은 Azure Cosmos DB만 잘쓰면 해결되는 것처럼 읽힌다

Azure Cosmos DB가 기술적으론 대단한데, 개발할 때는 마냥 좋은건 아닙니다. Azure CosmosDB를 실제로 써보면 RU(Request Unit)라는 과금단위에 당황합니다.

쿼리 하나마다 과금하는 형태지만, 리쿼스트 한 번에 3RU 트랜젝션을 만들 수도 있기 때문이지요. 이건 그저 쿼리를 해보면서 튜닝하고는 있는데, 유저 입장에서 직관적인 계산법은 아니긴 합니다. 그리고 Collection 마다 과금을 해서, RDBMS처럼 테이블을 자유롭게 만들고 부술 수 없습니다. 테이블 하나 만들 때마다 가격 요청이 있다고 생각하시면 됩니다.

그 외에 솔솔하게 대단한 기능도 있습니다. ‘change feed’라고, 변화값을 스트리밍하는 기능입니다. 자세한 내용은 아래 링크를 클릭하세요.
https://docs.microsoft.com/ko-kr/azure/cosmos-db/change-feed


HockeyApp in-app Update 좋다

참고: 이 글은 Android 개발에 해당하는 글입니다.

Naver/LINE은 nelo라는 모바일 텔레메트리 서비스가 있습니다. 퍼블릭 서비스로는 ELSA라고 부르는 것 같은데, 회사에서는 다들 nelo라고 부릅니다. 뭐라고 부르든 무슨 뜻인지 모르겠으니 그런게 있나보다 합시다.

Telemetry? 네, 모바일앱의 크래시 수집하고 터치나 스크롤 같은 유저활동정보를 기록하고 수치화하는 기능을 뜻하죠. 직역하면 ‘원격 활성수치 수집기’ 정도의 의미겠습니다. 스타트업에서 흔히 쓰는 서비스로 Crashlytics, UserHabit 등이 있습니다.

HockeyApp은 전세계에서 두세번째로 많이 쓰이는 모바일 텔레메트리 서비스로, Microsoft에서 2014년에 인수했습니다.

전체적으로 담백하게 생겼습니다

Crashlytics에는 없고 HockeyApp에 있는 기능으로 ‘업데이트 in-app 설치’ 기능이 있습니다. 꽤 유용한 기능인데 의외로 모바일 텔레메트리 SaaS 서비스들 중에 이 기능을 갖춘게 HockeyApp 외에는 없더군요. (또 있으면 알려주세요)

‘업데이트 in-app 설치’ 기능이 뭐냐면, Fabric은 Beta 앱을 별도로 설치해야 테스트유저들이 최신 apk를 설치할 수 있는데, HockeyApp은 SDK 라이브러리 안에 apk 다운로드와 ACTION_INSTALL_PACKAGE 인텐트를 직접 호출해서 테스트할 사람들이 앱을 실행하자마자 최신 버전을 원클릭으로 설치할 수 있습니다. 상상하는대로, ‘최신 버전이 있습니다’ 팝업이 뜨고, 클릭하면 apk를 다운로드하고, 설치하는 기능이죠.

어쩌면 대부분의 모바일서비스 개발팀은 이 기능이 필요 없을지도 모릅니다. Google Play Store에 앱을 올릴거고, Play Store 자체적으로 베타버전 관리 기능이 있기 때문이지요. 네이버 메인앱도 Play Store의 베타유저 관리기능을 이용하고 있으니까요.

하지만, 엔터프라이즈 환경이거나 Play Store에 아직 업로드할 생각이 없거나, Play Store의 베타 유저 관리가 번거롭다면 HockeyApp의 ‘업데이트 in-app 설치’ 기능이 정말 유용합니다.

Crashlytics와 마찬가지로 apk를 아무리 업로드를 많이 해도 무료입니다.

뿐만 아니라, 전통적인 Windows Desktop 어플리케이션도 ‘업데이트 in-app 설치’가 가능합니다. 저는 WPF 프로그램을 배포할 때 사용하고 있습니다. 보통 데스크톱앱의 업데이트를 관리하려면 바이너리를 올려놓는 별도의 서버를 마련해야만 했는데, HockeyApp은 무료로 꽤 좋은 업데이트 경험을 제공하고 있습니다.

2019년부터 HockeyApp은 Microsoft App Center로 이전 중에 있습니다.

HockeyApp이 제공하던 편의는 그대로이며, 소스코드 연계부터 디바이스 관리와 배포 기능을 더 강화했습니다. 그래서 기존의 제품 분류는 텔레메트리 서비스였다면, 이제는 배포기능이 더 강화되어서 모바일 배포 솔루션이라고 할 수 있으며 FastLane이 경쟁 서비스라고 할 수 있겠습니다.

주의할 점은 아직 이 글에서 소개한 in-app 업데이트 기능은 이전이 안되었습니다. 곧 되리라 기대합니다.
https://docs.microsoft.com/en-us/appcenter/sdk/distribute/android


성심당

귀국길 비행기 안에서 2시간 동안 한 흐름에 읽었다. 그만큼 빠르고 쉽게 읽혀서 좋다.

나는 원래 이런 책을 좋아한다 – ‘살아있는 사람의 이야기’

원래 이 책은 사자마자 읽은 프롤로그에서 지나치게 비현실적인 부분이 있어서 읽을 맛이 확 사라졌는데 그 부분을 꾹 참고 넘어가니 한 번에 읽을 수 있었다. 다행이었달까. 비현실적인 부분은, 빵집이 불에 활활 타고 있는데 주인은 현장에서 벗어나 성당에 가서 무릎꿇고 기도했다는거다. 이게 사실이었다면 믿음이 어마어마한 사람이라는 생각도 들지만 글쎄. 미화된 것이든 사실이든 그것은 책 전체의 스토리에는 별 영향이 없으니 넘어가자.

나에게 성심당은, 대전에 잠깐 있던 몇 년전 서울 올라올 때마다 KTX 역에서 ‘판타롱 부추빵’을 하나 사서 열차 안에서 야금야금 먹었던 추억이 있다. 나는 튀김소보로는 별로 입에 안맞더라.

이야기를 가진 집단은 그렇지 않은 집단보다 생존 가능성이 높다. (…) 이야기를 중심으로 임직원들은 단합하고, 같은 비전과 목표를 공유한다. 또한 이야기는 기업의 독특한 문화를 만들어낸다. 자기만의 문화를 가진 기업은 시장 안에서도 독자적인 생명력을 유지할 수 있다. [p25-p26]

책의 1장 시작에 나오자마자 주옥같은 내용을 건져서 기분이 좋았다. 이 문장이 하나로 끝까지 읽을 수 있었는지도 모른다. 우리 회사는 다른 유사 서비스보다 풍부한 이야기가 있다. 이를 잘 활용하면 좋겠다는 생각을 했다.

튀김소보로를 먹어본 사람과 그렇지 않은 사람으로 나뉘었다. [p84]

학생들도 우리 서비스를 써 본 사람과 아닌 사람으로 나뉘기를 바란다. 우리 기술, 우리 서비스, 우리의 진심을 접해본 학생과 아닌 학생으로 나뉠 정도로 우리의 아이덴티티가 있기를 바란다.

성심당의 인상깊은 점은, 지역에 대한 사명감이 대단하다는거다. 나는 그럴 수 있을까? 그러지 못했을 것 같아서 존경스럽다. 그까짓 지역이 뭐라고 말이다. 하지만 나 역시 한 지역을 넘어, 한 나라, 한 대륙(동아시아)에 대해서 그런 생각을 가지고 있다. 뭐든 작은 지역 부터가 시작이 아닐까도 싶다. 가끔 O2O 스타트업을 보면 서초구/강남구 등 구단위 부터 출발하는데 이제는 그런 것에 대해 ‘어느 세월에’라는 생각보다는 ‘결국 해낼 수 있겠지’라는 생각을 가지기로 했다.

사실 이 책을 읽으면서 질질 눈물이 날 때가 여러번 있었다. 재미난 점은, 이 책은 그런 최루성 내용이 전혀 없이 우여곡절을 꽤 담담한 필체로 적어나가고 있다는거다. 어쩌면 비행기 기내가 워낙 건조해서 그랬는지도 모르겠다.

한편, ‘아이고 왜이리 눈물이 날까’ 하면서 스스로를 돌아봤는데 어쩌면 이 책에서 이룬 많은 내용들은 내가 그토록 갈망하던 어떤 포인트들을 자극해서 그런게 아닐까 싶기도 했다. 예를 들어, 누군가의 평생직장을 만들고 싶던 꿈이라거나, 한 지역(또는 한 국가)의 아이콘을 만들고 싶던 꿈이라거나, 아주 차별화된 한가지를 만들고 싶던 꿈이라거나, 그것이 온전히 하나의 책으로 나오는 꿈 같은거 말이다.

여전히 나는 그것들을 이루고 싶다.

우리 회사의 기업문화에 대해

스타트업들은 회사 홍보를 할 때 기업문화가 수평적이라던가 발랄하다던가 등등 긍정적인 기운이 느껴지도록 노력하는 경우가 있다.

예를 들어 해변가에서 단체점프하는 사진이나 회사 안에서 탁구치는 모습을 홈페이지에 걸어놓는거 말이다.

그에 비해 우리 회사 바풀은 참으로 잔잔한 편인데, 우리 자신도 기업문화가 어떻다고 분명히 말을 못한다. 사실 그럴 필요가 없는지도 모른다.

곰곰히 생각하면 이렇게 말할 수 있겠더라.

우리의 기업 문화는 지극히 건전하다.

문화적, 정신적 건전함은 일과 목적에 집중할 수 있도록 한다.

“우리는 비전을 공유하고-만들고-가꾼다.”

그래서 인터넷과 세상 문화의 한 구석을 조금이라도 더 좋게 바꿔보고 싶은거다. 이것을 위한 각자의 삶이 모인게 지금의 기업문화다.

요즘은 건전함이 넘쳐서, 어떤 레벨의 누가 오든 그 사람이 충분히 탁월해짐을 경험한다.

부족한 사람이 와도 능력자가 되는. 우리의 건전함이란 그 정도로 탄탄하다.

우리가 좋은 인재들을 빨리 뽑는 이유는, 사실 당시엔 그렇게 탁월하지 않아도 우리의 문화가 좋게 만들 자신이 있기 때문이다.

궁극적으로 좋은 기업문화는,

우리가 바라보는 가치에 대해서 흔들리는 시점엔 서로 불나는 토크를 할 줄도 알고, 모두가 의견을 말할 수 있고, 모두가 그에 반박할 수 있고, 때로는 ‘이 의견은 독재적으로 결정합시다’라며 상대의 결정에 온전히 맡길 수 있는.

…그런 믿음이 탄탄하게 흐르고 있는거라고 본다.

문화란, 그렇게 조직 사이에 말 없이 흐르는거다.

YJ

이슈트래커 YouTrack의 단점

유명 개발사 JetBrains의 YouTrackAtlassian Jira보다는 개발자 집단에 특화된 이슈트래커입니다. 개발자 집단에 특화되었다는 말은 JetBrains CEO의 말에 의하면 그렇고 저도 동의합니다.

마치 콘솔작업처럼 키보드 하나만 쳐도 바로 커맨드 창이 뜨고 자사의 IDE제품군과의 매끈한 연결, 강력한 검색 기능 등이 그런 특징을 나타냅니다. 특히 이슈와 칸반을 모두 지원하기에 빠른 이슈리스팅과 시각적인 업무 흐름을 함께 파악하기에 좋습니다.

장점은 이전 글에서 읽으실 수 있고 이 글은 제가 있는 조직이 YouTrack을 도입한지 1년 즈음 지나서 느끼는 단점에 대해서 적습니다.

1. 매우 유연한, 그만큼 고민해야 하는 사용법

YouTrack의 칸반보드는 매우 다양한 기준으로 구성할 수 있습니다.

YouTrack 칸반보드. 출처: JetBrains blog
YouTrack 칸반보드. 출처: JetBrains blog

기본적인 틀은 하나의 이슈(=티켓)에 사용되는 특정 프로퍼티를 기준으로 하게 되는데, 중요도, 분야, 프로젝트, 담당자 등 그야말로 enumerable한 속성이면 모두 가능합니다.

또한 각 이슈의 위상을 결정하는 것(feature-task, feature-task-subtask 등), 이슈 간 연결 형태(주종관계/참조관계 등) 등을 직접 정의할 수 있습니다. 쉽게 말해 YouTrack은 ‘이슈트래커 만드는데 필요한 데이터 덩어리를 적당히 GUI로 엮어준 것’에 가깝습니다.

그러다보니 어떤 기준으로 어떻게 구성해야 하는지에 대한 시행착오와 판단 또한 끊임없이 겪습니다.

2. 빈약한 Integration

사실 이게 YouTrack을 사용하면서 가지는 가장 큰 불만일겁니다. GitHub issue, Trello 등이 slack 초창기부터 연동이 되었지만 YouTrack은 아직 연동도 되지 않고, IDE 플러그인은 자사 JetBrains 제품군 외에는 없다시피 합니다.

API는 오픈이니 직접 개발해도 되지만 어느 천년에, Atlassian JIRA가 직접 IDE들의 플러그인을 꽤 좋은 품질로 제공한다는 것에 비해서는 안타깝긴 합니다.

Visual Studio 연동이 안되는 것은 우리 팀에겐 치명적이고요. API가 오픈되어도 Zapier같은 API브릿징 서비스에도 관련 서비스는 없습니다. 회사의 모든 IDE가 JetBrains 제품군(IntelliJ IDEA, PyCharm, WebStorm, Android Studio 등)이라도 불만은 있는 셈입니다.

참고로 저희 회사는 (아마도) 우리나라에서 JetBrains 제품군을 가장 많이 사용하는 회사일겁니다. Products 페이지에서 2개(CLion, Rubymine) 빼고는 다 쓰고 있으니까요. 그럼에도 업무에 완결성이 잘 안이루어지는거죠.

3. 모든 것이 다 가능하지만 모든 것이 그냥 되지는 않아

안드로이드나 리눅스를 만져보면 처음에 이런 인상을 가지죠. ‘우와! 리눅스는 다 된다! 내가 상상했던 것, OS의 소스를 직접 보고 수정도 할 수 있고, 그야말로 전지전능해진 것 같아’

하지만 함정은, 쉽게 되지는 않는다는 거죠. YouTrack은 Workflow라는 기능이 있고 Workflow Editor라는 별도의 설치프로그램이 있어서 많은 것을 자동화할 수 있습니다. 일종에 스크립트 언어인데 익숙해지는데 시간이 꽤 필요합니다.

YouTrack WorkFlow Editor
YouTrack WorkFlow Editor. 자, 만능 편집기를 만들었으니 다 해보렴 ㄷㄷㄷ

Workflow editor는 몇 십개의 기본 workflow가 제공되는데, 예를 들어 이슈가 끝나면 코멘트를 못달게 하는 것, 상위 이슈가 fixed되면 하위 이슈도 자동으로 종료 처리하는 것, duplicate 처리되면 자동으로 닫는 것 등등입니다.

일하기 바쁜데 이슈트래커 스크립트 언어도 익히고 기술문서도 읽어야 하지요. 이런 것을 마치 아웃룩의 규칙 정하는 것처럼 콤보박스들과 조건 몇가지 만으로 만들 수 있다면 좋았을 겁니다.

4. InCloud 제약

InCloud는 YouTrack의 구독형 서비스입니다. 저희는 클라우드 구독형 서비스를 선호합니다. 설치형으로 머신을 관리하는 것 자체를 부담으로 생각하지요. JetBrains의 개발 툴체인은 IDEs(개발툴들)-YouTrack(이슈트래커)-UpSource(코드리뷰)-TeamCity(CI빌더)로 구성되어 있는데, 이 중 YouTrack만은 설치형 외에 구독형을 제공합니다.

이대로 되긴 한다만...
JetBrains 개발 툴체인. 이대로 되긴 한다만…출처: JetBrains

저희가 구독하는 YouTrack InCloud는 AWS의 East-Europe에 구성되어있다고 나오는데 일단 속도가 느립니다. 또한, 위에 언급한 개발 툴체인이 단일 계정으로 묶여야 하는데 InCloud account(Hub라고 합니다)와 나머지 설치형 account는 통합이 되지 않습니다.

그러므로, YouTrack을 사용하신다면 반드시 설치형으로 사용하시길 권합니다. 그 외에 InCloud임에도 SLA도 없고 공지된 유지보수 스케줄과 어긋나게 하루 내내 안된 적도 있습니다.

5. 칸반에 자동 새로고침이 없다

칸반보드는 한 눈에 진행상황을 보기에 좋습니다. 하지만 뭔가 이슈가 슉슉(!) 이동하는게 없이 꼭 새로고침을 눌러줘야 합니다. 더 나아가 이것을 TV에 쏘라고 ‘TV 모드’라는 뷰도 제공합니다. 이 TV 모드에도 자동 새로고침이 없습니다. 그냥 디자인 테마인거죠.

뭐 브라우저 플러그인으로 인터벌 새로고침 기능을 돌리면 되지만 그 때마다 전체가 깜박이겠죠. 오래된 컴플레인인데 구현하기 복잡한가봅니다. PivotalTracker에서 가장 만족했던게 누군가의 변경사항이 실시간으로 보였던 것입니다.

현재는 GitHub Issue로

바풀 개발팀이 3명 이하였을 때, 이슈트래커로 PivotalTracker를 열렬히 사용했습니다. 하지만 5명이 넘으면서 프로젝트를 나누면 한 눈에 파악하기가 불편하고 합치면 너무 와글와글해보여서 YouTrack으로 옮겼습니다.

이제 YouTrack은 5~10명 정도의 팀에는 너무나 방대한 기능이 있다는 생각이 들었습니다. 그래서 두 달 전부터 GitHub Issue를 사용하기 시작하고 있습니다. GitHub은 마일스톤-이슈라는 단순한 위계, 각종 규칙은 라벨로 적당히 유연하게 구성할 수 있고, YouTrack보다는 폭넓은 integration을 가지고 있습니다.

GitHub 이슈로 위의 단점들이 해소되는 것은 아니지만, 어차피 비슷한 단점일 바엔 좀 더 단순한걸 사용하자는 판단입니다.

10년을 생각하며

2010년 1월 1일 새벽 6시에, 나는 집에서 나와서 연구실로 향했다.

나는 그 때의 새벽 공기, 어스릇한 대기의 색상, 교차로의 신호등 불빛과 내 차에서 손가락을 가볍게 물고 있던 나의 자세와 생각을 모두 생생히 기억한다.

10년간 내가 교육을 기술로 재해석해보겠다고 스스로와 약속했고, 이제 4년이 되어 간다.
– 참신했고 호응이 좋았으나 널리 쓰이지 못한 ‘탭스터디’
– 많이 사용되지만 언제나 미완성으로 될 것 같은 지금의 ‘바로풀기’
– …

이제 내년이면 5년차가 되므로, 그 다음의 5년을 생각해야 할 때이다.
이 다음의 5년은, 어쩌면 나의 다짐에는 마지막 여정이 될 수도 있다.
그만큼 당시만큼의 고민을 하게 된다.

현재는 건축 관련 책을 많이 읽고 있다. 아마도, 좀 더 현실 세계와 연결성이 있던가, 작지만 단단한 건축과 같은 것을 상상하거나, 확장해도 전체가 어색하지 않은 어떤 구조를 만들고 싶은 욕망때문일게다.

지금 머리 속에 드는 생각은 ‘마인크래프트’와 비슷한 무언가가 머리 속에 자리잡는다. 하지만, 개념이 그렇다는거지 어떻게 발전할지는 모른다.

다음의 5년. 그리고 그 완성이 될 것 같은 10년.
나는, 인생에 어떤 족적을 남길까…?