Twowix World

설날연휴에 경마 분석 딥러닝을 시켜보았습니다.

Twowix — Sat, 1 Feb 2025 16:58:39 +0900

저는 일년에 한두번씩 데이트를 하러 가거나 친구들끼리 놀기위해 경마장을 가곤합니다.
(걱정 마세요~ 현금 3~5만원 정도 들고가서 놀이공원 입장료라고 생각하고 즐깁니다. 과도한 금액은 가정을 파괴합니다.)

경마장을 가보신분들은 알겠지만 경마장에 들어갈 때 필수로 구매해야 하는것이 존재합니다.
바로 경마지이죠.

아주 빼곡한 각종 정보

경마지에는 그날의 경기별로 엄청나게 많은 데이터가 적혀있습니다.
정말 세세하죠.
훈련사의 훈련평부터 해당 말의 과거기록은 당연하고, 몸무게 변화량, 과거경기의 상태 등등 정말 나열할 수 없을 만큼 많은 정보가 있습니다.

또 재미난것이 잘 달리던 말들은 다음번에도 대부분 잘 달리더라구요.
동물의 세계에서 서열이 존재하는것인지..
서로 경주를 했던 말들이 또 만나서 경주를 하면 그전에 이겼던말이 높은확률로 또 이기곤합니다.
(물론 항상 그렇진 않습니다. 그러니까 도박이겠죠)

그래서 경마장에 가보면 엄청난 학구열을 가진 아저씨와 아줌마들이 경마지를 두세개씩 들고 자신만의 분석을 해가며 엄청난 공부를 하는 풍경을 보게됩니다.
(정말 학구열이라는 표현이 맞을 정도로 엄청난 집중력으로 싸인팬으로 공부를 하고있습니다.)

과거 저는 데이터는 충분하니 데이터만 잘 모으면 통계학적으로 접근이 가능하지 않을까? 라는 생각을 하였고
'언젠가 시간이 나면 만들어봐야지~' 라는 생각을 한 채 시간이 꽤나 흘렀습니다.

그렇게 기억에서 잊혀질쯤...

2025 설연휴는 정말 길고 긴 휴가였습니다.
딱히 가는곳도 없고 집안에만 있기 적적하여 집중하여 경마 예측프로그램을 만들어 보았습니다.
(매일매일 15시간씩 개발 한것같아요. 오랜만에 너무 재밌어서..)

과거에 저는 ai나 딥러닝, 머신러닝같은 기술이 보편화되지 않았기에 통계학적으로 접근을 하려 했다면,
딥러닝을 공부할겸 딥러닝으로 학습을 시켜보자라는 결론이 나왔고, 먼저 마사회의 API를 모두 살펴보았습니다.

마사회 API는 상당히 많은 정보를 얻을 수 있습니다.
다만 문제가 조금 있었습니다.

마사회의 경기 결과 API 일부

겹치는 레거시 API들이 상당히 많이 존재하고
같은 값을 표현는 여러개의 키값이 존재 하거나
하나의 키의 데이터 형식이 다르거나
키값이 무엇을 의미하는지 설명이 잘 안되있다거나
(예를들어 등수는 숫자 1, 혹은 '01' 로 문자열, 특수문자 ① 등등 으로 하나의 키값에 존재합니다..)

꽤나 많은 작업을 거쳐야 이 데이터를 쓸 수 있겠다는 결론이 납니다.

같은 업을 하는 사람으로써 이해는 합니다...
왜냐하면 마사회 API는 놀랍게도 1985년 자료부터 값을 가져올 수 있습니다.
(제가 태어나기 전 부터 데이터를 저장해두었다는 사실에 얼마나 고생했을지 눈에 선합니다. 처음에는 수기로 작성했겠죠?)

저 많은 데이터를 처음부터 데이터 타입을 잘 맞추고 설계를 했다면, 문제가 없었겠지만 엄청 오래된 시스템의 마이그레이션은 상상 초월의 억압을 주곤하죠.

해당 데이터베이스를 거친 얼마나 많은 개발자가 있었을까요.
(그래도 너무 오래됐거나 사용을 안하거나 중복이되는 API들은 관리를 좀 해줬으면 좋겠습니다.)

데이터를 보다보니 너무 과거 데이터는 신뢰성이 좀 떨어지겠다는 느낌이 들었습니다.
그래서 2000년 데이터 부터 사용하자는 결론을 가지고 전처리를 하기 시작했습니다.
말정보, 기수정보, 경기정보, 경기출전마, 경기결과, 말무게정보, 주로별결과정보, 날씨정보, 말의진료정보 등등 10가지 이상의 마사회의 API를 사용하였습니다.
(워낙 API형식도 다르고, 특정 데이터가 없을때도 있고, 여러가지 결측값이 많이 있어서 이 작업만 이틀은 걸린것 같습니다.)

약 80만개의 데이터의 기본적인 전처리를 마쳤습니다.

이제 할 일은 학습을 어떻게 시킬꺼며, 어떤 데이터를 가지고 학습을 시킬까에 대한 고민이 있었습니다.

처음에는 몇가지 논문을 봤습니다.
의외로 경마에 대해 머신러닝이나 통계학적 접근을 하는 논문들이 꽤나 있더군요.

상당히 재밌게 읽었지만 딥러닝에 대한 정보는 찾을 수 가 없었습니다.

저만의 기준으로 중요한 정보라고 생각하는
말의 평균속도 (경기거리/시간), 처음 200m 주파 시간, 마지막 200m~결승선 주파시간, 경기거리, 말의승률, 기수의승률, 말의중량, 부담중량, 말의 성별 등등 꽤나 많은 파라미터를 가지고 학습을 시켜보았습니다.

학습 방법 및 각종 사용한 방법론은 글로 작성하기에 너무 길 수 있으니 이 후 시간이 되면 작성해보도록 해보겠습니다.

학습데이터는 2000~2024년도의 데이터로 학습을 하였습니다.
모델을 검증하기 위해서 2025년도의 데이터를 사용할 예정이었기 때문에 2025년의 데이터도 학습을 시켰을 시 과적합의 문제가 생길 수 도 있다고 판단하였기 때문입니다.

아무래도 데이터베이스에 값을 저장해두었기 때문에 너무 많은양의 데이터를 가져오느라 매번 학습시에 너무 오래걸려서 따로 캐싱 시스템을 만들어서 학습시간을 단축을 시켰습니다.

(그래도 오래걸리더군요..제 아내에게 rtx5090을 사달라고 땡깡을 부려야할 것 같습니다.)

그리하여 2025년 1월 경기들로 대한 예측을 해보았는데..

3등안에 들어갈말 3마리를 고르는 예측율이 60%~65%가 넘게 나오는겁니다.
(3등안에 들어갈 말 3마리를 고른 이유는 경마의 승부는 단승-1등말맞추기, 연승-3등안에들어오는말 하나 맞추기, 삼복승-3등안에들어오는말 3마리맞추기 처럼 대부분 3등안쪽을 맞추는 도박이기 때문입니다.)

처음에는 '와 파라미터를 제대로 잡았나? 이렇게 예측율이 높다고?' 라고 생각했습니다.
그런데 아무리 생각해도 조금 이상했습니다. 너무 예측율이 높았기 때문이죠.

그러다 문제를 찾았습니다.

그 중 하나는
1. 예측대상의 각 종 값은 최근 6개월 경기의 평균으로 잡고있었다.
2. 하필 거기에 예측할 경기의 값도 포함되었다.
3. 과거기록이 없는 신마는 예측할 경기의 값만 평균으로 잡힌다.
4. 사실상 실제경기랑 같은 결과가 나오게 된다.

예측 파라미터설정을 잘못 잡은것이었죠.
이외에도 여러가지 부분을 잡아서 최대한 객관적으로 잡아두고 다시 검증을 했습니다.

바로 33~38%대로 예측율이 떨어졌습니다.
한 경기에 말이 9~14마리 정도 출전을 하니 랜덤으로 골랐다면 약 20%~30% 사이의 값을 보일 수 있습니다.
그것보다는 높으니 어느정도 괜찮은 학습이 되었다고 볼 수 있습니다.

다만 여기서 만족하고 싶지가 않았습니다.
목표는 45%대의 예측율이었습니다.

그래서 경주의 결과와 예측가중치를 따로 살펴보니, 이상하게 실제 전문가들은 높게 쳐준말이 예측치가 너무 낮게 나오는 현상이 있었습니다.

아내와 함께 해당 값을 연구하기 시작했습니다.

아내와 계속 연구를 하며 결국 모델 학습시 사용했던 말의 중량, 말의 중량 증감값(직전경기대비 플러스 마이너스) 등의 말의 무게에 대한 값이 영향을 주고 있다는 결론이 났습니다.

평균속도 -> 높으면좋음
말의 승률 -> 높으면 좋음
말의 부담중량(안장, 기수의 무게등) -> 낮으면 좋음
같은 파라미터는 확실하게 방향성이 있는 수치이지만

말의 중량 -> 높은게 좋은가? 낮은게 좋은가?
말의 무게 증감량 -> 직전경기대비 살이 찐게좋은건가? 마른게좋은건가? 변화가 없는게 좋은건가?
처럼 방향성이 없기 때문이죠.
(물론 어느정도 중간값이 좋다라고 스코어링을 잡고 가는 방법도 있을듯합니다.)

그렇게 여러가지 파라미터에서 방향성이 확실한 파라미터만 남겨두고, 애매한 파라미터(말의나이, 날씨, 습기, 주로상태 등등)는 모두 정리하고 학습을 진행하였습니다. 거기에 조금더 확실한 방향성을 가진 파라미터는 조금 더 추가하여 학습을 진행하였습니다.

그렇게 학습 후 예측을 하니 현재는 원했던 45%~47%의 예측율에 가까워진 상황입니다.

가장 위에 있을수록 최근학습한 모델의 예측값입니다. 확실히 3등이내 적중율이 올라가는게 보이죠.

그 이후 어느정도 모델을 잡아서 빠르게 웹으로 볼 수 있는 사이트를 만들었습니다.

모델을 선택하고 특정 날짜를 선택하면, 예측된 값과 실제 경기의 결과를 표현하게 만들었습니다.
예측내에 분홍색은 3등안에 들어온 말, 파란색은 5등내에 들어온말 그외 여러 정보를 더 넣을 예정입니다.

2007_2024년도 학습모델을 통한 1월 12일 경기 예측

날씨가 풀리면 아내와 함께 경마장에 가서 제가 학습시킨 모델을 통해서 1000원 2000원씩 소액으로 즐기러 가봐야겠습니다.

오랜만에 너무 재미있게 진행한 프로젝트였습니다.
조금 더 예측율을 올리기위해 가끔 시간이 될 때 프로젝트를 열어 파라미터 조정도 하고 재미를 봐야겠습니다.

ps. 경마는 도박입니다. 소액으로 가끔 즐기세요

GPT와 개발자에 대한 고찰

Twowix — Tue, 26 Nov 2024 20:49:27 +0900

GPT와 개발자에 대한 고찰

어제밤 잠이 안와 GPT와 개발자의 관계에 대해 잡생각이 나서 꼬리의 꼬리를 물다가 글을 작성하게 되었습니다.

책->검색엔진->GPT
이전세대에서는 개발을 하려면 책을 통해 공부를 하여, 공부를 한 지식을 기반으로 개발을 해야했습니다.
아마 개발자의 서재에는 개발서적이 빼곡히 채워져 있었을거라 생각합니다.
그러다 자신이 부족한 지식을 빠르게 책을 찾아 공부하고 개발을 했을겁니다.

그분들이 열심히 개발을 하여 웹의 발전이 점차 진행되었고

어느덧 다음세대의 개발자들은 책과 검색엔진을 통해 정보를 얻어서 개발을 하기 시작했습니다.
개발자의 구글검색 사랑은 엄청났습니다.
검색엔진을 잘다루는 것이 개발자의 덕목이 될정도였습니다.
검색을 잘하는 비법', 검색 키워드를 공부하는 사람이 생길정도로요.
(여전히 구글에 "개발자 검색 잘하는법" 이라고 치면 수천개의 글이 나옵니다.)
(기시감이 든다면 맞습니다. 마치 '프롬프트 엔지니어링' 같은 느낌이랄까요?)

그러다 GPT가 등장을 했죠.
당연하게도 개발자들이 GPT를 사용하여 개발을 하기 시작했습니다.
바로 이전세대처럼 GPT를 잘다루는 것이 개발자의 덕목이 되진 않았지만 조만간 그런 시대가 올거라 봅니다.
그렇다면 당연하게도 질문을 잘하는법에 대해 점차 니즈가 생기게 되고,
'프롬프트 엔지니어링'이라는 꽤나 있어보이는 단어가 나옵니다.
단어는 거창해보이지만 크게 차이는 없습니다.
원하는 답을 얻기 위한 '질문을 잘하는 방법'이죠.

GPT의 개발생산성과 기반지식
GPT를 이용한 개발은 개발 생산성 측면에서 상당한 도움이 됩니다.
이전에 검색엔진을 필요한 정보를 찾아 개발을 하는것보다 체감상 몇배는 빠르게 정보를 이용할 수 있습니다.
GPT를 이용하지 않을 이유가 없는것이죠.

다만 여기에는 조건이 있습니다.
프롬프트에 자신의 기반지식을 통해 질문을 해야한다는것이죠.
뭘 모르는지 모르는 상태라면 GPT를 이용해도 질문자체가 어려울 수 있습니다.
따라서 기반지식이 많은 개발자일수록 GPT를 사용했을때 퍼포먼스가 더 좋아집니다.

어느정도 경력이 있을수록 개발할때 오히려 GPT를 더 많이 사용한다는 것이라는 말일 수도 있습니다.
슬프지만 요즘 시장이 안좋은것도 있지만 신입개발자 공고가 많지 않은 이유도 GPT도 어느정도 숟가락을 더했다고 생각합니다.

이쯤에서의 문제점
"이제는 GPT없으면 개발도 못할지경이다" 라고 이야기하는 개발자분들이 점차 많아지고 있습니다.
그만큼 GPT에 점차 의존도가 높아지고 있습니다.
저 역시 마찬가지구요.

GPT에 의존해도 생산성이 높으니까 좋은거아니냐구요?
아마 기업, 서비스측면에서는 좋을 것 같습니다.
하지만 개발자 개개인에게는 과연 어떨까 합니다.

GPT로 얻은 생산성만큼 개개인의 개발능력은 점점 떨어지고 있다는 것 같다는 느낌이 듭니다.
빠르고 쉽게 얻은 정보인만큼 정말 빠르게 휘발됩니다.

함수의 코드 종속도, 결합도
갑자기 개발얘기를 하겠습니다.
개발을 하다보면 특정 함수가 어떠한 코드에 종속이 많이 되어있거나, 결합도가 상당히 높아질때가 있습니다.
해당 코드가 아니면 다른곳에서 재사용 자체가 어려운 함수가 되는것이죠.
그러면 해당 함수는 그 코드가 변경되거나 사라지면 함께 변경되거나 사라지게 됩니다.

종속, 결합된 개발자
요즘은 클라우드내의 서비스가 너무 잘되어 있어서 서버 세팅 및 구성이 정말 간편해졌습니다.
하지만 가끔은 개발 사항에 따라 클라우드 내의 서비스를 이용하지 않고, 서버내에 직접 서버를 구성해야 하는 경우가 있습니다.

예를들어 데이터베이스를 직접 구성해야하는 일이 생겼는데,
AWS의 RDS로만 데이터베이스를 구성해본 개발자라서 "저는 RDS로 밖에 데이터베이스 못만들어요.."라고 말한다면..

'AWS가 사라지면 당장은 할 수 있는게 없다' 라고도 볼 수 있습니다.

요즘은 개발에 대해서 전방면에서 너무 발전이 되어 '개발이 아닌 조립을 하고있는게 아닌가?' 라는 착각이 들기까지 합니다.
그만큼 개발자들이 서비스와 종속, 결합도가 높아지는 경향도 있구요.

그러면 어쩌라고
뭐 어쩌라는 이야기는 아닙니다.
그냥 문득 생각의 꼬리가 꼬리를 물어서 적은글이니깐요.
다만 개발자 개개인의 성장을 위해서 가끔은 의도적으로 불편하게 개발을 해야 할 시대가 되지 않았나 합니다.
(누워서 개발하기, 물구나무서서 개발하기, 이런거 말구요)
머리를 쥐어뜯어가며 직접 개발을 했을때 그것만큼 성장곡선이 가파른게 없다고 생각하기도 합니다.

기초가 없는 디테일은 없고..
기반이 없는 능력은 쉽게 무너지지 않나..
라고 생각하기 때문이기도 한 것 같습니다.

개발하는 아저씨의 2022년 회고

Twowix — Wed, 1 Mar 2023 17:02:13 +0900

어느덧 2023년이 두달이나 지난 시점에 회고를 쓴다는게 이상하긴 하지만..

다사다난했던 22년의 연장선에서 이제서야 숨통이 트이는 시점에 글을 남긴다.

신규 개발팀의 시작과 끝

21년도 후반 이직을 하였고, 이직을 한 회사는 개발팀이 없는 회사로 개발팀을 새로 구성을 해야 하는 상황이었다.

어쩌다보니 개발 팀장이 되어 어쩌다보니 동료들을 하나 둘씩 구성을 하기 시작 하였고, 어쩌다보니 5명 남짓되는 작은 개발팀이 셋팅이 되었다.

그렇게 개발은 시작되었고, 무리없이 개발은 진행되고 있었다....만
22년도의 시장 상황은 급박하게 변하고 있었고, 그 어려움을 회사는 버티질 못했다.

그렇게 회사는 문을 닫게 된다.

깊은 내용까지는 적을순 없지만 22년도 겨울은 그 어느때보다 유독 추웠던 것 같다.

다시 시작

문을 닫은 회사의 모회사로 부터 제안을 받아 모회사로 다시 들어가게 되었고 회사의 내부 솔루션을 신규로 제작하는 일을 하기 시작했다.

엄청난 의욕저하와 '조금은 쉴까?' 했던 마음도 있었지만..
사람이 참 간사한게 개발을 하다 보니 또 재미가 있다.

현재 프로젝트는 수월하게 진행되고 있고, 언제나 바래왔듯 이번 프로젝트는 성공적으로 지나갔으면 한다.

리더

가슴이 아픈 22년도 였지만 그럼에도 불구하고 항상 배우는 것들은 있다.

나는 초,중,고에 언제나 반장,부반장을 해왔으며, 고등학교 응원단의 부단장을 거쳐, 노래한다고 까불던 어린시절에 그룹의 리더로 살아왔고, 온라인 게임에서 대형길드의 길드마스터로 활동을 했었고 (이상하게 볼 수 있겠지만 사회에 대해 가장 많이 배운곳이 게임이다.) 이 후 짧게 작은 앱의 스타트업 대표로 어느 정도 지내왔다.

이렇게 지내온 나는 거만하게도

"나는 리드를 많이 해왔던 사람이라서, 잘 할 수 있어"

라고 생각을 하며 지내 왔었다.

그렇게 개발자로 일을 하다보니 당연히 연차는 쌓이고, 경력 역시 쌓이니 동료들을 리드를 해야하는 순간이 오고, 실무와 관리직을 겸하게 되는 순간이 온다.

하지만 사람을 관리하고, 조직의 문화를 만드는 일은 고려해야 할 상황이 매번 다르다.

당장 떠오르는 고려할점만 적어도 동료의 성향, 실력 등 인적에 관한 상황이 있을 것 이며, 회사의 자금, 문화 등 조직에 관한 상황도 있을 것이다.

22년도에는 팀장으로써 많은 고민을 했었는데, 조금은 리더에 대한 생각이 변화한것 같다.

회고에 모두 적기에는 생각의 양이 많아 추 후 따로 글을 쓰던가 하겠지만 간단히 말해서

기존까지의 나는

"대장은 다 잘해야 해! 한명이 빵꾸나도 티가 안나게 대장이 다 매꿀 수 있어야 해!"

라는 생각이 지배적이었다면

이제는

"대장이 빵꾸나도 팀이 잘 돌아가야 그게 팀이야"

정도가 되지 않을까 한다.

게임

재작년부터 진행하였던 사이드프로젝트인 게임개발도 상당히 많이 진행되었다.

이제 꽤나 게임같다.
엄청 많이 개발했는데 할것도 엄청 많이 남았다..

개발중인 게임

결혼

어느덧 연애를 한지 900일이 넘었고, 22년 하반기 부터 결혼을 준비하고 있다.

다들 결혼준비 하는게 어렵고 준비하면서 많이들 싸운다지만

다행히 나는 운이 좋게도 마음이 잘 맞는 사람을 만나 큰 무리없이 준비가 진행되고 있다.

결론

회고의 결론이 있는게 맞나 싶지만...
(그냥 결혼/결론 라임 맞추고 싶었다.- 아재특)

피곤하고 힘들었던 22년은 지나갔다.
그렇다면 23년은 뭘해도 22년보다는 좋을것이다.

그럼 좋은것이다.

[PYQT] 급하게 만든 나만의 이미지 컨버터 (변환/압축)

Twowix — Sun, 11 Sep 2022 01:46:11 +0900

오늘은 추석이다.

자꾸 아버지가 pdf 파일을 jpg로 바꿔달라고 그랬다.
그리고 이미지파일은 jpg로 압축을 해달라고 그런다..

웹에 널려있는 온라인컨버터로 간단하게 변환을 시키고 싶었지만,
중요 자료이기에 공개된 웹상에서 하기엔 보안상 안좋다고 판단했다..

그래서 그냥 만들었다.

Info

pdf / jpg / png 이미지 변환 및 압축 프로그램

Install

각 OS에 맞는 압축파일 다운 및 압축 해제
window - win-twowix-image-converter-0.1.0.exe
mac = mac-twowix-image-converter-0.1.0.zip (TODO-맥이 회사에 있음..)

Usage

twowix-image-converter 실행
파일 선택 버튼으로 파일 가져오기 (pdf, jpg, png)
저장 경로버튼으로 저장할 폴더 선택

변환: pdf -> jpg / png, jpg -> pdf 로 하나씩 변환
압축: pdf, png, jpg -> jpg 로 압축

병합: png, jpg -> 하나의 pdf로 병합

Licence

누구나 편하게 사용하셔도 됩니다. (FREE)

소스는 깃헙에서 확인해주세요!

https://github.com/twowix/twowix-image-converter

사내 비개발자들이 보는 개발자에 대한 오해

Twowix — Sat, 12 Feb 2022 11:37:01 +0900

필자는 직업이 개발자라..

개발을 하며 살다보니 여러가지 개발자에 대한 오해를 겪곤한다.

과연 개발자는 어떤 오해를 받고 살고 있을까???

1. 개발에 관련된 모든것들을 할 줄 안다?

개발자라는 직업은 알고보면 정말 세부적으로 많이 나눠져있다.

당장 웹개발이라는 분야내에서도 퍼블리싱, 프론트, 백엔드, 데이터베이스, 데브옵스 등 상당히 많은 분야로 나눠져 있고

거기에 언어별로 또 나눠져 있다.

같은 백엔드 개발자여도 자바를 메인으로 사용하느냐 파이썬을 메인으로 사용하느냐에 따라 그들의 숙련도는 완전 다르다.

모든 분야가 그렇지만 직업이라는 것은 세부적인 분야가 상당히 많이 나눠져 있다.

다만 아직 개발자라는 직업이 오래되지 않은 직업이기도 하고 (다른 분야에 비해서..)

개발자의 세부 분야에 대한 용어 자체가 생소하기도 하니까 아무래도 비개발자분들이 볼땐 같은 개발자로 보게되는 경우가 왕왕 있는것 같다.

그러다 보니 이러한 오해가 생길 수 있는것 같다.

: "개발자 (웹프론트엔드 개발자) 님! 윈도우에서 돌아가는 포토샵같은 프로그램 하나 만들어주세요!"

: "그건 응용프로그램이라.... 제 영역이 아니에요."

: " 님 개발자아닌가요?"

: "그건 맞는데...."

해당 대화는

야구선수에게 운동선수라고 같은 운동이니까 축구도 잘하겠지? 라고생각하는것과 같은것

당연히 비운동선수보단 빠르게 적응은 하겠지만.. 다른 분야임은 확실하다.

2. 같은 분야 다른 개발자의 프로젝트를 바로 파악 할 수 있다?

한글을 안다고 해서 처음 접한 장편 소설의 줄거리를 바로 알 수 없는것과 같은 이치다.

예를 들어 소설작가 (해골)에게 (고양이)작가의 소설을 조금 수정 해달라는 요청이 왔다고 쳐보자.

" (해골)작가님! (고양이)작가님의 소설 4부의 5번째 단락을 조금더 긴박하게 작성해주실 수 있을까요?"

라고 했을때 당연히 (해골)작가는 (고양이)작가의 소설의 내용 및 줄거리를 전부 파악을 해야하고, 수정해야할 앞쪽 단락과 뒷쪽 단락에 어긋나지 않게 구성해야 하며, (고양이)작가의 글과 최대한 비슷한 문체로 작성을 해야한다.

개발도 똑같다.

"기존에 다른개발사에서 만든 프로젝트에서 해당 부분의 기능을 수정해 주실 수 있을까요?"

당연히 개발자는 해당 프로젝트를 파악해야하고, 수정해야할 기능의 앞 뒤 프로세스가 어긋나지 않게 구성해야하며, 해당 프로젝트의 컨벤션을 최대한 비슷하게 작성해야한다.

따라서

"그냥 똑같은 코드인데, 그거 하나 바꾸는데 왜이렇게 오래걸려?"

라는 것은

"그냥 똑같은 소설인데, 줄거리 바꾸는게 왜 이렇게 오래걸려?"

와 비슷한 맥락이라고 볼 수 있다.

(물론 예시일뿐이다. 프로젝트 바이 프로젝트로 정말 빠르게 파악해서 쉽게 수정이 될 수 도 있다.)

(어떤 직업이든 비슷한 경향이 있을 것이다.)

3. 컴퓨터(하드웨어)를 잘 다룰 줄 안다?

이 주제는 이미 많은 개발자 유머에서 많이 나오는 주제이므로 짧게 넘어가겠다.

대부분의 개발자는 상상하는것 만큼 컴퓨터를 잘 다루지는 못한다.

4. 수학을 잘한다?

물론 개발자는 수학을 잘할수록 개발에 대한 이해도가 빠르며, 수학을 잘하면 확실히 유리하다.

(정확히는 수학자체가아닌 수학적인 사고를 잘할 수록 유리하다.)

필자는 가끔 사람들에게 자조적인 말투로

"내가 무슨 개발자야~ 그냥 조립하는 사람이지"

라는 말을 할때가 있다.

요즘은 오픈된 API, 각 종 라이브러리, 개발관련된 서비스들이 너무 잘되어 있고 많이 있다.

~~조금 심하게 말하자면 그냥 재료들을 잘 조립하면 개발 잘한다는 소리를 듣는 시대이다.~~

그래서 수학적인 논리가 필요하지 않은 작업이 점점 많아지며,

"수학? 그게 뭐가 필요해?" 라고 말하는 개발자도 많다.

따라서 결론은 그렇게 수학을 잘하는 개발자는 많지 않다.

물론 개발자 바이 개발자다.

어쩌다보니 개발자에 대한 오해를 작성해 보았는데..

사실 이것말고도 개발자에 대한 오해는 상당히 많지만 당장 생각나는것만 적어 봤다.

ps. 사람의 성격이 모두 다르듯이 개발자 역시 모두 다르기 때문에 재미로 봐주세요!

모두가 내 직군은 아니다. (무엇이 그들을 다른 일을 하게 만드는가)

Twowix — Sat, 15 Jan 2022 17:20:48 +0900

포스팅에 앞서서 먼저 하나의 대화록을 먼저 봐보자

기획자: 이번에 웹의 결제쪽 UI/UX개선을 통해 인터렉션을 최대한 올리는 방향성 GNB와 더욱 나아가서 FNB쪽을 수정하는 방향성으로 기획을 해보았습니다. 디자이너님께서 확인 좀 부탁드립니다.

디자이너: 그러면 여기 GNB는 그라데이션이랑 애니메이션을 최대한 활용해서 FNB는 기존값을 유지하는편으로 구성해서 만들어볼텐데, 조금 더 불규칙하게 만들어볼께요...

프론트개발자: 불규칙하면 전부 다 앱솔루트로 잡아야하는데, css의 블럭 포지션이 문제가 생길꺼 같아요. 그리고 애니메이션위주면 브라우저렌더링에 문제가 생길꺼 같은데....흠.. 기존 값들은 최대한 쿠키쪽으로 담아서 처리를 해볼께요...

디자이너: 쿠키??로 담으면 불규칙이 된다는거죠?

경영진: 그러면 거기서 결제가 많이 일어나는건가요? 결제하는 동시에 다른결제도 합쳐서 되게 만들어볼까요?

백엔드개발자: 그러면 기존 디비 트렌젝션에 문제가 생깁니다. 기존의 레디스쪽이 어쩌구저쩌구 캐시랑 충돌이나서 어쩌구저쩌구 아에 전부 마이그레이션해야 할 수 도 있어요.

경영진: 그럼 된다는거죠?

마케터: 결제와 동시에 결제가 일어나는건 좋은데요? 그나저나 기획서를 보니 기존에 있던 배너 임프레션이 낮아질거같은데 CTA는 고려된건가요? 현재 DAU로 봤을때 어쩌구젖저구.....

지나가는 전파상: 아 그렇게 만들면 전압이 튀어서 쇼트가나~ 최대한 줄여..

지나가는 기타리스트: 그러면 최대한 풀링오프로 표현을 하면 다음 레가토 부분에서 멋지겠는걸요?

경영진: 그럼 만듭시다.

이렇게 귀엽게 회의가 되면 좋으련만..

해당 대화록에서 얼마나 서로 이야기가 통했을까?

(물론 대화록은 좀 극단적이긴 하다..)

결론부터 말하자면 저들은 대부분 해당 기획은 안된다는 얘기를 하고 있지만 결론적으로 해당 프로젝트는 진행되게 되버린다.

왜 이런일이 일어나는 것일까?

사실 이런 대화는 굳이 사무실이 아니더라도 친구들끼리, 연인도, 가족도 모두 일어난다.

각자의 용어를 상대도 안다는 가정하에 생기는 오류라고 볼 수 있다.

(혹은 그냥 알아듣지 못하게 만들기 위해서? 본인이 프로페셔널하게 보이려고?? 등 이유가 있을 수도 있다.)

필자는 개발일을 하고 있기에 개발직군에 대한 이야기를 해보겠다.

다른직군도 그렇겠지만 개발용어 역시 타 팀에게는 전혀 맥락 파악이 안되는 용어들이 많다.

또한 그 개발용어를 남발하며 소통을 하는 개발자들이 정말 많다.

~~(왜 개발자하면 떠오르는 이미지가.. 말 안통하는 너드스러운 체크남방을 떠올리는지를 잘 생각해보자!)~~

일전에 이러한 이야기를 들어본적이 있다.

개발자에게 "해당 기능을 업데이트할 수 있느냐?" 라고 물어봤을때

"어쩌구 저쩌구(개발용어) 때문에 어쩌구저쩌구(개발용어)현상이 일어날겁니다."

"흠... 된다는거죠?"

이런식으로 대화가 되서 그냥 "이건 되는거에요 안 되는거에요?" 라고 물어보게 된다고..

그래서 그들은 점점 멀어지며, 서로 대화를 꺼리는 순간이 온다.

(무언가 떠오르는 비슷한 맥락의 밈이 있지 않나?? ~~"그게 뭔데 ㅆㄷ아.."~~)

필자는 주니어 개발자가 입사를 하게 되면 언젠가 꼭 하는말이 있다.

개발용어는 우리직군끼리만 쓰고 최대한 타팀에게는 풀어서 말을 해라.

해당 용어를 풀어서 말을 할 수 없다면 그 용어의 뜻을 당신은 모르고 있는것이다.

그러니 해당 용어를 다시 공부하도록 해라.

전문용어라는 것이 사실 조금 더 빠른 표현을 위해서 생긴 용어들이 많지만

오히려 그로 인해 서로 소통이 안되거나 느려지는 상황이 생기는 아이러니함이 있다.

해당 용어가 앞으로 자주 사용 할 용어라면 먼저 해당 용어를 설명해주고 대화를 시작을 하거나

최대한 서로가 이해할 수 있도록 풀어서 소통을 하는 것도 그 사람의 능력이라고 생각한다.

간혹 이런 생각을 가진 개발자들을 많이 만나봤다.

개발자는 개발만 잘하면 되잖아! 의사소통이 무슨 문제야!

이러한 마인드를 가지고 있다면...

개발을 진짜 엄~~~~~~~~청 잘하면 된다.

하지만 아마 의사소통이 수월하지 않다면 개발요구를 다르게 구현하는 경우도 생길 것 이고,

그냥 개발만하는 기계가 될 가능성도 크다.

물론 모두가 전문용어를 알고있다면 오히려 더 빠른 소통이 가능하다!!

하지만 모두가 전문용어를 아는 대화가 얼마나 있을까??

(당장 친구들끼리의 회사얘기만 해도 무슨말인지 모르겠는데..)

(당장 같은 개발자인 백엔드개발자 프론트개발자가 대화하는 대도 서로 모르는 말을 하는데....)

상대는 내가 아니다.

내 머리속 내용을 상대도 알고 있지 않다.

반대로 상대의 머리속도 나는 모른다.

최대한 서로에게 이해할 수 있는 용어로 풀어서 소통을 하게 된다면!

말이 잘통하고 일 잘 하는 사람으로 보일 것 이다.

왜 많은 회사들이 필수조건, 우대조건으로 원할한 커뮤니케이션 능력을 꼭 적어두는지 기억하자.

ps1. 그렇다고 모든 대화를 전부 풀어서 대화하라는 것은 아니다.. (꼭 다르게 이해하시는 분들이.. ㅠㅠ)

ps2. 조금 강요하듯이 글을 썼는데, 그냥 이런생각이 있구나 정도로 봐주시면 감사하겠습니다.

[회고] 어느 덧 시간이 지나버린 개발자의 2021년 회고 (하반기)

Twowix — Thu, 13 Jan 2022 16:39:24 +0900

이전글 : https://twowix.tistory.com/86

바로 전글 회고를 작성하다보니 수명이 계속 줄었던 21년 상반기 였는데..

수명과 동시에 머리카락이 엄청 빠진 하반기 회고를 시작한다.

2021년 3분기

리뉴얼 배포 / 이직준비로 수명이 2년정도는 줄었던 분기였다..

동료들과 합이 워낙 잘 맞게 프로젝트를 진행한 결과

예상했던 프로젝트 기간보다 상당히 빠르게 프로젝트가 완성되었다.

하지만 프로젝트 완성과 프로젝트 배포는 또 다른일이다.

리뉴얼 배포의 시나리오를 전부 정리하느라 머리카락이 이만 삼천가닥정도 빠진것 같다.

아무래도 신규 서비스라면 고려할 사항이 그렇게 많지가 않아서 편하게 배포를 하겠지만

이미 서비스가 되고있는 상황에서의 배포는 상황이 다르다.

배포 시나리오를 생각할때는 3가지의 단계를 꼭 결정하고 시나리오를 구성하는편인데,

첫번째! 먼저 이슈가 될만한 상황을 정리한다.

1. 사용자가 항시 접속되어 있으며, 강의를 보고있을 확률이 크기 때문에 무중단으로 변경되어야 한다.

2. 각종 마케팅, 광고로 인한 url이 신규 서비스의 url로 redirect가 되어야한다.

3. 다행히 데이터베이스 마이그레이션은 다음단계로 미루어졌기에 데이터베이스에 관한 이슈는 크지않다.

4. 기존 서버에서 신규 서버로 옮겨지기 때문에, DNS의 변경이 일어난다.

5. 서버가 옮겨지면 세션정보가 변경되어서 유저들이 로그아웃이 될것이다. 하지만 로그인은 유지가 되어야한다.

작성 상황 말고도 몇 십가지는 더 많은 상황이 있었지만

다 작성하기에는 내부상황들이 많기에 여기까지만..

두번째! 이슈상황이 배포와 동시에 수행되는지 배포전/후에 수행이 되는지에 따라 앞선 이슈상황들을 정리한다.

1. 무중단으로 변경
(배포와 동시 수행)

2. 기존 url 신규 url로 매핑&리다이렉트
(배포전 프로젝트 내에서 수행)

3. 데이터베이스 마이그레이션
(휴…제일 억압인 아이지만 패스! 아싸구리)

4. DNS 변경
(배포 후 수행)

5. 배포 후 로그인유지
(배포전 프로젝트 내에서 쿠키와 세션을 적절히 이용해서 로그인유지 구성)

이렇게 정리를 해보면 최종 시나리오 정리에 대해 조금은 더욱 더 명확해진다.

마지막으로는 정리한 이슈상황을 토대로 시간순서대로 시나리오를 작성하고,

해당 시나리오에 관한 각종 커맨드나 확인해야할 부분등을 모두 테스트를 해본다.

또한 최대한 자동화를 할 수 있는 부분은 자동화를 만들어 둔다. (배포하는 자신을 믿지말자..)

그리고 개발 서버에 해당 시나리오를 토대로 만족할때까지 테스트 배포를 진행한다.

항상 큰 기능이 배포될때 상당히 신경이 날카로워 지는데,

그러다보니 이상하게 배포하는 날은 아침부터 저녁까지 무엇을 했는지

(저녁에 술과 안주는 무엇을 먹었고, 대화는 어떤대화를 하였고.. 등등)

전부 기억이 난다.

이번에 리뉴얼 배포하는날도 기억이 생생하다.

배포하는날 항상하는 루틴이 하나가 있는데,

배포자동화 스크립트의 실행하는 엔터를 다른 동료직원에게 맡기는거다.

(당연히 테스트를 여러번 수행해보고 문제없는 스크립트라고 판단이 되었을때!!)

이 루틴은 햇병아리 시절의 내가 서버배포에 대한 걱정과 불안을 장난 삼아 시작되었다.

하지만 이런 루틴이 지속되니 해당동료가 엔터를 칠때 어떻게 반응을 하는지가 상당히 오묘하고 재미가 있었다.

이번에도 시나리오를 최대한 완벽히 구성하고

대망의 배포 날짜에 배포 자동화 스크립트를 실행을 새로 입사한 동료에게 장난식으로 이거 엔터 쳐볼래요? 해서 배포를 했었다.

아무런 걱정과 망설임 없이 엔터를 치는 모습을 보니 그런 모습이 상당히 부러웠다.

아직은 배포에 대한 부담/걱정을 모를 수 있기에 충분히 그럴 수 있다.

한번의 엔터에 얼마나 많은 사람들의 노력이 녹아 들어있는지..

혹여나 잘못될 상황이 어떻게 일어날지에 대한 걱정 등등..

처음 개발일을 할때는 나중에 경력이 쌓이면 아무걱정 없이 퇗퇗퇗 치고 딱딱딱 배포하고 할 줄 알았건만

큰 기능의 배포는 항상 부담되고 걱정이 된다.

하여튼 배포는 성공적으로 마무리가 되었고, 현재까지 수월하게 서비스가 돌아가고 있다.

이런식의 배포라면 숨막힐듯.. AWS 짱짱..

동시에 갑작스런...은 아니고 이직제안이 가장 많이 왔던 시기였다.

사실 이직 생각이 아에없진 않았는데, 때마침 좋은 기회가 생겨서 이직을 하게 되었다.

이직을 할때마다 느끼지만 새로운 회사로 가는 설레임과 그동안 정들었던 동료들과의 이별의 슬픔 같은..

아주 여러가지 복잡 미묘한 감정이 피어오르곤 한다.

그래서 또 머리카락이 오만 팔천가닥정도 빠진것 같다.

2021년 4분기

이만큼 퇴사를 잘 표현한 짤이 있을까 싶다.

다니던 회사에서의 퇴사 그리고 새로운 회사로의 생활로 수명이 1년정도는 늘었던 분기였다.

이직하게된 회사는 개발팀이 이번에 셋팅이 되려는 곳으로 개발프로세스가 전혀 없던 곳이다.

개발 프로세스를 구축해가며 새로운 동료와의 코딩컨벤션, 업무분담 등 하나하나 만들어가는 재미가 있다.

지금까지 항상 이직을 해오면서 비슷한 일들을 해왔기에 점차점차 개발팀의 프로세스가 잡혀가는 것에 대한 기대가 크다.

사실 아직 개발자가 나포함 3명밖에 없기에 그렇다 할 문화를 만들기에는 합을 맞추는게 우선이다.

여기까지가 현재 진행형으로

글을 작성하며 다시 돌아보니 21년은 뭔가 엄청 바쁘게 산거 같지만 글로만 뭔가 주절주절해서 그렇지 뭐 엄청 바쁘진 않았다.

22년은 조금 더 재미있는 해가 될 예정이라고 믿어 의심치 않는다.

이글을 보는 모든분들도 올 한해는 원하는바가 꼭 이루어지기를 바랍니다.

화이팅!!

[회고] 어느 덧 시간이 지나버린 개발자의 2021년 회고 (상반기)

Twowix — Mon, 10 Jan 2022 23:11:51 +0900

이런 글은 살면서 처음 써보는것 같다.

하지만 점점 나이가 들수록.. 경력이 쌓일수록..

개발에 대한 기술과는 별개로 해당 연도에 있었던 일련의 사건들이 점점 흐릿해져감을 느껴져서 이렇게 글을 작성한다.

아마도 이쯤 지나오는 직장인들은 다들 공감할 것이다.

크게 다르지 않은 하루(일-집-일-집-주말잠-일-집…)가 많아질 수록 기억은 섞이기 마련이니까..

다행히 일을 할때 메모장에 그날의 키워드들을 적는 버릇이 있어서 하나씩 되짚어가며 기억을 가져가보겠다.

안지키면 감옥가는 코딩컨벤션 정립...

2021년 1분기

20년부터 이어진 기업 R&D 연구과제로 인해 수명이 3년정도는 줄었던 분기였다.

연구과제에 대한 자세한 내용은 적을 순 없지만 간략하게 '유저에 대한 개인화 값을 수집하여 분석 후 서비스내에서 사용하는..’ 하는 그런 주제였다.

다행히 연구심사과정은 문제없이 통과하였고, 한 시름 놓을 수 있었던 것 같다.

(번외로 연구심사를 하기위해 TTA 소프트웨어시험인증연구소에서 서버용 데스크탑 직접 가지고 다녔었는데, 알고보니 AWS에 그냥 올려서 시험을 봐도 문제가 없었다고 한다…)

그와 동시에 신규 프로젝트였던 애디를 오픈하였다. (https://addy.addcampus.com)

사내 개발자 모두 처음 접해보는 리액트였지만 나름 퀄리티있게 진행이 되었다.

2021년 2분기

베어유서비스 리뉴얼 / 웹개발(django) 강의로 인해 수명이 4년정도는 줄었던 분기였다.

먼저 베어유 서비스 리뉴얼에 대해 이야기 하자면 회사의 강의플랫폼 서비스인 베어유의 기술스택을 전부 변경하였다.

기존 레거시 php 에서 Django(drf) 백엔드를 구성하고 React로 프론트엔드(웹, CMS) 이렇게 3가지로 구성하게 되었다.

바로 직전 프로젝트 애디라는 서비스에서 React 기반으로 프로덕션 레벨을 어떻게 잡느냐가 많이 학습이 되었기에 그에 따라 조금 더 구성진 프로젝트로 진행되었다.

그리고 회고스러운 회고를 하자면,

아무래도 프로젝트를 리드함으로써 여러가지 느껴짐이 있는데 작년에 느꼈던 감정과 또 다른 새로운 감정을 느끼게 되었다.

나 자신을 바라보면 개발을 할때 어느정도 완벽주의자 성향이 있어서 동료들의 커밋을 전부 내손으로 어느정도 리팩토링을 해야 서비스에 올리는 버릇 아닌 버릇이 있었다.

(누군가에게는 코드리뷰가 될것이고, ~~누군가에게는 대충 작업해도 바꿔주는 호구처럼 될것이고,~~ 누군가에게는 너무 관여하는 사람이 될것이다.)

하지만 꽤 긴기간 합을 맞춘 동료들과 함께 하다보니 어느 순간 그들의 코드가 내코드가 되고 내 코드가 그들의 코드가 되어있는 기분좋은 감정을 느끼게 되었다.

마치 신성한 칼라로 연결되어있는 기분?

그래서 조금은 느슨하게 코드를 보고 진행을 하게 되었는데, 3분기쪽에서 나오겠지만 아주 성공적으로 서비스가 리뉴얼 되었다.

또한 내가 믿고 맡길수 있는 동료개발자가 더 많이 추가된다는 것은 그 무엇과도 바꿀 수 없는 기쁨이 아닐수가 없다.

신성한 칼라로 연결된 동료들

다음으로 강의에 대해 회고를 해보겠다.

온라인강의는 유튜브나 트위치로 실시간으로 진행한적이 몇번 있었는데,

상품으로써의 온라인강의는 처음해봐서 이슈가 몇가지 있었다.

첫번째로

강의를 듣는 타겟설정이 너무 어려웠다.

일단 중/상급자는 가르칠 깜냥도 안될뿐더러 그분들은 굳이 강의를 보지않고 직접 찾아서 만들면 그만이기 때문에 패스

그럼 초보자로 가야 할텐데...

초보자면 얼마나 초보자여야하지? 아에 사칙연산부터 알려줘야하나?..

웹 풀스택 개발을 주제로 강의를 하는데.. 프로그래밍기초에다가 언어별로 python, js, html, css 를 하나하나 다 설명해줘야할까? (물론 강의가 100강이넘어가면 가능하겠지만.. 아쉽게도 30강구성 맞춰야 해서..)

개발자를 목표로 하는사람일까? 그냥 취미로 개발을 하고 싶은사람일까?? 등등 타겟설정에 따라 강의 내용이 달라지기에 너무나도 힘들었다.

강의자료를 몇번을 바꿨는지 모른다..

과외나 실시간 온라인강의는 실시간 질문 등을 토대로 학습자의 수준에 맞추기가 가능하다.

하지만 실시간이 아닌 강의는 그것이 불가능하다는거...

두번째로

강의를 만들다보니 욕심이 생겨서 자꾸 1강에 10분강의라는 서비스의 컨셉에 자꾸 벗어나게 강의를 구성해버리게 되었다.

설명충으로써 최대한 많은 정보를 담고싶은 마음에 강의를 구성했었는데, 아쉽게도 몇몇개의 가벼운 내용은 조금 자르기도 했다..

(개발자로써의 마음가짐같은 꼰대스러운 멋진 말들을 많이 했건만…)

어찌저찌 몇가지의 이슈를 겨우겨우 넘겨 최대한 쉽게 웹개발에 발을 들일수 있게 구성을 하였다.

(Django 뿐만 아니라 프로그래밍 기초, Python 기초, JS 기초, 간단한 AWS 배포 기초 등 설명해주고 싶은건 다 넣었다.)

(강의 아무나 하는게 아니었다.. 역시 사람은 직접 겪기 전까진 다 쉬워보인다.)

(항상 겸손하자)

그렇게 강의준비와 촬영 등 여러 일을 다 하다 보니 어느새 여름이 되어버렸다.

(강의가 궁금하다면 강의 주소는 하단에 남겨놓겠습니다.)

ps1. 한방에 일년치를 다 적으려고 했는데 쓰다보니 글이 길어져서 상반기/하반기로 나눌께요 ㅠㅠ

ps2. 심심하면 한번 보러 와주세요~! 수명을 깎아 만든 강의입니다. https://bear-u.com/course/98

[Django] 개발 왕초보를 위한 웹서비스 풀스택 입문기

장고를 배워, 익명게시판 서비스까지 만들자!

bear-u.com

하반기 예고편

2021년 3분기

리뉴얼 배포 / 이직 준비로 수명이 2년정도는 줄었던 분기였다..

[Django] runserver 로 실제 서버를 돌리면 안되는 이유 (런서버는 어떻게 동작하나??)

Twowix — Sat, 21 Mar 2020 15:00:22 +0900

django를 개발하다보면, 혹은 다른 프레임워크로 웹백엔드를 개발하다 보면 앵간하면 개발 서버를 켜는 명령어가 있다.
django에서는 python manage.py runserver 라는 명령어를 치면 아주쉽게 간편하게 로컬에 서버가 켜진다.
아쉽게도 개발하다가 많은 사람들을 만나다보면 그냥 되는게 되는거고 말면 마는 분들이 꽤나 있는것같다.

'메인 서버에 올릴때 runserver로 그냥 켜놔도 되는거아니에요?'
'그냥 runserver nohup으로 백그라운드로 돌게하면 되는거아니에요?'
'그냥 검색해보니까 nginx+uwsgi 이렇게 메인에 배포하라는데 이유는 잘모르겠네요 ㅎㅎ'
라는 질문을 하는 분들이 꽤나 많다.

잘은 모르지만 was + wsgi 로 다들 조합해서 하는거 같으니까..
단지 검색하다보니까 어떤 조합으로 해서하면 좋다더라 하는 이런 글을 보고 그냥 쓰시는 분들도 많은것 같다.
(물론 잘 알고 쓰시는분들도 정말 많다 - 세상은 넓고 고수는 많다.)

해당 포스트는 이제 개발을 시작하시는 분들 초보자 or 신입분들을 위한 글이니
그 분들의 초점으로 글을 쓰겠다.
(그말인 즉슨 고수님들은 굳이 안보셔도 된다는 소리..)

일단 runserver 라는 명령어가 어떻게 켜지는지 부터 볼 필요가 있다.
[프로젝트를 아에 켜셔서 따라 가시는걸 추천합니다. 코드가 길어서 보기 힘들 수 도 있습니다.]

django 프로젝트를 생성하면 manage.py 라는 파일이 가장 바깥쪽 경로에 생성이 된다.
이 해당 manage.py 는 django 명령어를 인식하게 하기위한 중간역할 즉, django의 명령어 인터페이스라고 보면 된다.

#!/usr/bin/env python
"""Django's command-line utility for administrative tasks."""
import os
import sys


def main():
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'ProjectName.settings')
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == '__main__':
    main()

manage.py을 열어보면 위의 코드가 기본적으로 작성되어있다.

1. 프로젝트의 세팅을 뭘로 볼껀지 환경변수에 등록을 한다.
2. django가 안깔려있면 예외처리
3. excute_from_command_line 이라는 함수가 받아온 sys.args로 실행된다.
[오호~ 이곳이 뭔가 처리하는 곳이다.]

def execute_from_command_line(argv=None):
    """Run a ManagementUtility."""
    utility = ManagementUtility(argv)
    utility.execute()

해당 함수를 따라가면 ManagementUtility라는 클래스를 args로 가져오고
그것을 excute라는 클래스내 함수를 실행시킨다는 것을 알 수 있다.
계속 들어가보자!!

우리는 ManagementUtiliuty라는 아이를 볼필요가 있다.
(클래스가 꽤 길기 때문에 특징적인것만 넣겠다. 그외 안쪽 함수들은 직접 보시길...)

class ManagementUtility:
    """
    Encapsulate the logic of the django-admin and manage.py utilities.
    """
    def __init__(self, argv=None):
        self.argv = argv or sys.argv[:]
        self.prog_name = os.path.basename(self.argv[0])
        if self.prog_name == '__main__.py':
            self.prog_name = 'python -m django'
        self.settings_exception = None
        
        
    def execute(self):
        """
        Given the command-line arguments, figure out which subcommand is being
        run, create a parser appropriate to that command, and run it.
        """
        try:
            subcommand = self.argv[1]
        except IndexError:
            subcommand = 'help'  # Display help if no arguments were given.

        # Preprocess options to extract --settings and --pythonpath.
        # These options could affect the commands that are available, so they
        # must be processed early.
        parser = CommandParser(
        	usage='%(prog)s subcommand [options] [args]', 
        	add_help=False, 
        	allow_abbrev=False
        )
        parser.add_argument('--settings')
        parser.add_argument('--pythonpath')
        parser.add_argument('args', nargs='*')  # catch-all
        try:
            options, args = parser.parse_known_args(self.argv[2:])
            handle_default_options(options)
        except CommandError:
            pass  # Ignore any option errors at this point.

        try:
            settings.INSTALLED_APPS
        except ImproperlyConfigured as exc:
            self.settings_exception = exc
        except ImportError as exc:
            self.settings_exception = exc

        if settings.configured:
            # Start the auto-reloading dev server even if the code is broken.
            # The hardcoded condition is a code smell but we can't rely on a
            # flag on the command class because we haven't located it yet.
            if subcommand == 'runserver' and '--noreload' not in self.argv:
                try:
                    autoreload.check_errors(django.setup)()
                except Exception:
                    # The exception will be raised later in the child process
                    # started by the autoreloader. Pretend it didn't happen by
                    # loading an empty list of applications.
                    apps.all_models = defaultdict(dict)
                    apps.app_configs = {}
                    apps.apps_ready = apps.models_ready = apps.ready = True

                    # Remove options not compatible with the built-in runserver
                    # (e.g. options for the contrib.staticfiles' runserver).
                    # Changes here require manually testing as described in
                    # #27522.
                    _parser = self.fetch_command('runserver').create_parser('django', 'runserver')
                    _options, _args = _parser.parse_known_args(self.argv[2:])
                    for _arg in _args:
                        self.argv.remove(_arg)

            # In all other cases, django.setup() is required to succeed.
            else:
                django.setup()

        self.autocomplete()

        if subcommand == 'help':
            if '--commands' in args:
                sys.stdout.write(self.main_help_text(commands_only=True) + '\n')
            elif not options.args:
                sys.stdout.write(self.main_help_text() + '\n')
            else:
                self.fetch_command(options.args[0]).print_help(self.prog_name, options.args[0])
        # Special-cases: We want 'django-admin --version' and
        # 'django-admin --help' to work, for backwards compatibility.
        elif subcommand == 'version' or self.argv[1:] == ['--version']:
            sys.stdout.write(django.get_version() + '\n')
        elif self.argv[1:] in (['--help'], ['-h']):
            sys.stdout.write(self.main_help_text() + '\n')
        else:
            self.fetch_command(subcommand).run_from_argv(self.argv)

클래스의 생성자는 해당 args를 세팅하는 모양이다.
그리고나서 excute를 실행했으니 excute 함수를 보자!

1. 가져온 args를 subcommand라는 변수에 넣는다. (없을 시 help를 넣는다.)
2. 그리고 CommandParser라는 클래스를 세팅하면서 두번째 인자값을 찾아본다.
python manage.py runserver --settings=settings.product 같은 옵션을 넣을때 사용하는 친구로 보인다.
(해당 포스팅과는 관련이 적으니 넘어가겠다.)
3. 그리고나서 세팅에 설정한 앱들을 체크한다.
4. 이제서야 커맨드의 값이 runserver 일때 무엇을 할 것인지 나온다.

간단하게 살펴보면 에러를 체크해서 예외처리를 한 이 후에 가장 마지막으로 해당 커맨드가 help나 version, --help, -h 가 아니면 fetch_command라는 함수를 실행시킨 값을 토대로 run_from_args라는 아이를 실행시킨다.
이런식으로 쭈욱 따라가다 보면 정적파일들을 체크하고 경로를 설정하고, 각 종 django에 관련있는 아이들을 체크하고, DB도 체크하고 커낵션도 맺고, 로그를 어떻게보여줄지 설정하고, 경로를 설정하고 온갖 난리를 치다가 마지막에 결국 runserver에 맞는 모듈을 찾아서 해당 모듈을 실행시킨다.

class Command(BaseCommand):
    help = "Starts a lightweight Web server for development."

    # Validation is called explicitly each time the server is reloaded.
    requires_system_checks = False
    stealth_options = ('shutdown_message',)

    default_addr = '127.0.0.1'
    default_addr_ipv6 = '::1'
    default_port = '8000'
    protocol = 'http'
    server_cls = WSGIServer

    def inner_run(self, *args, **options):
        # If an exception was silenced in ManagementUtility.execute in order
        # to be raised in the child process, raise it now.
        autoreload.raise_last_exception()

        threading = options['use_threading']
        # 'shutdown_message' is a stealth option.
        shutdown_message = options.get('shutdown_message', '')
        quit_command = 'CTRL-BREAK' if sys.platform == 'win32' else 'CONTROL-C'

        self.stdout.write("Performing system checks...\n\n")
        self.check(display_num_errors=True)
        # Need to check migrations here, so can't use the
        # requires_migrations_check attribute.
        self.check_migrations()
        now = datetime.now().strftime('%B %d, %Y - %X')
        self.stdout.write(now)
        self.stdout.write((
            "Django version %(version)s, using settings %(settings)r\n"
            "Starting development server at %(protocol)s://%(addr)s:%(port)s/\n"
            "Quit the server with %(quit_command)s.\n"
        ) % {
            "version": self.get_version(),
            "settings": settings.SETTINGS_MODULE,
            "protocol": self.protocol,
            "addr": '[%s]' % self.addr if self._raw_ipv6 else self.addr,
            "port": self.port,
            "quit_command": quit_command,
        })

        try:
            handler = self.get_handler(*args, **options)
            run(self.addr, int(self.port), handler,
                ipv6=self.use_ipv6, threading=threading, server_cls=self.server_cls)
        except OSError as e:
            # Use helpful error messages instead of ugly tracebacks.
            ERRORS = {
                errno.EACCES: "You don't have permission to access that port.",
                errno.EADDRINUSE: "That port is already in use.",
                errno.EADDRNOTAVAIL: "That IP address can't be assigned to.",
            }
            try:
                error_text = ERRORS[e.errno]
            except KeyError:
                error_text = e
            self.stderr.write("Error: %s" % error_text)
            # Need to use an OS exit because sys.exit doesn't work in a thread
            os._exit(1)
        except KeyboardInterrupt:
            if shutdown_message:
                self.stdout.write(shutdown_message)
            sys.exit(0)

그래서 결국 열리는 파일은 django/core/management/commands/runserver.py 라는 아이다.
물론 해당 클래스도 꽤나 길기 때문에 사용되는 주요함수를 보겠다.
일단 클래스 자체가 기본으로 로컬아이피와 8000포트를 잡고 있다. 따라서 우리는 python manage.py runserver 라고만 쳤을때
127.0.0.1:8000 이 열린다는 것을 알 수 있다. 그 이후 실행되는 inner_run이라는 함수가 초반에 무언가 쫘악 셋팅을 한다.

1. 서버를 끄는 커맨드셋팅
2. 마이그레이션 체크
3. 현재시간을 가져와서 결국 로그창에 지금까지 했던 셋팅들을 띄운다. (↓ 바로 우리가 매일 보는 이것)

Performing system checks...

System check identified no issues (0 silenced).

You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
March 21, 2020 - 14:26:31
Django version 3.0.3, using settings 'ProjectName.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.

4. 그리고나서 run이라는 함수를 실행시킨다.

이 run이라는 함수는 django.core.servers.basehttp 에 있는 말그대로 python이 제공하는 http server를 여는것이다.
(해당 코드는 직접 살펴 보시길 - 간략하게 프로토콜은 HTTP/1.1, 요청수의 최대값, 각종 예외처리 등을 하고 서버를 연다.)
잘 살펴보면 https를 사용하면 예외처리를 한다는것을 알 수 있다.
이거 하나만으로도 보안처리를 최대한 생략한다는것을 알 수 있다.

생략한 과정이 꽤나 있었지만 그럼에도 불구하고 이 많은 함수를 거쳐서 우리가 간단하게 쳤던 그 명령어 runserver 하나로 드디어 서버가 열린것이다.

django.core.servers.basehttp의 가장 위 주석을 보면

"""
HTTP server that implements the Python WSGI protocol (PEP 333, rev 1.21).

Based on wsgiref.simple_server which is part of the standard library since 2.5.

This is a simple server for use in testing or debugging Django apps. It hasn't
been reviewed for security issues. DON'T USE IT FOR PRODUCTION USE!
"""

요런식으로 써있다.
이 주석의 3번째문단이 해당 포스팅의 내용을 다 담고있다고 볼수 있다.
다들 영어 잘하시겠지만 간단하게 해당 심플서버는 테스팅이나 디버깅할때 사용한다. 보안적으로 안좋으니, 메인서버에는 사용하지 마라!!! 이말이다.

어쩌다보니 runserver가 켜지는 과정을 포스팅해버리고 말았는데, 포스팅이 길어져서 다음 포스팅에 연결해서 써야겠다.
우리는 마지막 문장을 꼭 기억하자 DON'T USE IT FOR PRODUCTION USE!

ps.1. 내가 개발을 하는 초보분들에게 항상 추천하는 방법은 해당 라이브러리를 까보라는 것이다.
ps.2. 왜냐면 아무리 본인 잘짜도 검증된 라이브러리의 코드만큼 공부가 많이 되는것이 없기때문이다.
ps.3. 그러다가 나중엔 맘에안드는 코드부분의 컨트리뷰터 까지 된다면 금상첨화
ps.4. 이렇게 공부를 하면 의미없는 1일1커밋보다 훨씬 공부가 될 것이다.
( 1일 1커밋을 할 바에 잠을 자는게 더 낫다. - https://twowix.me/84 )
ps.5. django는 각 파일마다 주석만 봐도 이파일이 뭐하는앤지 아주 잘 설명해뒀다... 미친 프레임워크다...

1일 1커밋을 할 바에 잠을 자는게 더 낫다.

Twowix — Tue, 17 Mar 2020 23:00:36 +0900

개발을 하는 사람들의 문화중에 하나인 1일 1커밋

나는 1일 1커밋에 대해 아주아주아주 회의적이다.

1일 1커밋이라는것 자체의 의도는 참 좋다.

일기 쓰듯이 하루에 한번 개발을 하여 습관화를 하자라는 취지다.

하지만 일기 쓰듯이라는 것에 우리는 주목할 필요가 있다.

모두가 그렇진 않겠지만 일기라는 것은 미뤄야 제맛이다.

나는 초등학교 시절 일기를 몰아쓰곤 했다.

그리고 당연하게도 선생님께 혼쭐이 나기도 했다.

그런 아이가 커서 개발을 하는 사람이 되었고,

1일 1커밋을 하고 있는 개발을 하는 사람들, 동료들이 많다는 것을 알게되었다.

사실 처음에는 별 생각이 없었다.

그러다 문득 초등학교 시절과 똑같은 행동을 하고 있는 사람들을 보니 갑자기 너무 이상해보였다.

1일 1커밋의 목적은 개발을 매일매일 하자!! 개발을 습관화 시키자!! 등등 결국 '개발을 하자'가 목표다.

1일 1커밋이 목표가 아니고, 개발을 하는것이 목표다.

더욱 정확히는 개발을 습관화해서 실력을 키우자가 목표다.

그러나 사람들은 항상 1일 1커밋 그 자체가 목표가 되어있다.

결국 1일 1커밋자체를 억지로 하는 상황이 생기고, 이도 저도 아닌 상황이 온다.

주객전도의 예를 들어보겠다.

밤 11시 40분쯤에 '오늘의 1일 1커밋을 해야지~' 하고 개발을 시작했다.

코딩에 열중하다보니 11시 59분이 되었다.

'그치만 나는 깃허브에 잔디밭이 비는건 참을수없어!!'

집중을 깨고 11시 59분에 뜬금없이 아무 의미 없는 커밋을 한다.

그리고나서 새벽 12시 5분쯤 커밋을 한번 더하고 '아 오늘은 좀 쉴수있겠다~'

뭔가 이상하지 않나?

굳이 중간에 커밋을 하지 않더라도 개발이라는 행위를 분명히 했는데, 중간에 집중을 깰 필요가 있나??

잔디밭이 비면 안되는것인가?...

너무 보여주기식 습관이 되고있는게 아닐까?

그리고 개발자병에 걸린사람들이 대부분 의미없는 1일1커밋을 행하고 있다.

다시 한번 말하지만 1일 1커밋의 취지는 참 좋고, 성실히 잘 하고 있는 사람을 욕하는것이 절대 아니다.

내가 생각하는 1일 1커밋은 1일 1커밋이란 단어도 몰랐는데, 잔디밭이 쫘악 깔려있는것

그 자체 라고 본다.

A: "1일 1커밋한지 오래되셨나봐요? 깃헙에 잔디밭이 쫘악 깔렸네요~"

B: "1일 1커밋?? 그게 뭔데요?? 그냥 하다보니 이렇게 됬네요.. 허허"

이런 상황이 훨씬 멋있다고 본다.

사실 개발이 재밌고, 본인이 하고 싶다면 누가 시키지지 않아도 알아서 1일 1커밋이 되어있을것이다.

ps1. 글을 쓰고 다시보니 제목이 좀 자극적인것 같다...

ps2. 다시 한번 말하지만 1일 1커밋의 취지와 목적에 맞게 잘 이행하고 계신분들을 욕하는 것이 절대 아닙니다.

ps3. 갑자기 너무 배고프다.