결과를 고려해서 일을 하라는 의미이다.


며칠 전 도움을 요청이 있었다.

하나의 테이블에 저장된 데이터가 600G가 되어 한계 상황에 왔다고 한다.

데이터 정리를 해야 하는데 시간이 너무 많이 걸려서 빠른 방법을 문의했다.

방법은 없었다.

조금 더 빨리 할 수 있는 방법이 있기는 했지만 600G에서는 큰 도움이 되지 않는다.

아쉬워하는 그 친구에게 해줄 수 있는 말이 없었다.


출처: https://www.flickr.com

일을 할 때 가장 경계하는 것이 이런 경우다.

이런 일이 생기지 않게 개발하는 것을 최우선으로 한다.

즉, 문제를 해결하는 것 보다

문제가 생기지 않도록 하는 것이 가장 좋은 방법인 것이다.


대부분 프로그램이 돌아가면 된다고 생각한다.

시간과 인력 부족 등의 이유로 일단 돌아가는 프로그램에 집중한다.

기술 부채는 둘째치고

별 문제없이 돌아가면 넘어간다.

하지만 운전에 방어 운전이 있듯이

항상 뒷일(결과)를 고려해서 보다 나은 방법을 찾는 게 중요하다.

문제가 생겼을 때는 늦은 경우가 많다.

(병원에서 하는 말과 비슷한 것 같은데...)


뒷일을 고려한 개발을 하는 방법은

경험과 남의 코드를 많이 보는 것 외에는 없는 것 같다.

또는 코드에 대한 토론이 도움이 되는 것 같다.

다른 사람이 도움을 주기도 하고, 이야기 하다 스스로 발견하기도 했다.


남이 하는 걸 무조건 따라하는 것을 경고하는 속담이다.


저녁 운동을 마치고 집에 오는 중에

자신의 미래를 준비중인 한 대학생이 보내온 카톡을 받았다.

누가 알려준 괜찮은 스타트업이 있어서 지원하려고 한다,

국비 지원 학원이 좋다는 이야기를 들었다 등의 이야기를 꺼냈다.

4학년이라 주변의 친구들이 각자의 미래를 준비하기 시작하고

서로에 대해서 이야기 하는 와중에 이런 저런 생각에 연락을 한 것이다.


이런 저런 이야기를 하던 중에

[ 이것저것 벌려놓고 한가지도 제대로 소화를 못하는 것 같습니다.

생각을 해보니 제가 실력에 자신이 있었으면 하는 생각으로 돌아오게되고...

근데 또 이런 생각하다가 정작 중요한 코딩을 안하게 되네요.]

라고 말했다.

답을 알고 있으면서도 불안해서 연락한 것 같았다.


이미 학교 교수님 연구실에서 활동하고,

멋진 사자처럼이라는 모임에,

수요일 개발자 모임까지 참석하는 등,

나름데로 미래를 위한 준비를 하고 있었다.

이 친구가 자신의 주변 친구들보다 더 열심이 준비하고 있는 것 같은데,

주변 친구들 이야기에 불안해 진 것 같았다.


오래된 친구 생각이 났다.

같은 동네에 살아서

오고 가다 만나면 서로 어떻게 지내는지 물어봤다.

취업 준비중인데, C 언어 공부 중이라고 했다.

몇 달 뒤 길가다 만나면 비주얼 베이직이 유행이라서, 공부중이라고 했다.

그렇게 오랫동안(한 5년??) 여러가지를 공부하고 고민만 했었다.


이후로도 그 친구와 같은 친구들을 자주 봤다.

이런 고민 속에 자신을 찾아가는 친구도 있고

고민만 하다 다른 길을 가는 친구도 있었다.

그들의 공통점은

고민이 커져서 불안해 지면

계속 주변 사람의 말과 행동을 따라하려는 경향을 보이는 것 같다.


어떻게 하는 것이 좋을지는 모르겠지만

남이 한다고 따라해서 좋은 결과를 얻은 적은 없었던 것 같다.

남의 떡이 더 커 보인다고

내가 고민할 때 다른 사람의 자신 있는 모습이 부럽고 멋지게 보일 수 있는데

그걸 무작정 따라 하는 것은 더 큰 고민을 만드는 것 같다.


서로의 속사정을 알았다면,

나에게 연락했던 친구의 친구들이

그 친구를 더 부러워 했을 것 같다.


"경험이 적고 세상 물정 모르는 어린 사람이 철없이 함부로 덤비는 것을 비유적으로 이르는 말" 다음사전


이 말은 실력이 없는 사람이

어려운 일인 줄도 모르고 해결하려고 달려든다는 의미도 되고,

실력 좋은 사람 앞에서 잘난 체 한다는 의미 등이 있다.


개발자의 입장에서는 엔지니어의 함정이라는 말과 의미가 같을 것 같은데

상황 파악도 못하고

조금만 더하면 할 수 있을 것 같다는 생각에 안 되는 일을 계속 붙잡고 있는 경우(사람)을 의미할 것이다.

열심이 노력해서 문제를 해결할 수도 있겠지만

이미 소요된 많은 시간은 전체 프로젝트 일정을 망칠 수도 있다.

또, 겨우 겨우 제작한 코드는 이후에 문제가 생길 경우(보통 생기지만)

또 많은 시간을 소비하게 한다.

이것을 전투에서 이기고 전쟁에서 졌다고 한다.


아는 만큼 보인다고

내가 할 수 있는 것인지? 아닌지?

빨리 판단해서

나아갈지? 물러날지? 도움을 요청할지? 등의

판단을 잘 하는 사람이 실력있는 개발자라고 생각한다.


한 직원이 충고를 무시하고 며칠째 개발한다고 일하는 모습을 보며


ps) 개발에 성공할 경우

장기적인 관점에서

개발자 개인의 실력향상에는 아주 큰 도움이 될 수 있다.




의견 수렴 없이 자기 주장만 하다가 진척이나 결과가 없다는 것을 의미하여 부정적으로 보지만

브레인스토밍에서는 긍정적으로 본다 (나무위키).


예전에 한 신입 개발자가 있었다.

한 선배 개발자가 작업하는 신입 개발자를 보고 이렇게 하는 게 좋겠다고 조언했다.

신입 개발자는 수정했다.

잠시 뒤 다른 선배 개발자가 오더니 그것보다는 이렇게 하라고 했다.

신입 개발자는 수정했다.

그렇게 몇 명의 선배가 수정하라고 했다가 코드가 개판이 되었다.

전형적인 사공이 많으면 배가 산으로 가는 사례로

개발 중에 흔히 생기는 일이다.


출처:https://pixabay.com

긍정적인 면을 보면

사실 신입 개발자 입장에서는 이것이 많은 도움이 될 수 있었다.

최소한 신입 개발자는 다양한 문제 해결 방법을 알수 있는 기회가 될 수 있었다.

개발에는 하나의 정답만 있는 것이 아니기 때문이다.

또, 만약 그들이 모여서 토론했다면 더 좋은 결과가 있었을 것이다.

(실력 있다고 자부하는 사람들 끼리는 서로의 코드에 대해서 말하지 않는 불문율 같은 것이 있는 것 같다.)


이것이 Open Source의 장점 중 하나라고 생각한다.

(Open Source는 자유로운 사용이 더 중요한 핵심이다.)

여러 사람이 하나의 기능이나 제품을 각자의 방식으로 테스트하고 수정하면서 만들어 가는 것이고,

이 과정 속에 개인이 발전하기 때문이다.


출처: https://pixabay.com

다만 많은 Open Source가 초기에 불안정한 과정을 거쳤던 것처럼

초기에 많은 시간과 노력이 필요할 수 있다.


질문과 토론이 없는 우리의 현실에 있어서

사공이 많아서 배가 산으로 갈 수 있다면 아주 창의적인 것 같다.


불치하문(不恥下問)이라고 하며

아랫 사람에게 조차 물어서 배운다는 말이다 (다음 사전).


개발자에게 가장 중요한 명언이라고 생각한다.

항상 새로운 기술이 나오고, 

급변하는 IT 세상에서

배우지 않고, 묻지 않고 개발할 방법은 없는 것 같다.


내가 모든 것을 알수 없고,

내가 모르는 것을 다른 사람이 알 수 있으니

물어보지 않고 혼자 해결하려다 시간만 보낼 수도 있다.


반대로 너무 물어봐도 민폐가 되고,

쉽게 얻은 지식은 쉽게 사라진다고 한다.


따라서,

물어볼 것과 찾아볼 것을 잘 구분해야 할 것이고,

끊임없이 배우려는 자세가 중요한 것 같다.

전쟁은 싸워서 이기는 것이 아니라, 이긴 것을 확인하는 것이다.


이말은 손자 병법에 나온 말로 싸우지 않고 이기는 방법 중에 하나로 알려져 있다.

이순신 장군도 이 전략을 충실하게 실행한 것으로 알고 있다.

내가 강하면 굳이 싸우지 않아도 이길 수 있다는 것이고

상대가 인정하지 않으면 확인 차원에서 전쟁을 한다는 것이다.


이 전략이 성립 되려면 나와 상대에 대해서 잘 알아야 한다.

이것은 평소에 준비를 잘 해두라는 의미로,

평소에 준비가 잘 되어 있으면 쉽게 문제를 해결 할 수 있다는 것이다.

학생을 예로 들면, 평소에 공부(예/복습)를 잘 해두면 편하게 시험보고 1등(?) 할 수 있다는 의미가 될 것이다.


이것을 개발자의 입장에서 큰 개념으로 해석하면

[잘 준비되어 있으면 프로젝트를 쉽게 해결할 수 있다]라고 생각할 수 있을 것이다.

진상 고객/상사, 외부 환경 변화와 같은 외생 변수는 제외하고

진행할 프로젝트에 필요한 기술과 문제점을 잘 파악하고 준비해두면

쉽게 프로젝트를 진행 할 수 있다.

특히, 필요한 기술(라이브러리)이나 기술적인 어려움이 예상되는 부분을 찾아서 미리 준비해두는 것이 필요하다.


작게는 하나의 기능을 구현할 때,

일이 주어지면 코딩(싸움)부터 먼저 하려고 하는 개발자를 많이 봤다.

코딩부터 먼저 할 것이 아니고

화면설계서, ERD, 프로세스 명세서 등 필요 문서들을 챙기거나 간단하게 라도 작성하고,

내가 아는 것과 모르는 것을 구분해야 한다.

모르는 것은 준비하거나 도움을 요청하면 쉽게 개발할 수 있다.

만약 해결할 수 없다면 싸우지 않는 것이 칠천량 해전(임진왜란)처럼 패전하지 않는 길일 것이다.

(부작용은 싸우지 않겠다고 해서 어딘가로 가신 분이 ~~~)


이렇게 나를 알고 적을 안 뒤에 일하는 것이 당연이 쉽다 (지피지기).

그리고, 평소에 다양한 라이브러리에 대해서 알고 있으면 더 좋을 것이다 (부국강병).

예로, 웹 개발에서 자바 스크립트의 역할이 제법 많은데,

검색해 보면 무료 오픈 소스 라이브러리들이 많이 있다.

동일한 기능이라도 다양한 방법으로 구현되어 있기 때문에

미리 알아두면 좋은 게 너무 많다.


정리하면,

“전쟁은 싸워서 이기는 것이 아니라, 이긴 것을 확인하는 것이다.”는

싸워서 이기기 위해서 노력하지 말고, 이긴 것을 확인하기 위해서 싸운다로 해석하고

개발자 언어로 번역하면

코딩을 하기 위해서 노력하지 말고, 내가 알고 있는 것을 확인하기 위해서 코딩 하는 것이 좋다가 될 것 같다.



+ Recent posts