반응형

개발자에게 하면 안되는 말 3 가지

 - 간단한거죠? 일단 해주세요.

 - 이거(특정기간)까지 개발해주세요.

 - 타 서비스에서는 제공하던데요? 

반응형
반응형

ES6 for beginners
https://hackernoon.com/es6-for-beginners-f98120b57414

 

ES6 for beginners | HackerNoon

 

hackernoon.com

Topics I’m gonna cover in this post

  1. Let and Const
  2. Arrow functions
  3. Default parameters
  4. for of loop
  5. Spread attributes
  6. Maps
  7. Sets
  8. Static methods
  9. Getters and Setters

ES6 문법 + 활용 패턴 살펴보기
https://chancethecoder.tistory.com/30

  • 블록 범위 생성자 (Block-Scoped Constructs Let and Const)
  • 화살표 함수 (Arrow Functions)
  • 클래스 (Classes)
  • 프로미스 (Promises)
  • 비구조화 할당 (Destructuring Assignment)
  • 템플릿 리터럴 (Template Literals)
  • 향상된 객체 리터럴 (Enhanced Object Literals)
  • 기본 매개 변수 (Default Parameters)
  • 멀티 라인 문자열 (Multi-line Strings)
  • 모듈 (Modules)

자주 사용하는 ES6 문법 정리
https://velog.io/@kimhscom/JavaScript-%EC%9E%90%EC%A3%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-ES6-%EB%AC%B8%EB%B2%95-%EC%A0%95%EB%A6%AC

 

  1. 기본 매개 변수 (Default Parameters)
  2. 템플릿 리터럴 (Template Literals)
  3. 멀티 라인 문자열 (Multi-line Strings)
  4. 비구조화 할당 (Destructuring Assignment)
  5. 향상된 객체 리터럴 (Enhanced Object Literals)
  6. 화살표 함수 (Arrow Functions)
  7. Promises
  8. 블록 범위 생성자 Let 및 Const (Block-Scoped Constructs Let and Const)
  9. 클래스 (Classes)
  10. 모듈 (Modules)

 

.

개발자가 필히 알아야 할 ES6 10가지 기능

https://blog.asamaru.net/2017/08/14/top-10-es6-features/

 

개발자가 필히 알아야 할 ES6 10가지 기능

ES6(ECMAScript 표준의 6번째 에디션, ECMAScript2015)에 대한 이야기를 하기 전에 자바스크립트와 ECMAScript에 대한 것부터 간략히 소개한다. 넷스케이프(Netscape)에서 1995년 개발한 자바스크립트(javascript)

blog.asamaru.net

ES6(ECMAScript 표준의 6번째 에디션, ECMAScript2015)에 대한 이야기를 하기 전에 자바스크립트와 ECMAScript에 대한 것부터 간략히 소개한다.

넷스케이프(Netscape)에서 1995년 개발한 자바스크립트(javascript)는 웹 브라우저에서 동적인 기능을 제공하기 위한 언어다. 현재는 대부분의 브라우저에서 이 언어를 제공하고 있다. 그런데 표준 규격없이 여러 브라우저에서 독자적인 특성이 추가되면서 호환성 문제가 발생하기 시작했다. 이에 ECMA 국제 기구에서 “ECMAScript Standard”라는 표준을 만들게 되었다. 정확히 이야기 하자면 현재의 자바스크립트는 ECMAScript와 BOM(Browser Object Model)와 DOM(Document Object Model)을 포괄하는 개념이다.

개별적인 설명에 앞서 개발자가 필히 알아야 할 ES6 10가지 기능을 나열하자면 아래와 같다.

  1. 기본 매개 변수 (Default Parameters)
  2. 템플릿 리터럴 (Template Literals)
  3. 멀티 라인 문자열 (Multi-line Strings)
  4. 비구조화 할당 (Destructuring Assignment)
  5. 향상된 객체 리터럴 (Enhanced Object Literals)
  6. 화살표 함수 (Arrow Functions)
  7. Promises
  8. 블록 범위 생성자 Let 및 Const (Block-Scoped Constructs Let and Const)
  9. 클래스 (Classes)
  10. 모듈 (Modules)

 

1. 기본 매개 변수 (Default Parameters)

var link = function (height, color, url) {
    var height = height || 50
    var color = color || 'red'
    var url = url || 'http://azat.co'
    ...
}

함수에 넘겨주는 인자값에 대한 default 처리를 위해 위와 같이 처리 했었다면 ES6에서는 아래와 같이 간단히 처리할 수 있다.

var link = function(height = 50, color = 'red', url = 'http://azat.co') {
  ...
}

단, 주의해야 할 점이 있다. 인자값으로 0 또는 false가 입력될 때 두 예시의 결과는 다르다. ES5에서는 || 처리 시 0 또는 false 값이 입력 되어도 거짓이 되므로 기본값으로 대체된다. 하지만 ES6의 기본 매개 변수를 사용하면 undefined 를 제외한 입력된 모든 값(0, false, null 등)을 인정한다.

2. 템플릿 리터럴 (Template Literals)

ES5에서는 아래와 같이 문자열을 처리해야 했다.

var name = 'Your name is ' + first + ' ' + last + '.'
var url = 'http://localhost:3000/api/messages/' + id

하지만 ES6에서는 템플릿 리터럴을 제공하므로 "`" (back-ticked) 문자열 안에 ${NAME}라는 새로운 구문을 사용해서 아래와 같이 간단히 처리할 수 있다.

var name = `Your name is ${first} ${last}.`
var url = `http://localhost:3000/api/messages/${id}`

3. 멀티 라인 문자열 (Multi-line Strings)

ES5에서는 멀티 라인 문자열을 처리하기 위해 아래와 같은 방법들을 사용해야 했다.

var roadPoem = 'Then took the other, as just as fair,\n\t'
    + 'And having perhaps the better claim\n\t'
    + 'Because it was grassy and wanted wear,\n\t'
    + 'Though as for that the passing there\n\t'
    + 'Had worn them really about the same,\n\t'

var fourAgreements = 'You have the right to be you.\n\
    You can only be you when you do your best.'

하지만 ES6에서는 "`" (back-ticked) 문자열을 이용해서 아래와 같이 간단히 처리할 수 있다.

var roadPoem = `Then took the other, as just as fair,
    And having perhaps the better claim
    Because it was grassy and wanted wear,
    Though as for that the passing there
    Had worn them really about the same,`

var fourAgreements = `You have the right to be you.
    You can only be you when you do your best.`

4. 비구조화 할당 (Destructuring Assignment)

ES5에서는 구조화된 데이터를 변수로 받기 위해 아래와 같이 처리해야 했다.

// browser
var data = $('body').data(), // data has properties house and mouse
  house = data.house,
  mouse = data.mouse

// Node.js
var jsonMiddleware = require('body-parser').json

var body = req.body, // body has username and password
  username = body.username,
  password = body.password

하지만 ES6에서는 비구조화 할당을 사용해 아래와 같이 처리할 수 있다.

var {house, mouse} = $('body').data() // we'll get house and mouse variables

var {jsonMiddleware} = require('body-parser')

var {username, password} = req.body

주의할 점은 var로 할당하려는 변수명과 구조화된 데이터의 property명이 같아야 한다. 또한 구조화된 데이터가 아니라 배열의 경우 {} 대신 []를 사용해서 위와 유사하게 사용할 수 있다.

var [col1, col2]  = $('.column'),
  [line1, line2, line3, , line5] = file.split('\n')

5. 향상된 객체 리터럴 (Enhanced Object Literals)

ES5에서는 아래와 같이 JSON을 사용해서 객체 리터럴을 만들 수 있었다.

var serviceBase = {port: 3000, url: 'azat.co'},
    getAccounts = function(){return [1,2,3]}

var accountServiceES5 = {
  port: serviceBase.port,
  url: serviceBase.url,
  getAccounts: getAccounts,
  toString: function() {
    return JSON.stringify(this.valueOf())
  },
  getUrl: function() {return "http://" + this.url + ':' + this.port},
  valueOf_1_2_3: getAccounts()
}

위 예시와 달리 serviceBase를 확장하길 원한다면 Object.create 로 프로토타입화하여 상속 받을 수 있다.

var accountServiceES5ObjectCreate = {
  getAccounts: getAccounts,
  toString: function() {
    return JSON.stringify(this.valueOf())
  },
  getUrl: function() {return "http://" + this.url + ':' + this.port},
  valueOf_1_2_3: getAccounts()
}
accountServiceES5ObjectCreate.__proto__ = Object.create(serviceBase)

accountServiceES5ObjectCreate와 accountServiceES5는 동일하게 사용할 수 있으나 다른 구조를 가진다. accountServiceES5ObjectCreate는 accountServiceES5와 다르게 __proto__  port  url 속성을 가진 객체를 담고 있다.

ES6에서는 아래와 같이 처리할 수 있다.

var serviceBase = {port: 3000, url: 'azat.co'},
    getAccounts = function(){return [1,2,3]}
var accountService = {
    __proto__: serviceBase,
    getAccounts,
    toString() {
     return JSON.stringify((super.valueOf()))
    },
    getUrl() {return "http://" + this.url + ':' + this.port},
    [ 'valueOf_' + getAccounts().join('_') ]: getAccounts()
};

위 예시에 대해 ES5와의 차이를 요약하면 아래와 같다.

  • __proto__ 속성을 사용해서 바로 프로토타입을 설정할 수 있다.
  • getAccounts: getAccounts, 대신 getAccounts, 를 사용할 수 있다 (변수명으로 속성 이름을 지정).
  • [ 'valueOf_' + getAccounts().join('_') ] 와 같이 동적으로 속성 이름을 정의할 수 있다.

조금 더 자세한 내용을 보고 싶다면 gsfe/es2015features 를 참고하자.

6. 화살표 함수 (Arrow Functions)

화살표 함수는 항상 익명 함수이며 this의 값을 현재 문맥에 바인딩 시킨다.

아래의 예시는 화살표 함수가 지원되지 않는 ES5에서 this를 사용하기 위한 처리 예시다.

var _this = this
$('.btn').click(function(event){
  _this.sendData()
})

다음은 위 예시를 화살표 함수로 대체한 ES6 예시이다.

$('.btn').click((event) => {
  this.sendData()
})

다음은 ES5에서 call을 사용하여 context를 logUpperCase() 함수에 전달하는 또 다른 예제다.

var logUpperCase = function() {
  var _this = this

  this.string = this.string.toUpperCase()
  return function () {
    return console.log(_this.string)
  }
}
logUpperCase.call({ string: 'es6 rocks' })()

ES6에서는 화살표 함수를 사용하면 _this 를 사용할 필요가 없다.

var logUpperCase = function() {
  this.string = this.string.toUpperCase()
  return () => console.log(this.string)
}
logUpperCase.call({ string: 'es6 rocks' })()

화살표 함수가 한 줄의 명령문과 함께 사용되면 표현식이 되어 명령문의 결과를 암시적으로 반환한다.

ES5에서의 처리 예시.

var ids = ['5632953c4e345e145fdf2df8','563295464e345e145fdf2df9']
var messages = ids.map(function (value) {
  return "ID is " + value // explicit return
});

ES6에서의 처리 예시.

var ids = ['5632953c4e345e145fdf2df8','563295464e345e145fdf2df9']
var messages = ids.map(value => `ID is ${value}`) // implicit return

여러 개의 인자를 사용하는 경우는 변수 목록을 () 로 감싸줘야 한다.

ES5에서의 처리 예시.

var ids = ['5632953c4e345e145fdf2df8', '563295464e345e145fdf2df9'];
var messages = ids.map(function (value, index, list) {
  return 'ID of ' + index + ' element is ' + value + ' ' // explicit return
});

ES6에서의 처리 예시.

var ids = ['5632953c4e345e145fdf2df8','563295464e345e145fdf2df9']
var messages = ids.map((value, index, list) => `ID of ${index} element is ${value} `) // implicit return

또한 본문을 괄호로 감싸 객체 표현식을 반환할 수 있으며 ... 을 이용해 가변 파라미터를 사용할 수도 있다.

var ids = ['5632953c4e345e145fdf2df8','563295464e345e145fdf2df9']
var messages = ids.map((value, index, ...abc) => ({v:value, i:index, a:abc}))

7. Promises

ES6에서는 표준 Promise가 제공된다.

아래는 setTimeout 을 이용한 지연된 비동기 실행에 대한 ES5 예시다.

setTimeout(function(){
  console.log('Yay!')
}, 1000)

위 예시를 ES6에서 Promise를 사용해서 재작성하면 아래와 같다.

var wait1000 =  new Promise(function(resolve, reject) {
  setTimeout(resolve, 1000)
}).then(function() {
  console.log('Yay!')
})

위 예시를 화살표 함수를 사용해 재작성한 예시는 아래와 같다.

var wait1000 =  new Promise((resolve, reject)=> {
  setTimeout(resolve, 1000)
}).then(()=> {
  console.log('Yay!')
})

ES5 보다 ES6의 Promise를 사용한 예시가 더 복잡해 보이지만 아래와 같이 중첩된 setTimeout 예시를 보면 Promise의 이점을 확인할 수 있다.

setTimeout(function(){
  console.log('Yay!')
  setTimeout(function(){
    console.log('Wheeyee!')
  }, 1000)
}, 1000)

아래는 ES6 Promise 로 작성된 예시.

var wait1000 =  ()=> new Promise((resolve, reject)=> {setTimeout(resolve, 1000)})

wait1000()
    .then(function() {
        console.log('Yay!')
        return wait1000()
    })
    .then(function() {
        console.log('Wheeyee!')
    });

조금 더 자세한 내용을 보고 싶다면 Introduction to ES6 Promises – The Four Functions You Need To Avoid Callback Hell 또는 gsfe/es2015features 를 참고하자.

8. 블록 범위 생성자 Let 및 Const (Block-Scoped Constructs Let and Const)

let과 const는 중괄호("{}")로 정의된 블록으로 유효 범위(스코프)를 지정하는 새로운 var이다. 단, let은 변수를 const는 상수를 선언한다.

function calculateTotalAmount (vip) {
  var amount = 0
  if (vip) {
    var amount = 1
  }
  { // more crazy blocks!
    var amount = 100
    {
      var amount = 1000
      }
  }
  return amount
}
console.log(calculateTotalAmount(true))

위 예시의 결과는 1000 이다. var는 전역 또는 함수 내부로 유효 범위를 갖기 때문에 예시에 사용된 함수 내부의 "{}" 들은 아무런 역할을 하지 못한다. 아래는 위 예시에서 var를 let으로 바꾼 ES6 예시다.

function calculateTotalAmount (vip) {
  var amount = 0 // probably should also be let, but you can mix var and let
  if (vip) {
    let amount = 1 // first amount is still 0
  }
  { // more crazy blocks!
    let amount = 100 // first amount is still 0
    {
      let amount = 1000 // first amount is still 0
      }
  }
  return amount
}
console.log(calculateTotalAmount(true))

이 예시의 결과는 0 이다. let 으로 선언된 변수는 "{}" 블록 내부로 유효 범위가 한정되므로 100, 1000으로 할당된 변수는 해당 블록 내부에서만 유효하기 때문이다. if 블록 내부에서 let으로 선언된 amount 또한 해당 if 블록 내에서만 유효하므로 아무런 변경이 일어나지 않는다.

아래의 예시는 const를 사용한 예시다. const는 상수를 선언하는 것으로 여러번 선언될 수 없지만 let과 같이 블록 내부로 유효 범위가 한정되므로 아래의 예시는 오류가 발생하지 않는다.

function calculateTotalAmount (vip) {
  const amount = 0
  if (vip) {
    const amount = 1
  }
  { // more crazy blocks!
    const amount = 100
    {
      const amount = 1000
      }
  }
  return amount
}
console.log(calculateTotalAmount(true))

9. 클래스 (Classes)

ES6에는 class 키워드가 추가되어 ES5의 prototype 기반 상속보다 명확하게 class를 정의할 수 있다. get  set 키워드 외에도 static 키워드를 사용해 static 메소드를 정의하는 것도 가능하다.

class baseModel {
  constructor(options = {}, data = []) { // class constructor
        this.name = 'Base'
    this.url = 'http://azat.co/api'
        this.data = data
    this.options = options
    }

    getName() { // class method
        console.log(`Class name: ${this.name}`)
    }
}

constructor 는 class 내부에 하나만 존재할 수 있으며 메소드 정의에 function 또는 콜론(":")이 더이상 필요하지 않다. 단, property의 경우 메소드와 달리 생성자에서 값을 할당해야 한다.

또한 아래의 예시와 같이 class NAME extends PARENT_NAME 형식으로 상속이 가능하다. 상속시 부모 생성자를 호출하기 위해 super() 를 사용할 수 있다. 생성자가 아닌 메소드에서는 super 키워드를 사용해서 부모 메소드에 접근한다.

class AccountModel extends baseModel {
    constructor(options, data) {
      super({private: true}, ['32113123123', '524214691']) //call the parent method with super
      this.name = 'Account Model'
      this.url +='/accounts/'
    }

    get accountsData() { //calculated attribute getter
      // ... make XHR
      return this.data
    }
}

class 는 get  set 키워드를 사용할 수 있으며 선언된 함수는 아래와 같이 사용할 수 있다.

let accounts = new AccountModel(5)
accounts.getName()
console.log('Data is %s', accounts.accountsData)

위 예시를 실행하면 아래와 같은 결과를 얻을 수 있다.

Class name: Account Model
Data is %s 32113123123,524214691

10. 모듈 (Modules)

ES6 에서 모듈을 공식적으로 제공하기 전까지는 CommonJS, AMD, RequireJS 등의 비공식 모듈 스펙을 사용해 왔다. ES6에서 제공하는 모듈 스펙은 기존과 유사하지만 차이가 있다.

ES5에서 CommonJS를 이용해서 모듈을 사용하는 예시는 아래와 같다(module.js).

module.exports = {
  port: 3000,
  getAccounts: function() {
    ...
  }
}

main.js 파일에서 위에서 정의한 모듈을 불러서 사용하는 예시는 아래와 같다.

var service = require('module.js')
console.log(service.port) // 3000

여기서 부터는 ES6의 import  export 를 사용해서 유사한 기능을 구현한 예시다(module.js).

export var port = 3000
export function getAccounts(url) {
  ...
}

main.js 파일에서는 import 를 사용해서 module.js 모듈을 불러올 수 있다.

import {port, getAccounts} from 'module'
console.log(port) // 3000

위와 유사하지만 export 된 모든 변수를 아래와 같이 하나의 구조화된 데이터로 받을 수도 있다.

import * as service from 'module'
console.log(service.port) // 3000

ES6 당장 사용할 수 있는 방법 (Babel)

ES6는 확정되었지만 아직 모든 브라우저에서 완전하게 지원되지 않는다. 따라서 지금 당장 ES6 사용하고 싶다면 Babel과 같은 컴파일러를 사용해야 한다. Babel은 독립 실행형 도구로 실행하거나 빌드 시스템에서 사용할 수 있다. Grunt, Gulp  Webpack 용 Babel 플러그인이 있다.

ES6의 기타 특징

참고로 이 외에도 여러가지 특징이 있으니 관심이 있다면 git.io/es6features를 번역한 ECMAScript 6 Features를 참고하면 된다.

반응형
반응형

frontend-evolution

 

https://github.com/ManzDev/frontend-evolution

 

GitHub - ManzDev/frontend-evolution: Frontend Evolution timeline (1995-2019)

Frontend Evolution timeline (1995-2019). Contribute to ManzDev/frontend-evolution development by creating an account on GitHub.

github.com

https://velog.io/@teo/full-stack-developer#%ED%92%80%EC%8A%A4%ED%83%9D-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94-%EA%B5%AC%EA%B8%80%EC%97%90%EA%B2%8C-%EB%AC%BC%EC%96%B4%EB%B4%A4%EC%8A%B5%EB%8B%88%EB%8B%A4

 

풀스택 개발자에 대해서 어떻게 생각하나요?

혹시 풀스택 개발자에 대해서 어떻게 생각하시나요?? 프론트도 재밌고 백엔드도 재밌는데 둘다 하려고 하니 T자형 개발자가 되기 힘들고, 또 "풀스택개발자는 상상속 유니콘이다" 라는 말도 있

velog.io

 

반응형
반응형

좋은 동료가 되기 위한 10가지 방법

제가 수구를 처음 배울 때에, 코치가 해줬던 말이 잊혀지지 않습니다. 그는 “뛰어난 선수는 주변 선수들을 뛰어난 선수처럼 보이게 한다.” 라고 했습니다. 뛰어난 선수는 잘못된 던지기를 예상하고 미리 움직여 어떤 패스라도 잡을 수 있습니다. 뛰어난 선수가 공을 다시 패스할 때는 다른 사람이 쉽게 잡을 수 있도록 공을 던집니다.

 

오늘날의 소프트웨어 개발은 팀 스포츠와 같습니다. 수구에서와 같이 뛰어난 소프트웨어 시스템은 혼자서 만들 수 없습니다. 그래서 처음 10배 뛰어난 엔지니어에 대한 컨셉을 들었을 때는 혼란스러웠습니다. 어떻게 한 명의 뛰어난 사람이 팀웍을 이길 수 있을까? 제 경험상 성공을 위해 각 개인의 뛰어남은 필수 요소지만, 충분 요소는 아니었습니다. 개개인의 업적에 초점을 맞추면 좋은 소프트웨어 개발을 위해 팀이 필요하다는 큰 그림을 못 보게 됩니다. 그래서 10배 뛰어난 엔지니어에 대한 정의를 이렇게 바꿔봤습니다.

10배 뛰어난 엔지니어는 남들보다 10배 뛰어난 사람이 아니라, 주변 사람을 10배 뛰어나게 만드는 사람이다.

 

수 년에 걸친 개인적인 경험과 효율적인 팀 구성과 발전에 대한 연구를 조합하여, 개개인의 경험과 무관하게 10배 나은 동료가 될 수 있는 방법을 목록으로 만들었습니다. 훌륭한 동료가 되기 위한 일반적인 조언들과 함께, 다양한 배경을 가진 사람들 속에서 어떻게 좋은 동료가 될 수 있는가에 중점을 두었습니다.

 

더 나은 동료가 되기 위한 10가지 방법

 

  • 정서적으로 안전한 환경 만들기
  • 모두 동등하게 참여하도록 격려하기
  • 공명정대하게 공로 나누기
  • 회의에서 들리지 않는 목소리를 키우기
  • 개인적인 비판이 아닌 건설적이고 실용적인 피드백
  • 자기 자신과 타인에게 책임감 가지기
  • 팀에 가치있는 분야에 투자하기
  • 직장내 다양성, 포괄성 그리고 동등함에 대해 배우기
  • 성장에 대한 마음가짐 유지하기
  • 직장내 평등에 대한 회사 정책에 소리내기

 

1. 정서적으로 안전한 환경 만들기

 

2012년, 구글은 아리스토텔레스 프로젝트를 시작했습니다. 이는 구글 내의 많은 팀을 조사하여 몇몇 팀들이 왜 다른 팀보다 좋은 성과를 내는지 분석하는 프로젝트입니다 1. 이 연구는 팀의 생산성이 높고 낮음에 오직 두 가지 차이점만이 있음을 밝혀냈습니다. 그 중 하나는 연구자들이 정서적 안전함이라 부르는 요소였습니다. 하버드 비즈니스 스쿨의 Amy Edmondson 교수는 이것을 “팀내에서 대인 관계의 위험 감수를 할 필요가 없다는 구성원 사이에 공유되는 믿음” 즉, “발언에 대해 치욕스럽게 하거나, 거부하거나 처벌하지 않을 것이라는 확신” 이라고 설명합니다. 정서적 안전함을 갖춘 환경을 조성하는 것은 팀원들이 서로를 신뢰하고 업무에 대해 자유롭게 의견을 나눌 수 있는 공간을 만듭니다. 사무실에서 정서적으로 안전한 환경을 조성하는 몇 가지 방법이 있습니다.

  •  
  • 비판적이지 않은 방법으로 다른 사람의 아이디어와 감정을 인정해주세요. 인정은 판단하거나 평가내리는 것에서 분리되어야 합니다.
  • 팀 동료의 의견에 “응, 그리고” 같은 자세로 답해 대화를 이어나가 주세요 (즉흥 연기와 같이 말이죠!) 2.
  • 의심스러워도, 믿어주세요. 당신이 믿을 때까지 그들로 하여금 증명하도록 하지 말고, 틀렸다고 밝혀지기 전까지는 일단 동료를 믿어주세요.

 

2. 모두 동등하게 참여하도록 격려하기

 

아리스토텔레스 프로젝트에서 밝혀낸 생산적인 팀을 구성하는 두 번째 요소는 – 학술적으로 말하자면 – ‘균등 분배된 발언권’ 현상입니다. 기본적으로, 효율적인 팀에 속한 사람들은 동등하게 참여한다는 뜻입니다. 모든 구성원이 매 회의마다 동등하게 말해야한다는 것을 의미하는게 아니라, 시간이 지남에 따라 팀원 개개인이 동등하게 기여해야 한다는 것입니다. 그렇다면 팀원 개개인이 동등하게 기여하는 팀 문화를 어떻게 조성할 수 있을까요?

  •  
  • 회의시간에 동료에게 의견을 물어보세요.
  • “내 생각엔” 그리고 “아마도” 같은 표현으로 토론을 시작해보세요. (저는 이것을 ‘여성스럽게 말하면 어떨까?’ 화법으로 부릅니다)
  • 편하게 자주 얘기하세요 3.
  • 혼자 떠들고 있는 사람이 있으면 알려주고, 모두가 말할 수 있는 분위기를 만들어주세요.

 

3. 공명정대하게 공로 나누기

 

업무에 대한 공로를 정확하게 분배하는 것은 팀과 조직 내에 신뢰를 형성하는데 매우 중요한 일입니다 4. 우리들 중 많은 이들이 자신의 작업에 대해 제대로 인정받지 못하거나, 엉뚱한 사람이 공을 가져간 경험이 있을겁니다.

공로를 인정하는 일은 그 사람을 뛰어나 보이게 만드는 것뿐 아니라, 인정하는 사람도 같이 좋아보이게 합니다. 다른 사람들을 인정하는 사람들은 그렇지 않은 사람이 비해 더 똑똑해 보이고 호감이 갑니다. 서로 윈–윈 하는 일이기 때문에 동료를 칭찬하지 않을 이유가 없습니다.

다른 사람의 공로를 인정하는 문화를 만들기 위해서는 어떤 노력이 필요할까요?

 

  • 프로젝트가 끝날때 마다 당신을 도와준 사람들에게 감사를 전하세요.
  • 묵묵히 일을 하고 자랑하지 않는 사람들, 새로 들어와서 아직 자신이 없는 사람들에게 특히 주목하세요.
  • 누군가를 칭찬하고 공로를 인정할 때, 정직하고 구체적이며 진실되게 전하세요.

 

4. 회의에서 들리지 않는 목소리를 키우기

 

 

2009년, 오바마 대통령의 여성 스태프 그룹이 함께 ‘증폭’이라는 전략을 만들었습니다 5. 그들은 남성 중심적인 사무 환경에서 여성들이 겪는 여러 어려움에 직면해 있었습니다. 여성들이 중요한 회의에 참석하는 동안 그들은 간과되거나 소외되는 문제가 있었습니다. 그래서 그들은 목소리를 서로 증폭하기로 했습니다. 여성 스태프가 핵심 아이디어를 만들면 다른 여성들이 그것을 반복하고 계속해서 원 저자를 알려, 그 아이디어가 누구에게서 나온 것인지 알아차릴 수 밖에 없도록 합니다. 오바마 대통령은 이 사실을 알고, 여성 스태프들에 더 많은 기회를 주도록 했습니다. 그의 두 번째 임기에는 성별이 더 동등하게 나뉘었으며, 부서 중 절반은 여성이 이끌게 되었습니다.

이 일은 매우 단순하지만, 누구나 동료를 위해 할 수 있는 시행할 수 있는 구체적인 방법입니다. 소외되거나 간과되는 사람에게 귀기울여, 그들의 목소리를 증폭시켜주세요. 여성들이 자주 말하게 되는 것이 일상이 되어도 6, 부드럽게 말하거나 수줍어 하는 사람, 내성적인 사람에게도 일어날 수 있는 일입니다.

 

5. 개인적인 비판이 아닌 건설적이고 실용적인 피드백

 

 

비판받는 것을 싫어하는 것은 매우 일반적인 일이고, 신중하지 못하거나 건설적이지 않은 비판은 사람들의 생산성마저 깎아내릴 수 있습니다 7. 앞서 얘기했던 것과 같이 당신의 피드백이 사려깊고 건설적인지 아닌지가 좋은 동료가 되는데 있어 정말로 중요합니다. 뿐만 아니라, 피드백은 편향을 불러올 수 있으므로, 피드백을 잘 전달하는 것에 대한 학습은 다양한 팀에게 있어 아무리 시간을 들여도 아깝지 않은 일입니다.

예를 들면, 여성들이 받는 비난이나 조롱을 남성들은 받지 않는다는 것은 누구나 알고 있습니다. 여성들은 ‘된장녀’, ‘뻔뻔한’, ‘공격적’ 같은 이야기를 남성에 비해 많이 듣습니다. 2014년에 Textio의 설립자이자 CEO인 Kieran Snyder는 이 일이 사실인지 확인하고자 했습니다 8. 남성 105명과 여성 75명, 총 180명으로부터 248개의 리뷰를 수집하고 내용을 분석했습니다. 그게 사실이라는 것을 이미 알고 있음에도 놀라울만한 결과가 나왔습니다. 87.9%의 여성이 조롱이나 부정적인 피드백을 받았는데, 남성의 경우 58.9%에 불과했습니다. 내용을 따지고 보면 이 차이는 더 심해집니다. 76%의 여성이 업무 외의 개인적인 부분에서 비난을 받는 동안 2%의 남성만이 그러한 비난을 받았습니다.

더 나은 피드백을 주기 위한 다음의 방법을 제안합니다.

 

  • 피드백을 받을 수 있는 상황인지 먼저 물어보세요.
  • 그 사람의 업무적인 부분에만 초점을 두고 피드백하세요.
  • 어떻게 하면 더 개선할 수 있는지 얘기해주세요. 문제를 명확하게 하고 어떻게 하면 대상자가 개선할 수 있는지에 대한 생각을 얘기하세요.
  • 개인적인 비난은 하지 마세요. 그런 부분에 대한 피드백이 정말 필요하다고 생각한다면, 관리자나 HR 담당자와 얘기하여 내용을 정리하고 검토하세요.

 

6. 자기 자신과 타인에게 책임감 가지기

 

얼마 전에 대학시절 축구 선수로 활동했던 친구 James를 만났습니다. 그는 지금 한 스타트업의 COO로 있는데, 그가 말하길 많은 시간을 직원들에게 기본적인 팀웍에 해당하는 것을 가르치는데 쓴다고 합니다. 책임감에 관한 것에 중점을 두고요. 예전 일을 생각해보면, James는 수백 수천 시간을 좋은 팀원이 되기 위해 연습하는데 썼습니다. 팀으로 잘 굴러가기 위한 일들이 그에게는 명확하게 보이겠지만, 다른 사람들에게는 – 특히 책임감에 관해서라면 – 명확하지 않을 수 있습니다. 축구는 강한 책임감이 필요한 운동이고, 선수들에게 서로 책임을 지게하기 위해서는 시간을 들여 연습하는 것 외에 긍정적인 태도, 팀원을 독려하는 일, 그리고 유능함에 대한 높은 기준을 유지하는 방법이 있습니다. 자기 자신과 동료 모두가 책임감을 높이기 위해서는 이런 방법을 사용해보세요.

  •  
  • 일을 가능한한 제 시간안에 할 수 있도록 합니다 (엔지니어들에게 이게 참 어려운 일인건 알지만, 작은 프로젝트부터 정확성을 높여 나간다면 책임감 향상에 도움이 될겁니다).
  • Jeff Lawson이 창업자들에게 가장 중요하다고 말하는 것은 “한다고 말했던 일을 해라” 입니다. (역주: Jeff Lawson은 Twilio의 창업자)
  • 다른 사람을 돕다 보면, 다른 사람에게 도움을 구하기도 합니다.
  • 큰 프로젝트나 이슈에 대해서 팀의 일이 끝날 때까지 함께합니다 9 (실제로 남아도 좋고, Slack 같은 원격 도구라도 좋습니다).

 

7. 팀에 가치있는 분야에 투자하기

 

10배 뛰어난 엔지니어 되기에 대해 얘기하면 사람들은 흔히 다른 사람보다 뛰어난 것으로 받아들입니다. 개인적인 역량이 뛰어난 것은 좋은 동료가 되기에 필수 요소일 뿐이고, 결국 팀을 위해서 뭔가 해야합니다. 어떤 분야에 뛰어난 사람이 되려고 한다면, 그 분야는 당신에게 진정한 동기부여가 가능한 것이어야 합니다. 당신에게 에너지를 주는 일이면서 동시에 현재 보유한 능력과 관심사와도 맞아야겠죠. 개인 지식 기반이 점점 더 전문화되고 있기 때문에, 뛰어난 사람이 되기 위해서는 정말 많은 시간과 에너지를 투자해야 합니다 10. 잠깐으로 되는 일이 아니기 때문에 진정 즐길 수 있는 일이어야 합니다. 자기 계발/개발에 대한 이 사회의 관심이 큰 것으로 알고 있으니, 해당 분야에 대해서는 도서나 블로그 등을 통해 발전시키는 것도 좋겠습니다.

 

8. 직장내 다양성, 포괄성 그리고 동등함에 대해 배우기

 

다양성과 포괄성은 팀 스포츠와 같이, 모든 직급의 모든 사람이 함께 해야합니다. 좋은 동료가 되기 위한 최고의 방법 중 하나는 성차별과 인종 차별이 직장에서 어떻게 이뤄지고 있는지 스스로 학습하는 것입니다. 프로그래밍 언어와 툴 사용법을 익히는 것만큼이나 평등한 작업 환경을 구성하는 것에 대한 글과 연구에 관심을 가지고 따라잡는 일도 중요합니다.

“깨우친 남성의 뒤에는 항상 페미니스트가 있다”라는 농담이 있는데, 아마 깨우친 백인들도 유색 인종들이 받은 핍박 속에서 태어났을 겁니다. 이제 바꿉시다. 누구나 읽고 연구할 수 있는 시대입니다.

 

  • 모든 것을 읽으세요.
  • 사람들에게 읽기를 권유하거나 메일링 리스트에 가입하라 하세요.
  • 최대한 많이 들으세요.
  • 당신의 의견은 교육받은 만큼 그 가치가 올라갑니다. 그러니 스스로 깨우치지 못하면 당신의 의견은 별 의미가 없습니다.

 

9. 성장에 대한 마음가짐 유지하기

 

30년 전에, 심리학자 Carol Dweck은 실패로부터의 추진력에 관심을 가졌습니다 11. 그녀와 그녀의 연구팀은 학생들이 작은 실수로도 무너지는 반면, 실패로부터 회복하는 학생들도 있음을 알게되었습니다. 그 이유가 궁금했습니다. 수 천명의 아이들을 연구한 결과, ‘성장하고자 하는 마음가짐’이라는 용어를 얻어냈습니다. 이는 능력과 지능을 발전시킬 수 있다는 믿음을 의미합니다. 이런 마음가짐이 있는 학생들은 실패에서도 배워 능력과 지능을 키울수 있다는 믿음이 있는데, 지능은 발전되지 않는다고 믿는 학생들이 작은 실수로도 무너지는 것과 비교가 됩니다.

 

  • 주어진 시간과 노력, 인터넷으로 무엇이든 배울수 있음을 명심하세요.
  • 어떻게 발전할 수 있었는가에 대한 피드백을 준비하세요.
  • 결승선이 없는 일입니다. 좋은 엔지니어와 동료가 되는 것은 평생, 매일의 수련입니다.

 

10. 직장내 평등에 대한 회사 정책에 소리내기

 

마지막으로, 팀의 모든 동료를 위해 더 평등하고 포괄적인 업무 환경을 조성할 수 있다고 생각하는 것을 얘기하세요. 조직 내에서 어떤 위치에 있더라도 작업 환경을 개선하는 정책에 대해서는 지지할 수 있습니다. 8번에서 얘기한 것들을 읽고 연구한다면 더 쉽게 진행할 수 있습니다. 검증된 조직적인 변화의 예를 몇 가지 들어보겠습니다.

  •  
  •  
  • The Rooney Rule: 중요한 직책을 채용할 때, 소수 인종을 반드시 한 명 이상 후보에 넣어야 합니다 12.
  • 승진 대상 후보자 평가는 혼자가 아닌 단체로 해야합니다. 13
  • 회의, 급여, 계획과 같은 내부 절차의 투명성을 만들어가야 합니다.

 

맺음말

 

수구 선수 생활을 그만둔 뒤에 코치 생활을 시작했고, 가르쳤던 아이들에게 항상 얘기했던 하나는 이것입니다. 승률은 개인의 재능 합에 팀으로 얼마나 잘하는가를 곱한 것이라고요.

승률 = Σ(재능) * 팀웍

 

일하는 것에 적용한다면, 수식은 이렇게 됩니다.

생산성 = Σ(재능) * 팀웍


팀웍이 강한 팀은 개개인의 능력이 더 뛰어난 팀보다 더 뛰어날 수 있습니다. 이런 일들을 스포츠와 기술업계, 사회에서 수도 없이 보아왔습니다. 소규모 팀이라도 팀으로써 잘 기능할 때, 엄청난 소프트웨어를 만들어내는 일은 결코 우연이 아닙니다. 자, 그러니 개인적으로 우수해지는 것 외에, 제 코치가 저에게 말해준 것처럼, 진정한 뛰어남은 당신이 얼마나 대단한 사람이냐가 아니라 당신 주변을 얼마나 대단하게 만드느냐에서 온다는 것을 잊지 않길 바랍니다.

 

 

 

 

 

 

https://www.kateheddleston.com/blog/becoming-a-10x-developer

 

Becoming a 10x Developer

When I was first learning to play water polo, a coach told me something I’ve never forgotten. He said, “Great players make everyone around them look like great players.” A great player can catch any pass, anticipating imperfect throws and getting int

www.kateheddleston.com

 

반응형
반응형

화성에서 온 개발자, 금성에서 온 기획자

live.lge.co.kr/it_casting/

 

화성에서 온 개발자, 금성에서 온 기획자 | | LiVE LG - LG전자 미디어플랫폼

IT 업계에 계시는 분들이라면 여러 프로젝트를 통해 다양한 캐릭터를 가진 기획자와 개발자들을 경험하셨을 겁니다. 기획자와 개발자는 '화성에서 온 남자 금성에서 온 여자'의 남자와 여자처럼

live.lge.co.kr

T 업계에 계시는 분들이라면 여러 프로젝트를 통해 다양한 캐릭터를 가진 기획자와 개발자들을 경험하셨을 겁니다. 기획자와 개발자는 ‘화성에서 온 남자 금성에서 온 여자’의 남자와 여자처럼 아주 가까운 대상이지만 때로는 서로 무슨 생각을 가지고 있는지 도저히 이해하기 힘든 대상이기도 합니다. 오늘은 제가 그들을 이해하기 위한 첫 번째 시간으로 기획자와 개발자에 있어 가장 중요한 역량에 대해 이야기 해 볼까 합니다.

 

 

기획자란 사전적 의미 그대로 ‘일을 꾀하여 계획하는 사람’입니다. 즉, 어떤 문제나 과제가 있다면 이를 파악하고, 분석한 뒤 실제 해결할 수 있는 방법과 실행을 위한 준비를 거쳐 결과물이 잘 만들어질 수 있도록 매개하는 사람입니다. 이에 반해 개발자란 ‘새로운 물건을 만들거나 새로운 생각을 내놓는 사람’이라는 의미로 어떤 과제가 주어지면 이를 실제 실행에 옮겨 결과물을 만들어내는 역할을 담당합니다.

즉, 기획자가 무엇을 만들 것인지 잘 설계하면 개발자는 그 결과물을 세상에 선보일 수 있도록 실현을 해주는 존재인 것입니다. IT 업계의 기획자와 개발자도 예외가 아닙니다. 어떤 제품 또는 서비스를 기획자가 기획하면, 실제 개발자는 고객이 사용하게 되는 제품 또는 서비스를 만들어주는 역할을 합니다.

 

이렇듯 서로 비슷한 듯 하면서 다른 두 그룹인 기획자와 개발자가 갖춰야 할 가장 중요한 역량이 무엇일까요? 저는 단연 ‘커뮤니케이션’을 이야기합니다. 다만, 기획자와 개발자가 집중하는 커뮤니케이션 대상이 다를 뿐인 것입니다. 기획자는 이해관계자들과 수 많은 커뮤니케이션을 하고, 개발자는 컴퓨터와 커뮤니케이션을 합니다. 이런 커뮤니케이션 능력이 바로 각자의 역할에서 얼마만큼의 성과를 낼 수 있는지의 중요한 지표가 되는 것이죠.

 

기획자는 다양한 이해관계자들과 여러 수준의 커뮤니케이션을 합니다. 이를 통해 그들이 꾀하는 일을 추진할 수 있도록 상대방을 설득하고, 때로는 개발자들과의 커뮤니케이션을 통해 원하는 결과물을 만들 수 있도록 설득합니다. 프레젠테이션 자료부터 프로젝트 개요까지 그들이 작성하는 모든 자료와 문서는 커뮤니케이션을 위해 사용된다고 해도 과언이 아닙니다. 다른 사람들에게 그들의 생각을 전하기 위한 과정인 것이지요.

 

반면 개발자는 주어진 목표와 일정 내에 결과물을 만들기 위해 그들만의 커뮤니케이션 방식인 프로그래밍 언어로 컴퓨터와 커뮤니케이션 합니다. 하루 일과 중 많은 시간을 일반인들이 이해하기 힘든 프로그래밍 코드를 작성하고, 컴퓨터와 대화를 주고 받는 과정을 통해 결과물을 만들어 가는 것입니다. 프로그래밍에 대한 지식이 없다면 무엇을 의미하는지 이해하기 힘든 것이 바로 프로그래밍 언어이지만 우리가 이야기하는 일상적 언어처럼 고유의 정해진 문법이 있고, 같은 결과물을 만드는 데에도 우리의 일상 언어처럼 표현방법이 무수히 많이 있습니다. 이를 얼마나 효과적으로 표현하고, 잘 다듬는지가 바로 개발자의 역량인 것입니다.

 

“멋진 서비스를 기획하여 오랜 시간을 설명하였는데 개발자가 나의 의도와는 전혀 다른 결과물을 만들어내는 상황을 경험하셨습니까?”, “분명 기획한 결과물대로 개발을 하였는데 만족스럽지 않다고 다시 개발해달라는 기획자가 이해되지 않으십니까?” 서로에 대해 오해하지 말고 각자가 중요하게 생각하는 커뮤니케이션 대상이 다르다는 것을 이해하고, 인정해 보시기 바랍니다. 그들에게는 커뮤니케이션 역량이 바로 능력을 보여주는 덕목이기 때문입니다.

이 세상의 수 많은 기획자와 개발자의 오해가 사라지는 그날을 위해…

 

반응형
반응형

개발자가 기획자를 쓸모 없다고 오해하는 이유

live.lge.co.kr/it_casting_3/

 

개발자가 기획자를 쓸모 없다고 오해하는 이유 | | LiVE LG - LG전자 미디어플랫폼

개발자들이 기획자에 대해 가지는 편견 중 하나가 바로 '기획자가 무엇을 하는지 모르겠다'는 것입니다. 실제 개발자 커뮤니티를 보면 기획자에 대한 불만의 글들을 종종 볼 수 있답니다. 기획

live.lge.co.kr

개발자들이 기획자에 대해 가지는 편견 중 하나가 바로 ‘기획자가 무엇을 하는지 모르겠다’는 것입니다. 실제 개발자 커뮤니티를 보면 기획자에 대한 불만의 글들을 종종 볼 수 있답니다. 기획자의 기획물이 개발자 본인이 생각하는 수준에 미치지 못한다 등 개발자 본인이 기획을 해도 훨씬 잘 만들 자신이 있다 등 다양한 의견을 볼 수 있습니다. 심지어 기획자들은 개발할 때 귀찮은 작업들을 대신해주는 사람들이라는 의견과 개발자 본인이 기획해도 훨씬 좋은 서비스를 만들 수 있다고 확신하는 개발자까지 있습니다.

 

이것이 바로 개발자들의 눈에 비춰진 기획자들의 모습입니다. 바로 ‘뜬구름 잡는 사람들 또는 귀찮은 일을 대신해 주는 사람들’이라는 것이죠. 오랜 기간 개발자 생활을 하였던 저도 왜 이런 생각을 하는지 공감하는 부분이 있습니다만 단순히 눈에 보이는 것이 기획 업무의 전부가 아니다라는 것을 제대로 이해하지 못해서 일어난 오해라고 생각합니다. 오늘은 이런 개발자들의 오해를 풀기 위해 기획자들의 기본적인 업무에 대해 소개하고자 합니다.

 

③ 개발자들이여, 기획자가 하는 일은 생각보다 많다

 

기획(企劃)은 한자로 ‘도모할 기’와 ‘그을 또는 계획할 획’의 조합으로 ‘계획을 도모하는 것’입니다. 그래서 영어로 기획을 Plan이라고 하지 않고, Planning이라고 합니다. 한 마디로 기획이란 ‘Why to do?’와 ‘What to do?’를 명확히 하는 것으로써 ‘왜 할 것인가?’와 ‘무엇을 할 것인가?’를 결정하는 것입니다. 이에 비해 계획은 ‘How to do?’ 즉, ‘어떻게 할 것인가?’를 정하는 것입니다. 왜 할 것인지를 결정하는 것이 기획이고, 어떻게 할 것인지를 생각하는 것이 계획입니다. 즉, 기획을 다시 한번 더 정의하면 기획자의 의도가 반영된 계획을 도모하는 일이라는 것입니다.

 

기획의 분야는 너무나 많습니다. 이 중 오늘은 개발자들과 함께 협업하는 분야인 서비스 기획(인터넷, 앱) 분야에 한정해서 기획자의 업무들에는 어떤 것들이 있는지 살펴보겠습니다. 서비스 기획이란 고객에게 웹과 앱을 통해 새로운 서비스를 제공하기 위해 기획하는 일입니다. 이를 위해 다음의 업무들에 참여하고, 내부 의사결정을 내립니다. 물론 회사의 규모에 따라 다음의 업무에 대한 절차와 복잡도는 줄어들 수도, 늘어날 수도 있습니다.

 

서비스 기획 업무

위 도표에서 보듯이 서비스 기획자는 크게 시장조사, 서비스 기획, 서비스 개발, 서비스 마케팅, 서비스 운영의 단계에 참여하게 됩니다. 많은 개발자들은 서비스 개발 단계의 서비스 기획 1차 이후의 단계에서 기획자들과 협업하지만 기획자들은 하나의 서비스를 만들기 위해 시장조사부터 전략 수립, 회사 내 의사결정 수렴 및 서비스 개발 이후의 단계까지도 많은 영역에서 다양한 부서의 담당자들과 함께 협업을 하고 있습니다. 물론 회사 규모가 작은 경우라면 한 두 사람이 모든 영역을 담당할 수도 있고, 또는 생략하는 경우도 있습니다만 해당 서비스가 커지고, 참여하는 사람이 많아지면 분명 각각의 단계가 서로 다른 사람들에 의해 진행되는 모습을 볼 수 있습니다.

 

서비스 기획을 단순히 서비스 기능을 정의하고, UI를 그린 후 개발자에게 넘기는 활동이라고 너무 좁게 생각하지 마시기 바랍니다. 물론 개발자들이 보는 결과물은 서비스 기획서, 요구사항 정의서가 전부인 것처럼 보이더라도 이런 결과물을 만들기 위해 내∙외부 조직들과 많은 커뮤니케이션과 협조를 끌어내는 것까지 숨어있는 활동이 많다는 것을 이해하면 좋겠습니다.

 

때로는 기획자들이 구현 불가능한 터무니 없는 기능을 개발해 달라고 해서 화가 나십니까? 비현실적인 일정과 이미 시장에 있는 다른 서비스와 유사하거나 또는 많은 서비스들의 장점을 마구잡이로 합쳐서 그저그런 서비스처럼 보입니까? 하지만 제대로 된 기획자라면 기획서 한 페이지, 기능 하나를 정의하더라도 이 서비스를 쓰게 되는 고객의 입장에서 어떤 가치와 어떤 영향력을 줄 것인지에 대해 많은 고민을 하고 있는 사람들입니다. 가끔은 그 결과물이 개발자의 눈에는 초라하게 보일지라도 기획자를 존중하고, 고객의 입장에서 서로 같은 방향을 두고 협업한다면 분명 의미 있는 서비스가 탄생할 것입니다. 성공적인 프로젝트, 성공적인 서비스를 위해 기획자의 업무를 조금 더 넓은 시각으로 이해해 보심이 어떨까요?

반응형
반응형
PostgreSQL로 시작하는 SQL 코딩입문 Part 1 - 기본 편
국내도서
저자 : 박상용
출판 : 엔코아 2019.11.27
상세보기
PostgreSQL로 시작하는 SQL 코딩입문 Part 2 - 활용 편
국내도서
저자 : 박상용
출판 : 엔코아 2019.11.15
상세보기
Node.js 교과서
국내도서
저자 : 조현영
출판 : 길벗 2020.07.25
상세보기
개발자도 궁금한 IT 인프라
국내도서
저자 : 정송화,김영선,전성민
출판 : 제이펍 2018.06.11
상세보기

반응형
반응형

"자바 두명 타세요" 개발자 인력시장에 비유한 SW채용박람회

news.mt.co.kr/mtview.php?no=2020120310284718257

 

"자바 두명 타세요" 개발자 인력시장에 비유한 SW채용박람회 - 머니투데이

한 IT 공공기관이 소프트웨어(SW) 개발자 온라인 채용박람회를 진행하는 가운데 안내 포스터에 SW개발자를 새벽 인력시장 인부에 비유한 이미지를 사용해 물의를 빚...

news.mt.co.kr

한 IT 공공기관이 소프트웨어(SW) 개발자 온라인 채용박람회를 진행하는 가운데 안내 포스터에 SW개발자를 새벽 인력시장 인부에 비유한 이미지를 사용해 물의를 빚고있다.

판교창업존 운영기관인 경기창조경제혁신센터가 진행하는 '스타트업DNA-623 오픈런' 온라인 채용박람회 포스터다. 중소벤처기업부와 창업진흥원이 후원하는 이 행사는 스타트업들로부터 구인신청을 받고 이후 취업을 희망하는 구직자가 지원서를 제출하면 온라인상에서 매칭해주는 채용이벤트다.

하지만 좋은 취지와 달리 행사 안내포스터에 마치 영등포나 구로 새벽 인력시장에서 개발자를 픽업하는 듯한 이미지를 사용해 구설에 올랐다. 특히 "자바 두명 타세요"라는 문구는 이미 수년전부터 개발자들의 열악한 처우를 건설인부의 속칭 '노가다'(건축 및 토목노동자를 의미하는 일본어 유례 속어)에 비유한 사례로 회자돼 온 것이다.

최근 4차 산업혁명과 비대면 열풍으로 AI(인공지능)과 클라우드, 블록체인 등 SW시스템 개발 수요가 폭증하면서 개발자 부족현상이 심화되는 현실과도 맞지않다는 지적이다.

한 SW개발자는 "개발자 채용박람회라하면서 국가가 나서서 저런 인력시장 그림을 갖다 붙이는 것은 너무한 것 아니냐"면서 "오픈런이라는게 도망가라는 뜻인가? 개발자를 조롱하는 것같다"고 질타했다.

개발자 커뮤니티 오키의 노상범 대표는 "나름 유머라고 생각한 모양인데 담당자의 IT에 대한 인식수준이 저것밖에 안되나 싶다"고 꼬집었다.

경기창조경제혁신센터도 이같은 지적이 일자 포스터 이미지를 교체했다. 센터 관계자는 "개발자들을 모신다는 의미로 비하할 의도는 없었는데 잘못 전달된 것 같다"면서 "일부 지적이 있어 어제 바로 포스터 이미지를 교체했다"고 밝혔다.

 

반응형

+ Recent posts