mjipeo.net

그는 설곽킬러.

(전략)

‘경영의 중심에는 인간이 있다.’ 안 학장(안태식 서울대 경영대학장)은 경영학 수업에서는 좀체 듣기 힘든 ‘인간’이라는 단어를 강조했다. 경영학이라기보다는 철학과 사회학 강의를 듣는 기분이 들 정도였다.

“모든 학문과 의사결정의 주체는 인간이다. 인간이란 무엇인가, 삶이란 무엇인가를 생각하도록 유도해야 한다. 경영학이 모든 것을 할 수는 없겠지만 가능한 한 녹여내야 한다. 이런 것 없이 경영 기술자만 키울 경우 굉장한 위기로 갈 수 있다. 나는 무엇이고, 인생은 무엇이고, 사회는 무엇인가. 진실에 가까워지면 학생의 사고가 더 자유로워 질 수 있다. 성경 구절에도 ‘진리가 너희를 자유롭게 하리라’는 말이 있지 않은가. 사회적 성공에 구애되지 않고, 이기심을 극복하면 ‘사회적으로 의미 있는 삶(Social Significance)’에 가까워 질 수 있다. 창의성은 그곳에 있다. 자유란 인생의 본질을 깨닫기 때문에 얻어지는 것이다. 도전 의식도 여기에서 나온다. 요즘 기업가 정신이 부족하다는 얘기를 하는데, 이조차도 사회적으로 의미 있는 결정이 가능할 때 나오는 것이다. 맹자의 ‘호연지기’가 왜 생겼나. 담당함이란 조그만 것에 구애받지 않는 것, 소탐대실하지 않는 것이다.”

안 학장은 인간에 대한 탐구를 바탕으로 경영학에서 가르치는 자질을 키우기 위한 다른 방법론을 제시했다.

“글로벌라이제이션(Globalization)에서는 언어는 수단에 지나지 않는다. 다양한 문화의 이해와 수용이 중요하다. 리더십은 학문으로 가르쳐서 될 것이 아니다. 타인에 대한 배려와 사회적 의미에 대한 고민에서 나오는 것이다. 창의성은 기능적이고 전문성 위주의 경영학 교육이 유지되는 한 키우기 어렵다. 또 다른 차원에서 재(才)와 덕(德)을 보자. 나는 학생들에게 ‘너희는 최고의 인재니까 재능은 자랑할 거리가 아니다. 재능을 넘어서는 덕성을 키워라’고 얘기한다. 경양학 교육이 재능에만 치우쳐서는 안 된다. ‘기능쟁이’ 밖에 만들 수 없다.교과과정에서도 경영학만 중시해서는 안 된다. 교양과목(논리 철학 문학 역사 등)이 경영학과 접목돼야 한다. 학부는 각 영역이 요구하는 스페셜티(Specialty)를 키우는 곳이 아니다. 경영학은 삶의 기반 위에 세워야 한다. 사회 속에서, 인간 속에서 자리 잡아야 한다. 교과 외 과정에서 오히려 많은 것을 배울 수 있다. 학부생들에게도 이런 것들을 줄곧 강조해 왔다.”

(후략)

한경비즈니스 2009.07.06 커버스토리 ‘경영대 업그레이드 길을 찾다’ 中

FF3.5 정식 버전이 나와서 어제 깔았다.

근데 가장 자주 쓰는 Add-on인 All-In-On-Gesture이 호환되지 않아 어쩔 수 없이 그냥 쓰고 있는데, 엄청나게 불편하다.

마우스 우클릭 드래그로 뒤로, 앞으로 가기, 창 닫기 등만 쓰는데도, 진짜 엄청나게 불편하다.

사실 이런건 브라우저 기본 기능해 포함시켜도 될꺼 같다 -_- 옵션으로다가

http://naver.jp

깔끔하니 좋구만 ㅋ 일본일 취향에 맞을지.

구글이 혁신을 잃어간다

MS로 되돌아온 Google 개발자 이야기

역시 쉽지 많은 않구나. 규모가 커지면 어쩔 수 없는 건가.

모두에게 최상이기만 한 기업은 없다는 걸 다시 한번 확인시켜준다.

facebook은 median age가 27살이구나 ㅋ twitter는 더 젊을 듯. 확실히 군대 문제가 없으니까 우리나라보다 대충 2년 정도 빠르다 -_-

영화 아마겟돈 마지막에 이런 장면이 나온다.

해리(브루스 윌리스) : 안돼 당장 나와! 지금 상태에서는 도저히 안돼!
AJ(벤 애플랙) : 된다니까요! 할 수 있어요!

해리 : 장난해 지금!? 휴고도 그러다가 아까 가스층을 건드려서 우주공간으로 날아가버렸어! 얼릉 나오라고!
AJ : 지금 멈추면 방법이 없어요! 정말 할 수 있다고요!

해리 : 안돼 그렇게 하게 둘 순 없어!

AJ : 아 젠장, 제발 나를 좀 믿어줘요! 내가 반드시 해내고 말테니까, 그냥 날 하게 냅두라고요! 진짜 한번만이라도 나를 진심으로 믿고 일을 맡겨달란 말이에요!

마지막 몇십피트를 뚫는 중요한 작업이었고 시간에 쫓기고 있었다. 결국 해리는 AJ를 믿어주었고, AJ는 구멍 잘 뚫었고, 지구는 대충돌을 면했다.

누군가를 진심으로 믿는다 함은, 문자 그대로 아무것도 따지지 않고 믿는다는 것을 말할 것이다. 믿는다고 말하지만, 자신이 생각하기에 합리적이지, 논리적이지, 효율적이지 못하다는 이유로 이런저런 태클을 건다면, 그건 믿는게 아니고 그냥 자기 일을 대신 시키는 것일 뿐이다.

사랑이든, 사업이든, 종교든간에 누군가를 진정으로 믿고 무언가를 맡긴다는 건 그만큼 쉬운 일이 아니다.

종익이형은 평일 점심, 저녁 10번 중 평균 9번 정도 운동한다고 한다. 웨이트 + 스피닝(?)

거의 세미 프로급 운동량 -_-

운동 열심히 합시다.

이것 참, 씁쓸~ 하구만.

트랜스포머2 재밌다.

추측할 것도 생각할 것도 거의 없었고, 보는 내내 눈과 귀가 즐거웠다. 그것만으로도 지불한 돈의 가치가 있었던 것 같고.

변신로봇이 변신하는 거 보면서 ‘히야~~’ 이런 표정 짓는 건 애들만이 아니다. 루이비통 신상 가방을 바라보는 여자들의 표정이나, Google App Engine에서 URL-based로 Crontab 비슷한 기능을 지원한다는 것을 깨달은 JP의 표정이나.

그렇게 아무 동기 없는 순수하고 원초적인 동심을 존중해주어야 한다. 활용할 수 있으면 더 좋고.

“관리의 삼성, 지금까지는 성공했지만…”

“삼성전자 공장 한 곳을 방문했을 때였다. 담당 임원이 최근 공정 한 부분의 처리 시간을 70% 개선했다고 자랑스럽게 보고했다. 그런데 부연설명을 들어보니, 얼마 전 윤종용 부회장이 방문했을 때 지적받아서 개선 방식을 찾은 결과라고 했다. 70%씩이나 개선할 정도라면 윤 부회장이 지적하기 훨씬 전에 현장 임원들이 알아서 개선했어야 할 터이다. 지시를 받기 전에는 알아서 할 생각을 하지 못하는 사례다.”

“… 하지만, 내가 경험한 삼성전자 문화는 임직원의 창의성을 고양하기에 부족한 점이 많았다. 가만히 살펴보니 구조적인 이유가 있었다. 삼성전자에서는 기술자나 과학자로 성공하기보다 부하 직원이 많은 조직의 부서장이 되는 것을 선호하는 문화가 역력했다. 그래서인지, 고작 몇 명밖에 안 되는 부하 직원을 데리고 일하는 과장급들도 관리인으로 행동하는 경우가 많았다. 또, 승진에 필요한 고과를 상사가 주관적으로 정하도록 돼 있는 점도 문제다. 직원들이 자신의 창조력을 발휘하기보다는 직속 상사에게 충성하도록 유도하는 구조라는 뜻이다.”

침묵의 대가 - 김국현

“우리는 인생의 수많은 선택 속에서 세이프를 만끽하고 그리고 침묵해 왔다. 내일을 생각하지 않는 스스로의 침묵의 말로를 우리는 살고 있는 것 뿐이다.”

평범해 보이는 사람이 성공했다 - 조선일보

“삶에서 가장 중요한 것은 인간관계이며, 행복은 결국 사랑”

“하버드 엘리트라는 껍데기 아래엔 고통받는 심장이 있었다”

행복하게 늙어가는 데 필요한 요소는 7가지로 추려졌다. 고통에 적응하는 ‘성숙한 자세’가 첫째였고, 교육·안정적 결혼·금연·금주·운동·적당한 체중이 필요했다.

1937년부터 시작되어 당시 하버드대생들의 인생을 추적한 연구라고 하는데, 결과가 이래저래 흥미로워 보인다. 시사하는 바가 크다.

지난 달 초에 본 시험 결과가 오늘 도착했다. 880점에 99%. 90%만 넘으려고 했었는데 뽀록이 정말 제대로 터져주었다 -_- 작년 8월 GRE General 시험에서 후기 못 타고 리딩 롱이 5번에 나올 때 비축되었던 운을 다 써버린 듯하다. 70문제 중에 3문제는 몰라서 답을 안 썼고 (틀리면 0.25점씩 감점이 있다) 답을 기입한 것 중에 4개 틀렸다. 지금 생각해도 아리까리해서 찍었던 게 4문제는 넘었던거 같은데 흠.

늦게 전산과로 전과를 했고, 아직 수강하지 못한 필수 전공 과목(OS, Network 등)이 몇 개 있어, 혹시 그것 때문에 불이익이 있지 않을까 하는 노파심에서 보게 된건데, 그 정도 목적은 달성한 거 같다. 지금 생각해보니 정말 부질없는 생각이다 -_- 뭐 한줄이라도 더 쓸게 생겼다는 데 의의를 둔다.

공부하려고 하는 분야인 AI 관련 강의노트나 논문 같은거 찔끔찔끔 보면서, 3년 동안 내 머리 속에서 사라져버린 수학 개념을 비롯하여, 그 ‘익숙하지 못함’에 상당히 좌절하고 있는 상황에서, 그나마 힘을 주는 결과가 날아와 줘서 다행이다. 조지아텍에서 박사과정 중이신 김민장 씨가 관련 글에서 언급했듯이, 이 점수가 어드미션에 미치는 영향은 정말 미미할 것임을 알지만, 희미하고 얄팍하게 알고 있던 전공 관련 지식들을 한번에 정리할 수 있어서 좋았던 것 같다. 몇 달 뒤에 치를 고등교육재단 전공시험(그것도 별 변별력은 없다지만) 에 대한 대비도 되었고.

그런 의미에서, 성재와 김민장 씨가 그랬던 것처럼, 나도 후배들을 위해 관련 내용을 간단히 정리해보려고 한다. (스스로도 몇 달 후에 써먹을 수 있을 것도 같고 -_-)

준비

기본적으로 코드를 주고 결과값을 예상하는 문제가 5문제 정도는 된다. 머리 속에서 코드를 빠르고 ‘실수없이’ 돌리는 것이 중요하다. 나머지 문제들 중에서는 알고리즘, 오토마타, OS, Architecture가 상당 부분을 차지하고, 그외 토픽에서는 조금씩 골고루 출제된다. 모든 토픽에 대해 상세히 공부할 수는 없고 무엇보다 중요한 내용이 아닐 경우에 깊은 지식을 요구하는 경우는 드물기 때문에, 위에서 언급한 4개 부분에 대해서만 자세히 보고, 나머지는 토픽과 그 개념 정도만 이해하고 넘어가는게 효율적이다. 예를 들어 이번 시험에 Buddy Memory Allocation에 대해서 나왔는데, 뭔지 몰라서 찍지도 못했다 -_- 아마 이게 뭔지만 알고 갔어도 90% 맞출 수 있었을 거다.

실제 시험에서 가장 중요한 것은 ‘실수를 하지 않는 것’이다. 어려운 문제 푸느라 끙끙대는 것보다 쉬운 문제를 정확히 풀었는지 검산 한 번 더 하는게 이득일 수도 있다. GRE Subject 중 Computer Science가 통계상 평균이 가장 높고 분산이 상대적으로 작다. 그래서 평균 지점 근방에서는 1~2문제가 상당히 크게 작용할 수 있다. (각 문제당 배점이 모두 똑같다) 2시간 50분이 주어지지만 체감상 시간이 조금 부족하게 느껴지므로 미리 연습을 해보는게 좋다.

그리고 왠만하면 스터디를 구성해 공부하는 걸 추천한다. 나는 같이 할 멤버가 마땅치 않아 혼자 했지만(JP와 OS만 했음), 역시 혼자서 하는 건 자극도 덜하고 어려운 개념에 대한 이해도 느리다.

참고자료

GRE General과 가장 큰 차이점은 자료가 충분하지 않다는 것이다. 정확히 말하자면, 자료 자체는 널려있지만 ‘무엇을’ 공부해야 할지에 대한 감이 별로 없고, 그렇게 주먹구구로 공부한 것을 테스트할만한 문제셋이 충분하지 않다. 공식적으로 ETS에서 제공하는 모의고사 문제셋이 있긴 한데, 70문제 뿐이다.

기본적으로 학교 때 각 과목 수업에서 사용했던 교재들로 공부하면 무리가 없다. 최신 토픽이나 설명이 부족한 부분은 Google + Wikipedia ( + Wolfram) 조합으로 무조건 해결 가능하다.

위에서 언급한 성재와 김민장씨 포스팅에 링크되어 있는 것들이 우선 큰 도움이 된다.

• http://csuhak.info : CS 유학 커뮤니티 사이트
• http://www.cc.gatech.edu/~howardz/micellaneous/gre_cs_sub/ : ETS에서 공개한 토픽 출제 범위별로 링크 정리
• http://titanium.bits.googlepages.com/ : CMU 대학원생이 만든 모의고사 문제 & 솔루션

3번째 링크의 자료는 개인이 만든 것 치고는 상당히 완성도가 높다. 아래는 내가 참고했던 자료를 이것저것 짬뽕한 것이다. 위 링크에서 받을 수 있는 자료 외에 렉처노트 등이 포함되어 있다.

• http://mjipeo.net/study/GRE_Subject_CS.zip

주제

나름대로 중요하다고 (자주 출제되었다고) 생각되는 순서대로 정리했다. 개념만 공부해도 될 토픽과, 깊이 있게 이해해야 하는 토픽을 잘 구분하는 센스가 필요하다. 예를 들어 NP-Complete나 Turing Machine은 자세히 알고 있지 않으면 건드리지도 못할 문제가 꽤 있는 반면, RSA 알고리즘은 원리보다는 어떤 식으로 계산하는지만 알아도 된다.

• Algorithm
• Basic Data Structures
• Linked List, Tree, Graph, Hash Table, Heap, Binary Search Tree
• Advanced Data Structures
• Binomial Heap, Fibonacci Heap, Red-Black Tree, AVL Tree, B-Tree, Disjoint Set
• Analysis
• Order of Growth (Big-O, Big-Theta, Big-Omega)
• Recurrence Equation
• Master Theorem
• Sorting
• Bubble, Selection, Insertion, Shell, Heap, Merge, Quick, Bucket, Counting, Radix
• Order Statistics
• Dynamic Programming & Greedy Algorithm
• Amortized Analysis
• Graph
• Representation
• Adjacency Matrix, Adjacency List
• Traverse
• Inorder, Preorder, Postorder
• DFS
• Edge Classification
• Tree, Back, Forward, Cross Edge
• BFS
• Minimum Spanning Tree
• Kruskal, Prim
• Shortest Path
• Single Source
• Bellman-Ford, Dijkstra
• All Pair
• Floyd-Warshall, Johnson
• Maximum Flow
• Ford-Fulkerson
• Others
• SCC (Strongly Connected Component)
• Topological Sort
• Bipartite (Bigraph)
• Planar Graph (Euler’s Formula)
• String Matching
• Rabin-Karp
• Finite State Automaton
• KMP
• NP Theory
• P, NP, Co-NP, NP-Hard, NP-Complete, Reducibility
• Matrix Algorithms
• Approximation
• Linear Programming
• Simplex Method
• Automata & Formal Language
  
• Finite Automata
• DFA, NFA, e-NFA
• Regular Language & Expression
• Pumping Lemma for RE
• Pushdown Automata
• DPDA, NPDA
• Context Free Language & Grammar
• Pumping Lemma for CFG
• Turing Machine
• NTM, DTM
• Recursively Enumerable Language
• Recursive Language
• Reducibility
• Computability (Recursively Enumerable)
• Decidability (Recursive)
• Rice’s Theorem
• Halting Problem
• Church-Turing Thesis
• Operating Systems
• Basics
• Process
• Process Migration
• Thread
• User Thread, Kernel Thread
• Process Management
• CPU Scheduling
• FCFS, SJF, RR, Priority, Multiple Priority Queues, Interitance
• Priority Inversion
• Spin-Wait
• Concurrency
• Baker’s Algorithm
• Hardware Support
• Test-And-Set Instruction
• Semaphore, Monitor, Mutex
• Deadlock
• 4 Conditions for Deadlock
• Banker’s Algorithm
• Wait/Die & Wound/Wait
• Memory Management
• Addressing Modes
• Direct, Indirect, Register, Immediate
• Page & Segment
• Page Fault
• Page (Table) Size & Multilevel Page Table
• Swapping
• Disk Management
• Disk Scheduling
• FCFS, SCAN
• Capability vs ACLs
• Architecture
  
• Number Representation
• Floating Point (IEEE-754)
• Arithmetic Overflow
• Digital Logic
• Flip-Flop Circuit
• Karnaugh Map
• RISC
• Horizontal & Vertical Microarchitecture
• Alignment (Data Structure Alignment)
• Amdahl’s law
• Parellelism
• Hazard
• Data, Structural, Control
• Out-of-Order
• Superscalar
• Register Renaming
• Branch Prediction
• Cache
• Cache Misses
• Compulsory, Capacity, Conflict
• Unified/Split Cache (Instruction, Data)
• Multilevel Cache (L1, L2)
• Cache Coherency
• MSI, MESI, MOSI, MOESI
• Directory-based & Snooping
• Discrete Mathematics
• Relation
• Injection, Surjection, Bijection
• Partial order, Total order, Equivalence relation
• Countability
• First Order Logic
• Generating Function
• Recurrence Equation
• Master Theorem
• Resolution Theorem
• Information Theory
• Hamming Distance
• Error Detection & Correction
• Graycode
• Encoding (Compression)
• Huffman Code
• Run-length Encoding
• Lempel-Ziv-Welch Encoding
• Programming Language
  
• Lambda Calculus
• Continuation
• Currying
• Closure
• Variable Scope
• Parameter Passing
• Pass By Value
• Pass By Reference
• Pass By Name
• Pass By Value Result
• Garbage Collection
• Mark and Sweep
• Stop and Copy
• Reference Counting
• Network
• Circuit-Switched vs Packet-Switched
• OSI Layer Model
• Link Layer
• Ethernet
• Fast Ethernet
• Gigabit Ethernet
• Network Layer
• IP
• IP Fragmentation
• ARP (Address Resolution Protocal)
• Transport Layer
• TCP
• Application Layer
• HTTP, FTP, DNS, SMTP, SNMP
• Security
• Public Key
• OTP (One Time Password)
• RSA
• Integer Factorization
• Database
• Primary Key
• Numerical Analysis & Probability Theory
• Bayes’ Theorem
• Euclidean Algorithm
• Sieve of Eratosthenes
• Root Finding Algorithm
• Newton’s Method
• Method of False Position
• Bisection Method
• Secant Method
• Compiler
• Top Down & Bottom Up Parsing
• LALR, SLR, LR, LL
• Left Recursion
• Software Engineering
• Design Patterns
• Singleton, Factory, Adapter, Bridge, Composite, Decorator, Facade, Proxy, Command, Iterator, Observer, State, Strategy, Template Method

“당신이 나를 선택하지 않은 것이 인생의 가장 큰 실패가 될 것임을 기억하라”

나는 어떤 문제를 해결할 때, 외형적인 아름다움에 대해서는 전혀 생각하지 않는다. 오로지 어떻게 문제를 해결할 것인지에만 몰두한다. 하지만 작업을 마쳤을 때, 해결책이 아름답지 않다면 무언가 잘못되었다고 생각한다.

- R. Buckminster Fuller

프로그래밍 언어라는 것이 근본적으로는 기계어 생성을 위해 필요한 것이지만, 그보다 어떠한 로직을 ‘사람’이 쓰기 쉽고, 읽기 쉽게 만드는 효과가 훨씬 크다.

하지만 상당수의 개발자가 ‘쓰기’의 편의성은 마음껏 누리지만, ‘읽기’의 편의성에 대해서는 그다지 신경쓰지 않는 것으로 보인다. 가독성이 좋은 코드는 주석 하나 없어도 각 패키지, 클래스, 메쏘드, 변수이름만 보고도 대부분의 로직을 파악할 수 있다. if ~ else if ~ else if ~ 를 쓰지 않고 switch 를 쓰는 것은, 최적화보다는 디버깅과 가독성을 위해서 필요한 작업이라고 생각한다. 너만 보고 이해할 수 있으면 되는게 아니라고! 실제로 어떤 소스코드를 작성하면, 작성자가 아닌 사람이 그것을 들여다보는 시간이 압도적(90% 이상) 많다고 한다.

대부분 이런 부분에 신경쓰지 않는 이유는, 아무도 그런 것으로 인정해주지 않기 때문이다. 인덴팅 이쁘게 하고 변수명 직관적으로 잘 지었다고 인사고과에 반영해 주지는 않는다. 이직을 하기 전에는 자기 코드는 스스로 관리할 가능성이 크고, 이직한 이후에는 아웃오브안중이다. 용준이처럼 선천적으로 타고난 아름다움에 대한 강한 집착을 가진 아주 예외적인 케이스를 제외하고는, 듀를 맞추기 위해 개판오분전의 코드를 양산하기 일쑤다.

문제점를 인식하고 시스템적으로 이런 문제를 보완하고자 하는 움직임이 회사 내부적으로 생겨나고 있다. 이를테면 특정 메쏘드의 복잡성이 주어진 수치 이상일 경우네는 빌드&배포가 안되게 막아놓았다 (-_-) 여기서 복잡도랑 대애충 이해하기로는 분기 가능한 총 경우의 수다. 또 전에 알바를 잠깐 했었던 Static Code Analysis 툴을 몇억 주고 사와서는, 심각한 버그라고 판단되는 부분이 발견될 경우에도 마찬가지로 빌드&배포를 금지한다.

이러한 시스템은 ‘가독성’과는 별 관련성이 없을지도 모른다. 하지만 보기에 아름답고 엔트로피가 낮은 코드는 에러율도 낮을거라고 확신한다.

팀원들과의 인간적으로 소통할 수 있는 팀장이 정말 좋은 팀장인거 같다.

소통한다는게 굉장히 다양하게 해석될 수 있지만서도.

어차피 어느 정도의 개념과 능력과 경험은 그 정도 자리 올라갈 정도면 모두 갖추고 있을테니까.

결국 일은 사람이 하는 거다. 그것에 집중해야지.

엽문 재밌는 듯.

최근에 본 영화 중에 제일 나았다. 드라마와 액션이 적절히 조합되었다고 할까. 보통 볼게 많은 영화는 영화가 끝난 후 남는게 별로 없는데, 이 영화는 계속 여운을 남기고 무언가를 생각하게 한 것 같다.

아아. 아아아.

영춘권.

스스로 가장 서툴다고 생각하는 부분은 패배를 인정하는 것이다.

심지어 패배를 인정하지 않는다는 사실조차 인정하지 않는다.

정말 가슴이 쓰린 일이다.

아아. 이 개똥같은 자존심이란.

하지만 이 쓰라림을 통해 한 단계 더 성장할 것임을 알기에.

그래! 내가 잘못했다!

“창의력은 사물을 새롭게 보는 것이다. 의문을 갖고 질문을 많이 해야 한다. 질문을 많이 하려면 본게 많아야 한다. 독서와 여행을 하고 사람을 많이 만나야 한다. 조직의 창의력은 다양성에서 나온다.” - 정운찬 前 서울대 총장

기업은 결국 ‘수익’을 위해 존재한다. 누구도 이 사실을 부정하지 않는다. 하지만, 수익만을 추구하는 것이 과연 옳은 것인가의 문제는 차치하더라도, 그 수익 추구라는 과정 조차 항상 효율적으로 돌아가진 않는다.

준선이랑 룸메를 하며 한창 공부를 열심히 하던 시절, 우리는 ‘프리스타일’이란 게임에 빠져있었다. (모두 같이 거리로 hook up! ♬) 시험이 일주일 후건 3시간 후건, 중요한 시험이건 자잘한 시험이건, 우리는 매일 최소 1~2시간은 그 게임을 즐겼었다. 공부를 몇 시간씩 연속으로 ‘집중’해서 하는 건 쉬운 일이 아니다. 누구나 경험 해봤겠지만, 시험 직전의 집중력은 정말 엄청나다. 그 집중력이 보여주는 효율성은 말할 것도 없다. 저런 식으로 중간 중간 게임 등으로 딴 곳으로 시선을 돌렸던 것이, 그 당시에는 단지 너무 오래 공부하기 지겨워서 그랬던 거였지만, 결과적으로 보았을 때는 생산성을 크게 올려주었던 것 같다.

그렇다면 회사에서라고 이것이 적용되지 않을 이유는 없다. 자기 자신이 업무효율성을 높일 수 있다면, 그 사람이 업무시간을 활용하는 것에 대한 충분한 자유가 주어져야 한다고 생각한다. 물론 상식적으로 지켜야할 기본은 존재해야 한다. 그 자유가 방종이 된다거나, 그것으로 인해서 다른 팀이 그 사람과 의사소통하기가 불편해진다면 문제가 되겠다. (자리를 오래 비운다거나, 메일 확인 안하고 게임만 한다거나) 평가는 항상 Input과 Output으로만 이루어진다. 만약 어떤 사람이 Input이 너무 없어서 매일같이 놀기만 한다면, 그것은 팀장의 업무 분배에 문제가 있거나, 그 사람의 역량에 문제가 있는 거다.

좀 다른 측면에서 이 문제를 바라볼 수도 있다. 기본적으로 기업은 이익을 내기 위한 목적으로 직원을 뽑고 의자를 주고 컴퓨터를 주지만, 직원 입장에서 바라보았을 때 회사라는 공간은 자기가 눈을 뜨고 있는 시간의 반, 인생의 반을 소비하는 공간이다. 회사라는 곳이 단지 돈을 벌기 위해 종사하는 곳이라고 보기에는 비중이 너무 높다. 인생 그 자체일 수도 있다. 돈은 물론이고 인간관계을 비롯한 대부분의 상호작용이 회사를 중심으로 이루어지기 때문이다. 이건 회사가 그 사람의 인생을 존중해야 한다는 의미가 아니라, 그것으로 발생될꺼라고 예상되는 효율성으로 시선을 돌려야 한다는 것이다.

사무실을 돌아다니면서 사람들 스크린을 자주 본다. 100이면 99가 Eclipse와 Putty를 띄어놓고 키보드를 두드리고 있다. 어떻게 보면 참 당연한 모습인데, 가끔 무언가 ‘공장’같다는 느낌이 든다. 회사가 설정한 이상적인 개발자의 모습(버그를 만들지 않으면서 주어진 요구사항을 100% 구현하는 빠른 코딩 속도의 프로그래머)이 있고, 모든 개발자가 그 모습이 되도록 획일화시켜 간다. 똑같은 교육을 받게하고 똑같은 교재를 공급하며 똑같은 방법론을 제공한다. 결국 같은 조직 내에서는 역량과 수준이 도토리 키재기다. 특별한 이슈가 발생했을 때, 해결하는 방식은 물론 접근 방식도 그게 그거다. 창의성이란 없다. “개발자가 왜 창의력이 필요한대?”라고 묻는다면, 그것에 대한 답변은 길다. 하지만 각 구성원의 개성이 두드러지고 그 표준 편차가 크면 클수록 더 높은 창의성을 보일 것은 자명하다. 물론 그것이 ‘공장’ 시스템에서는 효율성을 떨어뜨릴 수도 있겠다.

이런 비슷한 얘기를 최소 5~6년 이상의 경력을 더 가진 직장 선배에게 물어보면, 십중팔구 하는 얘기라고는 “회사라는 곳이 ‘원래’ 그런 곳이야” 뿐이다. 원래! 바로 대부분의 사람들이 위 아래 할 것 없이 다 그렇게 생각하고 있다는 것이 현 시스템을 변화시키는게 가장 큰 장애물이 아닐까 한다. 결국 자신이 비즈니스를 일으키지 않는 한, 현실적으로 현 체계를 변화시키는 것은 불가능하다.

언제나 꺼름칙한 느낌을 지울 수 없다.