성공적인 홈페이지 제작을 위해 점검해야 될 사항 15가지

홈페이지를 성공적으로 제작하기 위해서는 다양한 항목들을 점검해야 한다. 디자인, 프로그래밍과 같은 기본사항부터 마케팅, SEO, 콘텐츠 등 부수적인 항목들까지 다양한 부분들을 점검함으로써 보다 완벽한 홈페이지에 가까워 질 수 있다.

1. 도메인

2. 호스팅

3. 디자인

4. 개발(프로그래밍)

5. 개발(프로그래밍)비용을 줄여야 하는 경우

6. 네비게이션 & UI(User Interface)

7. 메인화면(index page)

8. 콘텐츠

9. 마케팅

10. 검색엔진최적화(SEO, Search Engine Optimization)

11. 크로스 브라우저, 크로스 디바이스 – 호환성

12. 모바일 버전 vs 반응형 웹

13. 이미지/폰트 저작권 관련

14. 제작 후 점검사항

15. 예산/비용

1. 도메인

가장 먼저 사이트의 존재를 알리는 것이 도메인이다.

방문 전의 잠재고객은 도메인을 보고 사이트의 내용을 짐작한다.

· 도메인은 짧고 외우기 쉬운 것이 좋다

· 최상위 도메인은 .com 혹은 .co.kr을 사용한다.

· 도메인에 ‘키워드’를 포함시킨다.

- 예) www.bluejeanshop.com

- 청바지 전문몰인 경우 핵심키워드인 ‘bluejean’을 포함시킨다.

  도메인만 봐도 어떤 사이트인지 알수 있다. 이해가 쉬운만큼 기억하기도 쉽다

- 검색결과 상위노출에 유리하다

- 검색엔진은 검색어가 ‘청바지’일때 ‘bluejean(청바지)’이 포함된 도메인이 연관성이 크다고 본다.

· 하위 경로에도 키워드를 포함시킨다.

- 예) www.bluejeanshop.com/skinnyjean/

  폴더(경로)명 또한 해당 키워드를 활용한다.

- 경로만 봐도 제품 카테고리, 현재위치를 알 수 있다.

- 검색결과 상위노출에 유리하다

· URL scheme 의미론적이어야 한다.

- 카테고리명과 폴더명을 같게 한다.

- 카테고리명과 폴더명 모두 연관성 있는 키워드를 적용한다.

· 가급적 하이픈(-)이나 숫자는 포함시키지 않는다.

2. 호스팅

호스팅의 선정기준은 속도와 안정성이다. 그외에 개발/운영시 필요한 기능, 프로그램 지원여부, 부가서비스 등을 고려해서 선택한다.

· 다국어 제작시 문자셋은 uft-8로

- 일어, 중국어 등 외국어 버전까지 운영할 계획이라면 euc-kr 대신 utf-8 서버를 선택한다.

- euc-kr 사용시 한글과 영어 외의 언어는 글자가 깨진다.

· 자동백업 기능

- 자동으로 파일을 백업하여 실수로 파일이 삭제된 경우 몇일전 상태로 복원시키는 기능.

· 회선속도/로딩속도

- 호스팅 회사의 호스팅 서비스를 이용중인 사이트를 방문해서 실제 로딩속도를 점검한다.

· 서버 OS버전, 지원 프로그램, DB환경, 이메일 계정 지원 여부 등 개발/운영 환경에 따른 고려가 필요하다

3. 디자인

시각적인 아름다움과 함께 정보전달, 편의성을 고려한다.

· 미학적으로 아름다운가?

- 이미지 요소의 질이 높을 수록 좋다.

- 이미지 요소 = 사진, 일러스트, 아이콘, 타이포크라피

· 디자인 컨셉이 사이트 목적에 부합하는가?

- 사용자에게 줘야 하는 느낌, 사용자가 가져야 할 감흥을 명확히 규정한다.

/캐주얼복을 판매하면서 어둡고 고풍스러운 느낌을 줘선 안 된다.

/앤티크 가구를 판매하면서 가볍고 발랄한 느낌을 줘선 안 된다.

· 중요한 요소들이 부각되고 있는가?

- 중요한 요소일 수록

/눈에 잘 띄어야 한다.

/사이즈가 커야 한다.

/색상이 강렬해야 한다.

/볼륨감 있어야 한다.

/반복적으로 보여야 한다.

· 테마가 되는 색상이 정해져 있으며 일관되게 적용되고 있는가?

· 강조, 기능을 위한 색상 규칙이 정해져 있으며 잘 지켜지고 있는가?

· 링크가 걸려 있는 텍스트가 밑줄이나 색상 등 외형적으로 강조되고 있는가?

· 텍스트의 가독성이 충분히 확보되어 있는가?

· 중요한 문장들이 위치, 크기, 색상에 의해 시각적으로 부각되고 있는가?

4. 개발(프로그래밍)

정보전달 위주의 사이트인지 기능(서비스) 위주의 사이트인지에 따라 개발 유무, 개발 규모가 결정된다.

· 기능(게시판, 회원제 등)이 필요 없고 단순히 이미지와 글을 보여주는 정도라면 html 만으로 제작이 가능하다.

· 기능이 요구된다면 사이트의 규모, 운영목적 등을 고려하여 적합한 개발언어를 선택한다.

· 저예산의 소규모 사이트라면 기능/보안 문제로 고민하기보다 비용기준으로 선택해도 큰 문제가 없다.

- 주로 사용되는 언어들(php, asp, java 등)은 기능/보안 상에 치명적인 취약점을 가지지 않는다.

- 비용이 저렴한 php의 경우 상대적으로 기능/보안에 취약점이 있다고 하지만 야후나 페이스북, 워드프레스 등의 제작에 사용되고 있다.

5. 개발(프로그래밍)비용을 줄여야 할 경우

저예산으로 프로젝트를 진행할 경우 개발비용을 줄이기 위해 아래의 옵션들을 선택할 수 있다.

· 웹사이트에 기능을 포함시키지 않는다.

· wordpress, XE 등 설치형 블로그나 CRM을 사용한다.

· 호스팅社에서 제공하는 ‘홈페이지 빌더’를 사용한다.

6. 네비게이션 & UI(User Interface)

네비게이션 & UI는 철저하게 사용자 입장에서 체크되어야 한다.

어떤 화면에서도 원하는 다른 화면으로 손쉽게 이동할 수 있어야 하고 필요한 정보를 직관적으로 발견할 수 있어야 한다. 사용자 편의성에 기초한 점검사항들을 확인해 보자.

· UI 기본원칙은 일반적으로 통용되는 방식을 따르는 것이다.

- 로그아웃 버튼은 보통 화면 상단에 위치한다. 대부분의 사이트가 따르는 이 원칙을 어기고 엉뚱한 곳에 배치할 경우 사용자는 로그아웃 버튼을 찾아 헤   맨 시간만큼 이 사이트를 싫어하게 된다.

· 네비게이션의 메뉴명이 정확한 의미를 보여주는가?

-메뉴명이 ‘위탁판매’라면 위탁받은 제품을 팔겠다는 건지 제품을 위탁받겠다는 건지 불분명하다

-‘위탁판매제품’, ‘위탁판매접수’와 같이 메뉴명의 의미를 명확히 해줘야 한다.

-불분명한 메뉴명은 클릭률이 떨어진다.

· 앵커텍스트가 정확한 의미를 보여주는가?

-링크가 걸려 있는 텍스트(앵커텍스트) 또한 의미가 명확해야 클릭률이 높아진다.

· 네비게이션 구조, 카테고리 구조가 직관적이고 논리적인가?

· 네비게이션이 이미지나 플래쉬로 되어 있다면 하단쪽에 사이트 전체에 대한 텍스트 링크를 걸어 주는 것이 좋다.

· 각 페이지마다 제목 바로 밑에 현재위치(bread crumbs)가 표시되어 있는가?

· 깨진 링크, 없는 페이지에 접속이 시도된 경우 자체 제작된 404 page를 통해 대체 페이지 혹은 메인페이지로의 링크롤 제공하는 것이 좋다.

· 아크로뱃이나 어도비, 자바 등의 미디어 재생을 위해 플러그인이나 응용프로그램이 필요한 경우 해당 프로그램의 링크를 걸어 준다.

· 텍스트 위주의 콘텐츠인 경우 본문에 대한 ‘인쇄’ 버튼을 제공한다.

· 사이트맵을 제공한다.(가급적 이미지가 아닌 텍스트 링크를 사용하는 것이 SEO에 유리하다)

· 사이트 규모가 클 경우 ‘사이트 내 검색’ 기능을 포함시킨다.

7. 메인화면(index page)

메인화면은 사이트 내용을 요약해 보여주면서도 구성이 간결한 것이 좋다.

· 화면 구성이 무조건 간결해야 하는 것은 아니다.

-방문 목적이 다양하다면 목적에 부합하는 항목들로 다양하게 구성하는 것이 더 효율적이다.

/방문 목적이 상담이라면 상담전화 번호가 표시되어야 한다

/방문 목적이 구매라면 주요 제품에 대한 바로구매 버튼이 있어야 한다

/이벤트 참여가 목적이라면 이벤트 안내가 보여져야 한다.

/배송정보가 목적이라면 ‘배송확인’ 아이콘이 보여져야 한다.

-메인화면이 간결한 경우는 방문자들의 목적이 거의 한쪽으로 편중된 경우다.

· 신규방문자를 위해 ‘우리가 누구이고’, ‘무슨 일을 하며’, ‘무엇을 제공할 것인지’를 알려줘야 한다.

· ndex page (메인페이지)만 보고도 사이트 주요내용을 알수 있도록 명확한 메시지를 전달해야 한다.

· 메인페이지에서 중요한 페이지로 연결되는 링크를 시각적으로 부각시켜야 한다.

8. 콘텐츠

온라인 상에서의 콘텐츠는 대부분 ‘텍스트(글)’로 되어 있다. 이미지와 영상은 보조적인 역할을 한다. 좋은 정보를 담고 있는 양질의 글은 그 정보가 필요한 사람들을 웹사이트로 불러들인다.

· 문구는 간결하면서도 정확하게 정보를 전달해야 한다.(길고 난해한 문장을 찾아서 알기 쉽게 수정할 것)

· 문단의 구분, 제목, 소제목, 강조문구 등의 역할

-대충 훑어 봐도 이해가 가능해야 한다.

-본문 전체를 훑어 볼 때 문단, 제목, 소제목, 강조문구 등이 요약된 내용을 전달한다.

· 정보나 주장에 대한 근거를 뒷받침 하는 간단한 인용문이나 인용원문에 대한 링크를 제공한다.

· 소셜공유, RSS피드를 통해 콘텐츠를 전파한다.

· 사이트 내에서의 블로그 운영

-주소도 다르고 인터페이스도 다른 블로그를 운영할 경우 블로그 방문자를 웹사이트로 유입시키기 어렵다.

/예) 사이트 주소가 www.bluejeanmall.co.kr 이고 블로그가 blog.naver.com/bluejeanmall 일 경우 웹사이트와 블로그 사이에 거리감이 있다.

/예) 사이트 주소가 www.bluejeanmall.co.kr 이고 블로그가 www.bluejeanmall.co.kr/blog 일 경우 웹사이트와 블로그가 같은 도메인과 인터페이스를 가지므로 거리감이 없다.

/블로그 방문자는 콘텐츠(정보) 소비자이고 웹사이트 방문자는 제품소비자다. 블로그 방문자를 콘텐츠 소비자에서 제품 소비자로 전환(conversion)시키는데는 웹사이트 내에서 블로그를 운영하는 것이 더 유리하다.

/그럼에도 불구하고 마케팅 측면에서는 사이트 내의 블로그보다 네이버 블로그가 더 유리하다. 사이트 내에서 운영되는 블로그보다 네이버 블로그가 네이버에서 더 많이 노출된다.

/반대로 사이트 내에서 운영되는 블로그가 구글 상위노출에 유리하다.

9. 마케팅

마케팅 요소들을 적소에 배치해서 방문자가 웹사이트를 주변에 알리거나 제품을 구매하도록 유도할 수 있다.

버튼이나 아이콘, 링크, 네비게이션 등 고객의 행동을 유도하는 장치(콜투액션:call to action)와 고객에게 신뢰를 주는 내용이 이런 역할을 한다.

· 콜투액션을 통해 고객의 기대행동을 분명하게 제시 혹은 유도하고 있는가?

· 페이지 타이틀과 본문의 도입부 : 검색결과에 제목과 미리보기 형태로 보여지므로 클릭을 유도할 정도로 흥미로운 문구를 작성해야 한다.

· 고객의 피드백 창구가 충분한가?

· 방문자에게 신뢰를 주고 있는가?

-주소, 연락처, 블로그, 소셜은 물론 회원증, 인증서, 수상경력, 연혁, 거래처, 협력사, 연도별 실적, 포트폴리오 등 신뢰를 줄수 있는 항목을 누락시키지 말것

· 즐겨찾기 버튼

-즐겨찾기 해놓고 사이트에 접속하는 직접 방문자 많은 경우 검색엔진 상위노출에 유리하다

-즐겨찾기 버튼은 일종의 ‘콜투액션’이다. 즐겨찾기 등록을 유도한다.

· 파비콘

-즐겨찾기모음에서 파비콘은 시각적으로 두드러지고 사이트의 존재감을 높인다.

· SNS 공유 버튼

· 홈페이지빌더로 제작할 경우 sitemap.xml 파일 업로드나 로그분석, 전환추적을 위한 스크립트의 삽입을 제한하고 있는지 확인할 필요가 있다.

· 구글/빙 웹마스터 도구 등록, 네이버/다음 사이트 등록

· 구글 애널리틱스 등록

· RSS피드 등록

10. 검색엔진최적화(SEO, Search Engine Optimization)

검색엔진최적화는 아래의 기술적인 항목들에 의해 구현되지만 보다 중요한 것은 콘텐츠의 질을 높이고 웹페이지를 부지런히 알리는 것이다.

· title, h1 태그 안에 연관성 있는 키워드 포함

· 키워드 연구

· 메타태그 – title, description, keyword

· semantic markup (h1 등)

· sitemap.xml

· robots.txt

· User-friendly & Search Engine-Friendly

· Alt 태그

· 구글 웹마스터도구 등록

· 구글 애널리틱스 등록

-SEO는 제작단계에서 시작하는 것이 좋다.

-도메인, 카테고리명, 제목, 본문, UI 등 대부분의 사이트 구성요소가 SEO의 영향을 받는다.

-제작 후에 SEO를 진행하면 사이트 구조 자체를 변경해야 할 수도 있다.

· 검색엔진 최적화의 본질적인 부분은 태그가 아니라 콘텐츠와 홍보에 있다.

-양질의 콘텐츠를 생성하고 카페, 커뮤니티, 동호회 등 연관성 있는 사이트에 링크를 퍼뜨린다.

-생성된 콘텐츠는 사이트, 블로그, 트위터, 페이스북, 카페 등 다른 매체에 재활용한다.

-블로그의 경우 구글 대상 블로그(워드프레스)와 네이버 대상 블로그(네이버 블로그)를 같이 운영하고 하나의 콘텐츠를 중복 게재하는 것이 효과적이다. 서로간의 크롤링이 배타적인 관계에 있다. 구글에는 네이버 블로그가, 네이버에는 워드프레스가 서로 잘 노출되지 않는다.

11. 크로스 브라우저, 크로스 디바이스 – 호환성

어떤 환경에서 접속하더라도 화면이 깨지거나 UI 편의성, 기능요소들이 나빠지지 않도록 한다.

· 호환성 점검항목

-화면 레이아웃이 깨지지 않는지

-글자가 너무 크거나 작지 않은지

-UI(User Interface)가 편의성을 제공하는지

-기능요소(게시판, 입력폼)가 제대로 기능하는지

-이미지, 동영상이 옳바로 로드되지 않을 때 대체요소가 사용되고 있는지

/이미지 대체요소 – alt, title 태그

/동영상 대체요소 – caption 태그

· 호환성 점검 대상

-브라우저 : Internet Explorer, Chrome, Safari, FireFox 등(버전 별로도 체크 필요)

-디바이스 : 데스크탑, 태블릿, 스마트폰

-운영체제(OS) : Windows, Linux, Mac 등

-해상도 : 태블릿, 노트북 등 화면해상도가 작을 때 div의 overflow 속성에 의해 콘텐츠가 영역 밖으로 새나가거나 숨어버리는 현상이 생기지 않는지 체크.

12. 모바일 버전 vs 반응형 웹

모바일 접속에 대비하는 두 가지 옵션이 있다. 모바일 사이트를 별도로 제작하는 것과 반응형 웹으로 제작하는 것.

모바일 사이트는 PC사이트와는 별개의 사이트를 운영하는 것이고 반응형 웹은 기기별 스타일(CSS)만 다르게 적용시켜서 레이아웃, 글꼴 속성, 이미지크기 등이 화면 해상도에 대응하게 만드는 방식이다. 각각의 장단점을 파악해 보자.

· 모바일 버전

-별도의 모바일 버전 사이트를 운영

/pc 버전과 UI, 레이아웃, 콘텐츠, 도메인 모두 다르다

-낮은 해상도에서 보기 편한 레이아웃, 폰트 스타일(주로 크기), 콘텐츠

-pc버전과 별개로 제작, 운영해야 한다.

· 반응형 웹

-pc버전, 모바일 버전 구분 없이 하나의 사이트 운영

-모바일로 접속할 경우 낮은 해상도에 적합하게 레이아웃, UI, 콘텐츠가 자동으로 변경된다.

-모바일 버전을 따로 제작하거나 관리해야 하는 불편함이 없어진다.

13. 이미지/폰트 저작권 관련

저작권 관련 분쟁은 저작권과 사용권으로 분리되면서 매우 복잡해 진다. 분명한 사실은 제작업체에서 저작권을 위반한 경우 의뢰업체도 곤란해 진다는 것이다.

· 제작업체가 유료 이미지/폰트를 무단 사용한 경우 제작업체에도 법적 책임이 따를 수 있다.

-‘저작권’ 위반에 대해서는 책임이 없으나 결과물의 ‘사용권’에 대해서는 외뢰업체에게 책임이 있을 수 있다.

· 이미지/폰트의 저작권, 사용권으로 인한 문제를 예방하려면

-계약서에 저작권 및 사용권에 문제에 관한 면책 조항, 진술 및 보증 조항을 포함시킨다.(이렇게 해도 100% 안전하지는 않다.)

-무료 폰트를 사용한다.(나눔, 맑은고딕 등)

-상업적으로도 사용가능한 이미지만을 사용한다.

14. 제작후 점검사항

오픈하기전 마지막으로 링크, 기능, 맞춤법 등을 체크하는 시간을 가진다.

마지막 점검단계에서 구성이나 콘텐츠를 바꾸는 큰 수정은 가급적 피하도록 한다. 수정할 기회는 오픈 이후에도 얼마든지 있다.

· 깨진 링크가 없는지

· 메일로 여결되는 링크의 메일 주소, 통화로 연결되는 링크의 전화번호 확인

· 기능요소들 정상 작동 여부

-게시판, 입력폼, 예약 등

· JavaScript 에러 체크

· 호환성 체크 : 브라우저, 디바이스, OS, 해상도

· 맞춤법 체크

-국문 맞춤법 및 문법 체크

/크롬 확장프로그램 ‘바른 말씨’ 아래 링크에서 설치 가능

https://chrome.google.com/webstore/detail/%EB%B0%94%

EB%A5%B8-%EB%A7%90%EC%94%A8/jbeblnocjjhgkbdeocekdmdipkifpakk?hl=ko

-영문 스펠링 체크

/크롬 확장프로그램 ‘Spell Checker for Chrome’ 아래 링크에서 설치 가능

https://chrome.google.com/webstore/detail/spell-checker-

for-chrome/jfpdnkkdgghlpdgldicfgnnnkhdfhocg?hl=ko

15. 예산/비용

디자인비 + 개발비(프로그래밍) + 기획/콘텐츠 제작비 + SEO

· 디자인 비용

-이미지 구매 비용

/제작업체가 보유한 라이센스에 따라 비용이 달라진다.

//제작업체가 외주 작업용 라이센스를 가지고 라이센스 범위 내에서 작업하는 경우 비용이 발생하지 않는다.

//제작업체의 외주 작업용 라이센스 외에 다른 이미지를 사용할 경우 그 이미지의 라이센스에 따라 비용이 발생한다.

/이미지 라이센스에 대한 자세한 설명은 아래 링크 참조

-디자이너 작업비

· 개발(프로그래밍) 비용

-기능요소가 포함될 경우 개발비용이 발생한다.

-기능요소 없이 단순히 정보전달이 목적이라면 개발비용이 발생하지 않는다.

-기능요소의 비중이 적고 특별한 기능이 요구되지 않을 경우 오픈소스나 홈페이지빌더를 활용해서 개발을 대신할 수 있다.

· 기획/콘텐츠 제작 비용

-소규모 프로젝트에서는 작업인원 중 일부가 업무와 상관없이 처리하기도 하지만 규모가 커지면 전문 기획자, 콘텐츠 제작자가 참여해야 한다.

· SEO(검색엔진최적화)

-SEO 없이도 홈페이지를 완성할 수 있다.

-SEO가 반영되면 마케팅이 강화된다.

/SEO마케팅, 콘텐츠마케팅, 바이럴마케팅 등

-프로젝트 종료 후 SEO를 반영할 경우 적지않은 비용이 발생하므로 SEO 계획이 있다면 제작단계에서 진행하는 것이 좋다.

/SEO 작업 중 홈페이지 제작과 연계되는 것들

//도메인, 하위 폴더

//카테고리명

//콘텐츠에 사용되는 키워드, 키프레이즈

//각종 tag의 값 예)keyword, description, title, img

모든 항목을 충족시키는 것은 어려운 일이고 프로젝트의 목적이나 환경에 맞게 선별적으로 적용할 필요가 있다. 특히 예산에 따라 포기할 부분은 과감하게 제외시키는 것이 현명한 방법이다. 예를 들면 콘텐츠 외주제작이나 마케팅, SEO 등은 차후 진행이 가능한 작업들이다. 그외에 필수적인 작업들은 위 항목들을 가이드라인 삼아 작업의 완성도를 높일 수 있을 것이다.

일반인들에게 프로그래밍을 알려주는 온라인, 오프라인 수업 서비스!

https://opentutorials.org/course/1

개발자가 되기 위해 프로그래밍 기술만 있으면 된다고 생각한다면, 틀렸다!

코드를 잘 쓰는 것도 중요하지만, 일의 능률을 높이고 더 높은 연봉을 받기 위해서는 많은 이에게 자신이 누구인지 알리는 것이 중요하다. 다시 말해, 스스로를 마케팅해야 한다. 여기에서 성공적인 셀프 마케팅 방법을 소개한다.

모두의 개발자 팁 No.1 : 블로그 

블로그를 개설 후 한 달에 한 번 이상 포스팅을 올려라. 블로그에 올리는 글은 꼼꼼히 리서치하고, 바보 같아 보이는 말은 하지 않는다. 

농담이 아니고, 개발자들도 정말 작문 실력을 높이기 위해 노력해야 한다. 학교 다닐 때 국어 선생님이 가르쳐준 것들을 활용해보자. 글을 쓰기 전 개요를 작성하고, 서술 기법을 정하고, 문법이나 맞춤법을 확인하는 것 말이다. 

그런 후에는 아깝더라도 필요 없는 부분은 잘라내 지나가는 사람이 한번 훑어만 보아도 무슨 이야기인지 알 수 있을 만큼 단순하게 만들어라. 필자의 글을 읽는 에디터도 마찬가지지만 인터넷에서는 대화문과 같은 '뉘앙스'를 완벽히 전달할 수 없다. 

모두의 개발자 팁 No.2 : 오픈 소스

오픈 소스에 대한 거짓말들을 믿지 마라. 나이가 조금 어린 개발자들은 개발자가 실업자가 될 수 있었던 시절을 기억하지 못할 지도 모르지만, 경제 불황이 아주 최악일 때도 오픈 소스 프로젝트 개발자들은 빠른 시간 안에 일자리를 구할 수 있었다. 

오픈 소스 코드를 만들 때 자신이 원하는 직업이 어떤 것인지를 충분히 반영하기 바란다. 필자는 가능한 한 간단한 솔루션으로 어려운 문제를 해결하려 했지만, 그간 인터뷰해 온 개발자들은, 그들의 오픈 소스 코드에서도 분명히 알 수 있었듯, 간단한 문제를 복잡하게 만들기를 원했다. 

믿거나 말거나지만, 이런 시장도 형성이 되어 있으며 자신이 속한 시장을 반드시 코드에 반영시키기 바란다. 

모두의 개발자 팁 No.3 : 한 직장에 너무 오래 머물지도, 너무 자주 이직하지도 마라 

너무 자주 이직하지 마라. 농담이 아니다. 개발자들의 취업이 어려워지는 시절은 반드시 다시 온다. 그 때가 되면, 잦은 이직만큼 자신을 끈질기게 따라다닐 꼬리표도 없을 거다. 

반면, 한 직장에서 10년 가까이 머물며 한 가지 일만 하는 것도 좋지 않다. 한 곳에 너무 오래 머물다 보면 그 일이 일상화 돼버린다. 자신의 가치를 높이기 위해서는 IBM에서 IBM식으로 IBM 스택 코드를 쓰는 것에 만족해서는 곤란하다. 

필자는 개인적으로도 IBM이나 이와 비슷한 조직에서 1, 2년 이상 머무른 사람은 고용하지 않는다. 이들은 대체로 면접에서는 아주 훌륭한 모습을 보여주지만 프로그래밍 테스트에서 떨어지고 만다. 

모두의 개발자 팁 No.4 : 눈으로는 새로운 것을 추구하되, 실용적인 것에서 손을 놓지 마라

나이가 어린 개발자들은 화려하고 눈에 띄는 일을 좇는 경향이 있다. 필자가 가장 좋아하는 프로그래밍 언어는 루비(Ruby)지만, 루비는 평균적으로 봤을 때 자바(Java)만큼 돈을 많이 받지도 못하고 시장도 더 좁다. 

그렇지만 항상 그런 것은 아니다. 스칼라(Scala)가 강세를 얻고 있는 것처럼 보이지만, 시장 규모는 속일 수 없다. 반면 한 곳에 너무 오래 머무르다가 미래의 코볼(COBOL)이나 파워빌더(PowerBuilder) 개발자가 돼버려서도 곤란하다. 

모두의 개발자 팁 No.5 : 읽는 사람을 배려해 문서를 작성하라 

필자는 회사 임원들이 읽고 한 번에 이해할 수 있는 문서나 프레젠테이션을 만들었다는 이유만으로 프로젝트에 참여하거나 경영진 미팅에 참여하게 된 경험이 수없이 많다. 

필자는 항상 임원진들을 위한 개요를 서두에 작성해둔다. 다시 말해, 꼭 읽어야 하는 페이지는 개요뿐이고 나머지는 개요를 잘 이해하지 못했을 때 읽으면 된다. 이 때 고려해야 할 것은 엄청나게 바쁜 일정을 소화해야 하는 사람에게 이 주제에 대해 얘기하려면 어떤 정보를 골라서 설명해 줘야 하는가다. 

대부분 매니저들은 '누가 일의 진척 상황에 대해 자신을 귀찮게 하지 않고 이 일을 끝까지 이끌어 갈 수 있는가'를 가장 궁금해 한다. 이 부분에 중점을 두고 보고서를 쓰길 바란다.

모두의 개발자 팁 No.6 : 간결성이 생명이다

경영진들을 가까이 하다 보면 바로 알 수 있는 특징 가운데 하나는, 말을 잘 하는 사람일수록 짧고 정확한 답변을 한다는 것이다. 

답변이 길고 복잡해진다는 건 그 사람이 주제에 대해 잘 모르거나 별로 성실하게 일을 하지 않는다는 의미다. 또, 주제의 중요도와 목소리 톤은 반비례하는 것도 사실이다. 

정말 나쁜 소식을 전할 땐 조용히 문을 닫고 들어와 속삭이듯 말하는 법이다. 그다지 중요한 일은 아닌데 그냥 짜증 나는 소식일 경우 격앙된 목소리로 그 문제에 대해 목소리를 높이게 된다. 

중요하지 않은 일에 대해 목소리를 높이는 사람이 되지 마라. 자신이 무슨 이야기를 하는지 정확히 알고, 그 이야기를 어떻게 요약할 지 고민하되 세부적 사항들을 포함시키려 노력해야 한다. 

그렇지만 문장 하나 하나를 전부 세부 사항들을 곁들여 설명할 필요는 없고, 하늘이 무너진 것도 아닌데 작은 일에 호들갑을 떨지 마라(단지 한동안 괜찮은 빌드(build)가 없었기에 젠킨스(Jenkins)를 살펴봐야 할 지도 모를 뿐이다).

말로 하는 게 정 안 되면, 비용으로 승부봐야 한다. 숫자를 신중히 선택해 차트에 기입하고, 비용적인 측면에서 이것이 다른 것보다 더 낫다는 것을 확실히 보여줘라.

모두의 개발자 팁 No.7 : 관중을 놀라게 해라

관중 앞에서 발표하고 프레젠테이션을 잘 하는 방법에 대해 고민하라. 한 가지 주제에 대해 리서치하고 그 주제에 대해서는 '유일한' 권위자가 되지는 못하더라도 '전문가' 정도는 돼야 한다. 여러 사람을 상대로 하는 프레젠테이션은 재미적인 요소가 가미돼 있으면 좋다. 

이런 기술은 낯뜨거운 실수를 몇 번씩 반복하지 않고는 얻을 수 없는 것이다. 

그렇지만 경영진에게 한 주제에 대해 분명한 말로 잘 설명해 낼 수 있고 이에 대해 전문 지식을 가지고 있다면 그렇지 못한 사람에 비해 높은 연봉을 받게 된다는 건 장담할 수 있다.

모두의 개발자 팁 No.8 : 현실적인 개발자가 되라

자신이 설령 얼랑(Erlang)을 좋아한다고 해도, 이 시장은 그다지 크지 않다. 개발자라면 하나 이상의 프로그래밍 언어를 알아야 하며, '새로운' 주제나 새롭게 떠오르는 주제에 대해서도 잘 알아야 한다. 

그러나 충분한 고려 없이 '얼랑이 아니면 코드를 하지 않겠다'는 식의 미숙한 발언은 하지 않아야 한다. 좁은 분야의 전문가가 되는 것도 돈을 벌 수는 있겠지만, 거기에도 비용이 따른다. 

결국 자신은 전문 분야에 따라 그 분야에 국한된 배역만을 맡게 될 것이며, 그 분야가 유행을 탈 때는 좋겠지만 그 후에 자신이 뭍에 올라온 물고기처럼 바싹 말라갈 일만 남은 것이다. NoSQL이 자신이 진행하는 프로젝트에 더 잘 맞을 수도 있다. 그렇지만 기업에서는 일회성 시스템에 투자를 하지는 않을 것이다. RDBMS으로도 충분히 할 수 있는 프로젝트이기 때문이다.

모두의 개발자 팁 No. 9 : 툴을 이용해 어려운 문제를 해결하라

따로 시간을 내 다른 사람들이 잘 모르는 툴을 몇 가지 배워둬라. 다른 이들이 잘 모르거나, 사용하지 않는 툴은 무엇인가? 그 가운데 자신의 효율성을 더욱 높여줄 툴은 무엇인가?

예를 들어, 아스펙트4j(Aspect4j)는 사용하는 사람이 얼마 되지 않지만, 필자는 개인적으로 이를 아주 유용히 사용한다. 필자는 아스펙트4j를 잘못된, 아주 잘못된 것들에 사용한다. 아스펙트4j를 웹스피어(WebSphere) 대신 톰캣(Tomcat)에서 작동시키기 위해 클래스 파일 오퍼레이션(class file operations)을 만들었다. 비록 오리지널 소스는 없었지만 말이다. 

또한 상용 소프트웨어의 메모리 누수 문제도 고쳤다. 필자는 윌리 인트로스코프(Wily Introscope)를 도입했다. 그럴 때마다 사람들은 필자가 다른 이들이 잘 사용하지 않는 툴을 사용한다는 점 때문에 천재처럼 여기곤 했다. 

그리고 다른 이들이 개발업체를 기다리기로 결정했을 때에도 필자에게는 계속 진행하라고 하기도 했다. 필자는 eclipse.org/mat과 함께 살고 숨쉬었으며 그 결과 메모리 누수 문제를 해결할 수 있었을 뿐 아니라 어떤 행동과 한도가 OOME(Out Of Memory Error)를 초래하는지도 말해줄 수 있었다. 

복잡한 문제를 해결해 주는 이런 간단한 툴 덕분에 필자는 다른 개발자 사이에서도 돋보일 수 있었다.

모두의 개발자 팁 No.10: 겸손을 잃지 마라

개발자에게는 겸손이라는 자질이 아주 부족하다. 겸손해진다는 건, 때로는 원하는 것 이상으로 힘든 일을 도맡아야 함을 의미한다. 

또한 문제를 해결했다고 해서 이에 대해 자만해서는 안됨을 의미하기도 한다. 유명세는 오고 가는 것이지만, 한 가지 기억해야 할 것은 자신이 최근에 한 일 덕분에 유명세가 찾아오는 것이라는 사실이다. 그런 다음, 한 주만 지나도 유명세는 사라져 버릴 지도 모른다. 

타일러 더든의 말을 빌리자면, "당신은 특별한 사람이 아니다." 그렇다, 필자도 이 말의 아이러니에 대해서는 잘 알고 있다.

자신이 인기있는, 모두의 개발자가 됐는지 어떻게 알 수 있을까?

자신이 서 있는 곳에서 양 옆을 살펴 보자. 자신이 하고 있는 일과 같은 일을 하는 사람들이 보이는가? 그렇다면, 아직 멀었다.

자신이 많은 이들이 원하는 개발자가 됐다는 신호에는 다음과 같은 것들이 있다. 

사람들과 함께 있는데 다들 자신을 주목하고 있다든지, 특별한 상황이 아님에도 자신과 함께 사진을 찍고 싶어 한다든지, 자신의 연설을 모두가 기다린다든지, 혹은 자신의 연설을 얼마나 좋아하는지 직접 얘기한다든지 하는 것들이다. 

덧붙여, 영업 및 마케팅 직원들이 자신의 의견에 귀 기울여 듣는지도 봐야 한다. 딱 자신의 얘기라고? 그렇다면 축하한다, 이미 모두의 개발자가 된 것이다. 

그러나, 명성과 성공은 한 순간일 뿐이다. 이를 지속하기 위해서는 끊임없이 발전해야 한다. 아이러니하게도, 인기 있는 개발자가 될수록 정작 코드는 점점 더 적게 쓴다. 

다른 사람들과 소통하고 그들에게 동기를 주는 것이, 그리고 자신의 성공 비결을 전파하는 것이 경제적으로 더 효율적이 되기 때문이다. 자신이 원했든 원하지 않았든 말이다.

앞서 말했지만, 소프트웨어 개발자들이 일자리를 원한다고 해서 다 가질 수는 없는 시기가 다시 한 번 찾아올 것이다. 특히 '적자생존' 식의 분위기가 만연해지면, 묵묵히 제 할 일만 하는 사람보다는 '셀프 마케팅'을 잘 하는 개발자가 살아남게 될 것이다. editor@itworld.co.kr