[회고록] GDGoC세션 - 우리에게는 치트키가 없다.

 

25–26기 GDGoC CAU에서 2025년 9월 30일에 진행된 세션 “AIoT 회사는 어떤 일을 할까?” 중 마지막 챕터를 발췌해 작성했습니다.

실제 발표는 아래의 목차에 따라 진행되었으며, 「베이스 잘 치는 방법」 에서 해당 글의 앞 부분을 확인할 수 있습니다.

개인적인 생각을 담은 글이니, 그냥 그렇구나~ 하고 읽으시면 되겠습니다...

 

---

우리에게는 치트키가 없다.

「베이스 잘 치는 방법」 에서 무적만능 치트키로 '취미생의 마인드'를 소개했다.
취미생활을 하면서 여러 한계에 부딪히지만, '일단 재밌으니까 만족!'하고 취미생의 마인드를 켜면 당장의 문제를 해결(회피)할 수 있다.
다만 너무 남발하면 실력이 늘지는 않고, 가끔 욕심이 과할 때 필요하다고 소개했다.
 

전공생의 입장에서, '개발 재밌으면 그만'하고 취미생의 마인드를 on 해버리면 문제를 해결하기보다 계속 회피하게 되고...
실력은 그대로인데 마음속으로는 불안도가 점점 높아지는 악의 구렁텅이로 빠진다...
 
그래서 (고작 이지만 나름대로) 생각해본... 
 

1. 개발 잘 하는 법

우선 개발을 잘 하기 위해 노력하면서 생기는 어려움/한계에 대해 정리했다.
'베이스 잘 치는 법'에서 소개한 원인파악~해결방법에서 발생하는 어려움/한계와 동일한 포맷을 가진다.

 
 
 

한계1. 물리적 한계

1-1) 피지컬의 한계
한글200타 영타100타 안나오면 한컴타자연습 해야한다. 예공친구들과 합의점을 봤는데 200은 너무 심하고 한글300타로 기준을 올렸다. 영타의 경우 텍스트 에디터 프로그램에서 자동완성을 해주기 때문에 독수리타법 + 100~120타 사이로 나오는 경우가 왕왕있다. 영타 200타까지는 올리도록 하자.
 
1-2) 시간적 한계
밥 벌어먹고 살건데 시간이 없다하면 좀 문제가 있는거 아닐까 하는 생각을... 물론 정말 밥벌이한다고 전공공부하기 힘들 때가 있긴한데. 다들 대충 알아들었을 것이라 생각한다...
 

 

한계2. 장비의 한계

장비병은 대개 애플 병이나 키보드 병 따위로 찾아온다... 사과마크에서 힘이 온다나...
장비병은 상사병 같은거다... 사야 나으니까 열심히 벌어서 사고 비싼돈 주고 마련했으니 열심히해서 뽕을 뽑자.

한계3. 지능의 한계

우리를 제일 곤란하게 만드는건 이거라고 생각한다.
 
3-1) 좋은 코드가 뭔지 모름(개발력 떨어짐)
어떤 것이 '좋은 것'인지 구분하지 못하는 상태, 즉 찍어먹어봐도 이게 똥인지 된장인지 구분을 못하는 상태라고 보면 되겠다. 내력을 단련해서 스스로 똥과 된장을 구분할 수 있으면 제일 좋지만... 더 빠르고 좋은 방법은 피드백을 받는 것이라 생각한다. 
 
(1) 피드백을 많이 받자
내부적인 부분 - 소스코드 등은 코드 리뷰로 직접 하나하나 뜯어보는걸 피어리뷰해볼 수 있을 것 같고, 소나큐브 같은 분석 도구의 힘을 빌리는 방법도 있겠다. (회사에서는 소나큐브를 돌려서 일정 등급 이상이 나올때까지 리팩토링을 진행했다.)
 
또 디자인부터 UX와 같은 외적인 결과물도 매우매우매우매우 중요하다. 그런 의미에서 QA, 베타 테스트 등을 피드백 항목에 포함해보았다.
개인적으로는 특정한 ouput을 위해(보통 더 나은 결과물을 위해) 특정 구조를 취하게 되는 것이라 생각하는데, 따라서 외적요소와 내적요소의 인과관계, 당위성 따위도 주요한 피드백 요소가 될 수 있겠다.
 
(2) 좋은 코드를 많이 보자.
 
 
3-2) 지식이 부족함
CS 공부든 알고리즘 공부든 잘 모르는건 공부하면 된다. 공부를 좀 하자.
 

---

그럼 우뜨케해야 개발을 더 잘 할 수 있을까? 
개발력은 어떻게 키울 수 있을까?
개발력을 키우려면 좋은 코드를 많이 보자고 했는데, 좋은코드는 어떤 걸까?
 

2. 똥만 열심히 보면 똥만 싸게 된다.

일단 다시 '좋은 코드를 많이 보자'로 돌아왔다.
 
예공 전공 수업을 듣다보면 '전시를 많이 다녀라, 많이 경험해봐라.', '영화를 많이 봐라' 같은 얘기를 많이 듣는데, 본질적인 목적은 '안목을 키우기 위함'이다. 개발도 동일하다. 많이 놓치는 부분이라 생각하는데, 코드 - 더 나아가서 프로그램에 대한 안목을 높이자.
 
또 사족을 달자면...
기능적, 구조적인 부분외에도 '내가 만들어낸 프로그램을 팔기 위해 어떻게 잘 보여줄 것인지'도 개발의 안목에 포함된다고 생각한다. 개발자 컨퍼런스에 많이 참석해보고, IT 전시에도 많이 참가해보자. 어떻게 시연하고 어떻게 전시했는지, 어떤걸 보여주고자 하는지 생각해보자. 
 

똥만 열심히 보면 똥만 싸게 된다.

 
콩콩팥팥이라고 하는데... 정확히는 좋은 것만 보면 좋은 것만 만들 수 있다는 보장은 안되는데, 확실히 똥만 열심히 보면 똥만 만들 수 있다. 이거는 100%.
 
그러면 좋은 코드, 좋은 프로그램은 무엇일까?
 

3. 반복되는 코드는 개발자를 불안하게 만들어요.

본질로 돌아가자. 그럼 프로그램은 왜 만드는 걸까?
일단 팔아서 먹고 살려고 만든다... 우리는 직업 개발자니까.
이때 회사는 경영을 하기 때문에 최대한 저비용으로 많이 팔 수 있는 상품을 만들려고 할 것이다. 여기서 고민에 고민에 고민을 거듭하고 세월이 쌓여서 만들어진게 개발방법론 - 폭포수 개발, 에자일 개발 등등... 일 것이다.
 
간단히 정리해보자면
 
개발방법론, 명세서 등에 대해 배우는 이유
⇒ 고효율로 일하자
 
클린코드, 클린아키텍처 등등
⇒ 고효율로 개발하자
 
가 되겠다.
 

좋은 코드, 좋은 프로그램이 뭔지 잘 안와닿는다면 반대로 접근해보면 조금 더 쉽다.
최대한 저비용으로 많이 팔 수 있는 상품이 우리가 만드려는 추구미 프로그램이라고 했다.
 
그럼 반대로 좋지 못한 프로그램은 고비용 저생산을 유발하는 프로그램 = 만들때마다 계속 다시 처음부터 하나하나 만들어야하는 프로그램이겠다... 따라서 만들때 다시 사용할 수 있는 프로그램, 새로운 기능을 추가할 때 다시 처음부터 만들 필요가 없는 프로그램이 좋은 프로그램이라고 생각해볼 수 있다.
 
즉, 유지보수와 재사용성을 고려한 코드가 좋은 코드라고 결론지었다.
+) 이게 솔루션 기업의 존재의의가 아닐까 하는 생각
+) 그래서 응집도 결합도 이런 개념을 배우고 계속 설계를 강조하는게 아닐까 하는 생각
 

4. 지속가능한 코드

아래는 사내 교육 중에 간간히 받았던 질문이다.
 
나의 스타일이 잘 드러나는 코드는 좋은 코드일까?

정답은 아니다.
유지보수가 용이한 코드는 공통된 규칙에 의해 작성된 코드이다.
그래도 주석을 예쁘게 잘 달자는 얘기는 많이 듣지 않는가? 나 조차도 내가 작성한 프로그램이 어떻게 쓰였는지 까먹는데, 남이 쓴건 오죽할까. 코드가 매뉴얼에 따라 일관성 있게 작성되어있으면 내가, 인계받는 자가, 코드를 더 빠르게 파악할 수 있다.
 
기능을 구현하는건 쉽다.
지피티 딸칵으로 끝난다. (클로드가 이게 심한데, 워낙 스파게티 코드라 기능 하나를 추가하면 코드를 갈아엎어야한다.)
근데 이걸 지속가능하게 만드는 것은 어렵다.
지속가능한 코드를 만드는 건 아직 인간의 영역이라고 생각한다.
 

5. 지속가능한 프로그램

금융권, 기상청에서는 COBOL같은 고대언어를 아직도 쓰는 것으로 악명이 높다.
최근 기사에 국민은행에서 2025년 10월 17일까지 서버 프레임워크를 코볼에서 자바로 변경하는 작업을 진행한다고 한다. 그러니까, 아직도 코볼로 되어있다는 이야기다. 이런 경우 코볼을 할 수 있는 프로그래머를 비싼 연봉에 모셔오거나, 다른 프로그래머에게 코볼을 교육시켜야 한다... 사장되어가는 언어인 만큼 다른 언어에 비해 요구되는 비용이 크다.

 
개인의 작업물에는 10년, 20년뒤의 미래를 염두할 필요가 없겠지만, 기업의 시간 단위에서는 다르다. 앞으로 유지하는 비용과 교체하는 비용을 계속 저울질하게 될 것이다.
 

 
코드를 묶으면 프로그램이 된다. 지속가능한 코드도 확장하여 지속가능한 프로그램의 영역으로 가져왔다.
지속이 힘든 프로그램은 사람과 환경을, 리소스를 계속 프로그램에 맞추면서 비용을 소모한다.
프로그램 언어가 사장될지언정 인터페이스가 존재한다면 어떻게든 교체할 수 있다. 
패킷 규격같은건 왜 정하는 걸까, 인터페이스는 왜 필요한 걸까, 계속 생각해보자.