Approach
코딩이나 해석 업무를 진행하다보면 만나게 되는 에러 메시지들.
문법이나 순서, 빼먹은 data가 있다느니
준비과정이 부실해서 신뢰성이 저하될 수 있다느니
정말 이걸로 괜찮겠어?
라고 친절과 불친절의 줄타기를 하며 항상 되묻고는 한다.
그냥 해줬으면 좋겠다가도 그렇게 하는 것이 결과적으로 좋지 않을 것으로 알기에 다시 검토를 하고는 한다.
그런 업무들의 전제는 얼마나 잘 다룰수 있느냐 에서 시작한다.
그 프로그램이 기획된 방향대로 그리고 시간을 쏟을수록 결과를 믿음직하게 내놓고는 한다.
하지만 그런 프로그램들은 어디까지나 '도구'이다. 엔지니어링에 있어서 근본적인 접근방법은 기술자의 지식을 토대로 확인하고 계산하는 것이 최초 엔지니어링의 시작일 것이다.
하지만, 이제는 보여지는 것이 중요한 시대이다. 수치적으로 이미지적으로 결과물이 나타나고 이것을 바탕으로 실제 제품 프로세스가 기획된다.
그리고 이를 위해서는 어느 대단하신 분들이 직접 만들어 놓으신 그 프로그램의 사용방법을 자세히 숙지해야 한다.
결과적으로 앞서 달려가신 대단하신 분들의 탁월함을 다시금 깨닫고 에러 디버깅을 위해 정신을 차려본다. 내가 나의 입맛대로 만들 수 없다면 열심히 따라가야지
쓰고 읽어보니 나야말로 이 업무의 당위성에 대해 줄다리기를 하며 고뇌한 흔적이 명백히 나타난다. 그만 흔들려야겠다.
