歸天

software 제작을 완료후 어느날 갑자기,
내일까지  수정사항을 적용해서 마무리 해야 한다는 소식을 전해 듣는다.
아뿔싸; 수정 사항은 생각보다 만만치 않아 보인다.
양도 많고... 내일까지 하려면 시간이 모자랄 것 같다.

밥먹는 것도 잊고...
코드의 품질도 잊고...
일단 완성하고 보는거다!

그리고 어떻게든 완성을 해서 다음날 보내준다.
그런데..? 알고보니 오늘이 데드라인이 아닌가벼? 또다른 수정 사항이 온다.
ㅆㅂ... 완성 하려고 코드는 떡이 됐는데, 여기서 또 수정하려니까 ..... 욕밖에 안나온다.

아씨 이럴꺼면 좀더 유연하게 짜둘껄.... 뒤늦은 후회...
그래서 다시 마음을 다잡고 제네럴 하게 설계하고 짜기 시작한다.
일이 훨씬 수월하다... 훨신 유연해서 이제는 웬간한 수정사항도 받아 드릴 수 있을정도.

그리고 일이 끝난다. 후우.................




뭐 이런 스토리를 여러번 겪는다. 이전에 인턴 할때도 당장에 보여줘야할 Demo 를 위해
코드를 겁나 때우고 또 때워서 보여주고 -_ -. 근데 그 Demo 가 무지 잦아서 고생을 했던 기억이 있다.
Demo 할때마다 내 코드의 자존심은 구겨지고, 기분도 떨떠름한게... 욕구가 완전 사라졌었는데..

Agile 방법론으로 고객의 수정사항, 요구사항을 유연하게 잘 받아 드리면 좋은것은 당연한데,
좌우간 코드의 품질은 좋게 하고 볼 일이다.

그런데 중요한건 이런 코드 품질이 엔지니어의 실력은 둘째치더라도 프로젝트의 운영에도
많은 영향을 받는다는 것 이다.

그 운영이란게 참 추상적인데,
프로젝트의 일정 관리,
팀원들간의 커뮤니케이션,
팀원들의 컨디션 관리,
등등등이 포함되지 않을까 싶다.

게다가 엔지니어의 입장도 고려해야 하고, 클라이언트의 입장과 요구사항도 잘 맞춰야 하니까..
이게 여간 쉬운게 아닌 것 같다.

학교에서 배우는 “소프트웨어 공학” 에서 이런 것들에 대해 가르치는데,
이런 지식은 엔지니어링 자체에 대한 지식이기 보다는, 엔지니어링에 대한 엔지니어링
즉, 메타적인 지식이라고 할 수 있다.

나는 그냥 실력만 있으면 뭔들 못하니...(전형적인 엔지니어들의 생각?) 라고 생각했는데
“아 ... 실력이 다가 아니구나... “
라는걸 특히 최근에 많이 깨닫고 있는 중이다.

이런 경험들을 절대 잊지않고, 나중에 혹시 프로젝트를 운영할 일이 생기면 참고해야겠구나!!

아주 가끔 누군가 내 마음에 앉아 있다가 가는데

이번에도 마음에만 있다가 가시려나.


조금 더 기다리겠습니다.

마음가는 대로 살고 싶었다.
그래서
마음 가는 대로 하려고 노력했다.
다 내멋대로 살꺼라고 했다.
이거 내꺼니까.


그런데 살다보니
귀찮은 것들이 나를 귀찮게 했다.
이런 저런 귀찮은 것들.


그런데 그런 귀찮은 것 들을
내멋대로 그냥 그렇게 냅뒀더니
죄책감이 들더라.


아니 내가 왜?


조금더 마음가는대로 사는거다.