뒷담화 기록보관소

보통 SQL의 Where절을 구성할 때에는 다음과 같은 빈번한 형태에서 벗어나기 힘들다.

WHERE col1=val1 AND col2=val2 AND …

천편일률적 형태이긴 하지만, 실제로 이런 형태로 대부분의 문제는 해결되기 마련이다. 하지만 SQL이 아닌 일반 프로그래밍 언어에서 많이 사용하는 if문에서처럼 조건문을 Where절로 구현하려면 어떻게 해야 할까?

이산 수학(Discrete Mathematics)에서는 참과 거짓을 다루는 명제와 조건명제에 대한 이야기가 나온다. 명제는 참인지 거짓인지를 명확하게 판별할 수 있는 문장이나 수식을 말하며, p, q, r 등으로 표현한다. 함축(조건명제)은 두 개의 명제가 다음과 같은 관계를 가질 때 성립된다. 각 행의 내용은 동일한 의미를 가지며, 첫 번째 내용은 예시 문장이다.

• "날씨가 화창하다" → "소풍을 간다"
• p → q
• if p then q

위의 내용은 진리표(Truth Table)에 의해 다음 수식과 논리적으로 동치(Logical Equivalent)한다.

~p ∨ q

한글로 된 최초 명제의 예시로 치환하면(의미적으로) 다음과 같다.

"날씨가 나쁘거나 소풍을 간다"

날씨가 화창하다면 소풍을 가는지의 여부에 따라 참 거짓이 판별이 나는 것이고, 날씨가 나쁘면 소풍 여부는 상관이 없게 된다.

SQL 이야기로 돌아와서, 무조건 어떤 수식을 검사해야 하는 것이 아닌, 특정 조건에 따라 검사를 하거나 하지 않는 여부가 달라지는 복합적인 조건이 있다면 대개는 SQL을 동적으로 생성하는 외부 프로그래밍 언어 레벨이나 조건별 지시자를 이용하는 쿼리 프레임워크 레벨에서 if문과 같은 기능을 이용하여 복잡하게 구성하려고 하는 시도를 많이 보게 된다.

WHERE 1=1 (if condition1 = value1 then) AND A=B (end if)

위에서 설명한 명제의 함축을 이용하면 SQL 내에서 논리적 수식 만으로도 이러한 의미를 동일하게 구사할 수 있다.

WHERE (condition1 <> value1 OR A = B)

OR가 들어가니 성능에 영향을 줄까 걱정을 할 수도 있지만, OR 연산자의 앞부분이 참이면 뒷부분은 실제 평가를 하지 않고 넘어가는 쿼리 옵티마이저의 특성을 생각하면 결론적인 성능차이는 걱정할 수준이 되지 못한다.

요샌 저작권 무서워서 아무거나 퍼다 나르면 패가망신할 것만 같다. 저작권이 있는 자료의 내용 일부, 이미지나 사진의 조각, 동영상 및 BGM 음원도 예외가 될 수 없다.

예전에 몇 년간 즐겁게 개인 홈페이지를 꾸밀 때만 해도 이 정도까지 분위기가 흉흉하진 않았는데, 알면 알수록 더 무서운 게 저작권이다. 산업재산권까지 합쳐서 지식재산권이라고 부르기도 하는데, 요새는 여기다가 퍼블리시티권이라는 새로운 용어까지 대두되고 있으니 인터넷에 뭔가 올릴 때에는 절대 허투루 올리면 안 된다.

이 블로그도 제대로 글을 쌓기 시작한지 얼마 되지도 않았는데, 대대적인(?) 수술을 단행할 수밖에 없었다. 생각 없이 올려두고 있다 폭탄을 맞는 것 보다는 아무래도 마음이 편한 쪽이 나으니까.

블로그 프로필 사진(이미지)을 설정하는 관리자 기능이 있다. 연예인과 동급으로 잘생긴 외모를 가졌거나, 지나친 자신감으로 똘똘 뭉친 경우가 아니기에 도저히 얼굴사진 같은 민망한 설정을 할 수는 없으니, 적당한 이미지를 골라서 갖다 박아뒀는데, 내가 직접 그린 이미지가 아니면 언제 어디에서 뒤통수를 당할지 모르는 일 아닌가? 영 허접스럽긴 하지만 직접 끄적거린 이미지가 마음은 편하다.

내가 사용하는 핸드폰의 기능 중 팁이랍시고 올린 두 개의 글이 있었는데, 설명용 이미지를 해당 핸드폰 매뉴얼 자료에서 발췌해서 편집한 이미지를 사용했다가 부랴부랴 그림판 등을 동원해서 괴발개발 그려서 다시 올렸다. 매뉴얼 앞부분에 저작권 표시가 떡 하니 있었는데, 간과한 게 죄다.

커뮤니티 사이트에서 누군가 올린 게시물을 통해 재미있게 봤던 카툰을 블로그에 게시했었다. 오늘에 와서 다시 주의 깊게 살펴보니 CCL 라이선스, 즉 출처 밝히고 비영리에 변경불가다. 지금은 아니지만, 나중에 여기다 애드센스라도 하나 붙이면 영리인지 비영리인지 논란거리가 될 소지가 있는데, 분란의 싹은 애초에 뽑아두는 것이 상책. 그 결과로 현재 몇 개 되지도 않는 이 블로그의 포스트 하나가 줄어들었다.

이렇게 힘들게 저작권과의 사투를 벌여서 겨우 논란에서 자유로운 기틀을 잡았으니, 이제 나는 CCL은 달지 않을 거다. 맘대로 퍼가지 마시오! 라고 해 봤자 재미도 없는 텍스트만 가득한 이 내용을 누가 눈독이나 들이겠냐 만, 흥!

며칠 전 지인의 블로그에 오랜만에 놀러 갔는데, 아기자기한 캐릭터 그림과 귀욤귀욤한 테마로 꾸며짐이 강렬한 인상을 줬다. 그래도 저작권과는 절대 트러블이 있을 수 없을 것이다. 왜냐하면 직접 캐릭터를 그리고 테마까지 제작하는 디자이너이기 때문이다. 같은 컴과 출신인데, 부러울 따름이다.

지금 이 순간에도 이곳 저곳에서 사진과 이미지, 음원과 동영상들을 퍼 나르며 용감하게 광고배너까지 부착한 블로그들을 쉽게 검색해낼 수 있다. 무슨 배짱인지 모르겠다.

HTML 폼 입력란에서 엔터키 막느라 바쁜 양반들이 많다. 그나마 2000년대 초중반에는 몇 안 되는 개발자 커뮤니티 사이트 게시판에서 꼼수의 일종으로 조금씩 퍼지더니, 바야흐로 블로그 홍수시대에 와서는 온통 바이블이라도 되는 양 예제 코드랍시고 퍼 나르고들 계신다.

어디 한두 개라면 조용히 댓글 훈수라도 시도해 보겠건만, 검색엔진에서 수두룩하게 쏟아 나오는 결과 페이지들의 규모를 보니 이미 틀렸다.

심지어는 엔터키를 이미 가로챈 상황에서 역으로 엔터키 누르면 submit 되게 하는 방법이라 소개하는 웃지 못 할 블로그 내용도 있을 정도니 심각한 일이 아닐 수 없다.

form에 input type=text가 1개만 있으면 엔터누르면 서밋이 된다고???

얼마 전 우연찮게 재미있는 블로그 내용을 하나 발견했다. 블로그 주인장의 호기심과 댓글 릴레이 덕분에 실제로 새로운 사실을 알게 된 계기가 되었지만, 결국 온전한 폼이라면 어떻게든 submit이 되는 것이 원래 당연한 것 아닌가 하는 의견을 덧칠하고 싶다.

해외의 경우도 크게 다를 바가 없는 모양이다. 오죽하면 이런 글이 나올 정도니까.

The Enter Key should Submit Forms, Stop Suppressing it

jQuery팀 멤버가 하는 얘기니까 단순 헛소리라고 매도하려면 꽤 단단하게 논리 무장을 준비해야 하지 않을까?

다시 원점으로 돌아와서, 엔터키 이벤트 처리하느라 바쁘신 많은 웹 개발자분들에게 이런 이야기를 하고자 한다.

엔터키를 누르면 submit되는 것이 당연하다.

정상적으로 만든 폼이라면, TextArea 같은 특수한 입력 객체를 제외하면 엔터키로 submit되는 것이 당연하고, 그렇게 되어야만 한다. 원래 안 된다고? 그건 폼을 잘못 만들어서 그렇다. 아직도 A 태그로 만든 링크버튼으로 submit 호출하는 것이 정상적이라고 생각하는 착각에 갇혀있지 않기를 바랄 뿐이다.

폼 검사(Form Validation)는 onsubmit 이벤트 핸들러로 처리한다.

입력값 검증은 원래 onsubmit 이벤트 핸들러로 하는 것이다. 아직도 많은 사람들이 가짜 submit 버튼(A 태그 등의)에 달려있는 onclick 이벤트 핸들러로 폼 검사를 하고 있는데, 그런 건 안했으면 좋겠다.

스크립트에 너무 의존하지 마라.

폼 검사, Ajax 등 스크립트 기반 기능은 기본적인 마크업 내용의 편의성을 증대시키는데 사용되어야 하는 것이지, 필수가 되어서는 바람직하지 않다. 바람직한 웹 개발에서는 클라이언트 브라우저의 스크립트에 의한 폼 검사를 거치지 않아도 서버 측에서 입력 값에 대한 오류처리를 충분히 해야 하며, 적절한 UI를 제공해야 한다. 스크립트는 점진적 향상(Progressive Enhancement)에 있어서 하나의 측면일 뿐이다.