검색결과 리스트
글
Spring
Spring이란 무엇인가?엔터프라이즈 어플리케이션에서 필요로 하는 기능을 제공하는 프레임 워크이다.
J2EE에서 제공하는 다양한 기능 뿐만 아니라, DI, AOP와 같은 기능도 지원하고 있다.
특징
1. 스프링은 경량 컨테이너 이다.
스프링은 자바 객체를 담고 있는 컨테이너이다. 스프링은 이들 자바 객체의 생성, 소멸과 같은 라이프 사이클을 관리하며, 스프링으로부터 필요한 객체를 가져와 사용할 수 있다.
2. 스프링은 DI패턴을 지원한다.
스프링은 설정 파일을 통해서 객체간의 의존 관계를 설정할 수 있도록 하고 있다. 따라서 객체는 직접 의존하고 있는 객체를 생성하거나 검색할 필요가 없다.
3. 스프링은 AOP를 지원한다.
스프링은 자체적으로 AOP를 지원하고 있기 때문에 트랜잭션이나 로깅 보안과 같이 여러 모듈에서 공통적으로 필요로 하지만 실제 모듈의 핵심이 아닌 기능들을 분리해서 각 모듈에 적용할 수있다.
4. 스프링은 POJO를 지원한다.
스프링 컨테이너에 저장되는 자바 객체는 특정한 인터페이스를 구현하거나, 클래스를 상속받지 않아도 된다. 따라서 기존에 작성한 코드를 수정할 필요없이 스프링에서 사용할 수 있다.
5. 트랜잭션 처리를 위한 일관된 방법을 제공한다.
JDBC를 사용하든, JTA를 사용하든 또는 컨테이너가 제공하는 트랜잭션을 사용하든, 설정 파일을 통해 트랜잭션 관련 정보를 입력하기 때문에, 트랜잭션 구현에 상관없이 동일한 코드를 여러 환경에서 사용할 수 있다.
6. 영속성과 관련된 다양한 API를 제공한다.
스프링은 JDBC를 비롯하여 iBatis, 하이버네이트등 데이터베이스 처리와 관련하여 널리 사용되는 라이브러리와의 연동을 지원하고 있다.
7. 다양한 API에 대한 연동을 지원한다.
스프링은 JMS, 메일, 스케쥴링등 엔터프라이즈 어플리케이션을 개발하는데 필요한 다양한 API를 설정 파일을 통해서 손쉽게 사용할 수 있도록 하고 있다.
8. 자체적으로 MVC프레임워크를 제공한다.
때문에 스프링만 사용하면 MVC기반의 웹어플리케이션을 어렵지 않게 개발할수 있다.
Spring Framework의 설치와 모듈 구성
1. http://Springframework.org/download 에서 최신 버전을 다운 받는다 (현재: 2.5.6)
2. 압축을 푼다
dist폴더 : 스프링 Jar파일을 포함하고 있는 폴더
lib폴더 : 스프링을 사용하는 필요한 모든 외부 라이브러리를 포함하고 있는 폴더
docs폴더 : 스프링 레퍼런스 및 API Javadoc를 포함하고 있는 폴더
DI(Dependency Injection과 Spring Framework)
객체사이의 의존 관계를 객체끼리 직접하는것이 아니라, 외부 조립기가 수행한다는 개념
의존 관계 처리 방법 3가지
1. 코드에 직접 의존 객체 명시 AbstractDAO dao = new LoginDAO();
2. Factory 패턴이나 JNDI등을 사용해 클래스를 명시 (EJB같은곳에서 사용)
AbstractDAO dao = DAOFactory.create();
3. 외부 조립기를 사용 (Dependency Injection - DI 패턴 ~Inversion of Control)
외부 조립기를 사용하는 이 방법은 불필요한 의존 관계를 없애주는 좋은 방법이다.
DI패턴을 이용하면 직접적으로 객체에 의지 하지 않고 인터페이스에만 의존하게 된다.
DI패턴 적용 두가지 방법
1. 생성자 방식을 이용하여 설정
2. 설정 메소드를 이용하여 설정 (setter)
2. 스프링 설정 파일을 이용하여 의존 관계 설정(applicationContext.xml))
<bean name="writeArticleService"
class="kame.spring.chap01.WriteArticleServiceImpl">
<constructor-arg>
<ref bean="articleDao" />
</constructor-arg>
</bean>
<bean name="articleDao"
class="kame.spring.chap01.MysqlArticleDao">
</bean>
의 의미는
MySqlArticleDao articleDao = new MyArticleDao();
WriteArticleServiceImpl writeArticleService = new WriteArticleServiceImpl (articleDao);
위와 같은 xml 선언을 통해 WriteArticleServiceImpl객체와 MySqlArticleDao객체 사이의 의존 관계를 설정하였다.
//이렇게 설정하면 스프링 컨테이너로 부터 빈 객체를 가져와서 사용 할 수 있다.
Resource resource = new ClassPathResource("applicationContext.xml");
BeanFactory beanFactory = new XmlBeanFactory(resource);
WriteArticleService articleService =
(WriteArticleService) beanFactory.getBean("writeArticleService");
articleService.write(new Article);
이것을 제어 역행이라고 하는데, 스프링 프레임 워크의 핵심이다.
의존성을 띄는 객체를 내가 생성하는 것이 아니라,
내가 주입 받는것이다. 따라서 내가 원래 그 객체를 생성하고 살리고 하는 주제 제어자 였는데,
Dependency Injection에 의하여 내가 주입을 받는 대상자가 되어 버렷다.
따라서 저어가 역행하게 된것이다.
결합된 코드 즉, 밀접하게 연관이 된 코드는 테스트하고 재 사용할 시 어려우며 이해하기도 어렵다. 때문에 결합도를 낮추어서 의존하는 객체들 간 협업을 조정하는 책임이 객체 자체로부터 분리되어 나간 것을 말한다.
스피링에서의 AOP
1. POJO기반 AOP적용
기존에 우리는 특정 클래스(객체)를 공통적으로 사용할 필요성이 있을 때
특히 보안, 트랜잭션, 공통 기능(Common Class, Common Method같은 것들)을 여러 개의 서로 다른 객체들에서 접근하여 사용하려 할 때 일일이 생성하고 메소드를 불러서 써야 했다.
예를 들어 사용자가 입력한(이름, 주소, 학력, 각종 개인정보에 대하여 각기 다른 필드를 통해서 입력을 받을때) String객체를 암호화 하는 프로세스를 가진 간단한 프로그램이 있다고 가정할때, 각각의 정보들에 대하여 일일이 암호화하는(동일한 암호화 알고리즘으로..) 프로세스를 거쳐야 한다 (적절한 예인지는 잘 모르겠다;;) 생성된 객체에 대하여 일일이 메소드에 해당 값을 집어 넣은후 받아 와야 하는 번거로움이 생기며, 복잡한 의존성을 불필요하게 가지게 된다. 만에 하나 갑작스러운 요구 사항의 변경으로 필드를 하나 추가하거나, 필드를 삭제하게 될 때 해당 메소드를 부르는 작업을 추가 하거나 삭제 해야 한다. (깜빡하고 삭제하지 않으면 당연히 엑셉션이 발생하게 된다)
이는 매우 비 효율적인 것 임에 틀림없다.
때문에 나온 것이 AOP라는 기법이다.
AOP(Aspect Oriented Programming)란 공통 관심사항에 대하여 발생하는 복잡성과 코드 중복을 해소해 주는 프로그래밍 기법이다.
여기서 중요한 개념이 Aspect인데, 이 Aspect가 공통 모듈을 로직을 구현할 클래스에 적용된다.
(써놓고 보니 매우 난해하다;;;)
한마디로 말해 공통 관심사에 관해서 공통 관심사를 사용할 객체들이 직접 공통 관심사(공통 객체)를 생성 접근하는 것은 프로그램의 복잡도를 증가 시키고, 코드를 중복 시키고 결합도를 높여 객체지향적이지 못해지는 요인으로 작용하므로, 그렇게 하지 말고( 공통 관심사를 사용할 놈들이 직접 생성해서 지지고 볶고 하지 말고) 외부에서 따로 이쁘게 처리하자~! 이말이다.
예를 보자
<공통 관심사 클래스> - 아래의 클래스가 우리가 공통 관심사로서 사용할 클래스 이다.
public class LoggingAspect {
private Log log = LogFactory.getLog(getClass());
public Object logging(ProceedingJoinPoint joinPoint) throws Throwable {
log.info("기록시작);
StopWatch stopWatch = new StopWatch();
try {
stopWatch.start();
Object retValue = joinPoint.proceed();
return retValue;
} catch (Throwable e) {
throw e;
} finally {
stopWatch.stop();
log.info("기록종료);
log.info(joinPoint.getSignature().getName() + "메소드실행시간: "
+ stopWatch.getTotalTimeMillis());
}
}
}
그렇다면 이놈을 일일이 사용할 다른 여러 객체들에서 접근하지 말고 어떻게 쓸까?
<bean id="logging" class="kame.spring.chap01.LoggingAspect" />
<aop:config>
<aop:pointcut id="servicePointcut" expression="execution(* *..*Service.*(..))" />
<aop:aspect id="loggingAspect" ref="logging">
<aop:around pointcut-ref="servicePointcut" method="logging" />
</aop:aspect>
</aop:config>
이렇게 하면, expression="execution(* *..*Service.*(..))" />에 의해서 Service로 끝나는 인터페이스를 구현한 객체들에 대하여 우리의 공통 관심사 객체가 적용이 되게 된다.
음 . . 보다 자세한 내용은 좀 더 공부 해보아야 겠다 . 일단 DI와 AOP맛보기는 끝~!
(출처 및 인용 : 최범균님의 Spring 2.5 Programming, Spring in Action이 참 이해하기 쉽게 잘되어 있다 두책을 번갈아 보면서 공부하면 매우 효율적이다. 그리고 나는 가메 출판사에서 나오는 관련 전공 서적들에 항상 매력을 느낀다 . . Struts때도 그랫고 . . EJB3.0도 그렇고 . .)
설정
트랙백
댓글
글
네이트는 이 서비스를 선보인 이후 지난 주 창사이래 처음으로 통합검색 점유율이 10%를 넘겼습니다. 네이트 홍보팀은 요즘 경마중계하듯 매주 자사 검색점유율 상승분에 대해 보도자료를 배포하고 있습니다. 네이트가 최근 얼마나 고무돼 있는지 보여줍니다.
하지만 네이트의 시맨틱 검색 기술에 대해서는 많이 알려지지 않은 것 같습니다. 언뜻 보기에는 단순한 서비스인 것처럼 보이지만, 이 서비스에는 검색엔진 및 자연언어처리 업계가 지난 10년동안 연구해온 결과물이 반영돼 있습니다.
시맨틱 검색이라는 말은 ‘시맨틱 웹’에서 차용된 용어입니다. 시맨틱 웹을 기술적으로 이해하려면, 온톨로지∙RDF 등의 용어를 알아야 합니다. 쉽지 않은 일이죠. 온톨로지는 컴퓨터가 인간의 인식 능력과 유사한 기능을 하도록 하기 위해 만들어 놓은 거대한 데이터셋이라고 이해하면 될 것 같습니다.. 시맨틱 웹은 XML 기반의 마크업 언어를 기반으로 하며, RDF라는 구조를 기반으로 합니다.
이렇게 쓰기는 했지만, 사실 저도 자세히 모르는 내용입니다.
하지만 네이트의 시맨틱 검색에 온톨로지, XML, RDF 등의 기술이 반영된 것은 아닙니다. 때문에 엄밀히 말해서 네이트의 시맨틱 검색은 흔히 얘기하는 ‘시맨틱’은 아니라고 볼 수 있습니다.
그렇다고 해서 네이트의 시맨틱 검색을 무시해도 좋다는 것은 아닙니다. 온톨로지∙XML∙RDF 등의 방법론을 사용하지는 않았지만, 사용자의 검색의도를 파악하려는 시도, 단순 키워드 비교가 아닌 문장과 문서의 의미 분석 결과를 검색 결과에 반영하는 시도 등은 시맨틱웹의 접근 방법과 같습니다. 방법론만 다른 것이지요.
네이트 시맨틱 검색기술을 개발한 코난테크놀로지는 시맨틱 검색에 대해 “문장이나 단락에 기술된 주제를 파악하고 이를 대상으로 검색하는 것”이라고 정의했습니다.
네이트의 시맨틱 검색 서비스는 크게 ▲검색주제 ▲즉답 ▲주제별검색으로 나뉠 수 있습니다. 사용자가 검색어를 입력하면 검색한 사람이 관심있을 법한 검색주제가 왼편에 나타나고, 그 속성에 대한 ‘즉답’이 오른편에 나타납니다.
예를 들어 ‘이명박’이라는 검색어를 넣으면 공약, 당선이유, 경력 등의 검색주제가 나오며, 공약이라는 검색주제에 대한 ‘즉답’으로 ‘국민소득 4만불’, ‘7% 성장’ 등이 나오는 구조입니다.
이용하는 사람들은 대단치 않게 느낄지 몰라도, 이 정도 수준의 결과를 보여주기 위해서는 상당한 수준의 기술이 필요하다고 합니다.
이 같은 서비스를 위해 어떤 기술이 사용됐을까요? 우선 코난테크놀로지는 1만개 정도의 검색주제를 데이터베이스로 갖췄습니다. 사용자들이 검색어를 입력하면, 1만개의 검색주제 중 검색어와 맞는 검색주제를 찾아내 보여줍니다.
검색 키워드가 정치인과 관계된 것이라면 발언, 공약, 측근 등의 검색주제를 골라내고, 검색 키워드가 연예인이라면 데뷔정보, 신체사항, 소속사 등의 검색주제를 자동적으로 찾아냅니다. 검색어가 질병이라면 소개, 원인, 증상 등의 검색주제가 나옵니다.
이 같은 검색주제가 추출되면 그 주제에 맞는 즉답을 찾아야 합니다. ‘이명박’이라는 검색어에 대한 검색주제로 ‘공약’이 추출됐다면, 그에 맞는 ‘4만 달러 달성’이라는 답을 찾아야 하는 것입니다.
만약 구글 검색엔진이라면 ‘이명박 공약’을 검색했을 때 이명박과 공약이라는 단어가 포함된 문서를 보여줄 것입니다.
하지만 시맨틱 검색에서는 직접 ‘국민소득 4만불’ ‘7% 경제성장’ 등의 정답을 찾아내기 위해 노력합니다.
이를 위해서는 문서의 구조를 파악하고, 문장의 구문과 의미를 분석하는 기술이 필요합니다. 문장의 의미를 분석해 속성을 정의해 나가야 합니다.
예를 들어, ‘이순신은 인종 1년인 1545년 4월 28일 서울 건청동에서 태어났다’는 문장을 만나면 시맨틱 검색엔진은 이순신 출생일과 이순신 출생지를 파악할 수 있습니다.
‘이순신’이라는 메인 키워드를 중심으로 ‘1945년 4월 28일’에 ‘(이순신) 출생일’이라는 검색주제를 부여하고, 서울 건청동을 ‘(이순신) 출생지’라는 검색주제로 분류할 수 있습니다. 이는 ‘태어나다’라는 동사를 보고 판단하는 것입니다.
사람은 인지능력이 있기 때문에 이런 파악이 너무 쉽지만, 인지 능력이 없는 컴퓨터가 이를 파악하기 위해서는 무수한 부수정보가 필요합니다.
컴퓨터가 볼 때 ‘태어났다’는 글자는 단순 문자열에 불과합니다. 그냥 0과 1의 조합일 뿐입니다.
하지만 ‘태어나다’라는 동사 앞에 시간이 오면 출생일, 지역이 오면 출생지라는 속성을 부여토록 미리 정의할 수 있습니다. 이를 위해 자연언어처리 기술이 필요합니다. 형태소분석, 구문분석, 의미분석 등 다양한 절차를 거칩니다.
이는 결코 쉽지 않은 일입니다. 컴퓨터가 이해할 수 있는 사전(Lexicon)을 구축해야 하고, 분석할 수 있는 규칙도 있어야 합니다. 수학적 통계를 이용하기도 합니다.
쉽지 않은만큼 당장 완벽한 검색 결과를 제공하는 것은 불가능합니다. 실제로 네이트 시맨틱 검색은 아직 적지 않은 오류를 보이고 있습니다.
예를 들면 ‘신동엽’이라는 검색어를 입력하면 데뷔작 이라는 검색주제에 ‘남자셋 여자셋’이 나옵니다. 이건 잘못된 결과입니다. 신동엽씨는 남자셋여자셋이라는 시트콤보다 훨씬 먼저 데뷔했습니다. 코너 제목은 잘 기억이 안나지만 1990년대 초반 SBS 개국 당시 ‘안녕하시렵니까’라는 유행어로 혜성처럼 등장했던 것 같습니다.
그렇다면 네이트 시맨틱 검색은 왜 신동엽씨 데뷔작이라는 속성에 대해 남자셋여자셋이라는 즉답을 내놓았을까요? 아래 문장을 보면 납득이 갑니다. 검색엔진은 아래 문장을 보고 신동엽 데뷔작은 남자셋여자셋이라는 판단을 내렸습니다.
이날 신동엽은 시트콤 '남자셋 여자셋'으로 데뷔해 신인인 송승헌과 호흡을 맞출 당시를 회상하며, "신인이었던 송승헌이 도가 지나치게 잘생긴 외모에, 도가 지나치게 연기를 못해 두 번 놀랐다"고 말하며 좌중에 웃음을 던져주었다.
문장이 4중 복문으로 구성돼 있군요. 문장이 너무 복잡해서 시맨틱 검색엔진이 문장을 잘못파악한 것입니다. 이 문장을 볼 때 사람은 “남자셋 여자셋은 송승헌씨의 데뷔작”이라는 것을 금방 알 수 있지만, 컴퓨터한테는 아직 쉽지 않은 일입니다.
우리가 복잡한 영어문장 해석에 어려움을 겪는 것과 같은 이치입니다. ‘직관’이 없기 때문이죠.
하지만 점점 더 기술이 발전하면 이런 오류는 차츰 줄어갈 것입니다. 네이트 시맨틱 검색도 아직 완벽하지는 않습니다. 하지만 점점 더 좋아질 것으로 믿습니다.
설정
트랙백
댓글
글
네이트는 연초부터 베타 테스트를 하던 시맨틱 검색 기능을 오픈했다. 이 기법은 구문이나 문장 분석에서 중요 주제어를 추출하고, 이에 대한 값을 찾는 자연어 처리기술을 도입했다.
따라서 블로그, 게시판과 같은 구조화되지 않은 텍스트를 대상으로 주제 분류와 예상 답변을 제시하는 방식으로 그 뼈대는 일반적인 텍스트 기반 정보 검색(IR) 기법을 기반으로 하고 있다. 주제어 제시 방식이 마치 의미 기반 정보를 찾아 주는 것으로 보여 시맨틱이란 용어를 쓰는 듯 하다.
그런데, SK컴즈의 보도 자료를 보면 '시맨틱 웹'이라는 생뚱 맞는 내용을 등장시켜 혼란을 주고 있다.
시맨틱 검색은 1998년 시맨틱 웹이 주창되면서부터 차세대 검색서비스로 주목받으며 전세계적으로 연구개발이 진행되고 있는 분야이다. MS의 Bing이나 구글의 스퀘어드(Squared) 검색도 시맨틱검색의 일종이다. 국내에서는 솔트룩스나 시맨틱스가 시맨틱 검색을 개발하고 있다. 이같은 방식은 하키아(Hakia)와 파워셋(Powerset) 등 해외 시맨틱 검색 업체들이 개발했으나 실험실 단계에서 오픈해 아직 포털에 적용되지는 못했다.
정보 검색에 대한 두 가지 접근에서 보다시피 네이트가 이용한 (시맨틱) 기술은 전산학에서 꽤 오래된 분야로서 텍스트 분석, 자연어 처리, 기계 학습과 같은 분야는 인공 지능 분야에서 시맨틱 기술을 말하는 것이다.
하지만, 시맨틱 웹은 이와 완전히 다른 접근이다. 시맨틱 웹은 웹을 데이터 단위로 구조화 시켜상호 관계성을 파악하려는 시도 즉, 웹을 데이터베이스화 혹은 지식 기반으로 만들고 이를 기반으로 추론을 목표로 한다. (물론 웹을 이렇게 만드는 것은 완벽히 실패했다.)
다행히 위키피디아를 통해 웹에서 구조화된 데이터가 가능 하다는 것을 보여준 이후, 이를 RDF 방식으로 변환 시킨 DBPedia라는 프로젝트로 인해 크게 바뀌었다. LinkedData라고 불리는 이름으로 RDF 기반으로 데이터 웹을 구조화 시키거나 RDFa나 마이크로포맷 같은 방식으로 HTML 의미 마크업을 시도하고 있는 것이다.
따라서 이 두 가지를 어느 정도 분리해서 이야기해야 혼란을 피할 수 있다. 네이버의 이준호 박사님이 지난번 인터뷰에서 시맨틱 웹 검색 기술에 대해 의아하게 여긴것도 이 때문이다.
시맨틱 검색 계획은 어떤가? “시맨틱 웹이라는 건 연구자마다 정의가 다양해서..그래서 시맨틱 웹이라고 할 때 그것이 정확히 뭘 의미하는지 사실 잘 모르겠다. 의미 연관 검색그런 방식의 이 가장 시맨틱 검색에 근접한 정의일 텐데 그런 의미 기반 검색은 60년대부터 있었다. 이후 풀 텍스트 검색으로 많이 전환 됐다. 현재 알려진 것 중 마이크로소프트의 ’빙‘이 시맨틱 방식일 건데 우리도 검토하고 있기는 하다.온톨로지 검색 차원에서 노력하고 있다.”
네이버에서 온톨로지 검색 차원에서 노력한 결과로 나온 것이 영화 시맨틱 검색이다. 영화 콘텐츠 DB의 관계성을 RDF로 추출(Exporting)한 후 URI를 기반으로 그래프를 따라 의미를 쫓아가는 방식이다.
이와 같은 시맨틱 웹 검색 방식은 구조화된 지식을 담고 있는 그릇이 필수적이다. 포털의 경우, 영화나 음악 같은 DB를 RDF로 관계를 정하고 이를 URI 기반으로 사용자 콘텐츠와 유기적으로 엮음으로서 좀 더 의미적인 시맨틱 웹 검색이 가능할 것이다.
아직까지 기존 텍스트 기반 웹 검색에서 출발한 '시맨틱 검색'과 웹을 DB로 보고 이를 의미 기반으로 연결할 '시맨틱 웹 검색' 어느쪽이 성공할지는 알 수 없다.
하지만, 개인적으로는 후자가 좀 더 웹에 어울리는 것이 아닌가 싶다.
그러기 위해서는 사람들의 집단 지성에 의한 콘텐츠 저작 방식과 협업을 통한 지식 기반 구축이 가능하다는 것을 전제로 해야 한다. 위키피디아가 아직까지 어려운 이유가 저작 방식에 있고 사용자들은 의미를 달리해서 정보를 저작하는 데 아직까지도 익숙치 않다.
2006년에 의미적 글쓰기(Semantic Writing)이라는 글에서 저작 기능에서 의미적 데이터를 구분해서 저장하는 도구의 중요성에 대한 이야기를 했었다. 지금의 오픈 API와 같은 데이터 저장소와 RDFa와 마이크로 포맷(혹은 HTML5의 Microdata)과 같은 시맨틱 마크업을 통해 가능하지 않을까 싶다.
웹의 발전이 사람의 손에 의한 것이었던 것처럼 시맨틱 웹 검색의 가능성 역시 사람에게 달려 있다.
RECENT COMMENT