개발자의 “할 수 있다”는 말은 어디까지일까요?

이력서를 작성하다 보면 사용 기술 옆에 ‘상·중·하’를 표시하거나, ‘사용 가능’이라는 표현을 적을 때가 있습니다. 저 역시 그 칸 앞에서 여러 번 멈췄습니다. 저는 컴퓨터공학과에서 자바(Java)를 배웠습니다. 학교에서 웹 애플리케이션을 만들어봤고, 졸업 후 한국 회사에서도 Java를 사용했습니다. 일본 취업을 준비할 때도 Java 경력을 적었으며, 현재 업무에서도 계속 사용하고 있습니다.

그런데 누군가 “Java를 할 수 있나요?”라고 물으면 지금도 바로 답하기 어렵습니다. 학교에서 문법을 배웠다면 가능한 것일까요? 개인 프로젝트를 끝냈다면 충분할까요? 회사에서 일부 기능을 개발했다면 경력자라고 말할 수 있을까요? 같은 ‘사용 가능’이라는 표현 안에는 서로 다른 경험이 들어갑니다. 책을 읽고 예제를 따라 해본 사람도, 실제 서비스의 오류를 수정하고 운영해 본 사람도, 이력서에는 똑같이 ‘Java 가능’이라고 적을 수 있습니다.

이 글에서는 누가 초급이고 누가 고급인지 판정하려는 것이 아닙니다. 저 역시 제 수준을 하나의 등급으로 정확하게 설명하기 어렵거든요. 대신 학교와 한국·일본의 개발 현장에서 겪은 일을 돌아보며, 기술 수준을 어떤 근거로 설명해야 신뢰를 얻을 수 있을지 이야기해 보려고 합니다.

학교에서 웹 애플리케이션을 만들면 Java를 할 수 있을까요?

저는 컴퓨터공학과 재학 중 Java를 처음 배웠습니다. 변수와 조건문, 반복문을 익혔고 객체지향 개념도 공부했습니다. 수업에서는 웹 애플리케이션을 직접 만들어보기도 했습니다. 당시에는 프로그램이 정상적으로 실행되고 과제를 완성하면 해당 언어를 사용할 수 있다고 생각했습니다. 직접 코드를 작성해 결과물을 만들었으니, 졸업 이력서에 Java를 적는 것도 자연스럽게 느껴졌습니다.

하지만 졸업 당시의 저에게 실제 회사의 Java 업무를 맡겼다면 어땠을까요? 이미 운영 중인 코드를 읽고 수정하거나, 팀의 규칙에 맞춰 기능을 구현하거나, 오류가 발생했을 때 원인을 추적하는 일까지 바로 해낼 수 있었을지는 자신 있게 답하기 어렵습니다.

학교에서 웹 애플리케이션을 만들어본 경험은 분명한 출발점이었습니다. 다만 문법을 배웠다는 사실과 실제 업무를 수행할 수 있다는 것은 다른 문제였습니다. 혼자 결과물을 완성하는 것과 여러 개발자가 함께 관리하는 서비스를 만드는 일도 달랐습니다. 지금 돌아보면 당시의 저는 Java를 ‘배운 사람’에 가까웠습니다. 그런데 그때는 ‘배웠다’와 ‘할 수 있다’ 사이에 얼마나 많은 단계가 있는지 잘 보이지 않았습니다.

버리는 컴퓨터로 서버를 만들며 생긴 자신감

한국에서 전산실 업무를 담당하던 시절, 전사적 자원관리(Enterprise Resource Planning, ERP) 시스템의 출하 정보를 확인할 수 있는 사내 웹페이지를 혼자 만든 적이 있습니다.

별도의 프레임워크(Framework)는 사용하지 않았습니다. 화면은 HTML로 만들고, 웹 서버는 IIS(Internet Information Services, 인터넷 정보 서비스)를 사용했습니다. 동적 처리는 ASP(Active Server Pages, 액티브 서버 페이지)로 구현했습니다.

서버 장비를 새로 구매한 것도 아니었습니다. 회사에서 사용하지 않던 컴퓨터를 가져와 사내 서버로 구성했습니다. 외부 클라우드가 아니라 회사 내부에서 직접 운영하는 온프레미스(On-premises) 방식이었습니다. 화려한 시스템은 아니었지만, 현장에서 필요한 출하 정보를 웹으로 확인할 수 있게 됐습니다. 요구를 듣고, 화면을 만들고, 서버를 구성해 실제 사용 가능한 결과물까지 혼자 완성했습니다. 이 경험은 저에게 꽤 큰 자신감을 줬죠.

프레임워크도 쓰지 않고 필요한 기능을 만들었으니 당시에는 “개발이 생각보다 별것 아닐 수도 있겠다”는 생각도 했습니다. 하지만 혼자 개발하는 환경에는 당시 제가 알아차리지 못한 편리함이 있었습니다.

설계 방식과 코드 작성 규칙을 제가 정했고, 문제가 생기면 제 판단대로 고칠 수 있었습니다. 다른 개발자가 제 코드를 읽어야 하는 상황도 많지 않았습니다. 코드 리뷰, 공동 작업 규칙, 버전 충돌처럼 협업에서 생기는 복잡성도 거의 경험하지 않았습니다.

이 경험이 가치 없었다는 뜻은 아닙니다. 제한된 자원으로 실제 업무에 쓰이는 시스템을 완성한 일은 지금도 제 강점입니다. 다만 혼자 프로그램을 완성할 수 있다는 것과 팀 안에서 오래 관리할 수 있는 소프트웨어를 만드는 것은 서로 다른 능력이었습니다.

협업을 시작하자 ‘잘한다’의 기준이 달라졌습니다

실제 협업 환경에 들어간 뒤에는 개발을 바라보는 기준이 완전히 달라졌습니다. 혼자 만들 때는 코드가 정상적으로 동작하는지가 가장 중요했지만, 팀에서는 동작 여부만으로 끝나지 않았습니다.

팀의 코드 규칙과 명명 규칙을 따라야 했고, 기존 프로젝트의 구조에 맞춰 기능을 추가해야 했습니다. 코드 리뷰에서는 실행 결과와 직접 관련이 없어 보이는 부분도 수정해야 했습니다. 여러 사람이 같은 저장소에서 작업하니 깃(Git) 충돌과 브랜치 관리도 피할 수 없었습니다.

프레임워크와 라이브러리를 쓰는 일도 생각보다 단순하지 않았습니다. 사용법을 따라 하는 것만으로는 부족했습니다. 왜 이런 구조를 사용하는지, 기존 코드가 어떤 규칙으로 연결돼 있는지, 버전이 바뀌면 어느 부분에 영향이 생기는지를 이해해야 했습니다.

도메인 지식도 큰 벽이었습니다. 급여, 결제, 예약처럼 업무 규칙이 복잡한 프로젝트에서는 문법을 알아도 업무 흐름을 이해하지 못하면 올바른 기능을 만들 수 없었습니다. 기술적으로 실행되는 코드가 실제 업무 규칙과 맞지 않아 다시 수정되는 일도 있었습니다.

혼자 개발할 때는 제가 이해할 수 있는 코드면 충분했습니다. 협업에서는 다른 개발자가 읽고 수정할 수 있어야 했습니다. 일정과 품질을 지켜야 했고, 테스트와 문서도 남겨야 했습니다. 담당자가 바뀌어도 이어서 개발할 수 있는 상태를 만들어야 했습니다.

개발을 잘 몰랐을 때 오히려 제 실력을 높게 평가했습니다. 더 많은 도구와 규칙을 접하고 나서야 제가 모르는 범위가 얼마나 넓은지 알게 됐습니다. 자신감이 줄었다기보다, 개발이라는 일의 실제 크기를 조금 더 정확하게 보기 시작한 것입니다.

‘대형 프로젝트 참여’의 대형은 무엇일까요?

이력서에서 자주 보이는 표현 가운데 하나가 ‘대형 프로젝트 참여’입니다. 저 역시 약 3,000명의 사용자가 이용하는 공공기관 시스템 프로젝트에 참여한 경험이 있습니다. 그렇다면 사용자 3,000명이면 대형 시스템일까요? 대기업이나 공공기관이 발주하면 대형일까요? 참여 인원이 많아야 할까요? 데이터가 많아야 할까요? 개발 기간이나 예산이 크면 대형이라고 부를 수 있을까요?

저는 이 기준도 ‘Java 사용 가능’이라는 표현만큼 애매하다고 느꼈습니다. 사용자가 적어도 다루는 데이터가 민감할 수 있고, 사용자 수가 많아도 기능은 비교적 단순할 수 있습니다. 팀 규모가 커도 한 개발자가 맡는 범위는 작은 기능 하나일 수 있습니다.

프로젝트 전체의 크기와 개인이 경험한 범위도 구분해야 합니다. 대부분의 개발자는 큰 시스템에 참여하더라도 전체를 혼자 설계하거나 구현하지 않습니다. 각자 일부 화면이나 기능, 업무 영역 또는 개발 공정을 맡습니다.

따라서 “대형 프로젝트에 참여했습니다”라는 문장만으로는 개인의 역량을 알기 어렵습니다. 약 3,000명이 사용하는 공공기관 시스템이라는 배경은 프로젝트를 설명해주지만, 제 실력을 보여주려면 그 안에서 무엇을 맡았는지를 더 말해야 합니다.

프로젝트 기간은 얼마였는지, 어떤 기능을 담당했는지, 기본설계부터 참여했는지, 구현과 테스트 중 어디까지 책임졌는지, 운영 이후의 수정에도 참여했는지를 함께 적어야 합니다.

반대로 프로젝트 자체는 작더라도 요구사항 정리부터 설계, 구현, 배포와 운영까지 맡았다면 개인에게는 더 넓은 경험이 될 수 있습니다. 프로젝트 이름보다 내가 책임졌던 범위를 설명하는 편이 더 정직하고 유용합니다.

같은 경력도 한국과 일본에서 질문받는 방식이 달랐습니다

한국과 일본에서 취업을 준비하며 채용 과정의 초점이 다르다고 느낀 적도 있습니다. 다만 회사와 직무, 면접관에 따라 차이가 크기 때문에 아래 내용은 제가 직접 지원하고 면접을 본 범위에 한정된 경험입니다.

제가 경험한 한국 채용에서는 학력, 전공, 자격증, 이전 회사와 경력이 비교적 자주 언급됐습니다. 어느 회사에서 어떤 업무를 했는지, 어떤 도메인을 경험했는지가 지원자의 배경을 판단하는 기준처럼 느껴졌습니다.

반면 일본 면접에서는 실무에 바로 참여할 수 있는지를 확인하려는 기술 질문을 더 자주 받았습니다. 어떤 기술을 사용했는지뿐 아니라, 그 기술로 어떤 기능을 직접 구현했는지, 문제가 생겼을 때 어떻게 대응했는지, 프로젝트의 어느 단계에 참여했는지를 구체적으로 설명해야 했습니다.

같은 Java 경력이라도 단순히 사용 기간만 말하는 것으로 끝나지 않았습니다. 새 기능을 개발해 봤는지, 기존 코드를 수정해 봤는지, 오류를 분석해 봤는지, 팀의 규칙에 맞춰 협업해 봤는지에 따라, 답변의 내용이 달라졌습니다. 두 나라에서 질문받는 방식은 달랐지만, 공통점도 있었습니다. 결국 상대가 알고 싶은 것은 기술 이름 자체가 아니라, “실제로 무엇을 해봤고, 지금 어떤 일을 맡길 수 있는가”였습니다.

자기 객관화가 부족하면 답변이 양극단으로 흐르기 쉽습니다. 분명히 해본 일도 “잘 모릅니다”라고 줄여 말하거나, 한두 번 써본 기술을 능숙하다고 표현할 수 있습니다. 가장 설득력 있었던 답변은 경험의 범위를 있는 그대로 설명하는 답변이었습니다.

저는 지금도 Java를 ‘중’이라고 적습니다

학교에서 Java를 배운 뒤 한국과 일본의 업무에서도 계속 사용했지만, 기술 수준을 표시해야 한다면 저는 지금도 Java를 ‘중’이라고 적는 편입니다. Java로 기능을 개발하고 수정했으며, 오류 대응과 협업도 경험했습니다. 그렇다고 언어의 내부 구조나 성능 최적화, 복잡한 시스템의 전체 설계까지 자유롭게 담당할 수 있다고 말하기는 어렵습니다.

현재 제가 개인적으로 생각하는 ‘사용 가능’의 기준은 일정 기간 실제 업무에서 사용해 본 경험입니다. 대략 1년 정도 기능 개발과 수정, 오류 대응, 협업을 경험해야 비로소 업무에서 사용할 수 있다고 말할 수 있지 않을까 생각합니다.

물론 이 기준도 절대적이지 않습니다. 같은 1년이라도 단순한 수정 업무를 반복한 사람과 요구사항 분석부터 설계, 구현, 운영까지 경험한 사람의 깊이는 다릅니다. 프로젝트 환경과 담당 범위에 따라 경험의 밀도가 달라집니다.

개인 프로젝트 역시 하나의 기준만으로 평가하기 어렵습니다. 강의를 따라 간단한 예제를 만든 경험과 실제 사용자를 고려해 여러 기능을 설계하고, 배포한 경험은 다릅니다. 그래서 ‘상·중·하’나 ‘사용 가능’이라는 표시를 없애야 한다고 생각하지는 않습니다. 빠르게 기술 수준을 전달하는 표시는 필요합니다. 다만 그 뒤에는 판단의 근거가 따라야 합니다.

• 얼마나 오랫동안 실제 업무에서 사용했는가
• 어떤 기능을 직접 맡아 책임졌는가
• 실제 사용자에게 제공되는 서비스에 적용했는가
• 오류 수정과 유지보수를 경험했는가
• 기본설계나 상세설계에 참여했는가
• 팀의 코드 규칙과 리뷰 과정에 맞춰 협업했는가

기술 이름 대신 경험을 적어 보면 달라집니다

이력서에서 기술 이름을 완전히 빼기는 어렵습니다. 채용 담당자가 지원자의 경험을 빠르게 파악하려면 기술 목록과 등급도 필요합니다. 문제는 그 한 단어만으로 실력을 모두 설명하려 할 때 생깁니다.

예를 들어, “Java 중”이라고만 적는 대신 “Java 기반 업무 시스템에서 기능 개발과 수정, 오류 대응을 경험했으며, 팀의 코드 규칙에 맞춰 협업했습니다”라고 쓰면 판단 근거가 생깁니다. 공개할 수 있다면, 사용 기간과 담당 기능도 함께 적는 편이 좋습니다.

제가 과거에 만든 출하 정보 웹페이지도 단순히 ‘ASP 사용 가능’이라고만 적으면, 경험의 특징이 잘 드러나지 않습니다. ERP 출하 정보를 확인하는 사내 웹페이지를 혼자 만들었고, HTML과 IIS, ASP를 사용했으며, 사용하지 않던 컴퓨터를 온프레미스 서버로 구성했다고 설명해야 실제로 한 일이 보입니다.

공공기관 시스템 프로젝트도 ‘대형 프로젝트 참여’라고만 적으면 제가 한 일이 보이지 않습니다. 약 3,000명의 사용자가 이용하는 시스템이라는 배경과 함께, 프로젝트 기간과 담당 기능, 참여한 개발 단계와 책임 범위를 설명해야 합니다.

성과를 수치로 적을 때도 같은 원칙이 필요합니다. 응답 속도를 개선했거나 오류 건수를 줄인 결과가 실제 측정값이라면 좋은 근거가 됩니다. 확인할 수 없는 숫자를 억지로 만들기보다, 변경 전의 문제와 자신이 한 행동, 변경 후 달라진 점을 구체적으로 적는 편이 낫습니다.

자기 객관화는 경험을 축소해서 말하는 일이 아닙니다. 자신이 한 일을 상대방이 오해하지 않도록 구체적인 언어로 바꾸는 과정입니다. 작은 프로젝트라도 해결한 문제가 분명하면 강점이 되고, 큰 프로젝트라도 담당 범위를 설명하지 못하면 프로젝트 이름만 남습니다.

마치며: ‘할 수 있다’ 뒤에 경험을 붙여봅시다

지금도 저는 “Java를 할 수 있나요?”라는 질문에 단순히 “네”라고 답하기 어렵습니다. 학교에서 배웠고, 웹 애플리케이션을 만들었으며, 한국과 일본의 업무에서도 계속 사용했습니다. 기능 개발과 수정, 오류 대응과 협업도 경험했습니다.

하지만 아직 경험하지 못한 영역도 많습니다. 그래서 저는 Java 수준을 표시해야 한다면 ‘중’이라고 적습니다. 이 선택이 모든 개발자에게 맞는 기준이라고 생각하지는 않습니다. 같은 기술을 사용했어도, 프로젝트와 담당 업무에 따라 경험의 깊이가 다르기 때문입니다.

대신 기술 옆에 적은 등급을 설명할 수 있어야 한다고 생각합니다. 얼마나 사용했는지, 무엇을 만들었는지, 실제 서비스에 적용했는지, 어떤 문제를 해결했는지, 어느 단계까지 책임졌는지를 함께 말할 수 있어야 합니다.

자기 객관화는 자신을 낮추는 일이 아닙니다. “이 부분은 직접 해봤습니다. 여기까지는 책임질 수 있습니다. 이 영역은 더 경험해야 합니다”라고 구분해 말할 수 있는 상태에 가깝습니다.

다음에 이력서에서 ‘사용 가능’이나 ‘상·중·하’를 선택하게 된다면, 그 뒤에 한 줄을 더 붙여보면 어떨까요? 그 수준을 선택하게 만든 구체적인 경험입니다. 막연했던 기술 목록이 개발자로서 걸어온 과정으로 바뀌고, 그 과정이 화려한 표현보다 오래 신뢰를 남길 수 있을 겁니다.

이 글은 AI의 도움을 받아 작성했습니다. 필자가 직접 작성한 초안을 바탕으로 AI를 활용해 구조와 문장을 보정했으며, 모든 경험과 판단은 필자가 직접 검수했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.