어디까지가 단순한 코더의 역할인가요?

nickcave의 이미지

갑자기 궁금해졌습니다.

회사하는 일이란게 칩벤더에서 제공하는 라이브러리는 가지고

유저 인터페이스를 만드는 일인데요, 예를 들면 사용자의 요구에 따라

1번 버튼을 누르면 이렇게 동작되고 2번을 누르면 저렇게 동작되고.. 하는

프로그램을 만드는 일이죠. 특별히 알고리즘을 구현한다거나 하지는 않고

플로차트는 그리고 그거에 따라 기존 함수를 복사해다가 붙이는 일입니다.

그런데 며칠전 부터 이런일이 많은 분들이 말씀하시는 개발자가 아닌 단순

코더가 하는 일이 아닌가 라는 생각이 들었습니다.

이런일이 코더의 역할인가요?

bookworm의 이미지

흔히 코더의 상위 단계라는 프로그래머가 하는 일이
주어진 API(Prototype), 데이터 구조, 알고리즘을
사용해서 정해진 기능을 구현하는 것이라고 하니
참고하셨으면 합니다. (MS의 이야기입니다.)

B/o/o/k/w/o/r/m/

youngminny의 이미지

자신이 코더인지 확인하실려고 하시나요?
아님... 상사가 난 코더인데... 더 일을 시키시나요?? ㅎㅎ
예전부터 저도 이런류의 생각을 가끔 했죠..
coder,programmer,developer... T.T
내 위치가 어딜까??
bookworm님의 말이라면.. programmer는 아닌듯 싶은데....쩝

세벌의 이미지

nickcave wrote:
기존 함수를 복사해다가 붙이는 일입니다.

기존의 함수를 호출하는게 아니고 복사해 붙여서 또 하나의 함수를 만드나요?
불량청년의 이미지

어디서 코드를 붙여다 쓰던 어떻게 하든,

자신이 만든 최종 OUTPUT에 대해서 책임을

질 줄 안다면 개발자(Developer)라고 생각합니다.

다른 코드를 붙여다 쓴다 할지라도 충분히 검토후에

써야 한다는 말이죠. *^^* 더 나아가 갖고 온

코드를 수정해서 좀 더 성능을 높인다면 더할나위 없겠죠.

음... 회사 명함엔 Software Engineer이라고 써있네요.

H/W가 컴퓨터의 심장이라면 S/W는 컴퓨터의 영혼이다!

jachin의 이미지

코더아니었던 아키텍터는 없다고 생각합니다.

전 아키텍터가 아니더라도 진정한 코더라고 하더라도 굉장하다고 생각될 것 같습니다.

물론 아키텍터로서의 사고를 코더가 할 수 없는 것은 아닙니다.

코더또한 아키텍터로서의 사고를 할 수 있지만, 여러사람이 프로그램의 흐름을 서로 정의해 놓으면

프로그램을 작성하기 어려워지기 때문에 최소한의 혼돈과 최대한의 효율로써 작성할 수 있도록 계획을

설정하는 것이 아키텍터로의 역할이라 생각합니다. 코더 또한 그것에 상응하는 정확한 파트를 생산해 낼 줄 알아야 한다고 생각합니다.

아키텍터또한 코더로서의 경험이 없다면 절대 불가능한 일이겠죠.

hurryon의 이미지

jachin wrote:
코더아니었던 아키텍터는 없다고 생각합니다.

전 아키텍터가 아니더라도 진정한 코더라고 하더라도 굉장하다고 생각될 것 같습니다.

물론 아키텍터로서의 사고를 코더가 할 수 없는 것은 아닙니다.

코더또한 아키텍터로서의 사고를 할 수 있지만, 여러사람이 프로그램의 흐름을 서로 정의해 놓으면

프로그램을 작성하기 어려워지기 때문에 최소한의 혼돈과 최대한의 효율로써 작성할 수 있도록 계획을

설정하는 것이 아키텍터로의 역할이라 생각합니다. 코더 또한 그것에 상응하는 정확한 파트를 생산해 낼 줄 알아야 한다고 생각합니다.

아키텍터또한 코더로서의 경험이 없다면 절대 불가능한 일이겠죠.

그렇지 못한 아키텍터나 팀장들이 비일비제하죠. ㅡㅡ; 일례로 BIND 세팅조차 하지 못하지만 DNSSec 관련 저널을 발표하며 저널의 성능평가 부분에 후배나 석사들이 작업한 시뮬레이션 결과를 넣는 인간이라던지, 아니면 VPN 관련 저널을 발표하면서도 실제로 자신은 유닉스/리눅스에서 자신의 패스워드도 제대로 변경 못하는 인간들 많습니다.

대략 이런 인간들이 사회에 나가서 대학 교수(수도권에 있는 4년재 대학 교수가 되기 위해 SCI급 논문 3편 이상이면 대부분 지원 가능합니다)가 되거나 유수의 연구소에서 선임 연구원 자리 차지 하고 있겠지요. 이론과 실무의 괴리라고 생각됩니다만...어쩔 수 없는 일이라고 생각해야 할지...

nickcave의 이미지

sebul wrote:
nickcave wrote:
기존 함수를 복사해다가 붙이는 일입니다.

기존의 함수를 호출하는게 아니고 복사해 붙여서 또 하나의 함수를 만드나요?

기존의 함수도 호출하고 또 여러개를 호출해서 다른 함수도 만듭니다.

거의 짜깁기라고 해야 되나요?..^^ 대부분 종착역은 정해져 있더군요..

그리고 답변 감사드립니다.

부모님께 효도합시다.

sozu의 이미지

hurryon wrote:

그렇지 못한 아키텍터나 팀장들이 비일비제하죠. ㅡㅡ; 일례로 BIND 세팅조차 하지 못하지만 DNSSec 관련 저널을 발표하며 저널의 성능평가 부분에 후배나 석사들이 작업한 시뮬레이션 결과를 넣는 인간이라던지, 아니면 VPN 관련 저널을 발표하면서도 실제로 자신은 유닉스/리눅스에서 자신의 패스워드도 제대로 변경 못하는 인간들 많습니다.

제가 젤 싫어하는 부류의 사람들이죠 :evil:

대규모 프로젝트 해본 경험이 한번도 없는데 대규모 프로젝트 감리를 하는 하는 사람도 있지요~ :twisted:

-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

jachin의 이미지

hurryon wrote:
그렇지 못한 아키텍터나 팀장들이 비일비제하죠. ㅡㅡ; 일례로 BIND 세팅조차 하지 못하지만 DNSSec 관련 저널을 발표하며 저널의 성능평가 부분에 후배나 석사들이 작업한 시뮬레이션 결과를 넣는 인간이라던지, 아니면 VPN 관련 저널을 발표하면서도 실제로 자신은 유닉스/리눅스에서 자신의 패스워드도 제대로 변경 못하는 인간들 많습니다.

대략 이런 인간들이 사회에 나가서 대학 교수(수도권에 있는 4년재 대학 교수가 되기 위해 SCI급 논문 3편 이상이면 대부분 지원 가능합니다)가 되거나 유수의 연구소에서 선임 연구원 자리 차지 하고 있겠지요. 이론과 실무의 괴리라고 생각됩니다만...어쩔 수 없는 일이라고 생각해야 할지...

전 그런 사람들을 진정한 아키텍터라고 부르진 않습니다. 자칭 아키텍터라고 부릅니다. ^^a

nickcave의 이미지

jachin wrote:
전 그런 사람들을 진정한 아키텍터라고 부르진 않습니다. 자칭 아키텍터라고 부릅니다. ^^a

비 개발 업무팀의 팀장님이 일정을 가지고 압박하면 정말 힘들더군요.

아무리 설득을 하고 사정을 해도 막무가내 스타일로 아웃풋을 요구하면

정말 의욕 상실이더군요.

저: "이건 라이브러리 형태라서 건들면 프로그램이 꼬이는데요~"

팀장: "그럼 그 라이브러리 쓰지말고 너가 하나 만들어~"

저:"네? ... 그럼 일정 지연이...-_-;"

물론 해보지도 않고 프로그램 꼬인다고 한 저도 문제지만 팀장님도..참~..

부모님께 효도합시다.

Prentice의 이미지

( 코더도 아닌 초보가 감히 off-topic 내용을 한마디 던져봅니다.. 아키텍가 아니라 아키텍가 옳지 않을까요..? ^^; )

hb_kim의 이미지

많은 분들이 아키텍트한테서 너무나도 많은것을 바라고 계신것 아닌지 모르겠네요. 전체적인 흐름을 이해하고 정의할 수 있으면 아키텍트로써 할일은 충분히 하고 있는것 아닌가요?

소프트웨어 프로그래밍의 특성상, 세부 정의와 구현, 테스트등을 자기 손으로 직접하는 사람들이 꽤 많기는 하지만, 그렇다고 그게 꼭 필요조건은 아니죠.

그리고 사람에 대한 평가의 잣대는 뭘하는 사람이건간에 그 사람을 필요로 하고 또 그 사람의 필요에 대응해줄수 있는 주체가 기준을 만들어야 되지 않겠습니까?

idlock의 이미지

hb_kim wrote:
많은 분들이 아키텍트한테서 너무나도 많은것을 바라고 계신것 아닌지 모르겠네요. 전체적인 흐름을 이해하고 정의할 수 있으면 아키텍트로써 할일은 충분히 하고 있는것 아닌가요?

그만큼 개발환경이 열악하다고 느낀 개발자가 많기 때문 아니겠습니까....

계층이 잘 나누워져 있고.. 자기가 느끼기에 사회적으로 느끼기에 충분한 보상과 협업이 된다고 느낀다면.. 이런 이야기보다는 아키텍쳐 담론으로 올라갔겠지요...

아쉽군요... 아직은 한국은 배고픈 모양입니다... 저도 그렇고요..

버그헌터의 이미지

제가 근무하고 있는 회사의 경우를 말해볼까합니다.

팀이라고 할꺼까진 없지만 PM과 개발자로 나누어지져..
PM의 역할은 일정관리 및 말도 안되는 요구사항등을 개발자가 짜증나지 않게 막아주는 일이지요..

그럼 개발자는 무슨일을 하느냐.. 요구사항들을 수렴하여 설계부터 output까지 대부분의 개발 관련 부분을 처리합니다.
이게 우리나라의 IT현실이 아닐까합니다.

각종 서적을 보면 외국은 코더와 아키텍트로 나두어지는것같은데 뭐 이건 개발 효율을 위해 이상적일 수 도 있지만 잘난사람이 많은 우리나라에선 차라리 혼자하는게 업무 효율이 높지 않을까 싶네요.

코더의 느낌은 수준낮은 개발자를 비꼬아서 하는 말처럼 들리는건 왜일까요.
헤~ 뭐! 코더가 됐건 아키텍트가 됐건 EndUser를 만족시킬 프로그램을 개발한다면 그걸로 전 만족입니다. ^^

bookworm의 이미지

hb_kim wrote:
많은 분들이 아키텍트한테서 너무나도 많은것을 바라고 계신것 아닌지 모르겠네요. 전체적인 흐름을 이해하고 정의할 수 있으면 아키텍트로써 할일은 충분히 하고 있는것 아닌가요?

소프트웨어 프로그래밍의 특성상, 세부 정의와 구현, 테스트등을 자기 손으로 직접하는 사람들이 꽤 많기는 하지만, 그렇다고 그게 꼭 필요조건은 아니죠.

그리고 사람에 대한 평가의 잣대는 뭘하는 사람이건간에 그 사람을 필요로 하고 또 그 사람의 필요에 대응해줄수 있는 주체가 기준을 만들어야 되지 않겠습니까?

아키텍트가 직접 할 필요할 필요는 없지만 해 본 경험은 가지고 있어야 한다고
생각합니다.

B/o/o/k/w/o/r/m/

jachin의 이미지

검은해 wrote:
( 코더도 아닌 초보가 감히 off-topic 내용을 한마디 던져봅니다.. 아키텍가 아니라 아키텍가 옳지 않을까요..? ^^; )

핫! 그렇군요. ( _ _) =3 털썩... 이미 검은해님은 초보가 아니십니다....