입력과 출력
byHAJUNHOMay 04. 2020
Driving, AI 이미지 학습
프로그래밍은 참 쉽다. 물론, 내부는 어렵다. 마치 드라이빙과 같다. 차의 구동 원리를 몰라도 운전을 할 수 있다. 초급 편에서 말했던 "추상화"가 잘 되어 있다. 이와 마찬가지로 수학과 프로그래밍을 잘하는 사람들이 컴퓨터를 잘 몰라도 프로그래밍할 수 있도록 해 두었다. 수학과 컴퓨터를 잘하는 사람이 구글에 모여, AI를 활용한 이미지 학습에 대해 잘 몰라도 쉽게 활용할 수 있도록 만들어 주었다.
https://teachablemachine.withgoogle.com/train/image
Teachable Machine
Train a computer to recognize your own images, sounds, & poses. A fast, easy way to create machine learning models for your sites, apps, and more – no expertise or coding required.
teachablemachine.withgoogle.com
.
.
.
Behavior Modeling
입력과 출력의 관계를 기술하는 것을 말한다. 알고리즘을 사람이 짤 때에는 random related 함수를 이용하는 경우를 제외하고 특정 입력에 대한 결과가 매번 같았다. 그러나 컴퓨터가 짜는 "모델"의 경우 같은 데이터를 가지고도 다른 "모델"이 나오기 때문에 입력과 출력의 관계를 표현하기 힘들다. 즉, 환원주의가 정해진 시간 내 사람이 이해하기 편한 정도로 설명되기 힘들 경우에는 Behavior Modeling이 힘들다고 보면 된다. 이에, 평가도 쉽지 않다.
.
.
.
우리가 일반적으로 하는 실무 프로그래밍 코드 평가는
- 동시성(Concurrent)
프로그램에서는 보통 Multi-Thread를 말하나 스레드도 OS context switching 타임 슬라이스에 갇힌 순차적 명령 묶음(프로시저) 일뿐입니다. 동시성 충족을 위해 메시지 큐, 브로드 캐스팅, 푸시, 네트워크 연결 등이 마치 동시에 여러 작업을 하는 것처럼 만드는 기법이 필요합니다. 이런 기법의 목적은 사용자의 요청을 특정 시간 범위 내 처리할 수 있도록 구성하기 위함입니다. 은행 업무를 하는 직원들의 출/퇴근 시간으로 보면 됩니다. 정해진 시간 동안 동시 출근하여 일한 후 동시 퇴근하는 것과 같습니다.
- 병렬화(Parallel)
프로그램에서는 보통 Multi-Processing을 말하나 일을 나누어한다는 개념으로 Thread, Background Service, 샤딩, L4 스위치, DNS 로드밸런싱, Auto scale 등 사용자의 요청에 대해 Availability(가용성)를 보장하기 위한 다양한 논리적/물리적 기법들을 통칭할 수 있습니다. 논리적 기법을 이용해 여러 물리 서버를 통합하여 하나의 인스턴스로 제공되면 그 안에서의 병렬화는 동시성과 구분하기 힘들어집니다. 이에, 실무적으로 생각해 보면 단순히 은행 업무를 하는 직원들의 수로 보면 됩니다.
- 추상화(Abstraction)
초급 편에서 이미 말한 내용이지만 같은 맥락에서 예를 든다면, 고객이 원하는 부분을 제외한 은행이 어떻게 돌아가는지에 대해서는 최대한 모르게 하는 것을 말합니다. 고객이 원하는 것이 단순히 돈을 넣고 빼는 것이라면 은행 직원의 수, 선발 기준, 내부 시스템, 보안 설계 등은 전혀 몰라도 된다는 뜻입니다. 운전을 할 때에 자동차 회사들이 내부 엔진 구조를 설명서에 싣지 않는 것도 추상화가 잘 되었다고 할 수 있습니다.
.
.
.
이상한 프로그래머
세상에는 이상한 프로그래머들이 많다. 물론, 이상한 프로그램 마이크를 잡지 않고 고객이 원하는 것을 만들어 주는 프로그래머는 완전히 제외이다. 알고리즘을 잘 알면 STL(Standard Template Library)에 기여하면 될 것이고, AI에 대해서 놀랄만한 수학적 진보가 있다면, tensor flow에 녹여내면 그만이다. 추상화를 전혀 이해하지 못하고 중간에 공부하는 것을 왜 말하는지 모르겠다. 적어도 프로그래머로서 뭔가를 말하려고 한다면, 만들고 싶은 것을 말하는 것이 아니라 이미 만들어 본 것을 말해야 하지 않을까? 10년 이상 실무와 함께 강의를 같이 한 이유는 IT 분야 변화 속도가 워낙 빠른 이유도 있지만, 늘 가슴에 멘토님 말씀을 담아 두었기 때문이다. "실무 경험 없이 이론만 강의하면 안 되기 때문에 안식년에 여러 경험을 하러 돌아다닌다"였다. 나의 경우 10년 간 "여러분들에게 가르쳐 주고, 혹 내일 내가 까먹으면 다시 나에게 가르쳐 주세요"였다. 커뮤니케이션이 잘 된다는 의미는 본인의 몸에 잘 익지도 않은 것을 곁눈질로 보며 어렵게 강의하는 게 아니라 잘 몰라도 정말 본인이 만들었던 것을 가르쳐 주는 것이다. 사실, 온라인 강의가 워낙 잘 되어 있기에 반복법으로 기초 공부는 해도 되지만 실무에서만 알 수 있는 정말 작은 노하우는 모르면 프로젝트를 몇 달간 지연시키거나 프로젝트의 성패를 좌우하는 경우도 있다. 실리콘벨리, 페이스북 믿고 IoT 과제에 리액트를 선정해서 수십억을 날린 많은 기업들이 그 일례다. 이상한 프로그래머가 있는 경우 이런 경험도 폐쇄적으로 되어 버리고 만다.
- 사족 -
보고서에 구라를 친다던지 잘못한 것을 말 못 하는 엔지니어를 많이 만나는데 정말 안타까운 것이 뭔가 내세울게 하나도 없기 때문이다. 기업을 단 한 번이라도 만들어 본다면 매트릭스에서 빨간약을 먹은 것과 같다. 삼성전자에서 석사가 일을 잘 못하거나 서울대 출신이 몇 년 동안 별 성과가 없어도 윗사람들은 꾸준히 지켜본다(물론 학연 때문이 아니다) 그 사람이 충분히 능력을 발휘할 시간을 준다는 것이다. 그리고 한 방에 엄청난 히트 모델을 성공시키거나(삼성전자의 경우 이원화가 잘 되어 있어서 똑같은 프로젝트나 하드웨어가 조금만 다른 프로젝트도 여러 팀에 나누어서 시킨다 -LG 친구는 돈 ㅈㄹ이라 말하며 잘 될 수밖에 없겠네 라고 말했었다) 사람 평가 보는 눈이 이미 다른데, 정말 작은 것을 감추려고 한다. 자존감이 낮은 것이라 사실 같이 일하면서 변화시키는 것은 거의 불가능에 가깝다. 어느 정도는 높여줄 수 있으나 이미 과거에 잘못된 선택들을 하고 걸어온 인생이라 생각은 바뀌어도 삶의 태도가 바뀌진 않더라.
지난 초고를 읽다가 브런치에 옮기면서 사족을 더 달아본다. 최근 남산의 부장들이라는 영화를 보았다. 작은 것을 감추는 생각도 점점 크게 확대시키다 보면, 100만 200만 탱크로 밀어 버리면 그만인 생각과 같다. 자리를 지키고 현실을 지배하는 자가 과거도 지배하니까. 역사서도 다시 쓰면 그만. 크고 작업 기업의 총수들이 자신만을 위한 자서전을 써서 전체 출판은 못하고 직원들에게 나눠주는 것을 3번이나 보고 나니 드는 생각이다. 도전이 잘못된 것은 아니지만 워낙에 그 도전들이 모두 표절 의혹이 있으니 말이다. 학생들에게 만화를 많이 보라고 한다. 접근도 쉽지만 상상력 기르는 데는 그만이다. AI 잘하고 여유가 있는 사람들이 제프리 힌튼 교수 근처라도 가서 더 공부를 했으면 하는 바램이다. 돈자랑도 그만하고, 만들어진 피자 배껴서 만들지도 못하는 피자 만들려고 하지 말고. 한 때 기업 평가해서 기업당 80억씩 대출 승인해주고 하루에도 250억 이상 내보내도 정작 삶은 중산층인 엔지니어가...