Showing posts with label development. Show all posts
Showing posts with label development. Show all posts

Tuesday, September 10, 2019

What should I do

해야 할 것들은 산재해 있는데, 뭔가 제대로 하고 있는 건 몇 없는 것 같다. 이번에 한번 정리해 보고 실천해 봐야 겠다.

여태까지 잘 하고 있던 것


멘토링


  • 현재 격주로 수, 목요일로 오후 11시에 온라인 멘토링 진행
  • 수요일 팀, 목요일 개인으로 진행하는데 당분간은 2~3 팀 혹은 개인으로만 진행 예정
  • 아마 이것보다 더 우선순위에 있는 할 일이 생기지 않는 한은 우선순위 1번으로 진행할 듯 하다.

건강관리

  • 사실 운동을 한건 아니고 2년 정도 점심을 샐러드로 챙겨 먹고 있다.
  • 하지만 운동을 하지 않고 술도 자제하지 않다 보니 큰 효과는 없는 듯
  • 그래도 샐러드를 먹지 않으면 아채 과일 먹을 일이 없다보니 계속 챙겨 먹을 예정이다.

영화보기

  • 많은 영화를 보고 리뷰 글을 쓰고 있다.


이제 제대로 해야 할 것


건강관리


  • 고혈압 때문에 이제 운동을 제대로 해서 살을 빼야 한다. 내 몸을 너무 방치해 둔 듯
  • 기준은 아침, 저녁으로 시간을 내서 공원 걷기 운동 30분 하고, 좀 익숙해지면 달리기로 하던가 아니면 자전거 타기로 실천해 볼 예정이다.

공부

  • 머신러닝 딥러닝이 중요한 이슈다 보니 계속해서 공부해야 할 거 같다. 꾸준함이 중요.
  • 양자 컴퓨터 프로그래밍의 선구자가 없다 보니 시작을 하기 쉽지 않은데 조만간 번역서도 나오고 해서 이 역시 공부를 시작해 보려 한다.
  • 이게 만약 진행이 잘 된다면, 이 결과를 바탕으로 또 다른 계획과 목표를 실천하는 좋은 바탕이 될 것 같다.
  • 그래서 뭐든 기록이 중요하고, why에 대한 생각을 더 폭넓게 하며, 그로인해 얻는 가치가 무엇인지를 지속적으로 생각해야 한다.

Thursday, August 8, 2019

Machine Learning

작년부터 해서 머신러닝, 딥러닝에 대한 관심도가 높아짐에 따라 제대로 하지는 않고 이리 저리 알아만 보고 있었다. 책도 몇 권 보고, 스터디 모임도 참석해 보고 했지만 사실 내가 원하는 책이나 스터디 모임은 없었던 것 같다.

"뭔가 제대로 폭넓게 알 수 있는 방법"

이라는게 필요했다.

얼핏 보면 수학에 대한 이해도 필요해 보이고 data, visualization 라이브러리 사용법도 알아야 할 거 같은 이 분야에 대한 이해도는 상당히 부족한 상태였다.

그러다가 구글 스터디 잼에서 코세라 강의를 좀 맛본터라, 이렇게 시작하면 될 것 같다는 느낌이 들 때 쯤. 머신 러닝하면 한번쯤 이 강의를 들어야 한다는 인터넷 글이 많아서 바로 수강신청하고 보게 됐다.

https://www.coursera.org/learn/machine-learning

앤드류 응 교수의 강의인데 옛날에 만든 거라 영상과 음성 퀄리티가 썩 좋지는 않다. 그래도 듣다 보니 천천히 이해를 하고 진행할 수 있는 수준인 거 같아서 부지런히 공부 중이다.

사실 1주일에 3~4시간 정도만 투자해도 주당 강의 스케줄을 따라갈 수 있는데 그 시간을 내지 못해 강의 스케줄 따라가는게 쉽지 않다. 스터디 잼 때도 느꼈지만 주당 5시간 이상을 투자해서 뭔가 공부한다는게 쉬운 일이 아님을 다시 한번 느낀다.

어쨌든 코세라 강의를 통해 머신 러닝 공부도 하고, 인공지능이라는 타이틀이 붙은 개발자들과 대화가 가능한 수준으로 진행해 보려 한다.

자료는 github에 올려 놓고 링크를 걸어둘 예정이다.
사실 코세라 등록하고 보면 다 볼 수 있는데, 나중에 찾아볼 때 좀 쉽게 찾아보려고 하는 것도 있다.

Tuesday, August 6, 2019

WPF combobox background changes not work, apply combobox style windows 8 or later

combobox background 변경 시 변경 안되는 문제점에 대한 내용

https://blog.magnusmontin.net/2014/04/30/changing-the-background-colour-of-a-combobox-in-wpf-on-windows-8/

위 링크에 상세하게 설명이 되어 있는데 대충 내용을 얘기해 보면
Windows7 이전에는
  • SystemColors.WindowBrushKey
  • SystemColors.HighlightBrushKey
요 두 개의 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.

Thursday, July 25, 2019

Introduction to Augmented Reality and ARCore (4) - Bringing ARCore to life

Links
  1. Introduction to augmented reality (AR)
  2. The basics of AR functionality
  3. Taking the next steps with ARCore

Bringing ARCore to life


A Closer look at mechanics of ARCore

  • 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.

Ploy, a library of 3D assets for your AR app


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.


Introduction to Augmented Reality and ARCore (3) - Taking the next steps with ARCore

Links
  1. Introduction to augmented reality (AR)
  2. The basics of AR functionality


Taking the next steps with ARCore


Cloud Anchors for shared AR


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.


Use cases and current powers/limitations of AR

  • 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.

  1. 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).
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Introduction to Augmented Reality and ARCore (2) - The basics of AR functionality

Links

1. Introduction to augmented reality (AR)


The basics of AR functionality


What makes AR feel real?


Enables: motion tracking for AR

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.

Introduction to Augmented Reality and ARCore (1) - Introduction to augmented reality (AR)

사내에서 AR 스터디를 하는데, 코세라에서 조금 더 공부를 해 보고자 큰 맘 먹고 29$ 결제를 해서 듣게 되었다. ARCore는 부수적인 내용이고 사실 AR이 뭔지에 대한 이해 그리고 AR을 구현하려면 어떤 지식이 필요한지에 대해 이해를 하는 강의라고 보면 된다.

개발자인데 AR에 대해서 아무것도 모른다 싶으면 아래 Google AR VR 유튜브 채널에 가서 동영상 구경 몇 개 해 보면 뭔지 감이 올 것이다.

https://www.youtube.com/channel/UCkUZagbGbewp3bZQLXGzkmA

AR도 공부를 하다 보면 Unity 깔고 C# 코딩 부터 시작한다기 보다 optical & video 즉 computer vision을 공부한다는 느낌이 더 강하다. 마치 ML을 배우기 위해 python 먼저 코딩하는 것 보다는, math, data analysis, data modeling, data visualization 등을 이해하는게 더 중요한 것처럼.

강의 video는 완료하면 다시 볼 수 없으므로 각 주제별 summary text를 긁어서 정리를 해 볼까 한다.

해당 강의 링크
https://www.coursera.org/learn/ar

강의는 무료로 볼 수 있으며, 수료증이 필요하면 결제해야 한다.

Overview

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.

Types of AR experiences

  • Shopping and retail
  • Business
  • Social media
  • Gaming
  • Education
  • Healthcare
  • Nonprofits

Thursday, May 9, 2019

책 리뷰 - 커리어 스킬

Beginning


사실 책을 자주 많이 읽는 편이다. 그렇다고 해서 책 읽는 시간이 많은 건 아니고 출퇴근 시간이 조금 긴 편이다 보니 출퇴근 시간에만 책을 읽는다. 그 외에 시간에는 책 읽을 생각 보다는 코딩, 멘토링, 커뮤니티 활동 등의 시간을 써야 하기 때문에 책은 딱 출퇴근 시간에만 보게 된다.

어쨌든 여러 책을 많이 보다 보니 이런 것도 기록에 남겨두면 좋을 것 같아서 내 리뷰 블로그에 작년에 세 권 정도 간단한 리뷰를 썼는데, 실제 리뷰 쓴 책 보다는 훨씬 많은 책을 읽었기에 기록하고 공유하기 위해 이제 부터는 개발 블로그에다가 좀 제대로 써볼 생각이다.

커리어 스킬 - 10점
존 손메즈 지음, 이미령 옮김/길벗

존 손메즈 아저씨의 전작 <소프트 스킬> 보다 훨씬 더 책이 잘 나온 듯 하다. 왜냐하면 소프트 스킬의 경우 보기 싫었던 내용이 있었는데 헬스하는 내용, 부동산 내용 등 쓸데없다고 생각되는 내용들이 있었기 때문이다. 그런데 이번 커리어 스킬에는 그런 내용은 없다. 있긴 있는데 간단하게 언급할 뿐이다. 그 책에 이런 내용은 부적절하지 않냐는 민원이 제기되서 이번 커리어 스킬에는 안넣은 것일수도 있다는 느낌도 든다.

책 내용은 전반적으로 꽤 훌륭하다. 특히 이 분야에 아무것도 모르는 비전공자나 신입들이 보기에 좋은 내용들로 구성되어 있고 취업, 개발, 인간관계, 돈 버는 방법 등 여러가지 내용들을 총 망라했기 때문에 보면 좋을 듯 하다.

그리고 현업에 있는 사람들도 이 책을 보면 뭔가 얻는 내용들도 많을 것이다. 내 생각에는 가르치면서 배운다는 원칙을 이 책을 읽어서 알게 된것 뿐 아니라 실제로 실천도 해보면 좋다는 의견이다.

책 부록에는 사실 외국 개발 환경이 국내와는 안맞는게 있을 수 있기 때문에 국내 개발자들 인터뷰한 내용을 넣은 것 같은데, 첫번째 김요한 개발자를 제외한 뒤 세 개발자들의 내용은 취업 성공기에 한정되어 있어서 좀 다양하게 넣었으면 어땠을까 싶다.

내가 멘토링 해주는 사람들에게 이 책이 나오기 전에는 <프로그래머의 길, 멘토에게 묻다>를 추천했는데, 이번 커리어 스킬도 추천 책에 넣을 만 한듯 하다. 아니, 가장 추천하고 싶은 책이 될 거 같다.

책 읽은 기간


2019-04 ~ 2019-05

Wednesday, April 10, 2019

회사에서 하는 일을 잘 하는 게 자신의 개발 실력을 증명해 주지는 않는다. (2)


회사에서 하는 일을 잘 하는게 자신의 개발 실력을 증명해 주지는 않는다 (1)

---------------------------

그러면 실제 개발 실력이라는 것이 어디에서 오는 것인지 생각해 보자. 실력이라는 게 구체적으로 뭘 말하는 것인지 부터 인지해야 한다. 한자 그대로 실제 힘이라는 뜻이다. 좀 더 풀어서 말해보면 실제로 갖추고 있는 힘이나 능력 정도를 얘기하는 것일 것이다. 물리적인 힘은 눈에 보이기도 하고 어느 정도인지에 대한 감이 오는데, 소프트웨어를 개발하는데 나오는 실력이라는 건 눈에 보이지도 않을 뿐더러, 주니어 개발자가 만들던 시니어 개발자가 만들던 만들어 놓은 결과물의 차이가 크게 없어 보인다면 실력을 가늠하기가 쉽지 않은 건 사실이다.

Not 코드를 짤 줄 아는 능력, but 코드를 볼 줄 아는 능력


잘 모르는 사람은 이게 실력이라고 생각할 수 있는데 오히려 코드를 볼 줄 아는 능력이 실력일 가능성이 높다. 왜 그런가 하면 주력 언어가 있고 익숙하면 어느 정도 좋은 개발 도구의 도움을 받아 어느 정도까지는 코딩이 가능한데, 그 이상은 사실 좋은 코드가 있는 구글의 도움을 받아야 하는게 사실이다. 남의 코드를 가져와서 짜는게 실력이 아니라고들 하지만 남의 코드를 가져오기 전에 볼 줄 아는 혜안을 가졌다면 가져와서 붙여넣고 만들어 나가는 건 큰 문제가 아니라고 본다. 즉 코드를 가져오는 능력의 기본은 코드를 볼 줄 아는 능력이 뒷받침 되어야 한다는 뜻이다. 또한 코드를 볼 줄 아는 능력을 갖추고 있다는 건 문제를 해결하는 방법을 알고 있거나 찾고 있다는 뜻이기도 하다.

Not 동작하는 코드에 대한 만족, but 품질을 결정하는 요소를 실천하는 능력


역시 잘 모르는 사람은 동작하는 코드를 짤 줄만 알면 되고, 그 코드가 크게 문제가 없다면 그냥 두는 걸로 만족한다. 하지만 동작하는 코드만 짤 줄 아는 능력은 이 바닥에 들어온 사람이라면 당연히 해야 하는 걸 했을 뿐이다. 즉, 동작하는 코드를 짜지 않고는 일이던 뭐던 진행이 안되기 때문에 당연한걸 해 놓고 당연하다고 하면 어떻게 반응해야 할지 잘 모르겠다. 동작하는 코드를 짰는데, 그걸 잘 다듬고 보듬어 줘서 이후 테스트가 엄격하게 통과가 되는 원칙을 잘 지키는 코드로 만들어 나갔는지 혹은 유지보수와 기능 추가가 유연한 설계를 바탕으로 만들어진 코드였는지에 따라 소프트웨어 품질이 결정된다. 그러니까 이런 품질에 대해 고민하지 않고 만족하는 개발자는 실력이 있다고 보기 어렵다는 얘기다.

Not 회사에서 해야 하는 일에 대한 성과, but 개인이 정말 해보고 싶은 걸 해본 결과


실무 경력은 사실상 실무 경력일 뿐이다. 관련된 업무를 경험해 봤고 해 봤으니 동종 업계에서 하는 비슷한 일을 잘 이해하고 해낼 수 있는 것 정도가 전부인 것이다. 업무 프로세스 이해를 잘 해서 일을 잘 해 나가는 능력은 사실상 개발 실력하고는 크게 상관이 없다. 단, 일을 해 나가면서 조금씩 다른 구현을 시도해 보고 다른 설계를 해서 평소에 알고 있던 방법 외에 이런 저런 실험도 해 보고 하면서 진행했다면 괜찮을 수 있는데, 지금 알고 있는 범위 내에서 해야 하는 일만 했다면 그 이상을 보지 않고 일을 해 왔다는 것이고, 그건 개발 실력이 향상되지 않았다는 뜻이기도 하다. 진짜 실력을 키워 보려면 자기가 따로 해보고 싶은 쪽의 분석, 설계라는 단계를 잘 거치고 문서화를 잘 해 놔서 개발을 진행해 본 경험이 있어야 조금 더 많은 걸 볼 수 있다는 뜻이다.

그러면 정말 실력은 어디서부터 오는 것일까?


보통 회사에서 하는 일은 개발, 그러니까 기능의 구현에 많은 초점이 맞춰저 있는데 문제의 해결력 보다는 구현의 방법에 대한 스킬만 늘어날 뿐이고 누군가 문제를 주면 해결을 하지 못한다. 더 나가서 해결 못할 뿐만 아니라 그걸 자기가 해야 하는 일이 아니라고 생각한다. 그럼 누가 하느냐? 기획자가 해야 할 일이라고 한다. 기획자? 기획자는 개발을 하는 사람이 아니다. 오히려 문제를 만들어내는 사람이지 해결하는 사람이 아니다.

그런 문제를 해결하는 사람은 소프트웨어 개발자가 해야 할 일이며, 문제가 주어지면 잘 이해하고 분석해서 소프트웨어로 어떻게 만들면 좋을 지에 대한 설계는 사실 훈련을 많이 해야 한다. 단순히 코드를 잘 짜는 게 실력이 아니라는 뜻이다. 그런 분석 설계에 대한 훈련을 해서 그 문서를 도출해 내고 그걸 바탕으로 개발을 진행해 보면 다시 분석, 설계가 잘 되어 있는게 중요하다는 걸 뼈저리게 느끼게 된다. 이쯤에서 분석 설계에 들여야 하는 시간이 코딩하는 시간보다 많아야 한다는 걸 깨닫게 된다면 말 그대로 소오름이 돋을 것이다.

그래서 내가 정의하는 개발 실력이란


"주어진 혹은 해결해야 할 문제를 잘 분석하고
그걸 소프트웨어로 잘 만드려면 어떻게 해야 좋을까 하는 고민을 자신의 경험과 역량을 모두 쏟아내서 설계를 잘 해 내고
버그와 문제가 없는 코드를 작성해서
예상한 기간 내에 만족할 만한 수준의 결과를 내고
이후 추가 기능 개발 혹은 버그 수정이 잘 될 수 있도록
퀄리티 있는 소프트웨어 제품을 만들어 내서
이 소프트웨어를 쓰는 사람의 만족도를 높이고
계속 사용할 수 있는 소프트웨어로 만들기 위해 생명을 불어 넣을 수 있는(엔지니어링을 할 수 있는) 능력"
이라고 얘기하고 싶다. 아홉줄에 걸쳐서 썼는데 코딩 얘기는 한 줄 밖에 없다는 점에 주목하자.

분석은 문제 해결 능력에 가깝다. 실제 만들어 내야 하는 소프트웨어 요구에 대한 내용을 잘 이해하고 정리해서 소프트웨어로 만들어 낼 수 있도록 각을 잴 수 있는 능력이 요구된다. 이게 사실 제일 어렵다. 여기에서 실력이 가늠되기도 하는데 세상의 많은 문제를 소프트웨어 시스템으로 만들기 위한 요구를 분석해 내는 경험을 많이 하는 수 밖에 없다. 이건 경험치로 가늠할 문제지, 공부의 양으로 가늠할 수 있는 문제는 아니라고 본다.

설계는 사실상 소프트웨어를 만들기 이전에 잘 만들어 놔야 할 시스템 구성, 모듈간의 통신, 잘 정의되어야 하는 명세, 실제 데이터의 구성, 프로세스에 따라 데이터가 어떻게 흘러가는지에 대한 내용, 사용해야 하는 라이브러리나 프레임워크, 그걸 기반으로 지켜야 하는 기본적인 원칙, 테스트를 해야 하는 방법, use case, GUI 화면 인터페이스 등 소프트웨어를 개발하는데 필요한 모든 요소 대한 걸 몽땅 만들어 놔야 하는데 있다.

이 두 가지를 잘 하면 코드로 소프트웨어를 만들어 나가는 건 본인 역량 껏 해 나가면 된다. 주니어는 조금 더딜 것이고 시니어는 경험자이므로 상대적으로 빠르게 만들어나갈 수 있다. 이게 실력의 차이 아닌가? 라고 생각된다면 여태 내 글을 잘못 읽은 것이다. 주니어는 상대적으로 분석, 설계에 대한 경험이 없기 때문에 분석, 설계에 대한 결과를 잘 못 뽑아낼 가능성이 높고 잘 못 만든 설계서로 날고 기는 코드로 짜 봤자 원하는 소프트웨어의 기능을 만들어 내지 않았거나 못했다면 엄한테 힘쓴 꼴 밖에 되지 않기 때문이다. 여기서 구현에 관련된 부분 예를 들면 리액티브 프로그래밍 기법으로 짰느니 객체지향적인 방법으로 짰느니 하는 얘기를 해 봤자 아무 쓸모도 없다는 얘기다.

<흔히 볼 수 있는 생명주기에 대한 그림, 이런 그림을 이해하는게 실력하고 상관이 없다고 생각하는가? 그러면 진짜 소프트웨어를 이해하고 만들어 본 경험이 없을 가능성이 높다고 본다.출처: Introducing Systems Analysis, Design & Development Concepts>


전공자라면 소프트웨어 공학을 배웠을 것이고 거기에서 필요한 요소가 뭔지는 다들 배웠을 것이다. 이제 코드를 잘 짜는 능력만을 개발 실력이라고 착각하지 말고 전체 소프트웨어 생명 주기를 잘 이해하고 세상 혹은 내가 만들어 낸 문제를 훌륭한 소프트웨어로 만들려면 어떻게 하면 좋을지 고민해 보자.

나는 이걸 잘 해낼 수 있는 개발자가 진짜 실력을 갖춘 개발자라 보고 싶다.

Tuesday, April 2, 2019

사수가 꼭 필요하다고 생각하는 사람들에게

보통 이 바닥에서 사수라고 하면

  • 같이 일하는 사람인데 업무 프로세스를 이해하고 먼저 하고 있던 사람
  • 같이 일하는 사람인데 업무에 필요한 기술에 대해 경험해 보고 잘 아는 사람 (실제 아닐 수도 있는 건 함정)
  • 같이 일하는 사람인데 그 업무를 같이 진행하거나 다른 업무를 하더라도 기술적으로 뭔가 나에게 알려줄 수 있는 위치에 있는 사람 (대부분 여기에 해당)
이런 사람일 것이다.

<사수-부사수의 정석
출처: 국방홍보원 블로그>

개념은
군대에서 사전적 의미로 총을 쏘는 사람인데 보통은 2인 1조 경계 근무에서 지시하는 사람: 사수, 지시를 받는 사람: 부사수에서 사수를 의미하는 것이다. 그래서 보통 경험이 있는 선임들이 이제 경험을 쌓아야 하는 신병과 함께 조를 이루어서 일에 대해 배우고 경험하고 또 문제 생기면 감싸줄 수 있는 사람이다 보니 일반 사무실에서도 같은 개념으로 쓰고 있다.

그런데 개발에서는 일단 사수가 있는게 좋다라는 의견에 반대하는 편이다. 물론 사수가 있다면 일도 배우고, 자신의 부족한 부분을 보고 배울 수 있는 walk-through 개념으로 받아들이면 일 하기가 한결 수월하다는 점에서는 좋을 수 있다. 그게 개발이 아닌 쪽 그러니까 군대나 기타 다른 일에는 한 조로 움직여서 동일한 업무를 수행하니까 맞는 개념인데, 개발은 같은 개발을 둘이 동일하게 하지는 않는다. 

즉, 보통은 같은 프로젝트 내에서 일을 해도 큰 부분에 일부분을 맡아 개발을 하던가 아예 다른 모듈이나 파트 (예를 들면 프론트, 백엔드)를 맡게 되는 경우가 많으므로 사수한테 배운다라는 것이 잘 되지 않을 경우가 많다는 것이다.

그러면 "어차피 프로젝트는 달라도 같은 팀 내에서라면 같은 기술을 쓸 텐데 그러면 기술이라도 배울 수 있는 거 아니냐?" 라고 생각할 수 있다. 좋은 개발 문화가 정착된 회사라면 코드 리뷰나 포스트 모멘텀 발표, 페어 프로그래밍 등을 통해 공유하고 배우고 할 수 있는데, 거의 보통은 자기 할 일 바쁘다 보니 대충 찾아봐야 할 키워드 정도만 공유하고 알아서 찾아서 해야하는 일이 더 빈번하게 일어난다. 그리고 보통 사수라 불리는 사람들은 바쁜 사람들이기 때문에 신입들에게 세세한 관심이나 케어를 해주기가 힘들다.

결국 사수가 하는 역할은 같이 일 하는 사람인것 뿐인데, 조금 업무를 먼저 해본 사람 + 기술적으로 먼저 실무에 써본 사람인 것 뿐이고 삽질 방지를 위한 키워드 던져주기 + 가이드 역할 정도가 사수 역할의 전부라 할 수 있다. 또 업무 프로세스 익히는 것도 신입의 경우도 대략 3~6개월 정도면 사수가 안알려줘도 자연스럽게 파악이 가능한 부분이기 때문에 사수가 굳이 알려주지 않아도 된다.

오히려 사수가 있을 경우 내가 개발하는 일에 더 방해가 될 가능성도 있는데, 방치형 사수일 경우는 문제가 없으나 오지랖 부리는 사수일 경우는 갈굼 + 쓸데없는 관심 + 삼천포로 빠지는 잡담으로 인해 오히려 일 하는데 방해가 되기도 한다. 갈구는 사수라도 있는게 좋다라는 이상한 생각을 가진 사람도 있는 걸 봤는데, 절대 도움되지 않으며 어차피 그 사수도 사수한테 배운게 아니라 자기가 구글 검색이나 별도 스터디를 통해서 알게 된 걸 알려주는 거 정도 밖에 안되므로, 꼭 사수한테 배울 필요도 없다.

결론은
사수한테 뭔가 배워야 겠다는 생각 보다는, 내가 알아서 배워서 사수나 팀원들과 함께 목표를 달성하기 위한 일에 집중하고 그 일원으로써 노력하는 모습을 보여주는게 훨씬 좋다는게 내 생각이다.

단 한명의 개발자가 있다고 하더라도 스스로 주늑 들어서 사수가 있어야 한다는 생각에 사수를 정하고 본인 스스로 부사수를 자청하지 말고 각각의 동등한 입장에서 함께 일하는 co-worker 개념으로 생각하고 일하는게 맞다고 본다.

단 한가지 예외 사항이라면, 회사에 직원 중에 개발자는 아무도 없고 나 혼자 개발자라면 문제가 있을 가능성이 높다. 애초에 그런 회사에 들어가면 혼자 개발 관련된 걸 모두 혼자 해 나가야 하기 때문에 방향성을 잃을 가능성이 높다. 최소한 내가 개발이 뭔지 알고 일 진행을 어떻게 하는 지 알아서 개발의 방향성은 잃어버리지 않는다고 하더라도 개발을 잘 모를 가능성이 높은 영업, 디자인, 대표 등등의 사람들에 의해 개발일이 쉽게 휘둘리는 건 시간 문제기 때문에 그런 곳은 비추한다.


Thursday, March 28, 2019

저는 xx개발자입니다. 나를 소개할때 어떤 분류로 하는가.

사람들 마다 내가 무슨 개발자인지 얘기할 때가 있다. 그런데 그 소개하는 방법이 일관적이지 않고 저마다 다르다. 어떤 개발자가 있는지 유형을 한번 살펴보고 올바르고 소개하는 방법에 대해 생각해 보고자 한다.


특정 프로그래밍 언어로 자신을 소개


이게 제일 흔한 방법인데,
"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년 내내 한가지 언어와 한가지 플랫폼에서만 개발했을 가능성이 매우 적으므로 잘 소개해야 할 필요가 있다고 본다.

Friday, March 22, 2019

코딩이 어려운 이유? 문제는 공교육식 프레임

코딩, 프로그래밍, 소프트웨어를 개발하고 배우는데 다들 어렵다고들 한다. 이건 전공자, 비전공자 가릴 문제도 아니다. 그런데 처음 배우는 거는 누구나 다 어렵다. 어렸을 때 부터 지금까지 새로운 걸 보고, 듣고, 배우는게 쉬운 사람이 있었던가? 만약 있었다고 자신있게 말할 수 있다면 탁월한 재능을 가진 사람이라고 말하고 싶다.

(이제부터 코딩, 프로그래밍, 소프트웨어 관련된 단어는 개발로 통일해서 얘기한다.)

다시 잘 생각해 보자. 개발을 하는 게 왜 어려운지. 한번 더 잘 생각해 보자. 잘 생각해 보면 어려울 이유가 없다. 개발에 대해 아주 쉽게 설명한 글들이 인터넷에 널려 있고, 특정 기술 관련된 따라하기 책들은 한달이 멀다하고 마구 쏟아져 나온다. 유튜브 동영상도 있고, 같이 공부하는 학원, 학교, 회사 사람들과 함께 하면 어렵지 않은 이유를 찾는게 더 쉽다고 말할 수 있을 정도다. 그런데도 개발 하는 걸 배우는 사람들은 이해하는 것도 어려워 하고 뭔가 잘 와닿지 않아서 어려워 하고, 자신의 학력탓, 비전공자 탓, 나이탓, 수준탓을 하면서 어려워 한다. 어쨌든 어려워 한다는게 핵심이지 않겠는가?

난 이 이유가 어디에서 부터 오게 되었는지 오랜 시간 생각해 왔다. 같은 걸 배우고 하는데 수준차이가 나는 이유도 찾아 봤고, 과외, 온라인 강의 하면서도 찾아 봤다. 최근에 멘토링 하면서도 찾아보고, 인터넷 까페에 올라온 수 많은 게시글에 댓글을 달아 주면서도 많이 생각해 봤다.

그 결과 프로그래밍 하는 걸 어려워 하는 이유는 거의 아래와 같은 내용들로 수렴된다는 결론을 얻을 수 있었다.
  1. What의 문제: 뭘 해야 하는지 모른다. 
    • 공부를 하는 방법을 모른다. 코딩하는 방법을 알면 잘 하게 될 거라 믿는다.
    • 어떤 개발을 하는게 즐겁고 재미있는지 잘 모른다. 이유도 단순히 취업이 잘되는지, 돈을 많이 벌 수 있는지에 집중되어 있다.
  2. Why의 문제: 왜 어려운지 판단하지 못한다.
    • 내가 이해를 잘 못해서, 책이 쉽지 않아서, 내가 게을러서 등등 핑계는 찾을 수 있는데, 왜 어려운지에 대한 근본적인 의심을 잘 안한다.
    • 자신이 가진 궁금증에 대한 해결을 다른 사람에게만 의존하려 한다. why에 대한 생각의 흐름 정리를 스스로 하지 못한다.
  3. How의 문제: 어떻게 하는지에 대한 궁금증만 가득하다.
    • 하루아침에 뭔가 쉽게 되는게 아닌건데도 되는 방법만 찾고 싶어 한다.
    • 거기서 뭔가 조금만 더 고쳐서 해보려고 해도 계속 how to의 문제로만 귀결된다.
    • how to에 대한 것만 하고 싶어 하다 보니, what, why에 대한 중요성의 인식이 상대적으로 떨어진다.

여기에 있는 내용을 다시 종합해서 보면 근본적인 학습 방법에 대한 훈련이 안되어 있는게 결론이다. 스스로 궁금증을 가지고 문제를 만들고 해결해 나가는 과정에서 학습하고 그 결과를 문서/사진/동영상 등으로 리포트 하고 review를 하는 활동을 학교에서 잘 하지 않았기 때문이다. 사실 이런 활동들을 해야지 개발을 할 수 있는 훈련이 되는 것이고, 그렇게 해 나가야 조금씩 성장이라는 걸 할 수 있는 건데, 어렵다 => 못하겠다 => 남들한테 물어본다 => 내가 안한다 이런식으로 흘러가다 보니 잘 하고 싶은 생각은 충만한데, 그냥 시간만 흘러가게 된다.

이런 안좋은 마음가짐들은 모두 공교육에서 나왔다고 본다. 공부를 하는 이유는 성적 관리를 위해서이고, 공부를 하는 즐거움은 없다. 또 어떻게 공부하느냐에 대한 문제도 범위가 정해져 있고 방법도 널려 있기 때문에 내가 고민할 필요가 없다. 내가 점수를 내기 위한 시간 투자와 점수를 내기 위한 방법을 잘 아는 학원이나 과외를 받으면 되기 때문이다. 어쨌든 뭔가 문제를 해결하려는 생각의 정리나 리뷰, 발표 이런 활동 위주로 하지 않았으니까 주어진 시험범위 내에 문제를 풀고 점수를 얻어 평가를 받아 등급이 매겨지면 내가 잘 하는 사람이 맞겠지라는 생각만 가득한 것이다. 그렇게 10년 이상을 반복해서 살아온 사람들이 갑자기 그런 패턴이 아닌 활동을 하려고 하니 비단 코딩 뿐만 아니라 어떤 분야를 하던 어려운게 맞을 것이다. 

이제 주어진 범위의 지식을 단기간 알고 있다가 점수를 내는 방식으로 평가를 받는 방법의 공부를 하지 말고
내가 해결하고자 하는 문제를 만들고 그걸 해결해 나가기 위한 탐색, 고민, 분석, 설계, 생각, 정리, 깨달음, 발표, 피드백, 리뷰, 기록을 가능한 수준부터 해 나가 보자.
지금 이렇게 하는게 늦은거 같은데 제가 이걸 할 수 있을까요? 같은 이상한 질문 하지 말고 일단 해보자. 공교육식 프레임을 깨고, 성장을 위한 활동 프레임을 씌우자. 지금 부터 몇 개월 몇 년 후를 돌아봤을 때, 아무것도 안한걸 후회하지 않게 지금 당장 해야 한다.

늦었다고 생각할 때는 진짜 늦은게 맞을 수 있다.
하지만 늦었다고 해서 아무것도 하지 않는건 잘못된게 맞다.

Thursday, March 14, 2019

프로그래머가 되기 까지의 회고 (5) - 복학 후 각성할 때 까지

프로그래머가 되기 까지의 회고 (1) - 초등학교 시절
프로그래머가 되기 까지의 회고 (2) - 중고등학교 시절
프로그래머가 되기 까지의 회고 (3) - 대학 입학 부터 군 입대 전까지
프로그래머가 되기 까지의 회고 (4) - 군 시절

----

2001년 복학 했을 당시에도 공부를 열심히 하지 못했던 것 같다. 막연한 진로는 게임 프로그래머이긴 했지만 자신이 없었다. 당장 수업듣는 과목들도 자료구조, 마이크로프로세서, 이산수학 등 또 이론적인 과목들 뿐이었고 과제로 내주는 C 언어 프로그래밍은 동기나 후배들꺼 보고 겨우 이해해서 수정해서 내는 수준이었다.

지금은 상상할 수 없지만 그 당시만 해도 강의실에 흔한 빔프로젝터나 PC 같은게 있지 않았었다. 새로 지은 건물에는 구축이 되어 있었지만 80~90년대 부터 쓰던 강의실에는 그런걸 설치해 두지 않아서 누군가 수업시간 전에 빔 프로젝터와 노트북PC를 세팅해야 하는 일을 해야 했다. 물론 과대라 읽고 심부름꾼(시다바리)이라 쓰는 사람이 한다.

사실 과대가 될 생각은 해보지도 못했고 전혀 그런걸 할 생각도 없었는데, 어떤 계기로 인해 졸업할 때 까지 과대 혹은 반장이 되었다.

복학 후 자료구조 첫 수업 시간이었다. 지금도 그러는지 모르겠는데 첫 수업 시간은 대략적인 강의 설명, 리포트, 과제, 시험방식 점수 산정 방법 등등을 설명하고 1시간이 채 되지 않은 시간에 끝냈는데, 그때도 그랬다.

교수님이 대충 설명 끝날 때 쯤에 매 수업시간 마다 빔프로젝터와 노트북PC를 세팅할 사람(호구) 손 들라고 했다. 물론 아무도 손을 들지 않았다. 교수님이 혹하는 제안을 했는데 무려 2만원에 달하는 자료구조 책을 준다고 했다. 그래도 아무도 손을 들지 않았다. 무슨 생각이었는지 그 책을 그냥 갖고 싶다는 생각이 들었다. 그래서 손을 들었는데 바로 당첨되었다.

그후 모든 수업마다 내 동기들과 후배는 이런 일을 할 사람을 찾는 교수님의 눈빛을 보면 "반장~"을 외쳐댔고 그게 내가 되었다. 그렇게 계속 심부름 하면서 다니고 과대도 되었다. 그렇게 졸업할 때 까지 우리 반의 충실한 심부름꾼이 되었다. 기억에 남는건 학교에서 주는 용돈 수준의 과대비와 교수님과 동기 후배들의 잡일 처리였다. 아직도 나를 부르는 동기들의 목소리가 머릿속에 맴돈다. "반장~!"

<얘네들이 하는 말 믿지 마.
왜요?
그냥 믿지마!
저 이미 과대인데요?
빨리 탈출해 어서!
출처: http://young.hyundai.com/magazine/campus/detail.do?seq=16532>

이제 개발 얘기를 해 보자면, 2학년도 마치고 3학년이 되었지만 난 여전히 그저 그런 흔한 컴공생이었다. 과제는 점점 더 어려워지고 있었고 배우는 프로그래밍 언어도 C에서 JavaScript, C++ 등 해야 할 게 더 많아졌다. 더 하기 싫어져서 PC방에서 게임하던가 동아리방에서 놀던가 하는 걸로 시간을 보냈다. 지금 생각해 보면 그렇게 시간낭비를 하지 말았어야 했지만, 그때는 코딩이 너무도 하기 싫었고 코딩 안하는 과목 쪽에 눈을 많이 돌렸다. 소프트웨어 공학이라던가 데이터베이스와 같은 과목들.

그러던 중 프로그래밍에 눈을 조금 뜨게 된 중요한 계기가 몇 있었다. 객체지향 프로그래밍이라고 해서 C++의 class 개념을 추가해 객체지향적인 프로그래밍 과정을 이해하는 과목이 있었는데 초반 과제는 그럭저럭 했다. 그러나 중반 이후가 되니까 class, object 에 대한 이해를 하지 못하면 C언어로 짜듯이 주먹구구식으로 할 수 밖에 없고 결국 할 수 없는 수준이 되다 보니 정말 시간을 내서 이해를 해야 할 시간이 닥쳐오게 됐다.

내가 제대로 모르고 하는 부분이 뭐가 있는지 탐색해 나가다 보니 결국 포인터 부터였다. 그래서 연습하고 이해하고 연습하고 이해하고를 학교 실습실, 집에서 계속 반복해 가면서 이해해 갔다. 변수 이름 앞에 * 붙였다가 뗐다 하면서 오류 나는지 확인하고, 역시 & 붙였다 뗐다 하면서 오류 나는지 확인하고를 계속 반복하면서 알아보고 스스로 깨닫고 이해해 나갔다. 어떤 날은 새벽까지 집에서 그 짓을 하고 있을 때도 있었고 그 동안 스스로 하지 못했던 과제들을 포인터를 쓰고 안쓰고의 차이를 직접 해 보면서 알아 가기도 했다. 학교에서는 오후 늦게쯤 항상 가던 동이리방도 안가고 실습실에 야간 수업 들으러 오는 친구들 수업 시작하기 전 까지 몰입해서 했을 때도 있었다. 이러다 보니 야간반 애들하고도 안면이 트고 친해지는 계기도 되고 야간반 과대랑 졸업여행 계획도 같이 세우게 된 좋은 계기가 생긴것도 덤이긴 했다.

한 2주 지나고 보니 포인터의 규칙이 선명해 지면서 다른 모르는 부분들도 조금씩 이해가 되기 시작했다. Swap 함수가 왜 포인터의 주소로 념겨지는지, 함수의 포인터를 왜 넘겨주는지도 알게 되었다. new를 하면 메모리가 heap에 생기고 포인터 주소를 잃어버리면 어떻게 되는지 등. 학기 마지막 쯤 되니까 이미 1, 2학년 때 배우고 알고 있어야 하는 걸 그제서야 알았다. 사실 남들보다 한참 늦게 알게 된 것이다.

<이런 원리도 모르고 이해도 못한 채 코딩을 했던 시절이 있었다는 것이다.
출처: https://slideplayer.com/slide/5097101/>

목돈도 굴리려면 종자돈을 마련해야 한다는 얘기가 있듯이, 포인터에 대한 개념과 이해라는 종자돈을 잘 챙겨 두니까 이후에 파일 입출력 같은 것들도 목돈 불리듯이 술술 풀리게 되었다. 이 때 부터 내가 스스로 "각성"이라 불리는 상태에 돌입했던 것 같다. 학기 마지막 과제가 자동판매기 시뮬레이터였는데, 그걸 class 구조로 짜 나가면서 이해를 하기 시작했고, 새벽에 후배들과 문자 메시지를 주고 받으면서 설명해 주고 자랑(?)도 하고 그랬다.

그 열기는 여름방학 때에도 계속 이어갔다. 그 당시에는 Win32 API나 MFC로 Window 프로그래밍을 하는게 대세여서 후배들과 학교에 모여 스터디도 하고 C++ 관련된 책도 읽다 보니 STL이나 Effective c++ 같은 책들도 같이 보게 됐다. 2학기가 되고 나서 부터는 왠만한 과제는 스스로 배우고 풀기 위해 시간을 더 쓰게 되었고 어떻게든 혼자 힘으로 해결해 보려고 애썼다.


<Java 수업 시간에 class와 객체지향 개념 조금 알려준 후에 교수님이 과제로 내준 게, 스네이크 게임 만들기였다. 그때만 해도 말도 안된다고 생각했는데, 하다 보면 또 좋은 훈련이 되기도 한다.
출처: 위키피디아 뱀 게임>


교수님들이 내주는 과제는 너무 빡셌지만 그럴 때 마다 해내려고 하다 보니 재미도 생기고 자신감도 생기고 그랬다. 2학기 때는 Java도 했는데, 빡센 Java 과제를 해 나가면서 C++과는 또 다른 객체지향 개념에 대해 이해를 해 나갔고, 2학기가 끝나갈 무렵이 되자 어렴풋이 다음과 같은 느낌을 받았다. 이제 프로그래밍 문법 몰라서 못하는 수준은 아니고 튜토리얼이나 API 문서 같은거 보고 조금 따라 쳐본 후에 계속 API 참고 해 가면서 해 나갈 수준 까지는 됐던 것 같다.

거의 1년이 채 안된 기간 안에 많은 걸 이루어 냈다. 객체와 메모리 덩어리들이 머릿속에서 array, sort로 움직이고 포인팅하는 화살표 선이 이어지는 상상까지 할 수 있을 정도였고, 이제 내가 대학에 온 이유를 실현하기 위한 마지막 힘을 쏟기 위해 3학년 2학기가 끝나갈 무렵 게임 프로그래밍 학원 6개월 과정도 다녔다.

Tuesday, March 5, 2019

마스터의 경지, 그게 있기는 한가?

초급자의 흔한 착각


코딩하는 방법을 이제 막 배우는 입장에 있는 사람들은 흔히 자기가 하고 있는 프로그래밍 언어를 마스터를 해야 한다고 생각한다. 프로그래밍 언어를 마스터 해야 한다는 것도 착각일 수 있지만 그건 논외로 하고 어쨌든 마스터를 해야 한다는게
  • 일정 기간을 공부하면 된다는 걸 얘기 하는 건지
  • 알고리즘이나 기타 코딩을 빠르고 정확하게 잘 짜는 능력을 얘기하는 건지
  • 해결해야 하는 문제를 빠르고 정확하게 인지해서 해결 방법을 아는 걸 얘기하는 건지
  • 내가 모르는 걸 물어보면 대답을 잘 해 주고 친절하게 설명해주고 알려주는 사람을 얘기 하는 건지
기준이 없다. 그러니까 그냥 내가 모르는 걸 잘 알고 있는 것처럼 보이거나 나보다 조금 더 오래된 경력을 가진 사람이면 마스터의 경지에 다다랐겠지 생각하는 경향이 있다. 아무도 그런 기준을 정하지도 않았고, 뭔가 좀 잘 하는 사람들이 "내가 XX 프로그래밍 언어를 마스터 했다" 라는 말도 잘 안하는데 우리는 마스터의 경지, 고수 이런 경지가 있는 것처럼 생각한다.

그리고 그 좀 잘 해 보이는 사람에게, 어떻게 하면 잘 할 수 있는지 방법을 알려달라고 하지만, 뭔가 시원하고 가슴에 확 와닿는 대답을 해주는 사람이 없다.

이쯤 되면 빨리, 아 내가 뭔가 착각하고 있구나 라고 판단하고 그 혼란스러운 생각을 벗어 버려야 하는데, 시간이 지나도 자신은 잘 못하는 사람이고 이걸 마스터를 하지 않았기 때문에 삽질하고 있다고 생각한다. 또 이 분야를 마스터를 해야 내가 잘 하는 사람이 될 수 있을 거라는 생각만 계속 한다. 그리고 뭔가 액션을 취하지도 않는다.

언제까지 배우면 마스터를 할 수 있는지


제발 이런 쓸데없는 질문은 이제 그만 했으면 좋겠다. 자신의 학습 능력, 기억력, 사고력, 집중력, 이해력, 판단력 등등 객관적인 데이터나 상황에 대해서는 일절 알려주지도 않고 질문을 하면 대답을 해 줄수가 없다. 심지어 자기 자신도 잘 하는지 못하는지도 잘 모르면서, 이  막연하고 어렵고 힘들어 보이는 프로그래밍 공부를 사람들이 얘기해준 기간만 버텨내면 마스터의 경지에 다다를 수 있는지 알고 싶어하는 것 같다. 항상 그렇다. 이 공부를 언제까지 하면 되는지에 대한 궁금증을 풀기 위해 초급자들이 하는 질문 중에는 아마 부동의 Top 1일 것이다.

그걸 남들에게 물어보면 대답이 천차만별일텐데, 대충 그 대답의 평균 기간을 자기 자신한테 적용해 보면 될 거라고 생각하는 것 같다. 게다가 그 중에 제일 짧은 기간을 얘기해 준 사람의 말을 듣고 스스로 희망고문의 덫을 씌운다. 그래 X개월 하면 나도 잘 할 수 있을 거야라고.

그런데 이 생각을 가진 사람을 잘 살펴보면 공부라는 걸 제대로 해본 사람이 아닐 가능성이 높다. 열심히 해야 하는건 알겠는데 하기는 싫고 부지런 해야 하는 것도 알지만 막상 하기 귀찮고 게을러 지게 되고 핑계거리만 찾아서 자기 합리화만 한다. 그리고 그 막연한 마스터의 경지에 대한 질문만 계속 하는 것이다. 그리고 언젠가 이 고통스러운 시간이 지나면 마스터가 되어 있을 거라고 꿈을 꾸는 것 같다. 그래서 기간에 계속 집착하고 있는 것이다.
  • 누구는 학원 6개월을 다니면 될거라고 한다.
  • 누구는 독학으로 1년 정도 하면 될거라고 한다.
  • 누구는 3년을 했어도 아직 잘 모르는게 있다고 한다.
  • 누구는 평생 공부한다는 생각을 가지고 해야 한다고 한다.

누구 말이 맞는 말일까? 누구 말이 맞는 말일까 고민하는 거 부터가 잘못됐다. 그리고 나는 절대 그런 마스터의 경지는 없다고 자신있게 얘기할 수 있고, 그렇기 때문에 기간을 논하는게 무의미하다고 얘기해 줄 수 있다.

그러면 어쩌라는 건지?


일단 답답하고 짜증나는 심정은 이해하나, 이 분야가 아니더라도 뭔가를 잘 하기 위해서는 조금씩이라도 꾸준히 뭔가를 해 나가야 하는게 정답에 근접한 대답이라고 본다.

하루 아침에 갑자기 짠 하고 잘 하는 사람이 없듯, 뭔가 대단해 보이는 짓을 하는 사람들을 잘 살펴보면 계속해서 흥미를 가지고 꾸준히 해 왔던 사람들이라는 얘기다. 사실 본인은 그런 활동을 하지 않았으면서도 그런 마스터의 경지를 찾아 방황하고 있었으니 욕을 한번 들어 먹을만도 하다.

이제 뭔가 느껴지는게 있다면 제대로 차근차근 자신에게 맞는 방법을 찾아 나가는 것이 맞다고 본다. 또 다른 사람의 의견을 들어봐도 좋다. 사람마다 각자 해 왔던 방식이 다르므로 참고 정도만 하는게 좋고, 자기 스스로 맞는 방법을 찾아 나가야 한다. 누구나 꿈꾸는 것은 쉽지만 꿈꾸는 수준에 도달하기 위해서는 작은 실천의 발걸음을 한 발자국이라도 옮겨야 하지 않겠는가?

그래도 가르침을 주십시오! 라는 질문에는 대충 뭘 해야 하는지는 정해져 있긴 한데 잘 하려고 꾸준히 노력하려는 마음과 의지를 탑재한 후 실제 실천을 통해 연습하고, 정리하고, 발표하고, 공유하고, 피드백을 주고 받고, 이해하고 하는 활동들을 해 나가면서
  • 내가 이 일에 흥미가 있는지
  • 적성에 맞다고 생각하는지
  • 성취감 이라는게 있었는지
  • 꾸준히 하고 있는지
이런 걸 가끔 돌이켜 생각해 보면서 진행해 나가면 어느 정도 답을 얻을 수 있다고 본다.

최소한 이런 활동을 한 후에 다시 선배들을 찾아가서 마스터의 경지를 물어보자, 질문이 예전과 같이 이상하다고 느껴질 것이며 이제 그 선배들이 했던 이해 안가는 말들이 조금씩 이해가 되기 시작할 것이다.

Monday, January 14, 2019

회사에서 하는 일을 잘 하는 게 자신의 개발 실력을 증명해 주지는 않는다. (1)

제목이 좀 자극적이어도 글을 끝까지 읽기를 권한다.

개발 실력이라는 것?


실무 경험이 없는 그리고 개발자가 되려고 하는 사람 중에는 이렇게 생각하는 사람이 많을 것이다.

- 빨리 회사에 입사해 도움이 되는 사람이 되려고 하는 것
- 회사가 내 개발 능력을 잘 써주길 바라는 것

그런데, 사실 일해보면 알겠지만 위 두 생각은 틀린 생각이다.

일단 회사에 도움이 되는지 안되는지는 일을 함께 해 보지 않고 알 방법은 없다. 뭐 같은 기술을 쓰고 같은 개발을 하는 입장에서는 도움이 된다고 생각할 수 있지만, 근본적으로 일을 하는데 도움이 되고 안되고가 판단의 포인트가 아니라는 뜻이다. 회사는 제품 개발이 되고 수익이 나는 상황을 원하게 되어 있고 그러려면 일 하는 사람에게 요구하는건 개발 하면서 배웠던 개념이라던지, 좋은 개발 문화, 성장할 수 있는 환경, 코드의 품질을 높이는 작업 등등을 원하는 게 아니고 어떻게든 동작하는 코드를 작성해서 버그가 없이, 그리고 일정에 맞춰서 문제 없이 일을 끝낼 수 있는지에 대한 여부만 보게 되어 있다는 것이다. 즉, 시키는 일을 별 문제 없이 잘 해서 월급 줘 가며 일 할 수 있는 사람인지가 회사 쪽에서 가지는 시각이라는 것이다. 뭐 이것도 내가 여차저차 잘 해서 스스로 회사에 도움이 됐다고 생각하면 좋은 케이스이지만 그렇게 개발을 하다 보면 내 개발 실력이 느는게 아니라 회사가 원하는 일에 맞게 잘 훈련되서 거기에 맞춰 열심히 노동력을 제공 해 주고 월급을 받아왔다는 게 팩트인데, 그걸 잘 모른다는 게 사회 초년생들의 흔한 착각이다.

또 회사가 나의 능력을 잘 써주길 바라는 마음이 있는건 좋지만, 아마 반대의 상황으로 흘러가는 게 더 많을 것이다. 즉, 나의 능력과 흥미가 어디 있는지 크게 관심이 없고, 회사가 원하는 방향대로 나의 능력을 그쪽에 맞춰 키워나가는 걸 더 원한다는 것이다. 예를 들면 내가 가진 능력은 코드를 계속 리팩토링 해서 간결하고 유지보수 하기 좋게 코드를 짜는 능력이 있고 그걸 회사 업무 하면서 발휘하기를 원한다. 하지만 회사는 그런 거에 관심이 없고, 당장 2주 후에 만들어야 할 관리자 페이지와 프로모션 페이지를 만들어야 하고, 서버 로직과 DB 쿼리를 잘 짜서 어떻게든 기능을 만들어 내는 데 쫓기게 되는 상황이다. 이런 상황이면 잘 설계되고 잘 리팩토링 된 아름다운 코드는 나오기 어려울 수 밖에 없다. 아니면 시간을 더 투자해 내가 원하는 능력을 발휘해서 리팩토링된 코드를 잘 구현했다고 하더라도 쓸데없는데 시간 썼다고 생각할 가능성이 높다. 개발 문화가 나의 관심사를 발휘할 수 있는 문화가 아니라면 내 진짜 실력이 성장할 기회 조차도 없기 때문에, 애초에 아무 회사나 들어가서 내 능력이 잘 쓰이길 기대하는 거 부터가 잘못됐다. 처음부터 내 관심사에 대해 발휘할 수 있는 문화가 있는 회사를 찾아가서 일하는게 맞다.

이런 시간을 1년, 2년, 3년 보내고 나면 얻는 타이틀이 개발 실력일까?


개발 실력이 늘던 아니던, 성장을 했던 못했던 어쨌든 모두들 사회 생활을 하다  스스로 이렇게 부르게 된다.

"안드로이드 개발 2년차"
"자바 개발 3년차"
"서버 개발 5년차"

뭐 5년차 까지는 괜찮다. 회사 이직 시 연봉 상승에 아주 좋은 연차들이니까. 그런데 그런 시간을 보내온게 실력을 증명하는 길인지 아닌지 잘 생각해 봐야 한다. 일단 좋은 개발문화를 가지지 못한 회사에서 시키는 일과 일정에 쫓겨 일을 했던 사람이면 개발 년차가 크게 의미가 없다. 왜냐하면 내가 성장하기 위한 능력을 키운게 아니고 일 하는 방법을 잘 훈련해서 그렇게 시간을 보내온 거니까.

"내가 개발 3년 했으니까, 어느 정도 인정 받을 수 있겠지?"

라는 생각은 매우 위험하다. 개발 문화가 좋지 않은 곳, 즉 여태까지 일정에 쫓겨가며 시키는 일을 마무리 하는 것에 시간을 보내온 개발자는 비슷한 환경에서 일하는 다른 회사에서는 대우 받을 수는 있을 것이다. (왜냐하면 등급이 올라가면 더 단가를 후려치고 월급은 조금만 더 줘도 되니까) 그런데 대부분 이직을 원하는 회사는 개발 문화가 좋은 곳을 원한다. 카카오라던지 네이버, 우아한 형제들 이런 곳일 것이다. 그런 곳에 이력서를 넣고 면접을 한번 보러 가보자, 그러면 자신이 얼마나 형편없는 개발자였는지를 뼈저리게 느끼게 될 것이다. (물론 서류 전형이 통과될 수 있는지 없는지에 대한 여부는 논외이다.)

그 회사들이 원하는 면접의 형태에 코딩 테스트가 있다. 알고리즘 문제 해결이라던지 프레임워크나 특정 기술적 상황에서의 문제 대처 방법과 왜 그렇게 생각하는지에 대해 면접을 진행을 할 것이다. 하지만 회사에서 했던 일은 그런 것과 상관 없는 것들을 해왔기 때문에 면접을 잘 볼수 없게 된다. 혹은 그런 경험을 했고 잘 알고 있다고 하더라도, 그걸 남들한테 보여주거나 설명해 본 적이 없기 때문에 분명히 아는 건데도 어버버 하면서 말이 제대로 안나오게 되는 경우가 허다할 것이다. 그리고 그 경험을 한 후 부터 부랴부랴 알고리즘 공부도 하고 원하는 직군의 기술들에 대해 공부를 한다. 그런데 또 그게 잘 될리가 없다. 왜냐하면 갑자기 안하려던 걸 하니까 힘들고, 실무 하기 전에 공부할 때도 그런 레벨로 공부를 해보지 않았기 때문이다. 그런 레벨로 공부를 해보지 않았다는게 무슨 의미냐 하면 따라하기식 강의나 그저 그런 스터디모임에서 뭐 하나 제대로 끝내보지 못한 채로 수박 겉핥기 식으로 조금 "따라" 해 본게 전부인데, 면접 질문은 그런 수준이 아니라 근본적인 기술적 수준에 대한 것이나 그 해결 방법, 또는 왜 이런 기술과 방법을 썼는지와 같은 걸 물어보기 때문에 그런 걸 공부해 보지 않았으면 대답을 할 수가 없다는 것이다. 또 공부해 봤다고 하더라도 블로그 같은 곳에 잘 정리를 해 놓거나 어느 커뮤니티 사이트에서 발표 혹은 스터디 모임 주도 정도를 해보지 않았다면 어려운 일이 된다.

진짜 문제는 따로 있다.


결정적으로 가장 큰 걸림돌은 현실과의 타협이다. "나 정도면 이 회사에서 더 잘할 수 있어", "여기 말고 다른데 가도 크게 달라질까?", "당장 다음달 까지 마감 프로젝트 있는데, 그거 끝나고 다시 생각해보자" 이런 식의 타협은 현재 다니는 회사에 안주하게 되고, 시간은 계속 흐르고 이직 타이밍은 미뤄진다. 더 웃긴건 회사에서는 어느 정도 연차가 차면 시니어급 레벨로 인정해 주고 manager 노릇도 할 수 있기를 기대하는데, 여태까지 시키는 일만 한 채로 몇 년을 지내왔을 뿐이라 그런 능력이 또 갑자기 생길리가 없다. 아마 처음 드는 생각은 이럴 것이다. "아니 나도 잘 모르는데 누굴 알려줄 수 있을까?" 그리고 이 때 쯤 다들 힘들어한다. 그런다고 해서 회사에서 연봉을 많이 주는 것도 아니다. 그 시점에서 내가 몇 년차 개발자라는 걸 어필해도 먹힐리가 없다. "몇 년 동안 했는데 그거 밖에 안되냐?" 라는 말로 공격 당하면 서러움이 눈 밑과 목구멍까지 울컥하고 올라오게 된다.

그러면 개발 실력이라는 건 회사에서 하는 일 아니면 어디에서 오는 건지 다음 편에서 얘기해 보기로 한다.

Monday, December 3, 2018

프로그래머가 되기 까지의 회고 (4) - 군 시절

프로그래머가 되기 까지의 회고 (1) - 초등학교 시절
프로그래머가 되기 까지의 회고 (2) - 중고등학교 시절
프로그래머가 되기 까지의 회고 (3) - 대학 입학 부터 군 입대 전까지

----
뭐 나도 군대라는 곳을 어차피 가야 했었고, 공부하는 것에도 그렇게 흥미가 있지 않았던 데다 집에서도 군대를 빨리 다녀오는게 좋겠다고 해서 자연스럽게 1학년 까지만 다니고 휴학을 한 후에 군대에 지원했다. 그런데 정말 얼마나 지원자가 많았냐 하면 육군 같은 경우는 거의 1년을 대기해야 한다고 했을 지경이었고 그 외에 지원해서 입대하는 다른 공군, 해군의 경우도 몇 개월씩 기다렸다가 입대를 할 수 있었다. 내가 살았던 시대의 흐름이 그렇다 보니 나도 자연스럽게 그렇게 대기를 하고 군대를 가야 했다.

때마침 국가부도의 날이라는 영화가 개봉했고, 영화 리뷰 겸 그 때 나의 상황에 대해 설명한 내용이 있으니 아래 링크를 참조하면 더 좋을 것이다.
https://feelcommonlife.blogspot.com/2018/12/blog-post_3.html

육군은 안될거 같아서 나머지 지원해서 갈 수 있는 것 중에 해군에 지원해서 입대를 했다.  복무기간이 28개월이어서 복학 기간에 맞추려면 최대한 9월 이전에는 입대를 했어야 했고 안그러면 다른 방법을 찾았어야 했는데 다행히 7월에 입대해서 11월 제대하는 복부기간이어서 복학 준비도 할 수 있는 기간에 입대를 하게 되었다.

진해에서 기초 훈련을 받고 병과를 지원해서 나누게 됐는데 그때는 키 순서대로 헌병 데려가고 컴퓨터 관련과는 전산병으로 데려가고, 전자통신 관련 과는 통신병으로 데려가고 그런 식이었다. 난 컴퓨터공학과 다니다가 군대에 오니 뭐 당연하게 전산병이 되게 되었고 전산병 훈련 받는 기간에 정말 놀라운 경험을 하게 되었다.

<왼쪽 부터 겨울 정복, 근무복, 여름 정복이다. 어린 시절 단순하게 이 옷을 입으면 땅바닥을 구르는 훈련을 안할거라 생각해서 해군을 가게 되었는데... 땅바닥을 구르는 훈련 외에 다른 훈련이 기다리고 있다는 사실은 몰랐다.
출처: 해군 블로그 http://blue-paper.tistory.com/>

대학에서 Unix와 C를 한 것도 조금 신기했는데, 그 때 군대에서 전산병에게 교육한 내용은 무려 COBOL이었다. 실제로 구전과 책에서나 봤던 언어였고 실제로 이 언어로 프로그래밍을 한 사람을 찾는게 가능한 일인지도 힘든 그 COBOL. 그게 전산병 교육장 PC 실에 깔려 있었고 며칠 동안 COBOL 프로그래밍을 배우기도 했다. 그때 프로그래밍 했던 COBOL은 영어 문장으로 프로그래밍을 하는 거였고 BASIC과 아주 흡사했다. 필요에 의해서 실습도 하고 공부도 했지만 정작 군생활 내에 써먹어 보지는 못했다. 왜냐하면 실제 내가 군생활을 했던 곳에서는 COBOL을 쓰지 않았고 Visual basic이나 Power builder를 썼기 때문이다. 이 마저도 잠깐 해봤을 뿐이다.

<군 생활 때 워드병 생활을 하면서 열심히 문서 작성했던 워드 프로그램인 아리랑 3.0
출처: http://blog.daum.net/_blog/BlogTypeView.do?blogid=06Txc&articleno=15813762&totalcnt=129>

군 생활 때 전산실에 근무해서 Visual basic을 잠깐 접할 기회가 있긴 했지만, 곧 어른들의 사정으로 인해 어느 부서의 워드병으로 차출되어 거기서 문서작업 하는 일로 제대할때 까지 군생활을 했다. 상병, 병장의 계급을 달고 짬이 차면서 자연스럽게 공부하는 시간이나 자유 시간이 조금 생기게 됐는데, 그 때까지만 해도 개발 공부를 해야 겠다는 생각을 잘 하지 못했다. 이유는 다양했지만 지금과는 달리 그때는 컴퓨터를 쓸 수 있는 시간은 업무 시간이었고 일부러 거짓 보고를 올리고 사무실에서 야근한다고 하지 않는 이상 컴퓨터를 쓸 시간이 없었다. 두 번째는 공부 보다는 외박 나가서 PC 게임 하는 것과 록 음악 듣는 것에 더 심취해 있던 기간이었던 것 같다. 즉 전공 공부나 프로그래밍 공부를 해야 한다는 생각은 있었어도 실천은 못하고 음악 듣거나 외박 나가면 PC 게임 하는 걸로 시간을 보냈다.

제대 하기 몇 달 전 그 당시 인기 있었던 인터넷 정보 검색사라는 자격증이 있었는데, PC에서 객관식 시험을 치면 바로 합격 여부를 알 수 있는 자격증이어서 특별히 컴퓨터에 관심이 없던 사람들도 따곤 했던 자격증이었다. 그런데 사실 개발하는 능력하고는 전혀 상관도 없고 자격증 자체가 공신력이 있는 것도 아니어서 그냥 있으나 마나한 자격증을 따고 아주 잠깐 뿌듯해 했던 기억도 있다.

어쨌든 군 생활 때도 개발 관련된 활동을 하지 않았던 건 사실이다. 엄청나게 능숙한 워드 프로그램 작성 능력, PPT 작성 능력을 자연스럽게 익힌 것과 한글, 영문 타자 속도가 엄청나게 늘었다는 점 (각각 800, 500 타 정도?), 그리고 2벌식도 빠르게 치는게 지루해서 3벌식 타자 연습도 했던 (200타) 그런 시절을 보냈다. 팩트로 얘기하자면 개발과 개발 외에 컴퓨터로 하는 모든 작업의 물리적인 기본 능력만 키운 셈이다.

제대한 후에는 다행히도 복학할 학비를 부모님이 준비해 주셔서 학교에 복학할 수는 있었는데, 군 생활을 했던 3년 사이 쓰던 컴퓨터의 성능이 썩 좋지 않아서 또 컴퓨터가 좋아야 공부를 할 수 있다는 핑계를 대고 좋은 컴퓨터를 마련하고자 복학하기 전 까지 PC 방 알바를 하며 점심 값 제외하고 월 60만원 정도를 벌어 그 당시 살 수 있던 아주 좋은 성능의 PC를 장만했다.

지금 월 60만원에 알바하라고 그러면 미친놈 취급 받겠지만 그 당시(2000년)만 해도 최저 시급 개념도 희미했고 시간당 알바 시급이 대충 2천원 전후였기에 대략 최저시급 정도 받고 일했던 것 같다. 그래도 점심은 꼬박꼬박 사주고 한달에 한번씩 회식도 시켜줬던 PC방 사장님이 고맙기만 했다.

그리고 이제 다시 학교로 돌아갔다.

Friday, October 26, 2018

Interview me

이건 성공하는 프로그래밍 공부법 책에 챕터가 끝날 때 마다 개발자 들의 인터뷰 내용이 있는데, 거기에 있는 인터뷰 질문에 대해 내가 답변한 걸 적어본 것이다.

Q. 간단한 자기 소개 부탁드려요


저는 버넥트에서 AR/VR 기술을 사용하여 제품 개발을 하는 일을 하고 있는 김종필이라고 합니다. 회사에서의 소개는 이렇고 좀 더 폭넓게 소개해 드리면 소프트웨어를 개발하는 걸 업으로 삼고 배우고 익히는 걸 멈추지 않으려 노력 및 실천을 하고 있는 한 프로그래머라고 보면 좋을 것 같네요. 또 제가 중요하다고 생각하는 소프트웨어의 가치를 전파하기 위해 여러 대학생 및 이제 프로그래밍 일을 한지 얼마 안된 친구들과 소통하고 문제를 같이 고민하고 해결해 나가는 일도 같이 하고 있습니다.

Q. 요즘 리얼리티 프로그램이 대세잖아요. 하루 일과를 그냥 가감없이 보여줌으로써 시청자도 같은 감성을 공유하거나 삶을 간접적으로 체험한다거나. 이런 관점에서 하루 일과를 공유해주신다면?


출근은 유연 근무제를 하고 있어서 08:30 ~ 10:30 사이에 출근한 후에 17:30 ~ 19:30 에 퇴근하면 되는 환경입니다. 저는 일찍 출근하고 일찍 퇴근하는 걸 좋아하기에 08:30에 출근합니다. 사실은 아내가 대학원에서 공부를 하고 있기에 집에 일찍 가서 이제 두살 된 딸도 봐야 하는 이유가 더 큽니다. 출근 하기 전에 항상 오늘은 무슨 일을 하고 일을 언제까지 얼마나 해야 하는지 생각합니다. 회사 출근해서 자리에 앉은 다음에 이것 저것 상황 파악하고 하는 것 보다 미리 생각하고 나서 나만의 페이스 대로 일하는 걸 좋아합니다. 현재는 공기업의 연구과제 및 대기업 PoC 과제, 자체 라이브러리 개발 등 여러 가지 일을 하고 있습니다. 기술 베이스가 AR이다 보니 다양한 플랫폼과 다양한 디바이스를 가지고 개발을 하고 있는데요. 태블릿, 스마트폰, 스마트 글라스 등 디바이스의 특성도 있지만, android, iOS 등 플랫폼의 특성도 있기에 이런 환경에서 개발하는 것에 익숙해 져야 하는 것도 있습니다. 주로 하는 업무는 개발이 많고 연구과제 및 테스트도 많이 합니다. 기획팀과 디자인팀과도 협업해야 하기에 종종 회의도 하고, 디자인 시안, 이미지, 문서 등등 많은 걸 공유하며 같은 목표를 달성하기 위해 각 팀이 각자 맡은 바 일을 열심히 합니다.

Q. 프로그래밍 공부를 시작하게 만든 강력한 동기가 무엇이었나요?


PC 게임이었던 것 같습니다. 초등학교 때 컴퓨터 학원에 다니면서 컴퓨터 쓰는 법과 프로그램 짜는 법, PC 게임 하는 것 등, 컴퓨터를 학원에 다니면서 자연스럽게 컴퓨터라는 걸 접했습니다. 중학교 입학 할 때 부모님이 처음 PC를 사주셨는데 그걸로 열심히 게임을 했고 게임을 하다 보니 어떻게 만들어야 하는지 PC 잡지 등을 통해 알아보다가 프로그램 언어를 배워서 프로그램이라는 걸 짜서 실행 파일을 만들면 게임을 할 수 있다는 걸 알게 됐죠. 신기한건 그 때 부터 지금까지 게임을 만들어 본 적 없이 프로그래머의 인생을 살고 있긴 한데, 프로그래머가 되어야 되겠다는 동기는 확실히 PC 게임을 해보고 만들어 봐야 겠다는 생각을 하면서 부터가 맞는 것 같습니다.

Q. 맨 처음 누구나 프로그래밍 공부는 막막할 것 같습니다. 혼란스러웠던 시기의 에피소드를 얘기해주실 수 있는지요?


사실 컴퓨터 학원에서 프로그래밍을 배우긴 했는데 공부를 했다기 보다는 기계적으로 프로그램 짜는 훈련을 했던 것 같습니다. For문 돌려서 별찍기, 국어, 수학, 영어 점수 입력받아서 총점, 평균 구하기, 간단한 수학 문제 및 함수 만들어서 계산하기, 특정 년도와 월의 달력 출력하기 등 제 생각대로 프로그래밍을 했다기 보다는 컴퓨터 학원에서 정해준 문제를 푸는 방법을 익히고 그걸 그대로 프로그램을 짜는 훈련을 열심히 했던 거죠. 10살 부터 했는데 어린 나이에 뭔가 깊이 있게 공부를 했다기 보다는 자연스럽게 컴퓨터 프로그램이라는 형태가 어떤 것이라는 걸 반복 훈련을 통해 알게 되고 습관이 되다 보니 이후에 프로그래밍 하는 것도 아주 막 어렵거나 하진 않았던 것 같습니다. 그러니까 남들과 달리 어린 나이에 프로그래밍을 접한 거라 막막함을 느끼거나 생각할 시간도 없었다고 보는게 맞겠네요.
그래도 질문이 혼란스러웠던 시기니까 그 시기를 얘기해 보면 대학 다니면서 컴퓨터에 관련된 공부할 때였던 것 같습니다. 프로그래밍의 기본 적인 건 이미 알고 있었지만 뭔가 언어적인 특징을 조금 더 공부한다던가, UI 관련 프로그래밍을 할 때라던가 할 때 계속 공부해 나가면서 알아가야 했죠. 누구나 다 어려워 했던 C언어의 포인터의 개념도 공부해서 알았다고 하더라도 제대로 이해해서 활용하기 까지 저 역시 남들과 같이 오랜 시간이 걸렸던 것 같습니다. 또 컴퓨터를 배운다는게 프로그래밍을 배우는게 다 인줄 알았던 저에게 대학에서 공부했던 과정은 저를 더 컴퓨터에 대해 알게 해줬기 때문에 코딩을 잘 하냐 못하냐의 갈등 속에서도 소프트웨어를 만든다는 것에 대한 체계를 잡아 나갈 수 있었던 것 같네요.

Q. 자신만의 프로그래밍 공부법이 있으셨을 것 같습니다. 초창기, 성장기, 그리고 현재 왕성하게 활동하고 있느니 기간, 이 세 기간으로 나누어서 소개해주실 수 있나요?


초창기

대학 다닐 때는 프로그래밍 공부를 계속 해봐야 실력이 는다고 생각해서 방학때 스터디 모임도 하고, 게임 프로그래밍 학원도 다니고 했던 것 같습니다. 또 전공 관련된 책 역시 용돈으로 사서 원서 번역본 할 것 없이 이것 저것 많이 읽고 친구들한테도 빌려주고 했었습니다. 프로그래밍 관련된 지식이라면 모르는게 없어야 한다고 생각해서 계속해서 공부하고 많은 책을 읽어 봤던 것 같네요.

성장기

제가 성장했던 시기는 현업에서 일하고도 한참 지난 후 였다고 생각합니다. 프로그래머가 성장하기 위해서는 많은 경험이 필수적인데 저는 몇 년 동안 많은 경험을 하고도 크게 성장하지 않았다고 생각했었습니다. 그 중에 큰 걸림돌은 한가지 플랫폼과 한가지 언어에 종속적인 일을 쭉 해오다 보니 그랬던 것 같고, 제가 크게 성장할 수 있었던 계기는 기존에 해 왔던 PC용 프로그램이나 앱 개발이 아닌 웹 프로그래밍을 접하면서 부터였습니다. 그리고 그 웹 프로그래밍 경험도 쌓이다 보니까 어느 한가지 결론에 다다르게 되었는데요. 사실 여러 선배 개발자 분들도 아실거라 생각되는데 어떤 시스템과 서비스를 만드는 일에 특정 프로그래밍 언어와 플랫폼이 종속적이어야 하는 이유를 찾을 수 있는지를 생각해 보면 프로그래밍 외에도 알아야 할게 많다는 걸 느끼면서 성장을 했던 것 같네요.

현재

지금은 현업에서 아직도 프로그래밍이 가능할까 싶을 정도의 경력이 쌓여 있는데, 경력이 쌓이고 경험이 많아질수록 점점 더 기본에 충실해야 하고 원리에 대한 깊은 이해가 필요하다는 걸 많이 느끼고 공부하는 걸 멈추고 있지 않습니다. 알고리즘 문제 풀이를 하면서 논리적인 사고를 해야 한다는 걸 계속 느끼고 있고, 여러 플랫폼이 가지는 장점과 철학을 리뷰하면서 왜 이런 라이브러리와 프레임워크가 생기게 되었을까에 대해 만든 사람의 입장에서 이해해 보려고 많은 문서와 책을 읽고 있습니다. 이제는 저의 이런 경험을 후배 프로그래머에게 나눠주고 싶은 마음에 멘토링 활동도 열심히 하고 있습니다.

Q. 프로그래밍 공부에서 알고리즘이나 수학이 중요하다고 하는데요. 꼭 그런가요?


분야가 워낙 다양하다 보니 "그럴 수도 있고 아닐 수도 있다"로 해석될 수도 있지만, 저는 수학이 중요하다고 생각하는 쪽입니다. 웹 응용쪽 개발을 하는 프로그래머는 수학을 몰라도 아름다운 UI와 비지니스 로직 처리를 구현해 낼 수 있죠. 하지만 영상 인식의 분야와 머신 러닝 기반으로 개발을 하는 프로그래머는 관련된 수학 모델 설계와 지식이 필요할 수 있습니다. 그런데 이것도 수학적 지식에서 보면 그런 것일 수 있지만 프로그래밍을 하는 데는 "수학적 지식" 보다는 "수학적 사고 방식 및 논리 전개"가 중요한 것 같습니다. 수학적 지식은 필요할 때 다시 공부해서 적용하면 되지만 사고 방식 및 논리 전개는 자연의 법칙에 대한 이해와 깊은 사고 능력을 훈련하지 않고서는 배울 수 없는 가치이기 때문이죠. 수학을 배운다는 건 지식을 배우는 것도 있지만 사고 능력을 배운다는 차원에서 중요하다고 봅니다.

Q. 프로그래밍에서 중요한 것 세 가지만 꼽는다면 무엇이 있을까요? 세 가지 넘어도 됩니다.


소프트웨어에 대한 본질적인 이해

컴퓨터라는 물건이 어떻게 동작하고 이걸 통해서 뭘 하고 싶어하는 건지 그 근본적인 이해가 반드시 필요한 것 같습니다. 무슨 일이든 기초가 튼튼해야 응용력도 쉽게 길러지는 법이라고 생각합니다. 여기서 컴퓨터에 대한 이해가 하드웨어 지식도 필요하지만 소프트웨어에 대한 지식이 반드시 필요합니다. 프로그래밍이라는 걸 하기 전에 소프트웨어에 대한 이해를 하고 프로그래밍을 하는걸 강력하게 추천합니다.

코드 리뷰

흔히 컴퓨터는 거짓말을 하지 않고 프로그램이 잘못된 건 전적으로 프로그래머의 잘못이라고 하죠. 그런데도 많은 프로그래머들은 컴퓨터가 잘못된 것, 나는 프로그램을 제대로 짰을 것이라는 착각을 합니다. 프로그램을 잘 짜려면 여러가지 요소가 필요한데, 저는 무엇보다도 자기가 가지고 있는 생각의 흐름대로 프로그램을 짰는지 리뷰를 하는게 중요하다고 생각합니다. 코드를 타이핑 할 때는 몰랐던 많은 논리적 오류는 물론이고, 새로운 자신을 발견하고 반성도 하며 더 나은 내가 되는 좋은 계기가 되거든요. 이 훈련이 잘 되어 있으면 꼭 컴파일이나 빌드 작업을 해봐야 검증이 될 거라는 미신을 떨쳐내고 코드 리뷰만으로도 얼마든지 좋은 프로그램을 짤 수 있는 경험을 할 수 있게 됩니다.

장인 정신

프로그래밍을 공부하는 거의 대부분의 프로그래머는 코드를 짜고 동작하게 만드는 것 만이 프로그래머의 역할이라고 생각할 수도 있지만, 범위를 넓혀서 큰 프로그램을 짜고 여럿이 함께 훌륭한 소프트웨어를 만들어 나가는 과정은 동작하는 코드를 짜는 것 만이 전부가 아닙니다. 이 소프트웨어를 쓰는 사람의 요구, 현실 세계에서 요구되는 것들을 해결해야 하는 문제에 대한 분석, 이걸 이해해서 소프트웨어로 옮겨 나가는 논리적인 과정, 실제 가치가 있는 서비스인지 검증하는 절차, 지속적으로 서비스가 가능하고 필요한 추가 요구를 반영해서 더 좋은 소프트웨어를 만들어가는 방법. 이걸 소프트웨어 공학이라고 합니다. 이 분야는 경험적으로도 증명이 되었고 역사적으로도 많은 프로그래머 선배들이 좋은 책을 써 와서 간접적으로도 알 수 있는 지식입니다. 소프트웨어 요구사항의 정확한 분석, 설계, 개발, 테스팅, 유지보수등 소프트웨어를 만드는 일련의 과정을 거친다면 소프트웨어를 쓰려는 사람들이 품질 좋은 서비스와 생산활동을 할 수 있게 됩니다. 프로그래밍 하는 방법 외에도 소프트웨어 엔지니어링 공부가 꼭 필요하고, 소프트웨어의 품질을 높이는 것에 조금 더 신경을 쓰게 되겠죠.

Q. 닯고 싶은 프로그래머가 있나요? 동료도 좋고 유명한 프로그래머도 좋습니다. 그리고 그 이유는?


Robert C Martin 입니다. 소프트웨어에 대한 중요한 철학이 무엇인지를 잘 알고 그걸 알려주신 분이죠. SOLID 원칙, clean coder, 장인 정신 등 프로그래밍 실력이 뛰어나야 함은 물론 그 단계를 넘어 소프트웨어를 바라보는 시선이 어떠해야 한다는 얘기를 명확하게 해 줘서 좋은 것 같습니다. 어느 정도 프로그래밍 스킬은 익힌 것 같은데 소프트웨어를 뭔가 잘 만들어야 겠다는 욕구가 생기기 시작할 때 쯤에 이분의 명서들을 읽어 보면 많은 도움이 되고 많은 가치를 배울 수 있을 겁니다.


Q. 처음 프로그램다운 프로그램을 만든 경험담이 있으신지요? 어떤 프로그램이었나요? 그리고 지금 생각해보면 그 프로그램은 프로그래머 인생에서 어떤 역할을 했다고 생각하나요?


첫 회사에 입사해서 아직 뭐가 뭔지 모르던 시절에 회사 솔루션의 한 부분의 기능을 맡아서 구현하게 되었습니다. FTP 파일과 로컬 파일의 차이점을 비교하고 파일 동기화 기능 등을 구현하는 UI와 파일 diff, FTP 파일 전송 등등의 기능을 구현했죠. 지금은 뭣 모르던 신입때 처럼 우와좌왕 하면서 프로그래밍을 하진 않겠지만, 그 때는 많은 버그와 새로운 기능을 추가하면서 생기는 문제들을 해결하는데 많은 시간을 쏟을 때였습니다. 그리고 그 기능이 담긴 솔루션을 어느 공공기관에 납품을 하게 되었고, 거기서 실제 사용자들이 사용하면서 추가된 또 수많은 버그들과 요구사항 추가 구현 등을 하면서 정말 많은 경험을 했던 기억이 나네요. 짧은 기간에 프로그래밍을 잘했냐 못했냐 보다는, 사용자가 쓸 수 있는 프로그램을 제대로 만드는 능력은 코딩 실력과는 다른 것이라는 값진 경험과 깨달음을 얻었습니다. 대학에서 공부했던 소프트웨어 공학을 실전에서 신입때 경험해 보고 나니 이후에 만들었던 모든 프로그램들은 그냥 기능만 동작하게 만들었던 것 같지 않았습니다. 주어진 기능 구현만이 프로그래머가 해야 할 일이 다가 아니라는 걸 알았던 때였던 것 같네요.

Q. 프로그래머라서 행복할 때는 그리고 불행하다고 생각할 때는?


행복할 때는 쓸모 있는 소프트웨어를 세상에 내 놓았을 때인것 같습니다. 가장 훌륭한 소프트웨어는 처리 속도가 빠르고 기능이 많은 프로그램이 아니라, 사람들이 계속해서 쓰고 지속적인 업데이트를 통해 완벽에 가까운 프로그램을 만들어 나갈 때인 것 같습니다. 그런 소프트웨어를 계속해서 개발하고 사용하는 사람들의 가치를 소프트웨어를 통해 구현해 나갈때가 누구나 행복해 하는 때가 아닐까요?
불행할 때는 근무 시간의 불확실성인 것 같습니다. 단순히 야근이 많아서 일이 힘들다도 포함될 수 있지만, 일의 특성상 근무 장소나 시간의 제약이 거의 없다 보니 새벽에 작업을 진행해서 업데이트를 해야 할 때도 있고, 프로그램이 죽거나 오류가 나는 상황을 빠른 시간안에 해결해야 하는 상황이 닥쳤을 때 법정 근로 시간이 무기력해 지는 시간이거든요. 업무 시간 외에도 해결을 해야 하거나 할 때 종종 생각이 들긴 합니다.

Q. 지나온 과거를 돌이켜볼 때, "아~ 그때로 돌아가면 이런 공부를 좀 하고 싶다"라는 게 있는지요?


일단 미리 공부해야 한다는 차원에서는 딱히 그런 건 없는 것 같습니다. 다 그 나이에 맞는 수준의 공부를 해야 한다고 생각하기 때문에 더 빨리 공부한다고 해서 더 나아지리라는 보장이 없다는게 제 생각입니다.
하지만 선택의 순간에서 다른 선택을 했을 때 아쉬운 건 있는데 대학원 진학을 못했던 것입니다. 그 당시에 저는 취업 보다는 조금 더 공부해서 소프트웨어 공학쪽이나 그래픽 UI 처리 쪽을 더 공부 하려고 했으나 집안 사정 때문에 취업을 할 수 밖에 없는 상황이었죠. 부모님의 바램대로 졸업 전에 취업을 해서 회사 생활을 쭉 해오긴 했지만 마음속 깊은 곳 한쪽에서는 대학원을 진학해 조금 더 연구과제에 대한 공부를 했으면 어땠을까 하는 아쉬움이 조금은 있긴 합니다.

Monday, October 8, 2018

프로그래밍 언어를 잘 아는게 실력 향상에 도움이 되는가?

여러 커뮤니티 사이트와 네이버 까페 등을 가보면서 junior 레벨의 프로그래머가 항상 궁금해 하는 것들이 여럿 있다.
  • 제가 javascript를 열심히 공부하면 서버 개발하는데 도움이 될까요?
  • 제가 java로 네트워크 소켓 프로그래밍은 해봤는데 c#으로 하려면 어떻게 해야 하는 거죠?
  • java 공부를 열심히 하면 취업 할 때 도움 되나요?
  • angularjs를 이용해서 front-end 개발한지 2년 됐습니다. vue.js가 핫하다는데 배우면 이직할 때 도움 되겠죠?
뭔가 다들 중요한 포인트를 놓친 채 프로그래밍 언어 혹은 프레임워크에 의존적인 얘기들만 하고 있다. 더 이상한건 경력이 조금 되는 친구들도 뭔가 다른 영역에 도전하는 걸 많이 두려워 하고, 새로운 걸 도전해 보고 싶기는 한데 생각만 가득한 채 실천도 못한채로 질문을 하는 경우도 많이 있다.

결론 부터 말하면 어떤 특정 프로그래밍 언어나 특정 프레임워크에 의존적인 개발을 하다 보면, 기본적으로 자기가 개발이라는 걸 잘 못하고 있거나 잘 모르고 있다는 전제가 깔려 있을 떄 그런 생각이 들고 질문을 하게 된다. 그리고 이런 걸 질문할 수준이면 자신이 여태까지 개발을 제대로 하고 있었던 건지 되돌아 볼 필요가 있다고 본다.

질문을 하나하나 짚어보면서 분석해 보면

javascript 를 열심히 공부해서 서버를 개발하고 싶다.


우선 javascript를 먼저 배울게 아니라 서버가 하는 역할이 뭐고, 어떤 프로토콜을 써서, 어떤 데이터를 주고 받고, DB에서 데이터를 빠르고 효율적으로 가져와서, 어떤 유용한 결과를 request한 쪽에 줄 건지를 먼저 고민해야 하는게 서버를 개발하는 거라 얘기해 주고 싶다. 그런데 이게 중요하다고 얘기를 해 줘도 자꾸 javascript를 배워야 한다는 생각 먼저 한다. javascript로 된 서버 코드 예제를 분석하고 돌려보고 하면 자기도 서버를 개발할 수 있게 될거라 생각하는 것 같다. 그런데 그런 식으로 하면 처음엔 쉽고 빠르게 되는 것 같아 보여도 결국 내가 처음에 언급한 내용을 되짚어 보면서 구현을 하게 되어 있다. 프로그래밍 언어를 잘 아는게 개발을 잘 하는거라 착각하고 있는 것이다.

java로 네트워크 소켓 프로그래밍은 해봤는데 C#으로는 어떻게 하는 건지 잘 모르겠다.


이 친구는 첫번째 친구보다 더 심각한 상태이다. 최소한 네트워크 프로그래밍을 해야 하는 이유와 네트워크 프로그래밍을 통해 클라이언트와 서버가 뭘 하고 싶어 하는 건지 알고 있다면 프로그래밍 언어를 잘 알고 모르고가 크게 중요하지 않다. 다른 프로그래밍 언어를 경험 안해봐서 그런 것 뿐이지 사실 java나 c#이나 배워서 익히는 수준은 대동소이 하다. 자기가 여태까지 해 왔던 프로그래밍 언어는 익숙하니까 이게 전부인줄 알고 열심히 한건데, 세상에는 같은 동작을 하지만 다양한 다른 프로그래밍 언어로 네트워크 프로그래밍의 비지니스 로직을 구현할 수 있다는 사실을 알아야 한다. 마치 java+spring 프레임워크를 배우는 것 만이 개발자 최종 테크트리의 끝판왕이라 생각하고 다들 미친듯이 java만 한다면 그렇게 java와 spring 프레임워크에 익숙해 지다가 다른 언어 다른 프레임워크를 만나게 됐을 때 뭔가 해볼 생각을 하지 않는다. 그게 문제인 것이다. 다시 생각해 보라 그게 진짜 프로그래머의 모습인지를.

java 공부를 열심히 하면 취업할 때 도움이 되는지


이미 앞에서 설명해서 더 추가로 설명해 보자면, 특정 프로그래밍 언어가 더 취업이 잘 되고 안되고가 정해져 있다면 다들 그 프로그래밍 언어를 하는게 더 득이 되는지 경제학적으로 생각해 보면 된다. 모두 다 취업에 유리한 java만 배웠다고 하면 상대적으로 java를 할 줄 아는 사람이 많아지게 된다는 거고, 대체할 수 있는 프로그래머의 인력 풀도 시장에 많다는 뜻도 된다. "너 아니어도 할 사람은 많다" 라는 말을 들으면 가슴이 아프겠지만 실제로 수요가 그렇게 만들어져 있다면 거기에 탑승한게 잘한건지 아닌지 본인 스스로 판단 가능하다.
그런 시장의 수요가 극단적으로 일어나는 분야를 얘기해 보면 html, css 할 줄 아는 웹 퍼블리셔 분야다. 이 직군에 채용공고를 올리면 하루에 신입 이력서만 30개나 올라온다. 이틀이 지나면 50개가 찬다. 거짓말 아니고 진짜다. 그 중에 CS 전공자는 한명 있을까 말까다. 반대로 OpenCV, Machine Learning 분야에 Python, C++ 할 줄 아는 사람 채용 공고를 올리면 이것도 거짓말 안하고 2~3일에 이력서 1개 올라온다. 그것도 신입으로 올라오는데 그나마 다행인건 CS 전공자가 생각보다 좀 있다는 거 정도다. 상황이 어렇다 보니 취업성공패키지로 취업시켜 준다고 하고 따라하기식 반응형 웹사이트 만들기 몇 달 한거 가지고 취업하려고 하니 취업이 잘 될리가 없다. 남들이 잘 안하는 걸 해보라. 그러면 실력이 형편 없어도 당신을 모셔갈 회사가 있을 가능성이 높다.
또 어떤 기술을 택해서 뭔가 해 봐야 취업이 되는 건 사실이나, 그 기술이 중요한게 아니라 그 기술로 뭘 해봤냐가 더 중요하다는 사실을 잊지 말아야 할 것이다. 로그인 세션 관리, 결제 페이지 연동, 게시판 관리 등등 실제 비니지스 로직을 구현하고 만들어낸 결과물이 뭔지 그 경험을 통해 내가 성취한 업적이 뭔지를 잘 설명하는게 중요한데도 단순히 java라는 프로그래밍 언어를 잘 하면 취업 잘 되냐는 되도 않는 소리를 하면 맥이 빠지는게 사실이다.
또 취업을 하기 위해 java를 열심히 할게 아니라 취업을 하기 위해 java로 프로그래밍 하는 게 적성에 맞고 즐거운지 한번 되돌아 보자. 취업하고 나서 적응 못하고 적성에 안맞아서 괴로운것 보다 내가 정말 하고 싶은게 취업이었는지 IT 기술을 배우고 그걸 익히는게 즐거웠는지를. 이 생각이 들 때가 되면 내가 java라는 기술을 배우고 익혔던게 크게 의미가 없다. 당장 마음이 불안하여 취업을 하는게 목표인 사람들이 생각 못하는 건, 내가 이 직업을 가지고 일하게 되면 즐거울지 아닌지에 대한 것이다.

angularjs를 이용해서 front-end 개발한지 2년 됐습니다. vue.js가 핫하다는데 배우면 이직할 때 도움 되는지


이 친구도 여태까지 웹이라는 걸 잘 생각해보지 않고 회사에서 시키는 대로 열심히 일하다 보니 2년이라는 시간을 보낸 안타까운 케이스인 거다. 이 친구의 신입 시절은 아마 절대 그렇지 않았을 것이다. 회사에서 주어진 업무를 빨리 배우고 익히면 스스로 잘 하게 될거라는 생각에 그냥 열심히 했을 것이다. 심지어 angularjs를 잘 알고 할 줄 아는게 잘못된 점도 아니라는 것이다. vue.js도 사실 해보고 경험해 보면 다른 경험을 할 수 있으니 이직할 때 조금이라도 도움이 되는 건 사실이다. 그런데 프론트엔드라는 것이 angularjs던 vue.js던 뭘 더 잘해야 하느냐가 중요한게 아니다. 프레임워크를 잘 쓴다는게 쓰고 경험해 보면 아는 것이지만, 조금이라도 직관적으로 그리고 조금 편하게 개발해서 생산성이 얼마나 될 것인지, 나중에 수정 및 유지보수가 쉬운지 등등 프레임워크가 가져야 하는 본연의 기능을 잘 훈련하는 것 즉 방법적인 것에 불과하다는 것이다.
그러니까 웹 프론트엔드 개발을 하는데 중요한게 어떤 프레임워크를 잘 쓸줄 아느냐가 아니라 어떤 목적을 가진 사이트를 개발할 거고 거기에 맞게 뭘 적용해서 해야 하느냐가 더 중요하다는 얘기다. 그런데 이미 angularjs를 통해서 웹에 대한 이해 프론트엔드에 대한 이해가 충분히 잡혀 있다면 다른 유사한 프론트엔드 프레임워크가 추구하는 가치가 뭔지, 특징이 뭔지 정도는 찾아보면 알 수 있는 건데도, 또 배워야 한다는 생각을 한다는게 잘못됐다는 것이다. 심지어 언어도 javascript로 같은데도 말이다.
닭 잡는데 소잡는 칼 쓴다는 논어에 얘기도 있듯이 웹 프론트엔드가 하는게 뭔지 한번이라도 조금 더 생각해 보면 angularjs를 잘 쓰냐 vue.js를 잘 쓰냐가 크게 중요하지 않을 수 있다는 뜻이다. 오히려 이런 프레임워크를 쓰는 방법을 익히는 것 보다 각각의 프레임워크가 어떤 작업을 하는데 효과적이고 효율적인지 알아보고 적용할 수 있는 안목을 키우는게 더 중요하다. 그런 안목을 키우는 차원에서 토이 프로젝트로 이것 저것 실험적인걸 해보는 수준이면 크게 나쁘지 않으며, 거기서 다른 프론트엔드 프레임워크와의 차이점을 발견할 수준이면 더 없이 좋을 것이다.
다시 정리하자면 이직할 때 도움이 되는게 vue.js 쓰는 법을 아는게 중요한 것이 아니라 현재 써 왔던 angularjs와 어떤 차이점이 있고 내가 뭘 만드느냐에 따라 어떤 프레임워크를 선택하느냐의 기준을 얘기할 수 있으면 충분히 도움이 될 것이다.

결론


프로그래밍을 오래 하다 보면 점점 특정 프로그래밍 언어 의존적, 프레임워크 의존적, 더 나아가서는 툴 의존적인 경력이 쌓이게 된다. 그런데 그 기간이 길어지면 프로그래밍 능력, 생각하는 능력, 발전적인 능력이 쌓인다기 보다는 일하는 방법에 대한 훈련과 반복되는 익숙함에 시간을 보내게 되어 있다. 그리고 시간이 가면서 스스로 내가 잘 하는지 못하는지 불안해 지지만 쉽게 자신의 손에 익숙한 언어, 프레임워크, 툴을 버릴 자신이 없어진다. 물론 비지니스 로직 처리 하면서 시켜서 해야 하는 일 외에 더 좋은 방법에 대해 고민하고 구현하고 정리해 봤다면 프로그래밍 능력이 조금 좋아질 가능성이 높긴 한데, 대부분 회사 일 하느라 바쁘다 보니 생각은 있어도 실천하기가 쉽지가 않다. 이 상태에서 또 다른 프로그래밍 언어를 배우는게 프로그래밍 능력을 향상시키는 방법이 아님에도 불구하고 다른 프로그래밍 언어를 배우는 것이 나의 개발 커리어도 쌓고 실력이 향상될 것이라고 굳게 믿고 있다. 물론 방법을 어떻게 하느냐에 따라 실력을 쌓을 수 있냐 아니냐가 다를 수 있지만, 그냥 튜토리얼 실행해 보기 책 따라해보기 정도로 깔짝대는 수준으로는 어림없다는 것도 알아야 한다.

기술적으로 프로그래밍의 실체를 접한 친구들은 "실무 일을 열심히 하는 것" = "프로그래밍 실력 향상" 이라는 착각을 하는데, 왜 이런 문제가 발생하는지 진지하게 고민해 보도록 하자. 그리고 이 때가 되면 기술 적인 배움 보다는 조금 더 학문적인 수준에서 접근을 해야 할 필요가 있다. 학문적인 것이라 해서 논문을 쓸 수준의 연구를 하라는 뜻이 아니라 프로그래밍 이외의 것들에 대해 접해보고 생각할 시간을 가져야 한다는 뜻이다. 그렇게 해서 프로그래밍이라는게 어떤 것이고 그것을 통해 어떤 결과를 얻고 싶은 것이며 그 과정 중에 왜 이렇게 코드를 짜야 하는지에 대한 이해를 해야 할 때가 실력이 높아질 수 있는 때이다. 이제 프로그래밍이라는 행위를 왜 하는지, 소프트웨어가 추구하고자 하는 본질이 무엇인지를 조금 더 생각해보자. 여태까지 해 왔던 프로그래밍 언어 의존적, 프레임워크 의존적인 개발을 해 왔던 생각이 많이 달라질 것이다.

Tuesday, September 11, 2018

프로그래머가 되기 까지의 회고 (3) - 대학 입학 부터 군 입대 전까지

프로그래머가 되기 까지의 회고 (1) - 초등학교 시절
프로그래머가 되기 까지의 회고 (2) - 중고등학교 시절

----

그렇게 프로그래밍 하는 법을 기억은 하고 있지만 실제로 뭔가 해본 게 없는 체 대학에 입학하게 됐다.
진로 탐색을 하다 보니 컴퓨터공학과가 있다는 사실을 알았고, 게임 잡지나 컴퓨터 잡지를 둘러 봐도 프로그래밍을 하려면 컴퓨터공학과를 나와야 한다는 얘기를 접하다 보니 수능 점수에 맞춰서 컴퓨터공학과가 있는 대학으로 알아보고 진학하게 됐다.

사실은 프로그래밍 하는 거에는 크게 흥미가 있진 않았다. 초등학교때 학원 다니면서 배웠던 걸로 화면에 그림 그리고 적절한 로직을 짜면 되는 거 정도는 해봤기에 그런 것도 있었다. 사실 BASIC에서 짰던 허접한 게임 보다는 중고등학교 시절 열심히 그리고 재밌게 했던 화려한 그래픽의 컴퓨터 게임들을 실제로 만들 줄 아는 게임 프로그래머가 되어야 겠다는 생각을 해서 대학 진학을 한게 가장 큰 이유였다.

여러 학교에 지원했는데 최종적으로 한성대학교에 합격하게 됐고, 아빠 엄마도 나한테 과외 시켜준 적 한번 없고 학원도 제대로 보내주지도 못했는데 서울에 있는 4년제 대학교에 합격했다고 하니 좋아하셨던 것 같다. 난 이때 한성대학교가 서울에 있다는 사실을 처음 알았지만 학교 보다는 뭘 배우러 가냐를 더 비중을 뒀기에 학교 간판에 대해서는 신경쓰지는 않았다. 그러니까 좋은 학교를 먼저 선택한 후에 아무 과나 들어가는 친구들과 나는 목적의식이 다르고 내가 선택한 길이 옳다고 생각을 했다. 그리고 사실 수능 점수로만 따져서 갔다고 했을 때는 조금 더 좋은 학교에 갈 수도 있었다. 입학 후에도 동기들끼리 수능 점수 얘기할 때도 내가 과에서 수능 점수로만 Top5 안에 들었을 정도였으니까. 그때는 대학부심, 과부심 이런게 중요하다고 생각했고 조금 더 좋은 대학에 진학 못한게 아쉽다고 생각할 때도 있었는데, 지금 생각해 보면 조금 더 좋은 대학을 가는게 무슨 의미가 있고, 내가 남들보다 조금 더 잘나고 우위에 있다는 생각이 지금 다시 회고해 봐도 쓸데없는 생각이었다고 본다.

컴퓨터 공학과 라는 곳에 입학을 하다 보니 입학 전에 새 컴퓨터를 장만해야 공부할 수 있다고 엄마한테 얘기했다. 사실 중학교때 쓰던 286 PC는 초등학교 때 컴퓨터학원 다녔을 때 배운거 써먹고 공부하라고 사준 거였다면, 이번에 사준 컴퓨터는 정말로 대학에서 공부하는데 필요한 거라 목적성이 있어 얻게 된 컴퓨터였다. 6년간 잘 써왔던 286 PC에서 그 당시 인기 있던 586 PC로 업그레이드를 했고, 바로 그 PC에서 돌렸던 게임이 286 PC에서 돌렸던 것 보다 너무 잘 돌아서 좋았던 기억도 있다.

그렇게 대학에 가서 컴퓨터 공학과에서 배우는 과목들을 보니, 프로그래밍 수업은 C언어 배우는거 하나 정도였고 나머지는 다 이론적인 거나 수학 관련된 과목들이었다. 논리 회로, 공업 수학, Unix 시스템 이해, 선형 대수 등등의 과목이 있었는데, 수학은 고등학교때 잘 배웠던거 복습 반, 새롭게 배우는거 반 이정도였고 Unix라는 것도 처음 봐서 그때 까지 쓰던 DOS의 명령어들과 다른 것에 흥미가 있기도 했다.

<Unix console window 화면, 지금은 이런 화면으로 컴퓨터를 쓸 일이 거의 없지만 내가 처음에 BASIC으로 프로그래밍 했을 때만 하더라도 이런 화면으로만 썼었다. 지금도 Windows power shell로 unix나 linux system에 ssh로 접속하면 콘솔 화면으로 신나게(?) 컴퓨터를 사용할 수 있다. 문서 편집, 프로그래밍, 심지어 웹 브라우징 까지 모두 cmd로 가능하다!
출처: Unix wikipedia>

난 솔직히 같이 입학한 친구들 중에 프로그래밍에 대해 전혀 모르고 온 친구가 있다는 사실에 많이 놀랐다. 그러니까 나는 컴퓨터공학과에서 프로그래밍을 한다는 거 쯤은 알고 들어왔는데 동기들 중에는 컴퓨터 활용하는 법을 배우러 오는 곳이라고 잘못 이해한 친구도 있었고, 컴퓨터 타자 연습하는거 좋아해서 온 친구, 컴퓨터 조립하는 걸 좋아해서 들어온 친구, 컴퓨터라는 물건을 알고 있긴 했지만 한번도 써본 적도 없는 친구 등등 다양했다. 내가 그나마 조금 나은 케이스였던 것 같다고 그 당시 생각했지만 지금 생각해 보면 역시 부질없는 생각이었다.

가장 중요한 C언어 얘기를 해보면, 수업 시간에 코딩하고 실행하고 결과를 보는 실습을 하는데 그걸 따라가는 친구들이 몇 안됐었다. BASIC 아는 친구는 좀 있었는데, C는 나도 처음이었고 거의 대부분 C는 모른체 그렇게 수업을 들었다. 나도 변수, 반복문, 배열 까지는 BASIC과 큰 차이는 없어 보여 곧잘 따라하고 옆 자리 친구들에게 자랑도 했는데 지금 생각해 보니 그게 뭐 대단한거 했다고 자랑까지 했는지 조금은 부끄럽다.

게다가 C언어 말고 컴퓨터 쓰는 법 자체를 모르는 친구들이 꽤 되다 보니 그런 것도 옆에서 알려주면서 했던 기억이 난다. DOS와 Unix나 명령어는 다르지만 하려고 하는 목적은 같기에 교수님이 알려준 명령어를 잊지 않고 잘 기억했다가 실습시간만 되면 이것 저것 해보는게 재밌었고, 교수님이 뒤에서 지켜보다가 Unix 명령어를 막 쳐가면서 코딩도 하고 이것 저것 하는 모습을 보더니 눈썰미가 있는 학생이라면서 칭찬을 들었던 기억도 있다.

<Unix 실습 시간 외에는 Dos 환경에서 했기 때문에 프로그래밍은 Turbo C를 띄워서 했었다. 지금이야 워낙 IDE가 잘 되어 있어서 마음만 먹으면 얼마든지 쉽게 프로그래밍을 하고 배울 수 있다.
출처: turbo-c.soft32.com>

하지만 자랑질은 거기까지였고 역시나 포인터라는 이해하기 어려운 부분에 들어가면서 부터 그 후에 어떻게 코딩했는지 잘 모를 정도로 공부 안하고 포기했던 것 같다.

지금 대학생들은 안그러겠지만 나 때만 해도 공부하는데 집중한 친구들 보다는 놀고, 술마시고, 연애하는 걸로 입시 스트레스를 푸는 친구들이 많던 때였다. 나도 동아리 활동도 하고 과 친구들과 어울리고 하면서 술도 많이 마시고 많이 놀았었다. 얼마나 놀고 공부를 안했는지 학점 관리가 제대로 안될 지경이었고 F 학점도 있었다.

다시 기억해 봐도 대학 입학하고 첫 해에는 공부를 제대로 한 기억이 거의 없다. 그나마 있는 기억은 내가 남들보다 조금 더 많이 안다고 잘난척 한거 정도다. 결정적으로 그해 말 IMF 사태가 일어나면서 회사들이 줄줄이 부도 파산이 나고, 이제 회사 입사하려는 대학 졸업생 부터 20대 모든 남자들이 IMF 외환위기를 피해 모두 군대에 몰려 있다는 소식이 계속 들려왔다.

Thursday, August 30, 2018

성적 없는 성적표, 그리고 멘토링의 가치

지난 주 성적 없는 성적표라는 책을 읽었다.

성적 없는 성적표
성적 없는 성적표
『성적 없는 성적표』

『4차 산업혁명, 교육이 희망이다』를 펴낸 류태호 교수의 두 번째 저서다. 이전 저서가 4차 산업혁명 시대의 교육을 개괄한 개론이었다면, 『성적 없는 성적표』는 그 연장선에서 역량 중심 교육을 깊이 파고드는 일종의 각론이다. 저자는 먼저 역량 중심 성적표 도입을 준비하는 미국 교육계의 최근 동향을 자세히 설명한다. 그러고는 공교육 시스템의 기원과 미래 교육의 방향을 소개하면서 역량 중심 교육이 전개될 수밖에 없는 이유를 제시한다. 마지막으로 최신 기술을 활용한 교육 플랫폼, 빅데이터에 기반한...
Yes24 출처의 책 이미지와 내용은 위 부분을 참고하면 된다.

내가 지금부터 얘기 하려는 건 이 책에서 언급한 중요 내용이 내가 멘토링 활동을 하고 있는 가치와 일치한다는 점이다.

이 책의 내용은 4차 산업혁명에 대한 얘기와 그에 맞게 교육이 이루어 지려면 역량 중심의 교육이 이루어져야 한다는 주장이 주를 이룬다. 사실 이 책을 읽기 전에 같은 저자의 책 <4차 산업혁명, 교육이 희망이다>를 보고 개요를 파악해야 한다. 물론 나도 이 책을 먼저 읽은 후에 성적 없는 성적표를 읽었다.

여기서 언급하는 역량 중심 교육이 이루어 지려면 여섯 가지의 핵심 내용이 이루어져야 한다는 얘기를 하는데, 사실 책 읽다가 내가 하고 있는 활동의 가치와 너무 부합해서 놀라웠다.

게다가 나도 기존의 교육 방식 말고 프로그래머가 되려는 후배들에게 어떻게 하면 도움이 될 수 있을까를 몇 년 간 시행착오를 겪으며 활동을 해 왔다. 그리고 지금 하는 멘토링 과정에 이르러서야 뭔가 제대로 된 걸 하고 있다는 생각이 들었는데, 그 내용이 류태호 교수의 책에 고스란히 담겨져 있어서 사실 내가 제대로 하고 있구나 하는 느낌이 많이 든 건 사실이다.

역량 중심 교육 여섯 가지 핵심 내용

  • 학습자 중심
  • 과정 위주 평가
  • 수업의 개인화
  • 학습 시간의 자율화
  • 역량 평가의 공정성
  • 연속적인 역량 관리
여기서 역량 평가의 공정성을 제외한 다섯 가지 항목이 내가 하고 있는 멘토링 과정과 맞기에 그 내용을 내 멘토링 소개 페이지에도 업데이트를 했다.


자세한 내용은 위 링크 페이지에 적었기 때문에 한번 보면 좋을 것이다.

어쨌든 이 책을 읽고 느낀 바가 있어, 지금 하고 있는 활동을 꾸준히 그리고 부지런히 할 계획이다.