자기가 아무리 프로그램을 잘 짠다고 해도 고객의 요구를 못알아 듣거나 오해해 버리면 결과물은 영 엉뚱한 것이 만들어지지 않겠습니까. 사실 고객도 그 자신이 스스로 뭘 원하는 지도 추상적이고 애매한 수준으로 밖에 알지 못하는 지라 개발하는 쪽에서 훨씬 높은 수준의 상상력과 그를 구현하는 능력 및 기획력이 필요합니다. 당연히 교양수준도 높아야겠지요.
게다가 프로그램의 대형화가 일반적인 추세인지라 복수의 개발자의 협동이 필요한데 협동해서 일한다는게 말처럼 쉬운 일만은 아닙니다. 쿼드 코어 시피유도 오버헤드 때문에 실제 시피유 1개의 성능의 4배가 나오지 못합니다. 시피유조차도 그럴진데 그보다 훨씬 복잡하고 감성적인 사람들이 모여서 시너지를 낸다는 건 단순히 프로그래밍 능력만 가지고는 안되는 일이지요.
영어야 뭐, 최신 기술이 다 영어로 나오지 않습니까. 그 기술들이 한물 갈때 쯤이야 번역본이 나오고... 그나마 번역본이 나오면 양반이고 안나오는 경우가 태반에, 간신히 나온 것들도 차라리 영어가 더 쉽다고 생각될 정도로 해괴한 번역들도 많고...
게다가 요즘은 좁은 한국시장 만 가지고는 먹고살기 힘들어서 다들 해외 진출도 도모하는데 한국어로 된걸 외국에 팔기는 어려우니까요.
뛰어난 프로그래밍 능력은 소중한 것이지만 그것만 가지고는 결코 일류 소리 듣기는 어려울 것이라고 생각됩니다.
절대적으로 동감합니다. 전에 신입사원을 한명 뽑아서 쓰는데, 커뮤니케이션이 완전 엉망이 친구였습니다. 면접시 왜 그 친구를 뽑았는지 이해가 잘 안되더군요. 하나의 모듈을 구현하라고 하면, 3번에 걸쳐서 완성되더군요. 왜냐면, 제대로 이해를 못해서 자기가 이해한대로 하려다가 구현 못하고, 와서 물어보는 것을 반복했기 때문이죠. 코딩은 좀 못하더라도 커뮤니케이션 제대로 되는 친구와 일하는게 오히려 속 편하다는 것을 느꼈었지요..
많은 것이 필요하겠지만 그중에서 제일 중요한건 역시
많은 것이 필요하겠지만 그중에서 제일 중요한건 역시 커뮤니케이션 능력이 아닐까 합니다.
자기가 아무리 프로그램을 잘 짠다고 해도 고객의 요구를 못알아 듣거나 오해해 버리면 결과물은 영 엉뚱한 것이 만들어지지 않겠습니까. 사실 고객도 그 자신이 스스로 뭘 원하는 지도 추상적이고 애매한 수준으로 밖에 알지 못하는 지라 개발하는 쪽에서 훨씬 높은 수준의 상상력과 그를 구현하는 능력 및 기획력이 필요합니다. 당연히 교양수준도 높아야겠지요.
개발 관련 프로젝트에 관해서는 유명한 그림도 있지요.
http://sayingimages.com/a-project/
게다가 프로그램의 대형화가 일반적인 추세인지라 복수의 개발자의 협동이 필요한데 협동해서 일한다는게 말처럼 쉬운 일만은 아닙니다. 쿼드 코어 시피유도 오버헤드 때문에 실제 시피유 1개의 성능의 4배가 나오지 못합니다. 시피유조차도 그럴진데 그보다 훨씬 복잡하고 감성적인 사람들이 모여서 시너지를 낸다는 건 단순히 프로그래밍 능력만 가지고는 안되는 일이지요.
영어야 뭐, 최신 기술이 다 영어로 나오지 않습니까. 그 기술들이 한물 갈때 쯤이야 번역본이 나오고... 그나마 번역본이 나오면 양반이고 안나오는 경우가 태반에, 간신히 나온 것들도 차라리 영어가 더 쉽다고 생각될 정도로 해괴한 번역들도 많고...
게다가 요즘은 좁은 한국시장 만 가지고는 먹고살기 힘들어서 다들 해외 진출도 도모하는데 한국어로 된걸 외국에 팔기는 어려우니까요.
뛰어난 프로그래밍 능력은 소중한 것이지만 그것만 가지고는 결코 일류 소리 듣기는 어려울 것이라고 생각됩니다.
===== ===== ===== ===== =====
그럼 이만 총총...[竹]
http://elflord.egloos.com
ㅁㅈ
답변 감사드립니다
그림도 정말 재치있네요.
절대적으로 동감합니다. 전에 신입사원을 한명 뽑아서
절대적으로 동감합니다. 전에 신입사원을 한명 뽑아서 쓰는데, 커뮤니케이션이 완전 엉망이 친구였습니다. 면접시 왜 그 친구를 뽑았는지 이해가 잘 안되더군요. 하나의 모듈을 구현하라고 하면, 3번에 걸쳐서 완성되더군요. 왜냐면, 제대로 이해를 못해서 자기가 이해한대로 하려다가 구현 못하고, 와서 물어보는 것을 반복했기 때문이죠. 코딩은 좀 못하더라도 커뮤니케이션 제대로 되는 친구와 일하는게 오히려 속 편하다는 것을 느꼈었지요..
그림추천합니다.
저 그림이 의미하는 바가 깊네요.
보고 또 보게 됩니다.
개발에는 개발자내 뿐만아니라 여러 분야 사람들이
개발에는 개발자내 뿐만아니라 여러 분야 사람들이 협업해야 합니다. 특히
Developer, Designer, Manager 가 기본이 되는건 혼자 개발하지 않는 이상 피할수 없죠.
그들이 서로를 바라보는 시각을 재미있게 표현한 사진입니다.
http://www.reddit.com/r/reddit.com/comments/j9z2g/developers_vs_designers_vs_project_managers/
ㅋㅋㅋ
ㅋㅋㅋ 재밌네요
완전 공감이네요
완전 공감이네요
Seen BY DEVELOPERS가 정말 맞는 것 같은데요.^^
나머지 2개는 재밌게 표현한 것 같고
QA 시야가 추가되었습니다.
QA 시야가 추가되었습니다.
이렇게 될 수 있습니다. 펭귄에게 액티브X를 주면
이렇게 될 수 있습니다.
펭귄에게 액티브X를 주면 어떻게 먹나요..
여우와 황새 http://kldp.org/node/124823
교양을 갖추어야지 상대를 이해하고 상대에 맞게 프로그래밍을 할 수 있습니다.
프로그래밍만 잘하면 기술 우월 주의에 빠져서 기술만 있으면 뭐든 다 된다고 생각하는데 착각입니다.
기술은 그 자체가 목표가 될 수 없고 수단입니다.
아
기술은 수단이다. 좋은 말이네요!..
경향신문 - 소프트웨어 아키텍트를 아시나요?
경향신문 - 소프트웨어 아키텍트를 아시나요?
오...
좋은 기사네요..
북마크해놔야겠습니다.
소프트웨어 아키텍트가 되도록 노력해야겠네요.
감사합니다
컴학도의 입장으로서도 저에게 도움이 되는 좋은
컴학도의 입장으로서도 저에게 도움이 되는 좋은 기사네요. 링크 감사드립니다.
우문현답. 독서를 왜 해야하나요? 인문을 꼭 읽어야
우문현답.
독서를 왜 해야하나요?
인문을 꼭 읽어야 되나요?
책은 라면끓인 냄비받침 아닌가요?
의 공통된 답변이면 될것입니다.
좋은 답변들 많이 달아주셨지만... 저는...
소프트웨어는 '사람'이 사용하는 것이기 때문입니다.
프로그래밍은 '컴퓨터'에게 내릴 명령을 만들 뿐입니다.
사람이 사용할 소프트웨어라면,
사람들이 편리하게 사용할 수 있도록,
사용자가 특정 분야에 지식이 많지 않아도,
그 분야의 소프트웨어를 편리하게 사용할 수 있도록
만들 줄 알아야 '좋은 소프트웨어'를 만든다고 할 수 있겠습니다.
그런 소프트웨어를 만들기 위해서는 프로그래밍만 하는 것이 아니라,
과학과 인문학을 같이 공부하는 것이 중요합니다. :)
프로그래밍 능력이 한 두개가 아니기
프로그래밍 능력이 한 두개가 아니기 때문이지요.
위에서 아키텍트 설계 이야기도 나왔지만, 코더, 단위 테스터, 모듈 설계, 네이밍 컨센선스, 메모리 관리, 클래스 리팩토링, 디버깅 프로그래밍, 멀티쓰레드 테스팅, 락관리 에다가 OS 최적화, CPU 스케쥴링, 커널 수정 등등을
영어 공부 하지 않고 원서 책도 안 보고 고수한테 지도편달 받지 않고도 프로그래밍 잘 할 수 있다고 생각한다면 큰일이라고 생각합니다.
알고리즘 발전 속도 (심지어 HTML5 설마 성공할 줄 몰랐슴) 따라가려면 이거 저거 다 잘해야 합니다...
-----
안녕하세요 소프트웨어 공학센터 장원석 책임입니다.
http://www.software.kr