라떼군 이야기

 최근 꿀단지(Honeypots) 이론이 주목을 받은 적이 있었으며 이를 이용한 침입자 유인방법 및 관련 기능을 포함한 솔루션들이 출시되고 있는 추세이다. 이에 따라 간단히 Honeypots에 대해 알아보고 사내 보안 솔루션 구축에 대한 대안을 제시 하고자 한다. (아래 글 부터는 Honeypots 대신 꿀단지로 번역해 사용할 것이다.)

꿀단지를 이용해 실제 서비스하는 호스트인 것처럼 속이거나 공격자나 침입자를 유인할 수 있다. 하지만, 이 방법으로 구성하려면 침입자가 꿀단지 호스트를 통해 실제 서비스에 영향을 줄 수 있지 않도록 네트워크 구성을 분리해야 하고 안전한 망 구축을 위해 스위치 및 방화벽 장비의 추가 투입이 불가피한 것으로 보인다. 인적 자원 및 물적 자원의 투자가 불가피함에 따라 구성에 상당한 규모의 서비스 및 기업에서만 가능한 방법이라고 생각한다.

가상 기계(Virtual Machines) 또는 가상 꿀단지(Virtual Honeypots)의 방법도 물리적인 네트워크를 구성해야 하는 부담은 적지만 침입자를 온전히 속이려면 가상화를 지원하는 VMware, MS의 Virtual PC, Sun의 Virtual Box같은 소프트웨어(windows 2008의 가상화 기능도 마찬가지이다.)를 사용해야 하므로 해당 호스트의 성능에 따라 가용성의 차이가 커지므로 제대로 된 침입자 유인 서비스를 구성하려면 고 가용성의 호스트 장비가 필요하게 질 것이다.

이와 같은 이유 때문에 중소기업에서 꿀단지 기법을 이용해 다수 또는 가상의 침입자를 유인하는 시스템을 구성하여 침입자를 유인하고 지속적으로 살핀다는 것은 실제적인 여건상 힘들 수 있다. 실제 서비스에 대해 침입자를 유인하여 분석하는 대신 실제 서비스 네트워크와 분리된 내부 네트워크에서 일어나는 정보유출에 오히려 더 신경 쓰는 것이 더 효율적이다. 이런 기업들은 작은 정보 유출에도 회사 존립에 문제가 될 수 있기 때문에 내부자료 보안에 더 신경 쓰는 것이 현명할 것이다.

Honeynet 은 공격자가 시스템에 침입하기 위해 사용하는 방법으로 침입 도구에 대해 연구하기 위해사용 되고 있다. 이는 일부러 공격당하도록 구성된 시스템들로 이루어진 네트워크를 말하는데 방화벽 시스템(Firewall)이나 모든 incoming/outgoing 연결을 로깅하기 위한 NAT 서비스를 제공할 수도 있고 침입탐지 시스템(IDS)을 이용해 때로는 방화벽이 설치된 시스템에 함께 설치하기도 한다. 모든 네트워크 트래픽을 로깅하며, 알려진 공격을 감시할 수도 있다.

기존의 Honeynet은 꿀단지를 이용해 침입자를 유인하는 쪽에 치중해 있다고 한다면 거꾸로 꿀단지를 이용해 사내 또는 비밀이나 보안이 필요한 네트워크에 비밀자료 유출방지 및 사용패턴의 시스템 분석을 위한 꿀단지의 운영할 것을 제안하고 싶다.

기존 구성된 내부 네트워크에 설치된 웹 서비스나 SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol)나 방화벽 등을 꿀단지 기법으로 구현해 내부 직원에게는 비밀 하에 설치하며 실제 서비스처럼 운영해 볼 수 있을 것이다. 꿀단지의 로그 데이터 분석을 통해 사내 네트워크에 취약점 및 자료 유출 실태를 분석할 수 있을 뿐만 아니라 나아가서는 취약점 보완에 기여할 수 있을 것이다.@

참고자료
http://technet.microsoft.com/ko-kr/library/cc700732.aspx
http://www.honeynet.org/

'I want to put a dent in the universe.'

 

 위에 '나는 우주에 영향을 미치고 싶다.'라는 말은 스티브 잡스(Steven Jobs)가 최초의 GUI 환경 개인용 컴퓨터인 '리사(Lisa)'프로젝트에 돌입하면서 개발팀에게 한 말이다. 정말이지 스티브 잡스의 업적은 우주에서도 알고 있지 않을까? 하는 생각이 들 정도로 놀랍고 위대하다. 그는 때로는 돌출적인 행동을 하기도 하였지만 일할 때에는 원리원칙주의자이고 때로는 가벼운 티셔츠와 청바지를 입고 프레젠테이션을 할 만큼 개성적이며 권위주의 타파에 힘쓰기도 하였다.

스티브 잡스는 너무나 잘 알려진 대로 굴곡 많고 화려한 인생을 살고 있다. 그는 애플컴퓨터(Apple)의 설립자이지만 그가 추진한 리사(Lisa)프로젝트의 실패 이후 해고당하게 된다. 그 후 넥스트(Next)사를 설립하였고 비록 성공하지는 못했지만, 세계 최초의 객체지향 운영체제를 만들었다는 업적을 세웠다. 그는 또 한 번의 실패에 포기하지 않고 픽사(Pixar)를 설립하였고 그 유명한 최초의 장편 3D 애니메이션인 '토이 스토리(Toy Story)'를 탄생시켜 영화계에 일대 충격을 가한다. 결국에 그는 성공한 것이다. 이런 그의 성공은 여기에서 멈추지 않는다. 그는 결국에 해고당한 지 12년 만에 애플 CEO로 다시 복귀하게 되었고 혁신적인 상품인 아이맥(iMac)을 개발해 현재 애플을 적자에서 흑자로 바꾸어 놓았다. 아직도 그는 iPod 과 iTunes를 통해 아직도 애플을 꾸준히 성장시키고 있다.

스티브 잡스가 성공한 이유는 그가 자신의 처한 상황을 받아들이고 그것을 이겨내려고 노력한 것에서부터 시작한다. 실제로 그의 명연설 중 하나로 꼽히는 스탠퍼드 대학(Stanford University) 졸업식 연설에서 '당시에는 몰랐지만, 애플에서 해고당한 것은 제 인생 최고의 사건임을 깨닫게 됐습니다.'라고 회상하고 있다. 그뿐만 아니라 그는 '그 시기가 자유를 만끽하며 내 인생의 최고의 창의력을 발휘할 수 있는 시기였다.'라고 덧붙여 말함으로써 오히려 그런 상황을 잘 이겨냈을 뿐 아니라 그것을 넘어 그런 상황을 즐겼음을 알 수 있게 해준다.

대부분 사람이 실패나 어려움이 닥쳤을 때 쉽게 포기하는 이유는 그런 어려움 속에서 자신이 얼마나 더 강해질 수 있는지 알지 못하기 때문이다. 어떤 일이든지 아무 어려움 없이 얻어지는 것은 없다. 처음으로 자전거 탔을 때를 생각해보라. 당신은 균형을 잡지 못해 뒤에서 잡아주지 않는다면 도저히 자전거를 타지 못할 것 같다고 생각했을 것이고 어떤 사람들은 그런 시기에 아예 자전거 타는 것을 포기하기도 하였을지도 모른다. 하지만, 결국 이겨낸 사람들은 이내 머지않아 능숙하게 탈 수 있을 뿐 아니라 만약 누군가 또다시 뒤에서 잡아주려고 한다면 귀찮고 거치적거려서 오히려 타는데 방해만 될 뿐이라고 생각할 것이다. 결국, 어려움을 이겨낼 때 처음에는 불가능해 보였던 그것을 해내는 강해진 자신을 확인하게 되는 것이다.

기업도 마찬가지라고 생각한다. 맥킨지(mckinsey) 컨설팅의 조사를 따르면 기업평균수명은 점차 감소해 현재 15년 정도까지 줄어들었다고 한다. 하지만, 그와 상반되게 신기하게도 기업이 30년 이상 지속한다면 경영성과는 월등하게 좋아진다는 결과도 있다. 즉, 기업이 지속한 이후 20년 정도에 가장 낮은 경영성과를 이루다가 30년 이후에 다시 성과가 좋아지는 '스마일 커브(Smile Curve)' 현상을 볼 수 있다고 한다. 기업도 사람과 마찬가지로 어려움을 이겨낼 때 더욱 뿌리가 단단한 기업으로 성장할 수 있는 것이다.

수년 전 지금 회사로 이직하기 이전 조그만 소프트웨어 회사에 다녔었다. 처음 몇 달간은 회사 상황이 나쁘지 않았으나 점차 경영 악화로 상황이 안 좋아지기 시작했고 나는 그런 모습을 가까이서 끝까지 지켜봐야만 했었다. 이윤 추구를 목적으로 하는 회사라는 조직이 원래 목적을 이루지 못했을 때 주위 사람들을 얼마나 힘들게 할 수 있다는 것을 확인하고 몸소 체험한 시기였다. 그 당시 상황이 나를 너무 힘들게 해 두 번 다시 겪고 싶지 않지만 나에게 약이 되었던 소중한 경험에 감사하고 있다.@

 2006년도에 개봉했던 영화 중에 클릭(Click)이라는 영화가 있었다. 아담 샌들러(Adam Sandler)가 주연으로 나오는 코미디 영화다. 나는 다른 남자들처럼 SF나 전쟁영화도 즐겨 보기는 하지만 특히 코미디 영화를 더 좋아하는 편이다. 그러나 그냥 단순히 웃기기만 하는 영화는 좋아하지 않는다. 나는 그 이면에 영화가 전하고자 하는 메시지가 있는 영화가 좋다. 클릭이란 영화는 바로 그런 영화이다.

주인공인 마이클 뉴먼(아담 샌들러)은 건축가이고 아내와 아이들과 같이 살아가고 있다. 그는 건축가이며 모두가 부러워할 만한 아름다운 아내와 아이들과 같이 살아가고 있음에도 항상 만족하지 못한다. 그는 더 나은 삶을 원하고 그것을 위해 건축가로 더 높은 성공을 원한다. 그러던 어느 날 우연히 특별한 리모컨을 갖게 된다. 인생을 빨리 돌릴 수 있는 그런 만능 리모컨이다. 하지만, 성공에 너무 집착한 그는 리모컨을 오용해 결국엔 가장 소중한 아내와 아이와 자신의 건강까지 모든 것을 잃어버리게 되고 그때가 돼서야 비로소 그것들의 진정 소중함을 깨 닳게 되는 내용이다.

대부분 사람은 자신에게 주어진 환경들에 대해 만족하지 못하고 살아간다. 좀 더 나은 직장을 원하고 좀 더 높은 봉급을 원하고 좀 더 넓고 비싼 집에서 살기를 원한다. 때로는 남이 가진 것을 부러워하기도 한다. 내가 타는 차보다 더 좋은 차를 타고 싶어하고 더 좋은 집에서 살기를 원하고 좀 더 나은 직업도 갖기를 원한다. 하지만, 이렇게 부러워하기 전에 자신이 얼마나 많은 것을 이미 가졌는지 돌아보는 것이 바람직하다. 이 모든 것이 영화에서 말하는 것처럼 자신에게 주어진 것에 대해 만족하지 못하는 마음에서부터 생겨난 것일 수도 있기 때문이다.

사실 인간의 능력은 제한적이다. 뭐든 잘해내는 만능 인간은 아마 이 세상에 없을 것이다. 그래서 이런 제한적인 능력으로 짧은 인생을 살아가려면 어느 정도 선택이 따르기 나름이다. 인생을 성공에 바칠 것인가 아니면 또 다른 중요한 무엇에 집중할 것인가는 지극히 선택적인 문제이다. 미국 문화와 성공한 CEO의 상징인 스티븐 잡스(Steven Paul Jobs)의 '주 90시간, 즐기면서 일하자!' 처럼 일에 집중한 사람은 그만큼 일에 대한 보상을 받을 것이지만 다른 한편으로 잃는 부분이 분명히 생길 수밖에 없다.

내가 고등학교 다닐 때에 시험기간만 되면 공부 잘하는 애들이 공통으로 하는 말이 있다. 어제 공부하려고 했는데 일찍 잠들어 버렸다느니 티브이를 보다가 공부를 하나도 못했다느니 하는 말이다. 그렇다면, 시험 성적은 분명히 나빠야 하지만 결과는 절대 그렇지 않다. 그들이 정말 공부 하나도 하지 않았는데 성적이 좋은 것일까? 처음에는 나도 그런 줄만 알았다. 하지만, 우연한 기회에 그것들이 거짓말인 것을 알게 되었다. 그들은 다른 아이들보다 평소에 많은 것을 포기하고 공부를 하고 있었다. 만약 시험 전날 일찍 잠들었다면 평소에 다른 사람들보다 훨씬 더 많은 노력을 해왔던 것이고 티브이를 보았다면 이미 공부를 끝낸 상태였을 것이다.

비록 드라마의 내용이긴 하지만 베토벤 바이러스에서도 이런 비슷한 내용을 볼 수 있다. 정명환이라는 강마에(건우) 친구가 등장하는데 그는 천재여서 모든 것을 큰 노력 없이 잘할 수 있는 것처럼 다른 사람들에게는 보이긴 하지만 사실은 그 뒤에 보이지 않는 곳에서 항상 강마에에게 지지 않으려고 부단히 노력했다는 것을 볼 수 있었다.

드라마의 내용을 조금 더 빌리자면 천재라고 불리던 모차르트(Mozart, Wolfgang Amadeus, 1756~1791)마저도 작곡하면서 놀았다고는 생각하지는 않을 것이다. 놀면서 작곡했다면 그런 곡이 나올 수 없기 때문이다. 그의 짧은 35년생에의 600여 곡을 작곡한 것을 생각해보면 경제적으로 어려웠던 환경과 순탄치 않았던 가정생활 그리고 짧은 생애가 얼마나 많은 것을 포기하고 작곡에 매달렸는지 감히 짐작해 보게 한다.

누구나 자신의 삶에 대해 선택을 해나가고 있고 각자 주어진 시간에 대해 나름대로 가치를 찾아가고 있기 때문에 어떤 것이 더 가치 있는 삶이라고 절대로 단정 지어 말해서는 안 된다. 내가 한 시간 공부하는 이 시간에 다른 누군가는 잠을 잔다거나 티브이를 보고 있거나 게임을 하고 있다고 하더라도 공부하는 시간이 더 가치 있게 보낸 시간이고 다른 시간은 헛되이 보낸 시간이라고 단정 지어서 말해서는 안 된다는 뜻이다. 모두에게 공평하게 주어지는 시간에 대해 각자 자신에게 필요한 가치를 찾았다면 그것이 진정 가치 있게 시간을 보낸 것으로 생각해야 할 것이다.

나는 인생을 살아가는 시간보다는 죽음에 초점을 맞춰서 살아가고 싶다. 죽음이 내 앞에 닥쳤을 때 영화 클릭에서 보았던 리모컨으로 내 과거를 회상해 보고 잘살았노라 회상하고 싶다. 코미디 영화임에도 주인공이 죽음에 닥쳐 이미 잃어버린 아내와 자식들에게 잘못을 뉘우치고 과거를 회상하는 장면에서 나도 모르게 눈물이 났던 이유는 어쩌면 누구나 공감하는 내용 때문이었는지 모른다.@

 폴 그레이엄 (Paul Graham)의 해커와 화가라는 책을 읽고 난 후부터 얼마 전까지만 해도 나는 프로그래머와 예술을 하는 화가가 예술적인 작품을 만들어간다는 점에서 매우 닮아있다고 생각했었다. 사실 더욱더 그렇게 믿고 있었던 까닭은 아마 폴 그레이엄뿐만 아니라 그에게 영향을 받은 많은 사람이 비유를 통해서 프로그래머와 화가의 예술적 공통점 찾고자 했었기 때문에 지금까지 그렇게 내가 믿고 있었는지도 모르겠다.

그러나 얼마 전 미술전을 다녀오고 나서 생각이 바뀌게 되었다. 많은 천재적이었던 화가들이 다시금 칭송받는 이 시대에 프로그래머들이 자신의 활동들을 예술적 경지로 끌어올리기 위한 마음을 전혀 이해하지 못하는 것은 아니지만 그렇다고 해서 예술적인 부분과 동일시하는 데에는 문제가 있어 보인다는 다고 생각하게 되었다. 프로그래머와 화가는 그 근본부터가 전혀 다른 것이다. 프로그래머와 화가가 닮은 부분은 어떤 작품을 만들어가는 그 정신일 뿐이지 그것에 대한 모든 활동과 과정들이 닮아있다고 생각하는 것은 문제가 있다.

예전에 베트남으로 출장을 갔을 때의 일이다. 베트남 개발자들이 어떻게 일하는지는 가까이서 볼 기회가 있었는데 놀라운 것은 자신의 실력에 상관없이 소프트웨어를 개발하고 있다는 자부심이 굉장히 강하다는 사실이다. 그들은 창조적인 작업을 하고 있다고 생각하고 있었고 그만큼 대우받아야 한다고 생각하는 듯이 행동하는 것을 볼 수 있었다. 민족적인 차이를 고려하고 보았을 때에도 나로서는 받아들이기 어려운 일이었다. 나는 이것들이 모두 소프트웨어와 예술작품을 만들어가는 과정을 동일시하는 데에서 오는 착각이라고 생각한다.

프로그래머는 화가들처럼 창조적이지 않다. 소프트웨어는 먼저 요구 사항에서부터 시작된다. 요구를 만들어내는 사람(제품 기획자, 고객 또는 프로그래머 자신일 수도 있다.)있고 그 요구에 맞추어 작성되는 것이 소프트웨어이다. 요구에 맞고 그 기능에 문제가 없다면 좋다고 말할 수 있고 요구에 맞지 않는다면 그냥 간단히 Shift+Del 키를 눌러서 그냥 삭제해버릴 뿐이다.

하지만, 화가들이 그려내는 예술적인 작품은 그렇지 않다. 돈을 벌려고 고객들의 요구를 들어주기는 하지만 결과물들을 판단하는 우리의 눈에 비치는 그림들은 그런 요구 말고도 하나같이 작가 개개인의 깊은 생각들을 추가로 담아내고 있다. 가장 널려진 ‘레오나르도 다 빈치 (Leonardo da Vinci)’의 작품 ‘모나리자 (Mona Lisa)’도 누군가의 요구로 만들어진 초상이기는 하지만 저자의 의도가 드러나 있다. 그 인물의 눈썹에서부터 미소, 손동작 및 배경까지 그냥 그려졌던 것은 없다. 하지만, 소프트웨어는 좋고 나쁘고 맞고 틀림의 구분이 명백하다. 분명히 예술작품의 그것과는 확실히 다른 부분이다.

또한, 예술작품은 시간이 흘러도 그 작품성을 인정받는 데 반하여 소프트웨어는 그렇지 않다. 예술작품은 500년, 천 년이 흘러도 그것의 감동이 고수라니 사람들에게 전해진다. 1500년대를 살았던 브뤼헐(Pieter Bruegel)이나 1600년대를 살았던 람브란트(Rembrandt van Rijn)이 아직도 사랑받는 이유는 이 때문일 것이다. 하지만, 소프트웨어는 30년은커녕 짧게는 고작 1~2년이 지나고 나서는 언제 그랬느냐는 듯이 그것에 대한 혹평이 이어지는 것이 현실이다. 심지어는 당신은 몇 일전에 개발한 프로그램을 바라보며 지금도 속으로 욕하고 있을지도 모른다.

예술작품은 시간이 흘러도 많이 배운 사람이건 아니건 간에 그것을 보는 이에게 개개인 나름대로 감동을 준다. 각자 해석하는 방법은 다를 수 있지만, 감동 주는 것은 같다고 하겠다. 하지만, 소프트웨어는 전혀 그렇지 않다. 심지어 전혀 감동적이지 않다. 적어도 예술작품과 비교할 정도라고 하면 컴퓨터에 친숙한 사람이건 아니건 간에 그 소프트웨어를 접했을 때 전해져 오는 예술작품과 비견할만한 정도의 감동수준이 있어야 한다고 생각한다. 이것이 소프트웨어 개발을 공학적으로 접근해야 하는 가장 명백한 이유일 것이다.

무작정 예술작품과 동일시하고 자신의 지위를 격상코자 목소리를 내기에 앞서서 그만큼 예술작품을 만드는 정신으로 소프트웨어를 만들었는가부터 자답해보는 것이 바람직하다. 예술작품에 대해 우리가 먼저 배워야 하는 것은 소프트웨어를 개발하는 데 있어서 예술작품을 만들어가는 과정과 같은 많은 노력과 고통과 헌신을 먼저 배워야 하는 것이 아닐까?@

 아마 개발자라면 누구나 잘 갖춰진 환경에서 개발 하고 싶을 것이다. 잘 갖춰진 환경이란 개발프로세스 또한 포함할 것이면 그것은 결과적으로 결과물도 좋게 만들리라 생각할 것이다.

어떤 일이든 간에 잘하고 싶다면 나보다 나은 사람에게 배우는 방법이 가장 빠른 방법일 것이다. 특별한 몇몇은 다를 수도 있겠지만 보통 사람이라면 혼자서 어떤 것을 진정 그것이 의미하는 것을 알아가는 것은 많은 시간이 필요하다. 하지만, 어떤 것은 시간을 많이 들여도 불가능한 것도 있다. 그래서 사람들은 더 빨리 잘해지기 위해서 책을 읽는다든지 하는 방법으로 나보다 더 잘하는 사람들에게 배우려고 노력하고 있다.

개발에서도 마찬가지이다. 개발하기 좋은 환경을 갖추고 싶다면 먼저 그런 환경을 겪었던 사람들에게 배우는 것이 가장 효과적이다. 하지만, 일부 사람들같이 맹목적으로 그것을 모두 수용하다가는 오히려 부작용을 낳을 것이다. 가장 중요한 것은 그것들의 ‘의도’를 제대로 파악하는 것이 중요하다.

'의도를 파악하라'라는 말을 그토록 강조해서 처음 들어본 곳은 예전에 개인적으로 참가했던 이봉석님의 세미나에서였다. 이봉석 님은 하제 소프트 대표이사이시고 디바이스 드라이버와 관련해 우리나라에서는 어느 정도 권위 있는 분이다. 그분 세미나는 물론 주제의 내용도 좋았지만, 그것보다 개인적으로 더 좋았던 것은 어떤 것을 보더라도 항상 그것의 의도를 파악하려고 노력해야 한다는 학습방법(?) 같은 것을 깨 닳은 것이다. 책에 그려진 삽화 같은 것이 그런 예가 될 수 있을 것이다. 단순히 그어진 선일지라도 저자가 분명히 말하고 싶은 내용이 있을 것이고 그것을 파악하는 사람만이 그것의 진정한 의미를 알 수 있다.

나는 그 후부터 어떤 그림 하나를 보더라도 저자의 의도를 파악해 보려고 많이 노력하고 있다. 저자의 의도를 이해하려는 노력 없이 내 생각대로만 읽는다면 아마 내용의 오인으로 말미암아 오히려 독이 될 수도 있을 것이다. 핑계이긴 하지만 때문에 요즘 나는 많이 읽기보다는 하나를 봐도 좀 천천히 보는 편이고 기술서적 독서량은 좀 줄은 편이 되었다.

요즘 나는 한참 관심을 두고 있었던 부분은 현재 개발하는 프로젝트의 인지도 향상에 관한 부분이었다. 나는 개발자이기 때문에 개발 이슈에서부터 이런 인지도 향상의 방법을 찾고자 노력했었는데 그것 중 한 가지가 CMMI(Capability Maturity Model Integration, 역량 성숙도 모델 통합)[1]에 대한 부분이었다.

물론 우리 팀이 CMMI 5단계의 인증을 받는다면 하면 인지도 향상 및 프로젝트를 내다 팔 수 있는 시장이 엄청나게 확대될 수도 있을 것이다. 하지만, 실제 프로세스 개선을 위해 만들어진 이것이 프로젝트의 인지도를 향상시키는 데 얼마나 도움이 될 것인지는 의심해볼 만하다. 심지어 그런 의도를 가지고 접근한 기업이 CMMI의 인증을 받기 엄청난 비용(컨설팅 비용까지 1억~1억 5천만 원 정도)의 소요와 CMMI 1.2의 유효기간 3년의 제약조건을 버텨낼 수 있을 지가 의문스럽다. 원래 의도대로 프로세스 개선을 위한 방향 지침 정도로 생각했어야 했다. 이것을 오인해 대박을 내게 해주는 만능 도구로 생각했던 것이 잘못 이였던 것이다.

개발 세계에서는 그것의 의도를 파악하지 못해 잘못 해석하고 그 때문에 오류를 발생시키는 일들은 엄청나게 많다. 비단 CMMI에 대한 내 생각에 대해서만 예를 들었지만 이렇게 의도를 파악하지 못하는 곳에서 발생하는 오류는 수없이 많을 수 있다. 기술적으로 가장 기본적인 스킬인 언어 문법의 의도와 API 함수와 클래스의 의도, 시스템 구성의 미들웨어(middleware) 및 각각 프로그램들, 데이터베이스 스키마(schema)의 의도를 먼저 잘 파악하는 것이 가장 중요한 부분이 될 것이다. 더 나아가서는 상사나 동료 직원과의 의사소통이나 기타 업무 처리 능력도 의도를 얼마나 잘 파악했는지에 달렸다고 말할 수 있을 것이다.@