zerq

사이트 제작 중 쿠키로 세션을 체크하는데 새로고침을 하면 계속 세션이 풀리는 현상이 발생했다.

크롬과 사파리에서만...

참고로 이 사이트는 codeigniter를 사용해서 제작했다.

그리고 http://도메인/그룹아이디 로 접속을 해서 그룹아이디를 쿠키로 굽고 그 쿠키를 가지고 로그인체크를 하는 구조를 가지고 있었다.

원인을 찾아보다 쿠키값을 찍어보니 favicon.ico라는 값이 찍히면서 쿠키값이 변경되는것이었다.

왜 저 값이 찍히는지 찾아보는데 아무리 소스를 들여봐도 해당 단어는 없었다.

그러다 codeigniter로 작성했다는걸 생각하면서 혹시 http://도메인/favicon.ico라는 접속이 이뤄지는것이 아닐까 라는 생각을 하게 되었다.

그래서 소스에서 저런 접속이 있으면 끝내도록 수정을 하니 이 문제가 사라졌다.

확인은 해봐야겠지만 원인은 밝혀졌다.

크롬과 사파리에서는 새로고침 시 

http://도메인/favicon.ico 에 접속을 해서 파비콘을 확인하는것이었다.

크롬과 사파리에서 파비콘을 확인하면서 접속했을때 favicon.ico를 그룹아이디로 인식하게 만들어버리기 때문이다.

이는 codeigniter를 사용하면서 서버에서 rewrite모듈을 사용했기때문이다.

즉 특수한 경우에 발생하는 현상인 것이다.

스티븐 스필버그 감독은 영화 <뮌헨>을 발표한 후 알고 지내던 유태인 친구를 여러 명 잃었다고 고백했다. 영화 속에서 주인공은 이스라엘 정보기관 모사드의 도움을 받아 폭탄 제조, 문서 위조, 사건 뒤처리 등의 다양한 재주를 가진 6명의 요원으로 팀을 구성한 다음, 1972년 뮌헨 올림픽 선수촌에서 테러를 일으킨 검은 9월단의 배후 요원들을 한 명씩 살해한다.

하지만 시간이 흐르면서 주인공을 비롯한 요원들은 국가를 위한 복수와 비인도적인 살인 행위 사이에서 갈등을 겪게 되고 스스로의 생명마저 위협받자 깊은 회의에 빠져들게 된다. 스필버그 감독은 인간적인‘갈등’과‘회의’를 그렸을 뿐인데 열혈 유태인들은 그것조차 용납하기 어려웠던 모양이다.

아무튼 영화 속의 주인공은 복수의 대상 11명이 은거하고 있는 장소와 그밖에 필요한 정보를 얻기 위해서 일종의‘정보 브로커’와 거래를 한다. 그에게 거액의 돈을 주고 살해할 대상이 숨어 있는 장소에 대한 정보를 얻는 것이다. 재미있는 점은 주인공의 복수가 진행되는 동안 다른 나라의 정보조직에서도 똑같은 정보 브로커에게 접근해서 주인공과 동료들의 신원을 파악하려고 한다는 점이다. 이름도 없고, 얼굴도 없어서 어느 누구에게도 존재가 드러나지 않아야 하는 정보조직 세계의 요원들이 이렇게 ‘정보 브로커’라는 존재를 통해서 오히려 하나의 지점에서 만나는 현상이 벌어진다.

상황중심이란 개념 이해하기

이렇게 다양한 독립적인 개체들이 자신의 목적을 위해서 공통적으로 통과할 수밖에 없는 지점, 혹은 수행할 수밖에 없는 행동을 상황중심 프로그래밍(Aspect Oriented Programming)에서는 접점(join point)라고 부른다.‘ 상황중심’이란 요즘 프로그래밍 세계에서 주목을 받고 있는 ‘Aspect Oriented’라는 표현을 나름대로 우리말로 옮겨본 것이다.‘ Aspect Oriented’라는 말이 국내에서는‘관점 지향’이라는 말로 표현되기도 하는데, 이것은 그 동안 ‘Object Oriented’를‘객체 지향’이라고 불러온 관성의 영향인 것으로 생각된다.

사실‘관점 지향’이라는 말은 의미가 분명하지 않을 뿐만 아니라 겉으로 드러나는 의미조차 정확하다고 보기 어렵다. ‘관점’을‘지향’한다니? 프로그래밍을 수행하는 사람이 자기 관점을 분명히 세우고 그것을 목표로 전진하라는 말인가?‘ 관점 지향’이라는 말이 국내 프로그래머 사이에서 일정한 합의를 이루고 있는 표현이라면 어쩔 수 없지만, 최소한 이 글에서는‘Aspect Object’를‘상황중심’으로 표현하고자 한다. 이렇게 해야 새로운 방법론이 전하고자 하는 의미가 분명하게 드러나기 때문이다.

상황중심 프로그래밍은 말 그대로 현재의 소프트웨어 코드가 처해 있는 특정한‘상황’에 초점을 맞추는 프로그래밍을 의미한다. 폭발적으로 늘어나는 수요를 감당하지 못해 심각한 위기를 맞이했던 소프트웨어 개발시장은‘모듈(module)’과‘객체(object)’라는 혁명적인 개념을 발견하면서 위기를 극복했다. 방대한 분량의 소프트웨어 코드를 모듈과 객체라는 작고 독립적인 부분으로 분리할 수 있었기 때문에 프로그래머들은 점점 더 복잡한 업무를 수행하는 코드를 만들어 낼 수 있었던 것이다. 하지만 독립적인 모듈과 객체의 수마저 기하급수적인 규모로 증가하면서 예전과는 전혀 다른 문제가 대두되었다.

모듈과 객체는 코드를 추상적이고 부분적인 캡슐로 분리해서 전체적인 코드에 대한 관리가 가능하도록 만들고 필요하면 재사용 할 수 있는 방법까지 제공했다. 즉 모듈과 객체는 코드의 부분을 떼어내서 추상화하는 방법을 제공한 것이다. 하지만 이러한 방법은 모듈과 객체를 가로지르며 존재하는 공통의 관심사(cross-cutting concern)를 효율적으로 추상화하는 방법은 제공하지 않았다. 공통의 관심사란 보안(security), 성능(performance), 기록(logging)과 같은 소프트웨어의 일반적인 속성에서부터 데이터 캐시(cache) 관리나 네트워크 프로토콜의 구현처럼 구체적인 기능에 이르기까지 다양하다.

이러한 공통의 관심사는 특정한 모듈이나 객체가 구현하는 기능에 국한되는 것이 아니라 소프트웨어 시스템 전체에 걸쳐 수평적으로 영향을 미친다. 잘 이해가 되지 않는 독자는 다음 예를 생각해 보면 도움이 될 것이다.

공통의 관심사

인터넷 붐이 한창이던 90년대에 미국에서는‘수평적 시장(horizontal market)’과‘수직적 시장(vertical market)’이라는 표현이 자주 사용되었다. 수직적 시장이란 어떤 제품이 특정한 분야의 시장에 국한되는 경우를 의미한다. 예를 들어서 책, 의류, 자동차, 컴퓨터, 혹은 의료보험 시스템 등은 다른 분야와 겹치지 않는 자기 자신만의 시장을 형성한다.

이들은 모두 수직적 시장의 예이다. 하지만 웹브라우저와 같은 소프트웨어는 특정한 시장에 국한되지 않고 모든 수직적 시장들 사이에 공통적으로 존재하며 영향을 미친다. 그 자체로는 특정 품목에 대한 시장을 형성하지 않지만 여러 시장에서 동시에 존재하는‘공통의 관심사’가 되는 것이다.

영화 <뮌헨>에서 이스라엘의 모사드, 소련의 KGB, 미국의 CIA, 팔레스타인의 검은 9월단 등은 각자 겹치지 않는 고유의 영역을 구성하고 있지만, 그들이 어떤 인물의 은신처를‘검색’하기 위해서는 다양한 정보를 보유하고 있는‘정보 브로커’를 찾아가야만 했다. 각 국의 정보기관이 수직적 시장을 형성하고 있다면,‘ 정보 브로커’는 웹브라우저와 마찬가지로 수평적 시장을 형성하고 있는 셈이다. 이 경우에‘정보 브로커’는 여러 정보기관들을 가로지르며 공통적으로 존재하는‘공통의 관심사’로서의 역할을 담당한다.

오늘날의 프로그래밍 세계에서 수직적 시장을 구성하는 존재는 말할 것도 없이‘객체’들이다. 객체들은 저마다
주어진 일감을 구현하면서 일이 서로 겹치지 않도록 소프트웨어의 전체 영역을 분할한다. 이렇게 분할을 더욱 효율적으로 만들기 위해서 비슷한 일을 하는 객체를 한곳에 묶어서‘패키지(package)’라고 부르기도 한다. 지금까지 프로그래밍은 이러한 분할을 통해서 충분히 잘 이루어져 왔다.

하지만 이렇게 역할 분담을 통한 균형과 평화가 이루어진 상황에서도 여러 객체 사이에 존재하는‘공통의 관심사’는 존재하기 마련이다. 앞에서 예로 든 보안, 성능, 기록, 캐시, 프로토콜 등이 바로 그들이다. 이밖에 유닛테스트(unit test)나 테스트 자동화 등도 여기에 포함될 수 있을 것이다.

좀 더 이해를 돕기 위해서 하나의 구체적인 상황을 생각해보자. 소프트웨어의 사용자들이 항상 그렇듯이 개발자가 개발한 시스템을 이용하는 사용자 중에는 구체적인 데이터를 제시하지 않으면서 말로만“시스템이 느려 터졌다.

답답해서 못 쓰겠다.”라고 불평을 늘어놓는 사람이 있다. 소프트웨어를 제작하고 관리하는 입장에서는 이렇게 막연하게 불평만 늘어놓는 사용자처럼 속상한 존재가 없다.

구체적으로 어떤 기능을 사용할 때‘느린지’를 알아야 그가 겪고 있는 문제가 PC 하드웨어와 관련된 문제인지, 개발자가 만든 소프트웨어의 문제인지, 네트워크의 문제인지, 혹은 서버나 데이터베이스의 문제인지를 알 수 있고 그에 따른 해결책을 제시할 수 있기 때문이다(물론 사용자가 허락만 해준다면 그가 소프트웨어를 어떻게 사용하는지 직접 관찰할 수도 있을 것이다. 하지만 성격이 곱지 않은 월스트리트의 트레이더에게‘저는 소프트웨어를 제작한 사람인데요, 잠시 옆에서 PC를 사용하는 모습을 관찰해도 될 까요’라고 묻는 것은 자살 행위이다).

그렇지만 사용자가 데이터를 제공해 주지 않는다고 해서 손을 놓고 있을 수는 없으므로 우리는 필요한 데이터를 스스로 구해야 한다는 결론을 내리게 되었다. 그리하여 우리가 구현하기로 한 기능은 사용자가 소프트웨어에서 어떤 동작을 수행할 때마다 맨 처음 GUI의 이벤트 처리 메소드(event handler)에서 출발해서 서버와 데이터베이스에 이르는 과정에 존재하는 각 계층을 통과하는 데 걸린 시간을 측정한 다음 로그 파일과 같은 하나의 장소에 기록하는 것이었다.

스파이로그

사용자가 GUI 화면에서 주식이나 채권 가격 같은 데이터를 입력하고 OK 버튼을 눌렀다고 해보자. 그러면 소프트웨어의 흐름은 GUI 계층, GUI 계층 아래에 존재하는 네트워크 계층, 실제 네트워크 전송, 서버에서 사용자의 요청을 받아들여서 적절한 컴포넌트( component)에게 전달하는 계층, 데이터베이스에 저장되어 있는 프로시저(stored procedure), 최종적인 데이터를 담고 있는 응답객체를 생성하는 계층, 응답 객체를 GUI 클라이언트에게 전송하는 계층, GUI가 서버의 응답을 받아서 처리하는 계층 등을 차례로 통과한다.

이 때 각 계층에서 소요된 시간을 측정해서 하나의 객체에 저장하는 것이다. 이렇게 처리시간이 기록된 객체는 각 계층을 통과할 때마다 다음 계층에게 전달되면서 값을 축적해 나간다. 필요한 처리 과정이 모두 끝나고 나면 이 객체에 저장된 값은 미리 지정된 포맷에 따라서 로그 파일에 기록되고 객체의 수명은 끝이 난다.

이제 사용자가 시스템의 성능에 대해서 밑도 끝도 없는 불평을 늘어놓으면 로그 파일에 저장되어 있는 데이터를 분석해서 실제로 성능에 문제가 있었는지, 만약 문제가 있었다면 어느 계층에서 문제가 있었는지를 파악할 수 있다.

이렇게 유용한 기능의 이름을‘스파이로그’라고 불러보자. 앞의 설명을 읽으면서‘흠 소프트웨어의 여러 계층을 관통하는 <공통의 관심사>를 설명하려고 애쓰고 있군’하고 생각하는 독자가 있다면 만점이다. ‘공통의 관심사(crosscutting concern)’라는 개념을 이해했다면 상황중심 프로그래밍의 98%를 거의 이해한 것과 다름이 없다.

이러한 스파이로그를 실제로 구현하는 방법은 어렵지 않다. 소프트웨어가 객체지향 기법에 따라서 계층별로 잘 분리되어 있다면 더욱 그러하다. 각 계층의 시작과 끝 부분에서 시간을 측정하는 데 필요한 동작을 수행하기만 하면 되기 때문이다. 하지만 그것이 가능하기 위해서는 최소한 두개의 전제 조건이 필요하다. 하나는 스파이로그를 구현하는 프로그래머가 각 계층의 입구와 출구를 정확하게 파악하고 있어야 한다는 점이고, 두 번째는 스파이로그를 구현하기 위해서는 입구와 출구에 해당하는 객체의 소스 파일이 수정되어야 한다는 점이다. 즉, 입구에 해당하는 위치에서는 앞의 계층에서 전달한 시간 측정용 객체를 받아들인 다음 들어온 시간(time stamp)을 찍고, 출구에 해당하는 위치에서는 같은 객체 위에 나가는 시간을 찍고 나서 뒤에 있는 계층에게 객체를 전달해 주는 것이다.

이런 방법은 기능적으로는 아무런 문제가 없지만 코드의 관리라는 측면에서 보면 문제가 많다. 한 가지만 예를 들자면 이런 식이다. 시스템에 A, B, C, D라는 네 개의 계층이 존재한다고 하자. 하나의 동작(operation)이 완성되려면 A, B, C, D, C, B, A라는 완성된 사이클이 그려져야하고, 스파이로그는 이러한 일곱 단계가 소비하는 시간을 각각 측정해서 기록한다.

그런데 나중에 누가 C 계층을 리팩토링해서 그것을 C1과 C2라는 두 개의 계층으로 분리했다고 가정해보자. 그리고 스파이로그의 존재를 의식하지 못한 그가 C1이 받아들인 객체를 C2에게 전달하는 것을 깜빡 잊었다고 하자. 이와 같은 본의 아닌‘실수’가 도입되는 순간 C1과 C2 사이의 고리가 끊어지면서 스파이로그의 기능은 동작을 멈출 수밖에 없다.

여러 계층이 공유하고 있는‘공통의 관심사’가 단지 한계층에서 발생한 실수 때문에 완전히 동작을 멈춘다는 것은 공정하게 들리지 않는다. 뿐만 아니라 스파이로그의 기능이 여러 소스 파일에 분산되면서 코드의 관리가 어려워진다는 단점도 존재한다. 이러한 상황은 서로 독립적으로 분할되어 있어야 하는‘객체’라는 존재를 중심으로 하는 프로그래밍 방법론으로는 명쾌하게 해결되기 어렵다.

객체는 본질적으로 다른 객체와 나란히 서 있도록 만들어진 존재이지, 다른 객체의 허리를 가로지르며 직교(orthogonal)하도록 만들어진 존재가 아니기 때문이다. 바로 이와 같이‘난처한 상황’에서 힘을 발휘하는 것이‘상황중심’의 프로그래밍이다.

제록스 팔로알토연구소에서 탄생

상황중심 프로그래밍이라는 개념은 제록스 팔로알토 연구소에서 탄생한 것으로 알려져 있다. 현재 캐나다의 브리티시 콜롬비아 대학의 컴퓨터 사이언스 교수인 그레고르킥잘레스(Gregor Kiczales)는 팔로알토 연구소에서의 연구를 확장해서 현재 상황중심 프로그래밍 세계에서 대표적인 언어로 인정받고 있는 AspectJ를 설계했다. IBM에서도 HyperJ나 관심 변경 환경(Concern Manipulation Environment)과 같은 상황중심 프로그래밍 언어를 발표했지만, 현재 프로그래머 사이에서 널리 받아들여지고 있는 언어는 단연 AspectJ이다.

상황중심 프로그래밍에서 사용하는 개념은 크게 네 가지가 있다. 접점(pointcut), 안내(advice), 내부타입 선언(inter type declaration), 그리고 이들을 모두 묶어서 하나의 단위로 추상화하는 상황(aspect)이 그들이다. 상황중심 프로그래밍이나 이러한 개념들이 의미하는 바는 AspectJ의 홈페이지 등에서 쉽게 접할 수 있다. AspectJ에 대한 책도 이미 적지 않게 나와 있다. 여기에서 이들이 의미하는 바를 간단하게 살펴보자면 이렇다.

우선 접점(pointcut)은 공통의 관심사가 여러 개의 객체나 계층을 가로지를 때 그들과 만나게 되는 지점을 의미한다. 앞에서 살펴본 예에서는 각 계층의 입구와 출구가 접점에 해당하고, 더 앞에서 든 예에서는 모사드, CIA, KGB의 요원들이‘정보 브로커’와 만나는 상황 자체가 접점에 해당할 것이다. 접점은 상황중심 프로그래밍을 수행하는 프로그래머가 이미 존재하는 소프트웨어 시스템을 이해하고 있는 수준, 혹은 핵심을 짚어내는 안목에 따라 제대로 짚어질 수도 있고, 엉뚱한 곳이 접점으로 인식될 수도 있다. 어쨌든 프로그래머가 일단 접점을 골라냈으면 그 다음에 할 일은 그 곳에서 할 일을 정의하는 것이다.

그것이 안내(advice)이다. 상황중심 프로그래밍에서 안내는 객체지향 프로그래밍에서의 메소드에 해당한다고 생각하면 쉽다. 특정한 접점에 이르기 직전이나 혹은 직후에 어떤 일을 할 것인가를 정의하는 알고리즘이 안내의 내용을 이룬다.

내부 타입 정의(inter type declaration)는 약간 복잡하다. 이것은 자바 프로그래밍과 같은 기존의 프로그래밍 방식에 익숙한 사람들에게 개념적인 혼란을 초래하기 때문이다. 자바 언어를 예로 들자면, 어느 객체에게 새로운 인스턴스 변수(instance variable) 혹은 필드(field)를 추가하는 것은 언제나 소스 코드의 수정과 컴파일을 통해서 이루어진다.

프로그램이 실행되고 있는 도중에 새로운 필드를 내 마음대로 추가할 수는 없는 것이다. 자바 런타임(runtime) 내부에서 클래스 이름만 가지고 클래스의 인스턴스를 만들어내는 기능은 있지만 클래스에 이미 정의되어 있지 않은 필드를 더하는 기능은 없다.

그런데 상황중심 프로그램에서 사용하는‘내부 타입 정의’기능은 객체에게 새로운 필드를 동적으로 더하는 것을 가능하게 만든다. 이러한 기능이 필요한 이유는 이미 존재하는 다양한 객체와 계층을 가로지르면서 동작하는 알고 리즘을 작성하기 위해서는 주어진 객체의 정해진 틀을 뛰어넘는 능력이 필요하기 때문일 것으로 추측된다. 사실 필자 역시 상황중심 프로그래밍에 익숙하지 않기 때문에 섣불리 말하기는 어렵지만, 이러한 기능이 바람직한지에 대해서는 의문이 든다.

상황중심 프로그래밍을 구사하는 프로그래머가 어느 객체에게 내부 타입 정의 기능을 이용해서 동적으로 어떤 필드를 추가했다고 해보자. 그는 객체를 정의하고 있는 클래스에 새로운 필드를 사용하는 알고리즘을 추가할 수도 있다. ‘( 내부 타입 정의’기능을 통해서 추가한 필드가 퍼블릭으로 정의되어 있다면 기존의 자바 코드에서 접근하는 것이 가능하기 때문이다.)

이렇게 작성된 소스 코드를 나중에 읽는 다른 프로그래머는 (특히 그가 상황중심 프로그램의 존재를 인식하지 못하고 있다면) 도대체 이 코드가 사용하고 있는 필드가 어디에 정의되어 있는 것인지 알 길이 없다. 이런 식의 혼란은 미묘한 버그의 원인이 될 수 있다.

이런 측면에서 보자면 내부 타입 정의를 이용하는 것은 멀쩡한 객체에게 뼈를 깎고 살을 붙이는 성형수술을 시도하는 것, 혹은 객체의 유전자를 조작해서 없던 장기를 만들어 내는 것에 비유할 만하다. 수술이나 유전자 조작이 필요한 결과를 낳는다면 다행이지만, 잘못된 결과를 낳거나 그것이 남용된다면 차라리 하지 않느니만 못한 일이 될 것이다.

마지막으로, 객체지향 프로그래밍에서 클래스가 변수와 메소드를 한 곳에 묶어서 하나의 객체로 추상화하듯, 상황중심 프로그래밍에서 사용되는 접점, 안내, 내부 타입 정의를 한 곳에 묶어서 추상화하는 것은‘상황(aspect)’이다. 따라서 상황은 객체지향 프로그래밍에서 객체가 중심에 서있듯이 상황중심 프로그래밍에서 가장 중심에 서있는 개념이 된다(이것은 프로그래머들이 혐오하는‘중복’된 표현처럼 들린다. 하지만 달리 표현할 방법이 없다. 상황중심 프로그래밍에서 중심은 상황이기 때문이다).

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

출처 - ZDNet