iPhone쪽에는 초보인지라 거창하게도 초보를 위한 책이 있어서 하루만에 읽어 보았습니다.

그책은 로리 루이스의 ‘완전 초보를 위한 아이폰&아이패드 앱 개발’이었습니다.

성질이 급한편이라 책을 여러날을 두고 읽지 못하는 관계로 하루에 다 읽어보았는데,

말은 초보를 위한 책이라고 하지만, 정작 진정한 초보에게는 어울리지 않는다는 느낌을 받았습니다.

정서가 다른탓도 있겠지만, 책을 위트있게 만들려고 노력한 흔적은 있으나, 정확하게 무엇을 전달하고자 하는지 알맹이가 빠진느낌이랄까?(번역의 문제일까요? 잘모르겠습니다.-_-)

암튼, 내용자체가 어려운 주제를 다루고 있는 것이 아니라 무언가가 빠진채로 내용이 전개되고 있는 것입니다.  과연 이책을 저처럼 진정한 초보(?)가 무리없이 다 소화할 수 있을까요?

책을 덮고 곰곰히 생각해 보니 빠진것은 바로 Objective-C에대한 이해였습니다.

이책에서는 Objective-C에 대한 이야기를 거의 다루지 않습니다. 저자는 Objective-C에 대한 것은 기본으로 깔고 책을 읽기를 원하는 것 같았습니다.(물론 책에서는 그것을 강요하고 있지는 않지만, 책을 다 본 후의 내 느낌은 그랬습니다)

해서, 사무실 한켠에 꽃혀있지만, 거들떠도 보지 않던 마크 달림플, 스콧 내스터가 지은 “Objective-C 2.0″책을 보기로 맘을 먹었습니다.

처음에는 “Objective-C”를 따로 공부해야 할 필요는 없고 바로 iPhone개발서적을 보면서 간간히 나오는 정보를 바탕으로 개발을 하면 되겠지라는 아주 초보틱한 생각을 가지고 있었던 것이 사실입니다.

바보같았지요. 다른 어떤책이나, 블로거들이 말하던간에 iPhone앱을 개발하고자 한다면 Objective-C에 대한 공부를 선행해야 합니다.

이 책도, 하루에 다 읽었습니다. 무척 흥미진진하더군요. 책 겉표지와는 다르게 내용이 알기쉽게 잘 설명이 되어 있는 것 같았습니다. 물론 기존에 C 또는 C++ 하다못해 Java와 같은 언어에 대한 경험이 있다는 전제하에 그렇습니다. (경험이 충분하면 할수록 더 쉽게 이해할 수 있을 것 같습니다)

이책에서는 언어 자체에 대한 설명은 없기때문이지요. 저의 경우에는 제가 경험했던 여러 언어들의 특성과 책의 내용에서 이야기하고자 하는 Objective-C의 특성들을 비교하면서 아주 재미있게 끝까지 읽어 볼 수 있었습니다.

암튼, 이책은 강추입니다. (아마 Objective-C에 관련한 서적은 거의 이책외에는 없는 것 같습니다만..)

먼저 이책을 읽어 본 후에 다른 개발서적을 보는 것이 좋을 듯 합니다.

서두에 소개해 드린 책을 다시 읽어보니 이제는 아주 명확히 이해가 되더군요. 쩝..

암튼, 2일정도만 투자하면 기본적인 iPhone개발에 필요한 개념 및 문법은 숙지하실 수 있겠습니다.

그런 후에 다시 다음의 애플의 공식사이트에서 공부하시면 좋겠다라는 생각이 듭니다.

The Objective-C Programming Language

iPhone Application Programming Guide

iPhone Human Interface Guidelines

내가 이놈을 기다린 이유는 다름이 아니라 시급히 iPhone 어플을 개발해야 하기 때문입니다.

개인적이유로 사무실을 행신으로 이전한 후 집에서 쉬는 동안 Object-C에 대한 공부를 하고 있던 참입니다.

문법을 대충 살펴보고 어느정도 이해가 끝나니 실제로 테스트해 보아야 하는데 맥이 없으니 그것도 어렵더군요. 그래서 오매불망 이 녀석을 기다렸더랬습니다.

아래에 이녀석의 사진을 첨부합니다.

iPhone개발에 필요한 SDK를 다운받고 있는 모습을 찍었습니다.

빛이 좀 있어서 그런지 사진이 그닥입니다.(갤럭시 S로 찍었습니다)

사실, 맥북은 처음이라서 그런지 무척 어색할 것으로 생각했는데, 그닥 부담스럽지 않더군요.

화면도 미려하고 이쁜것이 iPhone이 그냥 생긴것이 아니더군요.

하지만, 초보자에게는 생소한 부분도 많고 처음 동봉된 케이스 안에 있는 도움말들이 크게 도움은 안되는 것 같더군요.

바로 막 사용하기에는 버거운 느낌이~.. 암튼 개발에 앞서서 맥에 대한 공부부터 먼저 해야 하겠습니다.

요새는 안드로이드 개발에 필이 꽃혔네요. 얼마전까지만해도 WPF개발에 매력을 느끼고 한참 몰두했었는데… 역시 대세는 모바일 그중에도 스마트폰인가 봅니다.

제가 임베디드 플랫폼에 발을 담그기 시작한 것은 2003,4년쯤 되는 것 같습니다.

그전에는 순수소프트웨어 개발만 하다가 처음으로 PDA OS포팅등 디바이스 드라이버개발을 시작했던 것 같습니다. 그후 몇년간 외국에서 리눅스 소프트웨어 개발만 하다가 다시 한국으로 와서 이제는 개발은 손을 떼고 관리자(?)/기획자로만 살아볼려고 했는데..

역시 송충이는 솔잎을 먹어야 탈이 나지 않나 봅니다.  다시 개발자로 이것저것 손을 대고 있습니다.

언제까지 이짓을 할 수 있을지 모르겠지만, 암튼, 다시 여러 플랫폼과 개발환경에 접하게 되니 예전에 잊어버렸던 새로운 기분? 신선감을 느낄 수 있어서 좋더군요.

이야기가 샜는데, 현재는 안드로이드로 간단한 어플을 개발중에 있는데, 참, 세월 좋아졌다는 생각이 많이 듭니다. 처음 접해보는 안드로이드는 아직 버그도 꽤 있는 것 같습니다만, 그럼에도 불구하고 상당히 발전해 있으며 개발환경도 매력적인 것 같습니다. 또한 응용프로그램의 경우 개발언어가 java로 되어 있다는 점이 처음 접하는 저도 아무런 어려움 없이 바로 개발 할 수 있도록 해 주는 군요.

개발환경의 완성도도 처음 우려했던 것 보단 훌륭한 편인 것 같습니다.

다만, OS자체의 버그등으로 인해서 단말기의 동작에 따른 원치 않은 결과가 발생하는 것들이 있더군요. 그러한 점은 테스트를 통해서 회피하거나 처리할 수 있는 수준이기는 하지만, 저처럼 처음 접하는 경우에는 모든 상황에 대해서 테스트를 해 보아야만 믿을 수 있다는 점이 좀 불안하기는 합니다.

하지만, 제가 처음 Wince기반 PDA를 개발하던 당시와 비교하면 하늘과 땅차이로 개발이 쉬워졌다는 점은 부인할 수 없네요.  속도도 만족스럽습니다. (제 개발환경은 NexusOne , 안드로이드 2.2입니다)

암튼, 앞으로의 성장이 기대되는 안드로이드입니다.

딸내미+아들내미

서진이와 준희의 더블샷입니다..

아들내미+쌍브이

준희의 단독샷입니다. 사진을 찍을라고 하면 꼭 저렇게 눈이 사라져 버리네요. 진을 찍을때면 아예 찡그려 버리는 듯이 보입니다.  헌데 가르쳐주지도 않았는데 쌍브이를 그리는 모습이 혹시 천재가 아닐런지..???

그건 그렇구, 넥서스원의 카메라 성능은 참 맘에 듭니다. HTC사의 카메라가 예전부터 성능이 좋은 것을 경험적으로 알고 있었지만, 이번 넥서스원의 카메라는 반응속도라던지 이미지의 질도 모두 나무랄데가 없을 정도로 맘에 듭니다. 제가 기존에 쓰던 T옴니아와는 비교할 수 없는 성능을 보여주네요.

드디어 옴니아를 버려야 할 시점이 된 것이 아닌지 모르겠네요.

개발을 진행중에는 그 어떤 것에도 신경이 쓰이지 않아서…

그런데, 우연히 틀어논 인터넷 음악방송에서 이 노래가 흘러나오는 것입니다.
‘One more time, One more chance’ 가수는 山崎まさよし이네요..

아마도 일본 애니메이션의 주제가였던 것 같습니다.
「秒速５センチメートル」인걸로 알고 있는데 저는 보지 못했습니다.
대신, 마눌님이 보는 것을 어깨너머로 목격했을 따름입니다..ㅎ..

어쨌든 넘 서정적인 느낌의 노래이네요.

왜 요즘의 한국에서는 이런 서정적인 노래를 기대할 수 없을까요?

これ以上何を失えば 心は許されるの
どれ程の痛みならば もういちど君に会える
One more time 季節よ うつろわないで
One more time ふざけあった 時間よ

더 이상 무엇을 잃어야 마음은 용서받을 수 있는걸까
얼마 만큼의 아픔이라야 다시 한 번 너를 만날 수 있을까
One more time 계절이여, 변하지 말아줘
One more time 서로 장난을 치던 시간이여

くいちがう時はいつも 僕が先に折れたね
わがままな性格が なおさら愛しくさせた
One more chance 記憶に足を取られて
One more chance 次の場所を選べない

서로 엇갈릴 땐 언제나 내가 먼저 약해졌지
제멋대로인 성격이 더욱 사랑스럽게 느껴졌지
One more chance 기억에 발이 묶여버려
One more chance 다음 장소를 고를 수 없었지

いつでも捜しているよ どっかに君の姿を
向いのホーム 路地裏の窓
こんなとこにいるはずもないのに
願いがもしも叶うなら 今すぐ君のもとへ
できないことは もうなにもない
すべてかけて抱きしめてみせるよ

언제나 찾고 있지 어딘가의 너의 모습을
건너편 플랫폼, 뒷골목 쪽 창가
이런 곳에 있을리 없지만
만약 바람이 이루어 진다면 지금 바로 너의 곁으로
불가능한 건 이미 아무것도 없어
모든 것을 걸고 끌어안아줄게

寂しさ紛らすだけなら
誰でもいいはずなのに
星が落ちそうな夜だから
自分をいつわれない
One more time 季節よ うつろわないで
One more time ふざけあった時間よ

허전함을 달래는 것 뿐이라면
누구라도 좋았을텐데
별이 떨어질 것 같은 밤이라
나를 속일 수 없었지
One more time 계절이여, 변하지 말아줘
One more time 서로 장난을 치던 시간이여

いつでも捜しているよ どっかに君の姿を
交差点でも 夢の中でも
こんなとこにいるはずもないのに
奇跡がもしも起こるなら 今すぐ君に見せたい
新しい朝 これからの僕
言えなかった「好き」という言葉も

언제나 찾고 있지 어딘가의 너의 모습을
교차로에서, 꿈 속에서도
이런 곳에 있을리 없지만
만약 기적이 일어난다면 지금 바로 너에게 보여주고 싶어
새로운 아침 앞으로의 내 모습
말하지 못했던 “사랑해”라는 말도

夏の想い出がまわる ふいに消えた鼓動

여름의 추억이 맴돌고 문득 사라진 고동 소리

いつでも捜しているよ どっかに君の姿を
明け方の街 桜木町で
こんなとこに来るはずもないのに
願いがもしも叶うなら 今すぐ君のもとへ
できないことはもう何もない
すべてかけて抱きしめてみせるよ

언제나 찾고 있지 어딘가의 너의 모습을
새벽녘 거리, 사쿠라기쵸에서
이런 곳에 올리 없지만
만약 바람이 이루어 진다면 지금 바로 너의 곁으로
불가능한 건 이미 아무것도 없어
모든 것을 걸고 끌어안아줄게

いつでも捜しているよ
どっかに君の破片を
旅先の店 新聞の隅
こんなとこにあるはずもないのに
奇跡がもしも起こるなら 今すぐ君に見せたい
新しい朝 これからの僕
言えなかった「好き」という言葉も

언제나 찾고 있지
어딘가의 너의 조각들을
여행지의 가게, 신문 한 구석
이런 곳에 있을리 없지만
만약 기적이 일어난다면 지금 바로 너에게 보여주고 싶어
새로운 아침 앞으로의 내 모습
말하지 못했던 “사랑해”라는 말도

いつでも捜してしまう どっかに君の笑顔を
急行待ちの 踏切あたり
こんなとこにいるはずもないのに
命が繰り返すならば 何度も君のもとへ
欲しいものなど もう何もない
君のほかに大切なものなど

언제나 찾으려 하지 어딘가의 너의 미소를
급행을 기다리는 철도 건널목 근처
이런 곳에 있을리 없지만
내 삶이 반복된다면 몇 번이라도 너의 곁으로
원하는 것 따윈 이젠 아무것도 없어
너 외에 소중한 것 따윈 없어

헌데, 아들 녀석이 계속 한쪽눈을 찡그리는 것이었습니다. 해서 두눈 다 뜨고 있으라고 했더니 옆에 있던 딸래미가 손으로 아들눈을 띄우려고 하더군요.
그때, 갑자기 녀석이 울기시작해서 한 10분을 우는 것이었습니다..
영문을 모르겠기에 엄마에게 물어보라고 했더니 이유인즉, 자신은 윙크를 했는데 아빠가 눈뜨라고 말해서 서러워서 그랬다는 것입니다.
아이들에게는 별것도 아닌 것이 큰일이 되나 봅니다. ^^;
아래는 그 사건의 사진입니다.

파마하기전의 모습

파마한 준희와 누나 서진이

눈뜨라고 했다고 우는 준희와 재미있어 하는 서진이

침대위에서 서럽게 우는 준희

사실 12월 6일에 일본어능력시험1급을 보았는데 준비도 하지 못했고 그 흔한 시험공략을 위한 책이나 모의고사도 본적이 없이 무작정 본 시험이라 기대를 하지 않았었습니다.

그래도 혹시나 하는 두근두근한 마음으로 시험결과를 조회해 본 결과!! 이게 웬일입니까?  합격이 되었습니다.

뭐, 아직 확실하게 합격통지서가 오지는 않았지만 , 다행스럽게도 합격커트라인은 넉넉하게 넘은 점수를 받았습니다.

그닥, 공부를 하지는 못했지만, 그래도 일본 컨설팅회사에서 4년이나 근무하면서 그래도 나름대로 열심히 살았다고 생각했는데 정말 나의 일본어 실력은 어떨까 하는 의문이 항상 따라 다녔습니다.

사실, 정식으로 일본어를 배운 것도 아니고 사전하나 그리고 문법책하나를 가지고 일본에서 생활하면서 공부한 것이라 막상 시험을 볼 생각을 하니 걱정이 많이 되었습니다. 

그래도 자신감을 가지고 시험에 임한것이 도움이 된 것 같습니다.

시험 당일을 회상해 보자면 정말 제가 준비한 것이 없이 갔다는 생각이 들었습니다.

총 문제가 몇문제이고 각 교시마다 몇분인지도 모르고 갔으니까요..

그 흔한 모의고사 문제도 한 번도 풀어보지 못했습니다.

청해문제가 나왔을 때는 지문이 없고 문제번호만 있어서 당황했던 기억이 납니다.

어떠한 시험이라도 사실 요령이 필요한데 너무 그런것이 없어던 것이지요.

문제가 어떻게 나오고 시간배분을 어떻게 해야 하는지에 대한 정보가 하나도 없었기에 처음 시험지를 보고서는 한참을 문제유형 파악하느라 멍하게 있었습니다.

그럼에도 합격할 수 있었던 것은 시험을 위한 준비는 아니지만 그래도 꾸준히 일본어잡지등을 읽어보려고 노력했던 것이 도움이 되지 않았나 싶습니다.

어휘는 역시 노력에 비례하는 것이기 때문이지요.

사실 일본어자격시험을 봐야겠다는 생각은 예전부터 가지고 있었지만 선뜻 실천에 이르지는 못했습니다.

능시라는 것이 일년에 한번 내지 두번 있는 것인데, 제가 일본에 있었기에 굳이 필요성을 강하게 가지지는 못했었기 때문이며 , 일본에 산지 한 1,2년 되었을 때 잠시 한국에 와서 능시1급 문제집을 서점에서 본 후로 너무 어려워서 깜작 놀랐던 기억이 있었기 때문입니다.

사실, 직장에서 그리고 일상생활에서 사용하는 어휘는 한계가 있으며 익숙해 지면 익숙한 단어와 문형만을 사용하기 때문에 학술적으로 접근하는 것과는 괴리가 있는 것 같습니다.

물론, 고급스러운 어휘와 서적을 읽기위해서는 단순히 일본에서 생활한다 또는 생활해봤다는 것과는 차원이 다른 노력이 필요하지요.

암튼,  마음의 짐을 하나 내려놓은 듯한 후련한 마음이 듭니다.

2009년의 마지막날에 극적으로 한가지 즐거운 추억과 기억을 가지게 되어서 기쁨마음으로 올해의 마지막 포스트를 써봅니다.

이러한 경우에는 하드한 해결방법으로는 JDBC 드라이버를 직접 수정해 주는 방법이 있으며 , 소프트한 방법으로는 <resultMap>을 이용하는 방법이 있습니다.
하드한 방법은 DBMS 별로 JDBC 드라이버를 수정해야 하는 불편이 있으므로 별로 추천하지 않습니다.

저는 <resultMap>을 사용하는 것을 추천합니다. 물론 조금 귀찮기는 하지만 <resultMap>을 사용하면 property에 지정한 컬럼명을 Key로 설정해 주기 때문에
대소문자문제는 고민을 하지 않아도 됩니다. 또한 명시적으로 레코드타입을 설정이 가능하기 때문에 가능하다면 <resultMap>을 사용하는 것이 좋겠습니다.

예를 들어 본다면 아래와 같은 설정으로 리턴되는 값들은 모두 대문자로 출력됩니다.

* sqlMap 설정

<select id=”getUser”  parameterClass=”java.util.HashMap”  resultClass=”java.util.HashMap”>
     select   user_id , user_name  FROM   user_list  WHERE  user_id = #user_id# and user_pass = #user_pass#
</select>

* 결과값

Key = USER_ID , Value = coyote
Key = USER_NAME , Value = 승냥이

하지만, <resultMap>을 사용한다면 우리가 원하는 형태로 리턴값을 조절 할 수 있습니다.
 
* sqlMap 설정

<resultMap id=”user.info”>
      <result property=”user_id”      column=”user_id”/>
      <result property=”user_name”    column=”user_name”/>
</resultMap>

<select id=”getUser”  parameterClass=”java.util.HashMap”  resultMap=”user.info”>
    select   user_id , user_name  FROM   user_list  WHERE   user_id = #user_id# and user_pass = #user_pass#
</select>

* 결과값

Key = user_id , Value = coyote
Key = user_name , Value = 승냥이

AOP가 필요한 이유를 설명하기 전에 일반적인 형태의 프로그램을 작성하는 방식을 살펴보겠습니다.

우리가 은행업무를 위한 프로그램을 작성한다고 가정해 보겠습니다. 은행업무에는 기본적인 입/출금업무가 있을 것이고 계좌이체업무도 있을 것입니다. 이러한 업무들이 바로 은행업무에 있어서 본질적인 비즈니스 기능이라고 할 수 있을 것입니다. 하지만, 이런 업무들만 있는 것은 아니지요. 누군가 돈을 찾아갔다면 그 정보도 남겨야 할 것이고 ID도용이 발생했다면 원인을 밝혀내야 하며, 온라인 뱅킹이 발생했다면 정상적으로 거래은행에 입금이 되었는지도 체크해야 합니다.

이와같이 은행업무를 위한 프로그램에는 핵심 비즈니스 기능뿐 아니라 부가적이라고 말할 수도 있는 보안, 인증, 로그 , 중복체크등과 같은 기능들도 통합되어 있어야만 비로소 완전하게 구현되었다고 말할 수 있습니다. 어쩌면은 은행 본연의 업무를 위한 코드들보다 부가적인 측면을 다루는 코드가 더 많아질수도 있겠습니다.

하지만 이 부가적인 기능을 다루는 코드는 비즈니스 로직과는 상관관계가 없는 경우가 많아서 여러업무에 중복적으로 사용되는 것이 일반적이지요. 보통 개발이 진행되면 진행될수록 사실 핵심 비즈니스로직보다는 이러한 부가적인 처리에 사용되는 코드가 문제가 되기도 합니다. 시스템 전체에 걸쳐서 사용되고 있기 때문에 수정도 힘들고 관리도 힘들게 됩니다.

AOP세계에서는 상기 설명했던 기능중에서 비즈니스로직을 구현한 기능들을 Primary(Core) concern이라고 부릅니다. 보안, 인증, 로그등과 같은 부가적인 기능으로서 시스템 전반에 산재되어 사용되는 기능들은 Cross-cutting concern이라고 부르고 있습니다. 바로 AOP의 핵심이 여기에 있습니다. 바로 AOP는 우리에게 있어서 골치거리인 Cross-cutting concern을 어떻게 다룰 것인가에 대한 새로운 패러다임을 제고하고 있습니다.

사실 AOP가 등장하기 전에는 Primary concern과 Cross-cutting concern이 같이 하나의 프로그램에 구현되어져 왔습니다. 당연히 비즈니스 로직과 상관없는 코드들이 여기저기 산재해 있게 되었기에 가독성과 유지보수성에 악영향이 있을 수 밖에 없었을 것입니다. 생산성 저하와 비용증가는 당연한 결과였겠지요.

하지만, AOP세계에서는 다릅니다. AOP는 Primary concern과 Cross-cutting concern을 별도의 코드로 구현합니다. 최종적인 프로그램은 이 둘을 조합하여 완성하게 되는 것이죠. 이것은 하나의 프로그램에 각각의 코드들이 혼재해 있는 것과는 명확히 다른 것입니다. 사실 이렇게 되기를 많은 개발자들이 마음속으로 바래마지 않았을 것이지만 그 방법을 몰랐었습니다. AOP는 모든 개발자들이 바랬던 이상을 구현해 놓은 것에 불과(?)한것이지요.

이제, AOP세계에서 새로운 용어들이 등장하게 되었습니다. 바로 Advice와 Code , Point-Cut 그리고 Weaving입니다.

Code는 Primary(Core) concern을 구현해 놓은 코드를 이야기합니다. Advice는 Cross-cutting Concern을 구현한 코드를 지칭하고 있습니다. 그럼, Point-cut은 무엇일까요? 바로 Advice와 Code를 연결해주는 설정 정보를 말합니다. 다시 말하면 Point-cut은 Code의 어느 위치에 Advice를 위치할 것인가에 대한 것입니다. 마지막으로 Weaving은 이 둘(Code와 Advice)를 조합하여 완성된 어플리케이션을 만드는 과정을 이야기합니다.

정리해 볼까요?

• Code : Primary(core) concern을 구현한 코드
• Advice:  Cross-cutting concern을 구현한 코드
• Jointpoint:Code와 Advice를 연결해주는 설정 정보, Advice가 적용 가능한 지점(메소드 호출, 필드값 변경)
• Point-cut: Jointpoint의 부분집합으로서 실제 Advice가 적용되는 Jointpint
• Weaving : Code, Advice, Point-cut등을 조합하여서 어플리케이션을 만들어 가는 과정

이 용어들을 이해하는 것으로도 벌써 AOP세계의 절반은 여행하셨다고 볼 수 있습니다. 사실 이 용어를 이해한다면 AOP는 그닥 어려운 것이 아닐 수 있습니다. 따라서 위의 용어들은 반드시 숙지하시길 권면드립니다.

그럼 왜 AOP(Aspect Oriented Programming)이라고 하는 걸까요?

AOP의 Aspect는 Advice와 Point-cut을 함께 지칭하는 단어입니다. 따라서 AOP는 Advice와 Point-cut에 대한 이야기를 하고 싶었던 것이네요.

Spring의 AOP패키지는 이러한 AOP개념을 멋드러지게 구현한 것으로서 그 배경에는 IoC 또는 DI가 자리하고 있습니다.

Spring AOP도 여러 AOP 프레임워크중의 하나입니다. 따라서 나름의 특징이 있습니다. 간단히 소개를 해보자면 다음과 같습니다.

• 자체적인 프록시 기반의 AOP 지원

필드값 변경과 같은 Joinpoint는 사용할 수 없고 메서드 호출 Joinpoint만 지원합니다. Spring AOP는 완전한 AOP를 지원하는 것이 목적이 아니라 엔터프라이즈 어플리케이션을 구현하는데 필요한 정도의 기능 제공을 목적으로 하고 있습니다.

•  Spring AOP는 자바 기반

AspectJ는 별도의 문법을 알아야 하지만 Spring AOP는 자바를 기반으로 하고 있기때문에 다른 언어를 익힐 필요가 없습니다.

Spring AOP는 내부적으로 프록시를 이용하여 AOP가 구현되기 때문에 메서드 호출에 대해서만 AOP를 적용할 수 있다는 점이 아쉬운 점이라고 할 만하지만, 크게 문제될 것은 없다는 개인적인 생각입니다.