brunch

매거진 개발이즈마이랖

라이킷 12 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 갬성개발자 Aug 16. 2023

인프콘 2023 (성장편)

인프콘 2023 에서 들었던 세션들 중, '성장' 관련 세션 두개를 정리한다.

나머지 기술 세션도 너무 좋았지만 (특히 동욱님의 발표 기승전결 완벽..)

글로 전달하기에는 한계가 있으므로 공개된다면 발표영상으로 보는 걸 추천한다.

그저 빛..

어느 날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들

영한님이 발표해주셨다 (팬미팅 느낌 ㅎㅎ)

Part 1. 기술과 비즈니스

개발자 = 기술과 비즈니스 둘다 잘해야한다.

1) 기술

# 세가지 유형의 개발자

1. 기술 공부를 안하는 개발자

- 팀에서 동작하는 코드를 보고 이렇게 비슷하게 짜면 되는 구나!

- 기술에 대한 깊은 이해 없이 개발 업무 반복

- 기술적인 근본 원인을 파악해서 문제 해결 어려움

- 팀에서 새로운 기술을 도입할 때 주저함

- 1년차 경험을 10번 반복하는 10년차가 된다.

2. 기술 트렌드 찍먹 개발자

- 기술 공부를 하기는 하는데..

- 팀에서 사용하는 기술도 제대로 이해하지 못한 상태

- 새로운 기술을 도입하자고 한다면?

- 기술의 깊이가 만들어지기 어렵다.

3. 팀 기술을 잘이해하는 개발자

- 팀에서 사용하는 기술 역량을 잘 쌓아둠

- 기술을 잘 이해해서 팀 업무를 원활하게 진행

- 팀에 기술 문제가 발생했을 때 원인을 정확하게 파악해서 해결

- 신뢰와 기술 포인트

- 팀에서 점점 중요한 업무를 맡게 됨

- 결과적으로 평가와 연봉에 반영

# 학습 순서

팀 기술 학습 → 업계 메인 기술 학습 → 주변 최신 기술 학습

# 경기와 훈련

- 운동 선수가 평소에 훈련하지 않는다면?

- 개발자도 꾸준한 훈련의 시간이 필요하다.

- 경기 = 회사 업무

- 훈련 = 업무외 학습의 시간

# 기술을 학습한다는 것

- 기술을 업무에 사용할 줄 안다고 그 기술을 잘 아는 것은 아니다.

ㄴ 1년차의 경험을 10번 반복

- 기술의 기본 원리를 이해하고 깊이 있게 학습

- 그 기술이 왜 필요한지 이해

- 해당 기술을 사용해서 밑바닥부터 스스로 완성

- 문제가 발생했을 때 해당 기술에 대한 해결사 역할

2) 비즈니스

비즈니스에 대한 학습에도 투자해야한다.

개발자가 비즈니스를 학습한다는 것?

비즈니스와 개발이 어떻게 연결되어있는 지 이해하는 큰 지도를 그리는 것

# 큰 지도 만들기

- 비즈니스 이해

ㄴ 인터뷰: 비즈니스에 대해서 듣고 이해하라, 기획자, 팀장, 문서 등등

ㄴ 어드민의 기능하나하나 다 사용하기 + 사용자의 기능 사용해보기

- 비즈니스 구현 이해

ㄴ 데이터: 핵심 테이블(엔터티), 핵심 필드 정리

ㄴ 핵심 업무 프로세스 정리

# 두 종류의 개발자

1. 비즈니스 이해가 약한 개발자

- 큰 그림에서 전체 상황을 이해하지 못함

- 지도가 없으므로 어디까지 질문해야할지를 잘 모름

- 작업의 영향 범위가 어디까지 영향을 미치는 지 파악이 어려움

- 요구사항을 제대로 처리하지 못함

- 중요한 메인 업무가 있을 때, 영향 범위를 잘 모르기 때문에 실패할 가능성이 높음

- 더 큰 업무를 맡기기는 어려움 (팀의 서브 업무)

2. 비즈니스를 잘 이해한 개발자

- 지도가 있으므로 어디까지 질문해야 할지를 잘 이해

- 시간이 지날수록 전체 그림에 살을 붙여서 비즈니스와 아키텍쳐에 대한 이해도가 높아짐

- 큰 변경사항이 있어도 영향 범위가 어디까지 미치는 지 이해

- 큰 그림으로 전체 상황을 이해하기 때문에 영향도 이해, 아키텍쳐 변경도 가능

- 조직에서도 더 큰 업무를 맡김(팀의 메인 업무)

- 도전적인 업무 가능

# 좋은 시스템을 설계하려면?

- 개발을 잘 하기 위해서는 비즈니스 이해가 필수

- 비즈니스를 이해해야 좋은 아키텍쳐 설계 가능

ㄴ 아키텍쳐 설계는 트레이드 오프

- 애플리케이션 아키텍쳐의 선택은 변경 가능성의 영향이 큼

- 그런데 이게 변할지 안변할지 선택이 필요 - 비즈니스를 알아야 가능

Part 2. 용기와 WHY

코드+비즈니스 -> 그 다음은 용기와 WHY 이다.

# 용기

사진+필기가 없는데 용기내서 메인기능 담당하라고 말씀해주셨던 게 기억난다.

이 슬라이드가 요 맥락에서 등장했는 지 모르겠습니다... ??

# WHY

- 근본적인 이유를 알아야 본질적인 답을 찾을 수 있다.

- 기술이든 비즈니스든, 근본적인 이유를 알아야 올바른 대안을 찾을 수 있다.

# WHY - 커뮤니케이션

- 공격조심

- 기획자에게

- 개발자에게

마법의 단어 “고민이 있습니다”

(존중하지 않은 사람에게는 이런 말을 하지 않기 때문)

코드를 개떡 같이 짰어도

# WHY - 내가 리더라면?

- 리더는 100번 질문해도 100번 대답할 준비가 되어 있어야한다.

- 왜 이 일을 해야하는 지를 잘풀어서 설명

- 팀장만 리더가 아니다. 모두가 리더다.

- 기술, 비즈니스 모두

# 깊이

끊임 없이 고민하고 항상 왜? 라는 근본 질문을 해라

그래야 깊이가 생긴다 좋은 시니어는 기술/비즈니스 둘다 깊이가 있어야한다

# 고민이 너무 많아서 개발속도에 영향을 준다면?

고민은 많이 하되 항상 단순하게 시작하라

구체화랑 추상화를 넘나들어야한다

짜봐야지 보인다

어설픈 최적화가 개발생산성을 엄청나게 낮춘다

항상 단순하게, 필요에 의해 늘려가기

아키텍쳐도 가장 단순하게 시작

고민은 하되 우리 상황에 맞게 최대한 단순하게

# 조급한 마음 vs 거북이 마음

- 멀티태스킹

ㄴ 인간의 CPU는 하나, 컨텍스트 스위칭 비용은 매우 큼

- 거북이 마음

ㄴ 한번에 하나씩 처리

ㄴ 속도 != 깊이

하나씩 뽀개면서 성장하는 느낌이 있어야한다

학습을 할때는 깊이에서 원리를 배우고 실무에서 이렇게 써야겠다 연관이 되며 시간이 걸린다.

고민하고 뜯어보고 만들어보고 해야 내껄로 된다.

느낀점

1) 기본기와 문제해결력 (from 깊이+WHY+꾸준한 학습) 이 개발자의 중요한 덕목이라고 생각하는데

영한님이 강조하니까 내가 잘생각했구나 하는 마음에 뿌듯했음

2) 개발자의 다양한 유형을 나눠주신게 좋았다.

내가 생각하는 개발자의 디폴트값 이상의 사람들이랑 일해와서 그런지

반대의 사례를 만나면 잘 믿기지 않고 좀 혼란스러운데 이런 객관화가 도움이 된다.

('1년차 경험을 10번 반복한 10년차' 는 발표를 위해 과장하신 건지 영한님이 실제로 만나신 건지 궁금쓰)

3) 제대로된 학습은 당연히 시간이 오래 걸린다는 말씀이 좋았다.

토비님의 세션도 듣던 세션이 일찍 끝나서 마지막에 살짝 들었는데 '나만의 정의와 설명을 만들어가기 (한 문장으로 정리 -> 한 문단으로 정리)' 를 말씀해주셨다. 위키피디아 설명을 복붙해서 블로그에 옮기지 말고 자신만의 언어로 정리할 수 있어야한다고 하셨다. 이 또한 시간이 오래 걸리지만 제대로된 학습이라는 생각이 들었다. 거북이 마음!

4) 기술과 비즈니스의 중요성을 반반이라고 하신게 인상깊었다. 그래도 개발자니까 기술의 비중이 조금더 높을 것이라고 생각했기 때문이다. 영한님의 경험 상, 개발과 비즈니스를 둘다 잘알아야지 혁신이 가능했다고 하셨다.

나는 내가 사용하고 좋아하는 서비스들만 해왔기 때문에 자연스레 비즈니스 이해도가 높은 편이다.

언젠가 관심이 없는 도메인을 담당하게 되어도 비즈니스 학습에 많은 시간을 투자해야겠다는 생각이 들었다.