chatGPT, AI, 그리고 소프트웨어 엔지니어의 미래

* chatGPT 사용해보기: 링크
 
최근 chatGPT 이야기가 뜨겁다.
특히 관심을 많이 가지는 사람들 중 하나는 개발자들이다. IT 업계의 성격상 얼리어답터 성향을 가진 사람들이 유독 많아서 그렇기도 하지만, AI가 코드를 작성하는 시대의 초입에 들어섰기 때문에 그럴지도 모르겠다.
특히 많은 주니어 개발자, 그리고 개발자를 지망하는 학생들이 chatGPT에 대해 걱정을 하고 있다. 'AI가 코드를 다 작성한다면, 가까운 시일 내에 개발자라는 직업은 없어지는 것이 아닐까?' 라는 막연한 걱정과 이에 따라오는 두려움이 원인인 것으로 보인다.
 
나는 이제 1년을 넘긴 지 몇달 된, 한 IT 기업의 주니어 백엔드 개발자이다.
이 글은 이런 내가 chatGPT와 AI, 그리고 소프트웨어 엔지니어의 미래에 대해 생각한 것을 정리하는 글이다.

목차

1. chatGPT는 무엇인가?
2. 왜 chatGPT를 경계하는가?
3. 왜 사람들은 질문을 하지 않는가?
4. 질문을 대하는 구성원과 리더의 자세, 사람과 AI의 자세
5. 엔지니어는 어떤 역할을 하고, 어떻게 AI와 공존해야 하는가?
6. 결론

1. chatGPT는 무엇인가?

아래 사진으로 요약할 수 있다.

chatGPT가 작성해 준 Controller 코드

GPT에게 아래 내용을 주문했다.

• Spring / Kotlin을 이용해서 코드를 작성해 달라.
• Controller class에는 메소드가 하나 존재한다.
• 이 메소드는 "/api/v1/tistory-katfun"이라는 URI를 호출한다.
• 이 메소드는 KatfunService 클래스 내의 katfunService 메소드를 호출한다.

결과물을 보면 놀랄 수밖에 없다. 사람이 말로 (글로) 요구사항을 설명하면, 눈 앞에서 chatGPT가 코드를 짜 준다. 작성한 코드에 대해 해설도 해 준다. 이 모든 것이 불과 수 초 만에 끝났다. 아무리 잘 짜는 사람이 와도, IDE의 도움을 받아도 이렇게 빨리 짤 수는 없다. 심지어 그 시간 안에 코드에 대해 설명까지 한다? 비교 자체를 불허한다.
 
이런 모습은 개발을 막 시작했거나, 본인의 전문성이 아직 부족하다고 느끼는 입장에서 충분히 걱정을 하게 만들 수 있다. 나의 경우에도, Spring을 그럴 듯하게 사용할 정도로 학습하고, 백지에 Controller와 Service를 척척 작성하기까지 어느 정도 학습의 시간이 소요되었다. 그럼에도 코드를 작성하다 보면 이게 맞는 건가 싶었고, 그러다 보면 작성할 때 시간이 많이 드는 것 역시 피할 수 없었다.
 
단순히 지금만 해도 chatGPT는 이런 모습을 보여 준다. 심지어 이것은 무료로 사용할 수 있는 GPT-3.5이고, 현재 유료 회원만 제한적으로 사용할 수 있는 GPT-4는 훨씬 진보했다고 한다. 이런 속도라면 몇 년 이내에 개발자를 충분히 대체할 수 있지 않을까?
 

2. 왜 chatGPT를 경계하는가?

먼저 우리가 GPT에 기대하는 것을 정의하고 넘어갈 필요가 있다.
우리는 GPT에 질문을 하고, GPT가 원하는 답을 내놓길 기대한다. 이 답은 정확해야 하고, 합리적이야 하며, 당장 사용할 수 있어야 한다.
이것을 다른 말로, '합리적으로 사고하는 것을 기대한다'라고 요악할 수 있다. 즉, 우리가 chatGPT에 기대하는 것은,

문제에 대해 생각하고 답을 도출하는 것

이라고 정의할 수 있다. (추가로 이에 대해 설명하는 것을 기대할 수도 있지만, 답에 대한 설명에는 관심이 없는 사람이 대다수라고 감히 예상하겠다.)
 
오래부터 사고하는 것은 인간의 영역으로 간주되어 왔다. 주어진 상황에 대해 사고하고, 의견을 제시하고, 타인의 의견을 경청하며 더 나은 방향을 찾아 갔다. 이것이 반드시 정답이라는 보장은 없지만, 이런 과정은 인류 발전의 역사와 정통한다.
 
잠시 GPT를 제쳐 놓고, 우리 스스로를 돌아 보자. 우리 중에서 '충분히 사고한다'고 자부할 수 있는 사람은 얼마나 될까? 이 글을 읽는 당신은 매일매일 마주하는 문제에 대해 '왜 그럴까? 내 생각은 이렇다' 고 제시한다고 자신 있게 말할 수 있는가?
개발자라면, 누군가 "저는 이렇게 개발해야 한다고 봅니다." 라는 말에, 별다른 이의를 제기하지 않고 수긍한 경험이 있을 수 있다. 수긍이 나쁘다는 것은 아니다. 하지만 타인의 의견을 듣고 의문 없이 받아들이는 과정은 위험하다. 특히 인간은 각기 얽힌 복잡한 인간관계 상, 상호간에 쉽게 의견을 표출하지 못하는 경우도 많다. 회사에서 팀장님이 "저는 이런 구조로 진행해야 한다고 생각합니다." 라고 할 때, 여기에 "내 생각은 다르다"고 생각하는 사람이 흔할까?
 
내 경험일 뿐이므로 빙산의 일각이지만, 적어도 인간 사회에서 이러한 상황에 의문을 가지고 고민하는 사람은 많지 않다고 생각한다. 한 명이 의견을 내면 다른 사람들은 별다른 고민 없이 이에 동조하고, 그렇게 조직이 가지는 다양성이라는 장점은 퇴색된다. 내 의견을 내기 전에 남의 의견을 먼저 듣고, 그 의견이 심각하게 문제가 있지 않다고 판단되면 더 이상 복잡하게 생각하지 않고 따르는 것이다.
 
우리가 GPT에 기대하는 역할 역시 크게 다르지 않다. GPT가 어떤 답을 알려주는지 묻고, 이 답이 큰 문제가 없다고 생각하면 이를 그대로 사용하는 것이다. 이것은 굉장히 위험하다고 생각한다.
앞서 조직의 장점은 다양성이라고 언급한 바 있다. 세상의 생각에 정답은 없다. 어떤 문제에 대해 조직의 구성원은 각자 다른 의견을 낼 수 있고, 이러한 의견을 잘 조율해서 최선으로 판단되는 방향을 바라보는 것이 조직의 역할이다. 서로 다른 의견들이 충돌하며, 그러한 과정에서 각 사람들의 사고력 역시 훈련되는 것이다.
하지만 사람들이 GPT에 의존한다면, 어떤 일이 벌어질까? 각기 다른 배경을 가진 수많은 사람들이 GPT의 답에만 의존하게 된다. GPT의 사고력은 훈련되겠지만, 사람의 사고력은 퇴화되는 것이다. 이것이 반복되다 보면 사람은 그 스스로는 사고력 면에서 경쟁력을 가질 수 없게 된다. 그렇기 때문에 GPT를 경계하는 것이다.

3. 왜 사람들은 질문을 하지 않는가?

사고하는 것은 어려운 일이다. 어렵기 때문에, 사회적 분위기 때문에, 획일화된 교육 과정에 따르다 보니, 각각 스스로 사고할 일이 줄어들기 쉽다.
한국 사회에서는 특히 상급자의 의견에 의문을 가지는 것이 금기시 되는 분위기가 있다고 한다. 한국 외에서도, 강의 등의 공개된 곳에서 교수님의 의견에 의문을 가지는 사람은 흔치 않다. 또, 많은 사람들은 대학에 가고자, 취업을 하고자, 획일화된 교육 과정을 따르기도 한다. 이러한 과정들이 인간 개인의 질문력 퇴화에 일조한다고 생각한다.
 
가령, 예를 들어 보자. 한국에서 대학 입시를 위해서는 수능 시험을 준비해야 한다. 수능 수학 시험을 예로 들면 (참고로 나는 수능을 본 적이 없다), 주어진 시간 안에 주어진 범위 내에서 출제된 문제들을 풀어야 한다. 이 과정에서 문제를 푸는 훈련은 될 수 있지만, "왜 이러한가?" 라고 물어보는 기회는 흔치 않다. 왜 대학에 가야 하는가? 왜 대학을 가기 위해서 이런 문제를 풀어야 하는가? 이런 방식이 최선인가? 왜 극한은 엡실론-델타 논법을 통해 정의하였는가? 왜 사람이 책상을 밀면 책상은 밀려나는가? 다양한 분야에서 "왜?"라는 질문을 할 수 있지만 그렇게 할 수 있는 기회는 드물다.
 
하지만 세상을 바꾸는 것은 "왜?" 라는 질문에서 시작한다. 기존의 불문율에 의문을 가지고 이의를 제기하거나, 기존과는 다른 방식으로 주어진 문제를 바라보거나, 타인의 의견과 충돌하며 내가 모르는 관점에서의 이해를 하거나. 이런 과정들은 결국 질문을 하며 이루어지는 것이다. 이런 면에서 우리는 계속 질문해야 할 필요가 있다.
 
질문에 대해서는 내가 개인적으로 좋아하는 리처드 파인만 교수님의 영상이 있다.

4. 질문을 대하는 구성원과 리더의 자세, 사람과 AI의 자세

앞서 다소 철학적인 얘기를 많이 했다. 사실 앞의 내용은 내 생각을 정리한 것일 뿐이므로, 별로 중요하진 않다.
 
우리는 질문을 어떻게 대해야 할까?
앞서 '한 사람의 의견에 동조하는 현상'에 대해 언급한 바 있다. 어떤 리더를 중심으로 한 조직이라면, 조직 내에서 다양한 의견을 주고 받아 방향성을 정해야 한다고도 언급하였다.
이런 조직에서, 리더는 가급적 스스로의 의견을 먼저 제시하는 것을 절제해야 한다. 반대로 팀원들은 적극적으로 의견을 내야 한다. 리더가 의견을 먼저 제시하게 되면, 팀원들은 리더의 의견에 동조하기 쉽다. '우리의 리더이니 합리적인 의견이겠지', '나보다 경험과 실력이 앞서는 분의 의견이니 맞겠지' 등의 이유로 동조하게 되는 것이다. 이것은 조직의 다양성을 죽이는 결과를 낳는다. 따라서 리더는 최대한 의견을 제시하지 말고, 반대로 팀원들은 서로 의견을 주고 받으며 토론해야 한다.
 
AI를 상대로는 어떨까? 나는 사람이 팀원, AI가 리더의 역할을 맡아야 한다고 생각한다. "내가 먼저" 의견을 제시해야 한다. 예를 들면 이런 식이다.

chatGPT와 주고 받은 코드 리뷰

(맨 마지막 코드가 다소 긴 관계로, 아래 접은글에 별도로 포함시켰습니다.)

@Service
class CommentService(
    private val commentRepository: CommentRepository,
    private val commentQuery: CommentQuery
) {
    @Transactional(readOnly = true)
    fun getComments(): List<PlayerComments> {
        return commentRepository.findAll()
    }

    @Transactional(readOnly = true)
    fun getCommentsByIds(playerCommentIds: List<Long>): List<PlayerComments> {
        return commentRepository.findByPlayerCommentsIdIn(playerCommentIds)
    }

    @Transactional(readOnly = true)
    fun getPlayerComments(playerCommentIds: List<Long>?): List<PlayerComments> {
        return when {
            playerCommentIds.isNullOrEmpty() -> getComments()
            else -> getCommentsByIds(playerCommentIds)
        }
    }
}

@Component
class CommentQuery {
    fun buildQuery(playerCommentIds: List<Long>?): Specification<PlayerComments> {
        return when {
            playerCommentIds.isNullOrEmpty() -> Specification.where(null)
            else -> Specification.where(
                PlayerCommentSpecifications.withPlayerCommentIds(playerCommentIds)
            )
        }
    }
}

class PlayerCommentSpecifications {
    companion object {
        fun withPlayerCommentIds(playerCommentIds: List<Long>): Specification<PlayerComments> {
            return Specification { root, query, criteriaBuilder ->
                root.get<Long>("playerCommentId").`in`(playerCommentIds)
            }
        }
    }
}

아래의 과정을 거쳐 질문했다.

1. 내 코드를 리뷰해 달라. 컨트롤러의 요청을 레포지토리로 넘기는 코드다.
2. 너 (GPT)가 제시한 리뷰 중에서 동의할 수 없는 부분이 있다. 이유는 이렇다.
3. 내 코드가 단일 책임 원칙을 위반한다고 생각한다. 이 부분에 대해 어떻게 생각하는가?

앞서 "해줘" 식 질문에 비하면 훨씬 유용하지 않은가? 나는 chatGPT를 이런 식으로 사용해야 한다고 생각한다. 사용자는 스스로의 의견을 주도적으로 제시하고, GPT는 이에 대해 사용자와 토론을 하는 식이다.

5. 엔지니어는 어떤 역할을 하고, 어떻게 AI와 공존해야 하는가?

결국 앞서 소개한대로, 소프트웨어 엔지니어는 아래 역할을 해야 한다.

• 코드, 설계, 아키텍처 등에 대한 사고
• GPT로부터 받은 결과가 합당한지에 대한 사고

엔지니어는 스스로의 관점에서 개발하는 코드, 구조 설계, 전체적인 아키텍처 등에 대해 고민해야 한다. 이것은 GPT 등의 AI가 쉽게 대체할 수 없는 영역이라고 생각한다. 단순히 코드를 문법에 맞게, 답이 명확한 문제에 대해 작성하는 것은 AI가 할 수 있다.
개발이라는 것은 무엇일까? 코드에 비지니스 및 여러 현실의 로직을 녹여 내어, 세상에 존재하는 수천 수만가지의 상황 각각에 적합한 형태를 갖추도록 하는 것이라고 생각한다. 이런 면에서, AI가 범용적으로 제시하는 솔루션은 개인 각각에게 적합하지 않을 가능성이 있다. 이는 "정답이 없는 문제"에 대해 물어본 것이기 때문이다.
정답이 없는 기술적인 문제에 대한 고민은 엔지니어의 몫이라고 생각한다. 비지니스 도메인, 시간과 자금 상황, 구성원의 숙련도 등 다양한 변수가 주어졌을 때, 어떤 방향성을 가지고 개발해서 사용자에게 경험을 전달할지 고민하는 것은 엔지니어의 몫이다.
 
GPT는 또한, 항상 정답만 제시하는 것은 아니다. 이것 역시 예시가 있다.

Leetcode 87번 문제를 물어봤을 때

chatGPT는 알고리즘 문제도 풀 수 있다. 하지만 늘 올바른 답을 제시하지는 못한다.
Leetcode에 대해 몇 번 사용해 본 결과, 출제된 지 오래 되지 않은 문제일수록 GPT가 어려워하는 경향을 보인다. 이러한 답에 대한 검증 역시 엔지니어가 해야 한다.
기술이 발전함에 따라 해결될 수 있기도 하지만, 결국 GPT의 답을 검증하고 활용하는 것은 엔지니어의 몫이다. 특히 앞서 말한 바와 같이, 조직의 의견이 획일화됨에 따라 발전이 더뎌지게 되는 것을 방지하기 위해서라도, 엔지니어는 GPT를 사용하고, 검증하며, 의심해야 한다.

6. 결론

엔지니어는 기술을 사용자에게 전달하는 경험의 질을 높이기 위해 고민하고 또 고민하는 직업이다. 흔한 말이지만 GPT를 포함한 AI 역시 하나의 도구 (또는 수단)일 뿐이다. 엔지니어는 수단을 사용하되, 매몰되지 않아야 한다.
 
존 카멕 역시 비슷한 질문에 대해 아래와 같이 답하였다.

"프로덕트 스킬"을 키우고 이를 위한 가장 적합한 도구를 사용하면 된다. 지금은 직접 코딩하는 일이 될 수도 있고, 나중에는 AI를 가이드하는 일이 될 수도 있다. 뭐가 됐든 간에, 역할의 본질에 집중해야 한다.
소프트웨어는 사람들을 위해서 무언가를 이루는 수단일 뿐인데, 많은 프로그래머들은 이런 본질을 이해하지 못한다. 사용자에게 전달되는 경험에 집중하고, 이 과정을 위해 사용하는 도구에 매몰되어서는 안 된다.
 
결국 우리가 사용자에게 어떤 경험을 전달하기 위해 집중하고 있는지 고민해 보고, 이를 위한 방법을 다변화하면 될 일이다. 시대의 흐름에 따라 그 방법은 분명히 변화할 것이다.
 
따라서, 'AI가 개발자를 가까운 시일 내에 대체하지 않을까?' 에 대한 답변으로, 나는 '아니다'라고 말하겠다. 우리가 사고하는 것을 멈추지 않는다면 말이다.