https://www.dogdrip.net/376791115

이런글이 종종 올라오는데, 개발이란 영역은 방대하기 때문에 비 개발자 개붕이들에게 글을 몇번 썼었다.

본 개붕이는 본래 읽판에 글을 몇번 썼는데 그때마다

https://www.dogdrip.net/47470715

이 공지에 의해서(자꾸 썰로 판정됨) 글이 날라가서 유저 개드립에 처음 글을 써본다.

솔직히 이 글이 개드립에 올라갈거란 자신이 없다.

 

H1.선요약

비 개발자 개붕이들이 하는 오해

Q1. 개발자는 수학을 잘 알아야 하나요?

A1. 이는 수학에 대한 오해로, 개임개발에 입사하거나, 최적화에 일하고자 하는 개붕이를 제외하고는

'수학'보다는 논리학을 잘 알아야 한다는 요구사항을 잘못 이해한 것에 가깝다.

 

Q2. 개발자는 평생 공부하나요.

A2. 반대로 묻건데, 입사할때 지식으로 평생 일할수 있는 고소득 지적 업무가 무엇이 있나요?

육체 노동을 제외한다면 평생 공부하는 것이 당연합니다.

의사, 변호사, 법무사, 회계사 등등 계속 공부해야하는 직업이 대부분입니다.

대체 무슨 고소득 직업이 공부하지 않고 버틸 수 있나요?

양심적으로 저는 의사들보다 훨씬 공부를 안하고 지내는거 같네요.

(즉, 반대로 저소득 프로그래머를 꿈꾼다면 굳이 공부하지 않아도 됩니다.)

 

Q3. 개발자는 돈을 잘 버나요?

A3. 수요공급 곡선을 따른다고 볼 수 있습니다.

채용 담당자의 능력이 모자라면, 자기 능력보다 더 높은 돈을 받을 수 있지만,

보통은 구하기 힘든 능려자가 많은 돈을 받고, 구하기 쉬운 능력자는 적은 돈을 받기 나렴입니다.

 

Q4. 제가 해도 될까요?

A4. 제 경험상 현업자들도 대부분 멍청하니까 해도 됩니다.

 

 

H2.개발자들을 위해 쓰는 글

나는 펌웨어 개발이라는 프로그래머....라고 부르기에도 되게 부끄러운 영역에 일하고 있기 때문에

반박하고 싶은 영역이 많을 거라고 생각함.

그러나, 이 글은 개발자가 아니라 비 개발자 혹은 개발자 입문을 위한 글이기에 감안해주길 바람.

 

 

 

 

 

 

M1.개발자란 대체 무엇인가?

개발자를 부르는 이름은 되게 많다.

개발자, 코더, 프로그래머, 아키텍쳐, 기타등등 여러 이름으로 불리지만,

나는 펌웨어 개발자인지라 오로지 프로그래머라고 불린다.

이름에 따라 역할이 규정되는 것은 아니고 내 기준으로 말하자면,

1. 시키는대로 하는 사람 : 코더

2. 1에 속하는 사람을 시키는 사람 : 프로그래머 혹은 아키텍쳐

라고 하고 싶다.

아무튼 프로그래머는,

3. 자연어(대부분의 사람이 이해할 수 있는 언어)로 규정되는 돈이 되는 컴퓨터 프로그램을 작성하는 사람

이라고 정의하겠다.

즉, 그 사람이 어떤 일을 하느냐보다 그 사람이 만드는 결과물이 "돈이 되느냐" 여부가 더 중요한게 아니냐?

가 펌웨어 개발자 입장에서의 관점이다.

 

M2. 개발자를 분류하자면

감히 내가 분류하자면

1. 전산수학 연구자 : 어떤 연산이 가장 호율적인가를 연구하는 사람

2. 프론트 엔드 : 사용자 눈에 보이는 것을 구현하는 사람

3. 백엔드 : 2번이 동작하도록 그러나 일 한 결과물이 사용자 눈에는 보이지 않는 사람

4. 펌웨어 : 작은 컴퓨터(논리회로)가 사용자의 의도에 맞게 동작하도록 하는 사람

라고 말하겠다.

먼저 말하자면, 나도 잘 모른다.

프론트엔드는 웹에서 동작하는 개념이다. 앱 에서는 적용되지 않는 개념이다.

백엔드 역시 웹에서 동작한다. 초창기 배민이 이벤트를 진행할 때 "미안하닭"을 띄우는 원인은 백엔드 최적화가 안되었기 때문이다.

12년에 SK가 서울 월드겁 야구 경기장에서 통신이 잘 안되었던 이유는, 월드컵 경기장 근처에는 삼성 기지국만 있었는데,

펌웨어 구현이 잘못되었기 때문임.

프론트에서 잘못 개발해서 사용자 서비스에서 문제가 있던건 뭐가 있을까....

유튜브의 싫어요 버튼 사라진다거나, 영상마다 얼마나 봤는지 바를 보여주지 않는게 프론트 문제일까..?

근데 이건 기획의 잘못이 아닌가..?

프론트를 모르니 어떤 문제가 프론트의 잘못으로 발생하는지 잘 모르겠다.

 

M3. 개발자간의 의견이 갈리는 이유

본인은 펌웨어 개발자기 때문에, 솔직히 별로 공부하지 않는다.

대부분 개발자의 의견이 갈리는 이유는, 결과물이 어느정도의 크기를 가지는지에 대해 생각의 차이점이 있기 때문이다.

 

컴퓨터에는 '진정한'의미의 무작위 숫자 추출이 없다.

 n개의 무작위 숫자 추출을 필요로 하는 프로그램이 있다고 하자.

이는 1~m까지의 숫자 중 n개의 숫자를 추출해야 한다.

이를 구현하는 방법은...크게 2가지의 방법이 있다.

1. 1~m까지 구현한 다음, n번 랜덤을 추출한 다음, i번째와 n번째 랜덤 숫자를 교체하는 방식

2. 1~m까지의 숫자를 추출하는 함수를 돌린 후, 이전에 구현되지 않은 경우 다시 랜덤을 뽑는 방식.

 

1번의 대충 짠 코드는 아래와 같다.

1....m까지의 배열을 만든다. (공간소요 m, 시간소요 m)

2. i번째로 랜덤으로 숫자를 뽑는다.

3. 결과물 숫자와 i번째의 결과물을 서로 바꾼다. ( 시간소요 3)

4. 2~3번과정을 n번 반복한다.

이는, 결정적을 m+3n번 걸린다.

 

2번의 대충 짠 코드는 아래와 같다.

1. 랜덤을 추출한다.

2. 0...i번째 배열에서 1번에서 추출한 코드가 있는지 확인한다.(공간소요 i, 시간소요 i) 있다면 이번 절차는 무효화한다.

3. 1~2번 과정을 n번 반복한다.

이는, n~m*n번까지 랜덤하게 발생한다. (최악은 무한시간인데 기대값이 얼마인지 지금 취해서 계산이 안된다)

어느 경우가 나은지는 경우마다 다르다.

10가지 가지수 중 5번 뽑는 것은 1번이 유리하지만,

(1번의 경우 10+5번 걸리나, 2번의 경우 1(최초 추출) + 1*1/0.99 + 1/0.98 + 1/0.97 + 1/0.96

100가지 가지수 중 5번 뽑는 것은 2번이 유리하다.

(1번의 경우 100+5번 걸리나, 2번의 경우 기대값이 6보다 작을걸로 기대하지만, 아무리 커도 100보단 작기 때문.)

 

이처럼 서비스가 어느정도 필요할지에 대한 생각에 차이에 의해 어떤 구현체가 답인지 갈라질 수 있다.

즉 뭐가 답인지가 정해져 있기 않기 때문에 개발자간의 의견이 갈린다.

spring이란 백엔드 프레임워크가 있는데, 이게 정부 표준이다.

근데 spring은 너무 방대한 프레임워크라 nodeJS를 좋아한다는 동기가 있다.

난 그쪽 분야에서 일하는게 아니라 뭐가 맞는 말인지 모르겠지만,

아무튼 복수 정답이라는 것은 이해할 수 있으리라 믿는다.

 

 

 

 

뭐 대충 아래와 같은 사항에 대해

https://www.dogdrip.net/371177794

1. 신호등을 추가한다

2. 각 차량간 정책을 정해서 지금처럼 신호등 없이 잘 처리하도록 한다.

라는 의견이 나올 수 있는데,

뭐가 답인지는 도로가 어떻게 생겼는지, 어떤 차가 주로 들어오는지, 어느방향으로 주로 가는지에 따라 달라진다.

심지어 공간소요에 방점을 찍느냐, 시간소요에 방점을 찍느냐에 따라서도 의견이 갈린다.

그렇다보니 개발자간의 의견이 통일되기는 몹시 어렵다.

 

M4. 수학은 개발자에게 얼마나 중요한가요?

"전산수학" 이라는 분야가 있다.

여기서 다루는 내용은 어떠한 연산을 어떤 순서로 계산하면 빠르게 계산할 수 있는가 이다.

이 내용은 되게 중요한게, 전산수학의 한계로 인해 스1 유닛이 스2의 유닛보다 길찾기를 존나 못한다.

네이버 길찾기가 지금처럼 길을 잘 찾는 것도 전산수학이 발달한 결과이고,

문명5에선 일꾼배치를 수동으로 해야 했지만, 문명6에서는 정책만 결정하면 일꾼배치가 수동보다 나은 것도,

최신 게임이 옛날게임보다 그래픽이 좋은 것도 하드웨어가 발달한 것 뿐만 아니라 전산수학이 발달한 덕분이다.

 

근데 실제 프로그램의 속도는 전산'수학'보다는 프로그램이 어떻게 설계되었는지가 중요하다.

내가 일하던 펌웨어 분야는 남이 아주 개판으로 짰어도, 어지간해서는 블럭 사이즈를 초과하지 않기 때문에 문제가 되지 않고

따라서 전산수학의 발전을 따라가지 않아도 서버에 문제가 발생하지는 않는다.

내가 지금 일하는 분야도 솔직히 전산수학 전혀 안 쓴다.

 

근데 '수학'이라고 이름은 붙어있지만, 결과물이 다르다.

이것저것 쓰고 싶은 내용이 많은데 술먹고 쓰는지라 뭘 써야 할지 모르겠다.

 

 

 

 

 

 

프로그래밍은 어쩌구 저쩌구 말이 많은데

프레임워크에 전혀 의존하지 않는 펌웨어 개발 입장에서

"프로그래밍"에 대한 이야기는

 

원자 명령을 모아서 분자명령을 만들고,

분자명령을 모아서 고분자명령을 만들고,

고분자명령을 모아서 현실세계의 문제를 해결하는 과정이라고 말하겠음.

 

즉 모든 문제는 '원자 명령'의 집합체로 해결됨.

c건 자바건 파이선이건.

(이 과정에서 스테이트건, 스레드건 하면서 골때리는 문제가 발생하지만, 그건 논외로 하고)

 

 

 

 

자.

여러분에게는 '원자명령'으로 a와 b 중에 뭐가 큰지를 판단하는 명령이 있다고 가정하자.

2개의 변수가 들어왔을때 둘 중에 큰 값을 출력하는 프로그램을 만들라고하면 어떻게 될까?

나는 많이 모자란 사람이라, 아래의 2가지 구현만 떠오른다.

 

1.

if(a>b)

ans = a;

else

ans = b;

 

2.

if (a>b)

temp = a;

else

temp = b;

ans = temp;

 

위 두가지 구현은 생긴건 많이 달라보이지만, 컴퓨터 입장에서는 썩 다를게.

문제는, 변수가 3개... 4개.. 혹은 그 이상일때 발생한다.

 

변수가 3개라고 하자

 

1.

if(a>b)

{

-if(a>c) ans = c;

-else ans = a;

}

else

{

-if(b>c) ans =b;

-else ans = c;

}

 

2.

if(a>b)

{

-temp = a;

}

else

{

-temp = b;

}

if(temp > c)

{

-do nothing;

}

else

{

-temp = c;

}

ans = temp;

별로 다르지 않다고?

변수가 4개라고 가정하자.

 

1.

if(a>b)

{

-if(a>c)

-{

--if(a>d) ans = a;

--else ans = d;

-}

-else // a<=c

-{

-if(c>d) ans = c;

-else ans = d;

}

else // a<=b

{

-if(b>c)

-{

--if(b>d) ans = b;

--else ans = d;

-}

-else // b<=c

-{

--if( c>=d) ans = c;

--else ans = d;

-}

}

 

2.

if(a>b)

{

-temp = a;

}

else

{

-temp = b;

}

if(temp > c)

{

-do nothing;

}

else

{

-temp = c;

}

if(temp>d)

{

-do nothing;

}

else

{

-temp = d;

}

ans = temp;

 

이처럼 같은 명령을 이용하더라도, 1과 2처럼 어떻게 동작할지는 달라진다.

중복된 코드를 빨간색으로 설정했는데, 어느쪽이 변수 4개를 5개로 확장했을 때 더 편할지를 생각해보자.

사람은 원체 다양하기 때문에 1번이 더 편하다는 사람이 존재할 수 있지만,

수학적으로는 2번이 더 편하다.

2번은 ans=temp 앞에다가 temp와 e를 비교하는 구문을 추가하면 끝이지만, 1번은 d와 비교하는 모든 구문에 e와 비교해야 한다.

1번은 temp 라는 변수를 사용하지 않았지만, "나"가 귀찮아진다.

2번은 "나"는 편하지만, temp라는 변수를 추가로 사용한다.

 

 

내가 다루는 펌웨어 기준으로 (c)

var1.var2->var3.var4[var5].var6.var7.var8.var9.var10

따위 코드는 굉장히 흔한 편이다.

위 코드는 어차피 복붙이라 입력하는것 자체는 문제가 없다.

var10이 typeA 라고 한다면,

typeA *shortCut = &var1.var2->var3.var4[var5].var6.var7.var8.var9.var10

라고하고 해당 변수를 바로 접근하는 대신 shortCut으로 접근하는 방법도 있다.

32비트 머신의 경우 shortCut은 32비트의 추가 메모리를 소모하지만, 변수를 1번에 접근할 수 있다.

shortCut을 적용하지 않은 경우 메모리를 접근하는데 var5가 변수인 경우 최악 더하기 1번 + read9번에서 최선의 경우 더하기 2번+read 1명령에 수행할 수 있게 된다.

심지어 read는 파이프라이닝을 할 수도 없다.

그렇다면 메모리의 용량 상황에 따라

shortCut을 선언하는 것이 효율적일 수도 있고, 선언하지 말아야 할 수도 있다.

 

 

 

 

 

struct {

int32 v1:4;

int32 v2:1;

....

}

같은 코드는 본래라면 권장하지 않는다.

각 변수에 들어갈 수 있는 값이 범위를 벗어날 수 있기 때문에.

그래서 struct 선언한 뒤에

#if V1_MAX_VAL > 16

ERROR!!!!!

#endif

같은 짓을 왕창 해둔다

V1_MAX_VAL이 늘어날 경우 struct의 bitfiled값을 바꾸도록 빌드에러를 발생시키는 건데

당연히 존나게 권장하지 않는 방법이다.

하지만 메모리를 아끼기 위해서 존나게 권장하지 않는 방법을 해야만할 때도 있다.

 

 

 

 

 

프로그래밍은 본래 프로그래머를 존나게 믿었지만, 현대 프로그래밍으로 갈 수록 안 믿는다.

이는 어떠한 수학적 발전이 아니라, 수 많은 경험 상 인간이 평균적으로 멍청하단 것을 알았기 때문에 발생한 경향이라고 본다.

그로 인해서 최신 프로그래밍은 "할 줄 아는" 것이 어렵지 "하기" 자체는 어렵지 않다고.. 생각한다.

 

뭐 c만 다루는 유사 개발자라서 틀린 말일 수도 있지만.