영화속에서의 IT (1): 허리케인 하이스트

이런 글을 쓰고자 한 목적부터.

이 블로그에도 잘 나와 있지만 취미가 영화보기인데
그 중에서도 최신 개봉작 챙겨보기다.

남들이 알고 있는 영화는 물론이고
남들이 잘 모르는 영화, 관심도 안가지는 영화임에도 불구하고 개봉작인데 볼만하다고 생각되면 본다.
남들의 평점으로 영화를 볼지 안볼지를 결정하는 건 나한테는 있을 수 없는 일이기에, 생각 외로 영화를 자주 보는 편이며 거기에 뭔가 눈에 거슬리는 것들은 아무래도 내가 좀 잘 알고 있는 분야의 장면이 나올 때인 것 같다.

여태까지 봤던 영화는 뭐 나중에 시간나면 써볼건데
우선 올해 본 영화 중에서 하나씩 써 보려 한다.
그래서 그 첫번째 영화는 허리케인 하이스트이다.

<Hurricane heist 해외판 포스터, 허리케인을 똟고 나오는 트럭 그리고 흩날리는 지폐가 생동감있는 액션을 선사해 줄 것이라는 걸 암시해 준다.>

IT 관련된 얘기에 앞서, 우선 영화에 나오는 허리케인 부터가 그렇게 현실적으로 존재할리가 없고 설사 영화적 장치를 위해 존재하는 허리케인이라 하더라도 비현실적인건 맞다. 하지만 난 기상 학자는 아니니까 이 부분은 패스하고.

일부 스포일러가 있을 수 있지만 IT 관련된 내용만 짚어낼 거라 큰 상관은 없을 듯 한데, 그래도 불편한 분은 안보는 걸 추천한다.

• 전반적으로 큰 구멍이 없는 설정인데

1. 주인공 윌의 차: 정교하게 만들어진 시스템 하에 작동하는 튼튼한 차다.
2. 드론: 드론 설정도 꽤 현실적이며 큰 문제는 없다.
3. 보안 시스템: 홍채 인식, 지문 인식 등 실제 존재하는 보안 인식 기능을 사용함으로써 신뢰도 있는 연방의 관리 시설이라는 인식을 강하게 심어준다.
4. 별도 네트워크 사용: 해킹을 위한 별도의 망을 쓰는데 그게 동네 있는 송전탑이라는 점

그럼에도 불구하고 지적을 해 보자면

• 암호가 바껴서 다시 해킹을 위한 암호화 알고리즘을 돌린다? 돌리는건 그렇다 치고 시간도 걸린다?
• 여기가 좀 마음에 안드는데, 영화 구성을 위해 넣은 장치이기는 하다. 알고리즘을 푸는데 시간을 소비하게 함으로써 주인공들이 뭔가 작전을 짜고 실행할 수 있는 시간을 벌어준다는 거에 있는데
• 사실 암호화 알고리즘이 바뀌면 그냥 안된다고 보는게 맞다. 그리고 영화상에서 분명히 얘기한다 어떤 key값이나 인증할만한 값을 구하는게 아니라 알고리즘을 다시 돌려야 한다고.
• 결국 알고리즘 얘기는 가짜에 불과하고 설명한대로 영화적 장치를 위해 넣은 것 뿐이다. 홍채 인식, 지문 인식 까지 있는 마당에 숫자로 된 알고리즘 그것도 거창한 것도 아니고 피보나치 관련된 거라고 언급까지 하니 모르는 사람이 보면 뭔가 대단한 거라도 해야 되는 것처럼 들린다.
• 게다가 네트워크를 사용해서 접근해야 되는 거면 이미 서버 쪽에서 접근 시도한걸 알아채고 끊어버릴 수 있는데도, 실제 송전탑이 물리적으로 박살나 네트워크가 안되는 상황이어야 실패를 한다.
• 고로 연방 시설의 서버 보안도 그렇게 썩 좋은 편은 아니라는 걸 알 수 있다.
• 이미 몇 달전 부터 계획해서 침투해 들어온 해커들이 쓸데 없는 키보드질을 하고 있다?
• 이건 다른 영화에서도 보이는 쓸데 없는 설정들인데 뭔가 키보드로 대단해 보이는 명령어들을 마구 입력하는 쓸데없는 짓을 해야 보안 시스템을 겨우 뚫을 수 있는 것처럼 해 놓는데
• 제발 이러지 말자, 어차피 admin이나 그에 준하는 계정을 획득해 시스템에 로그인 했으면 그냥 끝난거나 다름 없다.
• 그럼에도 불구하고 두 해커는 시스템에 접근하는데 상당한 시간을 소비한다.
• 시대가 많이 변했다. 보안 시스템 = 뭔가 어려운 작업 = 남들은 알지 못할것이라는 쓸데 없는 키보드질 이라는 설정은 그만하자.

쓰고 보니 IT 관련되서는 사실 구멍 보다는 보안 설정이 생각보다 잘 되어 있어서 그렇게 많이 깔만한 요소는 없는 것 같다.

소프트웨어가 뭔지 모르는 사람들이 코딩에 대한 질문을 하고 있는 걸 볼 때의 안타까움

우선 소프트웨어 개발이라는 용어에 대해 명확하게 이해한 후에 얘기를 해보고자 한다.

개발을 한다는 건 소프트웨어를 개발한다는 것이고 코딩을 한다는 건 프로그래밍 언어로 스크립트를 작성한다는 얘기다.
소프트웨어 개발과 코딩의 차이는 엄청난 것임에도 불구하고 소프트웨어에 무지한 사람들에게는 두 단어의 차이는 거의 없다고 봐도 될 정도이다.
그냥 특정 프로그램 언어로 코딩해서 실행하면 어떤 결과가 화면에 나오는 것 정도로 이해하고 있을 수 있는데, 사실 이 둘의 차이는 엄청난 것이다.

<당장 Software engineering으로 검색해봐도 나오는 이미지가 이렇다>

개발을 하는 대상이 소프트웨어이므로 소프트웨어 개발은 아래 내용들이 포함되는 걸 얘기한다.

• 요구사항의 확인, 수집, 분석
• 소프트웨어로의 개발 계획
• 요구사항 및 시스템의 설계
• 구현, 버그 수정, 테스트, 문서화
• 추가 요구사항에 대한 커스터마이징 및 버전관리, 유지보수

자 이제 내가 얘기하려고 하는 건 위의 내용을 학문적으로 공부해 본 적도 없고 실무에서도 적용해 본 적이 없는 사람들에 대한 얘기다.

안타깝게도 실무 경험은 없지만 학교에서 학문적으로 소프트웨어에 대한 과목을 공부해 본 컴퓨터 관련 학과 전공자 3학년 이상 학생들도 포함되는 얘기다.

네이버의 개발 관련 커뮤니티 까페를 가보면서 많은 사람들의 질문 글들을 보는데, 대부분 안되는 걸 되게 만들고 싶어하는 욕구가 충만한 글들이 대부분이다.

문제는 그 안되는 것들이 조금만 찾아보고 생각해 보면 다 해결할 수 있는 것들이라는 것이다. 사실 그런건 해결해 주면 되고, 다른 사람들도 댓글을 잘 달아주는 편이다.

어? 이게 문제가 아니면 뭐가 문제인거냐? 라고 생각할텐데 내가 안타까워 하는 건 그런 식의 문제 해결이 코딩하는 능력 향상에 매우 방해가 되는 행위라는 것이고, 소프트웨어 개발을 하는 능력 향상에는 전혀 미치지 못한다는 것이 문제라는 것이다. 위에 나열한 소프트웨어 개발 내용 중에 구현에만 해당되는 내용이며 구현에 따라서 다르겠지만 거의 대부분 잘 모르고 구현한다.

잘 모르고 구현한다는게 이해가 안될 수 있는데, 검색해 보면 그들이 원하는 거의 모든 문제의 해결은 best practice 라고 모범 답안 같은게 있다. 이것만 보고 이해한 다음에 자기가 구현하고자 하는 문제 해결에 응용해서 적용하면 해결된다. 이것도 어렵다 하면 기초적인 공부를 더 하는 것이 맞는데도 이 마저도 찾아보지 않고 찾았다고 하더라도 이해를 못하거나 이해를 하려고 하지 않는다. 그런 상태에서 안되는 걸 되게만 하려고 구현하고 있다는 게 잘 모르고 구현한다고 하는 것이다.

그런 질문을 하는 사람들의 다른 글들을 쭉 보면 소프트웨어 공학적인 기법, 설계의 노하우, 테스트, 오류 검증 방법, 성능 향상 이런 것들이 아니다. 반복적이고 단순한 문제를 마치 어려운 것 처럼 계속 질문해 나가고 답변이 달리면 마치 자기가 해결을 한 것 마냥 개발이 잘 되고 있는 것 같은 착각을 한다. 그 후에도 계속 비슷한 패턴의 질문-답변-질문-답변이 이어지는데 그러다 질문이 어느 순간 끊기게 된다. 이유는 예측이 가능하다. 자기가 알던 개발이라는 것이 코딩이 다가 아니라는 걸 깨닫는 순간인 것이다.

결국 그런 사람에게는 다음과 같은 문제점들이 나타나게 되어 있다.

• 요구사항이 뭔지 모르니까 뭘 만들어야 하는지 정확히 인지가 안되고,
• 계획을 잡지 않으니 생각대로 진행이 안되고 뒤죽박죽이 된다.
• 설계라는 걸 하지 않고 구현 먼저 했으니, 구현이 끝난 후에 다시 기존에 구현한 것에 덧붙이거나 다른 기능/모듈과의 연결을 계속해서 구현하기가 힘들어 지고,
• 버그 수정 능력도 부족한테
• 테스트라는 것도 할리가 없기 때문에
• 결론적으로 소프트웨어의 품질이 매우 떨어지게 되어 있다.

게다가 어찌해서 완료를 했다 하더라도 나중에 다시 버전업해서 기능 추가를 하려면 어디서 부터 손을 대야 할지 막막하니까 "그냥 다시 만들자" 라는 얘기가 나오게 된다. 그냥 다시 만들자는 얘기가 나온다는 건 소프트웨어를 아주 잘못 만든 것이다.

그래서 전공자던 비전공자던 일단은 생각한걸 바로 코딩하다가 막힌걸 물어보는걸 먼저 하지 말고 계획과 설계를 최소한 두번 이상 생각해서 문서화 라는 걸 한 후에 해보면 좋겠다는 생각이 든다. 그리고 비슷한 종류의 문제와 고민은 반드시 다른 사람도 겪어본 고민이기 때문에 구글에 검색해 보면 관련된 내용과 사례는 충분히 찾아낼 수 있다. 그래서 사실 그들에게 완벽에 가까운 답변인 "문서화 + 구글 검색" 이라는 얘기를 매우 해주고 싶긴 하지만, 정작 그들에게 필요한건 지금 내가 짠 코드가 안도는 이유(이유라도 알고 이해하면 다행)와 이걸 되게 하려면 어떻게 해야 하는지가 더 중요하다고 생각할 것이다.

나는 그들이 문제해결은 물론이고, 소프트웨어 공학 아니 공학까지 거창하게 갈 필요도 없다 소프트웨어 개발에 대한 이해를 하고 코딩이라는 걸 했으면 한다. 그리고 정말 진심으로 도와주고 싶다. 

다음에 내가 그들을 도와주려는 방법과 실천하는 사례를 얘기해 보려 한다.