IT 기술은 그 역사의 흐름과 기술 발전의 흐름에 맞추어 오래전의 기술도 배워야 하고 이후에 바뀐 기술도 배워야 합니다. 이는 기술 이해가 체계적이라 기존의 기술도 알아두면 이후의 기술에 대한 이해가 깊어지기 때문이구요. 기술을 실재 상황에 적용할때 기지를 더 발현하기가 좋게 되서네요.
흔히들 일상언어로 말할때 “다 안다고 자만하지 말고 겸손하게 임해”라는 말도 흡사한 전제인데요. 기초를 배웠을때 다 안다고 생각하는 경우도 있게 되고, 자만하지 않더라도, 기초를 기술하는 개념 몇개만 알고 멈출때보다 더 많이 알려고 하는 의지를 가지게 해주는 말일 것입니다.
물론 해킹이나 과학기술 계통에서 있는 고수가 하수를 대하는 특수한 방법들(흔히 맨스플레인이라고 하는 방법들)을 상기시키는 말이기도 한데, 원칙은 위에서 언급한 공부 태도를 길러주는 방법입니다. 위의 말이 이렇게도 쓰이는 것은 IT도 사람이 하는 분야라, 한 표현에 결부되어 부착된 문화라서이고, 이 이해도 기존의 기술과 이후의 기술을 잘 알아두는 태도에 의해 더 잘 이해가 될 수 있습니다.
이 체현을 위해 생각해볼만한 한가지 정보가 되는 IT 기술 공부법의 노하우를 어떻게 채택하면 좋을지 말해보겠습니다.
어떤 경우, IT도 과학이기에 체계적이기도 하고 논리적인 판단이 일정 부분 적용되는 분야가 IT라, 스키마를 잘 짜두면 판단의 체계에 의해 잘하는 인식으로 안착하기도 합니다. 연역이 가능한 부분이구요. 귀납적인 것을 추가한다면, 실시간으로 작동흐름을 살펴서 판단하는 방법도 있습니다. 그런데 이 경우에 연역이 가능한 부분과 귀납이 가능한 부분을 잘 구별해야 합니다. IT가 수학적이라 연역이 되더라도, 사용이나 경험에 의해 부가되는 분야라, 사용자의 동기나 맥락 등의 영향을 받아 같은 알고리즘도 다른 방식으로 인식될때가 있어서네요.
예를 들면 사이트 지표 측정 도구에서 실재로는 연결이 안느린데, 사이트 속도 지표 점수가 확 낮게 나오는 경우가 있습니다. 이 경우 여러 추측이 가능하지만, 제작 의도에 따라서는 지금 당장은 안느리더라도 사용자가 많아질 것을 예측해서 점검해보게 하려는 일괄적인 권고이기도 하구요. 지켜두면 좋아서 권고하는 경우가 많습니다. 하지만, 실재로는 안느린 조건에서 보면 SEO 적용에 부담이 가기도 해서 스트레스 유발 요인이 되기도 합니다. 다시 말해 제작 의도와 사용 경험이 서로 어긋나는 경우도 상당히 많다는 것이죠. 이는 원칙 하나만 알아서는 안되는 경우입니다. 때로는 제작 의도가 더 말이 되는 경우도 있으나, 둘다 맞는 경우도 있죠. 이는 연역과 귀납의 조화로운 운용이 필요한 경우입니다.
연역은 보통 논리라고 인식됩니다. 전제가 옳으면 결론이 틀릴 수가 없습니다. 이는 프로그래밍 방법론에서 특히 잘 통용되죠. 그런데 귀납적이어야 할때도 있습니다. 하나의 지식만 알고 여러 소프트웨어를 작동시키다보면 체계적이고 논리적이라고 생각했던 판단이 적용이 안될때가 있습니다. 이 경우는 IT 기술은 경험에도 의존하고 있는 체제이고, 고도화된 기술들이라 제작자가 만든대로 작동하기에 단일한 작동방법으로는 작동이 안될때가 상당히 많죠. 다시 말해 작동방법의 경우의 수를 다 알면 좋구요. 소프트웨어마다 다르다는 것을 전제해두어야 당황스러움을 줄일 수 있습니다. 여기서 작동방법의 경우의 수를 다 알아두는 것은 위에 말한 “다 안다고 자만하지 말고 겸손하게 임하는 것”에 의해 가능해집니다.
단순하지만 초심자 시절에는 혼동되는 것은 어떤 경우는 마우스 한번클릭으로 작동하고 다른 경우는 두번클릭으로 작동할때가 있고, 휠을 돌리면 스크롤되는 깊이를 조정한다든지, 맥에서는 휠을 올리면 스크롤이 내려가는 등등의 구별점도 관련 현상이구요. 대부분의 경우 이를 미리 안말해줘도 고려하는 능력들이 다 있는데, 특수한 경우 단일한 경우만 상정하는 경우도 있어서 당황하기도 하네요. 경험이 중요하구요. 어떤 경우 타과학하신 분들 중에서는 과학의 일양성에 대한 인식을 IT에다가도 적용하시고 어려운 것부터 보시기도 하는데, 활용법은 쉽게 알 수 있어도 기술적인 것이나 원리는 기초부터 배워야 합니다. (부끄러우시면 집에서 몰래 보면 됩니다 (?)) 고도화되어 기술들이 겹쳐지고 발전하면 이해도 꽤 어려워지구요. 논리나 체계도 중요한데, 문제 해결에 있어서는 경험이 중요하죠.
UEFI 펌웨어의 경우에도 BIOS 시절의 지식을 알면 시스템 고장의 원인을 알게 되는 진입로가 되는데요. 이 경우에도 기존의 지식과 새로운 지식을 융합해서 이해하려는게 중요합니다. 시스템 리저브드 파티션이나 NVRAM 등에 대한 인식이 가능했다면 잘하는 것입니다. 이에 대해서는 직접 살펴보세요. 이 기술들은 PC 고장과도 관련이 있어서 하나만 알아도 아주 기분이 확 살아나는 지식인데, 이 경우에도 정말 많은 것이 더 배움을 기다리고 있는 경우입니다.
그래서 초심자 시절에는 개념을 확실하게 잡기 위해 이미 정해진 표준 언어로 사태를 기술한 표현으로 배우되, 표현의 의미보다는 표현의 연관을 살피는게 요령입니다. 프로그래밍을 할때 IDE가 표시한 오류에 의미만을 생각하면 문제가 있는 라인으로 가봐도 문법적인 오류가 없는 경우가 있구요. 이 경우에는 오류 메시지의 표현의 의미보다는 표현이 지시하는 연합된 원리를 떠올려보려고 노력하면 좋습니다. 이것을 초심자 시절에는 어렵다고 하는 것은 실력이나 자격 문제라기보다 경험이 없어서인데, 요즘은 비전공자분들에게도 친절하게 원리를 알려주는 문헌과 인터넷 자료가 많으니 보시길요.
한 현상에 대해 잘 알려진 규칙만이 정답이 아님을 아는 것도 좋습니다. 보통 이상 현상은 잘 알려진 규칙을 비틀고 얽히게 해서 일어나니까요.
인터넷이 안된다고 하면 보통 네트워크 장치 리셋이나 라우터를 보라고 하는데 이 경우에도 경험이 많아지면 그이상도 보게 될 수 있습니다. 라우터 펌웨어가 변조되었다든지, 운영체제의 ARP 문제라든지, 네트워크 구동 소프트웨어에 유저권한이 바뀌었다든지, 파일이 리패키징된 등등의 가능성을 알려고 하는 진입점도 이 글에서 말하는 태도를 잘 알면 가능하구요. 전공이 아닌 분야더라도 문제 원인만큼은 잘 알게 되어 질문이나 수리 요청도 아주 잘하는 실력 향상으로 이어질 수 있습니다.
잘 해설받은 루트가 중요합니다. 요즘은 큰 업체에서는 자기들 사이트에 문서들을 공유하는데 이를 참고하시구요. IT적인 글은 개념을 떠올려야 하는 부분과, 써본 경험에 의해 사용과정을 떠올려보는 부분을 잘 구별할줄 알면 잘하시는 것입니다.
보통 신계급 또는 위자드리라는 칭찬도 받는 분들이 계시는데 그분들도 이글에서 말한 연역과 귀납을 잘 운용해서일 것입니다. 일단 이렇게 해설해둡니다.
