AUSG 아닌 사람이 AUSG Big Chat 가보기

 

AWS는 신이야.

 

백엔드 개발자로서 처음 AWS를 접하면, 마치 넓고 깊은 바다에 빠진 듯한 느낌이 든다.

'아 이거 왜 이렇게 어렵게 만들었어?'라는 답답함도 느끼곤 한다. 

그래서 나는 처음 백엔드 개발했을 때에는 AWS가 어렵게만 느껴졌지만,

학교에서 GPU 서버관리자로 일하게 되면서 AWS는 그저 신이라는 것을 느꼈다.

서버관리자를 하면서는 오류신고를 받고 해결하는 과정을 반복하는데,

AWS를 쓰면 그런 일이 거의 없다.

애초에 그런 오류가 나지도 않는다...

그래서 개발할 때 AWS를 사용하는 것이 즐거워졌고,

'이건 어떻게 만들었을까', '어떻게 이런 걸 딸깍 하나로 가능하게 했을까' 감탄하게 된다.

 

 

인간 존재의 의미부터 개발자 존재의 의미까지...

 

개발을 막 시작하면 누구나 설레고 신나는 순간이 있다.

내가 정말 대단하다고 생각했던 기술을 적용하고 됐을 때,

'어! 이거 된다!'하면서 들뜬 순간이.

 

내가 공부를 더 해야겠다고 생각한 이유 중 하나는 이것이다.

개발자라면 기술을 좋아할 수밖에 없고, 그렇기 때문에 오버엔지니어링을 하는 순간이 있다.

매 프로젝트마다 이것을 반복하는 것은 꽤나 쓸데없는 일이었다.

 

동아리 홈페이지 개발 및 운영, 그리고 사이드프로젝트인 Ecok을 개발하면서...

새로운 기술을 사용할 때에는 '꽤나 합리적인 이유'가 있어야 한다는 것을 느꼈다.

거기에 비용도 저울질하여 기술을 도입해야 하는 명확한 이유가 있으면 더 좋았다.

 

그럼 가장 많이 하는 행위인 ChatGPT한테 물어보는 것은 어떨까?

내 두번째 남자친구인 ChatGPT한테 '이 문제 발생했는데 해결해줘'하면 여러가지 방법을 제시하고,

그 중에 AI 본인이 생각하기에 가장 합리적인 대답을 **강추**해준다.

 

그럼 나, 백엔드 개발자는 왜 있는 것일까?

인간이 자연스레 인간의 존재에 의문을 가지며 철학이 탄생했듯이...

개발자도 자연스레 개발자의 존재에 의문을 가지게 된다.

 

AUSG?

조금 돌아왔지만 정리하자면...

나는 이렇게 불편한 나의 마음을 가장 먼저 해결하고 싶었고,

그래서 스스로 생각하고 결정을 내릴 수 있는 개발자가 되고싶었고,

그래서 공부를 깊이있게 할 필요성을 느꼈고,

새로운 커뮤니티에 소속되는 것이 그것도 해줄 수 있을까?라는 궁금증이 들었다.

 

나는 학교 SW 동아리 운영진으로서 2년째 활동하고 있기 때문에, 사실상 새로운 동아리에 들어가고 싶은 마음은 크지 않았다.

하지만 AUSG 홈페이지와 인스타그램 등을 보면서 뭐하는 곳인지 더 궁금해졌다.

결론적으로 AUSG 빅챗에 직접 참여하여 나의 궁금증을 해소하기로 했다!

 

AUSG 아닌 사람이 AUSG Big Chat 가보기

 

 

AUSG 홈페이지에 들어가보면 Big Chat이라는 건 간단히 말해 지식을 공유하는 세션이라고 한다.

AUSG에서는 모든 사람들이 지식 공유자가 되고, 이 지식이 나누면서 더 커진다고 생각한다.

 

 

 

키링, 스터커 같은 거에 딱히 욕심 없는데 출석체크랑 링크드인 팔로우까지 해서 둘 다 받았다.

 

가장 인상깊었던 세션 No I don't think so.

세 개의 세션이 진행되었는데, 내가 가장 인상깊었던 세션은 문성혁(AUSG 3기, 쿠팡 Sr.Back-end Engineer)님의 세션이었다.

처음에는 이렇게 시작한다.

개발에서 진리라고 말할만한 것들은 별로 없는데

It depneds. 모든 것은 상황에 따라 다르다는 것 하나만은 사실이다.

 

나는 이 세션에서 내 모든 것에 뜨끔했고, 그래서 AUSG이 정말 괜찮은 동아리라는 생각이 들었다. 

(물론 나머지 세션도 너무 훌륭했고 도움이 되는 내용이었다!)

 

+아래의 내용은 내 기억에서만 나온 내용이라서 정확하지 않을 수 있다...

발표가 너무 훌륭해서 메모를 하는 것을 완전히 잊어버렸다.

 

 

HTTP Status Code는 표현력이 부족.

401(Unauthorized) vs 403(Forbidden)

 

401은 요청에 인증이 필요함을 나타내는 상태코드이다. 그런데 Unauthorized? 

그러면 Unauthenticated라고 하는 게 더 적합할 것이다. 

게다가 원래는 401은 WWW-Authenticate 헤더 필드를 보낸다. 

이걸 클라이언트에서 다시 해석하고 다시 Authorization 헤더를 구성해서 재요청한다.

하지만 요즘에는 JWT 기반 인증이 보편화되면서 이 헤더는 거의 사용되지 않는다. 

 

403은 리소스에 대해 자격 증명이 부족함을 나타내는 것이다. 

 그래서 사람들은 401은 로그인이 안 됐다, 403은 로그인은 됐지만 권한이 부족할 때 쓴다고 보는 것이 일반적이다. 

 

하지만 이 역시 많은 사람들이 토론을 거쳐서 그렇게 하는 것이 따봉을 더 많이 받은 거지,

실제 문서에서 그렇게 하라고 하지는 않았다.

 

https://www.rfc-editor.org/rfc/rfc7235#section-3.1

RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication

https://www.rfc-editor.org/rfc/rfc2616#section-10.4.4

RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1

 

나도 항상 StatusCode 를 정할 때, 이거 맞나? 하는 생각이 들고

프론트에서도 여기서는 401 떠요, 403 떠요 

그러면 '지금 403 뜨는 게 맞아요.' 라고 하게 된다. 

이렇게 질문이 계속 들어온다는 것은 이 상태 코드 자체가 좋은 응답이 아니라는 것을 의미하는 것은 아닐까?

 

 

 

Restful API에 대한 집착

 

처음에 Restful이라는 말을 배우게 되면 REST의 원칙에 취하게 된다.  

REST란 Representational State Transfer이라는 것인데...

핵심은 resource의 representation.

HTTP URI를 통해 resource를 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것이다. 

 

그리고 함께 일하는 동료에게 '아 이건 restful하게 바꾸고 싶은데 어떻게 할까?'라고 물어본다. 

그러면서 응 restful, 응 restful, rest api하면서 거의 rest 집착녀처럼 행동하기도 하는데...

 

하지만 Restful API가 Restful하지 않다면 우리는 어떻게 해야될까?

예를 들어, 어떠한 간단히 resource를 삭제하는 작업이라고 해보자. 

그러면 DELETE를 써야겠다. 

그런데 서버단에서는 soft delete로 처리를 하고 있어서 사실상 PATCH에 가깝다. 

여기에서 내가 DELETE를 쓴다면 클라이언트에게 거짓말을 해야한다. 

거짓말을 하기 싫어서 PATCH를 쓴다고 하면,

리소스 중심이니까 이걸 '삭제'한다는 표현을 제대로 못하게 된다. 

그럼 Restful하지가 않게 되는 것 아닌가?

 

이 간단한 예시 뿐만이 아니라 비즈니스 로직은 정말 복잡하고,

이 REST라는 원칙이 모든 것을 다 처리할 수는 없다. 

RESTful API는 리소스에 관리에 관한 얘기지 비즈니스를 설명하는 도구는 전혀 아니다.

 

REST라고 무조건 좋은가? 정말 하나도 아니라는 것이다.  

 

 

주석에 대한 관점

나는 솔직히 말하면 주석다는 것을 싫어한다.

왜냐하면 메서드 명을 지을 때 고민해서 표현하고, 또 깔끔한 로직이 있으면 다 이해할 수 있는데 뭐가 문제?

주석을 매번 모든 구간에 다는 것이 나를 불편하게 하기도 했다. 뭔가 '예쁘지'않다고 할까. 

그리고 내가 최근에 본 인스타그램 릴스가 있는데... 여기서도 나의 편협한 생각을 지지해주었다.

Code == Art인데...'도대체 왜 주석을 다냐'는 것이다. 

Art가 되면, 함축적으로 다 표현할 수 있다.

그리고 내 블로그 이름도 'Code Art Online'이다...

이처럼 좋은 코드에는 주석이 없다는 것이 현재의 문화로서도 자리잡았다. 

 

그도 그럴 것이 Clean Code라는 아주 유명한 책에서는 '코드로 의도를 표현'해야 하고

'주석은 나쁜 코드를 보완하지 못함', 결론적으로 주석은 '나쁜 코드의 증거'라고 말한다.

 

그런데 의도, 역사, 상황, 예외는 어차피 코드로 표현할 수 없다.

 

예를 들어 역사, 방법 A로 하는 것이 낫지만

클라이언트의 요청에 의해 B로 하기로 합의했다고 해보자.

메서드명에 이 내용을 담을 수 있는가? 절대로 없다.

물론 Issue 및 PR에 포함할 수도 있겠지만, 주석보다 코드와 더 가까운 부분은 없다.

 

몇명이서 하는 작은 프로젝트에서는 물론 주석이 필요 없을 수 있다. 

하지만 기업에서 일하게 되면, 내 코드를 다른 사람이 보고 고쳐야 하는 경우도 많은데

따라서 '오늘 들어온 사람도 작업할 수 있는 comment'가 정말 필요하다.

 

 

TDD and 김DD

그리고 TDD이다. 먼저 말하자면 나는 TDD를 안 하지만 (못했다) TDD를 해보고 싶고 TDD를 하면 좋은 것 같다고 생각한다.

나는 TDD를 못해서 '김 주도 개발'이라는 것을 한다. 김 주도 개발은 김을 먹으면서 최소한의 타이핑으로 개발을 하는 것이다. 

그래서 이제 나같은 사람은 코드를 본인이 짜고 테스트 코드를 AI한테 시키는데... 이게 도대체 뭐하는 짓인가(?) 라는 것이다. 

 

 

결론적으로 TDD is not option이 현실적이라는 것인데 자세한 내용은 유튜브에 올라올 발표 영상을 직접 보는 것이 좋다.

여기에서는 TDD만이 아니라 AI의 시대에 개발자들이 TDD를 왜 해야하는지 쭉 이어지는 내용이 있다.

 

 

 

 

 

 

 

 

6. INTP의 뒷풀이 가보기

 

 

 

예상치못한 뒷풀이도 한다고 하여... 

운영진분들이 너무 친절하시고, 모르는 사람들도 많아서 부끄러워졌지만

그래도 가고싶어서 뒷풀이에 참여했다!

다들 세션이 좋았는지 많은 분들이 뒷풀이를 가셨다. 

 뒷풀이에서 내가 그동안 궁금했던 것들, 개인적으로 궁금한 것들을 조금씩 여쭈어보았는데

내가 지향하는 것들과 AUSG이 지향하는 것들을 마음속으로 비교해가면서 고민해볼 수 있는 시간이 되었다!