아쿠아프로젝트

그렇다면 자동차 한대를 구입해 1년간 운행하는데 들어가는 세금은 얼마나될까.

배기량이 1600cc급인 현대자동차의 뉴 아반떼(HD모델/오토/휘발유)는 공장도가격(세전가격)이 1108만8000원이다. 소비자는 여기에 개별소비세 관련 세금(190만2000원)이 붙은 1299만원에 차를 구입하게 된다.

취득단계에선 △취득세(23만6000원)+등록세(59만원) 등 82만6000원을 내고, 1년간 보유하면 △자동차세(22만3000원)+교육세(6만7000원) 등 29만원의 세금을 추가로 납부해야 한다.

1년에 2만㎞를 주행했다고 가정하면 연비(13.8Km/ℓ)를 고려할 때 약 1449.3ℓ의 휘발유를 소비하게 된다. 물론 여기에도 유류특소세(교통에너지환경세)·교육세·주행세·부가세 등의 세금이 붙는다.

휘발유의 경우 유류특소세(교통에너지환경세)가 ℓ당 462원이며 교육세는 유류특소세액의 15%, 주행세는 유류특소세액의 30%다. 부가세는 '휘발유가격+유류특소세+교육세+주행세'의 10%로 계산한다.

1년간 소비하는 휘발유에 붙는 세금만 유류특소세 67만원, 교육세 10만원, 주행세 20만1000원, 부가세 17만3000원 등 총 114만4000원이다. ℓ당 1315.92원(15일 휘발유가격 기준)을 기준으로 할 때 1년간 쓰는 기름값(197만7163원)의 60% 가까이가 세금인 셈이다.

결국 중소형차 1대를 구입해서 1년 운행하려면 총 416만2000원을 세금을 내야 한다.

배기량이 2000cc급인 NF 쏘나타(2.0 트랜스폼 모델/오토/휘발유)도 같은 조건으로 계산하면 차 구입 후 1년간 641만9000원을 세금으로 내야 한다. 차값은 세전 기준으로 1839만5000원.

미국(뉴욕시 기준)은 아반떼급 자동차를 구입할 경우 판매세와 재산세, 등록세 등 약 140만원의 세금만 납부하면 되는 것으로 전해졌다. 휘발유엔 ℓ당 0.184달러(연방기준)가 연료세로 붙기 때문에 아반떼와 동일 조건이라면 1년간 내는 유류 관련 세금은 36만원 정도에 불과하다. 한국 소비자들이 미국에 비해 2배 이상 더 세금을 내는 것이다.

업계 관계자는 "자동차는 그야말로 세금 덩어리"라며 "차가 많이 팔리면 그 만큼 세수가 늘어난다는 점에서 경기 부양을 위해 유류세 인하 등 추가적인 조치가 나와야 한다"고 말했다.

"개발자에게 이렇게 대할 경우 개발에 도움 안된다" 라는 주제로 몇가지 경우를 정리해봤습니다. 몇몇 항목은 개발자 뿐만 아니라 직원 또는 부하직원에게 해선 안될 불필요한 경우들입니다. 오늘 문득 이런 상황들을 정리해 봐야 겠다는 생각에 간추려 본 것으로 추후 편집 될 수 있습니다.

1. 수정사항이나 개선사항을 버그라고 표현하는 경우.
버그를 버그라고 이야기해도 개발자 입장에서는 썩 기분 좋은 일이 아닌데 수정사항이나 개선사항 조차도 버그라고 이야기 하면 개발자와 거리를 두는 격이 될 것입니다.

2. 그동안 시켜온 많은 업무 지시 사항들은 잊고 뭘 했는 지 묻는 경우.
지시 사항이나 기획에 의해서 일을 하고 있을 텐데 그 동안 무슨 일 해냐고 묻는 것은 개발자의 기분도 상하게 할 뿐만 아니라 지시자에 대한 신뢰도 무너지게 될 것입니다.

3. 조직 내에 존재하지 않거나 현재 존재하지 않는 인물에 빗대어 의견을 묻는 경우
내가 아는 사람이 말하길 이건 한 5일이면 개발한다던데 당신은 얼마나 걸릴 것 같습니까?
전에 일하던 개발자가 이렇게 말하던데 당신은 왜 이렇게 이야기 합니까?
어떤 일을 하거나 어떤 관계에 있더라도 타인과 비교해서 나를 평가절하 한다면 기분 나쁜 것은 당연합니다. 조직 내에 존재하지 않은 사람이 내린 판단은 조직 내의 시시콜콜한 사정을 알지 못하고 내린 결론일 것이므로 도움이 되지 않는 것이며 이런 말로 인해 개발자는 자신의 기술과 인격을 신뢰하지 않는다고 판단할 것입니다.

4. 회사의 부정적인 경영 상황을 이야기 해서 일 할 의욕을 떨어뜨리는 경우
회사의 비전을 이야기 해서 의욕을 가지고 일하게 하는 것이 일반적이지만 회사 상황에 대해 부정적인 말을 하는 경우 개발자는 개발 의욕이 떨어지게 될 것이고 이직을 고민하게 될 것입니다. 어찌보면 계속 근무를 해야 할지 이직을 해야 할지 정확하게 판단할 수 있도록 도움을 주는 고마운 말일 수 있겠습니다.

5. 열심히 일했거나 성과가 높을 때 그만한 혜택은 없고 더 많은 업무를 지시하는 경우
능력 발휘를 잘 하는 사람이나 근무시간 이외 시간을 투자해서 일하는 사람에게 업무를 중과하는 것과 이에 대한 보상 시스템이 없는 경우 점진적으로 업무의 하향 평준화가 될 것입니다.

6. 개발 공간을 별도로 분리하지 않고 타 부서와 근접한 곳에서 개발 업무를 하게 할 경우
개발 공간이 손님 또는 고객들이 드나들고 전화 업무가 많은 부서들과 함께 하는 곳일 경우 개발자의 집중력과 개발의 연속성을 떨어뜨릴 것입니다.

7. 지나치게 많은 회의를 하고 속사포 처럼 수시로 업무 지시를 하는 경우
이럴 경우는 체계적으로 일을 처리하는 곳에서는 일어날 수 없는 상황입니다. 또한 회의가 많으면 수시로 업무를 지시하면 그 만큼 개발 기간 대비 개발 시간을 줄이는 것이고 결국 개발자는 실제 개발 시간이 아닌 개발 기간 대비해서 나온 성과에 대한 책을 져야 할 것입니다.

8. 기획의 완성도가 부족한 상태에서 개발 업무를 추진하는 경우
되도록이면 기획의 완성도를 높여서 업무를 추진해야 하는 것이 상식입니다. 기획의 완성도가 떨어지면 어째꺼나 개발을 해야 하므로 개발자가 부족한 기획을 체워야 하므로 기획을 하게 만드는 꼴이 됩니다. 개발자가 보완한 기획이 잘되면 문제가 없겠지만 잘못되면 개발자 마음대로 만들었다는 질책을 받을 수 있고 역할 분담으로 인해 나올 수 있는 효율과 체계는 사라지게 될 것입니다.

9. 개발자의 본래 해야할 일과 동떨어진 업무도 병행해서 일하게 할 경우
조직의 규모가 클 경우 분업화가 잘 되서 이런 일이 없겠지만 중소규모의 조직에서는 개발자가 다른 업무도 하는 경우가 많습니다. 심지어 개발과 상관관계가 없는 서비스 업무를 하게 되는 경우도 있습니다. 이런 경우 개발의 효율은 당연히 떨어지고 추가로 배당 받은 업무에 대한 책임도 저야 하니 개발자가 오래 버틸 수 있는 근무 환경이 아닙니다.

10. 개발자와 회의 없이 결정된 사항을 예고도 없이 급작스럽게 지시하는 경우
일의 순서를 무시하고 진행된 일은 문제가 생기게 마련입니다. 개발자를 당황하게 만들면 일도 제대로 진행되지 않을 뿐더러 이런 상황이 반복되면 개발자는 이직을 고려하게 될 것입니다.



http://link.allblog.net/15058508/http://feeds.feedburner.com/~r/Tech21/~3/477390387/649

이건 팁) 웹사이트소스

 단 하나의 시각으로 바라보는 것보다 거꾸로 뒤집어 보기도 하고 다른 색깔을 입혀보기도 하고 기존의 것에 새로운 것을 덧붙여 보기도 하는 것이 그 출발이다.

주변부터 시작하는 관심을 들여야겠다! ^^