2024 Te-KHU Conference 후기

2024.06.01 기말고사를 2주 앞둔 주말 낮..
구체적인 계획은 없으나 진로를 컴퓨터 공학과로 잡은 나에게 좋은 기회가 생겼다. 그것은 바로

현직에서 활동 중이신 선배님들의 연사

4분이 오셨고, 컴공의 드넓은 분야를 개괄하는 이야기를 들을 수 있었다. 

---

첫 연사는 대학생 때 알았더라면 좋았을 것들이다.

엄마가 하지 말라고 하는 것들, 늦게 자지 마라.. 라면 많이 먹지 마라.. 등등 새겨듣고 실행한다면 정말로 도움이 되는 말들이 있다. 우리는 정답을 알고 있다. 단지 당장 가시적인 효과가 나오지 않아서 실행할 의지보다 당장의 욕구가 더 클 뿐이다..

꾸준한 영어 공부, 블로그 운영, 다독, 탄탄한 CS 지식의 필요성을 말씀하셨다. 
나는 사실상 졸업할 나이이므로.. 매우 공감하며 들었다. 이 중 티스토리를 열심히 해보기로 했다.
취준 할 때 닥쳐서 컴퓨터 구조 복습하는 것보다 지금 컴퓨터 구조 배울 때 정리해 놓으면 좋을 것 같았다.

대학원을 희망한다면 전문연도 고려해보라는 새로운 정보를 얻었다.
그리고 생각보다 훨씬 학점은 중요하고, Linked in으로 경력관리도 하고, 좋은 글도 많이 읽으라는 말씀을 해주셨다.


두 번째 연사는 Debugging 101 

실무에서 직접 개발하는 비율은 10-20%고 나머지는 다 디버깅이라고 한다. 실수를 하지 말라는 건 불가능한 요구이기에 - 실제로  **억대 연봉 개발자도 실수하기 때문에 -  디버깅은 필수다. 하지만 학교 커리큘럼으로 디버깅을 다루진 않는다.  
선배님께서 후배들이 마시면서 배우는 디버깅(...) 하지 않도록 여러 디버깅 팁을 주셨다.

우선, 비효과적인 디버깅이 있다. 바로, 오류가 문제없이 돌아가는 경우다. 끔찍하다고 한다. 

우리는 효과적인 디버깅을 다룰 것이다. 효과적이란 말은 경험적인 디버깅이다.
무슨 말이냐면, code를 줄줄이 읽어서 논리적 흐름을 파악하는 것보다
내가 원래 짠 의도에 맞게 가정을 세워서 실험해보는 것이 제일 효율적이라는 뜻이다. 

핵심 디버깅 과정 <재현 - 진단 - 고쳐 - 반영>
을 따라서 예시를 들어보겠다.

잠깐만!!
디버깅하기 전에.. 정확하게 무슨 일이 발생했고, 원래대로라면 어떻게 흘러가야 하는지 알고 나서 재현을 해야 한다.
디버깅 시작! 했다고 해서 바로 재현을 시도하거나 뭐가 문제인지 고민하는 게 아니다!! 

뭘 해야 하는지 정확하게 파악한다는 것은 대명사 없이 상황을 설명할 수 있다는 의미이다. 
지금 상황 파악을 했다면 몇 가지만 더 주의하고 디버깅을 시작한다.

• 반드시 한 시간에 하나만 해결해야 한다. 인간이 원래 멀티프로세싱이 안된다.
• 주변인한테 먼저 물어보면 헛 짓을 방지할 수 있다.

---

이제 진짜로 시작한다. 디버깅의 방법 중 대표적인 2가지를 다루었다. 

1. 브레이크포인트; 하나하나 돌려보면서 확인
   visual studio에서는 local, watch 창에서 debugging 도중에 값을 변경할 수 있다.
   - 일일이 돌려가면서 하지말고, 한 번에 원하는 실행 상황으로 이동할 수 있도록 하는 목적
   
   
2. 디스어셈블리; call stack 확인
   어셈블리어 코드를 보고 문제되는 코드를 찾을 수 있다. 예를 들어, 외부 라이브러리가 문제일 수도 있다.
   - 만약 jmp에서 멈췄으면 다시 코드를 확인한다.
   - 라이브러리가 문제이고 오픈 소스 라이브러리라면 코드를 확인한다 (^^;;)
   - 예시 상황으로, null point가 났다 -> reference가 아니라 copy 해서 생긴 문제네.. 이런 식으로 찾는다.

위 방법을 구체적으로 실행하는 방법은 아래와 같다.

1. 정확하고 구체적인 환경을 재현한다. 오류가 발생한 상황을 그대로 만드는 것이다.
2. 어떤 오류가 나는지 확인한다. 디버깅을 눌러서 오류 코드를 본다.
3. 오류 코드나 상황을 보고 가설을 세운다. 무한 loop인 거 같은데?라는 가정을 한다면 이를 실험한다.
4. 다른 코드를 변형하지 않는 선에서 수정한다. if문이 오류가 났다고 해서 if문을 지우는 등의 큰 실수를 하지 말자.

정말 현실적인 실무 작업을 볼 수 있어서 좋았다. 부끄럽지만 나는 아직도 개발자라 하면 코드창 열어놓고 키보드 두드리는 쿠루루 같은 모습만 떠올랐을 뿐, 코드창에 무엇을 두드리는지는 몰랐기 때문이다...

 

세 번 째 ! 힙스터 개발자의 길라잡이 

여기서 힙스터 개발자는 개발이 전무후무한 분야에서 새로운 결과물을 만드는 것을 의미한다!
당장 취업 자소서를 써야 한다는 상황이라면, 도움이 될 연사였다.

1. 일할 회사 고르는 방법
 개발 스택보다 컬처핏이 중요하다고 느껴졌기에 (실력이 받쳐준다는 전제 하에) 아래 내용을 따져보길 제안하셨다.

1. 조직의 분위기가 어떤가
2. 문화가 어떤가
3. 일하는 방식은 어떤가

2. 회사에 어필하는 방법
 스택을 사용하는 reasonable한 이유를 가지고 있고, 스택을 이해하고 있다는 점을 어필하는 것 - 이 부분이 넓고 얕게 아는 스택보다 더 중요하다고 하셨다.
당장 개발자를 희망한다면 엄청난 속도로 발전하는 현업에 맞추어 다양한 언어를 배워야 할까 고민하는 전공 학도들이 많다. 가려운 부분을 잘 긁어준 내용이었다.

3. 현업 트렌드

• AI 엔지니어링 : AI를 어떻게 잘 쓰는가 (AI 개발하라는 거 아님)
• 플랫폼 엔지니어링 - Devops , server dev, data engineer 파트가 연결된 분야 
  넹? devops 아닌가요?? 아닙니다.
  차이점: CI/CD 파이프라인, 모니터링보다는 개발자가 비즈니스 로직을 짤 수 있는 최적의 환경 만드는 것에 집중
  
  

 

마지막 연사, 컴퓨터공학과 나왔다고 꼭 개발자가 되어야 할까요?

컴퓨터공학과 졸업 후 다른 분야에서 일하시는 사례다. 개발의 영역에 발 담갔다가 데인 사람이라면 선배님의 연사가 매우 궁금했을 거라고 생각한다. (내 이야기다..) 
 선배님은 단호하게 말씀하셨다.  C++ class 어려워서, 또는 강의 중 어떤 내용이 어려워서 등의 이유로 개발자가 되기를 포기한다면 미래에도 똑같은 난관에 부딪힐 가능성 높다.  ... 현실을 정확하게 짚어주셨다. 채용을 위해서는 난관을 헤쳐나갈 수 있다는 능력을 보여주어야 한다는 것이다. 실제로 회사가 작아질수록 실패를 맛볼 가능성이 높고, 이를 케어해 주지 못할 확률도 높다고 한다. 본인의 회복탄력성이 자신의 능력으로 인정받을 것이라고 하셨다. 

---

매우 유익한 토요일의 오후였다. 하지만 연사 후 질의응답 내용이 정말 알짜배기였다. 
앞서 말했듯이, IT 전공에는 소수의 괴물들이 있다. 이들은 압도적인 능력치를 발휘하기 때문에 겁 먹고 '직업으로 개발은 절대 싫어' 하는 전공생이 꽤 있다. (내가 그렇다..) 내 자질을 의심하는 나에게 도움이 되는 말을 많이 주셨다.

1. 컴공 자질에 관한 말:
 이과고 문과고 어쩌구 저쩌고보다는, 논리적인 사고를 할 수 있고 코드를 머릿속으로 그려낼 추상화 능력이 있다면 코딩이 크게 무리가 되지 않는다.

2. 여러 stack을 쌓아야 할까요? 한 가지 언어에 집중해야 할까요?
게임 업계를 희망하는데 언리얼을 사용해야 할까요? 유니티를 사용해야 할까요?
대외활동을 해야 할까요? 프로젝트를 해야 할까요?

지금 막연하게 스펙을 목적으로 두지 말고, 언어나 코드는 수단이니까 자신이 하고 싶은 목적을 찾으라고 하셨다. 

 

우문현답 감사합니다.. 안개가 싹 걷혀진 느낌이에요.
일단 나는 프로젝트도 제대로 해보지 못한 응애이기 때문에 쫄지 말고 좀 더 부딪혀봐야겠다.

 

 

p.s.) CS 지식을 강조하셔서 로드맵을 찾아보았다.

https://roadmap.sh/backend

Backend Developer Roadmap: What is Backend Development?