AI를 잘 쓴다는 건 무엇일까 - 조코딩AX파트너스 AI 역량 진단 후기
AI와 함께 제한 시간 안에 실무 과제를 해결해야 한다면, 나는 어디까지 할 수 있을까?
조코딩AX파트너스의 APEX Expert AI 실무 역량 평가를 봤다.
평소 AI를 많이 쓰고는 있지만, 내가 정말 잘 쓰고 있는지 객관적으로 확인할 기회는 흔하지 않았다. 마침 무료 파일럿 응시 기회가 있어 신청해 테스트를 봤고, 결과는 85점 / 100점, 61명 중 5위였다.
순위가 잘 나와서 기분이 좋기도 했지만, 점수보다 더 흥미로웠던 것은 이 시험이 AI 활용 능력을 평가하려 했던 방식이다. AI를 잘 쓴다는 게 정확히 어떤 것인지 아직은 설명하기 쉽지 않다. 그래서 AI를 활용해 실무 과제를 해결하는 과정 자체를 평가 대상으로 삼았다는 점이 재미있었다.
목차
- 시험은 네 단계로 진행됐다
- 재미있었던 점 - 결과물만 보지 않았다는 것
- 다만 40분 안에 낯선 코드를 이해하는 방식은 아쉬웠다
- 그래도 리포트가 남긴 피드백은 분명했다
- AI 활용 역량을 어떻게 평가할 수 있을까
시험은 네 단계로 진행됐다
전체 시험 시간은 70분이었다. 이론 15분, 실기 40분, 마지막 게이트 검증 15분으로 구성됐다. 응시하면서는 크게 네 단계로 느껴졌다.
- 기본 AI 활용 이론
- AI 사용과 개발 관련 개념을 묻는 객관식 문제였다.
- 수정할 지점 찾기
- 처음 보는 Hono 웹 프레임워크 코드에서 개선할 만한 지점을 AI와 함께 찾는 단계였다.
- 실제로 코드 수정하기
- 찾은 문제를 수정하고 테스트로 검증하는 단계였다.
- 내가 무엇을, 왜 고쳤는지 설명하기
- 수정한 코드와 접근 방식을 주관식으로 설명하는 게이트 단계였다.
실기에서는 세 가지 개선안을 제출했다. 디렉터리 요청 처리, 경로 탐색 성능, 첫 요청 지연과 관련된 문제를 골랐고, 제출 코드는 기존 테스트 3,703개를 다시 돌린 결과 회귀 없이 통과했다. 수정 전에는 실패하고 수정 후에는 통과하는 테스트도 세 건 만들었다.
그래서 정량 평가는 30점 만점이었다.
| 항목 | 결과 |
|---|---|
| 이론 평가 | 17 / 20 |
| 실기 정량 | 30 / 30 |
| 실기 정성 | 23 / 30 |
| 게이트 검증 | 6 / 10 |
| AI 활용 | 9 / 10 |
| 총점 | 85 / 100 |
결과 리포트에서는 문제 진단력 100%, 검증·품질 습관 96%, AI 협업 90%로 나왔다. AI에게 답만 받아오는 방식보다는, 문제를 찾고 테스트로 확인하는 흐름에는 익숙한 편이라는 평가로 읽혔다.
재미있었던 점 - 결과물만 보지 않았다는 것
AI에게 얼마나 구체적으로 지시했는지, AI의 제안을 그대로 수용했는지 아니면 검증했는지, 실제로 테스트를 실행했는지까지 협업 로그를 기준으로 봤다. 내 경우 프롬프트 10회, 테스트 실행 16회, 수정 후 검증 사이클 3회가 기록됐다고 한다.
이 부분은 좋았다.
AI를 잘 쓴다는 건 그럴듯한 코드를 빨리 받아내는 것만은 아니라고 생각한다. AI가 제안한 내용을 그대로 붙이는 것보다, 왜 이 수정이 필요한지 확인하고 기존 동작을 깨뜨리지 않았는지 테스트하는 쪽이 더 중요하다.
리포트에서도 이 점을 좋게 봤다. 실제 병목을 수치로 확인했고, 기존의 경로 등록 순서나 URL 처리 규칙을 유지한 채 최소 범위로 수정했다는 평가였다.
AI가 답을 잘 주는 것도 중요하지만, 그 답을 검증 가능한 결과물로 바꾸는 능력도 함께 봐야 한다. 이 시험이 그 부분을 평가 대상으로 넣었다는 점은 꽤 좋았다.
다만 40분 안에 낯선 코드를 이해하는 방식은 아쉬웠다
실기는 20분씩 두 번, 총 40분 동안 처음 보는 코드를 가지고 진행됐다. AI를 활용해 수정할 지점을 찾고, 실제로 고치고, 테스트까지 해야 했다.
AI에게 코드를 읽혀서 후보를 받는 것까지는 가능하다. 하지만 답변을 기다리는 시간도 있고, 제안받은 코드를 내가 다시 읽고 판단하는 시간도 필요하다. 무엇보다 처음 보는 코드라면 수정 전에 구조와 기존 약속부터 이해해야 한다.
심도 있는 코드 리뷰나 개선 과제라면 납득할 수 있다. 그런데 40분 안에 낯선 코드의 문제를 찾아 수정한 뒤, 마지막 단계에서 “어떻게 접근해서 풀었는가”까지 설명하라고 하면 조금 애매해진다.
수정 자체는 AI와 함께 할 수 있다. 다만 그 코드가 왜 그렇게 동작하는지, 수정이 어떤 영향을 만들 수 있는지까지 충분히 이해한 상태에서 답하기에는 시간이 빠듯했다.
실제로 내 리포트에서도 정성 평가와 게이트 검증에서 아쉬움이 남았다. 개선 자체는 인정받았지만, 성능 개선 뒤의 메모리 비용이나 정렬 비용, 새 기능을 사용하기 위해 사용자가 해야 하는 일처럼 수정의 대가와 영향을 충분히 설명하지 못했다.
이건 단순히 글을 잘 쓰고 못 쓰는 문제가 아니다. 짧은 시간 안에 문제를 찾고 고치고 검증하고 설명하는 일은, 각각 필요한 사고의 종류가 다르다.
그래도 리포트가 남긴 피드백은 분명했다
결과에서 가장 명확하게 남은 피드백은 하나였다.
좋아진 점만 쓰지 말고, 그 대가로 무엇이 늘어나는지도 함께 적을 것.
예를 들어 성능을 개선했다면 수정 전 측정값만 제시하는 것으로는 부족하다. 수정 후 같은 조건에서 다시 측정한 값, 추가로 사용하는 메모리, 초기화 비용, 기존 사용자에게 달라지는 동작까지 같이 봐야 한다.
생각해보면 실무에서도 그렇다.
“빨라졌습니다”보다 “이 경로는 빨라졌지만, 초기화 비용이 생기고 이 기능을 호출해야 효과가 납니다”라고 설명하는 쪽이 훨씬 검토하기 쉽다. AI와 함께 코드를 수정할수록 이 설명은 더 중요해질 것 같다. 수정안을 빠르게 만들 수 있는 만큼, 사람이 책임지고 확인해야 할 범위도 더 넓어지기 때문이다.
AI 활용 역량을 어떻게 평가할 수 있을까
이 시험이 완벽한 평가 방식이라고 생각하지는 않는다. 특히 낯선 코드와 제한 시간, 주관식 설명의 조합은 앞으로 더 다듬어질 필요가 있다.
그래도 아직 기준이 뚜렷하지 않은 영역에서, AI 활용을 단순한 이론 점수나 결과물 하나로 판단하지 않고 다음을 함께 보려 했다는 점은 의미가 있었다.
- AI에게 무엇을 어떻게 요청했는가
- 제안을 검증했는가
- 실제 코드가 기존 기능을 깨뜨리지 않았는가
- 수정한 내용을 스스로 설명할 수 있는가
앞으로는 코드베이스에 익숙해지는 시간을 별도로 주거나, 문제 진단과 구현·설명을 조금 더 분리하면 더 좋은 평가가 될 수 있을 것 같다. AI를 잘 쓰는 사람은 단순히 AI의 답을 빨리 얻는 사람이 아니라, 답을 의심하고 검증하고 자신의 판단으로 연결하는 사람이니까.
그래도 이번 경험은 재미있었다.
객관적인 위치도 확인했고, 61명 중 5위라는 결과도 기분 좋았다. 무엇보다 평소 AI를 쓰는 방식을 한 번 돌아볼 수 있었다. 다음에는 “무엇을 고쳤는가”에서 멈추지 않고, 왜 이 선택을 했고 무엇이 함께 바뀌는가까지 더 명확하게 설명해봐야겠다.
피드백은 언제나 환영입니다.