Extreme programming이란..

Code Complete 2를 읽다가 익스트림 프로그래밍의 결함감지 비율에 대해서 보게 되었다. 매우 효율적이고 에러감지율이 높은 방식이라는 것이다.

익스트림 프로그래밍은 매우 극단적인 상황에서 숙련된 프로그래머들이 취하는 방식이라는 것만 개념적으로 알고 있었는데, 실제 어떻게 프로그래밍한다는 것인지 궁금해졌다. 그래서 찾아본 결과... 와우...

전문을 복사해서는 않되지만, 그래도 공부하는 셈치고 복사를 감행했다. 원문은 다음 링크를 살펴보면 된다.

원문 : Extreme Programming (미친병아리가 삐약삐약)

스포츠에만 익스트림이 있는 것이 아니다.. 프로그래밍의 세계에도 엄청난 도전을 즐기는 사람들이 있으니, 그들이 즐기는 프로그래밍 스타일을 eXtreme Programming, 줄여서 XP라고 한다.. (Microsoft의 윈도우즈 제품군 중 하나인 XP와는 하등의 상관관계가 없다.. 이 제품의 XP라는 명칭은 Exprience, 즉 보다 새롭고 좋은 경험을 제공하겠다는 Microsoft의 의지가 담겨져 있는데 공감하는 사람도 있고, 그렇지 않은 사람도 있고.. 양극의 반응을 보이는 네이밍인듯 싶다.. 난 매우 만족하는 편에 속한다..)

XP에 대해서는 우연히 듣게되어 도대체 뭔가 싶어 무작정 사서 읽게된Extreme Programming Installed, XP 도입을 위한 실전 입문이라는 책을 통해 알게되었는데.. 그때 읽은 기억중 가장 기억에 남는 대목은 책을 다 읽고 나중에 읽게된 책의 마지막 부분에 붙은 저자와의 인터뷰 내용이었다.. 바로 아래에 인용된 바로 이 부분이다..
매일 우리에게 급여를 지급하는 사람들 (고객, 경영진, 팀장, 좀 확장해서 넓혀보면 동료들, 협력사 등등)에게 그들이 이해할 수 있는 매일매일의 가치를 제공하라.. 왜 XP라는 극단적인 방법론이 나오게 되었는지를 모두 설명해주는 기저가 아닌가 하는 생각이 든다.. 신선한 충격이었다.. 그렇다.. 이 문장에서도 핵심은 이해할 수 있는이다.. 고객이, 경영자가, 즉 내가 아닌 남이 이해할 수 있는..

This will sound trite but I believe it. Work hard, be thoughtful about what happens. Work with as many other people as you can, teaching them and learning from them and with them. Read everything, try new ideas in small experiments. Focus on getting concrete feedback on what you are doing every day -- do not go for weeks or months designing or building without feedback. And above all, focus on delivering real value to the people who pay you: deliver value they can understand, every day. 

"진부하게 들릴지도 모르겠지만 저는 이렇게 믿습니다. 열심히 일하고, 일어나는 일들에 대해 사려 깊게 생각하세요. 가능한 한 다양한 사람과 함께 일하며 그들을 가르치고 그들로부터 배우고 그들과 함께 학습하도록 하세요. 닥치는 대로 독서하고, 작은 실험으로 새로운 아이디어를 시도해 보세요. 지금 하고 있는 일에서 구체적인 피드백을 얻는 데 집중하세요. 피드백 없이 수주 혹은 수개월 동안 디자인 하는 것은 피하세요. 
그리고 무엇보다도, 당신에게 급여를 주는 사람들에게 실질적인 가치를 산출해 내는 데 집중하세요. 매일 그들이 이해할 수 있는 가치를 제공해야 합니다." 

Extreme Programming 의 아버지, Ron Jeffries 와의 인터뷰 중에서.. { from XPer.org }

사실 XP는 일반적인 개발방법론으로는 일정에 맞추기 힘든 경우를 위한 극단적으로 효율성을 추구하는 방법론으로 프로들이 모여 행할때나 소용이 있는, 나같은 일반인이 따라하기에는 다소 무리가 있는 아이디어들이라고 생각한다.. 즉, 경험과 숙련도가 있는 사람들이 모여서 작업할때 효과를 발휘할 수 있는 방법론이라는 생각이다..
물론, 몇몇 아이디어들은 누구나 시도해볼 수 있는 것들도 있기는 하다.. 그렇지만, 그런 부분적인 것들의 도입으로 XP를 한다고 할 수는 없을 것 같다.. 어찌보면 새로운 것에 대한 시도조차 안해보는 것 같기는 하지만, 여러 프로젝트들을 보며 느낀점은 XP를 수행할 수 있는 역량의 팀은 그리 많지는 않다는 생각이 든다.. 시행착오를 하며 배울 수는 있지만, 이미 그 자체가 XP의 정신을 못 따르는 것은 아닌지.. 매일 그들이 이해할 수 있는 가치 제공은 거듭되는 시행착오에서는 발생될 수 없지 않는가.. 본의아니게 XP와 유사한 방법론을 사용하며 프로젝트를 할 수 밖에 없는 상황에 대한 비애감인가?

구루님의 젊은 프로그래머를 위한 충고라는 글을 보면서 생각이 나 몇자 끄적거려 봄..



회사 게시판에 올렸던 요약정리..

From: 오광섭 
Sent: Wednesday, March 12, 2003 9:19 PM
Subject: [참고] Extreme Programming Installed 요약


다 읽은 후 최대한 빨리, 기억이 살아있을때 정리하려고 했는데
시간내기 쉽지 않군요..



이 메일은 개발2팀 내부 게시판에 보관됩니다..
3.다울파 > 개발2팀 > 팀 내부 상세 논의 마당 > S/W 제작사의 실무 지침

앞으로 이곳 게시판에는
Code Complete, Rapid Development 와 같은 책을 읽고 요약을 올려둘 예정입니다..



부제는 XP 도입을 위한 실전 입문 이라는 책입니다..



S/W 개발사에서 검토는 해볼만한 방법론이기에 책 읽은 내용을
요약하여 정리해둡니다..

자세한 내용은 사내에 구비된 도서를 참조하시구요..



이 책은 어떤 딱딱한 이론서는 아닙니다.. (리팩토링이나 디자인 패턴 같은..)
그냥 저자들의 경험담을 형식에 구애받지 않고 마구 풀어놓은 수필 같은
책에 더 가깝습니다.. (물론 프로그래머들이 쓴 수필이므로 일반인들이
읽기에는 좀 맞지 않기는 하겠죠..)
해서 읽기가 어렵지 않고 읽으며 생각해야할 것이 별로 없기 때문에
한번씩들 읽어보시길 적극 권장합니다..
S/W 개발사의 구성원으로서의 사고와 경험의 폭을 넓혀줄 수 있을 것입니다..

이건 미국이라는 S/W 개발 선진국이기 때문에 가능한 이야기다..
말도 안되는 이야기다.. 그렇게해서 어떻게 S/W를 만들 수 있느냐..
말은 좋다만, 실제로 적용한 곳은 국내에 없을거다..
특별한 S/W 개발에만 적용 가능한 이야기다..
우리 여건이 받쳐주지 않는데 어케 도입하느냐..

국내에 XP가 소개되면서 위와 같은 논의는 무자게 많이되었고
현재도 논란이 계속되고 있는 것으로 압니다..
자바 관련된 뉴스그룹이나 웹 게시판 같은데 가보시면 많은 이야기들을
보실 수 있으실 겁니다..

하지만,
이들이 미국인들이기 때문에 이렇게 일할 수 있는건 아니다..
XP는 미국에서도 논란이 되고 있는 프로젝트 진행방식이며,
이들은 스스로가 이렇게 운영하기 위해 노력을 해 얻어낸 경험이며 결과인 것이다..
우리네 고객사나 이네들 고객사나 큰 차이는 없는 것이다..
사람 사는 동네 다 거기서 거기이므로.. 

중요한 것은 남이 제시한 XP를 맹목적으로 따르거나
무조건 비판하고 수용하지 않으려 드는 것 보다는
보다 열린 마음으로 장점 및 도입 가능한 부분을 수용하는 자세가 아닌가 합니다..
(물론, XP 옹호론자들은 일단 우리가 제시한대로 무조건 따라봐라..
최대한 규칙대로 극단적으로 행해야 한며, 일단 해보면 우리가 이야기하는
장점을 경험하게 될 것이라고 하고는 있지만..)



* XP 소개 (역자 서문 요약)

- 너무나도 각박한 현실에서 살아남으려는 극단적 (Extreme) 상황의 출발점

- 이해를 돕기 위한 예.. (왜 XP인가 ?)
도메인 전문가 2명을 포함한 10명의 개발자가 있다..
1년정도 걸리는 (120MM) 프로젝트를 4개월만에 끝내야 하는 상황이다
사람을 더 뽑을 수 있는 상황도 아니다..
고객을 만족시키면 10억의 인센티브가 지급된다..

- 제 생각엔.. 모든 프로젝트들이 조금씩은 이러한 성격을 가지고 있는 것
같습니다.. (미친병아리 생각)



* XP의 장점

- 동료, 고객 그리고 관리자와의 의사소통을 쉽게 만들어 주었다..

- XP의 가치는 단순성, 의사소통, 피드백, 그리고 용기에 있다..

- 성공적인 프로젝트 진행을 돕는다..
프로젝트를 성공적으로 이끄는 것 만큼 신나게 일할 수 있게 만드는
동기부여는 없다..

- 미친병아리 생각 : 성공적인 프로젝트 임을 느끼자면
개발사 뿐만 아니라 고객사도 만족을 해야 합니다..
그리고 그 시스템이 정말로 그들의 업무를 돕고 있다는 느낌을 받을 수
있어야 합니다.. 고객의 만족이 다시 개발사로 피드백 되어야 하죠..
음.. 다울소프트에서 성공적인 프로젝트는 어떤게 있을까요 ??
상공회의소 정도 ?

제 생각에는 이런 것들이 지속화 되면 구성원들을 더욱 힘들게 할 것
같습니다.. 성공적인 피드백을 회사 전체에 알리는데 인색하지 맙시다..

자기가 들은 칭찬은 마구 떠들어 봅시다..
만나서 이야기할 기회가 없으면 게시판이라는 의견교환의 다른
대안이 있습니다..



* XP 구성원들의 의미와 역할

- 고객
- 고객은 비지니스 가치를 높이는 것이 무엇인지 파악하고,
무엇을 먼저 하고 나중에 할 것인지를 결정하며,
시스템이 제대로 동작하는지 확인할 수 있는 테스트를 정의한다
- 고객이 개발팀과 현장에 같이 상주할때 매우 효과적으로 운영된다
- 한 사람이건 여러사람이건 고객은 한 목소리를 내야 한다
(이놈 딴 이야기, 저놈 딴이야기 하면 안된다)
- 고객이 우왕좌왕하면 관리자는 최대한 컨설팅을 해야 한다

- 프로그래머
- 시스템을 분석하고, 설계하고, 검사하고, 작성하고, 통합한다
- 모든 스토리의 난이도를 추정하고 일정을 보고한다
- 간단하고 명료하게 설계, 작성해야 한다..
- 프로그래머가 지켜야할 수칙들은 뒤에 많이 나온다..

- 관리자
- 고객과 개발자를 한데 모으고 융화시켜 팀이 순조롭게 운영되도록 돕는다
- 개발 프로세스를 수행하는 것이 아니라, 원할하게 진행되도록 돕는 것이다
- 관리자가 하는 일은 사람들 앞에 놓은 수많은 장애물들을 제거하는
것이다. 기존의 관리자 역할을 팀이 수행한다고 해서 일이 없어지는게
아니라 훨씬 더 많아지는 것이다. 필요한 물품구매에서 컴퓨터를 최신의
것으로 유지하는것, 작업공간의 효율적 배치 등등등..
- 관리자의 성공은 훌륭한 S/W를 제시간에 완성하는데 전혀 도움이 되지
않는 장애물을 제거할 수 있느냐 없느냐에 달려 있다.
- 회의를 주관하고, 일정을 점검하며, 사람들 사이의 분쟁을 조정하며,
팀원들을 배려하며, 암튼 고객과 팀에 관련된 모든 일을 처리한다.

- 프로젝트의 순환법칙
- 정의하고 추정하고 결정하고 구축하라. 그리고 배워라.
- 짧은 단위의 반복으로 추정능력을 기를 수 있으며,
추정능력이 높아짐에 따라 자신감과 성취감도 높아진다.



* XP의 주요 실천과제
처음부터 아래 내용을 변영하여 자신만의 XP로 활용할 생각은 말고,
일단은 아래의 실천과제를 무조건 수행하고, 차후에 점점 응용하여
활용해야 보다 효과를 높일 수 있을 것이다..

할 수 있는한 최대한 극단적으로 하는 것이 XP의 핵심이다..

- 현장고객 (On-Site Customer)
- 고객, 관리자, 개발자들이 한 팀이며, 한 팀은 한 방에서 같이 일한다
- 고객과의 의사소통은 현장에 같이 있을때 극대화 되며,
의사소통의 부재는 곧 프로젝트의 실패로 이어진다.
- 이메일 보내놓고 기다리는 것과, 고개돌리면 고객이 답을 해주는것은
엄청난 차이가 있다..
- 추측으로 만든 코드가 단 몇시간 동안에라도 얼마나 생기기 바라는가..
단 한줄도 없는것이 성공적인 프로젝트로의 도움이 된다..
- 고객을 상주시킬 수 없을때의 예는 이미 우리가 하고 있는 방식이므로
생략합니다.. 궁금하신 분들은 책을 직접 보시길..

- 스토리
- 사용자의 관점에서 보는 시스템 행위에 관한 짧은 설명이다.
- XP에서는 스토리를 통해 시스템 전체가 명세화 된다.
- 분석을 초기에만 하는게 아니라 항상 하라 (drive by analysis : 분석에
의한 추진)
- 그냥 작은 백지카드에 고객에게 물어보고 적는다.. 이게 전부다..
마음에 안들거나 더 작게 나눌 필요가 있다면 찢어버리고 새로 적는다..
- 모든 카드의 내용은 고객의 동의를 얻는다
- 스토리는 고객이 작성하는 편이 좋다
- 처음에 시스템 전체의 모든 스토리를 가지고 있지 않다고 해서 걱정할
필요가 없다.. 모든 것은 변할 것이고, 반복하면서 구체화 될 것이다

- 스토리 추정
- 작성된 스토리가 얼마나 걸릴지 추정한다. 처음엔 직관으로 한다..
프로젝트가 진행되면서 프로그래머들의 추정능력은 향상될 것이다..
완성된 스토리와 비교하여 추정할 수 있기 때문이다
- 계획수립
- 고객이 배포를 결정한다
- 고객이 테스트에 참여하고 프로젝트 진행에 적극 참여할 수 있도록
유도를 하라. 모르는 부분은 조언을 아끼지 말고 고객이 원하는
것을 만들 수 있도록 노력하라
- 반복 계획 수립
- 추정과 실천을 반복하면서 훈련을 자연스럽게 하게되며
보다 정확하게 일정을 추정하게 된다
- 조정
- 처음에는 직관을 사용해 추정하지만, 진행하면서 스토리의
일정을 계속 조정한다
- 매일 매일 하루 시작전 일일 약식회의를 하는 것은
조정을 위한 방법이 될 수 있다..
짧은 회의지만 발견된 문제점들을 전파하고 논의하는 기회도 된다
- 반복조정
- 희망속도가 아닌 실제속도에 맞춰 프로젝트가 진행될 수 있도록
매 반복시마다 (한개 스토리를 끝내고, 혹은 중간 회의마다)
조정을 한다
- 배포조정
- 고객이 비지니스 가치를 가장 높일 수 있는 방향으로
우선순위를 조정하고 배포를 조정할 수 있어야 한다
- 추정시간은 반나절 이하로 내려가지는 않도록 한다..
2시간만에 끝냈다면 코드리뷰 및 리팩토링을 한다..
- 반나절 추정을 했지만, 하루 반이 걸렸다..
잠시 시간을 가지고 추정이 틀린 이유와 앞으로의 추정을 위한
의논을 하고 경험을 공유한다
- 추정이 끝나면 담당 프로그래머가 사인을 한다..
확인을 마쳤다는 표시일 뿐이다..

- 작은 배포
- 격주로 한번씩 배포하라, 불가능하면 최대한 자주 배포하라
- 지속적인 고객의 점검이 가능해지며, 피드백을 효과적으로 반영 가능

- 인수테스트
- 중간중간 테스트를 게을리하지 말아라
- 고객이 인수테스트 명세를 결정한다
- 테스트를 뒤로 미루면, 테스트기간을 모두 개발에 할당해도
프로젝트는 지연된다. 이유는 간단하다. 프로그래머가 기억을
못하기 때문이다.. 프로그래머도 사람이다.. 프로그래머가 영원히 
모든 것을 기억할 것이라는 기대는 하지 않는게 좋다..
만들고 나서 바로 모든 테스트를 마치는 것이 가장 효과적이다..
테스트를 바로 하라
- 작은 배포로 인해 테스트를 자주 할 수 있는 기회를 놓치지 마라
- 테스트를 최대한 자동화 하라 

- 신속한 설계회의, 단순한 설계, 코드품질
- 단순한 설계 : 어느 순간에라도 설계는 현재의 스토리만 가까스로
충족시킬 수 있도록 단순화하라. 앞으로의 스토리에 집중하지 마라
앞으로의 스토리는 리팩토링이 충족시켜 줄 것이다.
- 회의를 길게하지마라.. 30분을 넘기지 말고, 서서해라..
서서하면 회의가 금방 끝난다..

- 프로그램 작성
- 짝 프로그래밍
- 모든 소스코드를 두명이 같이 작업하도록 하라
- 짝과 같이 작업을 하고 짝을 자주 바꿔라. 하루에도 몇번씩 바꿔라
- 심각하고 어려운 순간에만 사용하지 말고 항상 짝 프로그래밍을 하라
- 해보면 안다. 양적/질적 모두 더 나은 코드를 만든다
- 같이하면 덜 지치고, 짝 두명 모두 코드를 이해하게 된다
- 드라이버는 키보드를 직접 다루고, 파트너는 옆에서 일을 거든다
그냥 쳐다보는 것이 아니라 코딩에 적극 개입을 한다
- 팀 지식은 더 빨리 성장하고 일은 더 재미있어진다
- 코드 공동 소유
- 모든 개발팀원이 모든 소스를 관리하도록 하라. 모든 사람에게서
서로 배우게 된다.
- 모든 것을 소유하고 있으면 문제가 생기면 자로 자신이 수정할 수
있다..
- 지속적 통합
- 중앙 소스관리 시스템을 가지고 하루에도 몇번씩 통합하도록 하라
- 테스트를 뒤로 미루지 않기 위해 지속적으로 통합해야 한다
- 통합/테스트를 뒤로 미루면 고생은 2배가 된다. 미루면 미룰 수록
고생스러워진다..
- 10주 전에 작성된 소스코드에서 버그의 원인을 찾는것은
1주전에 찾는것보다 10배 이상 어려운 일이다..
- 단순한 설계
- 현재 필요한 만큼만 만든다
- 내일을 위해 미리 복잡한 알고리즘을 도입하지 말자
- 최대한 단순하고 명확하게 설계하도록 하자
- 단순함은 생각하는 것보다 복잡하다. 하지만 그만큼의 가치가 있다 
- 리팩토링
- 지속적으로 코드리뷰를 하고, 코드를 수정하라, 유연성이 확보된다
- 수정을 하는것을 두려워하는데, 단위테스트가 잘되어 있으면
두려운 일이 아니다
- 단위 테스트 주도 프로그래밍을 하면 디버깅 시간을 줄이고
효율적인 설계를 할 수 있다..
- 의도적으로 테스트 먼저 작성한다 (TDD - Test Driven Development)
150~165페이지에서 잘 설명되고 있다
- 코드작성 표준
- 미리 스타일을 정해둔다
- 모든 팀원들이 같은 스타일로 코딩하도록 노력하자
- 코드 공동소유에 도움이 된다
- 처음엔 획일적으로 느껴지겠지만, 그만큼의 보상을 받는다
- 자기의 개선을 표현하고자 하면 소스코드에 하지말고 의상에 하라

- 인수테스트, 단위테스트, 테스트, 테스트, 테스트
- 테스트 프로그램부터 작성하라. 프로그램의 규모가 커지면 커질수록
위력을 발휘하며, 수정을 두렵지 않게 만들어줄 것이다.
- 미친병아리 주 : 책에서는 JUnit에 대해서만 다룬다..
찾아보면 CppUnit이라고 C++을 위한 테스트 프레임워크도 존재한다 

- 진도관리
- 누구나 진실을 알 수 있도록 실제 진행상황을 팀, 관리자, 고객이
모두 알 수 있도록 해주는 아주 간단한 보고서 몇개만 사용한다
- 그 예로
- 완성된 스토리와 남은 스토리 비교 그래프 (p.185)
- 품질점검 : 단위테스트 점수 (p.187), 인수테스트 점수 (p.188),
일일 인수테스트 점수 (p.189) 등등
- 복잡한 보고서는 집어치우자
프로젝트 성공에 도움이 안되는 문서는 만들지 마라

- 결함처리
- 결함처리에만 전념하는 프로그래머를 따로 두어 급변하는 스케쥴에
따라 지원과 수정작업을 하도록 할 수 있다
- 항상 좋은 것은 아니다..
결함을 통한 피드백이 줄어들 수 있으므로, 문제를 피하려는 동기를
잃지않도록 한다
- XP 팀은 짝 프로그래밍을 하지 않은 곳에서 많은 결함을 발견하곤 한다
대부분, 전문적인 부분에서는 짝 프로그래밍을 중단하기 때문이다
- 결함보고를 받으면 단위테스트를 더욱 견고하게해 사전에 알아낼 수
있게 한다던지 등등 적극적인 조치를 취한다..



- 쉬어가는 페이지
- 프로그래머에게 가장 큰 완료 종지부는 성취감이다
- 이러한 성취감은 모든 팀원, 회사, 파트너 모두에게 전파되고
같이 느낄 수 있도록 하자
- 반복주기를 짧게 하고, 완성 / 종료됨을 같이 기뻐하고 즐겨라
아무리 작은 선물이라도 주면 더욱 좋다
- 프로젝트는 오랜 시간 지속될 것이다.. 중간중간 성취감을 느낄 수
있는 여유를 갖는게 좋다
- 주당 40시간 이상 일하지 마라
- 일할때 집중해서 일하고 가장 효율을 낼 수 있는 근무시간을 정해라
대략 하루 6시간 이상 집중해서 일하기 힘들다



* 보너스 주제 (한번 생각해볼만한 내용들)

- 해보겠습니다
대부분의 경우 이 말은 절대 맞출 수 없는 완성일을 지키기 위한
혹독한 수개월 간의 서문이다..
서로를 미워하게 되고 프로젝트가 끝나 제대로 돌아가도 성취감을 얻지 못한다

- "날 아무도 방해하지 않고, 혼자 내버려 둔다면 하루면 이일을 끝낼 수 있지"
XP 팀에서는 이를 완전작업일 (Perfect Engineering Day)라고 한다
여기에 다음 세가지를 더하자
1. 우리가 해야하는 모든 일에 대해 알아야 한다
2. 각각의 일에 대해 위와 같은 확신을 가져야 한다
3. 완전작업일이 실제 날짜로는 몇일이 걸리는지 알아야 한다

- 만약 모든 스토리를 다 가지고 있지 않으면 어떻게 하지 ?
- 조정을 통해 중요하지 않은 스토리의 추정은 뒤로 미룬다

- YAGNI : You Aren't Gonna Need It (XP 슬로건)
- 자주 논쟁거리가 되는 말이다.
- 우리가 필요할 것이라고 생각하는데 집중하지 말고,
현재 스토리에 더 집중하라
- XP의 모든 프로세스는 고객의 비지니스 가치를 높여주는데
집중해야 한다

- 무엇인가가 잘못되었을때, 누군가 비난할 사람이 필요한가 ?
- 아무나 "내 잘못이다" 라고 소리치고 이런 마녀사냥을 끝내라
- 중요한건 누구 잘못인가가 아니라 어떻게 해결할 것인가,
현재의 일이다.

- 희망과 두려움의 균형잡기
- 두려움 때문에 미루거나 덮어두려고 하는 것 보다는
터놓고 이야기해 접근방법을 찾는것이 문제해결에 도움이 된다

- 잘못될 수 있는 모든 것을 테스트하라
- 모든 내용을 테스트 하라는 이야기는 아니다..
- 다만, 잘못된 가능성이 있는 부분은 빠지지 말고 테스트하라



특히 책 맨 마지막 부분의 저자와의 인터뷰 내용중에..

당신에게 급여를 주는 사람들이게 실질적인 가치를 산출해 내는데
집중하세요. 매일 그들이 이해할 수 있는 가치를 제공해야 합니다.

라는 대목은 인상적이었습니다