y. u. m

말잘하는 능력은 타고난다고. 아니다. 말 잘하는 능력은 학습에 의해 키워나갈 수 있는 능력이다.

머리엔 정보로 가득채우고, 가슴엔 자신감이 충만하다면 어떤 자리에서 누굴 만나도 말 잘하는 사람으로 인식될 수 있을 것이다.

다시 강조하는데, 우리가 습관으로 익혀야할 말 잘하는 능력은 단순한 언변이나 에드립이 아니다. 입으로만 말하는게 아니라 머리로 말하는 능력이 필요한 것이다.

첫째, 다른 사람의 얘기를 잘 들어야 한다.
말 잘하는 사람치고 남의 말을 경청하지 않는 사람은 없다. 상대가 무슨 말을 하는지를 제대로 들어야, 자신도 그에 맞게 적절한 말을 할 수 있지 않겠는가. 그리고 이렇게 경청하는 매너는 상대로 하여금 호감을 주기에 충분하고, 자신의 말도 상대가 경청하게 하는데 효과적인 방법이다. 잘 듣는 것이 곧 잘 말하는 것의 시작인 것이다.

둘째, 시나리오 능력이 뛰어나야 한다.
머릿속에서 즉흥적으로 떠오른 말을 입으로 내뱉는데에는 한계가 있다. 말 잘하는 사람들은 대개 미리 시나리오를 그려보고 말을 한다. 프레젠테이션이나 회의를 앞두고 미리 머릿속으로 내가 어떻게 얘기하면, 상대는 어떻게 얘기할 것이고, 그럼 난 어떻게 얘기해야겠다는 등을 미리 그려보는 것이다. 그러면 훨씬 체계적이고 논리적인 말하기가 될 수 있을 것이다.

무조건 생각나는걸 입으로 내뱉기전에, 한번 머릿속에서 생각하고 판단해보라. 그러면 말이 너무 느려지지 않겠나고. 걱정마라. 연습을 통해 그렇게 말하는 것이 익숙해지면 1초 사이에도 머릿속에서 여러개의 문장을 되새김해볼 수 있게 될 것이다.

셋째, 자신감을 가져야 한다.
말하는 능력에서 자신감은 50% 이상을 차지한다. 그렇다고 틀리거나 부정확한 얘길 자신감있게 해서는 안된다. 정확한 얘기를 자신있게 하면 상대로 하여금 훨씬 더 높은 신뢰감을 얻게 된다. 아울러 설득도 쉽게 된다. 같은 말이라도 자신있게 하는 것과 그렇지 않은 것은 차이가 크다. 절대 끝말을 흐려서도 안되고, 부정확한 발음이어도 안된다. 또박또박하게 자신의 말을 정확하게 자신있게 전달하도록 노력해라. 어차피 말하는 것으로 먹고사는 사람이 아니지 않는가.

말하다 조금씩 실수한다고 뭐라고 할 사람도 없다. 자신감만 가지고 과감하게 말하는게 필요하다. 그렇다고 큰소리 뻥뻥치란 얘기는 아니다. 자신감은 소리가 크고 작고의 문제가 아닌, 명확하고 당당함의 문제인 것이다.

넷째, 신속한 정보수집력이 필요하다.
새로운 얘기는 듣는 사람으로서도 집중을 잘하게 한다. 다들 아는 식상한 얘기를 거론하는 것이나 했던 얘기 또하고 또하는 것은 곤란하다. 정보수집력은 말잘하는 사람의 필수자질이다.

특히 유행하는 트렌드나 이슈, 그리고 유머 등은 정보수집 능력에 비례해서 말잘하는 능력이 가늠되는 것이다. 자신만의 정보수집 경로를 만들어두고, 꾸준히 새로운 정보를 업데이트해 나가는 것이 필요하다.

매일 주요 신문을 보는 것은 기본이고, 전문분야 잡지는 꼭 구독해서 가치있는 정보를 확보해야 하며, 필요한 뉴스레터는 꼬박꼬박 챙겨서 받기도 해야한다. 특히 차를 타고 이동할 때 라디오의 시사프로그램이나 교양프로그램을 청취하는 것도 도움이 된다.

다섯째, 말 할때는 신중해야 한다.
말은 글과 다르게 한번 내뱉으면 주워담거나 고칠 수가 없다. 계속 줄줄 떠든다고 말잘하는게 아니다. 그런 말빨은 나이트클럽에서나 써먹을 수 있을뿐 그리 쓸만한데가 많지는 않다. 필요한 말을 신중하고 적절하게 잘하는 것도 중요하다. 말을 많이 하지 않더라도 충분히 말 잘하는 사람이 될 수 있다는 얘기다.

여섯째, 아는 것이 많아야 한다.
자신이 알고있는 분야의 얘기를 할 경우에는 말이 많아지게 되고, 말도 술술 자연스레 풀리게 된다. 누구나 공감하는 얘기일 것이다. 그렇다면 자신이 하는 일이나 전문분야에 대해서는 상대보다 더 많이 알도록 준비하는 것이 필요하다.

대개 말을 잘 못하는 사람이라 하더라도 특정 분야에 대해서는 상대적으로 말을 더 잘하는 경우를 보게된다. 대개 그 특정분야라고 하는게 자신의 관심사에 해당되는 분야이다. 연애나 술 얘기에는 침튀기며 얘기하다가도, 정작 필요하고 중요한 얘길 해야할 자리에선 말을 잘 못한다는 사람은 반성해야 한다. 그런 사람들은 자신의 관심사를 좀더 생산적이고 전문적인 분야로 옮겨보도록 노력해야 한다.

일곱째, 여유가 있어야 한다.
우선 앞에서 제시한 여섯가지 요소를 갖춘다면 여유를 가지고 말을 해야 한다. 조급해지면 말도 빨라지고, 해야할 말도 놓치게 된다. 여유를 가지고 말한다면 훨씬 더 조리있고 차분하게 상대를 설득시킬 수도 있을 것이며, 유머나 재치도 자연스레 나온다.

말하는 간간히 섞여나오는 유머는 상대를 집중시키는데 효과적이다. 절대 말 할때 흥분하지 않도록 스스로에게 여유를 가지도록 당부해야 하고, 말하는 템포도 스스로가 적절히 조절할 줄 알아야 한다.

말하는 것은 상대방과의 커뮤니케이션이다. 일방적으로 속사포처럼 떠들고 사라진다면 그건 말을 한 것이 아니라 소음을 만든 것이다. 최대한 밝은 미소와 여유로운 말이 훨씬 더 말 잘하는 사람으로 만들어줄 것이다.

아는 것은 싸움의 절반에 해당한다. 내가 하는 실수를 제대로 알고 있다면, 고치는 것은 시간문제다. 초보와 베테랑 개발자 모두 전체 프로젝트의 진척에 방해가 될 수 있는 업무의 측면에 대해 잘못 알고 있는 경우들이 많다. 범하기 쉬운 실수들을 왜 미리 살펴봐야 하는지 알아본다.

필자는 최근 중급, 초보 개발자들과 함께 일해 왔는데, 베테랑 개발자를 포함해 모든 개발자들이 주의하지 않는다면 쉽게 빠질 수 있는 오해의 함정들을 몇가지 발견하게 됐다. 여기에는 적절한 도구의 선택에서부터 웹 서비스의 적절한 사용법에 이르기까지 다양한 아이디어가 포함된다.

개발자들이 갖기 쉬운 6가지의 오해에 대해 설명한다.

1. 닷넷 애플리케이션 개발을 위해서는 비주얼 스튜디오 닷넷이 필수적이란 생각.

이런 생각을 했다면, 버려라. MS 닷넷 개발을 처음 접해본 사람들은 닷넷 프레임워크를 이용한 애플리케이션 개발을 위해 비주얼 스튜디오 닷넷이 꼭 필요하다는 오해를 하기 쉽다. 이는 사실이 아니다. 단지 MS 웹 사이트에 있는 닷넷 프레임워크를 무료로 다운로드받기만 하면 된다.

닷넷 프레임워크를 설치한 후 좋아하는 텍스트 편집기와 커맨드-라인 닷넷 도구를 사용하면 된다. 또한 샤프디벨롭과 같은 서드파티 개발 도구를 써도 된다.

비주얼 스튜디오 닷넷의 대안에 관한 보다 자세한 논의를 담은 이전 기사를 참고하면 좋다. 개발도구 선택은 개인적인 취향에 달려있지만 많은 개발 팀들은 협업을 단순화하기 위해 도구를 표준화한다.

2. 내가 습득한 정보, 꼭꼭 숨기기

개발자들이 갖는 독특한 특징의 하나는 정보를 모으는 것이다. 타인이 모르는 것에 대해 알 수 있는 능력은 종종 중요성에 대한 잘못된 인식을 키우게 된다. 반대로 이런 정보를 공유하게 되면 그룹 전체의 지식이 확대되므로 팀에 도움이 된다. 또한 공유된 개념은 다른 팀 멤버의 의견에 따라 발전할 수도 있다. 이 것은 오픈소스 운동의 핵심 측면이기도 하다. 마지막으로 다른 개발자나 개발자들에게 어떤 개념이나 아이디어를 설명하게 되면 많은 경우 당신의 지식도 커진다.

팀워크는 애질 소프트웨어 개발(Agile Software Development)와 같은 운동에 있어서 추진력이 된다. 또한 많은 그룹이 동료가 작성한 코드를 리뷰하고 조언을 주고 있다. 이런 행위는 양측이 서로 배우고 이해를 넓히는 역할을 한다.

3. 코드에서 코멘트 빠뜨리기

코드에 코멘트를 하는 것은 쉬우면서도 단순한 절차이다. 그렇다면 왜 코멘트가 자주 간과되고 무시되는가? 일부 개발자들은 어떤 형태로든 문서화를 하지 않는다면 일자리를 유지하는데 도움이 된다고 생각한다. 이는 바로 전에 다룬 정보 공유에 관한 오류와 밀접한 관계가 있다.

몇 군데 잘 배치된 코멘트는 코드의 판독성과 관리성을 향상시킨다. 그런데 코멘트가 남용될 수도 있다. 기본적으로 코드의 목적, 변수, 메쏘드 등을 짧게 설명하는 코멘트가 있으면 된다. 많은 그룹들은 코드에 변화가 생기면 코멘트를 삽입하기를 원한다. 이는 문제가 생겼을 때 변화의 내용을 파악하기 쉽게 한다.

4. 버전 컨트롤 시스템의 가치를 간과하는 것

많은 개발자들이 다음과 같은 시나리오를 너무나 잘 알고 있다. 중요한 웹 애플리케이션의 새 버전을 내놓았다. 그런데 웹 사이트의 문제점을 항의하는 전화가 다음날 아침부터 줄지어 날아든다.

개발자가 한두 가지 실수를 범했다는 것을 수용할 용의가 있다면, 버전 컨트롤 시스템은 이런 상황에서 최고의 친구가 될 수 있다. CVS, IBM 래쇼날 클리어케이스, MS 비주얼 소스세이프와 같은 버전 컨트롤 시스템을 사용함으로써 기존 버전의 애플리케이션으로 쉽게 돌아가서 이를 기반으로 제품을 생산할 수 있다. 이는 제품 사이트가 가동되는 것과 병행해 개발 환경 내에서 문제를 찾는데 필요한 시간을 벌 수 있도록 해준다. 이는 문제를 찾기 위해 제품 코드를 미친 듯이 찾는 것을 방지한다.

또한 소스 컨트롤 시스템은 병행 개발을 가능하게 하므로 팀 멤버들이 동일한 코드를 작성할 수 있다. 개발자들이 시스템에 변경된 사항을 입력하면 이들 변경사항이 한꺼번에 통합된다.

일부 개발자들이 버전 컨트롤 시스템을 싫어하는 한 가지 이유는 개발 절차에 있어서 하나의 계층을 추가하기 때문이다. 소스 컨트롤 시스템에 코드를 제출하고 추출하는 것이 시간을 잡아먹을 수 있다. 이런 시간이 일부 개발자들의 인내심을 시험할 수 있다.

5. 웹 서비스가 모든 프로젝트에서 필요하다는 생각

웹 서비스에 대한 모든 감언이설 때문인지 많은 개발자들은 프로젝트를 시작하면서 어떤 형태로든 웹 서비스를 사용해야겠다고 생각한다. 웹 서비스가 필요하거나 적절한 방법일 수는 있지만 무조건 써야 되는 것은 아니다. 상황을 분석해 웹 서비스의 구현이 적절한지 검토할 필요가 있다. 예를 들어 원격화와 같은 기술이 보다 적절할 수도 있다.

6. 데이터 확인의 중요성을 자주 잊는 것

데이터는 애플리케이션에서 다양한 방식으로 처리되고 조작된다. 이런 이유 때문에 개발자들은 데이터의 무결성과 유효성을 개발과정에서 확인해야 된다. 데이터는 널 문자를 리턴할 수 있는 백엔드 데이터베이스로부터 읽혀질 수도 있다. 널 문자는 대부분의 경우 예외상황 (exception)을 발생시키므로 실행을 계속하기 전에 데이터는 검사돼야 한다.

당신이 초보 개발자이거나 베테랑 개발자이거나에 상관없이 개발자들이 여섯까지 오해에 빠지기 쉽다는 것을 잘 알아야 한다. 심지어 이런 나쁜 습관에 당신이 빠지지 않는다고 해도 다른 팀원들이 이들 함정에 빠질 수 있다. 잠재적 실수에 대해 경각심을 가진다면 팀 프로젝트를 방해할 수 있는 실수들을 방지하는데 도움이 될 것이다.

누군가를 기다린다는 거 정말 힘들고 외로운 일이예요.
그렇지만 참 설레는 일이야