What is Programming?
프로그래밍: 컴퓨터가 이해할 수 있는 일련의 명령어(프로그램)를 작성하는 과정
프로그래밍의 사전적 의미는 위와 같다.
컴퓨터가 이해할 수 있는 명령어를 작성한다는 점에서,
말그대로 컴퓨터공학에서 강조하는
“컴퓨팅적 사고”의 중요성으로 이어진다.ex)
마인드맵의 자료구조는 무엇일까?
Notion 블록의 자료구조는 무엇일까?
티맵의 최적 경로 계산은 어떻게 할까?
Cursor Coding Assistant는 어떻게 설계했을까?
Program in perplexity
프로그램(program)의 어원은 다음과 같습니다:
어원
프로그램은 그리스어 'prographein'에서 유래했습니다. 이는 'pro' (이전에) + 'graphein' (쓰다)의 조합으로, "공개적으로 쓰다"라는 의미를 가집니다[5].
발전 과정
- 그리스어와 후기 라틴어 'programma': "공개 안내문"을 의미[5]
- 1630년대: "공개 통지"라는 의미로 영어에 도입[1]
- 19세기 초: 프랑스어 'programme'에서 유래한 영국식 철자 'programme' 사용 시작. 주로 "공연 일정표" 의미로 사용[5]
- 1920년대: TV 프로그램 일정을 지칭하는 데 사용[6]
- 1945년: 컴퓨터 프로그래밍 맥락에서 사용 시작[6]
컴퓨팅 분야에서의 의미 변화
- 1945년 ENIAC: "연산 프로그램"이라는 용어로 컴퓨터 설정 과정을 지칭[5]
- 1948년: Goldstine과 von Neumann이 문제의 코드화된 순서를 "routine"으로 정의[5]
- 1949년: "기계가 취할 논리적 단계 순서를 계획하는 과정"으로 프로그래밍 정의[5]
- 1950년대: 고수준 언어의 등장과 함께 "이상화된 언어로 작성된 명령 코드"를 프로그램으로 정의[5]
프로그램이라는 용어는 일련의 작업 목록에서 알고리즘의 전신을 거쳐 최종적으로 코드 자체를 지칭하는 것으로 진화했습니다[5].
출처
[1] Etymology of program by etymonline https://www.etymonline.com/word/program
[2] Program etymology in English - Cooljugator https://cooljugator.com/etymology/en/program
[3] PROGRAM Definition & Meaning - Dictionary.com https://www.dictionary.com/browse/program
[4] program - Wiktionary, the free dictionary https://en.wiktionary.org/wiki/program
[5] The origins of the word “program” in computing https://craftofcoding.wordpress.com/2022/01/06/the-origins-of-the-word-program-in-computing/
[6] How did “program” come to be electronic and computer lingo? - Reddit https://www.reddit.com/r/etymology/comments/f7jrdg/how_did_program_come_to_be_electronic_and/
[7] programme - Wiktionary, the free dictionary https://en.wiktionary.org/wiki/programme
[8] programme | program, n. meanings, etymology and more https://www.oed.com/dictionary/programme_n?tl=true
[9] Etymology of programme by etymonline https://www.etymonline.com/word/programme
점점 좋은 라이브러리와 프레임워크를 통해 상당 부분이 추상화되었고,
전체 코드 중에 개발자가 직접 구현해야되는 부분은 줄었다.
심지어 ChatGPT가 출시 되기 전에도 개발자는 command + c, command + v 키만 있으면 된다고 할 정도로
구현 난이도가 상당 부분 내려왔다.
ChatGPT가 출시된지 어느덧 2년이 됐다.지금 여기만큼 발전 속도가 빠른 곳은 본 역사가 없다.
그만큼 시간이 지나면서, 프로그래밍이라는 단어의 정의도 자주, 빠르게 변하고 있다고 생각한다.
내가 이해하는 프로그래밍
프로그래밍은 “무엇을 위해서,이것을어떻게?”에서어떻게를 담당하고 있다.
메타도 기획자들이 “효과적인 광고를 위해, 타겟 마케팅 광고 시스템을 만들자!”
구글도 기획자들이 “유저의 체류시간(=광고 노출)을 위해, 안보고 못 배기는 컨텐츠를 매칭해주자!”
SpaceX도 “로켓 비용 너무비싸! 로켓 비용을 위해서, 로켓이 집에 돌아오는 시스템을 만들자!”라고 했을 것이고,
개발진들은
어떻게…?라는 고민을 끝없이 한 끝에, 구현이 됐을 것이다.개발진들은 어떻게…?라는 궁금증 이후에 어떻게 하위 문제를 정의하여, 차례차례 해결해나갔을까?
크게
설계와 구현이다. 어떻게 → “이렇게하자!”
“아주 그냥 다방면으로 유저행동데이터 수집해서, 고객과 광고를 랭킹알고리즘으로 추천하자!”
앞에서도 언급했지만,
하자!의 난이도는 안그래도 많은 부분이 추상화 되어 해결되었으나, AI가 상당 부분을 미친듯이 가속화 하였다. 꼼꼼히 문법지키고, 반복 수작업
그렇다면, 이제 미래(어쩌면 현재)의 프로그래밍은
이렇게에 더욱 초점이 맞춰지고 있다.- 추상화되지 않은 부분은 앞으로도 여전히 구체화 해야한다.
- 퀄리티가 전보다 90에 빨리 달성됐다고, 90에 만족하는 집단은 없다. 옆 집단은 100에 더 빨리 다다를 것이기 때문이다.
이렇게 를 잘하기 위해서는 예전에는
어떻게에 팀원 각각의 수직적 이해도를 갖고, 10명이 투입됐다면, 지금은
더 적은 인력(=비용)으로 더 많은 수평적, 수직적, 입체적 문제해결역량이 요구된다.ex)
- 수평적(=넓은 이해도): Langchain, VectorDB, Text Embedding, “무엇이 가능하고, 어떤 툴을 언제 써야 할지 알고 있다.”
- 수직적(=깊은 이해도): 강화학습, 코사인유사도, 유클리드 거리, Self-Attention, Multi-Head Attention, Fine-Tuning “이 기술이 어떻게 작동하는지 알고, 최적화할 수 있다.”
- 입체적(=다양한 이해도): 금융 데이터, communication, MLOps “다양한 관점을 기반으로 완성도 높은 시스템을 만든다.”
예전에는 복싱, 레슬링, 유도가 유명했다면, 이제는 종합격투기(UFC)의 시대이다.
예전에는 수비수, 미드필더, 공격수가 중요했다면,
이제는 공격의 다양성과 공간 창출을 위해 팀에서 풀백과 골키퍼의 역량까지 중요해졌다.
고차원적으로 문제를 해결하려는 마인드는 AI 시대에도 추구해야하는 역량이지 않을까?
이렇게나는 왜 이게 좋은가?
크게 3가지인것 같다.
문제해결능력
앞에서도 말했지만, 문제해결능력은 이 일을 함에 있어서, 굉장히 중요한 요소이다.
근데, 이 역량은 평소에도 정말 중요하다.
문제는 삶에 있어서 항상 있어왔고, 항상 대비를하고, 만성적이든 급성적이든 유연하게 대처해야한다.
실제로, 문제 해결을 위해 단순히 구글링을 습관화했다는 것만으로,
또 영어 자료 및 논문을 거리낌 없이 찾아보는 습관을 들였다는 것만으로도,
삶에서 상당 부분이 수월해짐을 느꼈다.
완벽이란 표현은 너무 이상적이라고 생각한다. 당장 확신이 들고, 절대 오류 없을 것 같은 아키텍처와 코드도, 그저 아직 오류를 맞닥드리지 못했을 뿐이다.
오히려 컴공에서는
최적(optimize)이라는 단어를 많이 쓰는 이유가 그런 것이 아닐까 싶다. 완벽(perfect)라는 단어는 컴공에서 잘 들어보지 못했다.
그래서 나는 항상 들이박고 보는 것 같다. 일단 머드 축제에 뛰어들고 나서 생각한다.
모든 문제는 보고만 있으면, 엄두도 안나고 막막하기만 하다. 때로는 문제가 문제인지도 모른다.
완벽하다고 믿는 자동화 시스템은 결국 자동화를 위한 자동화를 위한 스크립트 코드가 된다.
장애 복구 시간(MMTR)을 줄이는 것. 즉, 회복탄력성을 높이는 것이 정말 중요함을 느낀다.
나는 그래서 이 일을 좋아한다.
큰 수의 법칙: 빅데이터
큰 수의 법칙은 표본집단의 크기가 커지면 그 표본평균이 모평균에 가까워 짐을 의미한다
노력 이라는 단어가 가장 잘 어울리는 통계적 개념이다.성공의 왕도는 이미 많은 사람들에게 알려져 있다.
“매일 꾸준히 해라”
하나같이 GOAT들의 성공스토리에서 나오는 진부하고 뻔한 얘기다.
하지만, 실제로 노력의 반복과 꾸준함은 결국 원하는 결과에 가까워지게 만든다.
주식도 장투가 쉬워보이지만, S&P500을 30년 들고있던 사람은 닷컴버블과, 서브프라임모기지 사건, 코로나 등 수 많은 위기가 있었을때, 수 많은 의심 속에서 꾸준히 그 믿음을 놓지 않은 것이다.
이 분야에서 어떠한 예체능, 과학, 문학 GOAT보다 뛰어난 놈이 있다.
AI는 채찍을 그 누구보다 많이 맞은 놈이다.
그 수 많은 데이터가 들어오고, 채찍과 당근을 양분삼아 LLM이 되었다.
데이터가 가진 힘은 이미 너무 체감하고 있고,
이놈이 내편이 되어, 나에게 점점 더 좋은 무기가 되어주는 것을 보고 있으면, 너무 재밌다…
앞으로 뇌과학과 양자컴퓨터의 발달로 전력효율과 메모리, 연산혁명까지 이루어진다면,
그 미래를 예측하는 것은 내가 감히?라는 생각이 절로 들 정도이다.
그래도 이 무시무시한 분야에 발을 들이고 있다는 것이 참으로 다행이라는 생각은 든다.
문제가 문제인지도 모르는 것이 진짜 문제니까.
공대 작가
Git Commit History를 보면, Git Graph야 말로 정말 삶을 가장 잘 나타내는 자료구조가 아닌가 싶다.
코드는 문서가 되고, 그 문서는 여러 branch로 나뉘었다가 다시 merge되기도 한다.
한프로젝트의 여러 branch가 충돌나고 resolve되고,
컴퓨터에 대한 상처, 깎임, 인내, 도파민이 이 문서들에 녹아있다.
어느 유튜버가 했던 말이 떠오른다. 컴퓨터공학은 공학 중에 유일하게 수학이라는 공학언어가 아닌,
프로그래밍 언어 를 쓴다고. 역시 매력적이고 재밌는 분야인 것 같다. 언어를 갖고 글을 쓰고, 문서를 구조화하고, 그 문서들 안에서 무궁 무진한 멋진 놈들을 엮어낸다는 것.
어떻게 보면, “공대 작가”가 아닐까 생각한다.
앞으로 나의 코딩스토리도 Git Commit History처럼 기록해보려고 한다.
자주 올 수 있을지는 모르겠다.
실제로 워킹할 프로덕트를 서빙하고 유지보수하는데 필요한 것은 처음보다, 오히려 지금이 알면 알수록 더 어렵다.
돌아보면, 기록하면, 도움이 될때도 있고, 실마리가 될 수도 있고,
그 자체가 나의 희노애락이 담긴 하나의 private repository가 되겠지
Share article