노스웨일즈 김씨 시조의 블로그

Cron 시스템을 설치 하고 난 후 한 참 후 Log파일을 보니, 

신기하게도 어떤 파일들은 Compress되서 5개 파일로 Rotate되는데 어떤 파일들은 그대로 남아 있다.

마침 궁금해 하고 있었는데 Jie가 로그가 많이 빨리 쌓이니 파일들을 Rotate해 달라고 한다.

일단 파일들을 보니 root계정으로 처리 되어 있어, root cron script를 보다 보니 특별한게 없다.

다른 사람들한테 물어봐야 하나 하고 있는데 예전에 OAS 일하면서 cron script가 /etc/cron.d 밑에도 등록될 수 있던게 생각이 나서 뒤져 보니 /etc/cron.d에 logrotate가 있고,
logrotate는 /etc/logrotate.conf 정보를 읽어 보고 있고, 최종적으로 /etc/logrotate.d/ 폴더를 읽어 오게 되어 있다.

grep으로 로그가 저장되는 폴더를 찾아 보니 드뎌 아래를 발견했다.

# cat /etc/logrotate.d/syslog

/var/log/corp/*.nzlog /var/log/corp/*.info /var/log/corp/*.warning /var/log/corp/*.crit /var/log/corp/*.notice /var/log/corp/*.err /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron /var/log/kern {
    missingok
    copytruncate
    sharedscripts
    rotate 5
    size=5M
    compress
    postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

리뷰해 보니 일반적으로 시스템에서 log rotate하는 설정에 회사 관련 로그파일들을 넣었던 것이다.

생각해보니 형태가 시스템 파일들 로테이션 하는 것과 유사 했다.

덕분에 새로운 걸 알게 되었는데, 한편으론 아직도 왜 나는 "Why"라는 생각을 가지고 뭔가 파고들지 않을까 하는 자괴심도 든다.

뭐.. Googling을 해보니 꽤 괜찮은 Article도 보인다.

http://www.ducea.com/2006/06/06/rotating-linux-log-files-part-2-logrotate/

Console 관련 업무를 시작하게 되면서 새롭게 경험하게 된 분야가 DevOps & CI 부분이다.

원래 계획은 어땠는지 모르겠지만, 

원준씨가 퇴사하면서 Chronos 부분을 인수인계 받아 진행하게 되면서 업무에 익숙해 지기도 전에 이 일을 맏게 되었다.

덕분에 지난 6개월 동안 Puppet, Jenkins, Stash 같은 여러 Tool들을 다뤄 보게 되었다.

뭐.. 어떻게 될 지 모르니 이 쯤에서 새로운 것들 정리해 보는 것도 좀 필요할 듯 싶다.

1.  Puppet

원준씨 퇴사하고 Chronos관련 업무를 맏고 나서 제일 황당했던 건 시스템을 Release하기 위해서는 Puppet Manifest를 작성해서 Production 에서 실행시켜야 한다는 거였다. 정말 황당했지만 뭐 어쩌랴. 덕분에 Puppet을 속성으로 공부해야 했고, 기존 API 시스템 Release용으로 작성되어 있던 Puppet Manifest를 수정해서 Chronos 용으로 사용하게 되었다. 업무를 하면서 어려웠던 건 선언적언어라는 패러더임과 AppNexus의 Coordination 시스템과의 연계 부분을 알게 되는게 많이 힘들었다.

2. Jenkins

예전에 대권이 Jenkins를 처음 소개 했을 때는 좋은 툴이라는 생각, 그리고 관련 업무는 대권에게 다 맞겼었다.

근데 Chronos 에 올라가는 Application들은 내가 관리하게 되니 해당 Application관련 Jenkins Job은 내가 다 작성해야 했다.

다행히 지금까지는 API팀에서 사용하던 코드들이 넘어 오는 상황이라 API팀이 작성했던 Jenkins Job을 Copy해서 시스템에 적용해 나갔다.

근데 Jie가 Master뿐만아니라 개발 branch의 update시에도 실행되는 Jenkins  Job을 작성해 달라 한게 좀 Research가 필요했다.

우선 Jenkins의 branch부분을 *으로 처리해서 Job을 등록했더니 git checkout시 계속 문제가 생겼다.

알고 보니 Jenkins  Git Repositories 부분의 Repository Name을 비어놓았더니 Jenkins가 remote 이름을 아무이름이나 부여해서 ${GIT_BRANCH}에서 나오는 origin/<branch name>을 인식하지 못하는 것이었다.

Source Code Management -> Git -> Repositories -> Advanced -> Name을 "origin"으로 수정하고 나니 우선 문제 해결.

이제는 master를 제외한 나머지 branch에 대해서만 실행하는 방법을 찾아야 했는데 찾아 보니 하나의 Article이 나왔다.

http://stackoverflow.com/questions/21314632/how-to-exclude-git-branch-from-building-in-jenkins

Source Code Management-> Git 부분의 전체 정보를 master에 맞추어 작성하고, Additional behavior에 Inverse 를 선택해주면 master이외에 다른 branch에 대해서 실행이 된다는 것이다.

나름 테스트 해보니 master제외한 다른 branch에 대해서 실행은 되는데 코드가 수정이 되지 않아도 Polling Schedule시점에 마지막으로 실행되었던 branch기준으로 계속 테스트가 실행이 되는 것이다.

그래서 곰곰히 Help Doc을 읽어 보니 branch부분이 정규식을 지원한단다. 

그럼 master를 제외하는 정규식을 설정하면 되겠다 싶어서 :^(?!.*master).*$ 를 넣어 보고 테스트 해보니 master이외의 branch가 Update될때 잘 실행이 된다.

결론적으로 master이외의 branch에 대해서 Auto test를 수행하려면 

1. Source Code Management 의 Git설정시 Name부분을 origin으로 설정하고, 

2. Branches to build를 :^(?!.*master).*$ 로 

3. Build Trigger -> Poll SCM 부분을 H/3 * * * *으로 설정하게 되면 

Jenkins가 3분마다 git을 Polling하여 수정된 branch가 있을 경우 해당 branch에 대해서 Jenkins job을 수행하게 된다.

3. Stash Jenkins연동

기존 코드의 Migration이 어느정도 진행이 되자 Jie가 이젠 master branch업데이트 되는 걸 PR로만 진행할 수 있게 하자고 한다.  당연히 할 일이긴 한데, PR할때 Test를 실행하게 해달라고 한다.

생각해보늬 DevOps가 Puppet manifest수정  자동 승인시 Jenkins build진행시키는게 생각이 나서  corpwiki와 DevOps팀의 Jenkins Job을 참조해서 아래와 같이 진행했더니 PR이 생성시  Jenkins Job을 실행 할 수 있게 되었다.

1. Stash설정 - Stash의 Project 설정의 Hooks화면의 "Stash Webhook to Jenkins"를 설정한다.

2. Jenkins

   Git의 Refspec부분을 +refs/pull-requests/*/from:refs/remotes/origin/pull-requests/*/from +refs/heads/*:refs/remotes/origin/* 로 설정하고, Post Build Actions에 Notify Stash Instance를 설정하면  PR 생성시  Jenkins job이 실행되고 결과도 PR로 전달된다.

개발 관련되서는 많이 공부하고 있었으면서도 CI/CD에 대해서는 조금 뒤쳐저 있었었는데 이번에 Chronos관련 업무를 맞게 되면서 많은 것을 공부하게 되어서 나름 유익한 경험이었다.

미리 좀 준비 할 여유가 있었다면 더 좋았을 텐데 말이지만...

볼티모어 아쿠아리움에서 사온 돌고래 인형이 어느덧 우리 율이의 좋은 친구가 되었다.

평소 주말처럼 YMCA에 수영을 배우러 갔더니 산타 할아버지 사진 찍는 행사를 했다.수업을 끝나고 사진 찍어야지 했는데, 행사는 끝났고 사진 찍는 배경은 남아 놨기에 마침 받은 수료증을 가지고 한번 찍어 봤다.

올 겨울도 Longwood Garden  Lightening구경으로 GoGo... 

처음 봤던 작년 만큼은 덜 하지만 그래도 역시 참 멋있다는..

눈 오는 날에 필리 시내 레스토랑에 놀러 갔다가 소화도 시킬 겸 Love Park에서 사진 한 컷.
갈때마다 사람들이 많아서 몰랐는데 알고 보니 Love상이 벤자민 플랭클린 로드 방향으로 설치 되어 있었다.

이번 겨울도 어김없이 폭설이..
주말내내 일기예보 보느라 TV보고... 그리고 삽질..
남들은 군대서 하는 삽질을 나는 40이 넘어서 하고 있다니..-.-
나중에 집 사면 Snow blower를 꼭 사야지..

뭐.. 암만 4시간 동안 삽질 하는라 힘들어도 썰매 타는 즐거움을 빼먹을 수는 없지..

영미누나가 친구 편으로 보내주신 한국 어린이 책...
율이가 잘 읽고 인형도 너무 좋아해요. 매번 고마워요 누나

동네 몽고메리몰 놀이터... 겨울에 처음 알게 됐는데.. 비 오는 날은 자주 가게 된다.

날이 따뜻해 져서 찾아왔던 몬다욱 공원.
이젠 율이도 버블 놀이를 제법 잘 한다는...

몇 년동안 일하면서 항상 하고 싶었지만 해보지 못했던 일중에 하나가 RPM 파일을 만드는 거였다.

일단 시간도 없었고.. ( 게으르다고 해야 할 까 .. ) 그리고 개발쪽 관련 공부에 집중하다 보니..

근데 이번에 원준씨가 이직하면서 본의아니게 Cron시스템을 인수인계 받아 진행하다 보니 RPM을 만드는 일이 생겼다.

일단 PUPPET관련해서 작업 끝내고, SYSOPS가 시스템까지 구축해준 상태에서 최종 확인을 하다 보니 새로운 RPM을 설치하는 게 진행이 되지 않는 것이었다. 시스템 문제인가 생각했는데, 잠시 시간 날때 확인해 보니 내 PUPPET에 문제가 있었다.

그래서 PUPPET을 고치고 새로운 RPM을 설치해 보니 RPM은 설치 되었다고 나오는데 설치되어 있어야 할 파일들이 없다. PUPPET을 이리저리 바꿔보고 했는데도 되지 않고... 시간 만 보내고 있는데 불연듯 RPM이 잘못 된건 아닐까 생각이 든다.

그래서 spec파일을 검토해 보고 googling을 해보니 아래 article이..

내용은 RPM에서 spec파일에 선언되어 있는 명령문들은 아래 순서 대로 실행된단다.

 1. %Pre of new package
 2. %Post of new package
 3. %Preun of old package
 4. %Postun of old package
http://stackoverflow.com/questions/7398834/rpm-upgrade-uninstalls-the-rpm

마침 나는 api spec파일을 copy하면서 Postun섹션을 넣었는데... 이게 실행이 되면서 설치 폴더들이 다 지워 지는 것이었다.api는 multi version을 위해서 rpm설치할 때 해당 version을 폴더 경로에 넣어서 uninstall도 하지 않지만 하더라도 해당 버젼 폴더만 지우니 문제가 없는 것이었다. 

나도 지금이라도 버젼을 넣어서 처리 할 까 생각하다가 어차피 자바로 포팅하기 까지만 지금 구조로 갈꺼니깐 없어 진 파일 패키지에 남아 있다고 해서 큰문제는 생기지 않을 듯 싶다.

흐미... SPEC파일에 대해서 조금만 봤어도 하지 않았을 실수 때문에 거의 하루를 날려버리게 되다니..

COPY를 하더라도 정확히 이해하고 해야지.. 그리고 다음에는  RPM만들떄 꼭 버젼을 고려해야 겠다.

결국 %Postun을 없애고 나니 RPM삭제이후에도 파일들은 시스템에 남아 있게 되는거 아닌가...

그동안 주로 EJB로 개발하다보니 Mockup테스트를 알고 있으면서도 사용하지 못했었는데 Cron Project를 진행하면서 사용하게 되었다. 알고 있는지는 10년은 된것 같은데 이제서야 쓸 생각을 하다니..

일단 시작은 Mockito를 사용해서 Mock객체를 생성해서 테스트를 진행해 보았다.

http://mockito.org

쓰는 방법은 간단했다.

mock(new ObjectO))를 실행하면 헤당 Object의 method를 실행할 수 있는 Mock객체가 생성된다. 

그 후에 when()등의 메소드를 사용하여 특정 메소드가 호출 될 경우 특정 결과를 Return하게 하도록 한후,

해당 Mock객체를 실제 객체에 Wiring하고  

객체 메소드를 호출하면 Mockup객체에 등록된 메소드에 따라 결과가 Return되고, 이를 통해서 실제 객체가 잘 실행되는지를 확인하게 되는 것이다.

처음 Mock을 사용할 때 when()메소드로 선언하는거 이외에는 원래 객체의 메소드를 호출하는 걸로 오해하고 진행을 해 보니  Mock객체는 객체의 메소드들을 가지고 있는 정말 Mockup객체일 뿐이었다.

특정 메소드 이외에 다른 메소드는 원래 코드를 실행하게 하기를 원할 경우는 mock()이 아닌 spy()를 사용해야 한다.

마침 내가 개발하는 코드가  Method가 여러개이지만,  각 Method가 다른 API를 호출하는 형태에서 API호출하는 부분을 별도의 private  메소드로 추출했고, 해당 부분을 spy() 하게 되면 외부 API를 사용하는 코드도 테스트 할 수 있게 될 듯 했다.

근데 문제는 Mockito는 private메소드에 대해서는 spy()를 진행할 수 없었다.

그래서 Search를 해보니 PowerMockito를 사용하면 private 메소드를 spy()할 수 있다고 한다.

일단 pom.xml에 PowerMockito dependency를 등록하고, 

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito</artifactId>
    <version>1.6.3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-easymock</artifactId>
    <version>1.6.3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>1.6.3</version>
    <scope>test</scope>
</dependency>

import org.powermock.api.mockito.PowerMockito;

...

@

Connector mockConnector = PowerMockito.spy(connector);
....
@Test
public void testThirdPartyConfig(){

PowerMockito.doReturn(configJsons).when(mockApiConnector, "list",
        "thirdparty-config", queryParam);
FacebookConfig config = mockConnector.getThirdPartyConfig();

참고로 내가 테스트 하려는 코드를 connect.getThirdPartyConfig 메소드이고, getThirdPartyConfig는 connect.list("thirdparty-config",queryParam) 메소드를 호출하여 외부 API를 호출하고, 그 결과를 파싱해서 사용자에게 객체로 리턴해준다.따라서 list메소드를 spy하면 외부 API를 호출하지 않고 getThirdPartyConfig메소드가 잘 실행되는지 확인할 수 있는 것이다.

잘 되기는 하는데 private메소드에 대해서는 좀 이상하게 실행이 되어서 Abstract메소드를 protected로 변경했더니 잘 싱행이 된다. 

그리고 진행을 하다 보니 PowerMockito가 Mockito를 사용하는 Test보다 훨씬 느리다.

서치를 해보니 내부적으로 객체 생성을 많이 한다고, 가능하면 Mockito를 사용하라는 걸 보니 , 이게 좀 문제 인듯 하다.

성능 부분을 제외한다면, PowerMockito가 꽤 괜찮은 솔루션으로 보인다.

집을 구매하려고 한국에 있는 돈을 가져오려고 은행 콜센터에 확인해 보니 

이건 뭐...한국에서 해외 송금하는게 무척 복잡하다.

1. 일반 송금

개인의 경우 매년 ( 1월 1일 ~ 12월 31일 ) 5만불까지 송금 할 수 있다고 한다.

총 5만 불이지만, 건당 1만 불 까지가 한도라고 한다. 그리고 이 돈이 부동산 구매에 사용될 경우 문제가 생길 수 있다고 한다.

2. 해외 이주 예정자 

1년 이내에 영주권을 취득할 예정인 경우 해외 이주비용을 미리 송금 할 수 있다.

이 경우에는 외교통상부에 해외 이주 신고 확인서를 발급 받아야 하고, 이 경우에는 주민등록이 말소 된다.

그리고 이를 위해서는 영주권 업무를 진행하는 기관에서 영주권 신청 상황과 취득에 대한 문서를 발급받아야 한다고. 그리고 영주권을 받게 되면 이를 은행에 또 보고 해야 한다고 한다.

한도는 제한이 없지만 10만불 까지는 문제 없이 보낼 수 있고, 10만불 이상의 경우는 세무소에서 자금 출처 확인서를 받아야 한다고. 그리고 10만불은 가계당으로 계산한다고 한다.

3. 영주권자.

영주권자의 경우는 여권과 영주권만 있으면 금액에 제한 없이 해외 동포 재산 반출로 반출 가능하다고 한다.

다만 10만불이 넘어 갈 경우 만일 부동산 처분에 의한 경우는 제한이 없지만, 그 이외의 경우는 세무소의 자금 출처 확인서를 받아야 한다고 한다.

4. 해외 부동산 취득

이 내용은 콜 센터에서 안내 해 줄수 없는 부분이라고 한다.

어쨋든 종합해 보니 우리 같은 경우는 영주권을 취득 하는 시점에 해외 동포 재산 반출로 처리 하는 게 제일 좋을 듯 싶다.

그리고 신한은행에 경우 해외 이주 및 유학 상담을 위해 별도의 콜 센터를 운영하고 있으니 이를 이용하는게 더 좋을 듯.. 전화 번호 1588-8716 

일반 콜센터로 전화 했다가 지점으로 전화 했었는데..  해외 이주 관련 콜 센터가 보다 정확하게 설명해 주었다.

Shell 코드를 작성하다보면 Java Property를 읽는 경우가 종종 있는데 보통은

. <FILE_PATH>

를 사용하면 FILE에 있는 각 변수 들이 환경 변수로 등록이 되어 사용된다.

보통은 문제가 없는데 만일 변수에 .이 있을 경우는 이를 command로 인식해 버려서 command를 실행하는 형태로 처리 되어 변수를 읽을 수 없게 된다. 역시 편한거에는 한계가 있다는 그래서 검색을 하다 보니 관련 해서 좋은 TIP을 발견

sed '/^\#/d' myprops.properties | grep 'someproperty'  | tail -n 1 | cut -d "=" -f2-

sed로 #로 시작되는 Line을 제외한 후  grep로 원하는 property가 나오는 마지막 라인을 가져온 후 = 이후의 값을 읽어 온다.

추가적으로 trim을 처리 하는 부분을 추가하면 아래 처럼 쓸 수 있다.

JAVA_HOME=`sed '/^\#/d' build.properties | grep 'jdk.home'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`

->build.properites에서 jdk.home property를 읽어서 JAVA_HOME변수에 넣는다.

출처 : http://shrubbery.homeip.net/c/display/W/Reading+Java-style+Properties+Files+with+Shell

흠... 드뎌 LOG Processing관련한 내용까지도 Tech Ops가 처리 해 줘서 이제는 12시에 다시 읽어 나서 작업 돌리고 자는 일은 끝..

이제는 LOG ANALYZE 도 인수 인계 해 버리면 정말 OAS API와는 작별을 고하게 될 듯 싶다.

이전다음

012345678

스티커 좋아 하는 율이 .. 뭐.. 어느 아이들이나 스티커는 다들 좋아 하는 듯.

회사에 놀러온 율이.. 예쁜 얼굴에 뭘 그리 붙였을 꼬...

아빠한테 사과좀 나눠 주지...

회사에서 나름 재밌었는지... 종종 회사에 대려 가도 싫어하지는 않는 눈치다.

이렇게 입혀 보니 숙녀티가 조금 나는 듯..

율아.. 예쁜 웃음 잃지 말자...

율이의 첫번째 인형 친구 율라...

어쩌다 놀이터까지 대려 왔네..

이전다음

0123456

동네 공원에서 아빠랑 공연 듣는 율이.

호... 이렇게 보니.. 뭔가 근사한 음악을 듣고 있는 것 같아 보인다...

이전다음

0123456789

여기 놀이터에는 나무 토막을 주로 깔아 놓는다....

아이들은 종종 나무 톱밥을 가지고 이런 저런 장난을 하고.. 율이도 그런거 좋아 하는데.. 아빠는 좀 자제해 줬으면..

올여름도 율이는 아파트 수영장을 제집 드나들 듯이...

뉴저지에 있는 USS 뉴저지 호.. 2차 대전 등 많은 전투에 참가 했던 퇴역함이다.

사실 Robber Duck온다고 해서 돈 내서 왔는데... Rubber Duck은 결국 일어나지 못하고...

올해 율이는 Independency Day 연휴동안 계속 불꽃 놀이만 봤다... 그런데도 아빠한테 불꽃 놀이 하는 곳 찾아 내라고 또 성화다...

아빠는 공부하고.. 율이는... ?

아... 웃는 모습이 너무 예쁜 율이..

뉴저지에 있는 9/11 관련 추모 시설... 당시 피해자들의 이름이 새겨져있다...

앞으로는 이런 비극이 일어나지 않아야 할텐데..

한살때쯤 머리 깍을때는 미용실 떠나가게 울었는데..

여름에 Ocean City가서 한 컷

뉴욕 출장갔을 때 사온 케잌..좀 비싸긴 해도 괜 찮은 맛이었다.

새로 사온 놀이집...

집사람 얘기로는 설정샷이라는데...

집사람 생일 기념 케잌..

율라를 제일 좋아라 하는 율이...

Matt이 초대해 주어서 함께 즐겼던 Dutch Wonderland. 애기들 위주의 놀이공원이어서 율이도 비교적 즐겁게 놀 수 있었다는..

Wonderland갔다 오는 길에 타본 증기 기관차....

짧은 구간 동안 운행하지만 나름 즐거운 경험이었다.

율이 친구 하은이..

예전에 매뉴용크 푸드트럭 축제 할 때 길거리에서 잠깐 지나 첬었는데..

다른 한국 분 소개로 다시 만나게 되었다는..

지금도 율이는 종종 하은이를 찾는다..

롱우드가든 Beer Garden에서.... 집사람은 맥주.. 율이는 물... 나는..:-(

올 여름 마지막 바다였던 Spring Lake.. 여러 군데를 다녀봐도 여기만한 데는 없는 듯..

매뉴용크 레스토랑 윅에 먹은 크라페.

가을이 되니 도토리가 애기들의 놀이감이 되었다.

올 여름도 별 탈 없이 잘 지내준 우리 율이..

남은 올 한해도 무사히 잘 지내자...

오늘 N1서버가 Decompression되었다.

OAS가 AppNexus될 때 예정 됐던 N1 Decompression이었지만, 다들 못내 아쉬웠나 보다.

Vlad는 공지 메일에 N1 Shutdown하는 Ed 모습을 찍어 보내고,

Adam은 "will we be sitting Shiva?"

Ryan은 "I’d recommend an Irish wake instead." 라는 멘트를 Slack에 남겼다.

특히나 마음에 가는 건 Victor가 소회를 메일로 남기면서 남긴 마지막 문구였다.

생각 난 김에 wiki에서 History를 챙겨 보니 OAS 6 가 8년이 되었고, N1이 OAS7으로 업그레이드 된 기간을 보니 6년 전이다.

그 8년 넘는 기간동안 OAS가 나에게 Salary 도 주었지만, 

나에게 미국으로 올 수 있는 기회, 결혼 그리고 예쁜 딸을 주었다는 생각을 하니 조금은 가슴이 찡했다.

미국에 와서 DHC 이슈가 생길때 마다 Stress때문에  힘들다가, 

언제 부턴가 DHC이슈가 줄어들었을 때, 사업이 잘 안된는 건 아닐까 하는 걱정보다는 편하한 나의 생활을 즐기기만 했던 나를 생각하면 아쉽다는 생각이 든다.

Network 사업 인력의 Layoff, MoonShot Project 등을 하면서 한 번쯤은 오늘과 같은 상황도 생각해 볼 수 있었을 텐데... 아직도 세상일은 나에게는 어렵다는 느낌이다.

뉴욕 오피스를 나오며 Jie에게 메신저로 인사를 하고 나오는데 정팀장님이 HR에 나의 Transition에 대해서 진행하고 있다는 소식을 전해 주었다.

모두 N1과의 작별을 하는 날, 나는 이렇게 OAS와의 작별도 맞이하게 되었다.