Slack Code에 '이 에러 고쳐줘'만 보내면, 처음에 뭘 볼까?

게시판: 뉴스 | 작성자: admin | 작성일: 2026-08-26T20:18:00.779Z

Slack Code를 사용해 볼 수 있게 되면, 해보고 싶은 것이 있습니다.

깔끔하게 정리된 지시를 전달하는 것이 아니라, 굳이 정보를 줄여 보는 것입니다.

예를 들어, 데모용 웹 앱에서 오류를 하나 준비해서 Slack에 이것만 씁니다.

이 오류, 수정해 주세요.

오류의 원인도, 변경해야 할 파일도 알려주지 않습니다.

약간 심술궂은 테스트이지만, 실제 Slack에서는,

「이거 안 움직이는데요」

「어제부터 오류가 발생하고 있습니다」

~라는 한마디로부터 조사가 시작되기도 합니다.

그럴 때, Slack Code는 가장 먼저 무엇을 할까요?

※이 기사는 2026년 8월 26일 시점의 Slack 공식 정보를 바탕으로 한 '시도하기 전의 실험 메모'입니다. 제 환경에서 Slack Code의 실제 기기 검증은 아직 진행하지 않았습니다.

갑자기 코드 작성을 시작할까?

이번에 가장 보고 싶은 것은, 처음에 생성되는 코드가 아닙니다.

코드를 작성하기 전에, 무엇을 조사할 것인지입니다.

에러가 발생했다고 해서 그 원인이 반드시 해당 화면의 코드에 있는 것은 아닙니다.

의도적으로 원인을 단일화하지 않는다

테스트용 버그도, 보기만 해도 답을 알 수 있는 것으로는 만들지 않습니다.

예를 들어, 문의 폼에서 보내기 버튼을 누르면,

라는 오류만 표시되도록 설정합니다.

하지만, 이 메시지만으로는 원인을 알 수 없습니다.

고려할 만한 장소를 몇 가지 준비해 두겠습니다.

이 상태에서,

이 오류, 고쳐 주세요.

라고만 부탁드립니다.

여기서 확인하려는 것은, 처음 발견한 의심스러운 부분을 그 자리에서 바로 수정할 것인지, 아니면 여러 가능성을 확인한 뒤에 실제로 작업을 시작할 것인지입니다.

예를 들어 API 요청이 실패하고 있는데 화면 쪽의 오류 표시만 수정해서 '수정했습니다'라고 표시한다면, 겉으로는 바뀌어도 문제 자체는 그대로 남아 있습니다.

반대로, 로그나 관련 코드를 확인하여,

「송신 처리까지는 작동하고 있다」

API에서 오류가 반환되고 있습니다.

「환경 변수가 로드되지 않았습니다」

그런 순서로 원인을 좁혀 나간다면, 꽤 인상이 달라집니다.

질문해 올지도 모르니 지켜보고 싶네

또 하나 신경 쓰이는 점은 정보가 부족하다고 판단했을 때 어떻게 하느냐입니다.

예를 들어,

어떤 조작에서 오류가 발생하나요?

재현 절차를 알려주세요.

바로 직전에 변경한 부분이 있나요?

라고 물어볼 수도 있습니다.

반대로, 리포지토리나 로그만으로 충분히 판단할 수 있다면, 사람에게 묻지 않고 조사를 진행할 수도 있습니다.

어느 쪽이 옳다고는 정하지 않았습니다.

무엇이든 질문을 받게 되면 AI에게 부탁한 의미가 약해집니다.

하지만, 모르는 일까지 마음대로 정해지는 것도 곤란합니다.

보고 싶은 것은,

스스로 조사할 수 있는 부분과 사람에게 확인해야 할 부분을 어떻게 나눌 것인가?

바로 그겁니다.

고쳐졌다는 것만으로는 기록하지 않는다

테스트가 끝나면 성공인지 실패인지뿐만 아니라 조사 과정도 기록으로 남길 생각입니다.

한 번에 정답을 맞혔다고 해도, 우연히 맞은 것뿐이라면 다음 버그에서도 같은 방법이 통한다고는 할 수 없습니다.

반대로 시간이 조금 걸리더라도 로그를 확인하고, 후보를 좁히고, 원인을 설명한 후에 변경했다면, 그 편이 실제 업무에서는 더 안심이 될 것 같습니다.

특히 확인하고 싶은 것은 불필요한 변경이 있는지 여부입니다.

원인을 모른 채 여러 파일을 광범위하게 변경해 버리면, 최종적으로 오류가 사라져도 다른 문제를 늘리고 있을 가능성이 있습니다.

「고쳐졌다」는 결과만으로는, 여기서는 알 수 없습니다.

간단한 버그 때문에 다시 한 번 시도한다

첫 번째 테스트가 끝나면, 반대 패턴도 시도해 보고 싶습니다.

이번에는 원인이 꽤 명확한 버그를 준비합니다.

예를 들어, 존재하지 않는 변수명을 참조하기만 하는 것 같은 단순한 실수입니다.

이쪽에서도 매번 긴 조사를 시작하게 된다면 그것은 조금 곤란합니다.

원인이 명확할 때는 바로 고친다.

원인을 모를 때는 조사한다.

정보가 부족하면 확인한다.

이런 전환이 가능하다면, 단순히 신중할 뿐만 아니라 일에 맞춰 행동 방식을 바꿀 수 있다는 뜻입니다.

「코드를 쓰는 AI」보다 「검색할 수 있는 AI」인가

AI 코딩 도구를 보면 아무래도 생성된 코드에 눈이 갑니다.

몇 줄이나 썼을까.

얼마나 빨랐을까.

한 번에 테스트를 통과했나?

물론, 그것도 중요합니다.

하지만 실제 개발에서는,

무엇을 고쳐야 할지 모르는 시간

더 긴 경우도 있습니다.

그래서 Slack Code를 시험해 본다면, 처음부터 답을 알고 있는 일만이 아니라, 원인을 찾지 않으면 시작할 수 없는 일도 맡겨 보고 싶습니다.

「이 오류, 고쳐」

그것만 건네줬을 때, 바로 코드를 작성하는 건가.

로그를 보는 건가.