[ Essay - Technology, Essay - Intuition ] Chat GTP시대의 도래와 생각하는 방식에 대해 : 개발자의 미래에 대해

이미지
벌써 올해도 반쯤 지나 뜨거운 여름이 다가왔다. 굉장히 빠르게 지나간듯한 느낌이 드는데  아마 의미있는 시간을 보냈다는 이야기이기 때문에  그렇게 나쁜 신호는 아닐 것 이다. 괴로운 시간이였다면, 1초가 1년 같이 느껴졌을테니 말이다. 더위에 매우 약한 나에게 있어서는 지옥과 같은 시기이기도 하지만 늘 그렇던 것 처럼 에어컨 덕분에 어찌저찌 버틸 수 있을 것 같다. 어쨋든, 이번에는 저번의 에세이 주제, Chat GTP시대의 도래와 생각하는 방식에 대한 이야기에 이어서  과연 개발자의 미래는 어떻게 될 것인가에 대해 이야기를 나누어보려고 한다. 어쩌면 모두가 인식하고 있듯이 지금 2025년 현재,  꽤나 중요한 시기에 직면하고 있는지도 모른다. 왜냐하면, 생성AI의 발전 속도가 생각보다 빠르게 발전하고 있고,  그에 따라 실제 업무에서도 빠르게 사용되어지고 있기 때문이다. 이러한 상황에서 개발자에게 있어서 가장 두려운 점은  당연히 생성AI에 의해 개발자가 대체될 것 이라는 두려움일 것 이다. 이는 개발자에게만 한정된 이야기는 아니지만 말이다. 아마 필드에서 나와 같이 일하고 있거나  개발자로서 직업을 가지려는 생각이 있는 사람이라면  한번쯤은 생각해볼법한 주제라 생각 한다. 물론 미래가 정확히 어떻게 될 지는 알 수 없으나  이런 생각을 함으로써 몇 가지 힌트는 얻게 될지도 모르니  만약 얻게 된다면 미래에 대한 방향성을 조금이나마 올바른 쪽으로 돌릴 수 있을 것 이다. 이 글을 끝맽을 때는 조금이라도 힌트에 도달하기를 바란다. 과거의 역사 이러한 의문에 대한 해결책으로서 일반적으로 자주 사용하는 방법이 있다. 바로 역사를 보는 것 이다. 물론 이러한 역사를 해결책을 찾는거에 대한 전제조건은  우리가 '구 인류'라는 전제조건이 있었을 때 의미가 있다. 그러니깐 현대인도 기원전 8세기의 고대 로마인도  본질적으로 다르지 않다는 것을 인정해야만 한다. 예컨데...

[ Django, Python ] 튜토리얼 예제로 살펴보는 Django 분석 ③ : http404 에러 처리, 템플릿 시스템, 네임 스페이스 설정

에러 처리 : 404 에러 일으키기

이제 에러를 일으켜 보려한다.

detail() view는 지정된 설문조사의 질문 내용을 보여준다.

코드는 아래의 사진과 같다.


위의 코드를 추가해
만약 요청된 view가 존재하지 않을 경우 Http404예외를 발생시키게 된다.

일단 잘 작동하는지 확인하기 위해 아래의 사진과 같이

polls/detail.html을 만들어 간단한 태그를 넣어보자.


정상적으로 프로그래밍이 되어졌다면 아래와 같이 브라우저에 표시된다.


위의 사진에서 볼수 있듯이, HTML태그를 작성한 대로


Question does not exist라는 문자열이 나타날 것 이다.

404 에러 일으키기 : ShotCuts - get_object_or_404()

만약 객체가 존재하지 않을 때
get()을 사용하여 Http404 예외 처리를 발생시키는 것은 자주 사용하는 용법이다.

Django에서는 이 기능에 대한 단축 기능(Shot Cuts)을 제공한다.


detail() View Shot Cuts으로 프로그래밍 하면 아래와 같다.


get_object_or_404 함수는 Django의 모델(model)을 첫번째 매개변수로 받고,


몇 개의 키워드 매개변수를 모델 관리자의 get() 함수에 넘긴다.

만약 객체가 존재하지 않을 경우 , Http404 예외가 발생한다.

정상적으로 프로그래밍 되어졌다면 아래와 같은 페이지가 브라우저에 출력된다.


숏컷을 사용하기 전과 다르게 다른 텍스트가 보이는데,
이는 숏컷기능에서 제공해주는 로그 인듯 하다.

공식 도큐먼트에서 이 함수에 대해 Django에서의 추구하고자 하는
철학을 아래와 같이 말한다.


get_object_or_404 함수 이외에도 비슷한 get_list_or_404 함수가 존재하는데,

이는 get() 대신에 filter()를 사용해

리스트가 비어있을 경우 Http404 예외 처리를 발생시킨다.

템플릿 시스템 사용하기

투표 어플리케이션의 detail() View로 되돌아가 보자.

Context 변수 question이 주어졌을 때,
polls/detail.html이라는 템플릿이 어떻게 보이는지 확인해 보기위해

detail.html파일을 아래와 같이 수정해보자.


Django의 템플릿 시스템은 변수의 속성에 접근하기 위해 
-탐색(dot-lookup) 문법을 사용 한다.

예제의 {{question.question_text }} 코드로 예를 들어보자.

Django는 먼저 question객체에 대해 사전형으로, 실패한다면 속성값으로
그래도 실패한다면 리스트의 인덱스 탐색을 시도한다.

{% for %} 반복 구문에서도 메소드 호출이 일어난다.
Question.choice_set.allpython에서 question.choice_set.all() 코드로 해석되는데,
이때 반환된 Choice객체의 반복자는 {% for %}구문에서 사용하기 적절하다.

템플릿에 대한 자세한 사항은 아래의 링크인 템플릿 지침서를 참고하기 바란다.


템플릿에서 하드코딩된 URL 제거하기

polls/index.html 템플릿에 링크를 적으면

이 링크는 아래와 같이 프로그래밍 될 것 이다.


위와 같이 강력하게 결합된 하드코딩된 접근 방식의 문제는
수 많은 템플릿을 가진 프로젝트들의 URL을 바꾸는게 쉽지 않다는 점이다.

그러나 polls.urls 모듈path() 함수에서 인수의 이름을 정의 했기 때문에
{% url %} 이라는 template 태그를 사용하여

url 설정에 정의된 특정한 URL 경로들의 의존성을 제거 할 수 있다.


하드코딩된 코드와 {% url %} 이라는 template 태그를 사용한 코드를 비교해보자.

{% url %} 이라는 template 태그를 사용하게 되면 우리가 지난번에 설정한
경로(path)에 설정한 값에 맞게 URL이 설정될 것 이다.

따라서 해당 detail ViewURLpolls/specifics/12/ 로 바꾸고 싶다면,
템플릿(polls/index.html)이 아니라 polls/urls.py 파일에서 바꿔주어야 한다.


이 경우에는 위의 사진의 경로에


위와 같은 코드로 바꿔주면 된다.

URL의 이름(Name Space) 정하기

이번 튜토리얼의 프로젝트는 polls라는 단 하나의 앱을 가지고 진행했다.

하지만 실제 Django 프로젝트는 이러한 앱들이 몇 개라도 추가 될 수 있다.

실제로 Django는 이 앱들의 URL을 어떻게 구별할까?

예를 들어 polls detail 이라는 View를 가지고 있고,
동일한 프로젝트의 블로그를 위한 앱이 있을 수도 있다.

Django{% url %} 템플릿 태그를 사용할 때,
어떤 앱의 뷰에서 URL을 생성할지 알 수 있을까?

정답은 URLconf에 이름(Name Space)를 추가하는 것이다.

아래의 사진과 같이 polls/urls.py 파일app_name을 추가하여,
어플리케이션의 이름(Name Space)를 추가할 수 있다.




그리고 polls/index.html 템플릿의 기존 내용을 네임 스페이스에 맞게
아래와 같이 재 설정 해준다.



위에서 설정한 네임 스페이스의 이름polls가 들어간 것을 확인 할 수 있다.



참고

첫 번째 Django 애플리케이션 만들기, part3 :

이 블로그의 인기 게시물

[ Web ] 웹 애플리케이션 아키텍처 (Web Application Architecture)

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 1 [서론, 클라이언트 사이드(Client Side)]

[ Web ] 웹 애플리케이션 서버 아키텍처의 정의 및 유형 ( Define and Types of Web Application Server Architecture )