과거의 경험을 비추어 생각해보건데, 한 사이트의 보안에 취약한 페이지는 로그인페이지보다는 ID와 비밀번호 찾기였었다. 그 이유는 로그인에 대해서는 신경써서 여러가지로 테스트 해보면서 만들지만, 그것보다 중요하지 않다고 생각하는 페이지는 고민을 많이 하지 않고, 원래 의도하던 기능만 충실히 만들기 때문에 취약점이 많은 것이 사실이었다.


사이트를 만들때 생각하는 시간에 대해 생각해 보건데, 요즘엔 모바일 페이지와 PC 버전이 만들어지는 상황에서, PC 버전은 당연히 만들어야하나 만들고, 모바일 페이지에서는 PC 버전으로 확인하라는 메시지로 대치하는 경우가 있다. 모바일로 구현하자니 시간이 들어가고, 사용성도 높지 않은 상황이라면, 쉽게 그냥 PC 버전으로 유도하는 팝업만 보이라고 작업지시가 내려지기 마련이다.


보안문제라면 사이트 제작자에게 피해가 가겠지만, 모바일 버전-PC버전 문제는 사용자에게 돌아간다. 사실 모바일 페이지를 만드는 이유는 PC 화면처럼 넓게 쓰지 못하는 상황을 작은 화면에 최적화시키도록 만드는 것이다.  PC 버전을 만들때, 모바일 화면으로 보지 않는 것이 아니다. 정말 한 번도 안본 페이지를 만날때는 정말 당황스럽다. 내가 YES24에 1년간 로그인하지 않았나보다. 모바일로 확인하다가 PC 버전으로 로그인하면 1년 넘지 않아 잠긴 내 계정을 해제시켜주겠다하여 PC 버전을 모바일로 봤다. 그러나 나에게 돌아온 것은 누를 수없이 뭉게진 로그인 다이얼로그였다.


YES24 왜 그러세요. 이 페이지 이번만 쓰고 말 것인가요?


저작자 표시 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
요새 잠을 많이 못자고 있다. 뭔가 일에 빠져들었을 때 나타나는 전형적인 증상이다. 회사일과 개인적인 일이 모두 신날 때, 건강문제를 조금 뒤로 하면 빠른 시간에 가시적인 결과가 나와서 좋은 것 아닌가.

CakePHP를 통해 MVC 구조화된 웹 어플리케이션을 개발하면서, 반은 해킹, 반은 고상한 설계를 생각하면서, 조금씩 아주 조금씩 만들어가고 있다. 조금씩이라고 말하는 이유는 한 두시간 공부해서 고작 열 몇줄 작성하는 정도이기 때문인데, 그 열 몇 줄로 MVC 프레임웍이 제공하는 재밌는 기능들을 쉽게 사용하는 것이다.

알량한 MVC 프레임웍...
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
관리자는 과정을 보고, 사용자는 결과를 본다.
어디에나, 어떤 것에나 과정과 결과라는 생각 거리가 있다. 모나리자를 만든 과정이 우리에게 중요할까? 잘 달리고 있는 지하철 5호선이 어떻게 만들어졌는지가 현재 우리에게 중요할까? 이렇듯 만드는데 참여하지 않은 대다수 사용자에게는 마지막 결과물이 중요한 경우가 많다.

개발자들에게는 개발 과정 중에 일어나는 코드의 변화를 관리해야할 필요가 생기게 된다. "버전관리"(SCM)라고 되어 있는 것 중 코드를 다루는 개발자들에게 중요한 것은, 언제 왜 그 코드가 거기에 들어가게 되었는가를 따져보는 것도 중요한 일 중의 하나이다.
svn blame
흔히 annotate 로 알려져 있는 명령이다. "svn praise" 라는 명령도 같은 일을 한다. 이 명령들은 과거에 어떤 일이 일어났는지 행단위로 알 수 있게 해준다.

과정이 중요하다는 것과 달리 이 글에서 말하고 싶은 것은, "결과가 중요하지 아니한가"는 것이다. 아니 개발을 멋있게 했다고 그래도 최종 코드가 예뻐야하지 않는가? 코드가 볼 만해야하지 않는가? 코드를 일부 수정하여 커밋할 때마다 항상 다음과 같은 생각을 염두에 둔다. 기본이다.
  • 내가 지금 반영하는 코드의 각 부분부분의 변화가 정말 의미 있는 것인가?
  • 혹시 인덴트가 바뀌었다고 커밋하지는 않았나?
  • 혹, 네이밍 컨벤션때문에 커밋하지는 않았나?
  • 내가 올리는 이 단순한 커밋때문에 과거의 기록이 묻혀버리지는 않을까?
중요한 생각들이며, 반드시 해야한다. 위에서 말한 과정 속에서 변경 기록을 남기기 위해 지켜야할 규칙들이다. 커밋하기 전 diff를 해보고, 내 변경이 이전 변경에 대해 기록을 덮어 쓰게 되지는 않는가?그것이 바이너리 파일이 아닌바에는 한 줄 한 줄의 변화가 의미 있어야하는 것이다. 커밋하나 할 때마다 이런 규칙들이 정교하게 지켜져야한다. 그러니 적어도 스스로 자책하지 않으려면, 최초에 인덴트, 네이밍 확실하게 해야한다. 예를 들어 보자

Revision 1: 최초 구현
1: for( i=0; i < MAX; i ++ )
1: {
1:     do_something( i );
1: }
Revision 2: MAX 를 사용하는 것이 버그였으며 BUFF_MAX 를 이용해야하므로 수정함.
2: for( i=0; i < BUFF_MAX; i++ )
1: {
1:     do_something( i );
1: }
Revision 3: 들여쓰기 오류가 지적되어 "{" 위치와 "( )" 앞 뒤의 공백을 조정
3: for(i=0; i < BUFF_MAX; i++) {
3:     do_something(i);
1: }
("{" 를 내리는 것도 문제가 된다.)
물론, BUFF_MAX 보다 인덴테이션이 더 중요했다고 말하면 할 말이 없다. 하지만, 이런 오류는 파일전반에 걸쳐 지적되기 쉽고, 상당히 많은 곳에 "들여쓰기 오류로 인해 수정" 이라는 기록이 마지막이 될 것이다. 예를 들어 설명했지만, 이와 같이 커밋이 처음부터 신중하게 되어 규칙을 지켰더라면 더 아름다운 기록이 될 것이다.

이렇게 생각하고 나면, 정말 커밋이 두려워지고, 사소하다 생각된 들여쓰기를 수정하지 않으면, 나중에 보다보면 들여쓰기도 위아래가 들쭉날쭉이 된다. 단순한 예를 들어 설명했지만, 이런 비슷한 것에는
  • 행 끝에 주석 달기
  • 함수 위치 옮기기
  • 함수 위치를 다른 파일로 옮기기
  • 노출 되지 않는 함수에 static 달기
  • 변경되지 않는 함수 인자에 const 달기
  • 변수 이름 변경하기
  • 숫자를 define으로 치환하기
  • 보기 좋게 enumeration 정렬하기
등이 있다. 이런 기본적인 것이 되지 않은 다른 사람의 코드나 어릴적(?) 코드를 보게 되면 사실 과거 히스토리를 생각하면, 수정하여야겠다는 욕구를 억눌러야하고, 실제로 억누른다. (나만 이러한가?)
파일 이름을 바꾸거나 다른 곳에 옮길 때도 svn의 경우 "svn copy" 를 써서 히스토리를 가져올 수 있어야한다. 그렇지 않으면 이전 변경 기록들은 모조리 사라지게 된다.

어찌, 과정을 중요시하는 것이 예쁜 결과를 눈 앞에 두고도 고치는 것을 억눌러야하는가! 사실, 코딩 컨벤션이나 엉성하게 작성된 코드는 나름 과거도 관리해야할 필요가 없을 정도로 커밋되었을 가능성이 많지 않은가?! 아우우~!

관리자로서, 코드의 변화를 중요시하고 이력관리를 해야하는 것과 잘못 작성된 코드에 대해 고쳐야하는 심정은 스스로 싸우게 되기 마련인것 같다.

내적갈등의 외적 표현이라 생각하시고 글읽기를 마무리 해주셨으면 한다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  1. 최호진 2006.08.29 15:29 신고

    멀티 플레이어가 대세인 요즘 사회 분위기에 동조하는 글 아닌가...!

  2. sooya 2006.09.01 09:18 신고

    의미 없는 커밋을 하면 주위사람이 괴롭다는 것을 뼈져리게 느끼는 요몇일이예요 -_-..
    아... 화날려고해요 -_-;

    • 최호진 2006.09.03 16:47 신고

      사람마다 배울 것과 배우지 말아야할 것을 구별해 놓으면, 웃을 수 있어..

+ Recent posts