Taehyun Jeon

최근 사회 이슈에 대한 견해

최근 가장 중요하다고 생각하는 사회 이슈는 AI 기술의 발전에 따른 개발자 역할의 변화입니다. 실무 현장에서 AI 사용에 따른 토큰 비용이 수천만 원 단위로 발생한다는 이야기를 듣고 적지 않은 충격을 받았습니다. AI가 이미 개발 워크플로의 핵심 일부로 자리 잡았고, 사람이 직접 코드를 작성하는 비중이 빠르게 줄어들고 있다는 현실이 체감되었기 때문입니다.

저는 이 흐름이 '개발자가 사라지는 것'이 아니라 '개발자에게 요구되는 역량이 바뀌는 것'이라고 생각합니다. AI가 코드를 잘 작성할수록, 사용자가 진짜 필요로 하는 것을 정의하고, 문제를 올바르게 쪼개어 질문하며, 결과물을 검증해내는 역량의 중요성은 오히려 더 커집니다. 그래서 저는 단순히 코드를 작성하는 사람이 아니라, 문제를 정의하고 AI를 도구로 잘 다루어 사용자에게 실제 가치를 전달하는 개발자가 되기 위한 준비를 이어가고 있습니다.

문제 해결 경험

가장 기억에 남는 두 가지 경험이 있습니다. 첫 번째는 군 복무 시절, 인터넷도 AI도 사용할 수 없는 폐쇄망 환경에서 책 한 권만으로 학습하며 여단 인트라넷의 D-day 카운터와 행정반 현황판을 만들어 낸 일입니다. 검색에 익숙한 환경에 비해 작은 문제 하나도 더디게 풀렸지만, 책을 처음부터 끝까지 직접 읽고 실험해 보는 과정에서 제약된 자원 안에서도 답을 찾아내는 끈기, 그리고 외부 자료에 의존하지 않고 스스로 설계하는 사고력을 얻을 수 있었습니다.

두 번째는 프로젝트 매니저 Grav를 만들 때의 경험입니다. Steam 라이브러리처럼 카드에 호버하면 광택이 자연스럽게 흘러내리는 효과가 꼭 필요했는데, 일반적인 CSS 방식으로는 원하는 표현이 나오지 않았습니다. 며칠을 고민한 끝에 발상을 바꿔, 카드 위에 또 하나의 사각형을 덧대고 카드 영역 바깥은 숨김 처리한 뒤, 호버 시 그 사각형을 아래로 이동시키는 방식으로 광택이 흐르듯 보이게 구현했습니다. 정해진 방법으로 풀리지 않을 때 문제를 다른 관점에서 다시 정의해 보는 일의 중요성을 배운 경험이었습니다.

협업과 갈등 해결 경험

팀 프로젝트를 진행하며 결이 다른 두 가지 협업 경험을 했습니다. 첫 번째는 DevChat 개발 당시의 일입니다. 코드 병합 과정에서 충돌이 발생했는데, 변경 범위가 커서 일반적인 방식으로는 안정적으로 풀리지 않았습니다. 결국 충돌이 발생한 코드를 비우고 다시 작성하는 방식으로 마무리했지만, 이 경험은 사전 합의된 코드 컨벤션과 작업 분담 규칙의 중요성을 절실하게 느끼게 해 준 계기가 되었습니다.

두 번째는 2026년 1학기 캡스톤 프로젝트에서의 경험입니다. 이전의 시행착오를 반복하지 않기 위해, 시작 단계에서부터 노션에 API 엔드포인트를 정확하게 문서화하고, 정기 회의를 운영하며 매번 회의록을 남기는 등 문서·소통 체계를 함께 만들어 두었습니다. 그 결과 백엔드와의 협업이 마찰 없이 매끄럽게 진행되었고, 제가 참여한 팀 프로젝트 중 가장 안정적으로 흘러간 프로젝트가 되었습니다. 두 경험은 협업의 결과를 좌우하는 핵심이 결국 '코드 이전의 합의'라는 것을 가르쳐 주었습니다.

직무 역량 — 기여할 수 있는 점

저는 크게 두 가지 축에서 강점을 가지고 있다고 생각합니다.

첫째는 '직접 만들고, 막히면 우회하고, 시도하며 개선하는 실행 자세'입니다. 필요한 도구가 있으면 직접 만들어 사용해 보는 메이커 정신(Grav가 그 대표적인 예), 일반적인 방법으로 풀리지 않는 문제를 다른 관점에서 다시 정의하는 우회 사고력, 그리고 인터넷도 AI도 쓸 수 없던 군 복무 환경에서 책 한 권으로 결과를 만들어 낸 제약 환경에서의 끈기가 그 기반입니다. 여기에 더해 널리 알려지지 않은 개발 도구나 자동화 환경까지 적극적으로 탐색·도입해 자신의 작업 환경을 끊임없이 최적화하는 습관이 있어, 같은 시간에 더 많은 결과를 만들어내는 일에 익숙합니다.

둘째는 '사람과 일할 때의 태도'입니다. 캡스톤에서 백엔드와의 협업을 매끄럽게 이끌어 본 경험에서처럼, 저는 코드 자체를 떠나 팀원들과 마찰 없이 서로를 존중하며 일하는 흐름을 만드는 일에 강점이 있습니다. 따라서 합류하는 팀에는 두 가지 방향의 기여가 가능하다고 생각합니다. 하나는 백엔드·디자인 등 다른 직군과의 부드러운 협업으로 팀의 흐름을 매끄럽게 유지하는 것이고, 다른 하나는 효율적인 작업 환경과 방식을 통해 같은 자원을 더 가치 있게 사용하는 것입니다.

실패 경험과 배운 점

가장 인상 깊은 실패 경험은 LMS-v2 프로젝트입니다. 학교 LMS를 사용하며 느낀 불편함에서 출발해, 방학 특강 기간 한 달 동안 2인 팀으로 새로운 LMS를 만들어 보자는 목표를 세웠습니다. 그러나 막상 시작해 보니 프로젝트 규모가 예상보다 훨씬 컸고, 함께 모여 작업하던 기숙사 생활이 끝나 환경이 바뀌자 추진력이 빠르게 떨어졌습니다. 결국 프로젝트는 완성하지 못한 채로 멈추게 되었습니다.

이 경험을 통해 두 가지를 배웠습니다. 첫째, 프로젝트의 실제 규모를 정확히 파악하고 일정에 충분한 여유를 두어 계획해야 한다는 점입니다. 의욕만으로 일정을 잡으면 결과적으로 더 많은 시간을 잃게 된다는 것을 몸으로 체감했습니다. 둘째, 프로젝트를 진행하던 환경에서 멀어졌을 때에도 흐름을 끊지 않고 끝까지 끌고 가는 끈기가 필요하다는 점입니다. 환경이 동기 부여의 큰 부분을 담당하고 있었다는 사실을 알게 된 만큼, 앞으로의 프로젝트에서는 환경 변화에 흔들리지 않도록 일정·진행 방식·동기 관리를 미리 함께 설계해 두려 합니다.