[참고] Linux Shell Programming

2011. 6. 15. 20:08 | Posted by 꿈꾸는코난

Table of Contents

Chapter 1: Quick Introduction to Linux
What Linux is?
Who developed the Linux?
How to get Linux?
How to Install Linux
Where I can use Linux?
What Kernel Is?
What is Linux Shell?
How to use Shell
What is Shell Script ?
Why to Write Shell Script ?
More on Shell...
Chapter 2: Getting started with Shell Programming
How to write shell script
Variables in shell
How to define User defined variables (UDV)
Rules for Naming variable name (Both UDV and System Variable)
How to print or access value of UDV (User defined variables)
echo Command
Shell Arithmetic
More about Quotes
Exit Status
The read Statement
Wild cards (Filename Shorthand or meta Characters)
More commands on one command line
Command Line Processing
Why Command Line arguments required
Redirection of Standard output/input i.e. Input - Output redirection
Pipes
Filter
What is Processes
Why Process required
Linux Command(s) Related with Process
Chapter 3: Shells (bash) structured Language Constructs
Decision making in shell script ( i.e. if command)
test command or [ expr ]
if...else...fi
Nested ifs
Multilevel if-then-else
Loops in Shell Scripts
for loop
Nested for loop
while loop
The case Statement
How to de-bug the shell script?
Chapter 4: Advanced Shell Scripting Commands
/dev/null - to send unwanted output of program
Local and Global Shell variable (export command)
Conditional execution i.e. && and ||
I/O Redirection and file descriptors
Functions
User Interface and dialog utility-Part I
User Interface and dialog utility-Part II
Message Box (msgbox) using dialog utility
Confirmation Box (yesno box) using dialog utility
Input (inputbox) using dialog utility
User Interface using dialog Utility - Putting it all together
trap command
The shift Command
getopts command
Chapter 5: Essential Utilities for Power User
Preparing for Quick Tour of essential utilities
Selecting portion of a file using cut utility
Putting lines together using paste utility
The join utility
Translating range of characters using tr utility
Data manipulation using awk utility
sed utility - Editing file without using editor
Removing duplicate lines from text database file using uniq utility
Finding matching pattern using grep utility
Chapter 6: Learning expressions with ex
Getting started with ex
Printing text on-screen
Deleting lines
Coping lines
Searching the words
Find and Replace (Substituting regular expression)
Replacing word with confirmation from user
Finding words
Using range of characters in regular expressions
Using & as Special replacement character
Converting lowercase character to uppercase
Chapter 7: awk Revisited
Getting Starting with awk
Predefined variables of awk
Doing arithmetic with awk
User Defined variables in awk
Use of printf statement
Use of Format Specification Code
if condition in awk
Loops in awk
Real life examples in awk
awk miscellaneous
sed - Quick Introduction
Redirecting the output of sed command
How to write sed scripts?
More examples of sed
Chapter 8: Examples of Shell Scripts
Logic Development:
Shell script to print given numbers sum of all digit
Shell script to print contains of file from given line number to next given number of lines
Shell script to say Good morning/Afternoon/Evening as you log in to system
Shell script to find whether entered year is Leap or not
Sort the given five number in ascending order (use of array)
Command line (args) handling:
Adding 2 nos. suppiled as command line args
Calculating average of given numbers on command line args
Finding out biggest number from given three nos suppiled as command line args
Shell script to implement getopts statement.
Basic math Calculator (case statement)
Loops using while & for loop:
Print nos. as 5,4,3,2,1 using while loop
Printing the patterns using for loop.
Arithmetic in shell scripting:
Performing real number calculation in shell script
Converting decimal number to hexadecimal number
Calculating factorial of given number
File handling:
Shell script to determine whether given file exist or not.
Screen handling/echo command with escape sequence code:
Shell script to print "Hello World" message, in Bold, Blink effect, and in different colors like red, brown etc.
Background process implementation:
Digital clock using shell script
User interface and Functions in shell script:
Shell script to implements menu based system.
System Administration:
Getting more information about your working environment through shell script
Shell script to gathered useful system information such as CPU, disks, Ram and your environment etc.
Shell script to add DNS Entery to BIND Database with default Nameservers, Mail Servers (MX) and host
Integrating awk script with shell script:
Script to convert file names from UPPERCASE to lowercase file names or vice versa.
Chapter 9: Other Resources
Appendix - A : Linux File Server Tutorial (LFST) version b0.1 Rev. 2
Appendix - B : Linux Command Reference (LCR)
About the author
About this Document

http://www.freeos.com/guides/lsst/

[펌] 프로그래머의 격언

2009. 8. 31. 19:45 | Posted by 꿈꾸는코난

1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그래머는 내가 원하는 대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사항은 프로그램을 완성한 후에 추가된다.
    기본 사양은 완성품을 고객이 보고 난 다음에 결정된다.
    상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.
    하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
    다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
    디버그는 납기일까지 하는 것이 아니라 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구 사항을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.  
    주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
    이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.  

12. 개발 스케줄은 산수를 무시하며 짜여진다.
     영업과는 1+1 = 2를 이해하지 못하는 사람의 모임이다.  

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
     나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
     시스템 엔지니어에게 고객은 돈이다.
     프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
     웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
     시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
     프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의  
     목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는  
     도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
     운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
     따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
     일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.  
     미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고
     한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고,
     그 사이, 쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진
     개발일자와 납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고
    부르는 것 같다.  

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
     영업은 꿈을 말한다.
     시스템 엔지니어는 공상을 이야기한다.
     프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
     1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
     않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.  

37. 아마추어는 버그발견의 천재이다.  

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.  

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.  

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고
     생각한다.
     시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
     프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것
     같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.  

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는
     사실을 깨닫고 빨리 최종요구조건을 확정하는 것이다.  
     SE가 고객에게  사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.  

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
     개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
     개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
     개발비의 10%만이 프로그램의 개발에 사용된다.

의사소통의 중요성은 다들 잘 아시리라 생각됩니다.

힘이나 상하관계에 의한 일방적인 커뮤니케이션이 아니라 상호 *소통*이 중요하다는 것을…

물론 *소통*을 다른 개념으로 사용하고 있는 듯한 사람이 있긴 하죠.

뇌 용량이 지극히 부족한 누구처럼…


주어진 일을 할 때 100% 판단 가능한 근거를 가지고 일을 시작하는 것은 거의 불가능에 가깝습니다. 아무리 많은 시간이 주어지더라도 어떤 것에 대해 100% 이해하고 시작하는 것이 쉬울까요?

따라서 일을 하면서 한정된 판단 근거를 가지고 판단해야 하는 과정이 반복됩니다. 그리고 그때마다 올바른 판단이 이루어진다면 주어진 일은 목적지를 향해 한발씩 더 다가가는 형태가 될 겁니다.

이때 올바른 판단을 위해 여러 가지 방법을 사용합니다. 예를 들어 다른 사람의 의견을 많이 듣고 판단한다거나 다양한 시스템(도구)을 활용하여 제대로 된 판단 근거를 유도하는데 사용하는 것입니다.

 

하지만 아무리 많은 좋은 데이터가 있더라도 결정은 사람이 하는 것입니다.

100% 올바른 데이터는 없기에… 또한 잘못된 데이터가 있기에…

 

그걸 잘 가려내어 올바른 판단을 할 수 있는 능력이 중요할 것입니다.


어떤 일을 할 때 각자 고유한 방식이 있습니다.

여기서 말하는 고유한 방식이란 게 사람마다 조금씩 다른 뭔가를 얘기하는 것이 아니라 좀 근본적인 두가지 측면을 말합니다.

 

A 스타일은 어떠한 문제가 주어졌을 때 그 문제를 분석하고 어떻게 해결해나갈지 방향을 생각하고, 또 그 내용을 정리하고 정리된 내용을 분석하고 그런 과정을 반복적으로 수행합니다. 근데 이 스타일이 너무 강해지면 문제의 본질을 망각해버리는 상황이 발생하게 됩니다. 예를 들어 주어진 문제를 풀어보니 코끼리를 그려야 한다면 처음에는 전체적으로 필요한 것을 파악하고 고민하고 그러다가 어느순간 코끼리는 사라지고 코만 계속 그리고 지우고 하는 과정이 되는거죠. 시간이 많이 흐른 다음에 “내가 뭘하고 있지” 느끼게 될 때가 있는데 이미 많이 늦어진거죠.

B 스타일은 어떠한 문제가 주어졌을 때 일단 구체화 과정까지 가보는 겁니다. 개발을 예로 든다면 어떤 문제가 있으면 일단 코드부터 수정을 해보는 거죠. 해보다가 안되면 다른 방법을 찾고 또 해보고 이러한 과정이 반복되는 것입니다. 근데 이 스타일이 너무 강해지면 시도해보지 않아도 빤한 일을 시도하는 경우가 생기고 빠뜨려지는 부분이 항상 생긴다는 겁니다. 예를 들어 동물원을 그려야 된다면 일단 대충 생각해서 호랑이, 사자, 곰 등을 그립니다. 다 그려놓고 다른 사람이 보니 동물원 건물 자체가 없습니다. 고민을 하게 되죠. 다 지우고 동물원 건물부터 다시 그려야 하나 아님 일단 그린 동물 사이사이에 동물원 건물을 그려 넣을까…

 

둘 다 극단적인 예입니다. 대부분의 사람들이 A 스타일과 B 스타일을 다 가지고 있습니다. 다만 어느 스타일 측면을 가지고 있냐에 따라 일하는 방식이 조금씩 다를 뿐이죠. 둘이 적절히 잘 조화를 이루게 되면 가장 좋겠지만 말만큼 쉬운 건 아니죠.

하여튼 어떤 일을 해야 할 때 세부적으로 내용을 잘 정리하고, 정리된 내용을 바탕으로 각각을 해결해 내갈 방안을 잘 고민하고 생각하는 게 중요합니다.

적어도 자신이 뭘 해야 하며 어떻게 해야 하는지는 계속적으로 고민해 나가는 것이 꼭 필요합니다.

그렇지 않으면….


예전에 프로젝트를 진행할 때 팀원 중에 이런 사람이 있었습니다.

개발계획서를 작성하고 프로젝트에 대한 일정을 생각해서 달라고 하니 아직 개발(여기서는 코딩을 말함)도 시작 못했는데 일정을 어떻게 알 수 있냐고 했습니다. 그럼 언제 개발이 완료될지 알 수 있냐고 했더니 개발이 끝나봐야 알 수 있다고 하더군요(OTL).

 

물론 무슨 일을 시작할 때 문제점이 무엇인지, 어떻게 문제점을 해결해 나갈지, 진행하면서 무슨 새로운 일이 생길지 알 수 없는 상태에서 일정을 도출해 내기란 불가능에 가까울지 모릅니다.

하지만 어떠한 조직에서 일을 할 때 일에 대한 예측 없이 진행한다는 것은 앞으로의 계획을 전혀 만들 수 없다는 것과 같습니다(언제 끝날지 모르는데 앞으로 계획을 세우는게 가능할까요?)

특히 개발이라는 무형의 괴물(?)을 봤을 때 언제 어떤 식으로 돌변해서 자신을 덮칠지 모르기 때문에 일정을 예측하기는 더욱 어려운 것 같습니다.

다만 일정을 예측할 때 지난 경험을 바탕으로 다양한 시나리오(앞으로 발생 가능한 일, 문제점 등등)를 감안하여 최대한  (?) 만드는 것이 중요할 것입니다.

 

근데 혹시 student syndrome이라고 아시나요?

해야 할 일을 미루고 있다가 결국 마지막 순간이 되어서야 실행하는 습관을 말합니다.

방학숙제를 쌓아두고 개학 전날 시작한다거나, 기말고사 준비를 시험기간 직전에 몰아서 한다거나 하는 식의 학생들의 버릇을 빈댄 거죠.

사실 회사 업무도 비슷한 경향이 있는 것 같습니다. 데드라인이 있으면 논리적으로는 그 전 언제 까지 어떻게 하는 등의 일정 수립을 합니다. 그러나 이상하게도 심리적으로는 데드라인이 가까이 오기 전까지는 시작을 하지 않는 경향이 있답니다. 항상 날짜가 많이 남아있어 보이죠. 그래서 막판까지 가다가 지금 시작하지 않으면 데드라인을 맞추기 어려울 것 같은 시점에서 드디어 발등에 불이 떨어지는 것을 느끼고 시작하게 되는 것이죠. 근데 그 깨닫는 시점이 늦을 수록 결과는 엉망이 되는 것입니다.


대부분의 회사에서 개발에 관련된 사항을 프로젝트화 해서 진행하고 있습니다.

“프로젝트”란 주어진 요구사항을 주어진 자원을 이용하여 주어진 기간동안 수행하는 것을 말합니다.

일상적인 업무와 프로젝트의 차이점이 바로 주어진 기간 동안 한시적으로 운영된다는 것이죠.

 

사실 조그만 조직에서는 프로젝트화 하는 것이 필요 없을 지도 모릅니다.

개발에 참여하는 인원이 소규모이고, 따라서 하는 일이 빤히 보이는 상황이기 때문에 프로젝트화한다는 것이 별로 의미가 없어 보일 수도 있죠.

하지만 항상 이 정도의 규모로만 개발이 진행된다고 볼 수 없기 때문에 프로젝트 기반으로 업무를 수행하고 체계화해 나가는 분위기를 익히고 경험하는 것은 매우 중요하다고 할 수 있습니다.

 

규모나 참여 인원에 따라 프로젝트 관리 방법도 상당히 많이 다르겠지요.

그래도 기본적으로 해야 할 일을 명확히 정의하고, 그 일을 누가, 어떻게, 언제까지 할 것인지를 미리 결정하고 진행하는 것은 기본이라고 볼 수 있습니다.

그리고 중간 중간 진행 상황에 대해 검토하고, 그 결과에 따라 다음 진행 방향에 대해 보완해 나가는 것이 필요하죠.

소프트웨어 공학에서 얘기하는 것처럼 시스템적이고 체계적이고 이론적인 부분이 현실에 적용되기는 상당히 어렵습니다. 다만 근본적인 개념을 이해하고 그 개념을 속해있는 조직의 현실에 맞게 접목하는 것이 가장 중요하다고 볼 수 있습니다.

 

앞으로 당분간은 일을 진행할 때 각자가 사전에 많은 생각을 하도록 유도하고, 기술적인 부분 검토나 아이디어 도출에 좀 더 많은 시간을 할애할 수 있도록 할 계획입니다.

모든 프로젝트가 그렇다고 할 순 없지만, 대부분 사전에 많은 고려를 하게 되면 나중에 완전히 엉뚱한 방향으로 일이 잘못 나아가는 것을 최소한으로 방지할 수 있습니다.

그리고 코딩 들어가기 전에 머리 속으로 체계화시킬수 있는 능력도 좀더 키우는 것이 필요할 것이라고 생각됩니다. 누가 대신해 줄 순 없지만 그렇게 하도록 유도할 순 있겠죠….

당신의 조직은 개발자를 올바르게 관리하고 있는가?

류한석(IT 컬럼니스트)   2007/10/09
 
한국의 많은 소프트웨어 업체들이 개발자를 제대로 관리하지 못하고(또는 안하고) 있다. 소프트웨어 개발은 정신에 의한 작업이다. 누가 하는 가에 따라서, 어떤 동기부여를 하는 가에 따라서, 어떤 환경에서 하는 가에 따라서, 어떻게 관리하는 가에 따라서 엄청나게 다른 결과를 만들어낸다.

하지만 관리라는 이름 하에 개발자에게 모욕적인 대우를 하는 경우도 많다. 작업에 지장이 있을 정도의 저사양 개발장비를 제공하고, 좁아터진 공간에, 계속 울리는 전화벨과 시끄러운 대화 소리, 휴식공간이라고는 전혀 없는 조직도 많다. 직원들의 일거수일투족을 감시하고, 심지어는 복장 검사를 하는 경우도 있다.

또한 프로젝트 데드라인을 맞추기 위해 새벽에야 겨우 집에 들어갔음에도 불구하고, 출근시간에 몇 분 늦었다고 해서 지각을 체크하고 전체 직원이 모인 회의에서 실명을 거론하는 회사도 있다. 그런 회사일수록 야근수당이 없고 교통비도 지급하지 않으며 사소한 비용을 아낀다. 한마디로 작은 비용을 절약함으로써, 신뢰 상실이라는 큰 비용을 지불하는 것이다.

그런 회사에서 만들어지는 소프트웨어는 품질이 나쁘다. 불행한 개발자들은 품질이 나쁜 소프트웨어를 만들어 낸다. 어쩌면 잠을 못 자고 피로에 지친 개발자들이 내쉬는 서글픈 한숨이 소프트웨어의 영혼에 스며들어 가는 것은 아닐까? 저주받은 소프트웨어. 마치 호러영화의 한 장면처럼 느껴진다.

회사는 직원들을 사랑하지 않으면서, 직원들에게 애사심을 강요하는 회사를 보고 있자면 실소가 나온다. 물론 회사로서는 직원들에게 사랑을 보여줄 수 없는 가장 큰 이유가, 열악한 비즈니스 환경으로 인한 비용적 압박 때문이라고 얘기할 것이다. 백분 양보하여 그것을 인정한다고 할 지라도, 그렇다면 도대체 왜 부적절한 관리자에게 관리를 맡기고 있는 것일까?

나쁜 관리자가 프로젝트를 망치고 있다!
업계를 보면 관리자의 자격이 전혀 없는 사람이 관리를 맡고 있는 경우가 무척 많다. 나쁜 관리의 비용은 엄청나다. 단지 팀 구성원들의 작업에 지장을 주는 정도가 아니라, 조직의 목표 달성에 해악을 미치며 결국 상당한 대가를 치르게 만들고 프로젝트를 완전히 망치는 경우가 빈번하다.

필자는 단지 관리자를 잘못 배정했기 때문에 수백억 원의 손해를 본 어느 대기업의 프로젝트를 경험한 적이 있다. 팀원들은 모두 유능했고 각자의 마음 속에 일을 잘하고자 하는 열정이 있었지만, 관리자의 무능과 변덕과 학대로 인해 팀원들은 모두 좀비가 되어갔다. 일부는 떠났고 일부는 일을 하지 않았고 일부는 하는 척을 했다. 결국 수년간 프로젝트를 진행했으나 결과는 나오지 않았고 프로젝트는 취소됐다. 몇 가지 추가적인 원인이 없었던 것은 아니지만, 가장 주요한 요인은 ‘나쁜 관리자의 존재’ 그 자체였다.

나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.

그러한 나쁜 관리자의 존재가 지극히 예외적인 경우라고 생각하는가? 만일 그렇다면 당신은 조직 생활의 경험이 많지 않든가, 아니면 억세게 운이 좋은 경우일 것이다. 그런 나쁜 관리자로 인하여 젊은 시절의 소중한 경험을 빼앗기는 팀원들이 몹시 많다.
나쁜 관리자의 해악은 단지 프로젝트의 실패로 나타나는 것뿐만 아니라, 사람들의 인생에서 그 시기에 필히 겪어야 할 소중한 경험까지 앗아가 버리는 것에 있다. 좋은 관리를 받아보지 못한 사람은 좋은 관리를 할 수가 없다.

좋은 관리자가 되기 위한 지침
그렇다면 좋은 관리란 어떻게 관리하는 것인가? 하단과 같이 몇 가지 지침을 제시할 수 있을 것이다.

첫째, 바라는 결과를 명확히 알려주어야 한다. 어떤 관리자들은 자신이 무엇을 원하는지 자기 스스로도 정확히 모르는 채 작업을 지시하고, 팀원의 작업 결과를 그날그날의 기분에 따라 자신의 기호대로 판단하곤 한다. 그런 관리자는 관리자로서의 자격이 없다.

둘째, 위임을 적절하게 수행해야 한다. 어떤 사람의 그릇은 위임할 수 있는 양의 크기로 정해진다. 즉 어떤 사람이 이루어낼 수 있는 최대 성과치는 그가 팀원들에게 권한을 위임할 수 있는 능력에 의해서 결정된다는 뜻이다. 할 일이 너무나 많지만 일할 시간이 없고 혼자서 모든 일을 처리하려고 하는 관리자는 탈진증후군(burnout syndrome)에 빠지게 된다. 그리고 탈진증후군에 빠진 관리자는 결국 팀을 궤멸시킨다.

셋째, 방법보다는 결과에 초점을 맞추어야 한다. 이 말에 오해가 없기를 바란다. 오로지 결과만 중요시하라는 뜻이 아니라, 결과가 올바르다면 방법은 팀원에게 맡겨두라는 뜻이다. 개발자 출신의 관리자는 자신이 선호하지 않은 방법으로 구현을 했다는 이유로 팀원을 질책하거나 업무를 회수하는 잘못을 저지르는 경우가 많다. 그런 관리자는 좋은 결과도 팀원들의 신뢰도 얻지 못할 것이다. 결과가 옳다면 그 방법은 팀원에게 맡겨두는 포용력을 가져야 한다.

넷째, 피드백을 주고, 코칭을 하고, 경력 개발을 지원해야 한다. 피드백이란 해당 직원의 업무 결과에 대해 어떻게 생각하는지 그 내용을 전달하는 것이다.
코칭은 일종의 도움을 주는 것으로서 선택 가능한 사항들 속에서 실행 계획을 만들도록 도와주는 것이다. 그리고 팀원이 새로운 지식과 경험을 쌓음으로써 성장할 수 있도록 경력 개발을 지원해야 한다. 팀원의 경력 개발에 전혀 신경을 쓰지 않은 관리자들이 너무 많다. 그것은 팀원을 일회용품으로 취급하고 있음을 스스로 증명하는 것과 같다. 경력 개발에 도움을 받은 팀원은 관심을 갖고 도와준 관리자를 언제까지나 기억할 것이다.

다섯째, 좋은 관리자는 자기 자신을 관리하는 사람이다. 좋은 관리자는 감정의 폭발에 반응하기보다는 사건에 대응한다. 불필요한 감정을 발산하여 팀원에게 공포심을 조장해서는 안 된다. 만일 감정이 폭발했거나 또는 잘못된 지시를 했다고 판단될 시에는 즉각 솔직하게 인정하고 사과를 해야 한다. 실수를 인정하는 관리자는 인간적으로 보인다.

좋은 관리 방법을 배우기는 힘들다. 왜냐하면 그것은 눈에 잘 보이지 않기 때문이다. 하지만 우리는 그것을 배우고 실천해야 한다.
그것이야말로 업계에 만연된 악순환의 고리를 끊어버리는 유일한 방법이기 때문이다. 우리가 겪은 불행한 경험을 다시금 후배들에게 전달해서는 안 된다.

비록 기술 중심의 소프트웨어 업체라고 할 지라도, 기술 관리란 기술이 아니라 사람을 다루는 것임을 잊지 말아야 한다. 회사가 가능한 범위 내에서 최상의 업무 환경을 제공하고, 개발자 개개인을 세심히 배려하는 피드백, 코칭, 경력 개발을 지원하는 관리자가 있는 조직이라면 개발자는 결코 불행하지 않을 것이며 더 나아가 어려운 일도 기꺼이 극복해 낼 것이다.

하지만 지금 이 순간에도 많은 기업들이 사소한 비용 절감과 무의미한 규칙 준수를 위해 직원들의 신뢰를 잃고 있으며, 나쁜 관리자를 배정함으로써 프로젝트와 팀원의 인생을 망치고 있다. 나쁜 관리자는 개인, 회사, 사회 모두에 악영향을 미치는 존재이다.

반면에 좋은 관리자는 탁월한 결과를 만들어내고 팀원들을 성장시키고 사회 전반에 좋은 인재를 공급한다. 그런 훌륭한 관리자가 어디 흔하냐고 항변하는 기업의 목소리가 들린다. 하지만 기업들이여, 그런 변명보다는 좋은 관리자를 채용하려는 노력, 그리고 양성하려는 노력, 그리고 그가 ‘진짜 관리’를 제대로 수행하였는지 평가하려는 노력을 무엇보다 먼저 기울여야 하지 않을까?
이전 1 2 다음