Tuesday, June 30, 2009

[정보공유]「log4sql」의 소개

[정보공유]

[산소]로부터의 정보공유입니다.
java의 DAO계층에서 Statement로 쿼리를 부르는 경우, 정확히 어떤 쿼리가 전송되는지 로그를 남기도록 driver를 proxying하는 driver, 「log4sql」의 소개입니다.

http://log4sql.sourceforge.net/index_kr.html

한글, 일어의 페이지가 있습니다.(만, 일어페이지는 좀 깨져있군요)

비슷한 것으로 p6spy가 있습니다. p6spy가 더 많은 기능을 탑재하고 있다고 생각합니다만, 라이브러리 평가페이지 jars.developer.com에서 Top 25% Rated의 평가를 받고 있네요.
살펴볼만한 가치가 있다고 생각합니다.

이상.

Sunday, June 28, 2009

best practice of designing DAO

best practice of designing DAO

지금까지의 경험을 정리하는 것입니다만, DAO의 구축에 대해 한 번 알고 있는 모든 것을 동원해 "어떻게 하는 것이 좋은 지"에대해 한 번 생각해 보고자 합니다.
Database를 이용하는 우선 설계의 방식에는 여러가지가 존재할 수 있습니다. 각각 모두, 요구되는 '기록과 열람'이라는 내용은 만족합니다. 그러나 어떤 것이 왜 좋은지 알 지 못한다면 곤란합니다.

우선은 기본적인 Data의 설계는 각 프로젝트별로 맡기고, 여기에서는 공통적으로 다루어야 할 issue에 대해서만 촛점을 둡니다만, DB의 모델링에 대해서는 다양한 시스템에 대한 설계의 경험을 쌓아야 합니다.

각 프로젝트별로 필요한 필드의 추출, 추출방식은 도메인 모델을 기준으로 하던지, use case를 기준으로 해도 문제가 되지 않습니다. 또한 generalizing과 degeneralizing도 어느쪽에 비중을 더 크게 두더라도 틀린 것은 아닙니다. 오히려 어느쪽에 비중을 더 두었는 지를 보고, 어떤 기능이 들어가는지 기획을 짐작할 수 있습니다.
리소스에 여유가 있다면, Fetch용 Database와 DML용 Database를 따로 두는 것도 가능합니다. 이런 경우의 Database의 설계는 일반적인 경우와 많이 다른데, 일반적인 경우만 다루어본 사람이 이러한 구조를 알지 못한 채, 이런 ERD를 만나면, "DB를 잘 알지 못하는 사람이 작성했나보군"하고 생각할 지도 모릅니다.

공통적으로 다루어야할 Database의 설계에 대한 Issue로 여기고 있는 것은 다음과 같습니다. 안전한 Data의 취급이 무시되어야 하는 시스템은 없을 것입니다.
다음에 적는 것들은 없어도 기록의 출입을 구성하기에는 문제가 없습니다만, 고려해 보아야 할 내용들입니다.

1) Optimistic Lock
2) Trigger를 이용한 Update Delete시의 Transaction Table에의 기록.
3) Procedure를 이용한 DML(plus DML query의 실행제한)

Optimistic Lock은 시스템의 구성에 따라 꼭 필요하기도 하고, 없어도 상관없는 경우가 있습니다. Transaction의 기Term이 긴 시스템이라면 반드시 필요합니다. 구현은 프로시저를 사용하지 않고 코드에서 구현한다면, 상당한 작업량이 될 수 있습니다. 만일 프로시저를 사용할 수 없다라면, OR-Map의 도입도 고려해 보는 것도 좋다라고 생각합니다.

Trigger를 이용한 Transaction을 Table에 기록하는 것은 고객의 동작을 기록해 놓는 것으로 , 안전성의 의미가 큽니다.

Procedure를 이용한 DML은 parameter check도 코드에서 하는 것이 아니라 procedure에서 하겠다는 얘기입니다. Data기록의 로직은 Database의 Procedure에 두겠다는 것은 한 가지 언어 이외에도 복수의 언어로 구성된 시스템에서 동일한 기록의 동작을 보장합니다.

이것은 DB에 매우 큰 로드를 걸지 않는 한, 매우 바람직합니다라고 생각됩니다만, 실제로 많이 사용되는 경우는 보기 어려웠습니다. 특히 Procedure를 사용하지 않고, Application서버가 여러대로 분산되어 있을 경우 부하를 DB보다는 Application서버에 두려 하는 경우, 또 OR-Mapper를 더 선호해서 이를 통한 DML 작업을 하는 경우가 이유로 많이 제시되곤 했습니다.
그러나 잘 생각해보면, Hibernate등의 OR-Mapper를 사용한다고 하더라도 Select에 대한 작업은 Cache Provider등을 사용해 이득을 볼 수 있지만, Insert Update Delete에 대한 작업이 그리 많이 이득을 볼 수 있는 시스템이라고 확실히 얘기할 수 있는 시스템은 많지 않은 것 같습니다.
Hibernate등을 선호하는 케이스라면, 시스템이 허용하는 한, 사용해도 좋다고 생각합니다.
이런 경우라면 insert update delete 명령어를 금지하면 안되겠지만, DBA계정이 아닌, Application이 사용하는 계정이라면 금지를 생각해보는 것도 가능할 지 모릅니다.(실제 그렇게 운영해 본 적은 없습니다만...)

아아.. 오늘은 이만 해야겠습니다.
이 문서는 완전한 것이 아니므로 추가될 것입니다.

Saturday, June 20, 2009

Today, I kicked a small project off for me.

오늘 부터 작은 실험을 시작하려고 합니다.
어떤 실험인가 하면, 가끔 적는 이 블로그에, 한글은 물론, 일본어와 영어로 적어보려고 합니다.

제가 적는 블로그는 회사의 업무시간 가운데에 적는 것이 많습니다.(그래서 매우 단편적이면서, 깊지 않은 내용들이 많습니다.)
그렇기 때문에 처음에는 하나의 언어로만 적어두었다가 나중에 나머지 언어의 내용을 추가해 적는 경우도 있을 것입니다.

이상한 문장도 많이 쓰고, 뜻이 잘 못 전달 되는 경우도 있을 것입니다.
하지만 몇 년 꾸준히 계속하면 큰 공부가 될 것으로 기대합니다.

방문해 주시는 분께는 한가지 부탁으로, 잘 못된 문장을 지적해 주시면 제게는 큰 공부가 될 것입니다.
아무쪼록 잘 부탁드립니다.

====

今日から自分のためにひとつの小さい実験を始めようと思います。
どんな実験なのかというと、たまに書くこのブログに、ハングルは勿論、日本語と英語も一緒に書いて見ようと思います。
私の書くブログは会社の業務時間の中に書くことが多いです。(それで非常に断片的だし、深くない内容が多いです。)
そうだから初めには一つの言語でだけ書き留めてから後で残り言語の内容を追加して書く場合もあるでしょう。

変な文章もたくさん書いてしまい、意味がよく伝えられない場合もあるでしょう。
しかし何年弛まず続けば大きい勉強になることで期待します。

訪問していただいた方にはひとつお願いがありまして、間違った文章を指摘していただければ、私には大きい勉強になると信じています。
なにとぞよろしくお願いいたします。

====

Today, I kicked a small project off for me.
to say what it is, it is writing my blog posts with Hangul (of course!), japanese and english at once.

I usually write my posts in working time( that's why they are piecemeal and outline-like)
so I might publish posts written with one language and add other languages later.

sentences will be wrong and ridiculous.
but I will hang on it for years and it will be a good study

to visitors, please leave your comment for me.
your little advice for my wrong english is great help
thank you.

Friday, June 19, 2009

groovy cgi

groovy파일을 cgi로 이용해 사용하는 장난(?)을 하다가, parameter를 받는 작업을 하던중, 제대로 처리하게 하지 못해서 애를 좀 먹었습니다.
한글이나 일본어가 깨지는 현상때문이었는데요. 파일도 utf-8(without BOM), 그리고 groovy.exe의 실행옵션에서 도움말에 있는 --encoding UTF-8 이나 -c UTF-8을 아무리 주어도 제대로 표시되지 않았습니다. 아파치의 설정이 잘못된 것인지도 보고, 옵션이 먹지 않는지 레지스트리의 .groovy파일 실행할 때 디폴트 옵션을 줘보기도 했습니다만, 해결은 다른 방법으로 되었습니다. 옵션에 -Dfile.encoding=UTF-8 을 주고 실행하는 것이었습니다.

아마도, 스펙대로라면 -Dfile.encoding=UTF-8 이 없어도 잘 표시되어야 할 것 같은데...., 잘 되지 않았습니다.


#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe -Dfile.encoding=UTF-8
//C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe -c utf-8 -D file.encoding=UTF-8

import java.net.URLDecoder;
def decoder = URLDecoder;

print "Content-type: text/html\n\n"
print "<html><head><meta content='text/html; charset=utf-8' http-equiv='Content-Type'/></head><body>"
def name='World'; println "Hello $name!"

/* == to show all env variables
def env = System.getenv()
for(k in env){
println(k)
} */

def __form = [:]
def arrykeyvalue
def strQueryString = System.getenv()['QUERY_STRING']
if (strQueryString != null) {
def arryForm = strQueryString.split('&')
arryForm.each {
arrykeyvalue = it.split('=')
__form.put(arrykeyvalue[0], arrykeyvalue[1])
}
}

__form.each {
print (it.key + ' = ' + it.value+ '<br>')
}

__form.each {
print (it.key + ' = ' + decoder.decode(it.value, "UTF8") + '<br>')
}

print "日本語 <br> "
print "한국어 <br> "
print "</body></html>"



html 태그가 있어 본문에 에러가 있다고 하니 일본어의 전각 괄호로 바꾸었습니다.
그리고 아래가 실행 내용입니다.




Wednesday, June 17, 2009

[정보공유] 윈도우즈환경에서 groovy로 cgi하기

최근에는 perl 프로젝트를 하고 있는 영향도 있지만, cgi의 재발견이랄까 재미를 느끼고 있는 것은 사실입니다.
도메인이니, 모델이니, DAO니 BL이니 하는 라이브러리를 만들고 난 뒤 여러 복잡한 프레임웍의 설정과 웹어플리케이션의 설정을 하고 나서야 페이지 하나를 볼 수 있는 엔터프라이즈급의 개발은 분명 가벼운 마음으로 할 수 있는 것은 아닙니다.
작은 프로그래밍을 가벼운 마음으로 해보기 부담스러운 것은 grails, gsp도 마찬가지에요. 그런의미에서 cgi는 상대적으로 부담이 적기 때문에 작은 프로그래밍을 해보기에는 적합합니다.

groovy로 cgi를 하는 방법은 전에도 한번 시도해보았었습니다만, 윈도우즈환경은 리눅스와 달리 groovy.bat 파일로 실행되는 결과를 output으로 보내기에는 적합하지 못했습니다. 왜냐하면 아파치 프로세스가 cgi용 파일을 만나면 그 파일을 열어 Shebang #! 을 보고 어떤 명령을 실행해서 값을 구할 지 처리하는 과정에서, cgi용 파일에 groovy.bat로 해석하라고 전달하게 되는데 ,
아파치 process가 groovy.bat test.goory 명령을 실행하면, 그 프로세스에 output이 return되어 지는 것이 아니라, bat파일을 해석하기 위해 %comspec%가 실행된 다음 그 프로세스안에서 다시 jre를 실행한 뒤 결과값인 output이 나오기 때문에, bat를 실행시킨 process에서는 output을 구할 수 없기 때문입니다.
Shebang을 사용하지 않고 AddHandler나 Registry에 Associated Application을 설정한 경우에도 잘 되지 못했습니다.
이야기가 길어졌습니다만, 결론은, 윈도우에서 제대로 groovy파일을 cgi로 사용하지 못했다. 라는 이야기 입니다.

반면 아마도 리눅스 환경에서는 -시도해 본 일은 없습니다만 - 아파치프로세스가 groovy 쉘 스크립트를 실행하여 output을 얻는 것은 특별히 문제가 되지 않을 것 같다는 생각이고, 또 그렇게 했다는 블로그를 본 적도 있습니다.

=============

그런데 최근 잠깐 살펴보니 Native Launcher 라는 것이 등장해 있었군요.
http://groovy.codehaus.org/Native+Launcher
groovy.exe를 바로 다운받을 수 있는 링크도 있습니다.

왜 groovy.exe를 사용해야 하는지 적어놓은 부분도 있습니다만, 여기에는 cgi 이야기는 없군요. (원래 할 수 있는 것을 제가 못해낸 건지도 모르겠습니다.)
어쨌든, 이 groovy.exe로 cgi설정을 해보았습니다. (apache와 groovy까지는 설치되어 있다고 가정합니다.)

groovy.bat 파일을 groovy.bat.old 로 옮기고,

httpd.conf 안에 LoadModule이 끝나는 곳에 다음 한 줄 추가

setEnv GROOVY_HOME c:\Progra~1\Java\groovy-1.6.0
(또는 PassEnv GROOVY_HOME 해도 되나요. 확인해 보지 않았습니다.)

그리고 .groovy파일 더블클릭하면 groovy.exe파일이 실행되도록 설정해 놓고. AddHandler는 특별히 추가하지 않았습니다.

그리고 다음과 같이 test.groovy cgi를 하나 만들고

#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe
print "Content-type: text/html\n\n"
def name='World'; println "Hello $name!"

실행해 보았습니다.


-_-)=b

HtmlBuilder까지 사용하는 것은 무난할 것 같습니다.

#!C:\Progra~1\Java\groovy-1.6.0\bin\groovy.exe
print "Content-type: text/html\n\n"

def writer = new StringWriter()
def builder = new groovy.xml.MarkupBuilder(writer)
builder.html(){
head(){
title("Groov'n with Builders"){}
}
body(){
p("""Welcome to Builders 101. As you can see
this Groovlet is fairly simple.""")
}
}
println writer.toString()


하지만 servlet이 아니므로 request나 response등의 객체는 사용할 수 없습니다. (사용하게 하려면 매번 web.xml을 읽어 ServletConfig를 new 하고, Servlet을 new하고... 해야 할 것 같습니다.)

앞으로 CGI방식으로 %ENV%에서 값을 받아오는 Method나 Class를 만들어보죠.

Monday, June 15, 2009

「폰더씨의 실천하는 하루」에서

「폰더씨의 실천하는 하루」에서

함께 어울리는 사람을 선택하는 과정에서 한 가지 염두에 둘 게 있다.
친구를 선택할 때에는 신중해야 한다는 것이다. 나는 사람들에게 종종 "당신이 생각하는 진정한 친구는 어떤 사람입니까?"라고 묻는다. 80퍼센트 이상의 사람이 "진정한 친구란 있는 그대로의 내 모습을 받아들이는 사람"이라고 답한다. 세상에! 이건 정말 위험한 발상이다. 동네 페스트푸드 식당의 아르바이트생은 있는 그대로의 내 모습을 받아들인다. 왜냐면 그는 나와 아무 관련이 없기 때문이다.
진정한 친구란 '나를 보다 높은 수준으로 끌어올려 주는 사람'이다. 그가 내 곁에 있음으로써 내가 보다 나은 사람이 될 수 있게 하는 존재다.

「폰더씨의 실천하는 하루」 Chapter "동료의 힘", 한글판 78페이지.

그리고 나는 여기에 매우 동의합니다.

김동현.

Sunday, June 14, 2009

[세상에 이런일이] 회의중 만들어낸 명령어

[세상에 이런일이]

금요일 회의중에 시스템 엔지니어 郷古상이 잠깐 기다려 보라며, 만들어낸 리눅스 명령행

for aln in `vzctl exec 200 "chkconfig --list | cut -f1 | sort | uniq | grep -v ":" | egrep -v '^$'"`;do vzctl exec 200 service $aln status > /dev/null 2>&1;ret=$? ;echo "$aln: $ret";done

한줄 명령이며 이 안에 외부 커맨드는 7개가 들어가 있습니다.
그리고 완벽하게 잘 실행되었습니다.

그는 이런 명령어를 그자리에서 만들어서 보여준, 내가 만난 두 번째 일본인입니다.

-_-)=b

Monday, June 8, 2009

어떤 방법(또는 어떤 라이브러리)이 좋은지 결정할 때.(git vs svn)

최근 git이 많이 쓰이고 있는데, svn과 비교해 어떤 장점이 있는지 궁금한 적이 있었습니다.
물론 공식 페이지도 열람은 해둡니다만 이 두가지에 대한 사용자의 경험을 보고 싶을 때가 있습니다.
이런 경우 나는 (앤드류가 자주 사용했던 방법을 따라서 하는데) A vs B 라고 하는 검색을 많이 합니다.
google의 search keyword입력창에서는 A vs ... 라고만 입력해도, 자동완성기능으로 비교가 되는 것들을 표시해 줍니다.주의해서 봐야 할 점은, 대게의 경우 양쪽 모두 advantage와 disadvantage를 가지고 있을 텐데, 한쪽에만 치우쳐서 얘기하는 것은 그다지 참고가 되지 않습니다.

다음은 가장 도움이 되었다고 생각하는 git과 svn의 비교 post입니다.
====
Well hard decision, I live in both worlds, currently I use svn as central repo and git mainly for versioning local repos.

Well both have their advantages and disadvantages. SVNs biggest disadvantage probably is the speed, and the model (which also is its biggest advantage for certain team structures)

Gits biggest problems are: Almost total lack of tool integration into existing tools. Rather unstable and not well integrated into Windows.

You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally. Git however has the bigger advantage of having a very compact meta format so this disadvantage basically is nullified unless you have a huge codebase with thousands of revisions! I would not despise one or the other.

I personally for a mixed team still would choose svn over git as it is currently, mainly due to the unpolished windows integration and lack of visual tool integration (yes git gui is known to me)
====

플러스, 최근에는 tortoisegit 이 나와 있습니다.

아. 결론으로는 지금은 svn, git은 좀 더 나중에... 라는 입장을 취하게 되었습니다.

groovy로 jude api를 이용하기

일본에서 java엔지니어에게 UML의 다이어그램을 그리라고 하면, jude-community를 꼽는 사람들이 많습니다. (윈도우즈 계열의 엔지니어라면 역시 visio를 사용하는 것 같습니다.)

jude-community는 무료이고, reverse engineering이 됩니다.
더 많은 기능을 지원하는 jude-professional도 있습니다만, 30일 평가판이후 라이센스 등록을 요구합니다.(그러나 실행하기 전에 시스템의 날짜를 평가판 사용기간의 날짜로 바꾸어 실행하는 것정도는 할 수 있네요)

자체로 몰론 GUI의 어플리케이션입니다만, 이 둘다 api를 제공하고 있습니다. 이 API로, save한 .jude파일을 읽거나 edit하는 것이 가능합니다. api는 jar의 형태로 제공하고 있습니다.
이를 사용해서 java로 save한 jude파일을 제어할 수 있습니다만, 이러한 작업이라면 역시 groovy를 사용하는 쪽이 더 매력적이라고 생각합니다.

다음은 groovy를 사용하여 jude의 api에 접근하는 방법을 나타냅니다.

우선 groovy를 실행할 때, API를 함께 load하도록 합니다.
>edit c:\Program Files\Java\groovy\conf\groovy-starter.conf
해서 다음을 추가

load /Progra~1/JUDE-P~1/*.jar


그리고 이하는 groovy script 소스입니다
class_listup.groovy


import com.change_vision.jude.api.inf.project.*
import com.change_vision.jude.api.inf.model.*

scriptName = System.getProperty("script.name")

if (args.length < 1) {
println "groovy ${scriptName} [jude fileName]"
return
}

def printClasses(packageObj) {
packageObj.ownedElements.each {
if (it instanceof IClass) {
println it.name
}
else if(it instanceof IPackage) {
printClasses(it)
}
}
}

def pro = ProjectAccessorFactory.projectAccessor
pro.open(args[0])

printClasses(pro.project)

pro.close()



제가 이 방법에 관심을 가지는 이유는, 바퀴를 재발명하지 않고, 잘 정의된 jude의 api를 이용하여, gui가 아닌 text 형태의 방식으로 쉽게 여러 아이디어를 구조화 하는데 도움이 될 수 있겠다고 생각해서 입니다. 아마 emeditor의 macro가 하나 더 증가 할 것 같군요. :)

Sunday, June 7, 2009

[정보공유] MySql의 Transaction의 주의점

[정보공유]

MSSql이나 Oracle은 Begin Transaction이 Stack처럼 움직이는 반면.

MySql의 Start Transaction은 Stack처럼 움직이는 것이 아니라 Flag가 서 있는 것처럼 움직이므로 중첩되지 않음.

다음과 같은 쿼리에서 주의할 것.
UpdateSomeTable set AField = 0;

Start Transaction;
UpdateSomeTable set AField = 1;
call usp_AProcedure /* <-- 이 안에서 커밋 */
RollBack;

이때 마지막의 RollBack해도 AField의 값은 0으로 돌아오지 않음.

Wednesday, June 3, 2009

[정보공유]Windows에서 80포트를 IIS와 Apache가 동시 사용하는 방법

[정보공유]Windows에서 80포트를 IIS와 Apache가 동시 사용하는 방법

80Port를 IIS와 Apache가 동시에 사용하려면 다음의 툴을 사용합니다.

Windows Server 2003 Service Pack1 32-bit Support Tools
http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en

실행은

c:\Program Files\Support Tooles>httpcfg.exe set iplisten -i 192.168.xx.xx<엔터>
HttpSetServiceConfiguration completed with 0.

2003용이지만 XP에서도 사용이 가능합니다.

이상.

Tuesday, June 2, 2009

오늘 utf8을 지원하는 윈도우즈용 그래픽 콘솔을 발견했습니다.

오늘 utf8을 지원하는 윈도우즈용 그래픽 콘솔을 찾았읍니다. 현재로서는 이것이 무료로 사용할 수 있는 유일한 방법인 것 같습니다.
이 콘솔은 다름아닌 Windows PowerShell V2 Community Technology Preview 3 (CTP3) 입니다.

test4.pl의 소스는 다음과 같습니다.

print "한국어\n";
print "日本語\n";

인코딩은 utf-8 without BOM




이를 인스톨하기 위해 전에 설치했던 Powershell 1.0을 Uninstall해야 했는데요. appwiz.cpl에서 보아도 uninstall을 찾을 수 없었습니다만, 다음의 커맨드로 해결했습니다.

powershell 1.0 삭제하기
%windir%\\$NtUninstallKB926139$\spuninst\spuninst.exe /quiet /passive

폰트를 바꾸거나 하는 것은 어떻게 하는지 아직 모릅니다만, 그런대로 만족합니다. :)

아. 사용할 때 chcp 65001을 해주셔야 합니다.

[정보공유] 온라인 한글 맞춤법 검사기

[정보공유]

온라인 한글 맞춤법 검사기

http://164.125.36.47/urimal-spellcheck.html

블로그를 쓰면서 혹시 맞춤법이 신경쓰여 찾아보게 되었음.
혹시 자녀가 있다면, 아이에게 바른 한글을 가르칠 때도 도움이 될 것 같음.

이상.

woo_김택우 says:
http://lab.naver.com/
woo_김택우 says:
이거 알지??
(Dev) Kim tonghyun says:
오- 몰랐어
woo_김택우 says:
음 써봐 재미있어

이성식의 [앞서가는 소수-짧은이야기]에서 소개받은 팃포탯(Tit for Tat) 전략

저는 이성식의 [앞서가는 소수-짧은이야기]를 메일링 리스트로 받아보고 있습니다.
삼성경제연구소(www.seri.org)의 포럼 "앞서가는소수/IT,기획,전략,조직관리,역량,리더쉽,CMM,PM,CRM,CIO"에 등록되어 있습니다.

매번 좋은 기사로 신세를 지고 있습니다만, 어제 팃포탯이라고 가상게임에서 승리한 전략프로그램의 로직을 소개하는 메일링 리스트의 메일이 도착해 있었습니다.

내용을 소개하면

====
팃포탯 전략
프로그램간의 가상게임에서 승리한 전략프로그램의 로직.

"내가 먼저 상대에게 협력하는 자세를 보인다.
그리고 그 협력하는 자세에 대해 상대가 협력 자세로 대응하면 다시 나 또한 협력하고,
상대가 배신하는 자세로 대응하면 나 또한 배신하는 자세로 대응한다."

도움과 배신이라는 상황에서 우리가 가장 많이 들어왔던 전략은 '눈에는 눈,이에는 이'다.
곧, 도움에는 도움으로, 배신에는 배신으로 응해 주는 것이다.
팃포탯 전략이 이와 다른 것은, 먼저 도움을 준다는 사실이다.

중국 철학자 증자는 말했다.
"남이 나를 소중히 여기기를 바란다면, 내가 먼저 남을 수중하게 여겨야 한다."
====

구글에서 검색한 또다른 기사의 팃포탯입니다.

<미국 미시간대 정치학자 로버트 액설로드는 1980년 게임이론 전문가들을 토너먼트 게임에 초대했다.
참가자들은 컴퓨터를 이용해 각각의 최상의 전략으로 상대와 게임을 벌였다.
이 게임 승자는 캐나다 토론토 대학의 아나톨 라포포트가 만든 ‘티포탯(Tit for Tat=맞받아 응수하기)’ 프로그램이었다.
참가자들은 이 결과에 입을 다물지 못했다.
‘이에는 이, 눈에는 눈’이라는 이 티포탯 전략이 너무나 단순했기 때문이다. 이 전략의 시작은 협조다.
그 뒤에는 상대방이 하는 것을 따라한다.
상대가 협조하면 협조하고, 속이면 똑같은 방법으로 보복을 한다. 그러면서 때때로 용서를 한다.>

====

가끔, 이미 아는, 단순한 사실로부터 다시 그 가치를 느끼는 일이 있습니다.
(몸으로 실천하지 않으면, 알고 있는 것이 아니라, '들은 적이 있는 것'이겠지요.)
이 기사로도 느낀 점은 많지만, 그것을 한마디로 정리하긴 어렵네요.
한가지 지금 분명히 말 할 수 있는 것은, "협조하는 사람을 더 잘 챙겨야겠다" 입니다.