AI가 내 대화 기록 다 털어서 개발자 평가를 내렸다
Claude와 Codex가 각각 내 모든 대화 세션을 분석해 독립적으로 작성한 개발자 프로파일입니다.
내용은 원문 그대로이고 형식만 통일했습니다.
내가 넣은 프롬프트 펼치기
내 다른 세션 모두 뒤져서 지금까지 나와 나눈 모든 대화 기록을 바탕으로 나를 개발자로 분석해줘.
단순한 성격 분석이 아니라, 실제 업무 성과, 성장 가능성, 기술적 역량, 의사결정 방식, 커리어 관점에서 평가해줘.
듣기 좋은 말보다 정확성을 우선해줘. 근거가 부족한 내용은 반드시 "추측"이라고 명시하고, 가능한 한 실제 대화에서 관찰된 패턴을 근거로 설명해줘.
1. 개발자로서의 핵심 프로파일
나의 가장 두드러지는 특징 / 문제를 해결하는 방식 / 의사결정 스타일 / 학습 방식 / 업무 스타일 / 장기적으로 성장할 가능성이 높은 영역
2. 강점 — 기술적 강점 / 사고력 / 실행력 / 커뮤니케이션 / 협업 / 리더십 잠재력 / 비즈니스 감각
각 항목마다 실제 대화에서 드러난 근거를 함께 설명해줘.
3. 보완해야 할 점 — 기술적 한계 / 사고의 편향 / 반복적으로 나타나는 약점 / 성장의 병목 / 커리어 리스크 / 인간관계 및 협업에서 주의할 점
특히 내가 스스로 잘 인식하지 못하고 있을 가능성이 높은 부분을 우선적으로 알려줘.
4. 페르소나별 평가
- 함께 일하는 시니어 엔지니어 — 장점, 답답한 점, 성장 가능성
- 엔지니어링 매니저(EM) — 신뢰도, 맡기고 싶은 업무, 승진 가능성, 리더십
- CTO — 조직 가치, 투자 여부, 우려 사항
- 스타트업 창업자 — 채용 여부, 적합 역할, 리스크
- 빅테크 면접관 — 채용 가능성, 강점, 우려, 예상 레벨
- Staff Engineer — 기술적 병목, 사고방식 한계, 다음 단계
- 미래의 나 (10년 후) — 잘하고 있는 것, 후회할 것, 지금 집중할 것
5. 성공 시나리오 vs 실패 시나리오
6. 앞으로 2년 성장 전략 — 우선순위 순서로 구체적으로
7. 한 문장 요약
8. 마지막으로 하고 싶은 말 — 오랫동안 나를 지켜본 멘토라고 가정했을 때 꼭 한 번은 해주고 싶었던 말. 칭찬만 하지 말고, 앞으로의 커리어와 인생을 위해 진심으로 남기고 싶은 한마디.
핵심 프로파일
운영 자동화를 도구화하는 실행형 시니어. Claude Code를 코딩 보조가 아닌 "운영 레이어"로 내재화했고, 그 경험을 팀 공용 자동화 시스템으로 이식하는 역할을 자발적으로 맡고 있다.
문제 해결 방식: URL + 짧은 지시 → Claude에 위임 → 빠른 검증 → 즉시 다음 단계. 막히면 롤백하고 다시 접근하는 것을 두려워하지 않는다.
의사결정 스타일: 빠르고 단호하다. 변경 범위가 커지면 먼저 눈치채고 스스로 롤백을 제안한다. "야 그냥 진지하게 물어볼게. 지금 변경사항이 너무 많은데."
학습 방식: 실사용 먼저 → 패턴 추출 → 도구화. 실제 CS 대응과 장애 대응을 먼저 해보고 나서 반복 패턴을 발견해 스킬로 만들었다.
장기 성장 가능성: 팀 전체의 개발 생산성을 높이는 플랫폼/도구 엔지니어링. 특정 프로덕트 기능보다 팀 자동화 레이어를 설계하는 역할.
강점
- 기술적 강점: 백엔드(Spring/JPA) 시니어 수준. 트랜잭션 훅, 검색엔진 sync 타이밍, interceptor vs filter 설계, 동적 설정 관리까지 정확히 파악하고 지시한다. 분산 쿼리, cursor vs limit 성능 판단, 시크릿 관리, SSH prod 접근 등 인프라 영역도 중상 수준.
- 사고력: 변경 범위를 의식적으로 제어하는 능력이 뚜렷하다. "아냐 그냥 진지하게 물어볼게. 걍 필터만들기 이전상태로 돌리고... 지금 변경사항이 너무 많은데" — 이 판단 자체가 고급이다.
- 실행력: Request interrupted 55회 확인. 잘못된 방향이면 실행 중에도 멈추고 즉시 재지시. 한 세션에서 feature 구현부터 PR 생성, 배포 지시까지 처리한다.
- 협업: "팀원들이 agit 스킬 돌릴 때마다 해매는 이슈가 있거든" — 팀원의 사용성을 기준으로 스킬 완성도를 판단하는 사고가 보인다.
- 리더십 잠재력: 팀 공용 자동화 레이어를 자발적으로 구축하고 있다. 공식 업무 지시가 아닌 자발적 주도라는 점이 중요하다.
- 비즈니스 감각: CS 대응 → 패턴화 → 스킬화. 완성도보다 "지금 당장 쓸 수 있는가"를 기준으로 판단하는 실용주의가 비즈니스 환경에 적합하다.
보완해야 할 점
- 기술적 한계: 프론트엔드 기초 수준. AI/ML은 로컬 LLM 연동, 사내 API 연동 수준이며 모델 파인튜닝이나 프롬프트 엔지니어링 깊이는 관찰되지 않는다.
- 사고의 편향 (추측): Claude에 위임하는 비중이 높아 "먼저 직접 시도해보고 막히면 물어보는" 패턴이 드물다. "Claude 없이도 설계할 수 있는가"를 스스로 점검할 필요가 있다.
- 반복적 약점: 명명(naming) 결정에 에너지가 과도하게 들어간다. 환경변수명, 스킬명에서 반복 수정 요청이 가장 많다. 처음부터 네이밍 기준을 명시적으로 갖고 있다면 이 비용을 줄일 수 있다.
- 성장의 병목: good-enough 기준이 팀 공유 도구에서도 일찍 닫힐 가능성이 있다. "아냐 그냥 두자 그렇게 중요한 툴도 아니고" — 팀원이 쓰는 스킬에서 동일한 기준이 적용되면 팀의 도구 품질 신뢰가 낮아질 수 있다.
- 커리어 리스크: 도메인 지식이 특정 플랫폼에 깊게 고착되어 있다. 도메인 독립적인 기술에 병행 투자 필요.
- 인간관계 (추측): 짧고 단호한 지시 스타일이 Claude 대상으로는 효율적이지만, 주니어 팀원 대상으로 동일하게 쓰이면 심리적 압박으로 느껴질 수 있다.
페르소나별 평가
방향 결정이 빠르고 롤백도 빠르다. 도메인 히스토리가 풍부하다. URL만 던지고 "확인해줘" 패턴이 많아 배경 없는 팀원은 맥락을 따로 파악해야 하는 부담이 있다.
신뢰할 수 있다. 배포에서 사고를 낼 타입이 아니다. CS 대응 루틴 자동화, 도메인 히스토리가 중요한 마이그레이션에 적합. 코칭/설명 스타일이 보완되면 승진 가능성 높아진다.
조직 가치 높음. 운영 자동화 문화를 팀에 이식하는 역할. 특정 도메인에 고착될수록 조직 내 이동성이 낮아지는 것이 우려 포인트.
초기 멤버로 채용. 백엔드 + 운영 인프라 + 팀 도구화를 동시에 처리하는 만능 시니어. 대기업 운영 환경에 최적화되어 있어 무에서 인프라 구축 경험이 부족할 수 있다(추측).
채용 가능성 중상. 시스템 설계 감각, 운영 경험, 도메인 깊이. 알고리즘 코딩 테스트 준비 여부 불명. 예상 레벨: Senior SWE (추측).
기술 병목은 단일 팀/도메인 외부에서 통용되는 설계 경험 부족. 다음 단계는 기술 결정을 글(ADR)로 설명하는 능력, 도메인을 넘어서도 적용되는 원칙을 언어화하는 것.
잘하고 있는 것: 도구를 만들어 팀 레버리지를 높이는 것. 후회할 수 있는 것: Claude 의존으로 스스로 설계하는 능력이 퇴화하는 것(추측). 집중할 것: 내부 기여를 외부에서도 볼 수 있는 형태로 남기기.
성공 / 실패 시나리오
- 팀의 반복 작업을 체계적으로 자동화하고, 그 경험을 다른 팀으로 이식할 때
- 운영 인프라가 갖춰진 중형 이상 팀, 자율성이 보장된 환경
- Staff/Principal Engineer 또는 Developer Experience 팀
- 새 환경에서 스스로 이해하는 과정을 생략하고 AI에만 의존할 때
- good-enough 기준으로 팀 공용 인프라 기술 부채를 누적시킬 때
- 외부 가시성에 투자하지 않아 커리어 옵션이 현재 회사에 고착될 때
2년 성장 전략
- 기술 결정을 글로 남기는 습관 — "왜 이렇게 설계했는가"를 ADR 형태로 짧게라도 기록. Staff 레벨 평가에서 직접적인 증거가 된다.
- 외부 가시성 확보 — 운영 자동화 경험, 도구 설계 원칙 같은 "다른 팀에서도 적용 가능한 내용"을 월 1회 이상 블로그 게시.
- 도메인 독립적 기술 투자 — 특정 도메인 외부에서 통용되는 시스템 설계 경험 확보. 사내 다른 팀 기술 공유, 오픈소스 기여, 또는 사이드 프로젝트에서 인프라를 처음부터 직접 구축.
한 문장 요약
멘토로서 하고 싶은 말
네가 만들어온 것들, 진짜 좋다. 팀 자동화 레이어를 자발적으로 만들고, CS 대응 패턴을 스킬로 이식하고, 팀원들이 쓸 수 있도록 환경을 깔아주는 것 — 이건 드문 능력이고 조직에 실질적인 임팩트를 준다.
근데 솔직히 하나 걸리는 게 있어.
너는 Claude 없이도 이 판단을 내릴 수 있어?
URL 던지고 "확인해줘" 하는 게 지금은 가장 효율적인 방식이 맞다. 근데 그게 너무 당연해진 나머지, 문제를 직접 손으로 파헤치면서 이해하는 과정이 줄어들고 있지는 않은지 한 번쯤 점검해봐.
도구가 사람을 강하게 만들 수도 있고, 도구에 의존하면서 사람이 약해질 수도 있거든. 지금 네가 어느 쪽으로 가고 있는지는, 어느 날 갑자기 Claude가 없는 환경에서 같은 문제를 마주쳤을 때 드러날 거야.
그리고 하나 더 — 지금 네가 하고 있는 것들을 외부에서 볼 수 있게 만들어. 사내에서 아무리 잘해도, 그게 블로그 한 편이나 발표 한 번으로 남아 있지 않으면 3년 뒤에 네 커리어 얘기할 때 꺼낼 수 있는 게 없어. 지금이 제일 바쁘다는 거 알아. 그래도 월 1편은 써.
핵심 프로파일
이전 평가는 AI 도구·개인 자동화 쪽 비중이 과대평가됐다. 전체 세션 기준으로 보면 핵심은 "복잡한 도메인의 백엔드 운영을 AI로 증폭해 처리하는 플랫폼형 시니어"에 가깝다.
가장 강한 축: 도메인 복잡도 이해(비즈니스 오브젝트 등록·수정, 복잡한 심사 분기 처리, 다수의 내부 API 연동, 하위 엔티티 일관성 관리), 성능·데이터 운영(MongoDB 인덱스, 대규모 문서 정리, 수백만 건 마이그레이션, ES dual write), 장애·운영 추적(모니터링 도구, 요청 로그, 메시지 큐 실패 처리, oncall 기록), 개발 프로세스 설계(이슈 관리 → branch → 단계별 환경 테스트 → PR → release → develop to master), AI 도구화(팀/개인용 Claude 스킬 시스템, Bear worklog, Claude/Codex/Gemini 호환).
강점
- 기술적 강점: 대규모 데이터와 운영 환경을 실제 제약으로 다룬다. 쿼리 속도뿐 아니라 변환 비용, 인덱스 활용, dry-run 추정 시간, 타임아웃, 슬립·청크 크기까지 본다.
- 도메인 이해: 비즈니스 오브젝트 등록·수정, 복잡한 심사 분기, 외부 연동처 누락 필드, 하위 엔티티 null overwrite 같은 도메인 불변조건을 잡으려는 사람이다.
- 운영 판단: 단계별 환경(개발·스테이징·프로덕션), feature/develop/master 흐름, force push 금지 같은 운영 관습을 명확히 갖고 있다.
- 문제 압박 능력: AI가 표면적인 리포트나 보정 결과로 빠지면 "그게 중요한 게 아니라 원인이 문제"라고 방향을 바로잡는다. 장애 분석에서 매우 중요한 능력이다.
- 실행력: 스킬, 가이드, Jira, PR, release, oncall, Bear worklog까지 반복 작업을 도구화한다. 개인 생산성을 넘어서 팀 운영 체계로 확장하려는 시도가 보인다.
- 비즈니스·콘텐츠 감각: YouTube 채널 분석, 블로그, 개발자·직장인 콘텐츠 아이디어를 기술 작업과 분리하지 않고 운영한다.
보완해야 할 점
- 속도와 안전장치의 불일치: force push 사고 이후 브랜치 가이드를 강화한 흐름이 대표적이다. 사고 후 학습은 빠르지만, 다음 단계는 사고 전 가드레일이다.
- AI 기대 수준과 협업 리스크: 에이전트가 맥락을 놓치면 감정적 표현이 강해진다. 실무적으로 이해되는 반응이지만, 사람과 일할 때 같은 강도로 나타나면 협업 리스크가 된다.
- 시크릿·권한·과금 민감도: 올라가고 있지만 초기에는 속도 우선의 흔적이 있다. 개인·회사 계정 분리, Vault 전환 같은 고민이 반복된다.
- 범위 확장 제어: 문제 하나가 스킬·가이드·봇·릴리즈·워크로그·문서까지 번지는 것이 단점이다. 우선순위 제어가 중요하다.
페르소나별 평가
상당히 믿을 만하다. 성능, 운영, 장애, 배치, 도메인 규칙이 얽힌 일을 맡기기 좋다. 이미 알고 있는 팀 관습을 AI나 동료가 놓치면 답답함을 강하게 표출할 수 있다.
신뢰 가능하다. 복잡한 백엔드 운영 개선, 릴리즈 프로세스 정비, 장애 재발 방지, 생산성 도구화에 적합. 승진 가능성은 높지만 사람을 안정적으로 이끄는 증거는 기술 증거보다 적다.
조직 가치 높음. 개발자 생산성, 운영 자동화, 장애 대응 체계, 도메인 지식의 도구화를 만들 수 있다. 보안·권한·브랜치 운영 사고를 시스템적으로 막기 전까지 큰 권한을 주기 조심스럽다.
초기 멤버로 뽑을 가능성이 높다. 백엔드 플랫폼, 운영 자동화, 사내 도구, 기술 콘텐츠가 모두 가능한 사람. 리스크: 제품 본질보다 내부 도구와 워크플로우 최적화에 과투자할 수 있다.
시스템 디자인·운영 경험 기준으로는 strong senior 후보에 가깝다. 예상 레벨: L5 가능성 있음. Staff는 아직 조직 범위 영향력 증명이 더 필요하다(추측).
기술 병목은 지식 부족보다 추상화와 영향력의 레벨업이다. 개인·팀 문제 해결을 넘어 여러 팀이 따르는 표준, 가드레일, 운영 지표, 리뷰 정책으로 승격시켜야 한다.
잘하는 것: "불편을 시스템으로 바꾸는 것". 후회할 수 있는 것: 너무 많은 도구와 흐름을 만들었지만 대표 성과가 숫자로 남지 않는 것. 지금 집중할 것: 큰 운영 문제 하나를 지표로 끝내는 일.
성공 / 실패 시나리오
- 데이터 규모가 크고 운영 이슈가 많은 백엔드 플랫폼 팀
- 반복 업무가 많아 자동화 효과가 큰 조직
- AI 도구를 팀 생산성으로 연결하려는 조직, 기술 콘텐츠·DevRel 감각이 가치가 되는 환경
- 도구화가 성과보다 앞설 때
- 검증보다 실행이 먼저 갈 때
- 모든 문제를 스킬·봇·자동화로 풀려 할 때
- 감정적 피드백이 사람에게도 그대로 전달될 때
2년 성장 전략
- 운영 가드레일을 먼저 만든다 — 브랜치, 배포, force push 금지, 시크릿, Vault, 계정, 비용, 테스트, 롤백 기준을 작업 전 체크리스트로 고정한다.
- 대표 성과 하나를 숫자로 만든다 — 대규모 배치 정리 시간 단축, DB/검색 엔진 운영비 절감, 장애 재발률 감소, 릴리즈 리드타임 단축 같은 결과를 수치화한다.
- 팀 표준으로 승격한다 — 개인 스킬과 가이드를 팀 RFC, 코드리뷰 정책, release playbook, oncall runbook으로 만든다.
- 커뮤니케이션 강도를 조절한다 — 문제 지적은 정확하지만, 사람에게 전달할 때는 재현 조건, 영향도, 다음 액션 중심으로 낮은 온도로 전달하는 훈련이 필요하다.
- AI 없이도 설명 가능한 설계를 남긴다 — AI를 잘 쓰는 것은 강점이지만, 커리어 평가는 결국 본인이 소유한 설계·운영·성과로 남는다.
한 문장 요약
멘토로서 하고 싶은 말
당신은 문제를 잘 본다. 특히 "겉으로 고쳐진 것"과 "왜 터졌는지"를 구분하는 감각이 좋다. 이건 운영형 시니어에게 매우 큰 장점이다.
다만 앞으로는 더 빠르게 움직이는 것보다 더 안전하게 움직이는 사람이 되어야 한다. 이미 충분히 빠르다.
이제 필요한 것은 큰 문제를 골라, 사고 없이, 지표로, 다른 사람도 따라 할 수 있게 끝내는 것이다.
댓글