이걸 보고 느꼈던 점은 20년 전에 대학 학부시절에 배웠던 논리회로 공부했던 것과 컴퓨터 구조와 원리 과목떄 공부했던 내용들이 떠올랐다는 것이다. 그렇다는 것은 컴퓨터의 기본 원리는 변하지 않고 동작 방식 역시 크게 바뀌지 않았다는 뜻일 것이다.
특히 비전공자들이 코딩하는 방법을 배우고 실무에 들어가서 일을 하는데 있어서 가끔 "전공 지식을 공부하는건 어떨까?" 싶다는 생각이 들기도 할 건데 그때 이책을 보면 된다. 국내 대학에 컴퓨터 전공 학부생 1,2학년 생이라면 이 내용을 반드시 배우게 되어 있기 때문이다. 그리고 실제 코딩하는 것과 크게 상관이 없어 보인다는 현타가 오면 전공자들이 흔히 농담식으로 얘기하는 "전공 공부 할 필요 없다"가 무슨 뜻인지 알게 될 수도 있다.
실제 코딩하는 데 있어서도 조금 이해가 되고 도움이 될 만한 부분은 bit, byte 간의 관계 그 연산 방법 bit shift가 뜻하는 것도 자연스럽게 알 수 있으며 and, or, not 같은 코딩 문법의 진짜 원리를 알 수 있는 기본적인 걸 논리 회로도와 함께 알 수 있게 된다.
다 읽고 나면 컴퓨터가 이런 원리로 동작 하는 구나를 알 수 있는데 컴퓨터 이론서가 필요하긴 한데 교과서 적인거 말고 교양서 수준으로 읽고 싶은 사람한테는 좋은 책일 것 같다.
나는 LINE 개발자입니다 -
강윤신 외 지음, LINE Developer Relations 팀 엮음/한빛미디어
오랜만에 쓰는 책 리뷰이다.
책 내용이 무겁지도 않은데다가 LINE 개발자의 LINE 입성기, LINE 자랑 정도의 글인데 순식간에 읽어 나갔다. 심지어 같은 사람이 쓴 글이 아닌 12명의 개발자들이 쓴 글이라 글 스타일이 다른데도 말이다.
크게 느끼는 부분이 몇 가지가 있어서 적어본다.
정말 중요하고 소중하게 느껴지는 코드 리뷰의 문화
나의 경우에도 제대로된 코드 리뷰를 해 본지도 꽤 오래된거 같다. 모두 각자 맡은 프로젝트가 있고 바쁘다 보니 코드 리뷰는 거의 사치가 되어 간다. 나는 내 코드를 스스로 리뷰한다. 리뷰-리팩토링-고민-리뷰로 이어지는 스스로의 리뷰는 남들과 함께 하는 리뷰에 많이 목이 마르다.
그렇다고 회사에서 코드 리뷰를 하지 말라고도 하지 않았고, 해도 큰 문제는 없어 보인다. 그렇지만 뭔가 더 생산적인 일을 해야 한다는 느낌을 강하 받는다. 그건 누가 얘기하지도 않고 강요한 사람도 없지만, 모인 사람들의 분위기가 그렇게 되는 것 같다.
라인은 대기업인데도 스타트업(?)의 느낌을 살려 팀 단위로 일을 하고 코드리뷰를 한다고 한다. 코드리뷰를 잘 하고 못하고의 문제가 아니라 한다는 게 권장되는 문화가 매우 부럽다.
문서화의 중요성
이건 나도 100% 동감하는 부분인데, 문서화는 정말 중요하다.
라인에서도 역시 문서화를 중요하게 생각하는데 내가 생각한거 보다 더 많은 문서를 작성하는 거 같다. 팀이 모든 문서를 보고 공유를 한다고 하고 팀의 누구와 얘기해도 내용이 공유가 된다고 하니, 이것 또한 부러울 따름이다.
그렇다고 회사에서 문서화를 안하느냐 그런건 아니다. 업무 진행과 이슈에 관련된 문서는 다른 회사들도 마찬가지로 잘 적는 편인데, 기술 문서에 대한 부분이 조금 부족한 것 같다. 나는 그런 문서가 중요하다고 생각해서 잘 적는 편이지만 공유가 된다기 보다는 그냥 참고용 정도로만 취급하는 정도라 중요도에 있어서는 크지는 않다.
스스로 해야 할 일을 찾는 자율성
이건 우리 회사도 크게 다르지는 않지만, 방향이 좀 다르다.
라인은 해야 할 일을 찾아서 하지만 팀원들과 함께 부족한 부분을 찾는다던가 지속적으로 대화하고 공유하는 형태이다.
우리 회사는 도달해야 하는 목표치를 정해 놓고 그 안에서 자율적으로 움직인다. 협업이라기 보다는 이슈가 생기지 않게 잘 하고 보고를 하는 형태라 조금 그 느낌이 다르게 느껴진다.
다만, 개발쪽으로는 최대한 많은 자율성을 보장해 주므로 필요하다면 얼마든지 원하는 기술과 할 일을 찾아서 할 수 있긴 하다.
책에 나온 사람들은 뭔가 대단한걸 했던 사람들이고 당연히 이런 사람들이 LINE에서 일한다는 어떤 예시를 든거 같다. 그건 어떻게 보면 좋은 조직의 문화가 좋은 사람들을 모이게 한다는 뜻이기도 할 것이다. 우리 회사도 그런 문화를 가진 회사로 발전했으면 좋겠고 거기에 내가 많은 참여와 기여를 할 수 있었으면 한다.
이 글은 취업 활동을 위한 인터뷰가 아닌 재직 중에 인터뷰를 진행했던 리뷰를 적으려 한다. 퇴사가 예정되어 있어서 퇴사 예정 기간 전에 인터뷰 한 것마저 포함되지 않는다. 즉 취업활동을 위한 인터뷰를 제외한 순수하게 인터뷰를 진행한 리뷰이며, 인터뷰에 성공해서 입사를 제안 받았던 아니면 탈락 했던 간에 중요한건 인터뷰를 진행한 이후에 회사 생활에는 큰 문제가 없었던 것들만 적어 보려 한다.
특히 어떤 회사 재직중에 이런 인터뷰를 진행했는지, 또 몇 년도에 진행했는지는 밝히지 않는다. 또 회사에 합격했는지 안했는지가 중요한 리뷰가 아닌 인터뷰를 진행하면서 어떤 걸 느꼈는지에 대한 내용 위주로 작성한다.
#1 외국계 인터넷 온라인 쇼핑 회사
링크드인에서 종종 헤드헌터들의 친구 요청이 많고, 외국 사람들의 친구 요청도 많은데 그런 사람들은 대부분 개인적으로 인터뷰 제안을 하는 사람들은 아니고 그냥 Job position이 있는데 관심 있으면 지원해 볼래? 아님 말고 식의 사람들이다. 이런 친구들이 이렇게 찌라시(?)를 뿌리는 수준이라 친구 추가는 하지만 이후 별 다른 활동이 없으면 친구 삭제를 하는 식으로 인맥 관리를 하고 있고 지금도 그렇게 하고 있다.
그런 와중에 외국계 회사에서 면접 제안을 해 왔는데 개인 메일로 왔고 포지션 및 제안 내용도 꽤나 구체적이었다. 다음달에 오프라인 인터뷰를 위해 한국에서 진행할 것이고 사전 온라인 코딩 테스트도 진행하기 때문에 관심있으면 지원해달라는 식이어서 "한번 해볼까?" 라는 생각이 들게 됐다.
그래서 조금 적극적으로 해보기 위해 이력서를 전달했고 온라인으로 진행하는 코딩 테스트는 언제 하는게 좋을지에 대해서도 물어봐서 일부러 오후 반차를 내고 평일 오후 시간에 하겠다고 회신을 했다.
여기서 온라인 코딩 테스트는 이 회사가 처음이었는데, 그 전에 다른 회사에서 오프라인으로 진행한 인터뷰는 손코딩 알고리즘 테스트나 사전 알고리즘 문제 까지는 풀어봤지만 온라인에서 진행한건 신선했기 때문에 어떻게 진행됐는지 아직도 생생하게 기억이 난다.
우선 온라인 코딩 테스트 링크를 클릭하니 보통 알고리즘 문제 푸는 사이트들과 방식이 좀 달랐다.
문제 설명에 맞게 코드를 작성하는 건 당연한데 실행 방법, 제약 조건 등 프로그램 명세에 대한 간단한 설명을 추가로 작성해야 하는 점
이 코드를 테스트하기 위한 테스트 방법에 대한 설명과 그 코드를 별도로 작성해야 하는 점 (보통 온라인 코딩 테스트는 문제를 풀기 위한 코딩만 하면 시스템이 테스트를 자동을 해 주고 pass, fail 결과를 자동으로 알려줌)
문제를 풀기 위한 시간 제한이 있었고 그 화면이 녹화가 되면서 진행된 점
이때만 해도 테스트 코드를 작성하는 것 까지는 했는데 이걸 테스트 하는 방법에 대한 걸 설명하는게 너무 어색해서 "Just run" 이라고만 적었던 게 기억이 난다. 나중에 생각해 봤을 때 "이 문제를 테스트하는 함수를 호출할 때 클래스 객체를 생성하고 함수를 호출할 때 파라미터 값으로 int 값을 넣어야 한다" 이렇게 적었어야 하는게 맞지 않았나 하는 생각이 든다.
그러니까 여태까지 테스트 코드를 작성할 줄만 알았지 테스트 코드를 어떻게 실행해야 하는지에 대한 설명을 해본 적이 없기 때문에 당황했던 것이다.
그리고 화면 녹화를 했다는 건 제 시간에 결과를 낸 코드를 작성하는게 중요한게 아니라 어떤 과정을 거쳐서 코드를 작성했고 그 설명을 어떻게 써 내려갔는지를 보고 싶어한다는 것도 알았다.
비록 온라인 코딩 테스트는 코드 자체는 맞게 써서 제출은 했지만 통과하지는 못했다. 우리나라에서 했던 방식과는 달랐던 것에 당황을 했고 이때 이후로 코딩 테스트를 평가하는 것에 대한 많은 생각을 하게 됐다. 단순히 어떤 지식을 아는지 모르는지에 대한 테스트가 아니라 설명을 해 나가는 방식의 코딩 테스트가 좋은 평가를 하는 방법이라는 걸 이 회사의 코딩 테스트를 해보고 나서 알게 되었다.
결과적으로 이 회사에서 진행했던 온라인 코딩 테스트는 좋은 경험이었다고 볼 수 있었는데, 나중에 내가 인터뷰를 진행하는 사람으로 참여해서 사전 코딩 테스트 문제를 내고 코드 리뷰를 하는 방식으로 발전 시켰고 좋은 결과를 얻었기 때문이다.
QA 분야로만 10년 넘게 활동하면서 여러 대기업 프로젝트 및 서비스 프로젝트에 대한 QA를 주도적으로 진행하신 분과 인터뷰를 했다. 다른 부서의 다른 분야다 보니 내가 알고 있는 부분에서의 교차 검증 까지는 어렵거나 모를거라 판단해서 쉬운 질문부터 하기 시작해 봤다.
"수십개의 프로젝트 QA를 진행하시면서 Unit test를 잘 진행하는 개발자들이 얼마나 있나요?"
라고 물어봤는데 대답이 매우 현실적이라고 해야 하나 충격적이라고 해야 하나 그런 경우는 거의 없다고 했다.
없는 건 둘째치고 해야 한다고 가이드를 주고 교육도 하는데도 기능 구현하기 바빠서 결국 하는둥 마는둥 하다가 안하는 케이스가 많다는 것이다. 그런데 QA에서는 통합 테스트 과정에서 꼭 필하기도 하고 각종 인증 시험에도 결과 보고서에 필요한 프로세스이기도 하니 최소 10개 아니면 1개 만이라도 만들어서 로그인 기능이라도 테스트 코드 통과시키게 한다고 한다. 더 놀라운건 개발자들이 알아서 하는게 아니라 QA팀에서 시켜서 한다는 것이다.
또 다른 질문을 했다.
"그건 단기 프로젝트 수주 받아서 진행한거라 일정 문제 때문에 그럴 수 있다고 보는데, XXXXX 회사에도 다녀 보셨으니 서비스나 솔루션 제품, 앱에 대한 QA는 다르지 않던가요?"
에 대한 질문도 마찬가지였다고 한다. 즉 개발문화가 그런 걸 하는 문화라면 QA가 매끄럽게 진행이 될텐데 아무것도 모르고 안하는 개발 문화라면 가이드 주고 교육시키는 것 부터가 일이라고 하니 좋은 개발문화가 있는 회사를 만나는 것도 쉽지 않겠구나 하는 생각이 많이 들게 되었다.
이 얘기를 듣고 인터넷 커뮤니티 등에서 주장하고 있는 unit test에 대한 내용이 현실에서는 아직까지는 많이 확산되지 않나 싶은 생각이 들게 됐다. 물론 최근에 좋은 개발문화를 가진 스타트업이나 다른 회사들은 개발자들이 자발적으로 하면서 진행하는 경우도 있긴 하겠지만 QA만 10년 넘게 전문적으로 하시고 대기업 부터 스타트업까지 수십개의 프로젝트를 진행하시는 분에게 얘기를 직접 들어보니 아직까지 좋은 개발문화가 자리잡기까지는 쉽지 않겠구나 라는 생각이 많이 들었다.
우리 회사에 아직 QA 프로세스가 있는 건 아니고, 일부 솔루션 사업부쪽에서는 QA를 자체적으로 진행하고 있기는 하지만 여전히 유닛 테스트나 DevOps는 일부 과제에서 제한적으로 진행하다 보니 꼭 남탓할 일은 아니라고 본다.
그래도 할 생각이 있어서 하는 것과 해야 하니까 하는 것과는 큰 차이가 있고 그게 개발 문화라고 생각하기 때문에 나도 그 분과 인터뷰 후에 내 스스로도 반성하는 계기가 되지 않았나 싶다.
나 역시도 연구과제 여러개 진행하고 있어서 하면 좋은 것들에 대한 일이 진행이 되지 않고 있는 데 그 중에 하나가 DevOps여서 만약 이 분이 회사에 오게 된다면 우리팀 DevOps를 진행하는데 탄력을 받지 않을까 생각해 본다.
요 두 개의 key를 가진 resource로 background color가 변경 되었는데
Windows8 이후에는 이게 동작이 안되기 때문에 다른 방법을 써야 한다는 것이다.
내가 진행하고 있는 공기업 과제의 개발 환경은 아래와 같다.
Windows 10, 10.0.18362
.NET Core 3.0.100-preview7-012821
이 환경에서 WPF 앱을 만들어서 진행하고 있는데
Combobox 역시 background 변경을 위해 실행해 보면 색이 변하지 않는 동일한 현상이 일어나는 걸 알 수 있다.
아마 Windows8 이상 부터는 WPF에서 지원되지 않게 SystemColors key 값을 바꿔 놓은 듯 하다.
따라서 ComboboxItem style과 template을 새로 정의한 후에 SolidBrushColor의 값들을 ComboboxItem의 key 값으로 변경해서 적용해야 한다.
적용 방법은 처음에 링크에 잘 나와 있다. 그리고 조금만 검색해서 찾아보면 결국 처음의 저 링크의 해결 방법으로 모인다는 사실을 알게 된다. 심지어 "wpf combobox background" 까지만 쳐도 "wpf combobox background color not working"으로 자동완성 되는 문장까지 볼 수 있다.
해결할 수는 있는데 쉽게 해결할 수 있는 문제는 아니다. style과 template을 다시 지정해 줘야 하니까. 이왕 시작한 .net core multi platform 작업에 이 부분을 추가해서 다시 예전처럼 SystemColors 값으로 쉽게 바꿀 수 있게 해줬으면 좋겠다. To microsoft developers.
Surface detection allows ARCore to place digital objects on various surface heights, to render different objects at different sizes and positions, and to create more realistic AR experiences in general.
Pose is the position and orientation of any object in relation to the world around it. Everything has its own unique pose: from your mobile device to the augmented 3D asset that you see on your display.
Hit-testing lets you establish a pose for virtual objects and is the next step in the ARCore user process after feature-tracking (finding stationary feature points that inform the environmental understanding of the device) and plane-finding (the smartphone-specific process by which ARCore determines where horizontal surfaces are in your environment).
Light estimation is a process that allows the phone to estimate the environment's current lighting conditions. ARCore is able to detect objects in suboptimal light and map a room successfully, but it’s important to note that there is a limit to how low the light can be for the experience to function.
Occlusion is when one 3D object blocks another 3D object. Currently this is only possible with digital objects, and AR objects cannot be occluded by a real world object. For example, in an AR game the digital object would not be able to behind a real couch in the real world.
Assets in multi-plane detection are scaled appropriately in relationship to the established planes, though only need to be placed on them (via anchor points) when it causes them to function like their real-world counterparts.
Immersion can be broken by users interacting with AR objects as if they were physically real. Framing can be used to combat these immersion-breaking interactions.
Spatial mapping is the ability to create a 3D map of the environment and helps establish where assets can be placed.
Feature points are stationary and are used to further environmental understanding and place planes in an experience. ARCore assumes planes are unmoving, so it is inadvisable to attempt to anchor a digital object to a real world object that is in motion. In general, it’s best not to place an object until the room has been sufficiently mapped and static surfaces have been recognized and designated as feature points.
Google's Poly is a 3D asset library that lets you quickly find 3D objects and scenes for use in your apps, and it was built from the ground up with AR and VR development in mind.
You can use VR creation tools from Google like Tilt Brush and Blocks to build 3D assets and store them on Poly for use in AR apps.
Poly allows you to browse, search, view and download thousands of objects and scenes for your project.
Poly is available on desktop, mobile, and in VR.
Poly can also create gifs and publish creations to the web.
The Poly API provides read access to assets in the Poly library.
With the Poly API, users can access Google’s growing collection of Creative Commons 3D assets and interact directly with Poly to search, download, and import objects dynamically across desktop, mobile, virtual reality, and augmented reality.
Creators can find all types of assets for applications and easily search for remixable, free assets licensed under a Creative Commons license by keyword, category, format, popularity or date uploaded.
Creators can filter by model complexity, or create a personalized experience by letting users sign into the app with their Google account to access any assets they’ve uploaded or liked on Poly.
Sceneform for easier AR content creation
Sceneform SDK is a high-level 3D framework that makes it easy for users to build AR apps in Java. It offers a new library for Android that enables the rapid creation and integration of AR experiences, and combines ARCore with a powerful physically-based 3D renderer. It includes a runtime API for working with graphics and rendering, and a plugin to help you import, preview, and tweak the look and feel of your assets directly in Android Studio.
Sceneform is highly optimized for mobile. Java developers can now build immersive, 3D apps without having to learn complicated APIs like OpenGL. They can use it to build AR apps from scratch as well as add AR features to existing ones.
What follows is a walkthrough of how to use Sceneform. It's more technically advanced than most of the other content in this course--it's very helpful to have a little background in Java to fully appreciate how you might use it yourself--but we've included it so that aspiring creators can start to learn how to use Sceneform to make their own AR content.
Using Ploy and Unity to create ARCore assets
Unity is a cross-platform game engine and development environment for both 3D and 2D interactive applications. It has a variety of tools, from the simple to the professionally complex, to allow for the streamlined creation of 3D objects and environments.
Poly toolkit for Unity is a plugin that allows you to import assets from Poly into Unity at edit time and at runtime.
Edit-time means manually downloading assets from Poly and importing them into your app's project while you are creating your app or experience.
Runtime means downloading assets from Poly when your app is running. This allows your app to leverage Poly's ever-expanding library of assets.
As we’ve covered, anchors are the mechanism by which you can attach virtual content to a trackable real-world point.
Building on this concept and supported by the cloud, Cloud Anchors are a cross-platform feature that allow both iOS and Android device users to share the same AR experience despite using different underlying AR technologies. Where traditionally anchors have been isolated to one device—or one augmented reality—these anchors can be shared by multiple different devices simultaneously.
This makes AR possible for groups of people rather than just individuals, allowing for shared, collaborative experiences like redecorating your home, playing games and making art in 3D space together.
ARCore can be used to create dynamic experiences for businesses, nonprofits, healthcare, schools, and more.
ARCore’s strengths are its phone-based spatial mapping capabilities and addressable user base. Approximately 85% of phones around the world run on the Android operating system.
At of the beginning of 2018, ARCore is already available on 100 million Android-powered smartphones and that number continues growing. ARCore requires a lot of processing power, so not all older Android models have the necessary specifications yet. ARCore is also available in China.
Limitations to consider with contemporary AR technology include: low-light environments, a lack of featured surfaces, and the availability of powerful mobile processors in new phones.
User experience (UX) and user interface (UI) to consider
User interface (UI) and user experience (UX) are two complementary fields of product design. They have a lot in common, but generally speaking UX is the more technical of the two. UX is the process and underlying framework of enhancing user flow to create products with high usability and accessibility for end users while UI is more akin to graphic design and focuses on the front-end design elements of the interface.
At the most basic level, UI is the visuals of your app and everything that a user interacts with and UX is the process that supports the user's journey and interactions.
Before creating an AR app it is important to deeply consider the design so that you are utilizing the minimal space of a phone display in the best possible way. By creating the most intuitive UX/UI for your app, you give it the best chance to succeed with users.
When using an AR app your smartphone’s screen will mostly be filled with input from the camera, showing the live feed of the real world. It’s important to not overly clutter the screen with buttons or other elements that are nonessential and might be confusing for users.
For example, the AR Stickers app displays placeable 3D objects at the top of the screen, so you can drag and drop a character into your scene. The app also allows you to hide the objects menu by clicking the “ ^ “ button. This lets the user concentrate on the character without the additional noise of the objects menu.
If your app demands a lot of features, make sure the icons are displayed at the corners of the screen and don’t take up the crucial real estate in the middle of the screen. This is usually where most of the interaction with AR objects take place. Giving users the option to hide the menu is also a great feature to ensure immersion.
It is important not to crowd the screen with too much information at once. However, with AR you’re not restricted to just the screen when it comes to UI menus. One option that allows creators to incorporate a lot of information is to use the environment as a menu, letting users interact with items or display information tagged to specific features, such as buildings.
Basic AR interaction options
The following list offers some of the major examples of the types of interaction options AR app creators can give users. Treat this as a starting point rather than a complete list; mobile AR is young, and creators are discovering new interaction mechanics all the time.
Drag and Drop: This feature lets users drag and drop objects from a menu of 3D digital assets “onto” the screen to place them on a real world surface (that has been spatially mapped by ARCore).
Voice: Voice is quickly emerging as a powerful interaction tool that creators can build into AR apps. Building in pre-programmed voice commands allows users to execute specific actions within the AR app. This is often best achieved by embedding the Google Assistant SDK to add voice-enabled smart interaction
Tap: With the tap mechanic, users can place objects in the real world by tapping on the screen. ARCore uses raycasting (the use of ray-to-surface as an intersection test), and projects a ray to help estimate where the AR object should be placed in order to appear in the real-world surface in a believable way. Another way to use tap is as a mechanic to interact with a digital object that is already placed in the scene. For example, maybe the app allows users to animate a 3D object when users tap on it.
Pinch and Zoom: Pinch and zoom lets users enlarge or scale down a 3D object—or use the interaction in creative ways to build a game or user experience. For example, this could be used to pull back the string of a bow in a bow-and-arrow target game.
Slide: Users can interact with 3D objects through sliding, which translates (or moves) objects in-scene, or use it as a game mechanic. For example, say you are creating an AR paper toss game. You could enable a slide interaction to let users project or throw papers into a trash can.
Tilt: Using the accelerometer and gyroscope, a tilt of the phone can also be used as an input for creative interactions. An easy example would be to make a “steering wheel” mechanic for a racing tabletop AR game.
Think like a user
User flow is the journey of your app's users and how a person will engage, step by step, with your AR experience.
Planning your user flow needs to take into account the scene, the user interactions, any audio cues, and the final user actions.
A user flow can be created with simple sketches and panels all collected into one cohesive diagram.
UX and UI are complementary fields of product design, and generally speaking UX is the more technical of the two.
When considering UX/UI, one good rule of thumb to remember with AR is to avoid cluttering the screen with too many buttons or elements that might be confusing to users.
Choosing to use cartoonish designs or lighting can actually make the experience feel more realistic to the user, as opposed to photorealistic assets that fail to meet our expectations when they don't blend in perfectly with the real world.
Users might try to “break” your experience by deliberately disregarding your carefully planned user flow, but your resources are better spent on improving your app’s usability rather than trying to prevent bad actors.
Next steps on the AR journey
Advanced 3D design tools like Maya, Zbrush, Blender, and 3ds Max are powerful professional tools.
Google’s Poly can be a good starting resource for building your first ARCore experience.
Poly by Google is a repository of 3D assets that can be quickly downloaded and used in your ARCore experience.
The recommended guide for your AR experience is a design document that contains all of the 3D assets, sounds, and other design ideas for your team to implement.
You may need to hire advanced personnel to help you build your experience, such as: 3D artists, texture designers, level designers, sound designers, or other professionals.
Accelerometer: measures acceleration, which is change in speed divided by time. Simply put, it’s the measure of change in velocity. Acceleration forces can be static/continuous—like gravity—or dynamic, such as movement or vibrations.
Gyroscope: measures and/or maintains orientation and angular velocity. When you change the rotation of your phone while using an AR experience, the gyroscope measures that rotation and ARCore ensures that the digital assets respond correctly.
Phone Camera: with mobile AR, your phone camera supplies a live feed of the surrounding real world upon which AR content is overlaid. In addition to the camera itself, ARCore-capable phones like the Google Pixel rely on complementary technologies like machine learning, complex image processing, and computer vision to produce high-quality images and spatial maps for mobile AR.
Enables: location-based AR
Magnetometer: gives smartphones a simple orientation related to the Earth's magnetic field. Because of the magnetometer, your phone always knows which direction is North, allowing it to auto-rotate digital maps depending on your physical orientation. This device is key to location-based AR apps.
GPS: a global navigation satellite system that provides geolocation and time information to a GPS receiver, like in your smartphone. For ARCore-capable smartphones, this device helps enable location-based AR apps.
Enables: view of real world with AR
Display: the display on your smartphone is important for crisp imagery and displaying 3D rendered assets. For instance, Google Pixel XL’s display specification is 5.5" AMOLED QHD (2560 x 1440) 534ppi display, which means that the phone can display 534 pixels per inch—making for rich, vivid images.
In order to seem real, an AR object has to act like its equivalent in the real world. Immersion is the sense that digital objects belong in the real world.
Breaking immersion means that the sense of realism has been broken; in AR this is usually by an object behaving in a way that does not match our expectations.
Placing is when the tracking of a digital object is fixed, or anchored, to a certain point in the real world.
Scaling is when a placed AR object changes size and/or dimension relative to the AR device's position. For example, when a user moves away or towards an AR object, it feels like the object is getting larger or smaller depending on the distance of the phone in relation to the object. AR objects further away from the phone look smaller and objects that are closer look larger. This should mimic the depth perception of human eyes.
Occlusion occurs when one object blocks another object from view.
AR software and hardware need to maintain “context awareness” by tracking the physical objects in any given space and understanding their relationships to each other -- i.e. which ones are taller, shorter, further away, etc.
The magic of AR: detecting, sensing, and understanding
There are two basic ways to track the position and orientation of a device or user: outside-in tracking and inside-out tracking.
Outside-in tracking uses external cameras or sensors to detect motion and track positioning. This method offers more precision tracking, but a drawback is the external sensors lower the portability.
Inside-out tracking uses cameras or sensors located within the device itself to track its position in the real world space. This method requires more hardware in the AR device, but offers more portability.
On the AR headset side, the Microsoft HoloLens is a device that uses inside-out tracking. On the VR headset side, the HTC Vive is a device that uses outside-in tracking.
On the AR mobile side, the Google Pixel is a smartphone that uses inside-out tracking for AR.
Inside ARCore: the building blocks of augumented reality
ARCore integrates virtual content with the real world as seen through your phone's camera and shown on your phone's display with technologies like motion tracking, environmental understanding, and light estimation.
Motion tracking uses your phone's camera, internal gyroscope, and accelerometer to estimate its pose in 3D space in real time.
Environmental understanding is the process by which ARCore “recognizes” objects in your environment and uses that information to properly place and orient digital objects. This allows the phone to detect the size and location of flat horizontal surfaces like the ground or a coffee table.
Light estimation in ARCore is a process that uses the phone’s cameras to determine how to realistically match the lighting of digital objects to the real world’s lighting, making them more believable within the augmented scene.
Feature points are visually distinct features in your environment, like the edge of a chair, a light switch on a wall, the corner of a rug, or anything else that is likely to stay visible and consistently placed in your environment.
Concurrent odometry and mapping (COM) is a motion tracking process for ARCore, and tracks the smartphone’s location in relation to its surrounding world.
Plane finding is the smartphone-specific process by which ARCore determines where surfaces are in your environment and uses those surfaces to place and orient digital objects. ARCore looks for clusters of feature points that appear to lie on common horizontal or vertical surfaces, like tables or walls, and makes these surfaces available to your app as planes. ARCore can also determine each plane's boundary and make that information available to your app. You can use this information to place virtual objects resting on flat surfaces.
Anchors “hold” the objects in their specified location after a user has placed them.
Motion tracking is not perfect. As you walk around, error, referred to as drift, may accumulate, and the device's pose may not reflect where you actually are. Anchors allow the underlying system to correct that error by indicating which points are important.
The current challenges facing AR today
Currently AR has a lack of user interface metaphors, meaning that a commonly understood method or language of human interaction has not been established.
The purpose of the interface metaphor is to give the user instantaneous knowledge about how to interact with the user interface. An example is a QWERTY keyboard or a computer mouse.
The details of what makes AR challenging from a technical standpoint are complex, but three influential factors are power, heat, and size.
AR requires high processing power, batteries generate heat, and a current challenge is fitting all the necessary components into a small enough form factor to wear on your face comfortably for extended periods of time.
Not everything in AR has to be 3D, but the vast majority of assets, applications, and experiences will require at least a little 3D design.
Currently, there is a limited base of people with 3D design and interaction skills, such as professional animators, graphic designers, mechanical engineers, or video game creators. For AR to grow, the adoption of 3D design theory, skills, and language needs to become much more widespread. Later on in this course, we’ll be discussing a few programs that are helping overcome this challenge, like Sceneform or Poly API.
Computer vision is a blend of artificial intelligence and computer science that aims to enable computers (like smartphones) to visually understand the surrounding world like human vision does. This technology needs to improve in terms of object detection and segmentation to make AR processes more effective.
AR도 공부를 하다 보면 Unity 깔고 C# 코딩 부터 시작한다기 보다 optical & video 즉 computer vision을 공부한다는 느낌이 더 강하다. 마치 ML을 배우기 위해 python 먼저 코딩하는 것 보다는, math, data analysis, data modeling, data visualization 등을 이해하는게 더 중요한 것처럼.
강의 video는 완료하면 다시 볼 수 없으므로 각 주제별 summary text를 긁어서 정리를 해 볼까 한다.
This class will teach you the fundamentals of augmented reality (AR), and how to build an AR experience using ARCore. Through the four week course, you'll learn:
- How to identify different types of AR experiences
- Tools and platforms used in the AR landscape
- What makes AR feel "real"
- Popular use cases for AR
- How to create an AR use flow
- How AR experiences work
- Tools like Google Poly and Unity to build AR experiences
- Next steps to start building an AR experience using ARCore and other tools
This course will break down complex AR concepts to make them easy to understand, while also sharing expert tips and knowledge from Daydream's ARCore team. The course is great for beginners who are just getting started with AR or ARCore.
Introduction to augmented reality (AR)
What is AR?
Now that you’ve gained a basic understanding of what augmented reality is, it’s important to understand how it differs from VR.
The most obvious difference is in the hardware itself. A VR experience must be viewed in some kind of headset, whether it’s powered by a smartphone or connected to a high-end PC. VR headsets require powerful, low-latency displays capable of projecting complete digital worlds without dropping a frame. AR technology does not share this requirement. You can hold up your phone and have a headset-free AR experience any time.
Augmented reality is direct or indirect live view of a physical, real-world environment whose elements are "augmented" by computer-generated perceptual information. Virtual reality is the use of computer technology to create a simulated environment, placing the user inside an experience.
Both technologies enable us to experience computing more like we experience the real world; they make computing work more like we do in regular life-- in a 3D space. In terms of how the two technologies are used, think of it like this. VR transports you to a new experience. You don’t just get to see a place, you feel what it’s like to be there. AR brings computing into your world, letting you interact with digital objects and information in your environment.
Generally speaking, this difference makes AR a better medium for day-to-day applications, because users don’t have to shut out the world to engage with them.
Humankind’s first foray into immersive reality through a head-mounted display was the “Sword of Damocles,” created by Ivan Sutherland in 1968.
HMD is the acronym for “head-mounted display.”
The term “Augmented Reality” was coined by two Boeing researchers in 1992.
A standalone headset is a VR or AR headset that does not require external processors, memory, or power.
Through the combination of their hardware and software, many smartphones can view AR experiences that are less immersive than HMDs.
Many of the components in smartphones—gyroscopes, cameras, accelerometers, miniaturized high-resolution displays—are also necessary for AR and VR headsets.
The high demand for smartphones has driven the mass production of these components, resulting in greater hardware innovations and decreases in costs.
Project Tango was an early AR experiment from Google, utilizing a combination of custom software and hardware innovations that lead to a phone with depth-sensing cameras and powerful processors to enable high fidelity AR.
An evolution of Project Tango, ARCore is Google’s platform for building augmented reality experiences.
이건 광화문 교보문고를 들렀다가 있었던 일을 생각해 봄과 동시에 평소에 커뮤니티 사이트나 개인적인 질문 중 많은 질문 중 하나인 "책 추천 부탁"에 대한 내 생각을 좀 써보려 한다.
7월 초쯤 아내가 논문 쓸 책 참고하겠다며 광화문 교보문고에 간다길래 나도 요즘 나오는 컴퓨터 관련 책이 뭐가 있나 볼겸 갔다.
<광화문 교보문고 사진, 요즘 서점은 책만 잔뜩 있는 곳이 아니라 북까페로 인테리어가 되어 있다.
출처: 교보문고 사이트>
python, c++ 관련 책들이 있는 책장에서 못보던 책이 뭐 있나 살펴보던 중, 아무리 봐도 대학생으로 보이는 여학생 둘이 python이 낫냐 C가 낫냐 따져가면서 책을 골라보고 있었다. 사실 무슨 책을 고르는지는 관심이 없었는데 만약 학생이라면 언어를 정하고 그 중에 어떤 책이 좋냐를 고를 줄 알았는데, 골라야 하는 언어가 다양하다 보니 컴퓨터 관련 학과 학생이 맞나? 라는 궁금증이 들기 시작했다.
그래서 용기를 내서 여러 프로그래밍 언어 책을 고르는 이유를 물어봤는데 컴퓨터 전공 학생들은 아니었고 정보통신? 정보보호? 과라고 해서 프로그래밍을 배워서 해야 하는 과제가 있어서 책 보러 왔다고 했다. 그런데 내가 나이가 좀 많이 들어 보여서 그런지 이 여학생들이 나를 보자마자 한다는 얘기가 "교수님이세요?" 라고 하더라. 서점에서 무슨 책 보는지 물어봤을 뿐인데, 교수님으로 보였나 보다.
그래서 개발자고 학생들 멘토링 해주는 일도 하고 있다고 하니까 C언어 중에 좋은 책을 추천해 달라고 했다.
사실 그 학생들에게는 아무 책이나 추천해 줘도 상관 없다고 생각한다.
뭐라고요? 아무 책이나 추천해 준다고요? 왜 그런 성의없는 짓을 하죠? 라고 생각하는 사람도 있을 것이다. 왜냐하면 그 학생들에게는 좋은 책이 중요한게 아니라 어떤 책을 골랐던 공부를 하는데 얼마나 시간을 투자해서 의미있는 시간을 보냈고, 그 책을 통해서 얻은 것이 무엇이냐가 더 중요하기 때문이다.
물론 추천해 준 책은 시중에서 잘 나간다는 책 몇 권을 골라주기는 했다. 그런데 그걸 골라가지는 않더라. 왜냐하면 자신들도 더 판단해 보고 싶었기 때문이겠지. 이미 자신들도 알고 있는 것이다. 남이 추천해준 책이 좋을 수 있지만 내가 좋아보이는 책을 고르는게 더 맞다는 생각이겠지.
여기서 부터 나의 얘기를 시작해 보려 한다.
나는 누군가에게 조언을 해주는 일을 하고 있기도 하고, 좋은 책을 추천해 달라고 하면 알려 줄 수도 있는 선배 개발자의 위치에 있기도 하다.
그런데 나는 책을 추천해 달라고 하면 추천해 주지 않는다는 얘기부터 한다. 그리고 아래와 같은 사족을 단다.
책을 딱 한권만 읽고 말거면 추천해 줄 수 있지만, 같은 주제로 다양한 책들이 너무 많기 때문에 추천이 어렵다.
또 나한테 좋은 책과 너한테 좋은 책은 상대적인 기준이 다를 수 있으므로 섣불리 추천해 주지 않는다.
그리고 책 만족도에 있어서도 추천해 준 책을 보고 후회를 하던 자신이 고른 책을 보고 후회하던 후회의 강도가 같을 것 같지만, 남이 추천해 준 책을 보고 후회를 한다면 후회를 넘어 추천해 준 사람에 대한 근본없는 분노를 느끼기 충분하기 때문에 추천해 주지 않는다.
그리고 더 나아가서 대뜸 책 추천을 해달라고 서슴없이 물어보는 친구들이 있는데, 그 친구들이 뭘 하고 있는지를 좀 살펴보고 나서 드는 생각은 조금 더 관심을 가지고 조사해 봤으면 좋겠다는 생각이다.
왜 그러냐 하면, 자신이 이 분야에 관심이 있고 공부를 하고 싶고 잘 알아서 지식을 쌓거나 회사 취업을 위해 준비하거나 업무를 더 잘하려는 마음 때문에 책을 보고 싶어 할 것인데 뭔가 좀 찾아보고 본인이 판단해 봐도 될 것을 남의 판단에 의지해 묻어가려는 심리가 있어 보이기 때문에 그렇다.
정말 아무것도 몰라서 가르침을 받고 싶은 심정 또한 이해가 가긴 하지만, 자신도 뭔가 알아보고 난 후에 책을 추천해 줄 사람과 "communication"이라는게 됐으면 좋겠는데 대충 흘러가는 식이
XXX 책 추천해 주세요
YYY 책 추천 드립니다.
감사합니다.
이렇다 보니 질문하는 사람도 뭔가 검증 절차도 없이 넙죽 받아먹기만 하고, 대답해 주는 사람도 자신의 관점에서 별다른 이유 없이 추천해 주는 식이다 보니 뭔가 모양새가 좋지 않다는 것도 내 생각이다.
책 추천에 대한 질문과 더불어 책을 추천받고 싶은 이유, 내가 어떤 분야에 뭔가를 하고 있다는 내용, 그래서 뭘 더 하고 싶은지에 대한 내용이 있으면 "communication"을 위한 시작이 좋다고 보고 싶다. 당장 책 추천 질문에 자신의 상태와 책을 보고 싶은 이유에 대해 장황하게 쓰는게 귀찮고 어렵다면 미리 자신의 블로그나 github 관련 페이지를 준비하고 링크를 걸어 주는 정도로만 해도 충분할 것이다.
이렇게 해서 질문을 해야 추천해 줄 사람도 그 사람의 history를 파악하고 책을 추천해 줄 수 있을 것이고, 책 추천해줄 사람이 조금 더 질문을 하는 식으로 해서 정말 필요한 공부가 무엇인지도 얘기해 줄 수 있다. 비록 책 추천이 아니더라도 더 좋은 얘기를 들을 수 있는 확률이 높다는 얘기다.
하지만 정 그렇게 준비하는게 귀찮고 그냥 책만 추천 받아 보고 싶으면 자신보다 더 잘알지 잘모를지도 모를 사람들에게 질문하고 답변 해 주면 감사하다고 하며 의지하지 말고, 본인의 검색 능력과 인터넷 글의 평점, 후기 등을 잘 읽고 판단해서 스스로 책을 고르는 주체적인 사람이 되어 보도록 하자.
--- 추가 내용
사실 책 추천의 수준이 python, android, javascript 등 특정 프로그래밍 언어 공부를 할 수 있는 책이다 보니 추천의 어려움을 넘어서 추천을 해 주고 싶지 않다는 생각이 더 많이 든다. 이런 책은 수십권 아니 수백권이나 되기 때문에 정말 자신에게 맞는 책을 보고 열심히 공부한다면 좋은 책을 골랐던 아니던 그 차이가 크게 없을 것이라는게 나의 생각이다.
혹시 그럴수도 있다. 한가지 주제를 정해서 추천해 달라고 했을 때 유일하게 추천(?) 수준이 아니라 볼 책이 그 책 밖에 없을 때. 과연 그런책이 존재하기는 할까 싶기도 할 것이다. 그런데 그런 책이 존재할까? 놀랍게도 있다.
자 만약 "프로그래밍이라는 행위에 대한 고찰과 그 프로그래머의 심리에 대해 나와 있는 책을 추천해 주세요" 라고 한다면 아마 아래 소개한 책이 유일할 것이다.
사실 책을 자주 많이 읽는 편이다. 그렇다고 해서 책 읽는 시간이 많은 건 아니고 출퇴근 시간이 조금 긴 편이다 보니 출퇴근 시간에만 책을 읽는다. 그 외에 시간에는 책 읽을 생각 보다는 코딩, 멘토링, 커뮤니티 활동 등의 시간을 써야 하기 때문에 책은 딱 출퇴근 시간에만 보게 된다.
어쨌든 여러 책을 많이 보다 보니 이런 것도 기록에 남겨두면 좋을 것 같아서 내 리뷰 블로그에 작년에 세 권 정도 간단한 리뷰를 썼는데, 실제 리뷰 쓴 책 보다는 훨씬 많은 책을 읽었기에 기록하고 공유하기 위해 이제 부터는 개발 블로그에다가 좀 제대로 써볼 생각이다.
존 손메즈 아저씨의 전작 <소프트 스킬> 보다 훨씬 더 책이 잘 나온 듯 하다. 왜냐하면 소프트 스킬의 경우 보기 싫었던 내용이 있었는데 헬스하는 내용, 부동산 내용 등 쓸데없다고 생각되는 내용들이 있었기 때문이다. 그런데 이번 커리어 스킬에는 그런 내용은 없다. 있긴 있는데 간단하게 언급할 뿐이다. 그 책에 이런 내용은 부적절하지 않냐는 민원이 제기되서 이번 커리어 스킬에는 안넣은 것일수도 있다는 느낌도 든다.
책 내용은 전반적으로 꽤 훌륭하다. 특히 이 분야에 아무것도 모르는 비전공자나 신입들이 보기에 좋은 내용들로 구성되어 있고 취업, 개발, 인간관계, 돈 버는 방법 등 여러가지 내용들을 총 망라했기 때문에 보면 좋을 듯 하다.
그리고 현업에 있는 사람들도 이 책을 보면 뭔가 얻는 내용들도 많을 것이다. 내 생각에는 가르치면서 배운다는 원칙을 이 책을 읽어서 알게 된것 뿐 아니라 실제로 실천도 해보면 좋다는 의견이다.
책 부록에는 사실 외국 개발 환경이 국내와는 안맞는게 있을 수 있기 때문에 국내 개발자들 인터뷰한 내용을 넣은 것 같은데, 첫번째 김요한 개발자를 제외한 뒤 세 개발자들의 내용은 취업 성공기에 한정되어 있어서 좀 다양하게 넣었으면 어땠을까 싶다.
내가 멘토링 해주는 사람들에게 이 책이 나오기 전에는 <프로그래머의 길, 멘토에게 묻다>를 추천했는데, 이번 커리어 스킬도 추천 책에 넣을 만 한듯 하다. 아니, 가장 추천하고 싶은 책이 될 거 같다.
이제 마지막 회사 그러니까 지금 다니고 있는 회사 버넥트에 대한 얘기이다. 지금 회사는 내가 지원한 것도 아니고 헤드헌터를 통한 것도 아니었고 지인이 알려준 것도 아니었다.
지금 글을 쓰고 있는 시점에서 대략 2년 전 1년간 운영중이던 C# 온라인 프로그래밍 강의를 할 때가 있었다. 온라인으로 코드 작성하고 설명도 하고 하면서 참여한 사람들에게 질문/답변을 받는 그런 모임이었고 거기서 여러 사람들을 많이 만나고 좋은 인연이 된 분들도 몇 있었다.
그 인연이 된 사람 중에 하나가 지금 내 옆자리에서 같이 개발을 하고 있는 사람이다. 어느날 내 온라인 강의에 참여하고 싶다고 해서 몇 번 들었던 사람이었는데 이름만 봐서는 남자인 줄 알았다. C#에 관련된 얘기 말고도 유니티와 최적화에 대한 얘기도 했었고, 나 역시 유니티 프로젝트를 2년 넘게 한게 있어서 이것 저것 알려주고 했었다.
그러던 어느날, 그 어느날은 10번 스타트업 회사에서 연락이 1주일이 넘어 2주일 째가 다 되어가던 어느 날이기도 했다. 자신을 버넥트에서 일하는 개발자고 사람을 구하고 있는데 C#에 대해 잘 아시는 것 같고 유니티 경험이 많아서 입사 제의를 한다는 메일을 받았다. 사실 버넥트라고 하길래 사이트 들어가서 보니까 증강현실, 가상현실쪽 하는 회사였고 유니티를 다룬다고 해서 대충 그런 기술을 사용하는 회사 정도로만 봐왔는데 이렇게 메일을 받고 보니 한번 어떤 회사인지 알아봐야 겠다는 마음이 들었다. 다음날 9번 회사에서 대표님은 마지막으로 잘 생각해 보고 빨리 연락 달라고 했지만 내가 거절을 했고, 그 거절 전화를 한 몇 시간 후에 10번 회사의 대표님한테도 이러저러한 부분 때문에 안맞아서 채용을 못하겠다는 메일을 받았다. 이 때만 해도 많이 아쉽긴 했는데, 2년이 지난 지금 다시 돌이켜 보면 그 스타트업 회사는 안가는게 맞지 않았나 하는 생각도 든다. 왜냐하면 그 회사가 아직도 뭐 하고 있는지 잘 모르기 때문이다.
일단 회사 정리는 이정도로 하고 버넥트에서 제안을 해 와서 면접을 보겠다고 했고 이력서를 다시 잘 정리해서 보내줬으면 좋겠다고 해서, 유니티 프로젝트 한 거에 Leap motion하고 Kinect 써서 제스처로 하려고 한 부분을 더 추가해서 이력서를 보냈다.
며칠 후 면접 날짜가 잡혔는데 회사가 이사를 가기로 해서 이사를 간 후에 면접을 봤으면 좋겠다고 다시 회신이 왔고 알겠다고 했다. 그 이사를 가기로 한 위치는 지금 위치에 앞 건물이었고 아주 오래되고 허름한 빌딩 건물이었다. 화장실 상태도 별로 좋지도 않았고, 특별히 출입문에 벨 같은 것도 없어서 물리적인 노크를 해야 할 정도로 건물 상태가 안좋았는데 사무실 크기에 비해 사람이 적었고 이사온지 얼마 안되서 그랬는지 조금 어수선한 부분도 있었다. 바로 옆 회의실에서 면접을 진행했고, 생각보다 많은 인원이 면접에 들어왔다.
그 때만 해도 회사에 사람은 대표님을 포함해서도 총 9명이었고 면접 때 들어온 사람이 대표님과 나한테 면접 제의를 한 개발자를 포함 총 5명이 들어왔으니 전 직원의 1/2이나 들어온 셈이었다.
우선 마음에 안들었던 점 부터 얘기하면
자기소개 해보라고 한 점
특별한 코딩 테스트나 깊이 있는 기술 면접이 진행되지 않은 점
이었다.
자기소개 해보라고 할 때만 해도 인상이 썩 좋지는 않았는데 심층 기술 면접 역시 진행되지 않았다.
대신 다른 점에서 좋은 인상을 받았는데
다양한 개발자 포지션에 해당하는 서버, 유니티 클라이언트, 안드로이드 네이티브 클라이언트였고 따로 웹 개발자도 있던 점
회사에 생각보다 다양한 포지션에 사람들이 있었다는 점이었고, 각 포지션에 관련된 개발 경험을 얼마나 해봤고 하려는 의지를 물어봤다는 점
사실 작은 회사다 보니 여러 포지션과 여러 경험을 한 사람을 원한 것 같았고 안드로이드 쪽 빼고 C++이라던지 서버쪽, 클라우드 서비스, 유니티 최적화 작업 및 문제 해결 방법, 하드웨어 dependency가 있는 개발 경험 등 폭넓게 물어봤던 점
이었고 대략 내가 경험해 본 부분을 물어와서 잘 얘기를 했던 것 같다.
그리고 기술 면접이 진행 된 후에 대표님과 바로 연봉에 대한 얘기와 회사에 대한 자세한 설명 그리고 질문/답변의 시간이 충분히 주어져서 회사에 개발자들의 수준과 앞으로 해야할 일들에 대한 것도 잘 이해가 되었다.
결과적으로는 나중에 면접 끝나고 나올 때는 괜찮다는 인상으로 변했는데, AR 관련된 기술적인 연구 개발을 진행할 것이라는 점, 리모트 솔루션과 다양한 SI 과제를 진행할 것이라는 점, 내가 해줬으면 하는 역할과 내가 하고 싶어하는 일이 맞아 떨어진 점 등이었다. 연봉 협상도 함께 진행됐는데 사실 마지막에 받았던 연봉의 수준은 아니었지만, 전 회사에서 경험해 봤던 스타트업 + 기술 기반 개발 + 작고 열정이 있는 팀 + 내가 기여할 수 있는 부분이 명확했다는 점에서 만약 일을 하자고 제안을 하면 이후 면접 스케줄은 취소하고 여기서 일해야겠다는 생각을 했다.
며칠 후 채용하기로 했다는 연락을 받고 버넥트에 입사를 했으며, 이후 일정이 잡혀 있던 면접 스케줄은 취소했고 이후 면접 제의가 들어왔던 연락은 모두 거절했다.
면접도 사실 경험치인 것 같다. 자주 보다 보면 내가 원하는 회사, 바람직한 회사가 눈에 들어오게 되고, 이상한 회사 재미 없을 것 같은 회사가 저절로 필터링이 되어가는 걸 경험적으로 알 수 있게 된다.
물론 면접을 보러 다니는 과정은 피곤하지만, 그래도 내가 즐겁고 재밌게 일할 회사를 찾아 나간다는 믿음을 가지면 면접 진행하는 과정속에서 얼마든지 만족할 만한 회사를 찾아 다닐 수 있다는 게 내 생각이다.
그러면 실제 개발 실력이라는 것이 어디에서 오는 것인지 생각해 보자. 실력이라는 게 구체적으로 뭘 말하는 것인지 부터 인지해야 한다. 한자 그대로 실제 힘이라는 뜻이다. 좀 더 풀어서 말해보면 실제로 갖추고 있는 힘이나 능력 정도를 얘기하는 것일 것이다. 물리적인 힘은 눈에 보이기도 하고 어느 정도인지에 대한 감이 오는데, 소프트웨어를 개발하는데 나오는 실력이라는 건 눈에 보이지도 않을 뿐더러, 주니어 개발자가 만들던 시니어 개발자가 만들던 만들어 놓은 결과물의 차이가 크게 없어 보인다면 실력을 가늠하기가 쉽지 않은 건 사실이다.
Not 코드를 짤 줄 아는 능력, but 코드를 볼 줄 아는 능력
잘 모르는 사람은 이게 실력이라고 생각할 수 있는데 오히려 코드를 볼 줄 아는 능력이 실력일 가능성이 높다. 왜 그런가 하면 주력 언어가 있고 익숙하면 어느 정도 좋은 개발 도구의 도움을 받아 어느 정도까지는 코딩이 가능한데, 그 이상은 사실 좋은 코드가 있는 구글의 도움을 받아야 하는게 사실이다. 남의 코드를 가져와서 짜는게 실력이 아니라고들 하지만 남의 코드를 가져오기 전에 볼 줄 아는 혜안을 가졌다면 가져와서 붙여넣고 만들어 나가는 건 큰 문제가 아니라고 본다. 즉 코드를 가져오는 능력의 기본은 코드를 볼 줄 아는 능력이 뒷받침 되어야 한다는 뜻이다. 또한 코드를 볼 줄 아는 능력을 갖추고 있다는 건 문제를 해결하는 방법을 알고 있거나 찾고 있다는 뜻이기도 하다.
Not 동작하는 코드에 대한 만족, but 품질을 결정하는 요소를 실천하는 능력
역시 잘 모르는 사람은 동작하는 코드를 짤 줄만 알면 되고, 그 코드가 크게 문제가 없다면 그냥 두는 걸로 만족한다. 하지만 동작하는 코드만 짤 줄 아는 능력은 이 바닥에 들어온 사람이라면 당연히 해야 하는 걸 했을 뿐이다. 즉, 동작하는 코드를 짜지 않고는 일이던 뭐던 진행이 안되기 때문에 당연한걸 해 놓고 당연하다고 하면 어떻게 반응해야 할지 잘 모르겠다. 동작하는 코드를 짰는데, 그걸 잘 다듬고 보듬어 줘서 이후 테스트가 엄격하게 통과가 되는 원칙을 잘 지키는 코드로 만들어 나갔는지 혹은 유지보수와 기능 추가가 유연한 설계를 바탕으로 만들어진 코드였는지에 따라 소프트웨어 품질이 결정된다. 그러니까 이런 품질에 대해 고민하지 않고 만족하는 개발자는 실력이 있다고 보기 어렵다는 얘기다.
Not 회사에서 해야 하는 일에 대한 성과, but 개인이 정말 해보고 싶은 걸 해본 결과
실무 경력은 사실상 실무 경력일 뿐이다. 관련된 업무를 경험해 봤고 해 봤으니 동종 업계에서 하는 비슷한 일을 잘 이해하고 해낼 수 있는 것 정도가 전부인 것이다. 업무 프로세스 이해를 잘 해서 일을 잘 해 나가는 능력은 사실상 개발 실력하고는 크게 상관이 없다. 단, 일을 해 나가면서 조금씩 다른 구현을 시도해 보고 다른 설계를 해서 평소에 알고 있던 방법 외에 이런 저런 실험도 해 보고 하면서 진행했다면 괜찮을 수 있는데, 지금 알고 있는 범위 내에서 해야 하는 일만 했다면 그 이상을 보지 않고 일을 해 왔다는 것이고, 그건 개발 실력이 향상되지 않았다는 뜻이기도 하다. 진짜 실력을 키워 보려면 자기가 따로 해보고 싶은 쪽의 분석, 설계라는 단계를 잘 거치고 문서화를 잘 해 놔서 개발을 진행해 본 경험이 있어야 조금 더 많은 걸 볼 수 있다는 뜻이다.
그러면 정말 실력은 어디서부터 오는 것일까?
보통 회사에서 하는 일은 개발, 그러니까 기능의 구현에 많은 초점이 맞춰저 있는데 문제의 해결력 보다는 구현의 방법에 대한 스킬만 늘어날 뿐이고 누군가 문제를 주면 해결을 하지 못한다. 더 나가서 해결 못할 뿐만 아니라 그걸 자기가 해야 하는 일이 아니라고 생각한다. 그럼 누가 하느냐? 기획자가 해야 할 일이라고 한다. 기획자? 기획자는 개발을 하는 사람이 아니다. 오히려 문제를 만들어내는 사람이지 해결하는 사람이 아니다.
그런 문제를 해결하는 사람은 소프트웨어 개발자가 해야 할 일이며, 문제가 주어지면 잘 이해하고 분석해서 소프트웨어로 어떻게 만들면 좋을 지에 대한 설계는 사실 훈련을 많이 해야 한다. 단순히 코드를 잘 짜는 게 실력이 아니라는 뜻이다. 그런 분석 설계에 대한 훈련을 해서 그 문서를 도출해 내고 그걸 바탕으로 개발을 진행해 보면 다시 분석, 설계가 잘 되어 있는게 중요하다는 걸 뼈저리게 느끼게 된다. 이쯤에서 분석 설계에 들여야 하는 시간이 코딩하는 시간보다 많아야 한다는 걸 깨닫게 된다면 말 그대로 소오름이 돋을 것이다.
그래서 내가 정의하는 개발 실력이란
"주어진 혹은 해결해야 할 문제를 잘 분석하고 그걸 소프트웨어로 잘 만드려면 어떻게 해야 좋을까 하는 고민을 자신의 경험과 역량을 모두 쏟아내서 설계를 잘 해 내고 버그와 문제가 없는 코드를 작성해서 예상한 기간 내에 만족할 만한 수준의 결과를 내고 이후 추가 기능 개발 혹은 버그 수정이 잘 될 수 있도록 퀄리티 있는 소프트웨어 제품을 만들어 내서 이 소프트웨어를 쓰는 사람의 만족도를 높이고 계속 사용할 수 있는 소프트웨어로 만들기 위해 생명을 불어 넣을 수 있는(엔지니어링을 할 수 있는) 능력"
이라고 얘기하고 싶다. 아홉줄에 걸쳐서 썼는데 코딩 얘기는 한 줄 밖에 없다는 점에 주목하자.
분석은 문제 해결 능력에 가깝다. 실제 만들어 내야 하는 소프트웨어 요구에 대한 내용을 잘 이해하고 정리해서 소프트웨어로 만들어 낼 수 있도록 각을 잴 수 있는 능력이 요구된다. 이게 사실 제일 어렵다. 여기에서 실력이 가늠되기도 하는데 세상의 많은 문제를 소프트웨어 시스템으로 만들기 위한 요구를 분석해 내는 경험을 많이 하는 수 밖에 없다. 이건 경험치로 가늠할 문제지, 공부의 양으로 가늠할 수 있는 문제는 아니라고 본다.
설계는 사실상 소프트웨어를 만들기 이전에 잘 만들어 놔야 할 시스템 구성, 모듈간의 통신, 잘 정의되어야 하는 명세, 실제 데이터의 구성, 프로세스에 따라 데이터가 어떻게 흘러가는지에 대한 내용, 사용해야 하는 라이브러리나 프레임워크, 그걸 기반으로 지켜야 하는 기본적인 원칙, 테스트를 해야 하는 방법, use case, GUI 화면 인터페이스 등 소프트웨어를 개발하는데 필요한 모든 요소 대한 걸 몽땅 만들어 놔야 하는데 있다.
이 두 가지를 잘 하면 코드로 소프트웨어를 만들어 나가는 건 본인 역량 껏 해 나가면 된다. 주니어는 조금 더딜 것이고 시니어는 경험자이므로 상대적으로 빠르게 만들어나갈 수 있다. 이게 실력의 차이 아닌가? 라고 생각된다면 여태 내 글을 잘못 읽은 것이다. 주니어는 상대적으로 분석, 설계에 대한 경험이 없기 때문에 분석, 설계에 대한 결과를 잘 못 뽑아낼 가능성이 높고 잘 못 만든 설계서로 날고 기는 코드로 짜 봤자 원하는 소프트웨어의 기능을 만들어 내지 않았거나 못했다면 엄한테 힘쓴 꼴 밖에 되지 않기 때문이다. 여기서 구현에 관련된 부분 예를 들면 리액티브 프로그래밍 기법으로 짰느니 객체지향적인 방법으로 짰느니 하는 얘기를 해 봤자 아무 쓸모도 없다는 얘기다.
전공자라면 소프트웨어 공학을 배웠을 것이고 거기에서 필요한 요소가 뭔지는 다들 배웠을 것이다. 이제 코드를 잘 짜는 능력만을 개발 실력이라고 착각하지 말고 전체 소프트웨어 생명 주기를 잘 이해하고 세상 혹은 내가 만들어 낸 문제를 훌륭한 소프트웨어로 만들려면 어떻게 하면 좋을지 고민해 보자.
군대에서 사전적 의미로 총을 쏘는 사람인데 보통은 2인 1조 경계 근무에서 지시하는 사람: 사수, 지시를 받는 사람: 부사수에서 사수를 의미하는 것이다. 그래서 보통 경험이 있는 선임들이 이제 경험을 쌓아야 하는 신병과 함께 조를 이루어서 일에 대해 배우고 경험하고 또 문제 생기면 감싸줄 수 있는 사람이다 보니 일반 사무실에서도 같은 개념으로 쓰고 있다.
그런데 개발에서는 일단 사수가 있는게 좋다라는 의견에 반대하는 편이다. 물론 사수가 있다면 일도 배우고, 자신의 부족한 부분을 보고 배울 수 있는 walk-through 개념으로 받아들이면 일 하기가 한결 수월하다는 점에서는 좋을 수 있다. 그게 개발이 아닌 쪽 그러니까 군대나 기타 다른 일에는 한 조로 움직여서 동일한 업무를 수행하니까 맞는 개념인데, 개발은 같은 개발을 둘이 동일하게 하지는 않는다.
즉, 보통은 같은 프로젝트 내에서 일을 해도 큰 부분에 일부분을 맡아 개발을 하던가 아예 다른 모듈이나 파트 (예를 들면 프론트, 백엔드)를 맡게 되는 경우가 많으므로 사수한테 배운다라는 것이 잘 되지 않을 경우가 많다는 것이다.
그러면 "어차피 프로젝트는 달라도 같은 팀 내에서라면 같은 기술을 쓸 텐데 그러면 기술이라도 배울 수 있는 거 아니냐?" 라고 생각할 수 있다. 좋은 개발 문화가 정착된 회사라면 코드 리뷰나 포스트 모멘텀 발표, 페어 프로그래밍 등을 통해 공유하고 배우고 할 수 있는데, 거의 보통은 자기 할 일 바쁘다 보니 대충 찾아봐야 할 키워드 정도만 공유하고 알아서 찾아서 해야하는 일이 더 빈번하게 일어난다. 그리고 보통 사수라 불리는 사람들은 바쁜 사람들이기 때문에 신입들에게 세세한 관심이나 케어를 해주기가 힘들다.
결국 사수가 하는 역할은 같이 일 하는 사람인것 뿐인데, 조금 업무를 먼저 해본 사람 + 기술적으로 먼저 실무에 써본 사람인 것 뿐이고 삽질 방지를 위한 키워드 던져주기 + 가이드 역할 정도가 사수 역할의 전부라 할 수 있다. 또 업무 프로세스 익히는 것도 신입의 경우도 대략 3~6개월 정도면 사수가 안알려줘도 자연스럽게 파악이 가능한 부분이기 때문에 사수가 굳이 알려주지 않아도 된다.
오히려 사수가 있을 경우 내가 개발하는 일에 더 방해가 될 가능성도 있는데, 방치형 사수일 경우는 문제가 없으나 오지랖 부리는 사수일 경우는 갈굼 + 쓸데없는 관심 + 삼천포로 빠지는 잡담으로 인해 오히려 일 하는데 방해가 되기도 한다. 갈구는 사수라도 있는게 좋다라는 이상한 생각을 가진 사람도 있는 걸 봤는데, 절대 도움되지 않으며 어차피 그 사수도 사수한테 배운게 아니라 자기가 구글 검색이나 별도 스터디를 통해서 알게 된 걸 알려주는 거 정도 밖에 안되므로, 꼭 사수한테 배울 필요도 없다.
결론은
사수한테 뭔가 배워야 겠다는 생각 보다는, 내가 알아서 배워서 사수나 팀원들과 함께 목표를 달성하기 위한 일에 집중하고 그 일원으로써 노력하는 모습을 보여주는게 훨씬 좋다는게 내 생각이다.
단 한명의 개발자가 있다고 하더라도 스스로 주늑 들어서 사수가 있어야 한다는 생각에 사수를 정하고 본인 스스로 부사수를 자청하지 말고 각각의 동등한 입장에서 함께 일하는 co-worker 개념으로 생각하고 일하는게 맞다고 본다.
단 한가지 예외 사항이라면, 회사에 직원 중에 개발자는 아무도 없고 나 혼자 개발자라면 문제가 있을 가능성이 높다. 애초에 그런 회사에 들어가면 혼자 개발 관련된 걸 모두 혼자 해 나가야 하기 때문에 방향성을 잃을 가능성이 높다. 최소한 내가 개발이 뭔지 알고 일 진행을 어떻게 하는 지 알아서 개발의 방향성은 잃어버리지 않는다고 하더라도 개발을 잘 모를 가능성이 높은 영업, 디자인, 대표 등등의 사람들에 의해 개발일이 쉽게 휘둘리는 건 시간 문제기 때문에 그런 곳은 비추한다.
기술 면접을 위한 노트북을 준비하라고 해서 노트북을 준비해서 약속된 면접날 아침 일찍 갔다. 왜냐하면 그 회사는 인덕원역 근처에 IT 회사들이 모여있는 어떤 빌딩이었기 때문에 가는 시간만 해도 1시간이 넘었기 때문이다. 여기서 그 회사는 내가 지원한 스타트업 회사가 아니고, 스타트업 회사 대표가 다른 회사의 이사이기도 해서 그 "다른 회사"에 온 것이다.
오전 10시까지 가야 하는데 1시간이 넘는 거리라 출근하는 기분으로 또 면접을 보러 가게 되었다. 오랜만에 타보는 9호선과 4호선은 왜이리 사람이 많던지, 일하고 있지 않을 때 출퇴근 시간에 무표정하게 지나다니는 많은 사람들을 보면 나도 빨리 일하고 싶다라는 생각이 든다. 막상 일할 때는 그런 생각이 안든다는 것도 신기할 노릇이다.
면접 장소에는 수석 개발자 분과 팀장 한분만 참석했다. 스타트업 대표님은 이날 출장이 있다고 해서 참석하지는 않았다. 뭐 기술 면접이니 상관 없다고 생각했다. 다시 생각해 보면 보통의 면접 프로세스와는 반대로 진행되고 있다는 걸 알게 되었다. 보통 기술면접 후 임원 면접이 진행되는게 많은데, 이때는 임원면접 후 기술면접이 진행되는 식이었으니까.
어쨌든 간단한 기술적 대화를 나눠보고 C#과 .NET 그리고 Xamarin 등등의 얘기를 하다 보니 수석 개발자 분도 본인이 하고 있는 일에 대해서는 잘 알고 있었지만 일반적인 기법에 대해서는 알지 못하는 것도 있다 보니, "어 그런 것도 있었어요?" 라는 얘기도 나왔다. C# 7.0이 나오면서 튜플이라는게 생겼는데 나는 호기심에 한번 코딩해본적이 있는 걸 얘기해줬는데 그런 반응이 나왔었다.
그리고 본격적으로 코딩 문제를 줬다. 요즘 같으면 REST API로 만들면 쉽게 해결되는 기술을 RPC라는 개념을 들먹이면서 원격에 있는 메소드를 호출하고 결과를 받아오는 프로그램을 여러 기술과 라이브러리를 조합해서 만들어보라는 식이었다. 문제 해결 능력을 측정하는 면에서는 꽤 괜찮은 방식이라고 생각되었고 점심시간 전 까지 대략 3개 정도의 라이브러리를 사용해서 3개의 프로젝트를 만들어 테스트를 진행했다.
시간이 좀 걸리다 보니 점심 시간이 되었고, 점심도 같이 먹게 되었다. 회사 건물 1층에 순대국 집이 있었는데 거기서 순대국 시켜준걸 같이 먹으면서 이런 저런 얘기를 했다. 스타트업 대표님에 대한 얘기도 잠깐 했는데, 이것 저것 하고 싶은게 많은 분이고 공대 나왔지만 사업적인 마인드가 있다는 얘기도 듣게 되었다.
점심을 먹고 또 다시 코딩을 하기 시작했다. 코딩은 회의실에서 혼자 진행했고 인터넷 사용도 자유로웠다. 다만 원격 화면 공유 프로그램을 설치해서 수석 개발자분이 내 화면이 공유되는 걸 지켜보는 식으로 진행되는 기술 면접이었다.
시간이 남으면 UI 까지 개발하는 것도 optional한 요구사항이어서 거의 2년 만에 WPF 프로젝트를 만들고 xaml 코딩을 하기 시작했는데 막상 하려다 보니 인터넷 검색을 상당히 많이 해 가면서 진행하게 되었다. 여기서 문제가 발견되었는데, 수석 개발자 분이 내가 인터넷 검색을 자주 하는 화면과 xaml ui를 코딩하는데 뭔가 잘 안되고 있다는 느낌을 받았는지 나중에 끝나고 xaml 코딩 많이 안해보셨냐는 얘기까지 들었다.
이 시점에서 내가 느낀 건 뭐였냐 하면 실시간 코딩 테스트는 사실상 압박을 주는 상황에서 똑바로 잘 하나 혹은 잘 아냐 측정하는 수준밖에 안된다는 점이었다. 물론 실시간 코딩 테스트를 잘 하면 좋은 인상을 줄 수는 있지만 코딩 테스트 보다는 코드 리뷰 형태로 가는게 더 나은 방식이라고 본다. 어쨌든 실시간 코딩 테스트는 면접자들에게 초초함+압박+긴장으로 인해 제 실력이 안나오는 상황이 연출되기 때문에 안좋은 방식이다.
그렇다고 해서 내가 WPF를 잘 모르고 xaml 코딩을 잘 못하는 사람이 아닌데도 보는 사람의 시각에 따라서 그렇게 비춰지고 평가를 받는다는 점에서도 딱히 좋다는 느낌을 받지 못했다.
어쨌든 거의 하루 종일 코딩하느라 기력이 다 빠진 상태에서 그런 얘기까지 듣고, 최대한 빨리 못한 부분을 완성해서 메일로 달라는 얘기를 듣다 보니 완전 기운 빠지게 되었다. 그 당시에는 제대로 완성해서 보여주고 이 회사에서 일해야지라는 생각이 더 컸으므로 주말까지 시간내서 진행하면 완성할 수 있을 것 같았다.
그렇게 해서 주말까지 작업해서 메일로 제출하고 결과를 기다렸다. 나는 솔직히 될 줄 알았고 결과도 금방 알려줄 줄 알았다. 그런데 주말까지 시간 투자해서 추가 구현 내용까지 진행했는데도 1주일이나 연락이 없어서 심리적 압박감이 이만 저만 든게 아니었다.
그리고 2017년 4월의 어느날 하루만에 참으로 많은 일이 일어났던 날이 있었다.
그 날은 9번 회사, 지금 10번 회사, 이제 마지막인 11번 회사이자 내가 재직중인 버넥트에 대한 얘기를 한꺼번에 할 수 있는 날이기도 하다.
사람들 마다 내가 무슨 개발자인지 얘기할 때가 있다. 그런데 그 소개하는 방법이 일관적이지 않고 저마다 다르다. 어떤 개발자가 있는지 유형을 한번 살펴보고 올바르고 소개하는 방법에 대해 생각해 보고자 한다.
특정 프로그래밍 언어로 자신을 소개
이게 제일 흔한 방법인데,
"Java 개발자에요."
"Python 개발합니다."
등등으로 얘기한다.
그런데 이 방법에는 문제점이 있는데 프로그래밍 언어로 내가 무슨 개발을 하는지 정확하게 알지 못한다는 것이다.
Java의 경우도 안드로이드 앱 개발을 할 수도 있고 웹 어플리케이션 개발을 할 수도 있다. Python의 경우도 웹 어플리케이션 개발을 할 수도 있고, 인공지능의 CV쪽 개발을 할 수도 있을 것이다. 프로그래밍 언어 기준으로 소개하면 조금 더 질문을 하게 되는 단점이 있으므로 프로그래밍 언어 기준으로 소개를 하기에는 명확하지 않다.
개인적인으로 특정 프로그래밍 언어를 한정지어서 소개를 하면 경험이 없어 보일 수도 있다는 의견이다. 물론 자기가 알고 있는 프로그래밍 언어가 다양하면 "저는 C#도 하고 javascript도 하고, 종종 C++도 하고 필요하면 Swift도 합니다." 라고 해도 될 거 같지만 역시 어느 분야의 개발을 하는지 정확하지 않다는 단점이 있다.
특정 framework로 자신을 소개
이건 두번째로 흔한 방법인데
"Spring framework로 개발합니다."
"React 개발하고 있어요"
"WPF 합니다"
요건 그나마 괜찮은건 특정 프레임워크는 떠오르는 프로그래밍 언어가 있기에 연관지어서 추정이 가능하다. 즉 spring이면 java, react면 javascript, wpf면 c# 이런 식이다. 그런데 이것도 확실하지 않은 건 spring boot도 kotlin으로 할 수 있고 wpf 역시 c#이 아닌 vb.net으로도 할 수 있기에 프레임워크 기반의 소개는 조금 더 구체적이지만 언어가 불명확할 가능성이 조금 있고, 아직 중요한 부분인 어떤 분야에 대한 게 나오지 않아서 어딘가 간지러운데 많이 긁지는 않은 상태이다.
특정 OS, platform, 포지션 등등으로 자신을 소개
"iOS 앱개발 해요"
"프론트엔드 개발자에요"
"서버 개발자입니다"
"웹 퍼블리싱 합니다"
"윈도우 프로그래머입니다"
"e-커머스 플랫폼 개발합니다"
"Unity 개발자입니다"
여기까지 오게 되면 그나마 조금 더 구체적이게 된다. framework 레벨은 궁금하지 않을 수 있으나, 역시 이것도 개발하는 분야에 한정된 얘기이므로 간단하게 얘기하기에는 좋으나 또 더 질문을 해야할 필요성을 많이 느낀다.
특정 도메인이나 기술, 서비스 등등으로 자신을 소개
"텐서플로우 써서 인공지능 개발합니다."
"ERP 시스템 개발하고 있어요"
"증강현실 쪽 기술 개발 하고 있습니다."
"자율주행 임베드 시스템 개발해요"
"회계시스템 유지보수 일 하고 있습니다"
이제 도메인 분야가 나왔다. 일반 사람들도 그렇고, 개발자도 추상화된 개념으로 받아들이기에는 괜찮다. 그런데 개발자라면 이제 이런 일을 어떻게 하고 있는지가 매우 궁금할 것이다. 분야는 정해져 있는데, 어떤 기술 기반으로 어떤 툴을 써서 무슨 언어를 쓰는지 궁금해 진다는 얘기다.
이제 대략의 결론
일반인한테는 대충 얘기해도 잘 모를 경우가 많으므로 상관 없는데, 개발자 끼리는 좀 정확하게 전달하는게 좋지 않을까 하는게 내 생각이다. 그래서 소개를 할 때는 적절하게 프로그래밍 언어 + 기반 OS, platform + 해당 기술이나 도메인 분야 + 활동 범위를 잘 얘기하는게 좋지 않을까 한다.
이런 방법으로 하는 내 소개
"저는 Unity를 써서 AR 기술을 바탕으로 산업현장에서 사용하는 멀티 플랫폼 디바이스 클라이언트 개발합니다. Android, iOS, UWP 환경으로 빌드하고 종종 navtive로도 개발합니다. 서버쪽은 Node나 Swift로 REST API도 개발합니다. 사용하는 언어는 c#, javascript, java, swift 등입니다."
로 하는게 좋은데 역시 말이 길어지므로 나도 역시 대충 대답해준다.
"AR 개발해요"
결론
필요한 사람에게 자세히 소개하는 건 좋은거 같은데, 말이 길어지므로 적당하게 말을 만들어 낸 후에 링크드인 같은 곳에 이력을 잘 적어둬서 나를 소개할 수 있는 링크를 던져 주자가 결론이다. 내가 궁금한 사람은 여길 방문해 보자. 했던 일이 많으니까 구구절절 설명하기도 어렵다.
한가지 피해야 할 소개는 프로그래밍 언어나 platform 의존적인 소개이다. java 개발, 윈도우 개발, iOS 개발, 프론트엔드 개발 등이다. 이렇게 하면 필연적으로 더 보조 설명이 따라가게 되어 있는 것 같다. 그리고 이제 막 주니어로 시작하는 개발자라면 했던 경험이 적으니까 상관 없는데 10년 이상 한 사람은 10년 내내 한가지 언어와 한가지 플랫폼에서만 개발했을 가능성이 매우 적으므로 잘 소개해야 할 필요가 있다고 본다.
코딩, 프로그래밍, 소프트웨어를 개발하고 배우는데 다들 어렵다고들 한다. 이건 전공자, 비전공자 가릴 문제도 아니다. 그런데 처음 배우는 거는 누구나 다 어렵다. 어렸을 때 부터 지금까지 새로운 걸 보고, 듣고, 배우는게 쉬운 사람이 있었던가? 만약 있었다고 자신있게 말할 수 있다면 탁월한 재능을 가진 사람이라고 말하고 싶다.
(이제부터 코딩, 프로그래밍, 소프트웨어 관련된 단어는 개발로 통일해서 얘기한다.)
다시 잘 생각해 보자. 개발을 하는 게 왜 어려운지. 한번 더 잘 생각해 보자. 잘 생각해 보면 어려울 이유가 없다. 개발에 대해 아주 쉽게 설명한 글들이 인터넷에 널려 있고, 특정 기술 관련된 따라하기 책들은 한달이 멀다하고 마구 쏟아져 나온다. 유튜브 동영상도 있고, 같이 공부하는 학원, 학교, 회사 사람들과 함께 하면 어렵지 않은 이유를 찾는게 더 쉽다고 말할 수 있을 정도다. 그런데도 개발 하는 걸 배우는 사람들은 이해하는 것도 어려워 하고 뭔가 잘 와닿지 않아서 어려워 하고, 자신의 학력탓, 비전공자 탓, 나이탓, 수준탓을 하면서 어려워 한다. 어쨌든 어려워 한다는게 핵심이지 않겠는가?
난 이 이유가 어디에서 부터 오게 되었는지 오랜 시간 생각해 왔다. 같은 걸 배우고 하는데 수준차이가 나는 이유도 찾아 봤고, 과외, 온라인 강의 하면서도 찾아 봤다. 최근에 멘토링 하면서도 찾아보고, 인터넷 까페에 올라온 수 많은 게시글에 댓글을 달아 주면서도 많이 생각해 봤다.
그 결과 프로그래밍 하는 걸 어려워 하는 이유는 거의 아래와 같은 내용들로 수렴된다는 결론을 얻을 수 있었다.
What의 문제: 뭘 해야 하는지 모른다.
공부를 하는 방법을 모른다. 코딩하는 방법을 알면 잘 하게 될 거라 믿는다.
어떤 개발을 하는게 즐겁고 재미있는지 잘 모른다. 이유도 단순히 취업이 잘되는지, 돈을 많이 벌 수 있는지에 집중되어 있다.
Why의 문제: 왜 어려운지 판단하지 못한다.
내가 이해를 잘 못해서, 책이 쉽지 않아서, 내가 게을러서 등등 핑계는 찾을 수 있는데, 왜 어려운지에 대한 근본적인 의심을 잘 안한다.
자신이 가진 궁금증에 대한 해결을 다른 사람에게만 의존하려 한다. why에 대한 생각의 흐름 정리를 스스로 하지 못한다.
How의 문제: 어떻게 하는지에 대한 궁금증만 가득하다.
하루아침에 뭔가 쉽게 되는게 아닌건데도 되는 방법만 찾고 싶어 한다.
거기서 뭔가 조금만 더 고쳐서 해보려고 해도 계속 how to의 문제로만 귀결된다.
how to에 대한 것만 하고 싶어 하다 보니, what, why에 대한 중요성의 인식이 상대적으로 떨어진다.
여기에 있는 내용을 다시 종합해서 보면 근본적인 학습 방법에 대한 훈련이 안되어 있는게 결론이다. 스스로 궁금증을 가지고 문제를 만들고 해결해 나가는 과정에서 학습하고 그 결과를 문서/사진/동영상 등으로 리포트 하고 review를 하는 활동을 학교에서 잘 하지 않았기 때문이다. 사실 이런 활동들을 해야지 개발을 할 수 있는 훈련이 되는 것이고, 그렇게 해 나가야 조금씩 성장이라는 걸 할 수 있는 건데, 어렵다 => 못하겠다 => 남들한테 물어본다 => 내가 안한다 이런식으로 흘러가다 보니 잘 하고 싶은 생각은 충만한데, 그냥 시간만 흘러가게 된다.
이런 안좋은 마음가짐들은 모두 공교육에서 나왔다고 본다. 공부를 하는 이유는 성적 관리를 위해서이고, 공부를 하는 즐거움은 없다. 또 어떻게 공부하느냐에 대한 문제도 범위가 정해져 있고 방법도 널려 있기 때문에 내가 고민할 필요가 없다. 내가 점수를 내기 위한 시간 투자와 점수를 내기 위한 방법을 잘 아는 학원이나 과외를 받으면 되기 때문이다. 어쨌든 뭔가 문제를 해결하려는 생각의 정리나 리뷰, 발표 이런 활동 위주로 하지 않았으니까 주어진 시험범위 내에 문제를 풀고 점수를 얻어 평가를 받아 등급이 매겨지면 내가 잘 하는 사람이 맞겠지라는 생각만 가득한 것이다. 그렇게 10년 이상을 반복해서 살아온 사람들이 갑자기 그런 패턴이 아닌 활동을 하려고 하니 비단 코딩 뿐만 아니라 어떤 분야를 하던 어려운게 맞을 것이다.
이제 주어진 범위의 지식을 단기간 알고 있다가 점수를 내는 방식으로 평가를 받는 방법의 공부를 하지 말고
내가 해결하고자 하는 문제를 만들고 그걸 해결해 나가기 위한 탐색, 고민, 분석, 설계, 생각, 정리, 깨달음, 발표, 피드백, 리뷰, 기록을 가능한 수준부터 해 나가 보자.
지금 이렇게 하는게 늦은거 같은데 제가 이걸 할 수 있을까요? 같은 이상한 질문 하지 말고 일단 해보자. 공교육식 프레임을 깨고, 성장을 위한 활동 프레임을 씌우자. 지금 부터 몇 개월 몇 년 후를 돌아봤을 때, 아무것도 안한걸 후회하지 않게 지금 당장 해야 한다.
2001년 복학 했을 당시에도 공부를 열심히 하지 못했던 것 같다. 막연한 진로는 게임 프로그래머이긴 했지만 자신이 없었다. 당장 수업듣는 과목들도 자료구조, 마이크로프로세서, 이산수학 등 또 이론적인 과목들 뿐이었고 과제로 내주는 C 언어 프로그래밍은 동기나 후배들꺼 보고 겨우 이해해서 수정해서 내는 수준이었다.
지금은 상상할 수 없지만 그 당시만 해도 강의실에 흔한 빔프로젝터나 PC 같은게 있지 않았었다. 새로 지은 건물에는 구축이 되어 있었지만 80~90년대 부터 쓰던 강의실에는 그런걸 설치해 두지 않아서 누군가 수업시간 전에 빔 프로젝터와 노트북PC를 세팅해야 하는 일을 해야 했다. 물론 과대라 읽고 심부름꾼(시다바리)이라 쓰는 사람이 한다.
사실 과대가 될 생각은 해보지도 못했고 전혀 그런걸 할 생각도 없었는데, 어떤 계기로 인해 졸업할 때 까지 과대 혹은 반장이 되었다.
복학 후 자료구조 첫 수업 시간이었다. 지금도 그러는지 모르겠는데 첫 수업 시간은 대략적인 강의 설명, 리포트, 과제, 시험방식 점수 산정 방법 등등을 설명하고 1시간이 채 되지 않은 시간에 끝냈는데, 그때도 그랬다.
교수님이 대충 설명 끝날 때 쯤에 매 수업시간 마다 빔프로젝터와 노트북PC를 세팅할 사람(호구) 손 들라고 했다. 물론 아무도 손을 들지 않았다. 교수님이 혹하는 제안을 했는데 무려 2만원에 달하는 자료구조 책을 준다고 했다. 그래도 아무도 손을 들지 않았다. 무슨 생각이었는지 그 책을 그냥 갖고 싶다는 생각이 들었다. 그래서 손을 들었는데 바로 당첨되었다.
그후 모든 수업마다 내 동기들과 후배는 이런 일을 할 사람을 찾는 교수님의 눈빛을 보면 "반장~"을 외쳐댔고 그게 내가 되었다. 그렇게 계속 심부름 하면서 다니고 과대도 되었다. 그렇게 졸업할 때 까지 우리 반의 충실한 심부름꾼이 되었다. 기억에 남는건 학교에서 주는 용돈 수준의 과대비와 교수님과 동기 후배들의 잡일 처리였다. 아직도 나를 부르는 동기들의 목소리가 머릿속에 맴돈다. "반장~!"
이제 개발 얘기를 해 보자면, 2학년도 마치고 3학년이 되었지만 난 여전히 그저 그런 흔한 컴공생이었다. 과제는 점점 더 어려워지고 있었고 배우는 프로그래밍 언어도 C에서 JavaScript, C++ 등 해야 할 게 더 많아졌다. 더 하기 싫어져서 PC방에서 게임하던가 동아리방에서 놀던가 하는 걸로 시간을 보냈다. 지금 생각해 보면 그렇게 시간낭비를 하지 말았어야 했지만, 그때는 코딩이 너무도 하기 싫었고 코딩 안하는 과목 쪽에 눈을 많이 돌렸다. 소프트웨어 공학이라던가 데이터베이스와 같은 과목들.
그러던 중 프로그래밍에 눈을 조금 뜨게 된 중요한 계기가 몇 있었다. 객체지향 프로그래밍이라고 해서 C++의 class 개념을 추가해 객체지향적인 프로그래밍 과정을 이해하는 과목이 있었는데 초반 과제는 그럭저럭 했다. 그러나 중반 이후가 되니까 class, object 에 대한 이해를 하지 못하면 C언어로 짜듯이 주먹구구식으로 할 수 밖에 없고 결국 할 수 없는 수준이 되다 보니 정말 시간을 내서 이해를 해야 할 시간이 닥쳐오게 됐다.
내가 제대로 모르고 하는 부분이 뭐가 있는지 탐색해 나가다 보니 결국 포인터 부터였다. 그래서 연습하고 이해하고 연습하고 이해하고를 학교 실습실, 집에서 계속 반복해 가면서 이해해 갔다. 변수 이름 앞에 * 붙였다가 뗐다 하면서 오류 나는지 확인하고, 역시 & 붙였다 뗐다 하면서 오류 나는지 확인하고를 계속 반복하면서 알아보고 스스로 깨닫고 이해해 나갔다. 어떤 날은 새벽까지 집에서 그 짓을 하고 있을 때도 있었고 그 동안 스스로 하지 못했던 과제들을 포인터를 쓰고 안쓰고의 차이를 직접 해 보면서 알아 가기도 했다. 학교에서는 오후 늦게쯤 항상 가던 동이리방도 안가고 실습실에 야간 수업 들으러 오는 친구들 수업 시작하기 전 까지 몰입해서 했을 때도 있었다. 이러다 보니 야간반 애들하고도 안면이 트고 친해지는 계기도 되고 야간반 과대랑 졸업여행 계획도 같이 세우게 된 좋은 계기가 생긴것도 덤이긴 했다.
한 2주 지나고 보니 포인터의 규칙이 선명해 지면서 다른 모르는 부분들도 조금씩 이해가 되기 시작했다. Swap 함수가 왜 포인터의 주소로 념겨지는지, 함수의 포인터를 왜 넘겨주는지도 알게 되었다. new를 하면 메모리가 heap에 생기고 포인터 주소를 잃어버리면 어떻게 되는지 등. 학기 마지막 쯤 되니까 이미 1, 2학년 때 배우고 알고 있어야 하는 걸 그제서야 알았다. 사실 남들보다 한참 늦게 알게 된 것이다.
목돈도 굴리려면 종자돈을 마련해야 한다는 얘기가 있듯이, 포인터에 대한 개념과 이해라는 종자돈을 잘 챙겨 두니까 이후에 파일 입출력 같은 것들도 목돈 불리듯이 술술 풀리게 되었다. 이 때 부터 내가 스스로 "각성"이라 불리는 상태에 돌입했던 것 같다. 학기 마지막 과제가 자동판매기 시뮬레이터였는데, 그걸 class 구조로 짜 나가면서 이해를 하기 시작했고, 새벽에 후배들과 문자 메시지를 주고 받으면서 설명해 주고 자랑(?)도 하고 그랬다.
그 열기는 여름방학 때에도 계속 이어갔다. 그 당시에는 Win32 API나 MFC로 Window 프로그래밍을 하는게 대세여서 후배들과 학교에 모여 스터디도 하고 C++ 관련된 책도 읽다 보니 STL이나 Effective c++ 같은 책들도 같이 보게 됐다. 2학기가 되고 나서 부터는 왠만한 과제는 스스로 배우고 풀기 위해 시간을 더 쓰게 되었고 어떻게든 혼자 힘으로 해결해 보려고 애썼다.
교수님들이 내주는 과제는 너무 빡셌지만 그럴 때 마다 해내려고 하다 보니 재미도 생기고 자신감도 생기고 그랬다. 2학기 때는 Java도 했는데, 빡센 Java 과제를 해 나가면서 C++과는 또 다른 객체지향 개념에 대해 이해를 해 나갔고, 2학기가 끝나갈 무렵이 되자 어렴풋이 다음과 같은 느낌을 받았다. 이제 프로그래밍 문법 몰라서 못하는 수준은 아니고 튜토리얼이나 API 문서 같은거 보고 조금 따라 쳐본 후에 계속 API 참고 해 가면서 해 나갈 수준 까지는 됐던 것 같다.
거의 1년이 채 안된 기간 안에 많은 걸 이루어 냈다. 객체와 메모리 덩어리들이 머릿속에서 array, sort로 움직이고 포인팅하는 화살표 선이 이어지는 상상까지 할 수 있을 정도였고, 이제 내가 대학에 온 이유를 실현하기 위한 마지막 힘을 쏟기 위해 3학년 2학기가 끝나갈 무렵 게임 프로그래밍 학원 6개월 과정도 다녔다.
첫 실무 + 기술 + 제안 면접을 끝내고 빠른 시일 내에 임원 면접 일정이 잡혔다. 평일 오전 시간에 잡혀서 출근하는 기분으로 좀 일찍 가서 커피 마시면서 기다리다가 면접 보러 들어갔다.
그런데 커피숍에서 기다리는 중에 대표님으로 보이는 분과 면접 봤던 실장님이 함께 밖에서 담배피우고 들어가는 모습을 목격했는데, 담배 피우시는 분이구나 하고 생각할 때 쯤! 눈 마주치면 어색하겠지, 또 커피숍 들어오면 안되는데 라는 생각에 자리를 잠깐 떳지만 담배만 피우고 들어갔다.
면접 시간 맞춰서 들어가서 대표님과의 첫 면접도 좀 쉽게 풀리는 느낌을 많이 받았다. 사업의 방향과 투자금액 현재까지의 상황 등에 대한 설명도 자세히 들었고, 기술 적인 내용은 실장님이 괜찮다고 하니 믿고, 같이 일해 보면 어떻겠냐는 제안을 받았다. 뭐 사실상 근로계약서만 안썼을 뿐이지 당장 내일부터 일하겠다고 하면 일할 수 있는 그런 분위기였다.
연봉 조건도 조금 쎄긴(?) 하지만 전 직장 연봉 수준으로 맞춰줄 수 있다고 했고, 대표님이 회사 경영을 1년 넘게 하다 보니 그냥 개발만 할 줄 아는 개발자로는 한계가 있다고 판단 CTO 같은 사람이 왜 있어야 하는지에 대한 얘기도 같이 나눴다. 전체적으로 사업 방향에 맞는 기술 선택 및 시스템 구성 그리고 기술적인 스킬과 업무 배분 정도를 할 수 있다면 좋겠다는 얘기도 했다.
여러 가지 얘기를 하다 보니 서비스의 프로토타입 수준을 벗어나 웹 서비스 + 데이터 저장소도 필요로 하는데 아직 로컬 서버로만 구성되어 있다고 해서 클라우드 서비스와 대용량 데이터 처리 기법 정도를 가볍게 얘기해 줬는데 여태까지 클라우드라는 걸 몰랐는지 상당히 관심을 많이 가졌고 필요한 만큼만의 돈을 쓰면 쓸 수 있는 서버 비용에 대해서도 매우 좋아했었다.
하지만 10번 스타트업 회사가 됐으면 하는 기대감이 더 컸기 때문에 일단 알겠다고 하고, 다른 곳 면접도 본 곳이 있어서 연락 드리겠다고 하고 나왔다. 이 시점에서 마음속으로는 10번 스타트업 회사가 안됐을 때? 이 회사는 어떨까에 대한 고민을 조금 했는데 솔직히 10번 회사가 안되리라는 생각은 하지 않았던 것 같다.
10번 회사의 기술 면접이 내일 이었기에 내일 기술 면접 진행하고 이후 결과를 보고 판단해 보기로 했다. 조금 부담스러웠던 건 여기 대표님과 실장님은 빨리 입사해서 주니어 레벨 개발자들을 도와 같이 일했으면 좋겠다는 어필을 너무 했다는 것이였다.
여태까지 수십번의 면접 경험 중에 이렇게 적극적으로 꼭 와서 일해달라는 얘기를 해줬던 회사 대표와 실무자들이 없었던 점을 보면, 여태까지 이 회사가 왜 마음에 드는 경력자를 찾지 못했는지에 대한 궁금증도 함께 들기도 했고 또 한편으로는 기분이 좋기도 했다. 사실 "나 돈좀 주고 일 시켜 주세요" 라는 저자세로 나오는 건 상당히 굴욕적이지만 "돈 줄테니 꼭 와서 일해 주세요"라고 나오는 건 같은 근로계약서를 쓴다고 해도 마음가짐 부터 다를 것 같다.
암튼 이 회사의 두 번의 면접 경험을 통해 얻을 수 있던 건, 사람의 마음을 움직일 수 있는 면접 보는 방식이었고 그게 "여기서 일하고 싶지않아? 어서 와서 일해줘" 라는 좋은 느낌을 받을 수 있는 신기한 면접이기도 했다.
상대적으로 너무 권위적으로 나오고 "뭐 알고 있는지 얘기해봐", "(대놓고 아니라 속으로) 이런 것도 여태 모르는 경력자였어?" 이런 느낌의 압박을 받으면 아무리 그 회사가 돈을 많이 주고 기술적으로 훌륭하다고 하더라도 같이 일하고 싶은 마음이 싹 사라진다는 걸 모든 면접관들이 빨리 깨달아야 하는 부분이라고 본다.
어쨌든 이 회사는 가지 않았지만, 이 회사를 갈지 안갈지의 결정을 했던 이유를 다음 회사들의 면접 결과를 정리해 보면서 얘기해 보려 한다.
코딩하는 방법을 이제 막 배우는 입장에 있는 사람들은 흔히 자기가 하고 있는 프로그래밍 언어를 마스터를 해야 한다고 생각한다. 프로그래밍 언어를 마스터 해야 한다는 것도 착각일 수 있지만 그건 논외로 하고 어쨌든 마스터를 해야 한다는게
일정 기간을 공부하면 된다는 걸 얘기 하는 건지
알고리즘이나 기타 코딩을 빠르고 정확하게 잘 짜는 능력을 얘기하는 건지
해결해야 하는 문제를 빠르고 정확하게 인지해서 해결 방법을 아는 걸 얘기하는 건지
내가 모르는 걸 물어보면 대답을 잘 해 주고 친절하게 설명해주고 알려주는 사람을 얘기 하는 건지
기준이 없다. 그러니까 그냥 내가 모르는 걸 잘 알고 있는 것처럼 보이거나 나보다 조금 더 오래된 경력을 가진 사람이면 마스터의 경지에 다다랐겠지 생각하는 경향이 있다. 아무도 그런 기준을 정하지도 않았고, 뭔가 좀 잘 하는 사람들이 "내가 XX 프로그래밍 언어를 마스터 했다" 라는 말도 잘 안하는데 우리는 마스터의 경지, 고수 이런 경지가 있는 것처럼 생각한다.
그리고 그 좀 잘 해 보이는 사람에게, 어떻게 하면 잘 할 수 있는지 방법을 알려달라고 하지만, 뭔가 시원하고 가슴에 확 와닿는 대답을 해주는 사람이 없다.
이쯤 되면 빨리, 아 내가 뭔가 착각하고 있구나 라고 판단하고 그 혼란스러운 생각을 벗어 버려야 하는데, 시간이 지나도 자신은 잘 못하는 사람이고 이걸 마스터를 하지 않았기 때문에 삽질하고 있다고 생각한다. 또 이 분야를 마스터를 해야 내가 잘 하는 사람이 될 수 있을 거라는 생각만 계속 한다. 그리고 뭔가 액션을 취하지도 않는다.
언제까지 배우면 마스터를 할 수 있는지
제발 이런 쓸데없는 질문은 이제 그만 했으면 좋겠다. 자신의 학습 능력, 기억력, 사고력, 집중력, 이해력, 판단력 등등 객관적인 데이터나 상황에 대해서는 일절 알려주지도 않고 질문을 하면 대답을 해 줄수가 없다. 심지어 자기 자신도 잘 하는지 못하는지도 잘 모르면서, 이 막연하고 어렵고 힘들어 보이는 프로그래밍 공부를 사람들이 얘기해준 기간만 버텨내면 마스터의 경지에 다다를 수 있는지 알고 싶어하는 것 같다. 항상 그렇다. 이 공부를 언제까지 하면 되는지에 대한 궁금증을 풀기 위해 초급자들이 하는 질문 중에는 아마 부동의 Top 1일 것이다.
그걸 남들에게 물어보면 대답이 천차만별일텐데, 대충 그 대답의 평균 기간을 자기 자신한테 적용해 보면 될 거라고 생각하는 것 같다. 게다가 그 중에 제일 짧은 기간을 얘기해 준 사람의 말을 듣고 스스로 희망고문의 덫을 씌운다. 그래 X개월 하면 나도 잘 할 수 있을 거야라고.
그런데 이 생각을 가진 사람을 잘 살펴보면 공부라는 걸 제대로 해본 사람이 아닐 가능성이 높다. 열심히 해야 하는건 알겠는데 하기는 싫고 부지런 해야 하는 것도 알지만 막상 하기 귀찮고 게을러 지게 되고 핑계거리만 찾아서 자기 합리화만 한다. 그리고 그 막연한 마스터의 경지에 대한 질문만 계속 하는 것이다. 그리고 언젠가 이 고통스러운 시간이 지나면 마스터가 되어 있을 거라고 꿈을 꾸는 것 같다. 그래서 기간에 계속 집착하고 있는 것이다.
누구는 학원 6개월을 다니면 될거라고 한다.
누구는 독학으로 1년 정도 하면 될거라고 한다.
누구는 3년을 했어도 아직 잘 모르는게 있다고 한다.
누구는 평생 공부한다는 생각을 가지고 해야 한다고 한다.
누구 말이 맞는 말일까? 누구 말이 맞는 말일까 고민하는 거 부터가 잘못됐다. 그리고 나는 절대 그런 마스터의 경지는 없다고 자신있게 얘기할 수 있고, 그렇기 때문에 기간을 논하는게 무의미하다고 얘기해 줄 수 있다.
그러면 어쩌라는 건지?
일단 답답하고 짜증나는 심정은 이해하나, 이 분야가 아니더라도 뭔가를 잘 하기 위해서는 조금씩이라도 꾸준히 뭔가를 해 나가야 하는게 정답에 근접한 대답이라고 본다.
하루 아침에 갑자기 짠 하고 잘 하는 사람이 없듯, 뭔가 대단해 보이는 짓을 하는 사람들을 잘 살펴보면 계속해서 흥미를 가지고 꾸준히 해 왔던 사람들이라는 얘기다. 사실 본인은 그런 활동을 하지 않았으면서도 그런 마스터의 경지를 찾아 방황하고 있었으니 욕을 한번 들어 먹을만도 하다.
이제 뭔가 느껴지는게 있다면 제대로 차근차근 자신에게 맞는 방법을 찾아 나가는 것이 맞다고 본다. 또 다른 사람의 의견을 들어봐도 좋다. 사람마다 각자 해 왔던 방식이 다르므로 참고 정도만 하는게 좋고, 자기 스스로 맞는 방법을 찾아 나가야 한다. 누구나 꿈꾸는 것은 쉽지만 꿈꾸는 수준에 도달하기 위해서는 작은 실천의 발걸음을 한 발자국이라도 옮겨야 하지 않겠는가?
그래도 가르침을 주십시오! 라는 질문에는 대충 뭘 해야 하는지는 정해져 있긴 한데 잘 하려고 꾸준히 노력하려는 마음과 의지를 탑재한 후 실제 실천을 통해 연습하고, 정리하고, 발표하고, 공유하고, 피드백을 주고 받고, 이해하고 하는 활동들을 해 나가면서
내가 이 일에 흥미가 있는지
적성에 맞다고 생각하는지
성취감 이라는게 있었는지
꾸준히 하고 있는지
이런 걸 가끔 돌이켜 생각해 보면서 진행해 나가면 어느 정도 답을 얻을 수 있다고 본다.
최소한 이런 활동을 한 후에 다시 선배들을 찾아가서 마스터의 경지를 물어보자, 질문이 예전과 같이 이상하다고 느껴질 것이며 이제 그 선배들이 했던 이해 안가는 말들이 조금씩 이해가 되기 시작할 것이다.
이 회사는 신경 안쓰고 있었는데, 어느날 갑자기 연락이 왔다. 지금도 생각해 보면 이상한데, 이렇게 연락받은 회사가 몇 된다. 이력서 넣은지 1~2주도 아니고 1~2달이나 지나야 연락이 오는건 어떻게 받아들여야 할 지 모르겠다.
이 회사도 마찬가지였다. 특이하게 기억나는 건 주말 오후 쯤에 뜬금없이 연락이 왔다는 거고 거기서 부터 인상이 썩 좋지 않았다. 당장 월요일날 면접 가능하냐고 재촉하길래 SI 인력파견 회사였던가? 의심이 되면서 일단 일정이 있어서 저녁때 된다고 하니까 오후 7시에 면접을 보자고 했다.
크게 관심도 없었고, 위치도 예전에 자주 파견 및 출장을 다녔던 기흥 동탄 삼성전자 쪽이어서 거리에 대한 거부감도 상당했다. 이쯤 되니 거의 모든 조건에서 면접을 볼 이유가 하나도 없었기에 그런 건데 그래도 면접에 응했던 건 어떤 회사인지 알아보고 혹시나 괜찮은 회사인지 알아보기 위함이었다.
월요일 오전 5시간에 걸친 기나긴 면접을 진행한 얘기는 10-1 스타트업 회사 면접을 참고하면 되고 기운이 거의 빠진 시점에 강남역에서 기흥 동탄 쪽으로 가는 광역버스를 타고 면접 장소로 향했다. 1550-1번 버스를 타고 종종 갔던 기억이 있어 오랜만에 타는 광역버스에 몸을 싣고 기흥 동탄으로 향했다.
회사 위치는 정말 신기하게도 기흥 삼성전자에 파견 나가 있었을 때 종종 점심 먹으러 나왔던 그 길에 어떤 빌딩에 위치하고 있었다. 늦은 시간이지만 회사 대표와 기술 이사로 보이는 분과 면접을 진행했다.
생각보다 회사는 작았고 자사 솔루션이 있긴 했지만 6번8번 회사의 일 진행 방식과 많이 비슷했다. 인근 반도체 공장에 파견 나가서 일해야 하는 점, 자체 솔루션과 기술력이 있는 회사인 점, 작은 회사지만 매출이 있는 회사라는 점은 공통 부분인 것 같다.
기술 면접 위주로 진행했는데 주로 대표님이 내가 어떤 경험을 가지고 있고 어떤 기술을 잘 사용했는지를 많이 궁금해 했으며, 특히 data visualization에 중점을 두는 회사다 보니 예전 굿어스 다녔을 때 모니터링 시스템 구축 및 WPF chart customizing 얘기가 자연 스럽게 나오게 됐고 그게 어필이 좀 된 거 같았다. 대표님과 기술 이사님은 사람은 좋아 보였고, 나름 일만 잘 하면 괜찮은 회사라는 느낌은 좀 받긴 했다. 위치가 너무 멀어 면접 볼 때는 큰 문제는 아니라고는 했는데, 면접 끝나고 생각해 보니 만약 다니게 되면 귀찮음이 밀려올 것 같았다.
연봉 얘기까지는 구체적으로 하지 않았는데 직전 연봉 수준에 맞춰 준다고는 했고, 사실 언제 부터 일할 수 있는지도 정확하게 얘기하지 않았기 때문에 면접 끝났을 때 그냥 괜히 왔구나 생각이 들었다. 아마 대표님과 기술 이사님도 그렇게 느꼈을 것 같다.
회사가 구체적이지 않은 이유부터 말하자면, 이제 막 스타트업을 차려서 뭘 할지 알지 못하는 회사였기 때문이다. 그럼 그 회사는 왜 지원했는가? 에 대한 걸 또 얘기해 보자면
이 회사의 대표 분이 "다른 회사"의 이사님인데 그 다른 회사가 꽤 매출이 있는 음향 전문기기 회사이다.
즐거운 일을 하고 싶어서 창업을 했고, 개발자들을 모아 ERP 솔루션 개발 및 "다른 회사"의 앱 개발을 하는 일을 하려고 한다.
소프트웨어 마에스트로 과정에 있는 젊은 친구들을 잘 육성해서 개발이 즐거운 일이라는 걸 얘기해 주고 싶고 함께 일할 자리를 마련해 주려고 한다.
여기서 이들을 잘 이끌어줄 멘토 + 많은 경력 + 올바른 개발자 마인드 + 그리고 실력이 갖춰진 사람과 함께 팀을 구성하려 한다.
여기 까지가 이 스타트업 회사에 대해 아는 내용의 전부였다.
그래서 내 영문이력서와 함께 회사 지원 이유, 궁금한 내용을 적어 그분에게 메일로 보냈다. 얼마 지나지 않아 내 블로그 글을 다 읽고 회신 하느라 늦었다는 얘기와 함께 미팅 날짜를 잡자는 회신이 왔다. 여기서 첫번 째 문제가 나왔는데 그 당시 블로그 글이 지금 처럼 많지 않았고 이직 얘기한게 전부였기 때문에 나에 대한 확신이 없다는 얘기도 함께 있었다. 뭔가 기술 블로그 수준의 블로그를 원한거 같기도 한데, 지금도 기술적인 내용은 안쓰고 있다는 점에서 블로그 공개를 조심스럽게 해야겠다는 생각이 든다.
위치는 강남의 어떤 공유 오피스에서 보자고 했고 오전 11시에 시간을 잡았다. 특별히 할 일이 없던 관계로 면접 끝나면 점심시간이니 영화를 보고 다음 면접 장소 (11번 째 회사)로 가면 되겠거니 하고 강남으로 향했다. 그 날은 하루에 면접을 두번이나 봤던 날이었다.
강남의 그 공유 사무실은 소문대로 사람이 많았고 여러 사람들이 각자 노트북을 가지고 일을 하고 있었다. 까페테리아 같은 곳도 있어서 간단한 먹을 거리를 먹을 수도 있었고, 회의실도 있고 팀 단위로 일할 수 있는 칸막이가 있는 자리도 있었다.
그리고...
이 회사 대표님과 매우 다양하고, 많고, 구체적이고, 이상적인 얘기를 오후 4시 까지 했다. 중간에 근처 쌀국수 집에서 점심을 함께 하고 계속해서 대화를 한 셈인데 점심 시간을 제외하고도 거의 4시간을 얘기한 것이다. 기술 면접도 없이 4시간을 대화 한건 여태까지 내 면접 경험상 전무 후무한 일이었으며, 그 만큼 첫 대면때 사람을 잘 알아보려는 대표님의 말 대로 진짜 사람을 알아보려는 시간이었었다.
물론 인터뷰 내용은 딱딱한 일반 회사의 그것과는 확연이 달랐다. 내 지난 과거의 삶과 어떤 생각을 가지고 살아 왔는지, 어떤 개발을 하면서 뭘 느꼈는지 상당히 구체적으로 얘기했고 나도 그분이 왜 스타트업을 하고 싶어하는지, 수익은 뭘로 나는지, 앞으로 함께 할 어린 친구들은 어디에 있으며, 나와 같은 시니어급 개발자는 어떻게 수급해서 진행하는지도 차근 차근 물어봤다.
얘기를 하다 보니 잘 진행된 거 같았고, 뭔가 구체적인 증거는 없었지만 하고 싶어하는 일이 긍정적이었기에 좋은 인상이 자리잡게 됐다. 대표님도 나와 얘기하다 보니 이제 실제 개발하는 실력을 검증해 보자고 해서 기술 면접을 해보자고 제안을 했다. 코딩 테스트는 자기가 이사로 있는 "다른 회사"에서 진행하고, 거기에 개발 수석과 함께 문제를 제한시간 없이(?) 풀어서 제출하는 형태라고 했다. 곧 "다른 회사" 수석과 연락을 해 일정을 잡았고 3일 후 오전 10시에 "다른 회사"로 와서 진행하자고 했다.
기술 면접 진행 전에 미리 소스코드 레벨의 작업된 내용을 확인해 보고 싶다고 연락을 해 와서 github 주소와 github에 공개하지 않았던 내 개인 프로젝트 소스 파일을 전달을 했다. 여기서 두번째 문제가 또 등장하는데, 그 당시 github에는 repository가 5개 정도 였고 그나마도 테스트 한다고 심플하게 올린 온라인 강의 코드들이 전부여서, "hello world" 수준의 코드로 판단하기 어렵다는 회신을 해 왔다.
그런데 여기서 속상한 건 그 당시 repository도 잘 살펴보면 hello world 수준은 아니라는 점이었다.
온라인 강의를 했던 코드들은 C#의 essential 수준의 강의 내용이라 C#을 잘 아는 사람이라면 허접한 코드가 아니며
AsyncServer 역시 C# 버전 문법의 극한치 까지 끌어올린 30 라인짜리 비동기 채팅 서버였다는 것이다.
NaverBookCrawler 역시 단순한 코드지만 개인 토이 프로젝트로 설명하기에는 손색이 없었으며
github외에 MVVM 패턴과 동적 다국어 변환 처리 코드 등 "hello world"라고 비하할 수준이 아닌 코드가 상당수였음에도
2017년에 비해 더 다양한 디바이스와 다양한 플랫폼에 대한 경험을 한 것 같다.
ARCore, ARKit을 활용해서 개발한 점도 그렇고, vuforia 역시 간단한 것 말고 복잡한 것 까지 추가로 구현한 점들 역시 좋은 경험 중에 하나였던 것 같다. => 하나의 image target을 가지고 상황에 따라 다른 game object를 증강시키는 방법 들
그 외에 현재 AR 기술의 한계점과 더 R&D 해야 할 부분들도 알게 되었다. 제일 중요한건 회사에서 R&D 연구소와, AR 개발팀이 별도로 분리가 되고 난 AR 개발팀에서 제품 개발에 대한 더 중요한 일들을 하고 맡게 되었다는 점이다. 업무 분담은 잘 되어 있는 편이고, 팀장과 대화를 많이 해서 내가 할 수 있는 일과 더 많이 도와 줄 수 있는 일을 찾아서 함께 진행하고 있다.
이런 말 하면 이상하게 생각할지도 모르지만 난 개발 프로세스도 없고, 개발 문화가 없는 스타트업을 선호하는 편이다. 왜냐하면 내가 그런 걸 알고 있기 때문에 그런 게 없는 회사가 개발팀에 가서도 얼마든지 좋은 사람들과 함께 만들어 나갈 수 있기 때문이다. 역으로 이미 좋은 개발 문화와 프로세스가 있는 회사라면 배우는데는 좋은데 내가 뭔가 이끌어나간다는 역량을 키우는 데는 부족할 수 있기 때문에 현재 내 포지션이 어딘지 잘 판단하고 회사를 잘 선택해야 한다. 제일 중요한건 좋은 개발문화와 프로세스가 없어도 같이 일 하는 사람들이 쓸데없는 고집이 있지 않고 열린 마음을 가진 사람들이어야 하고 나 역시도 그들과 함께 일하기 위해서 꼰대짓 하지 말고 좋은 개발 문화가 뭔지 뭘 하면 좋을지에 대한 걸 잘 얘기하고 그들에게 모범을 보여주는 게 중요하다고 생각한다.
그런 차원에서 1인 팀에서 6인팀으로 늘어나는 과정에서 내가 전파하거나 받아들인 문화는 아래와 같다.
유닛 테스트
Azure DevOps 사용 (아직까지는 repository만)
사내 스터디 활성화
프로젝트 리뷰
CI/CD 도입
기술 블로그 장려
등이다.
사실 junior level에서는 이런거 신경쓰는거 보다 당장 내가 맡아야 하는 프로젝트 일을 끝내는 데에 더 신경쓰고 있으므로 상대적으로 senior level인 내가 이끌어야 할 내용들이다. 여기서 사내 스터디 활성화는 내가 주도하는 건 아니고 내가 있는 개발팀의 팀장이 주최해서 참여하고 있는 것이다.
커뮤니티 활동
인천 GDG 개발자 커뮤니티
2018년 봄 쯤에 알게 되었는데 처음부터 이 커뮤니티에 들어가려고 했던 건 아니었고 여기 멤버 중 한 분인 승빈님이 git study를 열어서 참여하게 되었고 그러면서 자연스럽게 이 커뮤티니를 알게 되었다. 사실 git study 내용 자체는 알고 있던 거라 review 차원에서 듣게 된 것이고 여기서 내 개발활동의 영역을 넓혀 보고자 한 거였는데 git study는 study로 끝났고 인천 GDG 커뮤니티 활동을 조금씩 하게 된 건 좋은 것 같았다.
그러고 나서 보니 깨달은 바가 있었는데, 존 손메즈의 소프트 스킬이라는 책이 있는데 거기서 지역 개발자 커뮤니티 활동을 해보라는 얘기가 떠올랐다. 사실 이 책은 썩 좋은 책은 아닌데 쓸데없는 부동산 얘기와 피트니스 얘기가 있어서 그렇지만 다른 내용들은 꽤 볼만하다. 여기서 지역 커뮤니티 활동이 미국에서만 가능한 얘기인 줄 알았는데 내가 살고 있는 인천에도 이렇게 지역 개발자 커뮤니티가 있고 활동할 수 있게 된 건 매우 잘한 일이라고 생각한다.
이 까페는 웹 개발자 까페 중 가장 활성화된 까페를 찾다가 알게 되었고 가입 후 멘토링을 해주는 글을 올리면서 활동하기 시작했다. 실제로 여기서 멘티 분을 두분을 만나 멘토링을 해 줬고, 기타 고민 상담 글에 대한 댓글을 좀 과격하게 달아 주면서 활동하고 있었다.
그러다가 하반기 세미나 발표 때 발표자를 모집한다고 해서 내가 그 동안 웹 프론트엔드 기술 동향에 대해 생각한 걸 정리하면서 내 멘토링 활동 소개, 그리고 개발 잘 하는 방법 등을 발표하는 자리가 됐으면 해서 신청 했고 운 좋게 선정되서 발표도 하게 되었다.
난 주로 회사 개발 일 위주로 일을 해 왔고 커뮤니티 활동은 잘 안했었는데 이번 계기를 통해 오프라인으로도 커뮤니티 활동을 하게 된 계기가 됐고 여기 운영진 분들에게 매우 고맙다는 말을 전하고 싶다.
발표 자료는 잘 모르는 사람이 보다 보면 약팔이로 느낄 수 있으나 끝까지 보면 결코 약팔이 발표자료가 아님을 알 수 있으니, 대충 보고 욕하지 말았으면 한다.
스터디 그룹
스터디 모임에 대해 짧게 얘기해 보면 스터디 그룹은 조금 비추하는 편이다. 왜 그런가 하면 열심히 하는 사람도 드물고, 핑계대면서 빠지는 사람도 많은 데다가 그런 사람들과 함께 하면 나까지 게을러지기 때문이다. 사실 아는 사람들 끼리 해야 스터디 모임이 활성화가 되는데 그렇게 하면 또 친목 모임으로 변질되서 새로 들어오는 사람들이 적응을 못하는 현상도 생긴다. 그럼에도 불구하고 계속 시도하려는 이유는 사람들과 만나 얘기를 하고 새로운 생각들과 개발에 대한 관점을 얘기해 보고 싶었기 때문이다. 솔직히 기술 실력 높이는 건 스터디 그룹에서는 할 수 없는 일인 것 같다.
git - 기초 스터디
git 스터디는 위에 잠깐 얘기한 대로 승빈님의 스터디 그룹에 참여하는 것 부터 시작해서 진행했다. 물론 이 모임도 잘 참여하는 사람 아닌 사람 좀 갈리긴 했지만, 멤버 절반 이상이 인천 GDG 멤버였기 때문에 끝까지 잘 진행되기는 했다. 여기서 내가 배운 건 여렴풋이 알고 있었던 git flow에 대한 간단한 실습을 해봤다는 것이고, 역시 혼자 하는 거 보다 같이 하는게 좋다는 걸 알게 된 스터디였다.
혼자 프로젝트 오일러 문제를 풀다가 질릴 때 쯤 온라인으로 알고리즘 문제 풀고 코드 공유하는 식의 스터디 모임이 있길래 참여했는데 2주도 안되서 폭파 됐다. 폭파된 문제는 뻔한 거였는데 사람들의 참여율이 1주 만에 엄청 낮았다는 거였고, 2주만에 1/3, 3주차에 나를 제외한 한명만 참여하고 있었던 점이다. 쉬운거 부터 차례대로 풀어서 코드 공유하는 건데, 그것 마저도 아무 얘기 없이 안하는 사람들이 있었다는건, 스터디 모임은 유지되기가 어렵다는 걸 얘기해 주며 온라인 모임은 더더욱 유지되기 어렵다는 걸 반증하는 것 같다.
하반기에 다시 승빈님이 주최한 스터디 모임이어서 주저 없이 신청했다. 스터디 모임은 참여하기 쉬운 반면에 주최하는 쪽은 준비도 많이 해야 하고 신경써야 할 것도 많기 때문에 참여하는 쪽으로 하게 된 거고, 승빈님이 발표자료 준비를 잘 해오기 때문에 편한 것도 있었다. 내용은 ecma2015 문법 정리 + express를 통한 간단한 rest api 및 DB 연결 까지였다. 새로운 멤버들도 있었고, 기존 인천 GDG 운영자 분들도 있어서 잘 진행된 스터디였고 중간에 나오다 안나온 사람 둘 빼고는 잘 진행된 것 같았다. ecmascript2015야 하코사 발표 할 때도 엄청 많이 봤었고 그 전에 실무에서도 썼었기 때문에 역시 리뷰하는 마음으로 참여 했는데 진행하다 보니 역시 사람들의 생각은 조금씩 달랐고 그 대화에 참여하는 것 만으로도 즐거웠던 스터디 모임이었다.
이건 몇 년 전에 봐온 영국의 어떤 프로그래머 분에게 영감을 얻어 나도 수학 문제를 풀고 알고리즘 해결 방법에 대해 생각해 보자는 취지해서 시작한 것이다. 사실 시작할 생각은 훨씬 전부터 했지만 내가 멘토링을 진행하는 분 중에 알고리즘 문제를 푸는 연습을 하시는 분이 있어서 내가 모범이 되고자 시작한 계기가 제일 크다.
알고리즘 문제 푸는 방법은 다른 인터넷 글에 많이 나와 있으니 그대로 하면 재미 없을 것 같아서 내가 생각했던 방법과 잘못 생각하고 있었던 것, 나만의 생각의 흐름 정리, 마지막으로 코드 기교 부리기 정도로 해서 진행했다. 현재 15번 까지인가 풀고 잠깐 쉬는 중인데 올해도 조금씩 진행할 예정이다.
송도 GDG에서 알게된 백지훈님이 주최하는 모임에 참여하게 되서 진행한 온라인 스터디 모임이다. 백준 알고리즘 온라인 모임은 이미 죽어 있는 상태에서 다시 온라인 모임을 한다고 해서 참여하게 됐는데 여기 지훈님이 C++에 대해서 아주 잘 알고 있는 분인데다가 부지런한 분이어서 나도 같이 부지런히 알고리즘 문제 푸는 모임을 진행하고 있다. 문제는 프로그래머스라는 사이트에서 두 문제를 선택해 문제를 풀고 순서가 되면 문제 푸는 방법을 설명하는 식으로 진행하는 것이다. 이 모임 역시 안하는 사람이 절반이 넘기 때문에 그 사람들은 걸러 내고 지훈님과 나는 100% 참여율이고 나머지 몇 몇 분들이 조금씩 문제를 풀어와 같이 리뷰하는 식으로 하고 있다.
여기서 내가 중요하게 생각하는 건 알고리즘 문제 푸는 방법을 뛰어 넘어서 내가 선택한 언어가 어떻게 전략적으로 코드가 나오는지, 여러 다른 언어들로 풀어 가면서 나의 생각 정리하기 정도를 더 추가하고 있다. 알고리즘 문제 푸는 거 정리하는 거 쯤은 다른 블로그 쓰는 사람들도 하는 거라 나는 좀 더 차별성을 두고 진행하고 있다.
소프트웨어라는 제대로된 개념을 전파하기 위한 나름 나만의 활동인데, 현재까지 내 인생에서 제일 잘하고 있는 걸 꼽으라면 이 활동을 얘기하고 싶을 정도로 매우 중요한 활동이다. 학생, 취업준비생, 현업 개발자 등 다양한 분들과 함께 대화하고 소통하면서 그 분들에게 필요한 역량과 생각이 무엇인지 그리고 제대로 하기 위해서 뭘 해야 하는지를 알려주는 역할에 충실히 하고 있다. 나 역시 항상 가르쳐 주기만 하고 알려주기만 한다고 생각할 수 있지만 어린 분들이지만 남다른 생각을 가진 것과 대화하면서 더 배우기도 하는 점도 있는 등 좋은 면이 훨씬 많다.
정보처리기사는 내 전공과 관련된 거다 보니 아내와 함께 할만한걸 찾다가 한국사 시험을 보기로 했다. 사실 한국사 1회 시험을 본 적도 있고 떨어진 기억도 있기에 다시 해볼까 해서 해봤는데 아내와 다 둘다 실패. 점수도 50점 대로 합격과는 거리가 먼 점수였는데 기출문제 외우는 수준으로 한국사 1급은 딸 수 없다는게 내 생각이다. 한국사에 대한 매우 깊은 이해가 없이는 문제를 풀기가 매우 어렵기 떄문에 준비를 많이 해야 하는 시험이다.
베이스 기타 연주
전에 교회를 다닌 적이 있고 베이스 연주를 하다 보니 가끔 베이스 연주를 하곤 하는데, 합주는 안되니까 RockSmith 게임 동영상을 YouTube에서 재생하고 거기에 맞춰서 연주하는 수준으로 점심시간에 가끔 즐긴다.
요건 Fray의 How to Save a Life, Bass 연주하기도 쉬운데다 노래가 좋다.
아래 링크는 내가 직접 연주한 UpTown Funk intro 연주 부분
딸 다은이의 성장
갓난 아이였던 다은이가 이제 많이 성장해서 말도 하고 뛰어 다닌다. 집에 있을 때는 나에게 최고의 행복을 주는 아이.
오랜 기간 소통하지 않았던 친구들과의 소통
사실 만날 일이 별로 없기도 하지만 인천으로 이사도 왔고 다은이도 좀 커서 친구들도 다시 만나봐야 겠다는 생각이 들 쯤에 친구 한놈이 결혼한다고 해서 그 일을 계기로 다시 잘 지내보려 한다. 올해 부터는 여행 계획을 세워서 여행을 잘 다녀보기로 했다.
영화 리뷰
영화 많이 보기가 내 주요 취미임에도 불구하고 뭔가 리뷰 같은걸 적어 본게 별로 없다. 예전에 블로그에 적은건 CGV에서 썼던 링크인데 그마저도 다 날아가고 해서 다시 제대로 써볼 겸 해서 쓰고 있다. 작년 5월 부터 부지런히 쓰고 있고 계속해서 쓰고 있으니 칭찬할 만 하다.
영화 리뷰 글은 내 또 다른 블로그에서 볼 수 있다. https://feelcommonlife.blogspot.com/
.jpg)
