레고를 한 번이라도 밟아본 사람이라면 알 것이다. 머리 끝까지 치밀어오르는 극심한 통증을…. 아이가 있는 집이라면 더하다. 이를 혹자는 '레고 지뢰밭'이라고 말한다. 레고는 알다시피, 덴마크의 농촌 출신 목수 올레 키르크 크리스티안센이 영국 블록완구 키디크래프트 셀프록킹 브릭스의 기술을 빌려 만든 것이 시초다. 하지만 가장 먼저 레고를 밟은 사람이 누구냐는 구체적인 기록은 아쉽게도 남아있지 않다.

다음은 미국의 과학전문 매체 기즈모도가 레고를 밟으면 왜 그렇게 아픈지 과학적으로 소개한 것이다. 사소할 수도 있지만 한 번쯤 생각해볼 법한 궁금증이니 확인해보자.

◆ 바닥에는 여러가지 물건이 널려져 있는데 왜 유독 레고만 그렇게 아픈 것일까?

가장 큰 이유는 레고를 밟게 되는 발바닥이 인체 중에서도 매우 민감한 부위라는 것이다. 통증과 압력 등의 자극을 증폭해서 느끼게 되는 것이라고 한다.

◆ 왜 발바닥은 그렇게 민감한가?

사람은 발바닥을 통해 항상 균형을 잡는다. 따라서 이 부위에서 뇌로 제대로 된 정보를 보내지 않으면 우리는 균형을 잃고 쓰러지게 된다. 그런 이유 때문에 발바닥에 신경이 빼곡히 붙어있는 것이다.

◆ 그런데 왜 레고만 유독 아프다고 느껴지는가?

발바닥으로 밟아도 아픈 것은 그밖에도 많이 존재하긴 한다. 레고 공식 사이트에 따르면 지금까지 팔린 레고 블록의 갯수는 이제 인류 한 사람당 83개 정도 갖고 있는 것과 맞먹는다. 그만큼 도처에 널려 있고 칼과 같은 보기에도 위험한 물건과 달리 그리 신경쓰지 않기 때문이다. 또한 아이가 놀이를 하는 곳도 바닥이다 보니 밟게 될 확률이 높아지는 것이다.

특히 레고는 다른 물건과 달리 밟아도 쉽게 망가지지 않는다. 2012년 영국의 BBC 방송이 영국 개방대학에 의뢰해 레고 한 조각에 걸리는 부하를 조사한 결과, 변형될 때까지 걸리는 힘이 무려 4240뉴턴(N)인 것으로 나타났다. 이는 이 작은 레고 한 조각이 432kg의 힘을 버텨낼 수 있다는 것이다. 따라서 딱딱한 바닥에서 레고 한 조각을 무심코 밟았다면 이만큼의 힘이 고스란히 발바닥 신경으로 전달되는 것이다.

또한 레고를 밟을 때에는 가만히 밟는 것이 아니라 걷다가 밟는 것이므로 그 충격은 체중의 약 9배에 달하며 천천히 걷고 있을 때에도 충격은 2배가 된다고 한다.

과학적으로 레고를 밟을 때 압력을 계산해보면, 돌기(스터드)가 가로·세로 2개씩인 2X2 크기의 표준 레고 한 조각이 발바닥에 닿는 면적은 약 2.25㎠(돌기는 무시한다). 이를 체중 75kg(165파운드, 734뉴턴)인 남성이 밟았다고 가정해보자.

압력은 힘을 면적으로 나눈 값(P=F/A)이므로, 이를 걷고 있을 때가 아닌 단지 한 쪽에서 서서 레고 조각을 밟는 것만으로 발바닥에 걸리는 압력은 무려 3,262,222파스칼(=734N/0.000225㎡)에 달한다. 이는 표준 대기압의 32배에 달하는 힘이 매우 민감한 부위로 전달한다는 계산이 나온다. 앞서 소개한 바와 같이 레고를 밟을 때에는 단순히 서있던 것이 아니라 성큼성큼 걷다가 밟는 경우가 대부분이므로 그 고통은 이것의 2~9배에 달할 것이다.

이제 레고를 밟으면 왜 그렇게 아픈지 과학적으로 알게 됐으니 레고가 있는 가정이라면 평소 밟지 않도록 주의하자.

출처: <http://media.daum.net/digital/newsview?newsid=20140825155713453>

Paul Rubens | CIO

파레토 법칙에 따르면, 어떤 사건에서든 20%가 전체를 결정한다. 80:20 법칙으로 알려진 이 법칙은 사람과 관련된 거의 모든 분야에 설명력을 가진다.

소프트웨어 개발 분야에 이 법칙을 적용한다면, 몇 가지 잘못된 코딩 관행이 대다수 문제에서 원인이 된다고 정리할 수 있다. 즉 이런 잘못된 부분을 줄이거나 없애면 업무가 훨씬 쉬워지고, 생산적이 될 것이다. 가장 나쁜 코딩 실수 10가지를 정리했다.

1. 코드에서의 오탈자

놀랄 만큼 빈번히 저지르는 실수다. 프로그래밍 능력과는 아무런 관련이 없다는 점에서 '어이 없는' 실수이기도 하다. 단 하나의 변수나 기능의 명칭을 잘못 적어 코드 전체가 망가질 수 있다. 더 큰 문제는 이를 발견하기가 쉽지 않을 수 있다는 것이다.

해결책은 뭘까? 좋은 IDE(Integrated Development Environment)나 프로그램 전용 텍스트 에디터를 이용하면 오자를 크게 줄일 수 있다. 또 다른 방법도 있다. 쉽게 맞춤법에 따라 쓸 수 있도록 신중하게 변수나 기능의 명칭을 선택한다. 그러면 철자를 잘못 쓴 경우에도 쉽게 발견할 수 있다. 'recieve'로 잘못 쓸 확률이 높은 'receive' 같은 단어는 사용하지 않는 것이다.

2. 코드를 들여쓰기 또는 서식화하지 않는 실수

코드를 들여쓰기(indenting) 또는 다른 방식으로 서식화(formatting) 해야 한다. 그래야만 한 눈에 확인하면서 실수를 파악하기 쉽다. 또 다른 사람들이 코드 작업을 할 때도 도움을 준다. 코드가 일관된 형식으로 구성되어 있기 때문이다.

코드를 자동 서식화하지 않는 IDE를 쓰고 있다면, 자신이 정한 규칙에 따라 서식화 작업을 해주는 'Uncrustify' 같은 코드 뷰티퍼(Beautifer) 툴을 통해 코드 서식화를 하는 것을 검토한다.

3. 코드를 모듈화 하지 않는 것

코딩에 있어서는 좋은 관행 중 하나는 단 한 가지만 수행하는 기능을 쓰는 것이다. 코딩을 이해 및 유지관리가 쉽게 간략히 만드는데 도움을 준다. 긴 기능들에는 이를 통과하는 경로가 많을 수 있다. 따라서 테스트가 힘들어진다.

이를 위한 첫 번째 원칙은 '특정 한 기능이 화면 하나 이상의 공간을 차지하지 않도록 하는 것이다.' 두 번째 원칙은 '만약 if가 10개 이상이라면 너무 복잡하다는 의미이기 때문에 코드를 다시 쓰는 것이다.'

4. IDE를 지나치게 믿는 실수

코드 완성 (Code Completion) 기능을 제공하는 IDE 등의 툴들은 생산성 측면에서 '환상적'이다. 타이핑한 내용을 바탕으로 변수 등을 제시해 주기 때문이다. 그러나 이런 툴이 초래하는 위험 하나가 있다.

자신이 원하는 바를 정확히 완성시키기 위해 필요한 노력 대신, 보이는 무언가를 선택하게 되는 위험이다. 이 툴이 대신 '생각'해줄 수는 있지만 모든 부분에 이상이 없도록 만전을 기해야 하는 것은 자신의 책임이다.

그리고 당신 대신 생각을 해주는 과정에 위험이 초래될 수 있다. 코드 완성 툴은 오식 같은 실수를 줄여주고, 생산성을 높여준다. 그러나 방심을 한다면 '코드 완성' 오류가 초래될 수 있다.

5. 패스워드 하드코딩

나중에 시스템에 들어갈 수 있는 비밀 계정이나 패스워드를 하드코딩 하려는 유혹에 빠지기 쉽다. 이런 실수를 저질러서는 안 된다. 물론 편리할 수 있다. 그러나 다른 사람들 또한 쉽게 소스코드에 접근할 수 있다.

하드코딩 한 패스워드가 최초 당신의 의도보다 더 널리 알려질 수 있다는데 큰 문제가 있다. 이렇게 되면 큰 보안 문제가 초래된다. 그리고 이를 고치기 위해 큰 수고를 해야 한다.

6. 보호된 데이터를 제대로 암호화 하지 않는 실수

네트워크를 따라 이동하는 중요한 비밀 데이터에는 암호화가 필요하다. 네트워크를 이동하는 도중에 가로채기를 당할 위험이 있기 때문이다. 이는 그저 좋은 아이디어에만 머무는 것이 아니다. 법이나 규정에 따라 지켜야 할 의무사항이다.

암호화 없이 데이터를 전송하면 안 되는 것처럼 독자적인 암호화나 난독화 체계를 사용해서도 안 된다. 독자적으로 안전한 암호화 시스템을 개발하기란 아주 어렵다. WEP 사례를 보면 알 수 있다. 따라서 산업에서 입증된 표준 암호화 라이브러리를 정확히 도입해 사용해야 한다.

7. 너무 이른 코드 최적화

전설적인 프로그래머인 도널드 커누쓰(Donald Knuth)는 "프로그래머들은 프로그램에서 중요하지 않은 부분을 고심하느라 많은 시간을 낭비한다. 문제는 이런 효율성을 위한 노력이 디버깅이나 유지보수가 필요할 때 부정적인 영향을 초래한다는 것이다"고 말한 바 있다.

즉 코드가 더 빨리 실행되도록 천재성을 발휘했지만, 이것이 디버깅과 유지보수를 더 어렵게 만들 수 있는 것이다. 이를 위한 좋은 전략이 있다. 일단 깔끔하게 코드를 작성한다. 그리고 성능 향상을 위해서 최적화가 꼭 필요한 부분만 손을 본다.

8. 앞서 생각하지 못하는 실수

프로젝트의 목적은 무엇일까? 어느 정도 확장이 필요할까? 사용자 수는 얼마나 될까? 얼마나 빨리 실행될 수 있어야 할까? 이런 질문에 대한 답이 확실하지 않을 수 있다. 그러나 추정해야만 한다. 그래야만 이들 요건을 충족할 수 있는 애플리케이션 개발에 필요한 적당한 프레임워크를 선택할 수 있다.

트위터(Twitter)는 이런 미래의 요건들을 과소평가했을 때 직면할 수 있는 문제들의 본보기를 제시한다. 트위터는 루비(Ruby)와 레일스(Rails)를 포기하고, 스칼라(Scala)와 다른 기술을 이용해 코드의 상당 부분을 다시 개발해야 했다. 최초 채택한 루비 코드로는 고속 성장하는 사용자 기반에 맞춰 확장을 할 수 없었기 때문이다.

9. 프로젝트에 인력을 추가시키면서 시간을 낭비

대다수의 소프트웨어 프로젝트는 일정을 맞추지 못한다. 프로젝트에 인력을 추가시키면 다시 정상궤도에 올라설 것처럼 보인다. 그러나 이는 가장 많이 저지르는 실수 중 하나다. 실제로는 프로젝트에 새 인력을 추가할 경우 전반적인 생산성이 저하되는 결과가 초래된다.

10. 잘못된 시간 (일정) 추정

동시에 프로젝트에 인력을 추가하지 않고도 나중에 일정을 앞당기면 된다는 '유혹'에 빠져 들어서는 안 된다. 일정에 뒤쳐진 이유는 시간 또는 일정에 대한 추정이 잘못됐기 때문이다. 잘못된 것으로 밝혀진 프로젝트 일정을 무턱대고 고수하지 말고, 새로 다시 추정해야 한다는 의미다.

<출처: CIOKorea>