이 글에 대해서

이 글은 테코테코라는 코테 스터디 모임에서 진행한 김희성 님과의 특별한 밋업 현장을 요약한 것입니다.

테코테코가 사용하는 메인 책이 "코딩 테스트 합격자 되기: 자바 편"인데요. 모임의 한 멤버가 우연히 책의 저자인 김희성 님과 인연이 닿아, 그 인연으로 작가님과의 밋업이 성사되어 코딩 테스트부터 개발자의 이직과 성장 등 현실적인 이야기에 대해 저자님의 생각을 들을 수 있었습니다. (가능한 한 현장 발언을 최대한 그대로 옮기려 했으나, 중간중간 필자의 의견이 섞여 있거나 실제 멘트와 100% 일치하지 않을 수도 있음을 미리 밝힙니다.)

글 하반부에는 개인적으로 이 밋업을 통해 얻게 된 인사이트와 성찰과 간단한 상반기 회고도 담았습니다.

코딩 테스트 Q&A — 현장 그대로, 한 뼘 더 깊게

Q1 코딩 테스트 초보자를 위한 효율적인 학습 로드맵

Q1-1. 자료구조/알고리즘 우선순위는 어떻게 보시나요?

“자료구조를 잘 알아두면, 어떤 메서드가 어떤 시간 복잡도를 갖는지 자연스럽게 파악할 수 있다.
실무에서도 ‘왜 이 메소드를 쓸까? 이 구조를 택하면 성능이 어떨까?’를 빠르게 판단할 수 있기 때문에,
우선순위는 무조건 자료구조가 먼저라고 생각한다.”
– 김희성 님

자료구조가 변하지 않는 이유

김희성 님에 따르면, 자료구조는 “10~20년이 지나도 실무에서 새로 뚝 튀어나오는 게 드물 정도로 축적된 학문”이기에 꾸준히 공부해 놓으면 변치 않는 무기가 됩니다.
예컨대, 해시맵(HashMap)은 Key 탐색에는 효율적이지만, Value만 빠르게 찾으려면 다른 구조가 필요합니다. 이런 지식이 익숙해지면, 코딩 테스트 문제 풀이 시 “해시맵을 여기서 써도 되나?”를 바로 파악합니다.

알고리즘보다도 중요한 ‘자료구조 선택 능력’

실무 코딩 테스트(경력직 대상)는 복잡한 알고리즘(예: 다익스트라, 플로이드-워셜 등)보다는 우선순위 큐, 해시맵을 효율적으로 쓰는 문제가 자주 출제됩니다.
해시맵, 리스트, 트리, 스택/큐 등 주요 자료구조의 시간 복잡도와 쓰임새를 정확히 숙지한다면, “DFS나 특정 알고리즘을 외워두지 않아도 문제 의도를 빠르게 캐치”할 수 있다고 강조했습니다.

Q1-2. 깊게 한 챕터 vs 넓게 여러 챕터

“한 챕터를 깊게 파보면 내공이 훨씬 쌓여서, 결국 다른 챕터도 쉽게 접근할 수 있다.
그래서 본인은 자료구조 중에서도 해시나 우선순위 큐 같은 핵심 분야를
‘아주 깊게’ 파는 방식을 강력히 추천한다.”
– 김희성 님

왜 깊게 파야 하나?

“어느 한 분야를 깊이 파면 그 지식이 다른 문제 해결에도 확장된다”는 말은, 예를 들어 해시맵을 충분히 이해하면, 해시 충돌이나 키-밸류 매핑처럼 다른 자료구조와의 비교를 자연스럽게 알게 됩니다.
다양한 문제 유형(문자열 처리, 수열 처리, 그래프 탐색 등)에서도, 결국 핵심 자료구조만 바꿔 끼우면 쉽게 풀리는 케이스가 많다고 합니다.

해시, 우선순위 큐, DFS/DP 중심으로 대비

김희성 님이 여러 기업의 경력 코딩 테스트를 지켜보니,

구현/문자열 문제(쉬운 수준)
해시맵, 우선순위 큐
DFS 혹은 간단한 DP
정도가 공통적으로 자주 등장하는 패턴이었습니다.
이 때문에 “경력직 시험은 알짜 자료구조/알고리즘만 잘 익혀도 커트라인을 충분히 넘길 수 있다”고 조언합니다.

Q1-3. 저자는 어떻게 코딩 테스트를 준비하셨나요?

“삼성SDS에서 사내 코딩 테스트 강사로 차출돼서,
‘어쩔 수 없이’ 문제를 주말·퇴근 후 매일 풀다 보니 실력이 폭발적으로 늘었다.
주변 ‘잘하는 분들’ 스터디에 껴서 질문하고 답해주고,
그 압박감 속에서 엄청 성장했다.”
– 김희성 님

강제 스파르타 환경

김희성 님은 삼성SDS 시절, 우연한 계기로 (?) 사내 코딩 테스트 TF에 차출되어, 하루아침에 코테 강사를 맡았습니다.
“내가 강의해야 하니, 질문받기 전에 먼저 문제를 풀고 이론을 파악해야만 했고, 사내 고수 개발자들이 ‘이 문제 재밌으니 풀어보세요’ 라며 주말에도 숙제를 던져줬다. 그러다 보니 싫어도 빡세게 연습할 수밖에 없었다”고 회고합니다.

스터디와 ‘서로 질문 주고받기’의 중요성

스터디나 주변 동료 중 ‘잘하는 사람’이 있으면, 그에게 질문하거나 코드를 리뷰 받으면 좋습니다. 질문을 받는 쪽도 답하면서 실력이 늘고, 질문하는 쪽도 빠른 성장을 기대할 수 있습니다.
또한 문제를 서로 설명해주는 과정을 통해 “어설프게 알던 개념도 명확해진다”는 점을 강조합니다.

Q1-4. 코딩 테스트 시작하는 사람을 위한 꿀팁

단기간 몰입학습
- “하루 한 문제씩 1년 하는 것보다, 3~4개월 안에 빡세게 몰입해서 실력 끌어올리는 게 효율적” 이라는 조언입니다.
- 어느 정도 수준까지 올라가면, 이후 이직이나 테스트가 있을 때 짧게 ‘워밍업’만 해도 감이 살아난다고 합니다.
문제 의도 파악 & 자료구조 선택
- 문제를 보자마자, “이건 해시맵이면 되겠는데?”, “여긴 우선순위 큐로 정렬 대신 써야겠다” 등 자료구조 선정이 먼저 떠오르는 연습이 중요합니다.
- 구현하다가 시간 복잡도가 걸리면, “다른 자료구조로 개선할 수 있나?”를 습관처럼 체크해야 합니다.
멤버 구성과 압박감
- “스터디를 편한 사람들끼리 느슨하게만 하면 동기부여가 약하다. 서로 코드를 공유하고, 문제를 내고, 리뷰해 주는 등 어느 정도 ‘압박’이 있어야 실력이 잘 는다”고 경험담을 전합니다.

스터디 팁

3 개월 집중 압축기: “하루 3문제 1년”보다 “하루 10문제 3개월”이 실력 유지력이 높다.

잘하는 사람을 옆에 둬라: 질문·설명 사이클이 빠를수록 성장 곡선이 가파르다.

Q2. 코딩 테스트에서 기업이 실제로 평가하는 역량

Q2-1. 기업·면접관이 코드를 통해 보는 포인트

“경력직 코딩 테스트는 특별한 알고리즘보다는,
‘자료구조/구현 실력 + 시간 복잡도/성능 고려’
이 부분을 중점적으로 파악한다.”
– 김희성 님

경력 테스트 vs 신입 테스트
- 신입은 난이도 있는 알고리즘 문제가 나오기도 하지만, 경력직은 “언제, 어떻게 해시를 써야 하는지 아는가” 같은 구체적 실무력에 초점이 맞춰집니다.
- 예: “몇 천만 건 데이터를 다룰 때 해시를 어떻게 쓰고, 우선순위 큐로 어떻게 처리할지” 등의 문제 설정이 많습니다.
코드에서 눈여겨보는 부분
- 함수나 메서드를 나눌 때, 불필요한 복잡도를 만드는지?
- O(N^2) 로직이 나올 만한 상황에서 정렬+투 포인터 또는 우선순위 큐 같은 대안을 찾는지?
- 코너 케이스 처리를 섬세하게 했는지?
- “코드가 AI Copilot이 짜준 듯 템플릿 같지는 않은지” 면접에서 판별하기도 한다고 합니다.

Q2-2. 최근 트렌드와 난이도, 코딩 테스트의 중요도

“트렌드는 점점 라이브 코딩 면접이 늘어나고 있다”
- 작가님 경험에 따르면 스프링 프로젝트를 처음부터 만들어보게 하는 라이브 코딩 전형을 본 경험도 있다고 하셨습니다.
- AI를 어디까지 활용했는지를 파악하려면, 실시간 면접 코딩이 효과적이라는 흐름입니다.
“신입은 점점 난이도가 올라가는 경향이 있고, 경력은 실무형 문제 + 구현 능력을 본다”
- 대형 플랫폼 회사(네이버, 카카오, 쿠팡 등)일수록 코딩 테스트가 필수 관문이라 해도 과언이 아니며,
- 중견·스타트업도 여전히 최소한의 필터링 툴로 쓰는 분위기라 코딩 테스트의 중요성은 유지된다고 평가합니다.

LIVE 코딩 체험담
C사 시니어 면접(총 6라운드) 중 2라운드가 Web IDE + Zoom 실시간 코딩이었다고.

AI 의심 방지를 위해 인터뷰어가 “조건을 살짝 바꾸면?”을 즉석에서 던짐.

지원자가 본인 코드의 수정 포인트를 말문 막힘 없이 짚으면 “자료구조·성능 감수성 OK” 판정.

Q3. 실무에서 코딩 테스트 학습이 어떻게 활용될까?

Q3-1. 코테 점수가 실무 개발 능력과 연관이 있을까요?

“코딩 테스트 무용론을 말하는 분들도 있지만,
최소한의 필터링으로 의미는 충분하다.
실무에서 자료구조를 몰라서 엉뚱한 코드를 짜는 사례도 종종 보게 되니까.”
– 김희성 님

‘코테 = 업무 성과’를 직접 연결짓긴 어렵지만…
- 자율주행 알고리즘, AI 모델링처럼 심층 알고리즘이 필요한 팀이 아니라면, 코테 실력만으로 업무가 곧바로 ‘고효율’이 되는 건 아닙니다.
- 하지만 코테를 준비하며 쌓은 “자료구조·알고리즘 기본기”는, 실무에서 큰 트래픽, 대용량 데이터, 성능 문제를 만났을 때 신속히 해결할 발판이 됩니다.
기업 입장에선 ‘적은 비용으로 빠른 판단’
- 모든 지원자를 면접에 부를 수 없으니, 코딩 테스트로 기초 구현 능력을 확인하고, 그다음 면접을 보자는 게 많은 회사의 방식입니다.
- “누가 봐도 시간 복잡도를 전혀 고려 못하는 코드를 짜면, 실무 투입해도 문제 발생이 잦을 것”이므로, 1차 필터링으로 코테가 여전히 선호됩니다.

Q3-2. 코딩 테스트의 순기능

학습자 입장에서:
1. “자료구조 공부를 제대로 하게 되는 계기”
2. 문제 해결 아이디어를 여러 번 시도해볼 수 있어 응용력이 늘어남

기업 입장에서:
1. 빠르게 지원자 풀이 스타일과 사고방식을 확인
2. 최소 인력으로 많은 후보를 걸러내는 장점

Q4. AI 시대에 코딩 테스트의 역할

Q4-1. AI 시대, 코딩 테스트가 사라질까?

“과제 전형이 오히려 AI(Copilot, ChatGPT)로 해버리면
진짜 분간이 힘들다. 그래서 AI 시대에는 라이브 코딩이나
캠 녹화 코딩 테스트가 오히려 더 늘어나지 않을까?”
– 김희성 님

과제 전형 vs 코딩 테스트
- 과제 전형은 제출까지 수일~수주 시간이 주어지므로, AI가 대거 관여할 수 있습니다. 결과물 완성도가 높아져도 이게 AI가 한 건지 본인이 한 건지 기업 입장에서 가려내기 쉽지 않습니다.
- 반면, 2~3시간 제한된 코딩 테스트, 혹은 라이브 코딩은 “AI에게 물어볼 시간도 부족하고, 실시간 질의응답으로 검증이 가능”하기에, 오히려 강화될 가능성이 높습니다.

Q4-2. AI 도구를 활용한 코딩 테스트에 대한 견해

처음부터 Best Practice가 나오진 않는다
- ChatGPT 등에게 “이 문제를 풀어줘” 하면, 기본적인 코드를 제시해 주지만, 시간 복잡도가 최적이 아닐 수도 있고, 부분적으로 오류가 있을 수도 있습니다.
- 결국 개발자 본인이 의도를 파악하여 “더 효율적으로 개선해줄 수 있냐?” “이 자료구조 말고 다른 방안은 있냐?”를 AI에게 물어보는 과정을 반복해야 하고, 그 과정 자체가 역량입니다.
“AI를 잘 사용하는 능력도 앞으로 중요한 역량”
- 김희성 님은 “이미 AI가 제시하는 코드를 스프링 프로젝트에 조합해서 빠른 프로토타입을 만들 수 있다. 하지만 이후 성능 개선, 에러 처리, 확장성은 사람이 직접 챙겨야 한다”고 말합니다.
- 따라서 면접관은 “AI 코드 레벨이 아니라, 본인이 알고리즘 로직을 이해하고 실제로 변형·개선할 수 있는지”를 보게 될 거라고 전망했습니다.

김희성 님은 “AI에게 1차 답을 받아도, 그 답을 성능·품질 측면에서 ‘리뷰’할 사람이 이길 것”이라고 결론지었습니다.

ChatGPT가 버블 정렬을 제안하면, “O(N²)인데 N = 10만이면 터집니다. 퀵·힙 써볼까요?”를 바로 던질 수 있어야 합니다.
AI 코드를 그대로 들고 면접장에 오면, “조건 바꿔보죠” 한 마디에 당황하는 장면을 이미 여러 번 목격했다고.

코딩 테스트 Q&A의 핵심 요약

자료구조는 최소한 알아두자: 코테와 실무를 아우르는 ‘기본기’이며, 알고리즘보다 먼저 탄탄히 익히면 다른 문제에도 쉽게 확장 가능.
짧고 굵은 몰입이 효과적: 3~4개월간 스파르타 식으로 문제 풀이하면 실력이 빠르게 상승하고, 유지도 오래간다.
실무형 문제의 평가 포인트: 시간 복잡도, 구현 능력, 성능 최적화 시도 여부를 주로 본다.
AI 시대, 코딩 테스트는 오히려 유지·강화: 라이브 코딩·캠 녹화 등 실시간 형식으로 점차 바뀔 가능성.
‘왜(Why) 이 구조를 택했는지’를 끊임없이 고민하는 태도가 코딩 테스트든 실무든 결국 성장의 핵심.

취업 & 커리어 관련 Q&A

이번 세션에서는 이직, 커리어 전략, 시니어로 가는 과정 등 현실적인 질문들이 오갔습니다.

김희성 님이 삼성SDS → 쿠팡 → 42dot 을 거치며 배운 점들을 기반으로, “어떻게 커리어를 쌓고, 시장에서 인정받는 개발자가 될 것인가” 에 대한 생생한 노하우를 들을 수 있었습니다.

Q1. 시니어가 되기까지 가장 도움이 되었던 경험이나 배움은 무엇이었나요?

“기술을 고를 때 ‘왜(Why)’가 중요한지,
단순히 최신 스택을 쓰고 싶다거나, 유행이라서 선택하는 게 아니라
‘왜 이것이 우리 프로젝트에 필요한가’를 끊임없이 고민해야 했다.”
– 김희성 님

김희성 님이 꺼낸 키워드는 단 하나, “Why”.

경험 장면	배운 점	오늘의 조언
쿠팡 리더 리뷰 “MySQL을 왜 썼지?”	기술 선택엔 반드시 근거가 필요하다	신기술을 도입할 때 장점·비용·팀 Impact를 숫자로 설명할 것
스프링 2 → 3 버전 업 제안	버전 업은 ‘트렌드’가 아니라 ‘문제 해결 수단’	변경 비용·팀 공백·ROI를 계산해 설득하기
헥사고널 아키텍처 리팩터링(週末 코드 프리징)	한 번의 대수술이 장기 관점 OCP·SIP를 살린다	“코드 프리징→단독 리팩터→팀 리뷰” 프로세스 실험해 볼 것

현장 한 줄
“시니어는 ‘이 기술 쓰면 뭐가 좋아?’를 팀이 묻기 전에 먼저 답해놓는 사람.”

Q2. 이직을 고려할 때, 현재 환경이 부족하다고 느껴지면 어떻게 커리어 전략을 세우는 게 좋을까요?

“대기업 가고 싶은데, 현재 회사에선 카프카를 안 써요. 떠나야 할까요?” 라는 질문과 "이직에 있어서 도메인 지식이 중요할까요?"라는 질문이 있었습니다.

“주니어 시절엔 사실 도메인 지식보다 ‘태도와 기본기’가 훨씬 더 중요하다.
자기가 맡은 프로젝트에서 ‘왜’를 고민하고 개선을 시도해 보면,
이직할 때도 충분히 어필할 스토리가 생긴다.”
– 김희성 님

저자님은 연차별 관점을 나눠 설명했습니다.

주니어(1-4년)
- 도메인 지식 부족보다 ‘태도’가 먼저 보인다고 느꼈다고 합니다.
- 구체적으로는 “기존 시스템을 쓰면서도 Why? 를 고민했는지, 개선 아이디어를 제안해 본 적이 있는지”가 서류·면접에서 의외로 크게 작용했다고 회상했습니다.
미들·시니어(5년 이상)
- 리딩 경험과 즉시 투입 가능성을 기업이 중요시하는 듯하다고.
- 실제로 쿠팡은 잡 레벨 평가 시 “와서 바로 시스템 하나를 맡아 굴릴 수 있나?” 를 먼저 체크했다고 합니다.

결국 “배워야 할 스택이 회사 내부에서 절대 못 나온다”는 판단이 들면 브리지 이직도 방법이지만, 그전에 사이드 프로젝트나 사내 개선 작업을 ‘증빙 가능한 형태’로 남기는 편이 안정적인 선택처럼 느껴진다는 뉘앙스였습니다.

결론
“기술 부족 때문에 회사를 바꾸느냐 마느냐보다,
스스로 ‘제안→실행→성공’ 사이클을 두세 번 돌려보는 게
더 강력한 레버라는 사실을 잊지 말 것.”

Q3. 개발자로서 실력을 키우고, 시장에서 인정받기 위해 어떤 경험을 쌓고 어떻게 관리하면 좋을까요?

“프로덕션까지 직접 올려보는 경험이 매우 큽니다.
개발·배포·운영 전 과정을 맛보면,
데이터가 쌓이고 성능이 나빠질 때까지의 문제 해결 프로세스를 체득하게 되죠.”
– 김희성 님

사이드 프로젝트 vs 회사 실무
- 가장 이상적인 건, “회사의 실제 프로덕션 서비스” 를 초기부터 배포까지 경험해 보는 것입니다.
- 그러나 SI/SM 등 운영 위주 업무를 한다면, 서비스 신설·런칭을 직접 해볼 기회가 적을 수 있으므로, 사이드 프로젝트나 개인 토이 프로젝트를 통해 “런칭·유저 피드백·성능 개선” 미니 버전을 체험해 보라고 조언합니다.
성과 수치화, 지표 관리
- “API 응답 속도를 n초에서 n/2초로 단축했다.”
- “DB에 데이터가 100만 건 쌓일 때까지 부하 테스트했는데, XX 알고리즘으로 교체 후 응답이 30% 빨라졌다.”
- 이런 식으로 수치화해 두면, 면접 때도 구체적으로 어필하기 좋고, 본인 이력서에 설득력 있게 담을 수 있습니다.
회사의 SM 업무에서도 ‘개선 제안’ 해보자
- 예: 자동화 테스트 툴(Jenkins, CI/CD) 도입, 로그 수집/모니터링 시스템 개선, 코드 리뷰 문서화…
- 제안 시 팀이 거부할 수도 있지만, 시도했던 과정만으로도 “주도성을 가진 지원자”임을 보여줍니다.

Q4. 연차가 낮더라도 시장에서 고평가 받는 개발자들의 공통점은 무엇인가요?

“빠른 연봉 인상을 받는 분들을 보면,
대부분 본인이 팀 내 리딩을 하거나,
구조 설계를 주도해 본 케이스가 많았어요.
‘윗사람 지시만 받는 사람이 아니다’라는 확신을 주는 거죠.”
– 김희성 님

김희성 님의 관찰로는 다음 두 가지가 반복해서 보였다고 합니다.

자기 주도 제안 습관
- 기존 업무 외 ‘개선 티켓’을 스스로 만들고, 구현·배포까지 책임지는 모습이 내부 승인을 확 끌어올렸다는 예시가 자주 언급됐습니다.
- 팀 내에서 신규 시스템을 아키텍처 설계하고, 필요한 업무 티켓을 나누어 할당하며, 전체 일정을 관리하는 역할을 해본다면, 자연스럽게 리더십과 책임감을 검증받게 됩니다.
- 이렇게 “메인 설계자”가 되면, 회사 밖에서도 “이 사람은 단순히 요구사항만 수행하는 개발자가 아니다” 라고 인정받게 됩니다.

작은 리딩 경험
- 3~4년 차 때부터 “내가 맡은 서비스를 성능·안정성 측면에서 어떻게 개선할 수 있을까?” 를 끊임없이 고민해 본 이들은,
- 인터뷰 때도 “장애 대응을 어떻게 했고, 어떤 지표를 수집해 개선했나”를 스토리 있게 말할 수 있습니다.
- 김희성 님은 “결국 면접관은 그 ‘스토리’에 감탄해서 연봉을 높게 제안하는 것”이라며, “연차보다 문제 해결 사례가 중요한 세상”임을 강조했습니다.
- 주니어 한두 명이라도 코드 리뷰·교육을 해본 경력은 “작은 조직에서도 팀을 굴려 봤다”는 신호로 작동할 수도 있다고 말씀하셨구요.

“결국 ‘이 사람을 믿고 일을 던질 수 있나?’ 에
답을 내놓을 수 있는 사람,
연차보다 ‘리스크 없이 맡길 수 있음’을
증명하는 스토리가 핵심인 듯 하네요.

Q5. 삼성SDS, 쿠팡, 42dot 등 회사별로 주니어(미들급) 개발자 채용 시 중요하게 보는 요소는?

“주니어일수록 무엇을 해봤냐도 중요하지만,
‘왜 이런 기술을 택했고, 문제를 어떻게 해결했는가’
그 태도를 더 많이 본다.”
– 김희성 님

SI/SM 위주의 보수적 환경 - 삼성SDS 초반 조직
- 실험적 기술 도입이 쉽지 않아 도전 의식이 약해지기 쉬움.
- 그럼에도 불구하고, “VOC 처리 외에 무엇을 더 해봤는지?” 가 인터뷰에서 차별화 포인트.
대규모 트래픽 & 빠른 코드 리뷰 문화 - 쿠팡
- 면접 때 라이브 코딩 2번을 거치며, 실전 같은 문제 해결과 아키텍처 디자인을 물어봄.
- “자료구조·DB 설계를 어떻게 하겠는가?” 식의 심층 질문.
- 주니어라도 “자기가 만든 설계를 논리적으로 설명할 수 있나?”를 평가.
스타트업·개발 주도성 - 42dot
- 자율주행·AI라는 특수 도메인이지만, 웹 백엔드 영역은 실무형 구현을 보는 편.
- “네가 직접 문제를 발견하고 해결책을 제안해 본 경험이 있는가?”를 특히 중시한다고 합니다.
- 어떤 면접에서는 스프링 프로젝트를 제로 베이스에서 띄워 API를 만드는 라이브 코딩을 시키기도 함.

결론적으로…

김희성 님은 전반적으로 “기술과 커리어 선택에 있어, 본인이 왜 이걸 택했는지 명확하게 알고 있어야 한다” 는 얘기를 여러 번 강조하셨습니다.

이직 타이밍에 대해서도, “환경이 부족하다고 느끼면 사이드 프로젝트로 보충하거나, 지금 회사에서 해볼 수 있는 개선을 먼저 시도해 보는 게 좋다. 그래도 제한이 많으면 이직을 고민해 볼 수 있다.” 정도의 유연한 시각을 가지신 듯합니다.

“Why를 묻고, 수치로 증명하며, 제안부터 실행까지 책임지는 사람.
그게 김희성 님이 말한 ‘고평가 개발자’의 공통 DNA였습니다.

기타 자유 질문 & TMI

이 섹션은 밋업 후반부에 자유롭게 오간 대화 내용을 간추려, 간단한 ‘질문-답변’ 형식으로 정리한 것입니다. 회사 복지부터 개인 커리어 이력 관리, 목표 설정 등에 대해 자연스럽게 이야기가 오갔습니다.

Q1. 포티투닷(42dot) 회사 분위기와 복지는 어떤가요?

“주니어보다는 네이버·카카오·삼성 등 시니어·미들급 인력이 많다. 반쯤 스타트업 같지만, 현대차 자회사이기도 해서 안정적 자본이 뒷받침되는 편이다.”
“매달 리프레시 휴가를 하루씩 쓸 수 있고, 주 2회 재택과 자율출퇴근제 덕분에 근무 환경은 상당히 자유로운 편이다.”
“ 문화적으로는 기술에 대한 적극적인 의견 제시와 코드 리뷰, 스터디 등 자기주도적이고 진취적인 분위기가 있다."

Q2. 포티투닷은 도메인 특성상 알고리즘 역량이 필수인가요?

“특정 부서들은 확실히 그런 것 같다. 예를 들어, 자동차·자율주행 관련한 업무에서는 알고리즘 역량이 많이 요구되는 것 같기도. 웹 백엔드 업무와 같은 다른 일반 IT 회사에서 요구하는 백엔드 역량과 크게 다르지 않은 부서들도 있다."

Q3. 이력서는 어떤 주기로 업데이트하면 좋을까요?

“SDS처럼 대기업은 연 1~2회 성과평가 시즌마다 ‘자기소개서’ 비슷한 걸 작성하게 되는데, 그 문서를 잘 백업해 두면 자연스럽게 이력서 갱신이 된다.”
“소규모 회사라면 1년에 한 번 정도 스스로 업무 성과, 기술 스택 활용 사례를 정리해 두는 습관이 좋다.”
“링크드인 프로필도 틈틈이 업데이트해 놓으면, 이직 제안이 들어올 때 빠르게 대응 가능하다.”

Q4. 삼성SDS→쿠팡→42dot 순서로 이직하신 결정적 이유가 있었나요?

“SDS 시절엔 SM·SI 조직이라 새로운 기술을 도입하기가 어려웠고, 사내 코딩 테스트 강의만 오래 하다 보니 실무 백엔드 경험을 쌓고 싶었다.”
“쿠팡은 대규모 트래픽과 빠른 개발 문화가 매력적이었고, 실제로 코딩 테스트와 라이브 코딩을 여러 번 거쳐 입사했다. 큰 스케일의 시스템을 다루며 성장 폭이 컸다.”
“42dot은 자율주행 분야가 흥미로웠고, 스타트업 문화이지만 현대차 지원이 있어 안정성도 보장되는 점이 매력적이었다. 지금은 백엔드 중심 업무를 하면서도 도메인적으로 AI·자율주행과 인접한 환경을 체감하고 있다.”

Q5. 경력 5년 차쯤 되면 어떤 걸 주의 깊게 고민하며 이직해야 할까요?

“‘회사에서 어떤 역할을 맡고 있고, 주도적으로 뭘 해봤는지’가 5년차 이직 관건이다. 단순 운영 업무만 했다면, 어떻게 개선 제안을 했고 무엇을 직접 실행했는지 보여줄 자료가 필요하다.”
“기술 스택보단, ‘프로젝트에서 문제를 발견하고 해결한 경험’ 을 구체적으로 갖춰두면 좋다. 면접에서도 그 ‘문제 해결 과정’에 대한 스토리를 많이 물어본다.”
“외부 세미나 참여, 사이드 프로젝트 경험 등도 보태면 차별화가 될 수 있다.”

Q6. SM 환경에서 개선 제안이 번번이 받아들여지지 않으면 어떡하죠?

“현실적으로 SM·SI는 위험 부담이 큰 시스템이어서 쉽게 새 기술을 넣기 어려운 경우가 많다. 작은 범위라도 ‘자동화 툴 도입’, ‘로그 시스템 개선’ 같은 부분적 제안을 시도해 보는 게 좋다.”
“실패하거나 거절당해도, 그 시도 과정 자체가 이직할 때 ‘주도적으로 무언가를 해봤다’ 는 근거가 될 수 있다.”
“혹은 사내 TF나 신규 프로젝트 팀을 찾아서 내부 이동을 노려볼 수도 있다. 적극적인 태도가 결국 더 좋은 기회를 만든다.”

Q7. AI 시대에 고민이 많다. 목표나 꿈이 있으신가요?

“AI가 코드를 짜준다고 해서 개발이 사라지진 않을 것 같다. ‘왜 이 로직을 택해야 하는지’ 결정하고 개선 포인트를 찾는 건 여전히 사람 몫이라고 본다.”
“개인적으로는 새 기술에 빠르게 적응하는 걸 최우선 목표로 삼고 있다. ChatGPT나 Copilot을 적극 써보되, 그 결과물을 ‘왜 이게 최적 or 비효율적인가’ 판단할 줄 아는 게 중요하다.”

인사이트 + 회고 + 생각 정리

“AI는 답을 줄 수 있지만, 질문을 던지는 건 인간의 몫이다.”
— 《AI 시대 내 아이의 미래를 바꿀 인재 교육》 p. 190

(그런데 그런가? 질문할 것도 AI한테 질문할 수 있는ㄷ..)

'고연봉 주니어'의 비밀?

최근 개인적으로 가지고 있던 고민 중 하나는 "평범한 환경에서 일하는 3-4년 차 주니어 개발자임에도 불구하고, 남들보다 앞자리 수가 다른 고액 연봉을 받는 사람들의 비밀은 무엇일까?" 였다. 물론, AI 연구자나 해외 명문 출신, 혹은 글로벌 빅테크에서 테이블이 다른 연봉 체계를 받는 분들은 제외. 국내 IT 업계에서 평범한 백엔드 개발자가 시장에서 고평가 받을 수 있다면 그 이유가 궁금했다.

개발자로 일한 지 오래되지는 않았지만, 40살 이전에 나름의 정점을 찍어보고 싶다는 개인적 목표를 갖고 있다. 그게 꼭 연봉만은 아닐 것이다. 또, 단순히 연봉만으로 부자가 될 수 있다고 생각하지도 않는다. 하지만 시장에서 확실히 인정받고 높은 평가를 받으며 일한다는 사실 자체가, 하나의 큰 성취감을 가져다준다고 믿기 때문이다.

김희성 님과의 이번 밋업을 진행하고 돌아보며 이 질문에 대한 답을 어느 정도 정리할 수 있었다.

결국 그만큼의 돈을 받는다는 것은 회사에 그만큼의 가치를 제공하고 있다는 의미다. 즉, 연차는 주니어일지 몰라도 실제로 하고 있는 업무와 책임은 이미 시니어급이라는 뜻이다. 회사에서 주어진 업무를 그냥 잘하는 것을 넘어, 스스로 문제를 발견하고, 해결책을 제안하며, 그 제안을 완전히 자신의 책임 하에 끝까지 주도적으로 이끌어내는 사람들이다. 쉽게 말해, 회사가 "믿고 맡길 수 있는" 사람이 되어 있다는 뜻이다.

저자님은 이런 사람들의 특징을 다음과 같이 표현했다.

"윗사람이 업무의 세부 내용을 몰라도,
아무 문제 없이 완전히 맡길 수 있는 사람이 고평가를 받는다.
연차와 상관없이 그런 사람이 곧 시니어이고,
나아가 리더라고 부를 수 있다."

실제로 그런 고평가 주니어 개발자들은 단순히 주어진 일을 잘 수행하는 사람이 아니라, 끊임없이 "왜(Why)"를 질문하며 스스로 문제를 발견하고 해결하는 사람이다. 업무를 해결하는 과정에서 팀 내부는 물론, 다른 부서와도 적극적으로 협업하며 "일이 되게 하는 사람"이라는 인식을 준다.

이러한 맥락에서 내 개발자로서의 정체성도 재정의할 필요가 있다고 느꼈다. 기존에는 단순히 "문제를 푸는 사람"이라고 스스로를 생각했는데, 이제는 좀 더 적극적으로 "일이 되게 하는 사람"으로 바꾸어야겠다는 생각을 하게 되었다. 단순히 코드 작성이나 문제 해결을 넘어, 업무 전반의 흐름과 협업 관계를 적극적으로 관리하며 결과를 만들어내는 사람이 되어야 한다는 것이다. 그리고 이것이 바로 "직책"이라는 단어가 가진 본래의 의미가 아닐까 싶다.

현업에서 “왜(Why)”를 고민한다는 것

현재 넥슨의 결제팀에서 일하면서도 비슷한 고민을 하는 것 같다. 엊그제 보도된 자료에 따르면 넥슨의 2025년 상반기 매출은 1조 원을 넘었는데, 이 매출의 상당 부분을 차지하는 유저의 결제가 우리 팀이 관리하는 시스템을 거친다. 이 때문에 우리 팀의 모토는 99.999%의 안정성도 아닌 100%의 안정성이다.

김희성 님도 삼성SDS 시절 SI/SM 환경에서 안정성과 보수성에 대해 이야기했는데, 현재 내가 일하는 환경 역시 비슷한 듯싶다. 업무 환경 자체가 보수적이지는 않지만, 안정성 확보를 위해 코드 리뷰, 정식 QA, SE 협업 등 엄격한 절차를 거쳐야 한다. 신규 개발과 레거시 시스템 개선 작업이 빈번히 이루어지고 있지만, 혁신적인 변화를 빠르게 이루기는 현실적으로 쉽지 않다.

이런 환경에서 ‘내가 주도적으로 일한다는 것은 무엇인가’가 계속 고민 포인트였다. 단순히 주어진 요구사항을 구현하는 수준을 넘어서서, 시스템의 기술적 고민과 검토, 영향도 파악까지 철저히 문서화하고 공유하는 과정을 통해 업무를 주도하려고 했다. 최근에는 업무와 시스템에 대한 이해도도 조금씩 늘어나면서, 코드 레벨에서 자잘한 부분(예외 처리, 로깅 개선 등)을 발견해 제안, 실행하여 개선된 사례도 생기기 시작했다.

하지만 진정한 자기주도성을 갖추려면 시스템 전반에 대한 이해도는 물론, 다른 팀 시스템과의 연관성을 고려한 넓은 시야가 필요함을 느끼곤 한다. 무엇보다도 프로덕트에 대한 강력한 오너십이 필요한데, 돌이켜보면 이 오너십이 초반에는 잘 생기지 않았던 것 같다. 남이 만들어 놓은 레거시 시스템이 대부분이었기 때문이다. 그런데 하나씩 직접 손대고 개선해나가면서 자연스럽게 오너십이 생기는 경험도 했다. 결국 개발자의 진짜 역량은 코드 실력처럼 눈에 보이는 것만이 아니라, 보이지 않는 부분에 더 많이 있는 것 같다. 호기심, 오너십, 자기주도 실행력, 그리고 책임감 같은 역량은 AI가 결코 대신해 줄 수 없다.

진정한 의미에서의 자기주도성이란 정말 무엇일까? 책 『AI 시대 내 아이의 미래를 바꿀 인재 교육』에서 이렇게 말한다.

"자기주도성, 이제는 새로운 정의가 필요하다. AI 시대의 자기주도성은 단순히 주어진 과제를 성실히 수행하거나 스스로 공부하는 수준을 넘어서야 한다. 스스로 삶의 방향을 설정하고, 목표를 계획하며, 그 목표를 이루기 위해 필요한 지식과 기술을 주도적으로 배우고 활용하는 능력, 이것이 진짜 자기주도성이다." (p. 180)

내가 현업에서 “왜(Why)”를 고민한다는 것은 단순히 코드를 잘 짜고 문제를 해결하는 수준을 넘어, 프로덕트에 대한 진정한 오너십을 갖고 업무 전반의 흐름을 이해하고 주도적으로 관리하는 것을 의미한다. 이런 오너십은 처음부터 쉽게 갖출 수 있는 것이 아니라, 내가 맡은 시스템에 점점 더 깊이 관여하고 책임을 질 때 비로소 생기는 것이라고 생각한다.

AI 시대, 지식 패러다임이 바뀐다 (?!)

밋업 후 저녁 식사 자리에서 저자님이 "대학생들이 AI를 공부에 어떻게 활용하면 좋을지 묻는데, 여러분은 어떻게 답하겠는가?"라는 질문을 던졌다. 다양한 의견이 오갔는데, 나는 이렇게 대답했다.

"오히려 AI를 더 많이 잘 써야 한다고 생각해요."

"지식을 소유한다는 시대는 끝난 것 같아요. 과거 우리가 '수학의 정석'을 펼쳐놓고 하나씩 개념을 익히고 문제를 푸는 방식의 학습은, AI 시대에는 근본적으로 바뀌지 않을까요? 이제 중요한 것은 내가 가진 지식의 총량이 아니라, 얼마나 빠르게 필요한 지식을 찾고, 조합하고, 활용할 수 있는지라고 생각합니다."

책 『AI 시대 내 아이의 미래를 바꿀 인재 교육』에서는 다음과 같이 이야기한다.

"AI 시대의 자기주도성, 진짜 경쟁력은 어디에서 오는가? 스스로 질문을 던지고 답을 찾는 능력에서 시작된다. AI는 답을 줄 수 있지만, 질문을 던지는 건 인간의 몫이다. 예를 들어, 아이가 챗GPT에게 '공룡은 왜 멸종했나요?'라고 묻고 답을 얻었다고 치자. 여기서 멈추면 AI가 해준 숙제를 받아 적은 것과 다를 게 없다. 중요한 건 그다음이다. 왜 이 질문을 던졌는지, 답에서 무엇이 흥미로운지, 더 알아보고 싶은 게 무엇인지 스스로 생각하고 확장해 나가야 한다. 결국, AI는 공을 던져주는 역할을 할 뿐이고, 그 공을 가지고 어떻게 경기할지는 인간의 몫이다." (p.190~191)

그러니까, 이게 핵심인 거 아닐까?

AI에게 질문을 하고 답을 구하는 것 OK. 학습을 할 때 AI를 쓰는 것 OK. 그런데... 쟁점은 그게 아니라, AI가 준 정보를 어떻게 내 것으로 만들어갈 수 있느냐는 것이다. 단지 AI가 준 답을 그대로 옮겨 적는 것에 그치지 않고, 그 답에서 시작해 다시 질문을 던지고, 스스로 의미를 발견하고, 더 나은 방식으로 확장할 수 있어야 진정한 자기주도적 학습이 이루어지는 것이다.

즉, AI가 문제 해결에 도움을 준다는 사실은 분명하지만, ‘어떤 질문을 던지고, 그 답을 어떻게 재해석·적용하느냐’ 가 인간의 몫인 셈이다.

책에서 예로 든 공룡의 멸종 사례처럼, 학생이 AI에게 던진 질문에서 멈추지 않고 더 나아가 "왜 이런 질문을 하게 되었을까?" 혹은 "이 멸종에서 우리가 얻을 수 있는 교훈은 무엇일까?" 같은 추가 질문을 계속 던져야만 진짜 의미 있는 학습이 된다.

이제 더 이상 중요한 것은 지식을 얼마나 내 머릿속에 소유했느냐가 아니다. 이미 지식은 어디에나 널려 있고, 언제든 AI가 가져다줄 수 있다. 중요한 건 그런 지식을 빠르게 찾아내어 조합하고, 내 문제를 해결하는 데 유의미하게 활용하는 능력이다.

일론 머스크는 베이징 TV와의 인터뷰에서 문제해결 학습법에 대해 흥미로운 예시를 들었다.

"문제 해결 방법을 가르치는 것, 그리고 도구가 아니라 문제에 대해 가르치는 게 중요합니다. 예를 들어, 엔진 작동법을 사람들에게 가르친다고 해 봅시다. 전통적 접근법은 '드라이버와 스패너에 대한 모든 것을 가르쳐야 하지만 이건 너무 어려운 방법입니다. 훨씬 더 나은 방법은 이렇습니다. '여기 엔진이 있는데, 이제 이걸 분해해 볼까요? 아, 드라이버가 필요하네요?' 이때 두 가지 중요한 일이 일어납니다. 공구들의 관련성이 분명해지고, 학생들은 학습 목적을 깨닫게 됩니다. 자신이 뭘 배우는지 인지하는 것이죠." (p.170)

그러니까, “ChatGPT를 잘 쓰는 법”이 중요한 게 아니라, 어떤 문제를 풀고자 하는지가 명확해야 AI를 쓰는 목적과 배움이 생긴다는 것이다. 마치 “드라이버가 필요한 이유”를 엔진 분해 과정에서 깨닫듯이, AI가 필요한 이유를 구체적 문제 상황에서 자각해야 한다는 말이다.

AI 시대에 필요한 것은 단편적 지식이 아니라, 주어진 문제를 이해하고 그 문제를 해결하는 과정에서 필요한 도구와 지식을 능숙하게 활용하는 능력이다. 컴퓨터 과학계의 대가인 페드로 도밍고스 워싱턴주립대 명예교수 역시 AI 시대에 대해 이렇게 전망했다.

"미래는 사람과 AI가 대결하는 구도가 아니라, AI를 능숙하게 다루는 사람과 그렇지 못한 사람의 구도가 될 것이다. AI 활용 능력이 직업과 기회를 좌우하는 중요한 요소가 될 것이다." (p.26)

즉, 앞으로의 학습과 성장의 방향은 AI를 단순히 잘 이용하는 것을 넘어, AI와 끊임없이 상호작용하며 자신의 사고를 깊게 확장하고, 질문을 던지며 지속적으로 성장하는 데 있다. 단순히 AI가 주는 답을 그대로 받아 적는 것이 아니라, AI의 답을 발판 삼아 끊임없이 더 깊은 'Why'를 던지는 것. 이것이 새로운 시대의 지식 패러다임일 것이다.

개발자 == “왜”를 계속 물을 수 있는 직업 + AI 시대의 개발자 버프 (혹은 진화)

이번 밋업에서 가장 많이 들은 단어는 단연코 "왜(Why)" 였다. 김희성 님이 강조한 핵심 키워드가 바로 "Why를 끊임없이 던질 수 있는 사람이 결국 인정받는다" 였기 때문이다. 그런데 이 말을 듣고 나니, 한 가지 깨달음이 생겼다. 내가 개발자라는 직업에서 "지속 가능성"을 찾을 수 있다면, 그 이유도 바로 이 "왜"를 계속 질문할 수 있는 일이기 때문일지 모르겠다는 생각이다.

세상에는 아무리 질문을 던져도 답을 찾기 어려운 문제가 너무나 많다. 개인적인 예로, 나는 25년 넘게 편두통을 앓고 있는데, 수십 권의 책과 논문, 온갖 병원을 돌아다니며 '편두통 유발 인자라는 CGRP 신경 펩타이드가, 그러니까 왜 생기냐는 것이다'를 물었지만 명쾌한 답은 아직도 찾을 수가 없다. ChatGPT o3 심층 리서치도 이건 답을 못 준다. 또, "우주 먼지의 현자타임즈" 같은 유튜브 채널에서 다루는 천체 물리학이나 "BODA"의 철학 팟캐스트에서 즐겨 다루는 "타고난 운명을 나의 의지로 바꿀 수 있을까? (자유의지 vs 결정론)" 과 같이 명확한 정답이 없는 질문들 역시 많다.

그런데 개발이라는 영역은, 적어도 이러한 막막함과는 다른 감각이 있다.

분명히 정해진 정답은 없을지라도, 실험과 데이터, 코드라는 눈에 보이는 증거를 통해 명확히 개선되는 결과를 확인할 수 있기 때문이다. 그러므로 "왜?"라는 질문을 계속 던지고, 그에 대한 해답을 찾아가는 과정에서의 성장과 성취감을 느낄 수 있다.

창의성의 본질에 대해 일곱 살의 한 소녀가 이렇게 말했다고 한다.

“창의성이란 처음 생각한 것을 넘어서서 더 많은 것을 생각하는 것이다.”

스탠포드 대학의 제레미 어틀리 교수는 다음과 같은 영상에서 이 말을 창의성에 대한 가장 탁월한 정의라고 평하며, 이것이 인간이 가지는 고정관념이나 한계에서 벗어나 지속적으로 더 나은 해결책을 찾아가는 과정임을 강조했다.

https://youtu.be/rSS5yM74zeo?si=c1YWZyQVtHjTpqac

어틀리 교수는 AI를 단순한 도구로 바라보는 사람과 동료로 바라보는 사람의 결과물이 완전히 달라진다고 설명했다.

AI를 그저 “답을 주는 도구”가 아니라 “함께 문제를 풀어가는 협력자”로 받아들이는 순간, 문제를 해결하는 방식이 근본적으로 바뀐다는 것이다. 예를 들어, AI가 준 답변이 만족스럽지 않을 때, 단순히 그 도구의 한계를 탓하는 대신 동료에게 피드백을 주듯 AI에게 추가 정보를 주고 질문을 던지면서 더 나은 결과를 도출할 수 있다는 이야기다.

이런 예시를 들었다.

“AI에게 직접 '이 질문을 어떻게 하면 더 잘 던질 수 있을까?' 라고 묻는 식으로 AI를 활용하는 게 가능하다. 이런 접근법은 엑셀에게 엑셀 사용법을 물어보거나, 이메일에게 이메일 사용법을 묻는 것과는 전혀 다르다. AI는 그 스스로가 자신의 사용법을 가르쳐줄 수 있다. AI를 ‘사용’하는 게 아니라 ‘함께 일하는’ 협력자로 바라볼 때, 전혀 새로운 가능성이 열린다.”

이는 책 『AI시대 창의적 인간 - 인간은 어떻게 인공지능과 공존할 것인가?』에서 저자가 주장하는 "크리지먼트"와 유사한 개념이다.

크리지먼트는 창의성을 실제로 만들어 내는 것이라기보다는 창의성을 관리하는 개념입니다. 창의적인 결과물을 만들어 내는 각 분야의
A들이 고도화되고 대중화될수록 더욱 절실하게 필요한 개념이자 능력입니다. 이는 마치 실무자가 관리자로 넘어가는 것과 같은 획기적인 전환이죠. 혹은 선수가 감독이나 코치가 되는 변화와도 비슷하고요. (p. 197)

그동안 창의성을 논할 때 우리는 플레이어로서의 창의성, 즉 '어떻게 창의적일 것인가'라는 기술적인 측면에만 집중했습니다.

이제는 디렉터로서의 창의성, 즉 결과물을 어떻게 배치하고, 어떻게 각각의 창의적인 퍼포먼스들을 활용해서 전체적인 효과를 극대화할 것인가'를 고민해야 합니다. 그러려면 기존의 창의성 개발 방법이 아닌, 다른 방법으로 디렉팅 능력을 향상해야 하죠. (p. 199)

이러한 관점의 전환은 앞서 언급한 "일이 되게 하는 사람으로서의 개발자"와도 맞닿는 지점이 있지 않을까?

개발자의 전문성이라는 것도 마찬가지로 재정의의 영역일 수 있겠다. 과거에는 개발자의 전문성을 "코드를 얼마나 효율적으로 짜는가", "어떤 기술 스택을 능숙하게 다루는가"와 같은 기술적 측면에서 좀 더 중점을 두었다면, 앞으로는 그보다 더 넓은 차원으로 확장되어야 한다는 니즈를 받고 있는 것은 아닌지. 그러니까, 물론, 현재도 그렇지만 이런 요구사항이 앞으로 더욱 심화되지 않을까? 단순히 기술적 문제 해결자가 아니라, 제품과 비즈니스의 전체적인 맥락을 이해하고, 다양한 영역 간의 소통과 협업을 주도하며 최적의 결과를 만들어낼 수 있는 사람으로 진화한다면, 개발을 비롯해서 비즈니스를 둘러싼 구분된 직무들의 경계가 점차 흐려질 수 있을 것이다.

결국, AI가 가져오는 변화는 개발자에게 더 큰 기회를 제공하는 동시에, 더 큰 책임과 역할을 요구하는 것이다. 이제 개발자는 AI라는 강력한 이질적 지능(Alien Intelligence)와 협력하며 기존의 역할을 넘어 "문제를 해결하는 사람"에서 "문제를 정의하고, 더 나은 문제를 발견해 내는 사람"으로 성장해야 할 때인 듯하다.

넥스트 스텝과 액션 아이템

한편으론, “개발” 이라는 일을 10년, 20년 넘게 한다고 해서 모두가 자동으로 시니어가 되는 건 아닐 것이다. 그렇다면 넥스트 스텝은 무엇인가? 이제 다음과 같이 정리해 볼 수 있을 것 같다.

문제를 단순히 푸는 것 이상으로, 문제 자체를 발굴하고, 구조화하며, 결과물을 책임지고, 주변을 리딩하는 데 탁월하기.
단순히 “코드가 제대로 돌아가는지”만 보는 것이 아니라, “왜 이렇게 해야 하고, 이것으로 회사와 고객은 어떤 가치를 얻게 되는지, 필요한 협업과 커뮤니케이션은 무엇인지”를 깊이 고민하기.
호기심, 실행력, 오너십, 그리고 끊임없이 “왜(Why)”를 놓치지 않는 태도.

그리고 이런 액션 아이템도 설정해 보자.

💡 액션 아이템

"왜?"를 일상화하기
- 주어진 업무라도 무조건 실행부터 하지 말고, 최소한 한 번은 스스로에게 물어보자.
  - “이건 왜 이렇게 구현되어 있지?”
  - “지금보다 더 나은 방법은 없을까?”
  - “이 방식이 고객과 회사에 정말 가치를 줄 수 있나?”
개선 아이디어의 적극적 공유와 실행
- 아이디어가 떠오르면 문서화하고 팀원·리더와 적극 공유하기.
- 작은 것이라도 실제 배포까지 주도하여, 그 과정에서 협업을 경험하고 최종적으로 “이 개선으로 무엇이 달라졌나?”를 팀과 함께 회고하기.
- 이를 습관화하여, 조직 내에서 “일을 주도적으로 끝까지 책임지는 사람”으로서의 신뢰를 얻기.
기술 선택에 있어 명확한 Why를 문서화
- 지금 사용하는 도구와 라이브러리의 사용 목적과 근거를 정리하고, 더 나은 대안이 있는지 정기적으로 리서치하기.
- 새로운 제안 시 장점, 비용, 팀 임팩트를 수치화·문서화하여 팀에 공유하고, 기술적 설득력을 높이기.
AI와 적극적으로 협력하는 방법 배우기
- AI를 단순한 도구가 아닌, 협력자로 인식하여, 업무의 효율성과 창의성을 극대화하는 방법을 적극적으로 탐색하고 시도하기.
- AI에게 직접 “어떻게 하면 더 잘 협력할 수 있을지” 물어보고 피드백을 받아 나만의 AI 활용 전략을 정기적으로 업데이트하기.
호기심에 미치기 (Deep Dive)
- 팀의 제품·기술·사업 도메인 전반에 대해 철저히 공부하고, 조금이라도 모르는 부분이 나오면 즉시 리서치하고 공부하기.
- 질문을 두려워하지 않고, 내가 궁금한 모든 것을 적극적으로 팀원이나 주변 전문가들에게 물어보기.

저작자표시 비영리 변경금지 (새창열림)

'회고' 카테고리의 다른 글

2024년 회고 - 연대와 성장의 경험들 (0)	2025.01.01
대기업과 스타트업, 보수와 진보, 그리고 정치적 무관심, 내란과 민주주의에 대한 소회 (feat. 토요일 밤에 윤석열 탄핵 🎶) (3)	2024.12.14
GPT 복붙만으로 프로그램을 만들 수 있을까? (feat. AI 시대의 개발자, 기묘한 질문들, 그리고 낯설고도 친절한 어떤 존재에 대해서) (1)	2024.10.26
항해 플러스 백엔드 5기 수료 회고 - 여름 방학 경험치 이벤트가 끝나면? (9)	2024.08.28
2024년 8월 3-4주차 내가 깨야했던 퀘스트에 대해서 (feat. 패시브 스킬 회고) (0)	2024.08.26

《코딩 테스트 합격자 되기: 자바편》 김희성 저자 밋업 스케치 – “왜(Why)를 묻는 개발자”의 성장 전략 + 2025 1H 개인적 회고