버그는 제품이 개발되면서 생기는 자연스러운 현상이다. 이 버그는 항상 존재할 수 있음을 항상 가슴 속에 자연스럽게 담아야 하며, 버그로 인해서 어떤 문제가 생기는 것이지, 어떻게 해야해야 하는 것인지를 잘 깨달아야 할 것이다.
버그는 어떻게 생기는 것일까?

1. 요구사항의 이해 부족
요구사항이라고 할 수 있고, 표준에 대해서 제대로 이해하지 못해서 문제가 생길 수 있다.
특히 디자이너가 디자인 기획을 하고 나서, 명확한 UI 네비게이션을 생각하지 못하고, 기획을 하다가 구현을 하고 나서 문제가 생긴 경우가 종종 있다.

UI 요구사항에서 문제가 생긴 경우가 있다. 윗쪽 화살표만 가지고도 채널 업, 볼륨 업, 네비게이션에 대한 윗쪽 방향인지 구현하다가 문제의 소지를 그 때서야 발견하고, 기획자체를 수정하는 일이 생긴 적이 있다.

또는 개인적으로 자주 하는 것인데, 표준 문서에 대한 잘못된 이해에서 버그가 생길 수 있다. 분명 A, B를 이용해서 C를 만들어야 한다. 이렇게 되어 있어 있으면, A,B,C,D를 구현해서 E를 사용하게 하는 인터페이스를 만들어서 주위 프로그래머들을 고생시킨 적이 있다.

개발하기 전에 여러 시나리오에 대해서 체크하고, 잘 모르면 상급자에게 물어서 확인하고 잘 넘어갈 수 있도록 해야한다.

2. 지식의 부족
언어의 특징 혹은 개발 플랫폼에서의 특수한 상황을 인식하지 못한 상태에서 일어날 수 있는 버그가 있다.

정상적인 종료가 안되거나, 확실하게 null 또는 deconstructor를 호출하지 않아서 메모리에 조금씩 조금씩 메모리가 쌓여서 시스템이 작동이 되지 않는 현상을 발견될 수 있다.

메모리 할당을 잘못해서 스택이 엉키는 경우가 존재할 수 있으며, 한번은 CLDC의 thread와 관련된 suspend/resume을 제대로 이해하지 못해서 꼬일 수 있으며, 비동기 이벤트에 대한 처리를 잘 못해서 시스템이 깨질 수도 있다.

언어자체에 대한 공부가 필요하며, 만든 이에게 interface를 잘 사용하고 있는지 확인하거나 interface문서를 보도록 해야한다.


3. 잘못된 환경설정 파일
코드는 완벽히 잘 되어 있는데, 환경 변수를 잘못 기입하여 혼동된 값을 저장하여 문제를 일으킬 수 있는 부분이 있다.

assert를 잘 이용하거나 로그를 꼭 찍는 일이 필요하다.


4. 사명감
버그는 사람을 피곤하게 한다.
책임감과 사명감을 가지고 제품의 완벽성을 추구하려고 하는 것이 좋다.

그리고, 관리자는 적당하게 버그가 크리티컬하지 않으면, 나름대로 협상을 통해서 가이드라인을 정해서 버그를 피해 갈 수 있는 방법을 고객에게 제시하는 것이 필요하다.
모든 자동화는 복잡성을 늘리는 것이므로, 어느 정도의 수준의 합리적인 타협은 필요하다.
그렇다고 해서, 대충대충 넘어가는 것은 아니며, 제품이 완벽해 가는 과정속에서 사명감을 가지고 책임을 다해 제품이 나올 수 있도록 개발자 스스로, 관리자가 독려해야 한다.

먼 미래나, 힘든 프로그램 환경이나, 갑회사의 장으로부터 문제생기면 '박살'을 내겠다(사실은 더욱 좋은 것으로 패취해주는 것이었음. 그 말 생각해보니, 공기업은 깡패라는 생각이 들었다.) 라는 소리를 들으면, 우울하다.
돈받고 일하는 것이지만, 서비스를 제공하는 입장으로서는 썩 기분이 좋지 않다.

소프트웨어 개발 자체가 3D업종이라는 것은 소프트웨어업계에서 알려진 것이고, 싼 임금으로 밤새도록 돌리면 다 되는지 알고, 밤새워 해도, 인정받기 어려운 부분이 존재한다.
비전이 없기에 똑똑한 사람들은 다들 떠나고, 떠나지 못한 무능력한 관리자들 덕택에 새로 들어온 직원은 밤마다 시달린다.

내가 보는 소프트웨어 공학은 바로 이런 문제에서 시작되었다. 짧은 시간내에, 고품질의 소프트웨어를 산출어 내는 단계가 쉽지 않다. 어떻게 하면, 잘, 고급스럽게, 제 시간에, 삽질하고 않고 고품질의 양질의 소프트웨어를 만들어 낼 수 있을까?

요구사항 -> 설계 -> 구축 -> 테스팅 -> 유지보수

이 과정을 잘하는 것이 소프트웨어 공학이라고 생각이 든다. 버클리 대학의 소프트웨어 공학 교재에서는 "소프트웨어 공학은 가르칠 수 없다. 그러나 배울 수 있다."라는 구절이 있다고 한다. 소프트웨어 공학은 체계적인 교육이 아닌 체험에서 나온 것임을 잘 알려주는 것이다.

소프트웨어가 전부가 아닌 다양한 경험을 기반으로 해야 한다. 그리고, 그 경험을 인정해 주는 분야가 되어야 한다. 그리고, 그 경험을 싸구려처럼 여기는 관리자들가 있다하더라도 전문가가 되어야 한다.

비관하는 마음을 없애기 위해서는 자기 스타일을 죽여야 한다. 공학적이고, 자기 겸손적이고, 자신이 깨져야 서서히 보이는 것이 틀림이 없다. 긴 인생, 길게 보면서 가야지.. 짧은 목표 의식에 그 목표를 이루지 못해 비관한다면, 전문가가 되기보다는 비관주의자가 되기 쉽다.

자신을 비하하기 않기 위해서는 때로는 필요없는 욕심을 줄여야 한다. 힘을 다해서, 최선을 다해되 그 결과가 성공하지 못했다고 비하하지 않고, 환경이 나를 무너뜨리지 않고, 오기를 가지며 희망을 가져야 한다.
결국은 언젠가 그 결실을 맺을 거라 생각이 든다.

성실, 인내, 면학 이 세가지가 꾸준히 자기를 발전시키고, 자기 비하하는 시간을 줄이며, 목표를 향해 전진하는 좋은 덕목이 되는 것이 과거나 현재나 미래나 똑같이 써먹는 항목인거 같다.

사람을 키우는 리더쉽은 가장 어렵다. 인내와 자제와 스스로의 괴리감과 자신감부족, 조급함때문에 쉽게 이루어 지지 않고 계속 연단되어 훈련되어져야 비로서 그 리더쉽을 통해서 조직이 발전될 수 있다.

'새로운 경험 + 상황에 맞는 교훈 * 사랑 = 성장'

이 내용은 어느 책에서 가져온 글이다. 즉 성장은 새로운 경험에 비례하지만, 상황에 맞는 교훈 과 사랑과 비교한다면 그렇게 큰 변수는 아니라는 사실이다. 즉 관리자는 사랑이라는 가장 큰 변수를 통해서 사람을 키울 수 있다. 그래서, 순간 순간 상황에 대한 놀라운 대처하는 방법을 알려주고 옆에서 인정해주고, 방향을 제시해 줄 수 있어야 한다.

하지만, 새로운 경험이 꼭 긍정적이지 않을 수도 있다. 그 때는 그들에겐 계속적인 재확신과 칭찬이 필요하다. 아끼지 말고 너는 할 수 있다, 아직 능력을 다 발휘한게 아니다. 익숙치 않아서 그렇다 하며, 확신을 주며, 이정도까지 한 게 정말 많이 오고 있다며, 관리자가 원하는 기대치만큼 오지 않더라도 격려하는 것이 중요하다.

좌절하는 팀원들에겐 더 많은 격려가 필요하다. 그러나 팀원들이 실망할 때 우리까지 덩달아 실망하는 때가 종종 있다.
그것을 잘 조절할 수 있어야 사람 키우는 조직문화를 잘 다스릴 수 있다.

결국은 사람을 키우는데 중요한 것은 바로 문제 해결 능력과 비교 될 수 있다.
문제의 마인드를 바꿀 수 있도록 해야 한다. 이 세상의 모든 조직, 관리자, 개발자들은 완벽할 수 없다. 항상 부족하고 단지 노력할 뿐이다. 문제를 어느 책에 있는 말로 바꾸어 본다.

problem 이란

predioctors 이들은 우리의 미래형성을 돕는다.
remiders 우리는 자족하지 않는다. 우리에게는 하나님과 우리를 도와줄 사람들이 필요하다.
opportunities 이것들은 우리들 틀에 박힌 모습에서 꺼내어 창의적으로 생각하게 해준다.
Blessing 이것은 우리가 대체로 통과하지 않은 문들을 열어준다.
lessons 각각의 새로운 도전이 우리의 선생이 될 것이다.
everywhere 어느 장소 어떤 사람도 여기에서 예외가 되지 않는다.
message 이것은 우리에게 잠재적인 재난에 대해 경고한다.
solvable 해결책이 없는 문제는 없다.

이렇게 문제에 대한 생각을 통해서 생산성을 높일 수 있도록, 격려를 하여 조직에 오랫동안 몸담고 그 방향을 제시해 주어야 한다. 그리고, 좋은 습관을 가질 수 있도록 격려해야 한다. 실제 조직생활 3년안에 그의 사회관, 조직관이 결정된다. 관리자는 계속적으로 팀원들에게 강조해야 한다.

'나쁜 결과 -> 부정적인 생각 -> 부정적인 생각' 이 아니라, '나쁜 결과 -> 긍정적인 생각 -> 긍정적인 생각'이 가능하도록 방향성을 제시해야 한다.

정도를 걸어라.
나에게는 가장 어려운 일인 듯 싶다. 이 현실세상은 잔머리와 술수의 세계라고 생각해오는 세계관을 가지고 있기 때문에 정도를 걸어라 하는 말에는 이상주의자들의 말이겠거니 하는 생각을 자주 하게 된다.

스티브 맥코넬(Steve McConnell)이 나에게 정직을 가르켜 주었다.
"가치와 옳은 일을 하는데 집중하면 돈을 벌 수 있습니다. 하지만 돈을 버는데 집중하는 오히려 부를 얻을 수 없을 것입니다."

바르게 일하는 것은 무엇을 의마하는 것일까? 의도적인 수련과 함께 요즘 나의 머리를 짓누리는 이 느낌은 말로 설명하기 어려울 정도로 버겹다. 정직하게 코딩한다..

스티브 코넬은 이렇게 말했다. 전형적인 실수를 피하고, 개발 기본에 충실하고, 위험을 사전, 사후관리를 통해 피하며, 일정위주로 개발을 하는 등, 4가지의 전략을 가지고 함께 진행해야 빠르고 좋은 결과를 얻을 수 있다고 한다.

그리고, 그 사람 생각에다가 문득 떠오르는 내 생각을 2가지를 추가하고 싶다.

1. 구현방법이 모를 때는 붙잡고 아는대로 얘기해본다. 해결책이 문득 떠오를지 모른다.
2. 땜빵과 완전 뒤엎고 시작하는 것을 잘 파악한다. 남의 꺼를 쓸때는 특히나.

내 일을 잘해야 겠다..

내가 반복되는 실수
1. 빨리 인터페이스에 익숙하지 못해서, 혼자서 끙끙앓다가 문제를 엉뚱하게 푼다는 것
2. 모를 때는 바로 바로 물어보는 것보다, 좀 더 노력해보고, 도저히 못 풀 때 물어본다는 점
3. 내가 닥친 문제에 대해서 올바르게, 이해하기 쉽게 설명을 못한다는 점
4. 게으르다는 점
5. 한번 실수에 대해서는 또 같은 실수를 하는 것
6. 메소드, 프로퍼티의 이름을 잘 짓지 못하는 것

=> 해결 방법
1. 실수에 대해서 네이버 블로그를 이용하여 팁형태로 제공하여 나의 문제를 해결.
2. 모를 때는 그 자리에서 물어봄.
3. 엉뚱하게 풀 것 같으면, 선임자에게 이렇게 구현을 하려고 한다하며, 해결 방법을 같이 모색
4. 자주 코드를 들여다보는 습관을 가짐.

급한 데모를 위해서 간단하게 만든 코드들이 있었다.
지저분하고 도저히 알아먹기 힘든 코드들이기 때문에, 다시 짜는 게 좋을 정도로 지저분했고, 실제 데모 당일날 제대로 동작을 하지 못했다.
어느 정도 시간이 지난 이후에, 사후처리를 확실히 안하고 넘어가다가, 다시 똑같은 데모가 와서, 그 데모를 위해서 하루를 버려야 했다.

즉, 한번 끝난 데모에서 적절하지 마무리를 못했을 경우는 반드시 그 작업을 끝내야 한다. 그래야, 다시 똑같은 데모가 왔을때, 손 털고 구경을 할 수 있다. 마무리를 철저히 하도록 선임자에게 설득을 해야 한다. 코드에 대한 감이 생생히 남아 있을때에...

문서(매뉴얼), 주석없는 코드는 아무런 쓸데 없는 코드이다.
이 두가지가 없으면, 결국은 다시 때려 부수는 일을 하게 마련인 것이다.
혼자서 하게 되면, 이런 것이 필요없으나, 여러 사람들이 공동으로 할 때에는 주석말고, 반드시 문서로 쉽게 매뉴얼로 작성해야 한다. 이는 Macro적 시야는 문서에서, Micro적 시야에서는 주석에서 알 수 있기 때문이다.

적절한 프로세스를 기반으로 가이드라인을 제시하고, 상식적인 혹은 확인할 수 있는 범위내에서, 구성원들이 따라야 할 규칙과 표준을 지키도록 해야 한다.
특히, 코딩 컨벤션, 백업 같은 경우는 반드시 지켜야 한다. 중요한 철학등은 문서화하여 반드시 공유할 수 있도록 해야 한다.